A Slint fanboy from Berlin.
You said Lennart is obnoxious and there is nothing like a big "that is not my problem" to not get your project adopted.
IMHO he does manage to get his projects widely adopted. His personality does not seem to have the effect you claim it has.
Systemd said on its first website that its a system management daemon. That is where the name came from. It was never supposed to be just an init system.
No need to buy out udevd, considering the guy doing that was on board with systemd from the start and made sure that systemd-init can make maximum use of udev and the other way around... you typically do want to start stuff in response to hardware appearing and disappearing. Now they can do that safely by just asking systemd-init to manage the services. They needed to run stuff thenselves before, which pretty often ended up blocking the udev daemon from recognizing new events... a quality of live improvement for everybody involved:-)
The rest has similar stories (only run network services when the network is up, start services only after the system clock has a sane value over starting the service and then adjusting the time at some later point (which some services handle really poorly), ... . There are some damn good reasons for the stuff systemd does. That bootloader is a pretty central piece in the image by the way.
Oh, and did I mention that anyone using or talking about non-systemd methods of doing things tends to get painted as "oh that's OLD and OUTDATED and OBSOLETE, just use the systemd way it's Modern™ and good"?
That is pretty much the only thing I can agree with:-) And that is because the systemd ways are ofentimes way more robust and able to deal with corner cases way better.
Considering how widely Lennarts code got adopted: You must be missing something.
Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
Ok, thanks for the summary.
Anything that is cool/unusual/noteworthy about it?
To be fair: Free software projects were and also are dying from lack of ownership.
And the existing free software projects tend to be old and make it really hard for young people to join IMHO. They avoid the popular (and proprietary) stuff, which makes them hard to discover and their processes seem archaic.
When going so far back: Please do not leave out the FL part of FLOSS. Free/Libre software kicked this all off, the OSS is a later attempt to "sell" the development process FL software came up with to companies, stripping out all the pesky ideas about society benefiting for moving all the benefits over to the companies using OSS. Free/libre softwsre and OSS are technically the same, but the idea behind the licenses are so very different: Free/libre software wsnt to give rights to end users, OSS cares about the freedom of the developers between yourself and end users -- giving the companies the right to commercialize your work for you.
The moment you stop caring for the social and societal aspects of software, it becomes OK to host on a proprietary service. That was never the case for the free/libre parts of our community. Those projects tend to shun proprietary services like discord, github and stuff. Pretty old fashined... not very sexy for young devs:-(
We said the same about memory safety: That's something a compiler can not solve. Now it does.
It is nice to see that sometines things do improve.
You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.
Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.
More than that: "its only an init daemon that does not even make use of Linux features". They all try to work on all posix systems while systemd is Linux-only and uses everything the kernel can offer to make things safer and more reliable.
I revolve very much around copyleft and its ideology. Free software formed my entire career, just as it did for the founders of Slint. From my point of view slint is GPL and offers some other license options for users that do not want GPL for whatever reason.
Forking slint is just as easy as forking any other GPL licensed project: Take all off slints code under GPL and you are done. Yes, you can not relicense that fork to a more permissive license without replacing all the code that you did not write... but that is exactly the same as with any other GPL project you fork. Any use of Slint under GPL is exactly as using any other GPL project, with the same obligations and protections to all parties involved.
I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from. Is it "just" because there is a company backing it? Or because that company is selling their product in addition to oing it under GPL? That is fine for the GNU project from all I understand. Or is it because of contributions happen under MIT terms? But that does not effect the end users that the GPL is protecting in any way.
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.
You are fine with a free software project using Slint as well: Slint is a GPL project, with everything that implies. The releases are out there and the slint project is bound to the terms it released them under. In theory we could release new versions without the GPL option, but we can not take the sources of the released versions away. Neither the other licensing options nor the contribution rules change that. If youbare happy with GPL dependencies, you can use Slint just as any other GPL dependency, with the same risks and benefits.
The copyright holders of any GPL project can decide to relicense their (future) releases. I admit that it is a bit simpler in Slints case due to the contribution rules, but other projects have similar rules in place. Copyright assignments, CLAs, ..., they all exist to simplify a possible future relicensing effort. And even GPL projects without such provisions in place have manged to relicense before.
As a user of Slint you typically never get into contact with our contribution setup at all. Only a contributor might pause and decide not to spend time on Slint due to that. IMHO that is entirely normal: I use tons of free and open source projects that I would never contribute to -- for various reasons ranging from contribution terms, to programming language being used or the projects community.
In many cases you can also publish slint related code in your own repository under whatever license you like. While this obviously does not work for core functionality that has to live in Slint itself, it does work for a wide range of things you might want to make available (like new widgets, ...).
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.
You contribute code to slint under MIT and you can also use that contributed code under MIT or any other license of your choosing, it stays your code after all. You can not use other peoples code from the slint repo under MIT though, that is correct. The royalty free license tries to get as close to MIT as we can while limiting the use on embedded... but with that limitation in place it is of course not an open source license.
Contributing back to Slint is in no way required, so if you do not like our contribution terms, then you are free to not do so. Ypu are also free to use something else if you do not like our license terms.
We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times, often with extensive community feedback, to get it as clear as it is right now. If you have ideas on how we can improve, I am all ears.
You are technically correct: Slint is free software. You can get Slint as GPL or commercial terms -- or the royalty free license. The latter lets you do whatever you want anywhere with the exception of "embedded" (this exception makes is not open source).
When you contribute to any MIT license project you are in the same situation: Your code will be redistributed by some company under different license terms. That's the point of MIT & Co. You contribute MIT code to a project, the project releases its code under MIT, and a company consumes the project and restricts its use. Slint is just cutting out the middle step here.
Disclaimer: I work for Slint and appreciate being paid for contributing to open source software. I also appreciate Slint being free software.
It is unfortunately developing very slowly and it is impossible to interact with git repos... which nowadays is basically every repo:-(
Take a look at jj. It is not as ambitious, but develops faster and you can use it with any git repository out there (as long as it does not need git submodules that is).
This is the presentation from FOSDEM about the OS:
Rust @programming.dev Slint 1.7 Released with New Widgets, Multi-Window Support, and Live-Preview Redesign
Programming @programming.dev Slint 1.7 Released with New Widgets, Multi-Window Support, and Live-Preview Redesign
The security theater is strong in this one.
"Nothing on this page asks for your faith.", immediently followed by a whole list of "trust me" (to manage the keys correctly, that the person notices the keys getting stolen, that she manage the entire signing process correctly, ...). No HW is used that could make it harder to steal keys, just some offline USB storage and a password manager. Every mainstream distro does way better than this, incl. Void linux this is based on.
No systemd with all the security improvements that brings either, but I guess that will bring in a small fan base:-)