241–250 of 251 posts
Earlier quoted context omitted.
arch (or any rolling release) on a home server doesn't sound like a good idea?
Once you try a rolling-release distro you realize it's actually a very good idea
OpenSUSE Tumbleweed is a lot more stable than ArchLinux for that kind of stuff though. It stages updates in tested snapshots. ArchLinux updates just error if you time them right.
Earlier quoted context omitted.
Once you try a rolling-release distro you realize it's actually a very good idea
It's not though, few server usecases allow/require your environment to change every day. OpenSUSE Tumbleweed is a lot more stable than ArchLinux for that kind of stuff though. It stages updates in tested snapshots. ArchLinux updates just error if you time them right.
Earlier quoted context omitted.
It is more like the ZFS started supporting Linux, not FreeBSD uses Linux implementation.
>The switch to [ZFS on Linux] as upstream https://papers.freebsd.org/2019/eurobsdcon/jude-the_future_o...
Earlier quoted context omitted.
> Both of these are very far from the normal needs of linux installs: there is no one size fits all, there are even interesting inbetween (chrony doing hardware time-stamping with ntp is very clever) but when you design a system, you have to make choices. There were choices/options, some of which have existed for decades. Instead of replacing them, systemd could have provided optional or mandatory services (eg time,…
> Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled > but I do kn…
This was over 5 years ago so I don't recall the details, but it did involve an issue/bug with systemd's handling of the way its internal services were disabled - it MAY have been unique to RHEL. Their fix was ultimately to upgrade RHEL that by then defaulted to chrony, but they were planning on that upgrade anyways. At the time I was making fun of my friend for using Kubernetes, which IMO is another overly complicated solution. :-P
> Maybe I can help you with that - I used to run a non systemd DHCP
Thanks, but I did solve most of the problems; it was a pain as both documentation and other issues (that again may be resolved) at the time made it a much larger hassle and we were an ubuntu shop moving from upstart to systemd that ubuntu 16.04 moved to. Now that systemd has "won out" (and I have accepted that it has), there's more clear and concise examples in documentation and stack overflow. I still dislike that it bloated out what IMO should be just a service and process management framework, though.
> RE IPv6
As I said, IPv6 (and IPSec) was used as an example of how flexibility is required when supporting services or protocols (and I'm a bit pleasantly surprised that systemd-networkd does), not an issue I was actually fighting. Also, enough consumer ISPs hand out /64's that flexibility isn't easy.
I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files, as it makes it harder to get a holistic configuration view. Fortunately that's a rare experience I need to deal with in today's world and I don't use linux as a router.
Earlier quoted context omitted.
> Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled > but I do kn…
> What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain. This was over 5 years ago so I don't recall the details, but it did involve an issue/bug with systemd's handling of the way its internal services were disabled - it MAY have bee…
Using Kubernetes is rarely justified because most companies are NOT at google scale :)
> I'm a bit pleasantly surprised that systemd-networkd does
There are many very pleasant surprises with it. I only wish it integrated better with intel iwctl
I'd also be happy if it duplicated iwctl functions so I could get rid of it, and it would be even better if it could also replace bluez: wireless is getting more integrated, with the new WIFI protocols giving a role to BLE (ex: Wifi-Aware 4.0 Instant Communication)
Read about Wifi Aware 4.0 and you will see why having systemd-network work with iwctl and bluez would be much harder than integrating them
> I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files
Oh no it's about chunking out your /56 prefix to multiple /64 subsets within that prefix. In that specific case, I agree with the article that systemd also made that simpler compared to what needs to be done when not using systemd
> Thanks, but I did solve most of the problems
Great! Should you run into problems during your 24.04 migration, my offer still stands: I think systemd is a nice tool, and I'll be happy to show you how to use it for advanced usecases
Don't hesitate to ping me on ycombinator if I don't reply to your email (the spam filter is not optimal)
Earlier quoted context omitted.
But where does the init system end and the kitchen-sink begin? For instance do you consider networking to be part of init or is it something else. For me, I bring network up in initramfs, so it's definitely part of my init. The only truly bad systemd-* I've worked with is systemd-journald. Which often fails to contain log entries that should be present or simply just corrupts itself.
> But where does the init system end and the kitchen-sink begin? resolved, timesyncd, homed, journald, networkd (was very happy with Debian's interfaces(5) ). Never thought of mounting file systems as process control, so also add mounting and taking over fstab . Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of. (I'm personally most regularly annoyed by resolved…
Found one, repartitioning:
* https://www.freedesktop.org/software/systemd/man/latest/syst...
Earlier quoted context omitted.
> But where does the init system end and the kitchen-sink begin? resolved, timesyncd, homed, journald, networkd (was very happy with Debian's interfaces(5) ). Never thought of mounting file systems as process control, so also add mounting and taking over fstab . Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of. (I'm personally most regularly annoyed by resolved…
Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl. Having systemd units automatically categorized and queryable has been very nice (the -u flag). The tag flag has also been great for me. The --since and --until flags are godsends, I don't really care to waste time converting timestamps in my brain when all I want to do is do somethin…
Except the file format does not seem to be ACID and can get corrupted, so if the system crashes you may lose the reasons for said crash. This is strange since SQLite was available at the time, so I'm not sure why they didn't use a battle-tested, known-good format; Howard Chu (of OpenLDAP, etc):
* https://www.linkedin.com/pulse/20140924071300-170035-why-you...
> To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.
Centralizing logs from my perspective is sending them to a central host, which last time I checked, journald could not do, so I have to run (r)syslogd regardless to do off-host log-shipping.
And it's easy enough to tell (r)syslogd to put everything in one file (which is the default on some distros) and optionally do separate file at times. With the added benefit of not necessarily having all of your eggs in one binary basket. And if you want a query-able logging API, you can do that too:
* https://www.rsyslog.com/doc/configuration/modules/omlibdbi.h...
* https://syslog-ng.github.io/admin-guide/070_Destinations/270...
> I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices.
My complaint about systemd is about tight coupling between components. If someone finds limitations with (e.g.) journald, how do they swap it out or write a replacement? If the systemd folks want to have their own logging system that's fine, but why won't they architect things so it can be swapped out?
> And really it's not like systemd is ripping away your old tools especially in that particular case.
You mean like udev which used to be in a separate repo but the systemd folks took and tightly coupled?
Earlier quoted context omitted.
Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl. Having systemd units automatically categorized and queryable has been very nice (the -u flag). The tag flag has also been great for me. The --since and --until flags are godsends, I don't really care to waste time converting timestamps in my brain when all I want to do is do somethin…
> Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl. Except the file format does not seem to be ACID and can get corrupted, so if the system crashes you may lose the reasons for said crash. This is strange since SQLite was available at the time, so I'm not sure why they didn't use a battle-tested, known-good format; Howard Chu (of Op…
Earlier quoted context omitted.
> ZFS is probably the biggest reason for me. Maybe in the past there was an argument for that, but ever since FreeBSD started using OpenZFS implementation...what's the difference? My ideal OS would be something like NixOS, but on FreeBSD and with better language than Nix.
> My ideal OS would be something like NixOS, but on FreeBSD and with better language than Nix. Something nicer than nix would be nice, but otherwise perhaps keep an eye on https://github.com/nixos-bsd/nixbsd
Earlier quoted context omitted.
ZFS is a first class part of FreeBSD. you can use it on linux, but it will always have some rough edges. How rough it open to question though, for some it works well.
Used ZFS on Debian in production for 8 years, yet to experience rough edges but always interested to learn.
- bootloader (when root is on ZFS)*
- ARC vs kernel page cache and OOM Killer
That's all in my opinion.
*: Relative to FreeBSD, but that's because bootloader in FreeBSD is part of the base system and in linux it could be one of many.