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).
Is it an advantage though ? One of the main objections in the article is exactly that.
There's no atmosphere that helps with heat loss through convection, there's nowhere to shed heat through conduction, all you have is radiation. It is a serious engineering challenge for spacecrafts to getting rid of the little heat they generate, and avoid being overheated by the sun.
A typical CPU heatsink dissipates 10-30% of heat through radiation, and the rest through convection. In space you're in a vacuum so you can't disipated heat through convection.
You need to rework your physical equipment quite substantially to make up for the fact you can't shed 70-90% of the heat in the same manner as you can down here on Earth
This is so grim. What a stark difference to Japan. On one side there is a government setting up a new company, with the aim of competing at the highest end of the most complex technological process in existence. Meanwhile the EU is setting up bureaucrat managed funds to keep the remaining companies, currently suffering from the decline of the German auto industry, alive. Oh and they also paid TSMC to set up a factory, how pathetic.
What do you think the EU is? It's not a country, not a federative union. These things need a lot of discussions and synchronization among member countries, it does not work otherwise, so it takes time. I also hold the opinion that time is a resource the EU does not have, so it badly needs to reform itself - its framework no longer works for this "new age".
the #1 problem with the EU's administrative structure is that its power comes from below, i.e. from the member states. Any of them could pull a Brexit and the entire union could be in jeopardy.
The #2 problem is language. Despite what many on HN think, European borders very much exist. They exist via language and bureaucracy.
These two combine to create many problems the EU and Europe in general has. The lack of vision, the excruciatingly slow bureaucracy, both are symptoms of the same underlying problems.
Last time I spent a month in Norway I repeatedly had various residents explain to me that various things were the way they were "because we are a socialist country".
If they call themselves "socialist" then I will too.
Well, there is a difference between "this is a socialist country" and "I am a socialist".
Granted though, that under a functioning democracy, there will be overlap: if the country is x then most likely at least a plurality of voters support x. It doesn't mean that "all citizens support x" or "any specific citizen supports x and self identifies themself an x-ist".
> Well, there is a difference between "this is a socialist country" and "I am a socialist".
To be clear, the former is what I was repeatedly told. Nobody personally self-identified themselves as a socialist to me, they described their country as socialist.
Mostly out of curiosity, a read on a TCP connection could easily block for a month - how does the I/O timeout interface look like ? e.g. if you want to send an application level heartbeat when a read has blocked for 30 seconds.
This is very true. Most examples of async io I've seen - regardless of the framework - gloss over timeouts and cancellation. It's really the hardest part. Reading and writing asynchronously from a socket, or whatever, is the straightforward part.
I don't have a good answer for that yet, mostly because TCP reads are expected to be done through std.Io.Reader which isn't aware of timeouts.
What I envision is something like `asyncio.timeout` in Python, where you start a timeout and let the code run as usual. If it's in I/O sleep when the timeout fires, it will get woken up and the operation gets canceled.
I see something like this:
var timeout: zio.Timeout = .init;
defer timeout.cancel(rt);
timeout.set(rt, 10);
const n = try reader.interface.readVec(&data);
No, I'm targeting Zig 0.15. The new Io interface is not in master yet, it's still evolving. When it's merged to master and stable, I'll start implementing the vtable. But I'm just passing Runtime around, instead of Io. So you can easily migrate code from zio to std when it's released.
Yes, seems so - but they shut down a lot more terminals too, not just the seized ones.
And it seems the biggest reason for them shutting down the terminals was pressure from US Senator Maggie Hassan to shut down scam centers, not the government in Myanmar.
They've extended their range, so there's lots of cases where they don't have wild ones around, but there's still overlap, at least according to the article I read.
1. M. Ibericus queen + no male (unfertilized egg) -> M. Ibericus male.
2. M. Ibericus queen + M. Ibericus male -> M. Ibericus queen
3. M. Ibericus queen + M. Structor male -> M. Structor male, no genes from the mother
4. M. Ibericus queen + M. Structor male -> M. Structor/Ibericus hybrid female, (worker ant, infertile)
