71–80 of 120 posts
Earlier quoted context omitted.
Plus systemd isn't UNIX, but going with Plan 9 concepts is now UNIX? Yeah, right.
Plan 9 was designed as an advancement on UNIX, where 100% of everything is a file. so, I say yes
Earlier quoted context omitted.
Care to elaborate on your problems? Or maybe a more fundamental question would be -- would you be interested in a project like this solving whatever your particular gripes with systemd might be?
Thanks for a constructive response! I don't code any more, and I was never an OS-level programmer. And the systemd debate has been argued, and my champions lost. So I concede; I don't want to argue about systemd. The problems are still there though, and I'm interested in ideas that propose to solve them. This article was scratching different itches than the ones that bother me. I'm not interested in Kubernetes, or an…
You don't own any USB peripherals?
systemd is a real power tool and the more I learn about it the better I like it.
When you need to get something done, systemd often as not has your back.
Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch it on with "IPAccounting=yes" and read the values and kill the service if its data egress was beyond my maximum.
This is just one simple example of how systemd makes life easy - there's many, many more examples.
For example did you know that systemd/nspawnd lets you do virtualisation with all the benefits of containerisation such as resource/memory optimisation? The more you dig, the more you'll find to like about systemd.
systemd haters gonna hate but show me something better.....
If anything, systemd influences what modern Linux is so heavily that modern Linux should be referred to as linux/systemd instead of gnu/linux.
Does anyone know if it’s possible to run multiple instances of an app via systemd that all listen on the same port and it does some kind of round robin load balancing to the services? I could introduce my own load balancer proxy like Envoy but I want to reduce complexity as much as possible for systemd to be a viable alternative to k8s.
http://0pointer.de/blog/projects/socket-activation.html
I've done it with Python it's very easy.
systemd listens on a port and when a connection request comes in it starts your service. You could spawn a new process and let systemd keep waiting for new inbound connections.
Earlier quoted context omitted.
I noticed the same but came away with a different conclusion, "hey, k8s is reimplementing the OS.". In other words, concepts which have existed for years, battle tested and well known, are new and untested in the k8s world.
They're not even really new or untested, just being done at a different plane of abstraction. Running a system efficiently across multiple machines requires different implementations of familiar abstractions than running on a single machine. Even the single machine approach has changed dramatically in the last 20+ years. We started single program, went to single user, to multi-user, to multi-processor, to multi-core,…
Like, it appears to target doing same thing systemd does but with different APIs which is like... okay ? Sure, some consistency on one side, on other it is now entirely dissimilar from anything that looks like normal Linux userspace.
I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'
Same - we now use systemd to sandbox our apps, set resource limits, hide the rest of the system, mount read-only FS, etc. Add a custom SELinux policy for your service, and you get a compelling alternative to containerization (at least at runtime).
If someone is building say an embedded system that has to run different services (say a NAS, or a router), it's pretty compelling alternative to a bit more heavy weight containers like docker.
systemd is better than "fine" or "great" - systemd is awesome. systemd is a real power tool and the more I learn about it the better I like it. When you need to get something done, systemd often as not has your back. Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch…
Earlier quoted context omitted.
systemd is like chicken tendies -- its always been there for me.
My first experience was with Arch Linux right when they switched to Systemd. I hated it, but I didn't really get what it was, not knowing what an init system or a process even is. But I was then quite surprised a few years later when it was just the normal thing for me when people in Debian were basically fighting a war over it.
I dislike its "let's just reinvent features that worked entirely fine" (like journalctl binary logs WITH NO FUCKING INDEXING, so they are slower than text files for usual operation somehow), but at its core competence it's extremely useful.