Ofcourse they can. But which particular person will do it ?
The "upstream" people deal with their own drivers, subsystems or tasks which takes up their time - but if someone feels they want to take on this too, they'll do it (normally that doesn't happen - it's up to the original authors to take responsibility)
users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?
At the very least, drive letters do make SMB shares a bit simpler for the non technical folks. T:\MyData is easier for them than \\0010-somehost-win.site1.mycorp.loca\Share01\MyData\
I used to support a group of completely tech illiterate users in construction & manufacturing. Them figuring out T:\ was hard enough, ask them to type in a UNC path into the address bar in explorer and you get "Wtf is file explorer? Wtf is an address bar? Where is the backslash key??"
I've set up a local gitea now, and configured a few local runners as we test this setup out.
It's a few hours worth of work. Basic git operations and pull requests works fine for us already.
The interesting part will be how much maintenance this will need, and not the least how hard it'll be to port over github actions. We have trivial workflows, but I suspect this conversion will be the painful part.
How can wifi be a star topology when all clients connect to the base station using the same airwaves? If it really were a star topology, it would also not be possible to use aircrack-ng or other tools to gather data for WPA cracking by passive listening -- that can only happen on a shared medium network.
I think the most accurate classification is that wifi emulates a star topology at OSI layer 2 on top of a layer 1 bus topology.
> But... Why on earth do the people filing an administrative subpoena not have to notify the interested parties too?
Generally they do - with some notable exceptions being if you're a non-citizen and you're no longer in the US, and it's either a criminal investigation or related to intelligence or national security.
> In September 2024, Amandla Thomas-Johnson was a Ph.D. candidate studying in the U.S. on a student visa when he briefly attended a pro-Palestinian protest.
> Weeks later, in Geneva, Switzerland
It is obviously not criminal, but I guess that you don't need much to qualify something as related to intelligence and national security, attending a pro-Palestinian protest may be enough.
It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a Wayland app.
It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use.
Also certain types of power tools for mac probably need use Quartz directly as well.
> Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly.
Honestly I think this is a pretty fair approximation of "no one". How many people are writing tools like this vs. the number of people writing regular applications? A very small number, I'd say.
And after working extensively with both libX11/libxcb and libwayland-client directly, I can say that none of them are particularly pleasant to work with. Actually, no, that's not true: libwayland-client wins, easily. Every single Wayland protocol has code generated for it that works exactly the same way. I suppose the same is (more or less) true of libxcb, but libX11 (and all the other libraries you might have to use, like libXrender, libXrandr, libXext...) are a complete mess.
And even then, libwayland-client has a much lower number of concepts you have to understand than libxcb does, simply because the Wayland protocol has a small number of concepts you need to understand. libxcb is definitely an improvement over libX11, but it can't magically make all the underlying X11 protocol concepts become unified.
Having written a new gtk program recently I had to implement Wayland and X -isms in the code. Off the top of my head X prefers using W_Class and Wayland prefers app-id with each window having a role set. Both are fine. I honestly think Wayland is nicer but realistically you code for both. To get a global hot key you register it with the compositor and it works. But you can run a background daemon to catch all keys if you really want.
And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want.
Why would I want to add more complexity to a display server?
Creating a window and Vulkan context and receiving input events (e.g. what game-like applications need) is fairly trivial via Xlib but far worse in Wayland. The Xlib API also sucks compared to Win32 or Cocoa, but writing a Wayland client for something as trivial as creating and managing a window is much worse than on any other platform (see: https://www.p4m.dev/posts/29/index.html)
Basic window system functionality really needs to be provided by the OS, not by 3rd-party libraries. And there's no reason why simple things like creating a window should be drastically more code in an OS API than in a wrapper library like SDL.
I actually wrote some stuff directly because I was young, poor and stupid.
First year in uni my windows laptop broke, had to lug around a heavy second hand underpowered ppc powerbook and wrote some application I needed that I didn't want "bloated".
Font handling, shared memory backbuffers, network api, etc.. as I wrote in another comment. It is an API to solve over the wire graphics in the late 80s/early 90s era using idioms of that time, and already by year 2000 the problems (rasterization power) didn't exist nor is it even a suitable API surface (even less so 25 years later).
reply