Re: libcupsfilters: mupdf not "Required"
"Rainer Fiebig" ([email protected] via blfs-dev Mailing List) <[email protected]> Tue, 3 Feb 2026 14:36:34 +0100
| Newsgroups | gmane.linux.lfs.beyond.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 03.02.26 um 03:41 schrieb Uwe Düffert ([email protected] via blfs-dev Mailing List): > Hi, > > On Mon, 2 Feb 2026, Rainer Fiebig wrote: > >> I was just about restarting work on this when I read that bombshell-news >> about dropped support for SysV. What an unfortunate and blatantly wrong >> decision! Very disappointing and demotivating. >> >> To me it seems pointless now to contribute to this project anymore. So >> I drop out of this thread here. > I was hoping I could avoid the discussion, but at this point I feel I > should raise my voice too. I'm happily following *LFS in a way "since > decades". I haven't contributed all that much, but I'm a huge fan of > "your system - your rules". So basically I'm build *my* system and > really appreciate all your effort, teaching etc. to allow me to do that. > And I only contribute when I have the feeling that whatever I found out > about building my system could be ahead of or otherwise be beneficial > for what you are doing "officially". > > Guess it is rather save to say by now that I will *never* switch to > systemd either - as long as I can avoid it in any way. I can't always - > in my company I have to deal with it, but it's burden! I understand the > theoretical benefit for "complex scanarios", but often it is more like > complicating instead of solving problems for me. Yes it is e.g. "caring > about" magically restarting crashed services but may easily do so with > with wrong parameters or credentials. Which is way harder to deal with > than a just stuck or crashed service. That is something I can deal with, > maybe craft a maintenance cron job around it or something. But that may > well run into a race condition with systemd trying to do it faster but > intransparently and unfortunately wrong. Then the service seems to be > "well running" but it is disfunctional. Happened to me more than once... Which boils down to "Systemd's distro - Systemd's rules". Consequently, they should rename the project to "Systemd From Scratch". And - while at it - the servers from "rivendell" to "mordor" and "anduin" to "morgulduin". To me, the decision to drop SysV is all the more incomprehensible and inexcusable as LFS is primarily an educational project that intends "...to help you learn how a Linux system works from the inside out." With simple SysV as an init-system and some effort by the user, that was achievable. With monstrous systemd this idea can be binned. And so the "systemd-only LFS" will fail at its highest-ranking goal. What users now (falsely) learn is that "... 1678 "C" files plus many data files." are needed to bring up and shut down a Linux-system. And only later they may become aware that there would have been an alternative which needed only "... 22 C files ...plus about 50 short bash scripts and data files." to do just the same job. And at the same time let them have better control over their system. > > I'm very aware I may not be speaking for a majority, but *I* would > prefer to drop support for GNOME and Plasma due to systemd in favor of > support for SysV or something... Your system, your rules, your effort, Exactly. To drop the all too willing servants of systemd would also be the obvious alternative for lessening the workload. > I'm not trying to convince anyone. That said: *LFS are not loosing me > that easily. I'm deviating from the book anyway, as long as it helps me > - despite changed focus - the project is welcome. > > @Rainer: Your contribution would not be pointless! Yeah, sure, it may In my view, the decision to drop SysV means withholding a simple and proven core-element of a Linux-system from future LFS-users. I consider this a disservice not only to them but to the Linux-ecosystem as a whole as this only fosters a systemd-monopoly. And I will not support that. I also think that needlessly sacrifycing simplicity and manageability for complexity and intrusiveness is generally not a good idea. Rainer > not meet your own quality standards anymore ("tested against currect > offcial book"), but at least for me, it is welcome anyway. Prominent > example: Thomas' multilib branch is not mainstream either, but > OUTSTANDING VALUABLE!!! > > Keep up the good work, everybody! > Uwe > -- http://lists.linuxfromscratch.org/sympa/info/blfs-dev Unsubscribe: See the above information page