Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Arnt Karlsen]

On Tue, 27 Jun 2017 13:26:46 -0700, Bruce wrote in message 

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Bruce Perens]

I don't have a list. If you'd like to help with software patents, that
would be nice, as none of the organizations that purportedly support Linux
do. Linux Foundation is an infringer's club. Open Invention Network
protects patents from Linux, not the other way around.

On Tue, Jun 27, 2017 at 12:53 PM, Arnt Karlsen  wrote:

> On Tue, 27 Jun 2017 10:57:33 -0700, Bruce wrote in message
> :
>
> > Steve,
> >
> > Well, I've fought bigger dragons than this and won.
>
> ..ok, link to your list of Microsoft's alleged 235 patents
> they said we infringed upon in Utah 'n Delaware? ;o)
>
> --
> ..med vennlig hilsen = with Kind Regards from Arnt Karlsen
> ...with a number of polar bear hunters in his ancestry...
>   Scenarios always come in sets of three:
>   best case, worst case, and just in case.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Arnt Karlsen]

On Tue, 27 Jun 2017 10:57:33 -0700, Bruce wrote in message 
:

> Steve,
> 
> Well, I've fought bigger dragons than this and won. 

..ok, link to your list of Microsoft's alleged 235 patents 
they said we infringed upon in Utah 'n Delaware? ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Bruce Perens]

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 
wrote:

> On Mon, 26 Jun 2017 21:30:39 -0700
> Bruce Perens  wrote:
>
>
> >
> > On Sun, Jun 25, 2017 at 1:09 PM, Hendrik Boom 
> > 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@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Joachim Fahrner]

Am 2017-06-27 16:02, schrieb Steve Litt:


I know if I were a real programmer...


real programmers can write Fortran programs in ANY language ;-)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Steve Litt]

On Mon, 26 Jun 2017 21:30:39 -0700
Bruce Perens  wrote:


> 
> On Sun, Jun 25, 2017 at 1:09 PM, Hendrik Boom 
> 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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reverse-engineering systemd is fighting strategic incompetence.

[Bruce Perens]

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.

On Sun, Jun 25, 2017 at 1:09 PM, Hendrik Boom 
wrote:

> On Mon, Jun 19, 2017 at 12:15:17PM +0100, KatolaZ wrote:
> > On Sun, Jun 18, 2017 at 12:08:47PM +0200, info at smallinnovations dot
> nl wrote:
> ...
> ...
> > > Expanding to that we can even make a libsystemd0 that actually
> works with
> > > any init system (except systemd) for all relevant init parts and to all
> > > other calls answering that systemd is not present.
> > >
> > >
> >
> > I fail to see the importance of such task, since I really don't
> > understand what are these things that all init systems have in common,
> > except for riping orphaned processes. But again, if you feel like
> > having a library for all init systems to share is something worth
> > doing, please do it.
>
> 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.
>
>
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] reverse-engineering systemd is fighting strategic incompetence.

[Hendrik Boom]

On Mon, Jun 19, 2017 at 12:15:17PM +0100, KatolaZ wrote:
> On Sun, Jun 18, 2017 at 12:08:47PM +0200, info at smallinnovations dot nl 
> wrote:
...
...
> > Expanding to that we can even make a libsystemd0 that actually 
works with
> > any init system (except systemd) for all relevant init parts and to all
> > other calls answering that systemd is not present.
> > 
> > 
> 
> I fail to see the importance of such task, since I really don't
> understand what are these things that all init systems have in common,
> except for riping orphaned processes. But again, if you feel like
> having a library for all init systems to share is something worth
> doing, please do it.

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.


-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng