As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.

I still have weird glitches where applications don’t seem to update on screen (chrome and firefox, both natively doing wayland).

Lack of any solution for programmatic geometry interaction. This one has been afflicted with ‘perfect is enemy of good’, as the X way of allowing manual coordinates be specified is seen as potentially too limiting (reconciling geometry with scaling, non-traditional displays), so they do nothing instead of proposing an alternative.

The different security choices also curtail functionality. Great, better security for input, uh oh, less flexibility in input solutions. The ‘share your screen’ was a mess for a long time (and might be for some others still). Good the share your screen has a better security model, but frustrating when it happened.

Inconsistent experience between Wayland implementations. Since Wayland is a reference rather than a singular server, Plasma, Gnome, and others can act a little different. Like one supporting server side decorations and another being so philosophically opposed to the concept that they refuse to cater to it. While a compositing window manager effectively owned much of the hard work even in X, the X behavior between compositors were fairly consistent.

I’ve been using Plasma as a Wayland compositor after many failed attempts, and it still has papercuts.

Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.

Uh… Sounds like it’s not really system’s fault, your setup is just terrible.

I don’t know his specific issue, but the general behavior of systemd going completely nuts when something is a bit ‘off’ in some fashion that is supremely confusing. Sure, there’s a ‘mistake’, but good luck figuring out what that mistake is. It’s just systemd code tends to be awfully picky in obscure ways.

Then when someone comes along with a change to tolerate or at least provide a more informative error when some “mistake” has been made is frequently met with “no, there’s no sane world where a user should be in that position, so we aren’t going to help them out of that” or “that application does not comply with standard X”, where X is some standard the application developer would have no reason to know exists, and is just something the systemd guys latched onto.

See the magical privilege escalation where a user beginning with a number got auto-privileges, and Pottering fought fixing it because “usernames should never begin with a number anyway”.

Nothing much, just getting far fewer client emails for some reason…

Well, we got to see roughly something play out with the xz thing. In which case only redhat were going to be impacted because they were the only ones to patch ssh that way.

Most examples I can think of only end of affecting one slice or another of the Linux ecosystem. So a Linux based heterogenous market would likely be more diverse than this.

Of course, this was a relative nothing burger for companies that used windows but not crowdstrike. Including my own company. Well except a whole lot fewer emails from clients today compared to typical Fridays…

I’ve not used crowdstrike, but looks like a part of the pitch is “cloud managed”, which often implies that the vendor takes care of everything, including updates. Particularly since they market it as a security solution, they weld likely emphasize that they can update rapidly enough to keep up with security attacks that move very quickly because they don’t care about “risk”.

All I’ve noticed is that a lot of internet related things in my work are much faster today.

The schadenfreude could only be sweeter if my company used CrowdStrike on all the Windows systems. Then I really would have had a very peaceful focused day.

Yeah, time to switch from CrowdStrike to SolarWinds…

Related, I predict Windows on ARM will be a massive failure, again.

Windows is Windows because a critical mass of their market is terrified of being vaguely incompatible with any software they use today. Wine will never give them enough confidence just like ARM emulation of x86 will never give them confidence.

Extra bizarre, from what I’ve seen the Windows devices vendors are treating the ARM variants as a premium model and charging more for them, despite having no real compelling story for the customers. You can either have an x86 offering that’s from all appearances just as overall capable and absolutely able to run your software today, on an ARM offering that is more expensive and maybe a bit less compatible, with maybe better battery life (either sincerely or at least a belief).

Mac is able to force the issue because the hardware and software all wanted to make ARM happen and forced it, but with Windows on ARM, only Qualcomm really cares, Microsoft and all the device vendors would prefer to hedge their bets, which in this case tie goes to the incumbent.

Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.

Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.

With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.

Depends on if you stick to distro provided dependencies, then you are generally good, unless a third party repo decided to supersede that dependency.

I have spent a long time carefully packaging as a third party repository and it’s generally doable. Just sometimes another repository isn’t as careful and blows away the distribution provided libraries.

You don’t need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.

The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they’re best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn’t mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.

Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.

“App image” and " install from tarball" violate those principles, but not snap or flatpack.

Per https://www.gnu.org/software/tar/, it’s been the case since 2004, so for about 19 and a half years…

Well, tar.zstd is starting to be the thing now.

You don’t need the z, it auto detects the compression

While that is technically true, Microsoft didn’t really make any effort to correct the misunderstanding, despite it being a widely reported story in tech.

I suspect they had a legitimate faction that was going to say “rolling release” and so they let it go.

Of course, the kernel drivers are now commonly signed. The real problem is catering to manufacturers demanding to have their own bespoke driver pack, often including some stupid branded management application, when it’s just the same as the other dozen manufacturers packaging of the same product. Then you end up with bloated “driver packs” and a system tray of a half dozen vendors screaming for you to pay attention to them and know that they are somehow contributing to your experience.

In Linux, you have a kernel driver and a myriad of vendor’s pci ids mixed together and the vendors just have to deal with it. As a side effect, a USB to serial dongle is about 99% likely to work in Linux, and in my experience 90% unlikely to work in Windows (can’t find the driver for it, or in one very prominent case Microsoft bans drivers of counterfeit chips that function fine, but violate IP rights). Punishing the counterfeiters may have been understandable, but ultimately the unwitting customers paid rather than the counterfeiters (they still sold their devices, but the users that were oblivious suffered).