Steve,

Well, I've fought bigger dragons than this and won. And while there are
paid developers working on SystemD, I have not yet seen technical evidence
that they spend any time at all on obfuscation. APIs change, but for
technical purposes, and they don't all change at once. Real programmers
aren't just skilled, they are willing to take a challenge, even if there's
a chance of failure. So far, I am hearing a lot of meekness.

While this discussion has been going on, I outfitted a ham station in my
trailer and pulled it to a dark-sky and RF quiet 10 acre site that I had
bought, to operate for ARRL Field Day. And incidentally, discovered a cave
on my new property. I didn't get in, but there is cold air blowing out of
the ground! So, I've been busy. Now that this project is over, I have some
time to work on the problem of libsystemd0.

My first approach is not to change the library at all, but to make
something that provides all of the services it expects and yet is not
SystemD. Some of the calls might just return errors, but there is no reason
that other software can't provide the expected information. If that works,
I would try the unmodified libsystemd0 binary and unmodified GNOME
binaries. In other words, hack only one thing, and leave everything else
unmodified.

This could also be a path to replacing SystemD on Debian without hacking
all over the distribution.

    Thanks

    Bruce

On Tue, Jun 27, 2017 at 7:02 AM, Steve Litt <slitt@???>
wrote:

> On Mon, 26 Jun 2017 21:30:39 -0700
> Bruce Perens <bruce@???> wrote:
>
>
> >
> > On Sun, Jun 25, 2017 at 1:09 PM, Hendrik Boom <hendrik@???>
> > wrote:
>
> > > The point is that that proposed libsystemd0 would *not* be an init
> > > system, and it would still enable software that was written to use
> > > systemd to run flawlessly.
> > >
> > > But I have to agree that writing such a thing is infeasible because
> > > the so-called systemd cabal can change the specs faster than anyone
> > > can do the reverse engineering. And it will take reverse
> > > engineering, because the specs aren't sufficient.
> > >
> > > I use the term "strategic incompetence" for the organisations that
> > > produce such system(d)s.
>
> > I really dare any "cabal" to change both the specs and the *clients
> > *in a way I can't keep up with. There are enough clients.
> >
> > No real programmer would worry about something like this.
> >
> > This is getting silly.
>
> So true, but I'm a fake programmer, having spent almost two decades
> making my living writing office automation code in C, Perl, Turbo
> Pascal, Clarion, Rbase, and probably 10 other languages. As a fake
> programmer I just can't keep up with the moving target obfuscation of
> the "cabal", who, did I mention, consists of several people paid good
> salaries just to keep the obfuscation moving.
>
> I know if I were a real programmer I'd be able to keep up with 10
> people who have been dealing with their code base for 6 years and are
> paid just to move their obfuscation, and still have plenty of time for
> my life and my day job. But alas, I'm just a fake programmer.
>
> SteveT
>
> Steve Litt
> June 2017 featured book: The Key to Everyday Excellence
> http://www.troubleshooters.com/key
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>