So to be a GPL project you need to be able to trust the project to release all future releases under GPL in addition to having released existing code under GPL?

I do not like this approach:

First of, you need a crystal ball to decide whether a project is GPL or not: Some projects managed to pull off a license change before, just by asking devs whether they are ok and replacing code from devs that did not agree. Its rare, but it happens, so checking for CLAs, copyright assignments, ..., is not enough.

Secondly this definition excludes lots of projects that release their source code under GPL, including the GNU project. They ask for copyright assignment, both to defend the GPL license, as well as to be able to relicense when weaknesses in the current licenses are found. I give you that GNU is probably way more trustworthy wrt. not changing away from the free software spirit than some random company.

But you do get all code under GPL, which you seem to agree is a freedom preserving choice. That does make Slint free software and as save to use as any other free software project out there.

The story is a bit different when you want to contribute to slint. Slint is not a even playing field for contributions. The company has an advantage in that if can use all contributions as MIT and you can only use the companies changes under GPL, commercial, or royalty free terms.

As a contributor you need to decide whether you contribute to the slint repository, or maybe write an add-on library which you are free to license as you see fit.

My coworker used it till his HDD broke, taking his key into data heaven. The repository is still online thanks to radicale, but he has no way to ever get push access to it again.

So it is useless as any misstep can potentially kill your access to the repo.

Yes, I should not have said "impossible": nothing is ever impossible to breach. All you can donis to make a breach more expensive to accomplish.

Those separate tpm chips are getting rare... most of the time they are build into the CPU (or firmware) nowadays. That makes sniffing harder, but probably opens other attack vectors.

Anyway: Using a TPM chip makes it more expensive to extract your keys than not using such a chip. So yoj win by using one.

Well, its a brand new standard library. A fresh start.

Small communities have a hard time staying up to date. X11 was ported decades ago, when non Linux OSes had more mind share and commercial backing. I doubt anyone could port X11 if that was the new thing mainly developed on Linux today.

With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.

If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.

Fuck binary logs too.

Text logs are binary, too... they just uses a pretty common binary encoding.

Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).

Do you actually use text logs in a professional setting? Just curious.

I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.

The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only... Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.

You behemoth is my plumbing layer:-)

I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.

If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.

First off, there are lots of problems with systemd (mostly down in the details) and controversial defaults at times, bugs, bloat, and hickups and whatnot. Like basically in all projects all the time. So of course there is valid critique on systemd, lots of it.

But I have a problem taking any argument seriously that is based on "I am smarter than everybody else". I do not like detail Y or developer Z, so the project X sucks and everybody that disagrees is either a paid shill, forced into it or just stupid. There is no point in even talking with people like that.

Check out the devuan mailing lists then:-)

Most devs have never seen a braille display or used a screen reader. Thos that did probably could not read of the braille display and were happy for the screen reader to read or random words with no idea how to use a computer with just the information read out.

It is hard for a seeing dev to get a feel for how information needs to be presented using assistive technologies (which are usually not even available to the developer).