101–110 of 317 posts
Earlier quoted context omitted.
Hey, someone rediscovered xinetd
I once won a backdoor contest by installing a systemd socket who launched /bin/sh as root. At this point, people don't question why systemd is being bound to some random ports.
Earlier quoted context omitted.
I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the…
From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong.
One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?
Earlier quoted context omitted.
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
I'm not a Linux expert, but I thought that systemd was generally hated?
On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together.
On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers. There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety.
What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
Earlier quoted context omitted.
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the…
> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before. From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me…
I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
Earlier quoted context omitted.
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can…
Earlier quoted context omitted.
I'm not a Linux expert, but I thought that systemd was generally hated?
>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a…
FreeBSD & OpenBSD would happily disagree.
Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
I'm not a Linux expert, but I thought that systemd was generally hated?
Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files.
Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.