> Using the wl_seat.get_pointer request, clients may obtain a wl_pointer object. The server will send events to it whenever the user moves their pointer, presses mouse buttons, uses the scroll wheel, etc — whenever the pointer is over one of your surfaces. [...] The server sends this event when the pointer moves over one of our surfaces, and specifies both the surface that was "entered", as well as the surface-local coordinates (from the top-left corner) that the pointer is positioned over.
So the program should know the pointer's local coordinates.
Doesn't it use a special metal layer, and the laser high-heats the spots to make them amorphous (to write) and then low-heats them to crystallize (to erase)?
How do you guys solve the problem of conforming DB schema to TS interfaces (or vice versa depending on what you like)?
Do you manually keep them in-sync (that's what I'm leaning into as the most practical solution)? Do you introspect the DB schema? Or maybe use something like Drizzle which autogenerates sql migration to keep the db schema in-sync
Yes, but when you connect your phone to a Nebula network, and go to http://media-server in your browser, the DNS won't resolve it to your desired node, because the phone client (same on desktop) didn't update DNS of the phone, so you'll have to use node's IP address.
That's what I've read (when evaluating Nebula), at least.
It doesn't automatically update, that's true. But I think the typical way to deal with this is to have a nebula subdomain. www.nebula.example.com instead of www.example.com.
When your nodes are not very numerous, and their IPs are statically assigned, you can just have them in a hosts file, or even served by your normal name server if you're using a split-horizon configuration.
If you want multiplatform drivers that you can use to plug your device into computers of any architecture, there are abstractions for that. IMO, it's easier to write 3 or 4 versions of your driver than to use them, but they exist and some people really like them.
If you mean standard logical interfaces, those exist. Also, hardware interfaces are highly standardized.
The problem is that the drivers are exactly the code you write to make all the abstractions fit each other. So there is very little you can do to abstract them away.
> Couldn't drivers be built on some abstraction that would simplify some work?
That's like asking the alchemist to publicly publish their manuscripts.
In an ideal world, yes. However, we don't live there. Until a few years ago, GPUs and other drivers were guarded more carefully than the fucking Fort Knox.
Once you publish your drivers, you reveal a part of the inner workings of your hardware, and that's a no-no for companies.
Plus, what the other commenter said - getting hardware guys to design for a common driver interface is probably not gonna get traction.
Somebody somewhere has to do the work of making sure everything works together. Right now that's the OS. You're proposing moving that work to a standards committee. Either way, the problem persists. You either do that or go the Apple way which is to vertically integrate the wholes stack from hardware to software, but then you have Apple's problem, which was lower hardware compatibility.
If you could get every hardware manufacturer in the world onboard with such an interface, perhaps. But even if 90% of them were onboard there would be edge cases that people and companies would demand support for and there goes your standard.
Drivers exist to ultimately turn actual hardware circuits off and on, often for highly specialized and performance-critical applications, and are often written based on the requirements of a circuit diagram. So any unified driver platform would also involved unified hardware standards, likely to the detriment of performance in some applications, and good luck telling Electrical Engineers around the world to design circuits to a certain standard so the kernel developers can have it easier.
