Re: libcupsfilters: mupdf not "Required"

On Tue, 2026-02-03 at 14:36 +0100, Rainer Fiebig wrote:
> 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
> > 

I had intended to stay out of this discussion. But this does it.

Raving about a non-existing monopoly. Do you have any idea of what a
monopoly is ? Here there is an alternative. so there can be no
monopoly.

That other developers choose to use systemd is not something to blame
systemd for. They are free to use it or not. But they choose to do so
because of its merits.

The basic logic of system is not so different from sysv. Targets
compare to runlevels and service units to init scripts. If the
additional fucntionalaty would be inplemented sysv would also vastly
increase in size. So what is the problem hete. It doesn't seem hard to
grasp to me.

If you have nothing to say but this nonsense but shut up.

I for one fully support the choosen direction, otherwise the project
would soon be next to worthless, 

-- 
=================================================
Maurice van der Stee

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page