New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yeah, a lot of it is quite opaque but by now it's basically everywhere. From managing your terminal sessions, over udev, dbus (used to panic when it's - world writable - socket received an empty message), syslog down to dictating that you can only run a desktop on vt1 (want to run it somewhere else or even multiple? tough luck... vt1 is where it should be according to Poettering: WONT-FIX.). The fun really starts when you try to not run it (by now even on Devuan fully avoiding nonsense like logind seems to become more and more complicated or even impossible).
Sadly not being updated anymore for a very long time but it's a start: https://suckless.org/sucks/systemd/
The github tickets where confused users try to make sense of Poettering's crazyness just to be told that it's obviously their fault are still gold though.
May for you, but Alma is the heart for cPanel, next to Cloudlinux
debian
I forgot to mention that I use it for services lol.. Will have to research this to grasp it fully, I guess systemd = Linux for me..
Just asked GPT to translate a sample systemd service to a sysvinit script and it looks completely foreign
Edit: This was quite interesting
It sure will. SysV is an archaic scripting monstrosity after all. Nothing wrong with disliking / replacing it. Like i've said SysV's shortcomings are a known problem. I'd probably rather use something like s6 or runit (daemontools, or ...) too if it weren't for the practically non-existent support. It's not really hitting the point though as while systemd being an "init system" is certainly true managing services is only a very little part of what it does. If it had stayed with managing services i'd (hate for Lennart-ware aside) probably even kind of like it.
Watching it right now. I already have an idea where he'll go with this but lets see
@totally_not_banned let me know what you thought of it. To me, he sounded fair (but I don’t know the topic so anything could have)
Actually you probably want a *BSD then. Debian is forced to incorporate a lot of things that are outside its control (e.g., systemd). That's the main drawback of Linux land - all the core packages are independently maintained, so there isn't just one community.
If you want a community that together decides what path to take...then you pretty much have to choose BSD since it's a single build tree including kernel and userland. In fact, you probably have to choose OpenBSD since Free/Net take all of Open's projects (ssh, ipf, etc.) onboard.
Debian 12 i386 can install in under 500MB.
We really should stop calling it RedHat and call it what it is: IBM.
Big publishers certify their stuff against RHEL. So if you're going to run enterprise stuff, you're often running RHEL because that's what the vendor supports. Vendor support matrixes drive everything in enterprise.
Not sure I agree with either of those adjectives. It's just a different perspective. systemd in my experience is grossly overengineered and is the svchost.exe mindset for Linux. Last I read it's something like 300,000 lines of code. Does it start ntpd better than SysV? You can argue the merits and all these other capabilities, etc., but dude, I just wanted to start ntpd.
I bet 95%+ of use cases are perfectly fine with SysV, which is actually much simpler to learn than systemd. Radically changing the OS (logging, etc.) for 5% of use cases is strange to me, but then, I'm not selling licenses for $800+ a pop whose cost I need to justify.
He sure is but like i said above the general setup gave away a little in regards to where he was coming from. Less so than i thought initially but the "change-resistance" theme obviously was kind of a corner stone.
He's kind of agreeable in general but i think he makes some underlying assumptions that, while probably not exactly incorrect, are given a little to much weight in my opinion. It's a bit hard to go over this in a coherent manner as he's really touching a lot of stuff but i'll try to keep it at least somewhat concise.
First off i get where he's coming from with the resistance to change. There's a ton of people that simply look at the whole thing from a "SysV works for me so get lost" angle and thinking back to the discussion at the time saying that there was a lot of emotional shit thrown around instead of actual arguments is quite accurate (like those death threats sent to Poettering - there's probably little suspicion of me being a Lennart fanboy in any shape or form those but those guys should seriously spend a bit more time outside...). I'm not sure how much this can be made into a major factor though.
Personally i have very little love for SysV (it's clunky and archaic with the only upsides being it's massive flexibility - it's all scripted after all - which comes with a lot of error prone work though and being battle-tested... beyond that...), so my tears shed over seeing it go would be very limited (the machine i'm writing this from actually runs s6, even if it'll probably not be something i'll stick with - i don't have the nerve to write the configuration of every service by hand and i haven't seen a single package yet that would supply those by default). I very much care what it's replaced with though and being forced into a choice between this and systemd i'll grumpily stick to it. Not because i know it or even like it but because it doesn't get in my way.
He's also obviously right about modern systems being way more dynamic that the ones which stuff like SysV init was actually built for (well at least kind of - most rc-like init systems these days actually do dependency management and parallelism, so they are already way more intelligent than their common ancestor) but i think he overestimates the amount of configurations where that's really all to relevant and that's just in relation to the service management part. All those advanced features... I highly doubt they'll see use in more than a tiny fraction of configurations and beyond those will do nothing but add needless complexity, which might not sound like much but is in my opinion really one of the major road blocks in regards to achieving efficiency, reliability and (practical) flexibility.
He makes an important point in that some kind of "system layer" doesn't necessarily have to be systemd though. It shows how the debate is really about two topics. One being on the idea of said "system layer" and one being on the question if systemd is a well engineered piece of software, which - at least to me - are two very different things. As much as i hate for example dbus and as much as i'd claw to it being superfluous on a lot of systems it's hard to deny that at least it's concept makes some sense in certain configurations and there being a lot of uncharted territory in that regard might even reach beyond those. In general i'd be very much open to such ideas even if i think the heavily reduced scope those would have might make them not all that big of a topic.
I also think he kind of nails it with Lennart drawing his inspirations from the big mainstream systems, which is for a large part what is making his work problematic (the other being his horrible attitude and the - in my opinion - lacking talent). There's this huge tendency for those systems to lean towards high complexity black box technology, which, while maybe being perfectly well suited for their environment, are usually quite hostile towards customization (you just don't exchange system parts of Windows or MacOS and you don't care for anyone to understand the inner workings either - actually having those as obscure and cryptic as possible helps you keeping a technological edge). I don't see anything inherently wrong with systemd. It's just that it's really the base to LennartOS and not so much a component to an open system environment.
My only really strong disagreements would be on some rather minor points i guess. Like having some understandable system is all that much about comfort. It's obviously also about that but something being understandable has way further reaching implications than mere comfort. I also don't really get how he intertwines systemd with containers. Both of those are perfectly able to exist independently of each other. Sure systemd has some features in that regard (if i'm not mistaken init can even boot into VMs over network - a feature every single person has obviously been missing for decades...) but there's no real connection between the two. How persistent device naming (it's pros and cons aside) is related to systemd escapes me - it's a kernel feature as far as i know (at least that's where i disable it usually) and a better logging system (as much as that actually makes sense) is kind of a non-topic (even if i understand that he's mentioning it because of all the fighting back then in regards to binary logs, which are in my humble opinion certainly not a wise choice). Kind of like the ability to have user-daemons running from peoples home directories is nice to have but certainly neither all that newsworthy or important.
Did that actually happen? I think that's more legend than fact.
Anyway, he's happy now: he's at Microsoft, where he fits in.
Yeah, i can second that. The community aspect is a pretty strong point of the BSDs (at least for FreeBSD/NetBSD - i haven't really dealt with OpenBSD much yet). In regards to NetBSD it's even pretty common to have forum posts answered by actual developers, which is pretty cool. Up to this point i had not seen anything like this with any but maybe the smallest of the small Linux distributions.
I used to have a script for building embedded systems from generic Debian packages. I'm sure with more effort it could be pushed down further but with deleting a couple of unneeded files here and there i remember it being around 150MB for a basic system.
Agreed. I kind of doubt it starts ntpd at all though. It is ntpd (besides a lot of other things).
Well, kind of. There's a lot of complexity that's easily overlooked when your having written shell scripts for decades on end, which is still very real for someone just getting into the system.
How often do people do that? I can see removing symlinks to deactivate or reactivate services, but if you're installing some common package, it's going to source its config from /etc whatever most of the time and you don't have to touch the shell scripts.
But SysV is so far in the rear view mirror I've already flushed that memory so maybe I'm misremembering.
To be honest i don't really know. I just remember it being reported back then and given the amount of emotion that was poured into the debate i've simply thought it to be realistically possible. I've never actually looked into it though. I might not condone death threats but it's not like i care all that much what happens to Lennart either
Haha. I guess in the end everyone gets what he deserves and i don't mean that only mean that in relation to Poettering...
Sure having to actually mess with the scripts is not exactly a common occurrence but when one takes the inner workings out of the equation a lot of the critique in relation to systemd is probably equally moot as being a mere user that simply hammers in
apt-get installyou probably don't regularly notice that much of a difference either. Things just work or they don't.Well, i guess it kind of depends on the situation. For some people having to whip up init scripts happens more often than for others while the next guy maybe hasn't read a single one in 20 years of using *nix.
i'm use ubuntu and raspbin (i think it's debian for pi ?) and steam os (just try it for gamming, but normally windows still much better for gaming)
@totally_not_banned many thanks! Starting to get the basics of the debate. Very interesting.
@raindog308 I’m not sure FreeBSD is what I need, because, ultimately, I need my stack of applications to run on my OS.
Not saying that like some edgy comeback, I just do. In my view, my primary goal are my applications, and my OS is a way to accomplish said programs. Not really the other way around.
Already using alma 8 or 9 ...
Im using OS/2. EOL means nothing after its been EOL for 10 years.
Yeah, system design might not be everyone's cup of tea but when it is it's a lot of fun. Probably not going to realistically happen but if i ever happen to have way to much free time i totally plan to have a stab at assembling the perfect system (that noone will ever notice or use)
It very much depends on what your stack looks like. If i'm not fully mistaken there is no docker support though so that alone might already make it a nonstarter. At least NetBSD and (i think) FreeBSD have pretty good syscall compatibility with Linux though so even closed source Linux binaries might just work after all.
As far as general application availability is concerned the BSDs aren't half bad, be it FreeBSD's port tree or NetBSD's pkgsrc (which really works mostly anywhere - including Linux - even if 3rd party systems suffer from a chronic lack of testing as it's not used much outside of NetBSD) and OpenBSD is probably not much worse.
Package management on FreeBSD pretty much drove me insane though. It's not that tools aren't good (some are really nothing short of excellent). It's the amount of options to do more or less the same thing which is pretty confusing but that's mostly just because i wanted to compile everything from source. As far as binary packages are concerned it's really not much different from any other package management system.
The biggest difference would probably be (kind of similar to the non-availability of docker) virtualization. There is no KVM (and therefore Proxmox is out of the question) and every BSD has kind of it's own approach to it. FreeBSD has Bhyve and Xen, NetBSD also has Xen and about 3 other systems (of which from what i read none really works... at least out of the box) and OpenBSD likely has something else again. So if virtualization is a requirement chances are it would (under ideal circumstances at least...) need drastic adjustments.
Semi related: Some time ago i ran into https://clonos.convectix.com/ which seems to be kind of a FreeBSD based Proxmox alternative. I didn't really get to it yet but i totally want to try it. Proxmox really has been lacking some direct competition and maybe this is thing is actually a viable alternative.
Bunch of proprietary stuff.
Hypervisors run VirtFusion.
VMs run either:
So realistically, I couldn't use it on the hypervisor (but let's imagine for a second that it dosen't matter, all it does it managing KVM's anyway)
I could probably create a set up where I replace RunCloud.io with a stack of applications on my own, I'm not too sure what limitations there are in that aspect. The underlying stack is:
The other VMs, and I guess these are the most "interesting", because this is where I run custom developed programs using my own "suite of applications" and not just some proprietary tool, they're ALL on Docker
Previously, only one project was on Docker, but I recently implemented Docker on it all
Frontend deploys automatically and backend deploys with version management and one command (./stage or ./prod), all through Docker, Git & Docker Hub - so I guess this would be fairly hard to port over in any way where I maintain my current way of thinking about servers. The containers are often mixes of:
Stuff like that
Edit: ClonOS looks very interesting, at least in theory
Super similar setup here also, debian, docker, compose. Better than spending weeks configuring k8s whilst still not understanding it.
Push commit -> TeamCity CI builds docker images -> Push to self hosted docker registry backed by B2 -> watchdog pulls the latest image onto prod machines when it is updated.
Should get rid of the watchdog bit really, likely replace it with some ansible triggered by CI, then replace TeamCity with Github actions.
Nice!
I'll look into this, especially since I'm honestly somewhat on an JetBrains fanboy (not that I'm proud of it)
I also use GitHub Actions to trigger the Docker builds
I use Docker Hub's free plan and have ALL projects be the same bucket, called "bucket" (creative, I know), and then the tags represent the project:
project-service-environment
About Watchdog, how do you handle downtime? It's not that important or you can build without it? Because if I pull and restart a compose with the latest images, because some services usually take a while to fully stop, it often results in noticeable downtime, so I kind of wanted to automate new backends going live, but for now, I've had to settle on a ./stage and ./prod because then at least I can choose when it goes down
Edit: You probably mean "Watchtower", no?
Big jetbrains fan boy here too, although I'm going to drop TC as my builds will fit into the free actions allowance and it'll free up some resources not having Java services eating memory.
Yeah, my bad, I mean watchtower. Regarding downtime, at the minute I don't care but this is one of the reasons I plan on switching to CI triggered ansible or something. I'll be able to roll services individually + do blue/green deployments as everything is in front of a caddy reverse proxy (need to replace this with haproxy though).
So eventually it'll be spin up new services, reconfigure load balancer to point at new services, spin down old services. With a delay in between in case the lb needs pointing back in the event of an issue
@emgh Yeah, kind of as expected. The general applications wouldn't be much of a problem but replacing Docker (the next best thing would likely be FreeBSD jails which while technically somewhat similar are still a quite different beast) is going to be hard and there probably isn't any even semi-dropin replacement for Runcloud at all. In any case even ignoring Runcloud it would be a ton of pain as you'd basically have to redesign the whole backend from ground up. Understandably not a realistic option.
Same but other way lmao. People recommended Debian and I did yum LOL
Yeah, I was also thinking jails when people talked about docker, but as you say, its a completely different beast. The basic idea is somewhat the same, but that's pretty much where the similarities end.
While I'm not saying replacing docker with jails would in any way be feasible, I do recommend people check out jails anyway, it's a really underrated and overlooked technology and once you grasp it you can do really cool stuff with it.
https://docs.freebsd.org/en/books/handbook/jails/
As an individual, you can actually just use the Red Hat Developer Subscription. Up to 16 VMs are free: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
What speaks against it? Does anyone have experience with it?
That you can’t use 17, 18, or 19.
I think 16 is enough for most people.
I mean you can use for example Almalinux, Rockylinux or even Ubuntu Server for the standard stuff and RHEL only for the important stuff.
It's about the principle. Debian has been just as stable for me.
https://www.debian.org/intro/free