On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands wrote:
> The program that ran most of OpenMoko was written on the assumption that
> it would be very soon replaced by separate components that would all
> pass messages around via d-bus
ah! 12+ years i'm glad someone remembers. i got the trolltech
Luke Kenneth Casson Leighton writes:
> On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
...
> the heavy usage of d-bus for the openmoko OS basically was part of
> what killed the project. it would not surprise me at all to find that
> d-bus is similarly slowing systemd down when compared
On Tue, Jul 04, 2017 at 11:44:33AM +0100, Luke Kenneth Casson Leighton wrote:
> On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
> wrote:
>
> >> > Openrc is included in Debian.
>
> > It was one of the candidates considered when deciding what init system
> > to adopt, altought it had much l
On Tue, Jul 4, 2017 at 11:44 AM, Luke Kenneth Casson Leighton
wrote:
> anyway i'll dig the parabola microsd card out again, switch to
> parallel openrc and boot it up. it might be a bit much for the A20 to
> handle, but we'll soon see.
ok we're looking at a 21 second boot time to the lightdm
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
wrote:
>> > Openrc is included in Debian.
> It was one of the candidates considered when deciding what init system
> to adopt, altought it had much less support than systemd or upstart (and
> I suspect it's even less tested than sysvinit).
On 2017-07-04 at 10:04:03 +0100, Luke Kenneth Casson Leighton wrote:
> On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen wrote:
>
> > Openrc is included in Debian.
>
> that's new (and fantastic to hear) - it appears that openrc is
> interoperable with initscripts so in theeorryyy there shouldn't be
On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen wrote:
> Openrc is included in Debian.
that's new (and fantastic to hear) - it appears that openrc is
interoperable with initscripts so in theeorryyy there shouldn't be any
need to submit new configs (start/stop scripts for services).
l.
_
On Mon, Jul 03, 2017 at 06:32:00PM -0400, zap wrote:
>
> > Indeed, volunteer time is seriously limited, and there are things that
> > are just beyond what can be expected from them.
> >
> > E.g. if a mayor DE would start requiring systemd to work, Debian would
> > not be in the position to fork it
On Mon, Jul 3, 2017 at 6:12 PM, Tzafrir Cohen wrote:
> Hang on, is this for the images for the EOMA68?
no.
> I figure you don't have
> systemd there because the kernel is < 3.12. But no udev? Or is this for
> an unrelated system?
correct. my main laptop.
TBH I'd remove systemd from my copy of Mint, but I'd be afraid to break it.
No, not because of systemd itself -- because of me. Things tend to break
when I tinker with them, lol, especially when they're as complicated as a
modern OS is.
So I guess I'll live with it for now.
___
> Indeed, volunteer time is seriously limited, and there are things that
> are just beyond what can be expected from them.
>
> E.g. if a mayor DE would start requiring systemd to work, Debian would
> not be in the position to fork it, but that doesn't mean that
> non-systemd users will be forced t
On 2017-07-03 at 11:34:29 -0400, Jonathan Frederickson wrote:
> The distro maintainers have to manage their (often limited and unpaid)
> time wisely. In Debian's case, choosing systemd as the init system
> means that package maintainers only have to write much shorter systemd
> service files instea
On 07/03/2017 01:12 PM, Tzafrir Cohen wrote:
> I'm not going to join this pro/anti systemd discussion as it is
> pointless at this point, but,
For the most part I agree with you, but I must admit I trust someone
with as much experience like Luke far more than systemd. But you are
free to avoid th
On Mon, Jul 3, 2017 at 3:43 PM, Troy Benjegerdes wrote:
> Gee, it's as if you're talking about bitcoin-core
bitcoin-core is not a critical and essential dependency which has
been forced onto 98% of GNU/Linux users without their informed
consent.
l.
I'm not going to join this pro/anti systemd discussion as it is
pointless at this point, but,
On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote:
> for example, until i discovered that angband.pl actively maintains
> systemd-less debian packages for xorg, udev, pulseaud
On Mon, Jul 3, 2017 at 12:35 PM, Adam Van Ymeren wrote:
> It's unfortunate that systemd is seen as necessary to get these shorter
> service files for service declaration. Or that sysvinit requires you to
> write long complicated init scripts.
>
> Rather than replacing the init system, it would be
Jonathan Frederickson writes:
>> this one example underscores that "freedom" - having access to the
>> source - is no longer the only factor, meaning that we are heavily and
>> critically deependent on decisions made by distro maintainers.
>
> Again, this has always been the case! Unless you're
when i was looking at taking over maintenance of depinit one of the
first tasks was to add full automated compatibility for initscripts.
signiicant advantages of depinit were lost in the process but there
was no loss when compared to sysvinit itself. individual initscripts
could then be replaced
> this one example underscores that "freedom" - having access to the
> source - is no longer the only factor, meaning that we are heavily and
> critically deependent on decisions made by distro maintainers.
Again, this has always been the case! Unless you're packaging things
yourself, you're dep
On 07/03/2017 03:52 AM, Luke Kenneth Casson Leighton wrote:
> https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
>
> two years. that's how long one of these bugs has been in systemd.
> *via a remote network*. what the hell is an init sy
On Mon, Jul 3, 2017 at 3:38 PM, Jonathan Frederickson
wrote:
> People have always done this, it's just that the systemd folks are
> writing their own versions of lots of different services. And that's
> okay! You're free to use them, or not, as you choose.
... actually... we (the users) are in n
On Mon, Jul 03, 2017 at 12:05:59PM +0100, Luke Kenneth Casson Leighton wrote:
> On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos wrote:
>
>
> > Also I don't consider going from a variety of options each with it's
> > disadvantages to a single option essentially standardizing it a bad
> > thing. It's
On Mon, Jul 3, 2017 at 10:24 AM, Luke Kenneth Casson Leighton
wrote:
> there's a misconception that software that does its job actually
> needs "development". good stable software that does a job and does it
> well (the unix philosophy) often simply needs "maintenance" only -
> keeping up-to-dat
On Mon, Jul 3, 2017 at 3:00 PM, Jonathan Frederickson
wrote:
> It's true that the systemd developers have also written replacements
> for existing software that *have* been widely adopted, notably
> systemd-logind in favor of ConsoleKit. But ConsoleKit's original
> developer(s) have stopped maint
On Mon, Jul 3, 2017 at 4:40 AM, Luke Kenneth Casson Leighton
wrote:
> the situation before systemd was that we had quotes imperfect quotes
> disparate programs that were managed by completely different teams.
> the actual init system(s) that used those programs did not "develop"
> significantly b
On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos wrote:
> Also I don't consider going from a variety of options each with it's
> disadvantages to a single option essentially standardizing it a bad
> thing. It's just a lost opportunity to make a real standard for sure,
> but I don't think that's mono
On Mon, Jul 3, 2017 at 11:00 AM, Erik Auerswald
wrote:
> Systemd is supposed to replace the complete init system, not just the
> process with PID 1. In addition, it adds lots of other functionality (DNS
> resolver, DCHP client, network configuration, desktop session management,
> ...), all of whi
Hi,
On Mon, Jul 03, 2017 at 10:26:51AM +0200, Philip Hands wrote:
> Luke Kenneth Casson Leighton writes:
>
> > https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
> >
> > two years. that's how long one of these bugs has been in systemd.
On Mon, Jul 3, 2017 at 12:06 PM, Luke Kenneth Casson Leighton
wrote:
> even with that in mind i see no down-side to the additional workload
> that you refer to when you consider the upside that diversity brings.
> no monoculture, no centralised control, and a need for people managing
> *differen
On Mon, Jul 3, 2017 at 10:06 AM, Philip Hands wrote:
> Are you aware of confirmation bias?
you're talking to a reverse-engineer, so you know that i am.
the problem is that there are so many different "signs" from so many
different directions that it becomes completely overwhelming to
enumerate
Luke Kenneth Casson Leighton writes:
> On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands wrote:
>
>> Might I ask in response: What the hell are you doing not fact checking
>> this before repeating it?
>
> because in the scheme of programs-that-constitute-systemd it really
> doesn't matter, phil.
...
On Mon, Jul 3, 2017 at 9:47 AM, Bill Kontos wrote:
> much variance. And yet people keep breaking abis and support the idea
> of multiple inits that do the same thing in slightly different ways
> requiring the maintenance of multiple init scripts over and over
> again.
when i was looking at taki
On Mon, Jul 3, 2017 at 10:52 AM, Luke Kenneth Casson Leighton
wrote:
> for anyone who still believes that systemd is okay to use and deploy,
> and that there exist "great advantages that outweigh the risks", are
> you *finally* getting the message now?
Because the only distro that uses systemd-
On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands wrote:
> Might I ask in response: What the hell are you doing not fact checking
> this before repeating it?
because in the scheme of programs-that-constitute-systemd it really
doesn't matter, phil. the slashdot report also includes a link to
this se
Luke Kenneth Casson Leighton writes:
> https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
>
> two years. that's how long one of these bugs has been in systemd.
> *via a remote network*. what the hell is an init system doing being
> acce
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
two years. that's how long one of these bugs has been in systemd.
*via a remote network*. what the hell is an init system doing being
accessible *via DNS queries*?
for anyone who still
36 matches
Mail list logo
