ICBMs early on applied star tracking to increase precision, starting with pretty simple analog systems (I recall something about shifting a tape with simulated tracker signal to a position matching the launch time) to modern digital map systems.
It was the common complaint about writing VCL apps in Delphi - that single message box app would be 0.5MB binary.
But that was the static overhead of VCL core library and the benefits were considerable compared to writing raw WinAPI.
And unlike MSVC 16kB WinAPI executable you didn't have chance of sudden surprise "oh, but you need to update msvcrt.dll to run this" because Delphi (and Lazarus/FPC) default to statically linking the runtime
It should work with tiled output, so long as a) it reports tiled geometry in DisplayID b) the driver handles it right.
Then it should show up as single display.
It's also how Apple XDR display presents itself to MacOS (two DisplayPort 1.4 tunnels over USB4, tiled layout in DisplayID).
I suspect it's possible that it doesn't have a valid tiled geometry block, but that's something that was already handled right when first 4k displays landed, so...
It didn't win on being superior [1] but because it was either systemd or you don't get to to use GNOME 3.8. On more than one distro it was the reason for switching towards systemd.
I will fully admit though that upstart was worse (which is an achievement), but the solution space was not at all settled.
[1] systemd project tackles a lot of important problems, but the quality of implementation, experience of using it, working with it, etc are not really good, especially the further you get from simplest cookie cutter services - especially because both systemd handling of defaults is borked, documentation when you hit that maybe makes sense to author, and whoever is the bright soul behind systemctl kindly never make CLIs again (with worst example being probably systemctl show this-service-does-not-exist)
> systemd project tackles a lot of important problems
Fundamentally, this was it. SysV startup scripts had reached a local maximum decades earlier, and there was serious "overhang". When I said "superior", I really meant that it was superior to SysV, not that it was the best system that could have been imagined.
And I think the frustration was that, because it did solve so many problems, so many groups (like GNOME) were willing to switch over to it in spite of its warts; and this made it impossible for anyone who was seriously affected by its warts to avoid it. "If you don't like it, don't use it" not being an option was what drove so much of the vitriol, it seems to me.
As I said in that comment from 2019, if the maintainers had had Linus Torvald's commitment to backwards compatibility, I don't think there would have been any significant backlash.
Why did GNOME and basically all the large distros all jump with both feet in on using systemd? Because it was better. It was simply significantly better than all the alternatives. For the vast majority it was a no-brainer upgrade. The holdouts were the one's who had simple needs and were already happy with what they had. The rest of the world jumped on systemd. Because it was better.
GNOME and systemd teams were in many ways joined at the hip, and GNOME unilaterally decided that from 3.6 to 3.8 they would switch certain APIs from one already deployed widely (polkit and related) to one that was documented like north korea is democratic (logind) which also didn't work in isolation from systemd.
Trying to run GNOME 3.8 without logind caused significant problems and instabilities, trying to implement the same APIs turned out a futile endeavour though one OpenBSD guy got sufficiently motivated and kept patching GNOME for OpenBSD for years - though too late for the forced switch.
The large distros jumping "both feet" on systemd were essentially Fedora/Redhat (where it originated and who was employing major maintainers), and IIRC SuSE. Arch was still seen as something of niche and - crucially - was very neophyte about adopting systemd related ideas for significant amount of time with little regard for stability.
The holdouts were not just those who were happy with debian/redhat simplistic run-parts script. They were also those interested in solving the problems in different way. Hell, systemd was pretty late to the party, the major difference was that it had funding behind it
N.b. recently we had a bit of a small scandal in Poland which, among details, had the question of why perfectly fine radios had to be replaced on a bunch of new machines.
The official answer is that the new (L3Harris) radios are for better cooperation with M1 Abrams (the scandalous part was that the machines weren't supposed to cooperate with Abrams).
The unofficial addendum however was that "Americans implement STANAGs in not really compliant or compatible ways"
Everything that can be airgapped probably should be. Healthcare, education, public safety, social services, public administration. Anything that touches massive troves of sensitive data for an entire country or continent.
Non trivial amounts of industrial and civil infrastructure, sometimes the air gapping is also because there's no viable connectivity more so than security reasons (or you have to assume flaky network so the system is designed to operate as separated island 99% of time - for unlikely example Chick-Fil-A has such requirements for their k8s clusters running individual restaurants.
Sometimes it's also simpler to physically air gap a system than to deal with more complex security.
reply