Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one.
I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
The problem is ultimately that by choosing one, the other gets left out. So whatever is left out just has one more nail in its coffin. With LFS being the "more or less official how-to guide of building a Linux system", therefore sysvinit is now essentially "officially" deprecated by Linux. This is what is upsetting people here.
I'm OK with that in the end because my system is a better LFS anyhow. The only part that bothers me is that the change was made with reservations, rather than him saying no and putting his foot down, insisting that sysvinit stay in regardless of Gnome/KDE. But I do understand the desire to get away from having to maintain two separate versions of the book.
Ultimately I just have to part ways with LFS for good, sadly. I'm thankful for these people teaching me how to build a Linux system. It would have been 100x harder trying to do it without them.
Linux is just a kernel, that does not ship with any sort of init system.. so I don't see how anything is being deprecated by Linux.
The LFS project is free to make any decisions that they want about what packages they're going to include in their docs. If anyone is truly that upset about this then they should volunteer their time to the project instead of commenting here about what they think the project should do IMO.
nothing is actually stopping people from understanding systemd-init except a constant poorly justified flame war. it's better documented than pretty much everything that came before it.
> As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
Maybe they're KDE users. I was under the impression that gnome requires it. FTA it sounds like KDE will soon too. Gentoo doesn't come with a desktop by default either, you have to emerge it, which might install systemd..
FTA: "The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd"
> I was under the impression that gnome requires it.
It doesn't seem to require it at this moment. I have "-systemd" in my USE flags, and have neither sys-apps/systemd nor gnome-base/gnome currently installed. After enabling several USE flags that have nothing to do with systemd [0], emerge was quite happy to offer to install gnome-base/gnome and its dependencies, and absolutely did not offer to install systemd.
Honestly, I don't even know if GNOME has a hard dependency on Wayland... I see many of the dependent packages in the 'gnome-*' categories have an "X" USE flag. I CBA to investigate, though.
Is KDE Plasma building in hard systemd requirements, or is it just building in hard Wayland requirements? I'd known about the latter [1] and -because I'd thought it was important to the KDE folks that KDE runs on BSD- would be surprised if they irreversibly tethered themselves to systemd.
[1] Though do note that the same blog post that announced the change in policy for Plasma also announced that no other KDE software was going to have a hard dependency on Wayland for the foreseeable future.
Read the article: "The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd"
I really like SeaFile for this kind of thing. It follows the "do one thing and do it well" philosophy. It's just file sync with some basic document editing features (markdown, .doc I think). Super fast and dependable, highly recommend.
From what I understand (may be wrong) this is exactly the reason that they stopped allowing Linux installs on PS3s.
People were buying them just for this purpose. However, the consoles were sold at a discount because Sony expected users to buy games, controllers, etc. If someone bought a PS3 alone, without anything else then Sony lost money.
I think it's beta for a reason. I just tried the appimage for their latest release and it's behaving in the same broken way that I remember.
I have a multi-monitor setup with different size & resolution screens, so that may be a factor for the problems I'm having. Really hope it'll work someday.
The water used by data centers are either closed loop, meaning that they recirculate a set amount of water.. or the water evaporates, and my understandingis they don't use potable water for those systems. I might be wrong, but I don't think data centers aren't destroying potable water.
The water is reutilized, a big reason is the difficuty to filter new incoming water because of impurities and uncertainty about quality (e.g. winter times make the river water very muddy and difficult to filter).
Second because is because adding water is a cost, whereas reuse existing water is simpler and saves money. There are always losses of water, however these are neglectible.
Not mentioned here but for more extreme cases of devices cooling is done with distilled water (zero minerals) and the whole device works submerged under this water, the hot water isn't thrown away because it distilled water takes a lot of effort to remove the minerals and effort to keep them out, so the closed loop is very efficient.
Here's one in Oregon from today's San Francisco newspaper. If they recycle, it's still loses enough equivalent to 4000 people a year. Maybe that's worth it, but it reads like it's not enough for their future plans. It's not like the city population in question has changed that much historically so there's some future expansion of something planned. That water sounds very pristine since they are going to have to take over national park land.
https://www.sfgate.com/national-parks/article/mount-hood-wat...
You're not wrong. In a worst case scenario I resort to using strace to figure out where a program is reading config from.. from what I understand, if this kernel module is in use then even that approach wouldn't help.
But since the use case is personal dotfiles, I imagine the user isn't going to forget that they set this up.
reply