[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systemd



On Tue, 2015-01-20 at 21:22 -0800, Russ Allbery wrote:
> Pretty sure there's no dependency on journald.  I think you have to use
> systemd's syslog passthrough if you're launching systems under systemd as
> an init system (although I'm not 100% sure about that even), but that's
> not the same thing as journald or the journal itself, and that's systemd
> as an init system, not logind, which can run separately.

No, the dependency is unavoidable.  Try running "sudo journalctl" some
time - you will the stuff that it has written under to /run/log.  As is
typical of the systemd mob, it backward compatibly works so well you
don't even notice.  Well you won't if you don't work on device where the
overheads of storing it twice hurt.  If they do you don't have much
choice.  You can turn off syslog, but not journald.

> > Yes, it's very likely some DD's will find other bits of candy they
> > provide attractive - and if we aren't locked in now we soon will be.
> 
> Lock-in is such a weird way of describing free software and published
> interfaces.  It's not at all the way that we were using that term back in
> the days of Microsoft trying to kill free software.

I am not comparing us to Microsoft.  We hold us to higher standards than
that.

Journald it an excellent starting point for a discussion on lock in.
After all why are we forced to use a binary logging just because 

> Maybe it's just that I've been around for a long time now, but I am
> completely mystified by this supposed lock-in concept.  It makes no sense
> to me whatsoever, even after lots of people trying to explain it at great
> length.
> 
> It's *way* easier to replace systemd components than it was to replace
> /bin/login across seven versions of proprietary UNIX, and I and others did
> that all the time.  It meant having to redo everything /bin/login did,
> which was a giant pain in the ass, so it was miserable to have to do it,
> but we needed to do it to get where we wanted to go, so we did.  systemd
> is no different -- it's just software.  It's *free* software, in fact, so
> unlike with /bin/login where we had to reverse-engineer code for which we
> had no source, all you have to do is grab whatever bits of systemd you
> still need, tack them on to whatever you're doing, and as long as you're
> okay with using the GPL, you're all set.  You can even do that on an
> ongoing basis.
> 
> You're about as locked in to systemd as you are into readline.  If people
> write a widely-useful piece of software, surprise surprise lots of other
> software starts using it.  That software will be written to that API.
> That means that, if you want to replace it, you will have to reimplement
> that API or convince a lot of software to change what it relies on.  But
> that's just *normal*.  That's how free software has always worked.  That's
> not lock-in -- or, put another way, if that's lock-in, 90% of the software
> in our archive is locked into one thing or another.
> 
> The alternative would be vast amounts of basically wasted effort writing
> two implementations of absolutely everything, not because you actually
> have problems you're trying to solve, or any unique approach to the
> problem, but just so that you can say that you have two implementations.
> If that sort of thing turns your crank, by all means, knock yourself
> out -- I'm happy to see people pursue anything they like to work on in the
> free software world.  But that certainly doesn't sound fun, interesting,
> or particularly useful to the broader world to me.
> 
> I'm quite happy to have just one implementation of something as long as I
> can fork it when I need to change it.  systemd is under the GPL, so I have
> all the free software freedoms, so I'm happy -- if anything seriously bugs
> me about it, I'll fork it with other like-minded people.  If there aren't
> enough other like-minded people, that's *my* oproblem, not systemd's, in
> exactly the same way that the FSF Emacs maintainers have no obligation to
> keep XEmacs development alive just so that we have two good
> implementations of Emacs.
> 
> -- 
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
> 
> 



Reply to: