Serpent OS Infrastructure & Tooling Almost Completed

[Teggs]

I'm glad to hear that Serpent OS is proceeding. The design philosophies and principles put forth by Ikey drew me to Solus, and the realisation of them by him and others kept me there. Even if Serpent OS does not have the same, or all of the same goals as Solus, I can't help but be interested in it, and intend to try it when it's declared ready for general desktop use.

Good luck to the Serpent team.

[ms178]

As a performance-driven person, I'd love to see their vision of a performant Linux desktop come to fruition. I also used Solus for some time, but the lack of timely updates eventually made me move on. That is my only big question mark: Can they sustain their efforts this time? I hope they will keep on pushing the boundaries for a modern and yet simple distro.

[ermo]

As a performance-driven person, I'd love to see their vision of a performant Linux desktop come to fruition. I also used Solus for some time, but the lack of timely updates eventually made me move on. That is my only big question mark: Can they sustain their efforts this time? I hope they will keep on pushing the boundaries for a modern and yet simple distro.

In terms of processes, our focus is on minimising friction so humans can do what humans are good at and the machine can do the rest essentially.

This is because we believe that it is important to respect the maintainer's time and attention in order to avoid longer term burnout. At the same time, I expect our processes and tooling will keep evolving as we meet new (or simply unforeseen) challenges and find (better) ways to solve them.

[mdedetrich]

IME, it has good concurrency support ootb, yes.

In fact, it has been fairly straightforward for us to rely on both std.concurrency and std.parallelism as appropriate.

I'm not really qualified to give an opinion on how Dlang fares against Rust in this regard, so you'll have to ask elsewhere or make up your own mind on the subject.

As far as resources for getting your feet wet goes, The Dlang Tour is IMHO excellent and so is Programming in D.

Finally, it might pay to read the Dlang vision document, as it accurately and fairly outlines the challenges of bringing an older language (D is around 20 years old now) up to date in a modern world that is increasingly seeing the value of memory safety ootb.

As a final note, Dlang is not without its warts, but my impression is that this is both well known and well understood and is consequently being addressed carefully and thoughtfully by the current Dlang maintainers on behalf of the Dlang Foundation.

I have to commend you for using a more principled and robust tool compared to C/C++. I remember when I was in uni and colleagues were rewriting stuff in D and they generally had very positive views.

My only concern is (and I don't really like bringing it up) is the maturity and robustness of the language at least compared to other options like Rust (If Rust didn't exist wouldn't be saying this). The story might have been a bit different 5-7 years ago, but Rust has been eating D's cake for a while now.

[Ironmask]

I have to commend you for using a more principled and robust tool compared to C/C++. I remember when I was in uni and colleagues were rewriting stuff in D and they generally had very positive views.

My only concern is (and I don't really like bringing it up) is the maturity and robustness of the language at least compared to other options like Rust (If Rust didn't exist wouldn't be saying this if Rust didn't exist). The story might have been a bit different 5-7 years ago, but Rust has been eating D's cake for a while now.

There are a dozen modern mainstream languages to choose from. D is not one of them. That's why I was so perplexed by the choice.
It's not even that D is bad, it's just that it failed to launch and has always been neglected. Looking at the merge requests, there are 3 active maintainers on the Serpent infrastructure, so it's not immediately doomed to failure, but they really could have chosen anything modern that more than a handful of niche hobbyists knew. At this rate, the project is doomed to be a cult project while the rest of the world continues with the variety of modern languages that more people know.

I reject ermo's proposition that it's "close enough to C so people can pick it up", there are an exceedingly few amount of people who want to learn a new language (even if in the same family of the language they're used to), install the tooling, learn the tooling (like how D has an optional garbage collector), set up their editor, learn the idioms of the language just to provide acceptable merge requests to the repository. You're asking a Greek to speak Roman. You're going to have to be deeply invested in this project to go all the way towards doing any of that, and that is not going to be a big crowd. Actually, it's more like playing the lottery.

[blackiwid]

For the package management system and how they both sound far more robust than the more common ones.
NixOS was just what I was originally going to go with because it was the only one I knew of at the time (not interested in Guix), plus it seems to have a ton of packages.
I know Nix is a bit complex and more server-oriented but I'm so fed up with mainstream package managers.

As ermo jumped in in refusing to accept that Serpent is only for desktop I would refuse the notion that there is even any linux distro except maybe chrome or something alike that is exclusively for desktop.

I find it even odd to believe that this small micro optimizations matter for desktop more than for server. I am using mostly nixos for a server and at least 1 desktop.

The feature is not desktop or server the feature is the way to configure, reproducability, and the reasons I try to get to guix os is partially disagreements with freedom (offering nearly by default intrusive semi proprietary stuff like zfs kernel support is icking me a bit) but more so that the configuration language is horror and I am unwilling to learn this brain eating language that makes no sense and is probably out of the nightmares of a sysadmin instead of a real developer.

Desktop is just to small to really target that only by a real base level distro not just a spin like most distros are.

[White Wolf]

This seems like an interesting idea, but knowing his track record of starting and leaving projects, idk if I as a user should bet or invest in this.

I'm using Solus 4th year now. All fine. In this time Fedora broke my other machine once. So when he builds something it's really good. Others are taking it to manage and it's still rolling

[ermo]

There are a dozen modern mainstream languages to choose from. D is not one of them. That's why I was so perplexed by the choice.
It's not even that D is bad, it's just that it failed to launch and has always been neglected. Looking at the merge requests, there are 3 active maintainers on the Serpent infrastructure, so it's not immediately doomed to failure, but they really could have chosen anything modern that more than a handful of niche hobbyists knew. At this rate, the project is doomed to be a cult project while the rest of the world continues with the variety of modern languages that more people know.

I reject ermo's proposition that it's "close enough to C so people can pick it up", there are an exceedingly few amount of people who want to learn a new language (even if in the same family of the language they're used to), install the tooling, learn the tooling (like how D has an optional garbage collector), set up their editor, learn the idioms of the language just to provide acceptable merge requests to the repository. You're asking a Greek to speak Roman. You're going to have to be deeply invested in this project to go all the way towards doing any of that, and that is not going to be a big crowd. Actually, it's more like playing the lottery.

Is this a really long-winded way of implying that you, personally, are most definitely not going to bother to learn Dlang and contribute to Serpent OS tooling?

OK then. To each their own. Live long and prosper.

To those of you with a more curious, inventive and adventurous mindset: Come join the party. We're a friendly bunch. And we have cookies.

[ermo]

I have to commend you for using a more principled and robust tool compared to C/C++. I remember when I was in uni and colleagues were rewriting stuff in D and they generally had very positive views.

My only concern is (and I don't really like bringing it up) is the maturity and robustness of the language at least compared to other options like Rust (If Rust didn't exist wouldn't be saying this if Rust didn't exist). The story might have been a bit different 5-7 years ago, but Rust has been eating D's cake for a while now.

Rust has been "eating D's cake" for a while now (did I just write that sentence on a public forum with a straight face? I think I did. Oops). No question about it. What I see happening is that this acts as a positive driver in making the Dlang Foundation and its leaders + maintainers sit up and get their developer story straight.

If Dlang can approach, say, 80% of Rust's memory safety + lifetime analysis powers (via DIP1000 and associated @safe by default work) and, in addition, focus on making its standard library @nogc by default, all the while maintaining its approachability and quick prototyping properties due to its default GC, then so much the better?

There are undoubtedly areas where Rust is the better choice than Dlang. It's just that our use case isn't one such area; we are doing (user-facing) batch tools and services (not hardware-facing kernel modules in a memory constrained RT SoC domain where manual control and automatic verification of memory management are both essential properties) and we need to be able to react quickly to new requirements, both of which are areas in which Dlang is very well suited while still allowing for super efficient machine code generation where it matters.

And it's perfectly alright to disagree with the above too.

[mdedetrich]

Is this a really long-winded way of implying that you, personally, are most definitely not going to bother to learn Dlang and contribute to Serpent OS tooling?

OK then. To each their own. Live long and prosper.

To those of you with a more curious, inventive and adventurous mindset: Come join the party. We're a friendly bunch. And we have cookies.

I think its more accurate to say that by picking up D you are effectively reducing the potential number of contributors to the project by a large margin. Sometimes the benefits of the language far outweighs this reduction in potential contributors, but I don't see how this is the case when comparing D with Rust. Both D and Rust effectively cover the exact same problem space. The only exception here is that D has an optional GC for the cases where you don't need top performance and don't want to manage memory it however can be argued that Rust solves this in a different way (i.e. it. tells you when there is a bug with memory access) however if you don't want to manage memory there is https://github.com/Manishearth/rust-gc.