HN user

Jasper_

10,237 karma

@JasperRLZ / Jasper#0194 / jstpierre@mecheye.net

Posts16
Comments1,716
View on HN

Blanket blocking socketcall() caused regressions for all 32-bit applications trying to make sockets. In theory, glibc disables socketcall when running on kernel version >= 4.3. In practice, Debian/Fedora/Ubuntu all set glibc's "expected kernel version" to 3.2, so socketcall() is still used on most 32-bit glibc binaries shipped.

https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/...

https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glib...

That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.

The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.

LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).

Most GPU drivers these days are DRM drivers, which implement fbdev support for backwards compatibility only [0]. The fbdev API is primarily "fake" these days.

DRM/KMS using dumb buffers are the preferred API if you want to do software rendering and modesetting. You can find several examples of this online if you search for drm_mode_create_dumb.

[0] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds...

The words "virtual machine" and "interpreter" are mostly interchangeable; they both refer to a mechanism to run a computer program not by compiling it to machine code, but to some intermediate "virtual" machine code which will then get run. The terminology is new, but the idea is older, "P-code" was the term we used to use before it fell out of favor.

Sun popularized the term "virtual machine" when marketing Java instead of using "interpreter" or "P-code", both for marketing reasons (VMware had just come on the scene and was making tech headlines), but also to get away from the perception of classic interpreters being slower than native code since Java had a JIT compiler. Just-in-time compilers that compiled to the host's machine code at runtime were well-known in research domains at the time, but were much less popular than the more dominant execution models of "AST interpreter" and "bytecode interpreter".

There might be some gatekeepers that suggest that "interpreter" means AST interpreter (not true for the Python interpreter, for instance), or VM always means JIT compiled (not true for Ruby, which calls its bytecode-based MRI "RubyVM" in a few places), but you can ignore them.

Every year they drop a "new GPU!" announcement with absolutely no details. All their numbers are "in simulation only".

Last year it was their "Thunder" architecture being the world's fastest GPU, now it's Zeus. Neither one actually exists. https://bolt.graphics/bolt-graphics-unveils-thunder-the-worl...

All their blog posts and marketing material are just generic hype about the concept of raytracing. I don't think these guys have an actual product.

Basis also drops quality on the floor by targeting subsets (ETC1s and UASTC) in hopes of having a "common transcodeable subset". In practice, a number of runtime transcoders seem to just decode to RGBA and then fully re-encode anyway, but on the CPU.

Has anybody ever figured out what "invert a binary tree" means? That came from Max Howell, and nobody else seems to have ever received that question.

The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?

metal-tt/metal-nt require you to specify the exact architecture, and that's not forward-compatible unless you update your application for every new device release. Even minor SKU revisions like applegpu_g13p/applegpu_g13g/applegpu_g13s/applegpu_g13c are different compilation targets, and that doesn't help you when Apple releases applegpu_g14.

Microcode was only used for the RSP, which was a modified MIPS coprocessor and could only realistically be used for T&L. After that, the RSP then sends triangles to the RDP for rasterization, pixel pipeline, and blending, all of which are fixed-function, admittedly with some somewhat flexible color combiner stuff.

Ubershader actually has three different opposite meanings, unfortunately.

The classic usage is a single source shader which is specialized using #define's and compiled down to hundreds of shaders. This is what Christer uses in that blog post above (and Aras does as well in his ubershader blog post)

Dolphin used it to mean a single source shader that used runtime branches to cover all the bases as a fallback while a specialized shader was compiled behind the scenes.

The even more modern usage now is a single source shader that only uses runtime branches to cover all the features, without any specialization behind the scenes, and that's what Dario means here.

It happened all the time. I've played plenty of D3D11 games where clicking to shoot my gun would stutter the first time it happened as it was compiling shaders for the bullet fire particle effects.

Driver caches mean that after everything gets "prewarmed", it won't happen again.

Encryption without authentication is not very useful; if unauthenticated, your ISP could middle-man your connection and effectively decrypt everything while making you think you're encrypted.

If that's not in your threat model, and you want encryption for another purpose, then I could understand that, but currently, protecting the endpoints against malicious attackers in the middle is the big value of TLS.

No, they don't do any of that. There are 100 different blockchain implementations at least, and none of them are standardized across any of those metrics. Everything from the consensus mechanism to the packet format to the bytecode is different. The standard way to interop between the Tezos blockchain and the Polygon blockchain is to create a token on both sides and attach a tag saying "don't touch me I'm actually somewhere else".

The only way to standardize ~all companies would be to have them all run the same exact ledger system, and if it was easy enough to make them do that, it would be easy enough to have them standardize a different reporting system for the same purpose.

The blockchain can't do anything with stablecoins, because that's interfacing with a financial system that's out of the reach of smart contracts. Even if we assume that a stablecoin is backed by real USD sitting in a bank account, there's nothing stopping anyone from just taking money out of the bank account, and the smart contract is none the wiser. You still have to trust someone at the end of the day.

It can't track physical items, because you can always just lie about the data. Company A says "I put the jewels in box 1352", and Company B opens the box to receive a bunch of dish towels. Just because it's cryptographically verified, doesn't mean it has any semantic value.

If Company A and B already trust each other not to put bad data on the chain, then they also trust each other to just send emails back and forth, and you don't need a cryptographically verified blockchain. It secures the least important part of the process.

I'm not seeing what you claim to be seeing in that demo video. I see a per-triangle debug view, and a per-cluster debug view. None of that is showing repetition.

Repetition is a link, not a copy. It's recursive; meshes can share submeshes, which in turn can share submeshes, all the way down.

While it does construct a DAG to perform the graph cut, the final data set on disk is just a flat list of clusters for consideration, along with their cutoffs for inclusion/rejection. There seems to be a considerable misunderstanding of what the DAG is used for, and how it's constructed. It's constructed dynamically based on the vertex data, and doesn't have anything to do with how the artist constructed submeshes and things, nor does "repetition become a link".

The scene needs a lot of instancing for this to pay off. Unreal Engine demos show such things as a hall of identical statues. If each statue was different, Nanite would help far less.

What makes you say this? The graph cut is different for each instance of the object, so they can't use traditional instancing, and I don't even see how it could help.

The main thing that took them down was that when Tears of the Kingdom leaked a week early, the Yuzu developers made a special build available exclusively on Patreon that was able to run it, actively marketed its ability to play a leaked game copy on their YouTube and socials, and in some cases actively pointed people to where they could find a pirated copy for themselves on their Discord server.

Nintendo could have sued them into oblivion at any time (as the court documents show, they had been stepping over the line for a long time), but chose not to. If it wasn't for the Tears of the Kingdom thing, Yuzu would probably still be around today.

Also, there seem to be no sane API for managing layouts or switching them programatically, or subscribing to layout change event

X11 has XkbMapNotify/XkbStateNotify.

Wayland has a wl_keyboard.keymap event.

A better idea would be to allow to send arbitrary Unicode strings and maybe integrate regular input and IME input (input system for typing Asian characters).

Not particularly, the difficulty here is that some clients want text input, and some clients really do want key events (e.g. think games where holding W does not really have much to do with the Unicode code point 'w'). This was discussed for a long time, and the current design was decided as the best option.

IME systems do exist and already work just fine; they are integrated client-side. IME systems cannot really be integrated into the protocol since many of them involve custom UI.

That said, there's a proposal for an "input-method" extension which lets you commit text directly, but I don't think anybody is actively championing it. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

It's a strange distinction, because the standard library sometimes eschews this. `os.path` is accessible through just `import os`, because they made os.py import it into the local namespace.

I wish it was clearer sometimes what was a module, and what was an attribute in the core import syntax. `import foo; foo.bar` only breaks if it's a module, and `import foo.bar` only breaks if it's an attribute. If you do `from foo import bar`, the syntax works with both.

I'm referring to needing to traverse all path segments to determine the winding order for an individual pixel. You can't solve this problem locally, you need global knowledge. The easiest way to do this is to build an acceleration structure to contain the global knowledge (what Slug does), but you can also propagate the global knowledge across (Hoppe ravg does this).