Vision for new platform

Vision for new platform

[Rich Felker]

Hi everyone,

A mid- to long-term goal I've had on top of musl is putting together
the basis for an efficient user-oriented embedded/mobile platform, for
things like netbooks, phones, tablets, etc. Struggling with a Debian
upgrade and massive breakage of NetworkManager and bluetooth support
in non-desktop-environment setting over the past few days has had me
thinking a lot more about how utterly broken the current direction
freedesktop.org and related projects are taking the "Linux platform"
is, and also the lack of viable alternatives.

So, I'd like to get started in our community a discussion towards
designing and implementing something new. The scope I'm looking at is
the components needed to make a portable/mobile system usable both to
non-technical users and sophisticated users who just don't want to
waste their time (and perhaps fight with a tiny touchscreen keyboard)
typing 5-10 commands to connect to a network or launch applications
every time they need to do something, things like:

- network connector
- media mounter
- pluggable devices such as: video capture/webcam, audio, printers,
  scanners, obex/bluetooth file transfer, etc.
- file/device/application browsing/management

Many of these areas would involve two separate layers: low-level
daemons and scripts for handling hardware events and acting on them,
and front-end scripts and guis for accepting user control.

Two huge sources of complexity and errors in the prevailing
dbus/policykit/consolekit way of handling these things under the
freedesktop.org regime are:

1. Attempting to account for multiple "local users", possibly even
   simultaneously, with complex policies controlling their access to
   hardware and configuration.
2. Splitting the handling of hardware events between system-level
   processes and user-desktop-environment processes, and requiring
   complex, poorly documented interactions between them to get
   anything done.

Both of these theoretically make the system a lot more flexible and
configurable, but in practice, unless all the software you want to use
supports all this flexibility, you're usually stuck with no
configurability at all (for example, the inability to change mount
options on removable devices). Certainly goal #2 should be thrown out;
it should always be sufficient for the system-level processes to do
the configuration and possible assignment of user access rights on
hardware events, and for the user processes to receive at most a
notification. Goal #1 is more questionable; presumably the intent is
to secure a system with multiple user accounts from one user fooling
around with the hardware while another is active at the console (e.g.
spying with the microphone or changing the network connection to
intercept traffic), but while noble, I think this goal is just
impossible to satisfy. Certainly any user who has EVER had access to a
device can just keep an open file descriptor to it in a detached
process and get it back later, unless the device has a way to forcibly
destroy all open handles (like vhangup on terminals). I suspect it
makes a lot more sense to mostly or fully drop goal #1 and simply
document the situation - especially since the types of systems that
will be dealing with a user touching the hardware are not the same
kind of multi-user systems as a traditional headless unix box. In any
case, I think we can do a better job of making something that's robust
and secure than the current desktop folks have done.

What I'd really like to end up with is something that's not just a new
distro (in fact it could be used on or by several of the distros this
community is already working on as well as further new ones or perhaps
existing ones), but a new "platform" of sorts, with the idea that it
would be fully capable of running and interoperating with existing gui
*applications* written for X/GNOME/KDE/whatever, but not necessarily
compatible with any of the system-level junk these environments use.

And of course, my vision also involves the utmost level of robustness
and stability: freedom from broken corner cases, race conditions, etc.
This is an area where traditional simple scripts (boot scripts,
network scripts, etc.) horribly failed, using ugly things like pid
files, killall commands, broken behavior when a device was quickly
inserted then removed, etc. -- and failures like are largely
responsible for letting junk like dbus, systemd, etc. take over.

Speaking of which, if we embark on a project like this, I think we
should have a fairly strict set of standards for what tools and
dependencies are disallowed. In particular, I'd want to see:

- no xml config files
- no dbus
- no python or perl
- no invasion of the login/auth system (i.e. no requirement to use
  special pam modules to get a working login session).
- no desktop environment dependencies
- no java-style namespaces (the ones that look like backwards dns)
- no hidden config/state (i.e. nothing hidden in the config
  directories of other software like dbus, or in config registries, or
  anything like that)
- no complex inter-component dependencies that can break the whole
  system when one component is changed or upgraded without making
  corresponding changes in others

What I would like to see:

- as much as possible, especially among things local admins or systems
  integrators might want to modify, in 100% portable posix shell
  script
- minimal amount of system daemon level code written in c
- stuff that doesn't treat the user as an idiot but rather as somebody
  who doesn't want to waste their time typing repetitive commands.

I still see this all, at least the completion of it, as a mid- to
long-range project, but I think it's something we could and should
start discussing, and I hope some of you who are already into
distro-building will be interested in experimenting with new
approaches to the ugly guts of making a working user-facing system.
Maybe we can start with the daemon/script side of things and some CLI
tools to work with them and just experiment and see how it evolves,
and then solidify the design and polish the implementations once we
have some results.

Rich

Re: Vision for new platform

[Isaac Dunham]

Rich Felker <dalias@aerifal.cx> wrote:
> A mid- to long-term goal I've had on top of musl is putting together
> the basis for an efficient user-oriented embedded/mobile platform, for
> things like netbooks, phones, tablets, etc. Struggling with a Debian
> upgrade and massive breakage of NetworkManager and bluetooth support
> in non-desktop-environment setting over the past few days has had me
> thinking a lot more about how utterly broken the current direction
> freedesktop.org and related projects are taking the "Linux platform"
> is, and also the lack of viable alternatives.
Utterly broken?
I'd call that an understatement - to be broken, it has to correspond to
something functional. :)
> So, I'd like to get started in our community a discussion towards
> designing and implementing something new. The scope I'm looking at is
> the components needed to make a portable/mobile system usable both to
Oh no, not *another*! :P
> non-technical users and sophisticated users who just don't want to
> waste their time (and perhaps fight with a tiny touchscreen keyboard)
> typing 5-10 commands to connect to a network or launch applications
> every time they need to do something, things like:
> - network connector
> - media mounter
> - pluggable devices such as: video capture/webcam, audio, printers,
>   scanners, obex/bluetooth file transfer, etc.
> - file/device/application browsing/management

Somehow this reminds me of Puppy Linux....
 
> Many of these areas would involve two separate layers: low-level
> daemons and scripts for handling hardware events and acting on them,
> and front-end scripts and guis for accepting user control.
> Two huge sources of complexity and errors in the prevailing
> dbus/policykit/consolekit way of handling: 
> 1. Attempting to account for multiple "local users", possibly even
>    simultaneously, with complex policies controlling their access to
>    hardware and configuration.
> 2. Splitting the handling of hardware events between system-level
>    processes and user-desktop-environment processes, and requiring
>    complex, poorly documented interactions between them to get
>    anything done.
> Certainly goal #2 should be thrown out;
> it should always be sufficient for the system-level processes to do
> the configuration and possible assignment of user access rights on
> hardware events, and for the user processes to receive at most a
> notification. 
Not sure I exactly follow this statement. Is usbmount + some userspace
scenario based on inotify similar to what you have in mind?
Or Ymount [http://murga-linux.com/puppy/viewtopic.php?t=69283]?
Or neither?

>Goal #1 is more questionable; presumably the intent is
> to secure a system with multiple user accounts from one user fooling
> around with the hardware while another is active at the console, but
> while noble, I think this goal is just impossible to satisfy... In any
> case, I think we can do a better job of making something that's
> robust and secure than the current desktop folks have done.

> What I'd really like to end up with is something that's not just a new
> distro (in fact it could be used on or by several of the distros this
> community is already working on as well as further new ones or perhaps
> existing ones), but a new "platform" of sorts, with the idea that it
> would be fully capable of running and interoperating with existing gui
> *applications* written for X/GNOME/KDE/whatever, but not necessarily
> compatible with any of the system-level junk these environments use.

Again, reminds me of Puppy Linux--assuming I halfway understand
what you're talking about ;).

> And of course, my vision also involves the utmost level of robustness
> and stability: freedom from broken corner cases, race conditions, etc.
> (This is an area where traditional simple scripts horribly failed,
> using ugly things like pid files, killall commands...)
Somehow, I doubt that'll happen just because you want it to.
I doubt that anyone else had the intent of making something *un*stable,
and software *always* has bugs (unless you call them all features).
Not that it's a bad goal, just that it may not happen.

> We should have a fairly strict set of standards for what tools and
> dependencies are disallowed. In particular, I'd want to see: 
> - no xml config files
> - no dbus
> - no python or perl
> - no invasion of the login/auth system (i.e. no requirement to use
>   special pam modules to get a working login session).
> - no desktop environment dependencies
> - no java-style namespaces (the ones that look like backwards dns)
That's actually what Java used (hence the com.sun namespace).
> - no hidden config/state (i.e. nothing hidden in the config
>   directories of other software like dbus, or in config registries, or
>   anything like that)
> - no complex inter-component dependencies that can break the whole
>   system when one component is changed or upgraded without making
>   corresponding changes in others
All of which sounds like a fit list for banning. Now maybe I should get
around to finishing sprinkler-precip.py :P
(I use python, but think it's only suitable for light use--things where
you start the program once in a while, do something, then close it)
> What I would like to see:
> - as much as possible, especially among things local admins or systems
>   integrators might want to modify, in 100% portable posix shell
>   script
> - minimal amount of system daemon level code written in c
> - stuff that doesn't treat the user as an idiot but rather as somebody
>   who doesn't want to waste their time typing repetitive commands.

Did I mention that this reminds me of Puppy Linux?
BTW, I got a few of the Puppy developers interested in musl, and one of
the moderators said (regarding musl) "You guys feel free to invite the
developers to join our forum. Explain to them how useful Puppy could be
to a developer. :)"
I had discounted that proposal...

Isaac Dunham

Re: Vision for new platform

[Rich Felker]

On Thu, May 17, 2012 at 08:11:43PM -0700, Isaac Dunham wrote:
> Rich Felker <dalias@aerifal.cx> wrote:
> > A mid- to long-term goal I've had on top of musl is putting together
> > the basis for an efficient user-oriented embedded/mobile platform, for
> > things like netbooks, phones, tablets, etc. Struggling with a Debian
> > upgrade and massive breakage of NetworkManager and bluetooth support
> > in non-desktop-environment setting over the past few days has had me
> > thinking a lot more about how utterly broken the current direction
> > freedesktop.org and related projects are taking the "Linux platform"
> > is, and also the lack of viable alternatives.
> Utterly broken?
> I'd call that an understatement - to be broken, it has to correspond to
> something functional. :)

The functional thing it corresponds to, sadly, is probably Windows...

> > non-technical users and sophisticated users who just don't want to
> > waste their time (and perhaps fight with a tiny touchscreen keyboard)
> > typing 5-10 commands to connect to a network or launch applications
> > every time they need to do something, things like:
> > - network connector
> > - media mounter
> > - pluggable devices such as: video capture/webcam, audio, printers,
> >   scanners, obex/bluetooth file transfer, etc.
> > - file/device/application browsing/management
> 
> Somehow this reminds me of Puppy Linux....

Well Puppy Linux is a distribution, seemingly one that's aimed at
running off removable, possibly read-only media. What I'm talking
about is not a distribution but a group of components of a system -
basically, the properly-factored version of the actually-useful
functionality of a "desktop environment". Things like getting
connected to a network and accessing removable media without opening a
terminal with a root shell.

> > 2. Splitting the handling of hardware events between system-level
> >    processes and user-desktop-environment processes, and requiring
> >    complex, poorly documented interactions between them to get
> >    anything done.
> > Certainly goal #2 should be thrown out;
> > it should always be sufficient for the system-level processes to do
> > the configuration and possible assignment of user access rights on
> > hardware events, and for the user processes to receive at most a
> > notification. 
> Not sure I exactly follow this statement. Is usbmount + some userspace
> scenario based on inotify similar to what you have in mind?
> Or Ymount [http://murga-linux.com/puppy/viewtopic.php?t=69283]?
> Or neither?

No, looks like completely the opposite direction. In my vision, there
would be no involvement of user processes in mounting removable media.
The mount would be performed by system processes, based on system-wide
configuration with sane defaults that most people wouldn't need to
override (but could change if needed), and user processes could
discover it by inotify on /media (or whatever) or with dbus
(completely optional but perhaps desirable if you want to use apps
that do things that way).

> > And of course, my vision also involves the utmost level of robustness
> > and stability: freedom from broken corner cases, race conditions, etc.
> > (This is an area where traditional simple scripts horribly failed,
> > using ugly things like pid files, killall commands...)
> Somehow, I doubt that'll happen just because you want it to.

Well if we design and implement it rather than just wishing for it, it
can happen.

> I doubt that anyone else had the intent of making something *un*stable,

No, but it happens from copying (and cargo-culting) bad examples.

> and software *always* has bugs (unless you call them all features).
> Not that it's a bad goal, just that it may not happen.

The vast majority of problems like this do not come from bugs like
typos in the source, signedness mismatches, off-by-one logic errors,
etc. They come from fundamentally wrong assumptions about the behavior
of interfaces used, ignoring the possibility of failure, not
considering concurrency, etc. I.e. they are major design bugs and
systemic implementation errors, not "innocent" bugs.

> > - no java-style namespaces (the ones that look like backwards dns)
> That's actually what Java used (hence the com.sun namespace).

That's why I called it java-style. Seeing it in software almost surely
means the software was designed by people who learned on Java, meaning
they're almost surely unqualified to write working code, much less
efficient code...

> All of which sounds like a fit list for banning. Now maybe I should get
> around to finishing sprinkler-precip.py :P
> (I use python, but think it's only suitable for light use--things where
> you start the program once in a while, do something, then close it)

I have no problem with using Python to implement local scripts or even
standalone applications. What I have a problem with is using it to
implement core system components that everything else depends on.

> > What I would like to see:
> > - as much as possible, especially among things local admins or systems
> >   integrators might want to modify, in 100% portable posix shell
> >   script
> > - minimal amount of system daemon level code written in c
> > - stuff that doesn't treat the user as an idiot but rather as somebody
> >   who doesn't want to waste their time typing repetitive commands.
> 
> Did I mention that this reminds me of Puppy Linux?

Can you elaborate on that? If Puppy Linux has custom scripts/software
in this direction, they might very well be useful as a model or even
basis for some of what I want to do. But I don't see the connection as
of yet..

Rich

Re: Vision for new platform

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-05-17 21:06:20 -0400]:
> A mid- to long-term goal I've had on top of musl is putting together
> the basis for an efficient user-oriented embedded/mobile platform, for
> things like netbooks, phones, tablets, etc. Struggling with a Debian
> upgrade and massive breakage of NetworkManager and bluetooth support
> in non-desktop-environment setting over the past few days has had me
> thinking a lot more about how utterly broken the current direction
> freedesktop.org and related projects are taking the "Linux platform"
> is, and also the lack of viable alternatives.

yes

> - network connector
> - media mounter
> - pluggable devices such as: video capture/webcam, audio, printers,
>   scanners, obex/bluetooth file transfer, etc.
> - file/device/application browsing/management

nice
some of these would require lot of work
(i'm thinking about current audio or printing infrastructure..
where every device has different capabilities and thus requires
separate configuration)

> would be fully capable of running and interoperating with existing gui
> *applications* written for X/GNOME/KDE/whatever, but not necessarily
> compatible with any of the system-level junk these environments use.

i wonder if that's possible considering all the tight
interdependency between the system-level junk and
desktop applications

Re: Vision for new platform

[Isaac Dunham]

On Thu, 17 May 2012 23:26:11 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Thu, May 17, 2012 at 08:11:43PM -0700, Isaac Dunham wrote:
> > Rich Felker <dalias@aerifal.cx> wrote:
> > > non-technical users and sophisticated users who just don't want to
> > > waste their time (and perhaps fight with a tiny touchscreen
> > > keyboard) typing 5-10 commands to connect to a network or launch
> > > applications every time they need to do something, things like:
> > > - network connector
> > > - media mounter
> > > - pluggable devices such as: video capture/webcam, audio,
> > > printers, scanners, obex/bluetooth file transfer, etc.
> > > - file/device/application browsing/management
> > 
> > Somehow this reminds me of Puppy Linux....
> 
> Well Puppy Linux is a distribution, seemingly one that's aimed at
> running off removable, possibly read-only media. What I'm talking
> about is not a distribution but a group of components of a system -
> basically, the properly-factored version of the actually-useful
> functionality of a "desktop environment". Things like getting
> connected to a network and accessing removable media without opening a
> terminal with a root shell.

Puppy Linux is more of a project than a ditribution--there have to be
at least 100 different "puplets" (what they call derivative
distributions or unofficial projects related to Puppy).  Many of them
use the Woof build system (some sort of internal project), but not
all.  In fact, it seems that the only prerequisites for calling
something a puplet are:

1. Make it as light (CPU, disk, and RAM) as you can
2. Make it easy to use
3. Offer a bootable version
4. Mention it on the Puppy Linux forums

It is often run from removable media or loaded into RAM, but not
always. More relevantly, they seem to have this philosophy that "Doing
stuff from the console is always fine, but having to do it from the
console means something's wrong".  They have quite a few customs
scripts, which seem to work pretty reliably in my experience.

> No, looks like completely the opposite direction. In my vision, there
> would be no involvement of user processes in mounting removable media.
> The mount would be performed by system processes, based on system-wide
> configuration with sane defaults that most people wouldn't need to
> override (but could change if needed), and user processes could
> discover it by inotify on /media (or whatever) or with dbus
> (completely optional but perhaps desirable if you want to use apps
> that do things that way). 
Sounding more and more like usbmount + inotify, although usbmount
doesn't seem to have the sane defaults down and requires editing a
(plaintext) config file to fix them. usbmount is also dbus unaware.

> > > What I would like to see:
> > > - as much as possible, especially among things local admins or
> > > systems integrators might want to modify, in 100% portable posix
> > > shell script
> > > - minimal amount of system daemon level code written in c
> > > - stuff that doesn't treat the user as an idiot but rather as
> > > somebody who doesn't want to waste their time typing repetitive
> > > commands.
> > 
> > Did I mention that this reminds me of Puppy Linux?
> 
> Can you elaborate on that? If Puppy Linux has custom scripts/software
> in this direction, they might very well be useful as a model or even
> basis for some of what I want to do. But I don't see the connection as
> of yet..
Puppy Linux is built on numerous custom scripts, doesn't ship with Perl
or Python by default (they're included in devx.sfs, the development
addon), I know that some versions don't have dbus. The scripts are
fairly easy to use, without assuming that you're clueless (although
there is documentation).
Daemons are kept to a minimum, but there are enough to get the job done.
You can use Gnome/KDE/... stuff, if you want--but it doesn't have all
the services provided by Gnome or KDE.

Re: Vision for new platform

[aep]

Rich,

I started a similar approach in 2011, called HereticLinux, and 
antidesktop.org. An attempt to write linux userspace and ui from 
scratch, after being pissed from all the FDO junk for too many years.
Then i learned during my current work that more then half of the linux 
ecosystem is driven by less then a dozen megacorps, and that any vision 
different then theirs is just not relevant.
Not to mention that most of the code is the way it is because a large 
workforce like that can just not create anything clean by definition.
The other side of the story are scattered communities like 
suckless.org, tending to isolate themselves in their religious island.
In between, there's a whole lot of nothing. Random bits of code on 
random git repos by random people not cooperating due
to the lack of any common ground other then "well the shit sucked, so i 
just removed networkmanager and wrote what i need in 20 lines <favorite 
language>"
If you put them in one room, then they start fighting over which 
language is the best, and what color the bikeshed should have. Boring.

FDO is the way it is, it's a pile of shit, but it's the only 
organization that managed to combine a zillion lines of code to some 
sort of consistent thing.
Even if the thing is utter crap and only targets a specific audience 
(not me), it's as consistent as you can get.
So instead of trying to rebuild every single piece they fucked up (my 
original over-the-line experience was when archlinux put dbus to the 
default base install for basic system services), i nowadays go with the 
crowd of "random code on random git repos". I wrote the 100-billionth 
network thing, the 400-zillionth initsystem, etc, etc. Nothing you could 
ever reuse due to the lack of an actually consistent design. Just like 
99% of the junk on github.

At a different project, we started to approach the problem the other 
way round and are building isolation chambers for each piece of software 
(e.g. bluez) so it's shitty design doesn't affect the system too much.
The bridges between the components are well engineered from senior 
system designers, rather then from some teenager who thinks xmlrpc is 
the next cool thing to put in a cpu scheduler.
However, this is a commercial activity, and i don't see any FOSS 
project for that to appear out of the blue any time soon. If it would, 
it'd certainly help. But working on the 101-billionth network manager 
just isn't very interesting.
I will always prefer my 500 line hack over someone elses 500 line hack. 
Creating new, modern building blocks that reduce my 500 lines to 10, 
because someone did all the hard work for me, now that would be really 
cool.

On the note of your (technically correct) set of standards: Instead of 
enforcing a specific view which eventually turns into a defunct religion 
because the views are outdated, i prefer making generic mission 
statements and handpick smart people.

So long.

Arvid


On Thu, 17 May 2012 21:06:20 -0400, Rich Felker wrote:
> Hi everyone,
>
> A mid- to long-term goal I've had on top of musl is putting together
> the basis for an efficient user-oriented embedded/mobile platform, 
> for
> things like netbooks, phones, tablets, etc. Struggling with a Debian
> upgrade and massive breakage of NetworkManager and bluetooth support
> in non-desktop-environment setting over the past few days has had me
> thinking a lot more about how utterly broken the current direction
> freedesktop.org and related projects are taking the "Linux platform"
> is, and also the lack of viable alternatives.
>
> So, I'd like to get started in our community a discussion towards
> designing and implementing something new. The scope I'm looking at is
> the components needed to make a portable/mobile system usable both to
> non-technical users and sophisticated users who just don't want to
> waste their time (and perhaps fight with a tiny touchscreen keyboard)
> typing 5-10 commands to connect to a network or launch applications
> every time they need to do something, things like:
>
> - network connector
> - media mounter
> - pluggable devices such as: video capture/webcam, audio, printers,
>   scanners, obex/bluetooth file transfer, etc.
> - file/device/application browsing/management
>
> Many of these areas would involve two separate layers: low-level
> daemons and scripts for handling hardware events and acting on them,
> and front-end scripts and guis for accepting user control.
>
> Two huge sources of complexity and errors in the prevailing
> dbus/policykit/consolekit way of handling these things under the
> freedesktop.org regime are:
>
> 1. Attempting to account for multiple "local users", possibly even
>    simultaneously, with complex policies controlling their access to
>    hardware and configuration.
> 2. Splitting the handling of hardware events between system-level
>    processes and user-desktop-environment processes, and requiring
>    complex, poorly documented interactions between them to get
>    anything done.
>
> Both of these theoretically make the system a lot more flexible and
> configurable, but in practice, unless all the software you want to 
> use
> supports all this flexibility, you're usually stuck with no
> configurability at all (for example, the inability to change mount
> options on removable devices). Certainly goal #2 should be thrown 
> out;
> it should always be sufficient for the system-level processes to do
> the configuration and possible assignment of user access rights on
> hardware events, and for the user processes to receive at most a
> notification. Goal #1 is more questionable; presumably the intent is
> to secure a system with multiple user accounts from one user fooling
> around with the hardware while another is active at the console (e.g.
> spying with the microphone or changing the network connection to
> intercept traffic), but while noble, I think this goal is just
> impossible to satisfy. Certainly any user who has EVER had access to 
> a
> device can just keep an open file descriptor to it in a detached
> process and get it back later, unless the device has a way to 
> forcibly
> destroy all open handles (like vhangup on terminals). I suspect it
> makes a lot more sense to mostly or fully drop goal #1 and simply
> document the situation - especially since the types of systems that
> will be dealing with a user touching the hardware are not the same
> kind of multi-user systems as a traditional headless unix box. In any
> case, I think we can do a better job of making something that's 
> robust
> and secure than the current desktop folks have done.
>
> What I'd really like to end up with is something that's not just a 
> new
> distro (in fact it could be used on or by several of the distros this
> community is already working on as well as further new ones or 
> perhaps
> existing ones), but a new "platform" of sorts, with the idea that it
> would be fully capable of running and interoperating with existing 
> gui
> *applications* written for X/GNOME/KDE/whatever, but not necessarily
> compatible with any of the system-level junk these environments use.
>
> And of course, my vision also involves the utmost level of robustness
> and stability: freedom from broken corner cases, race conditions, 
> etc.
> This is an area where traditional simple scripts (boot scripts,
> network scripts, etc.) horribly failed, using ugly things like pid
> files, killall commands, broken behavior when a device was quickly
> inserted then removed, etc. -- and failures like are largely
> responsible for letting junk like dbus, systemd, etc. take over.
>
> Speaking of which, if we embark on a project like this, I think we
> should have a fairly strict set of standards for what tools and
> dependencies are disallowed. In particular, I'd want to see:
>
> - no xml config files
> - no dbus
> - no python or perl
> - no invasion of the login/auth system (i.e. no requirement to use
>   special pam modules to get a working login session).
> - no desktop environment dependencies
> - no java-style namespaces (the ones that look like backwards dns)
> - no hidden config/state (i.e. nothing hidden in the config
>   directories of other software like dbus, or in config registries, 
> or
>   anything like that)
> - no complex inter-component dependencies that can break the whole
>   system when one component is changed or upgraded without making
>   corresponding changes in others
>
> What I would like to see:
>
> - as much as possible, especially among things local admins or 
> systems
>   integrators might want to modify, in 100% portable posix shell
>   script
> - minimal amount of system daemon level code written in c
> - stuff that doesn't treat the user as an idiot but rather as 
> somebody
>   who doesn't want to waste their time typing repetitive commands.
>
> I still see this all, at least the completion of it, as a mid- to
> long-range project, but I think it's something we could and should
> start discussing, and I hope some of you who are already into
> distro-building will be interested in experimenting with new
> approaches to the ugly guts of making a working user-facing system.
> Maybe we can start with the daemon/script side of things and some CLI
> tools to work with them and just experiment and see how it evolves,
> and then solidify the design and polish the implementations once we
> have some results.
>
> Rich

Re: Vision for new platform

[Rich Felker]

On Mon, May 21, 2012 at 10:05:52PM +0200, aep wrote:
> Rich,
> 
> I started a similar approach in 2011, called HereticLinux, and
> antidesktop.org. An attempt to write linux userspace and ui from
> scratch, after being pissed from all the FDO junk for too many
> years.
> Then i learned during my current work that more then half of the
> linux ecosystem is driven by less then a dozen megacorps, and that

Yes, I'm quite aware. For the core "ecosystem", I'd say it's closer to
75% than just half.

> any vision different then theirs is just not relevant.

Well it's not relevant by itself. You have to work to make it
relevant. And that's hard work. I think having a phone running a
kick-ass system that's always smooth and responsive even on low-end
hardware would be pretty relevant to a lot of people. Becoming
relevant gives you influence. The influence to call others out when
they do stupid things, and the influence to get others to adopt, build
upon, and contribute back to your systems.

> In between, there's a whole lot of nothing. Random bits of code on
> random git repos by random people not cooperating due
> to the lack of any common ground other then "well the shit sucked,
> so i just removed networkmanager and wrote what i need in 20 lines
> <favorite language>"

I'm not looking to make yet another script that auto-joins a wireless
network based on your written-by-hand list of known networks. The goal
would be something that requires the minimal possible degree of
interaction, and does so without "dbus hell".

> FDO is the way it is, it's a pile of shit, but it's the only
> organization that managed to combine a zillion lines of code to some
> sort of consistent thing.

The zillion lines of code sounds like the heart of the problem. I bet
at most 1% of them do anything useful, and the rest is layer upon
layer of wrappers.

> Even if the thing is utter crap and only targets a specific audience
> (not me), it's as consistent as you can get.
> So instead of trying to rebuild every single piece they fucked up
> (my original over-the-line experience was when archlinux put dbus to
> the default base install for basic system services), i nowadays go
> with the crowd of "random code on random git repos". I wrote the
> 100-billionth network thing, the 400-zillionth initsystem, etc, etc.
> Nothing you could ever reuse due to the lack of an actually
> consistent design. Just like 99% of the junk on github.

As bad as it sounds, this is at least a step forward. Instead of
putting thousands of person-years into producing a piece of trash, you
only put 30 minutes into it. And then you don't feel any attachment to
it that would keep you from throwing it out when you realize how much
it sucks.

> At a different project, we started to approach the problem the other
> way round and are building isolation chambers for each piece of
> software (e.g. bluez) so it's shitty design doesn't affect the
> system too much.

This is definitely a step forward as well, but I wonder if it wouldn't
make more sense to just strip out all but the useful parts, or replace
it entirely.

> The bridges between the components are well engineered from senior
> system designers, rather then from some teenager who thinks xmlrpc
> is the next cool thing to put in a cpu scheduler.

Also definitely a step forward.

> However, this is a commercial activity, and i don't see any FOSS
> project for that to appear out of the blue any time soon. If it
> would, it'd certainly help. But working on the 101-billionth network
> manager just isn't very interesting.

Agreed. I would say, aside from a few particularly cool things that
were algorithmically novel, working on the Nth whatever in libc was
not that interesting either. What is interesting, however, is having
the complete thing together that works and doesn't suck. My feeling
about stuff like network managers is about the same. In itself it's
not interesting, but if 2 years from now we have the kick-ass mobile
device platform, THAT's interesting.

> I will always prefer my 500 line hack over someone elses 500 line
> hack. Creating new, modern building blocks that reduce my 500 lines
> to 10, because someone did all the hard work for me, now that would
> be really cool.

:) :) :)

> On the note of your (technically correct) set of standards: Instead
> of enforcing a specific view which eventually turns into a defunct
> religion because the views are outdated, i prefer making generic
> mission statements and handpick smart people.

I tend to agree with this sentiment too. They were more meant as
starting guidelines than religion.

Rich

Re: Vision for new platform

[nwmcsween]

I am also working on something similar but less ambitious - I want to 
reuse what's out there but based on code quality. I plan on using llvm, 
musl, compiler-rt, libc++, mclinker, toybox and a few required gnu 
projects. My main idea is to use mruby and rspec for integration 
testing (to mitigate breakage and ensure deployability) and for package 
building / testing where building is for many package manager formats 
(such as output for rpm, deb, etc) and where testing covers mainly code 
quality based on analysis. There's also a whole whack of other ideas I 
have such as using LSH for hashing source (to find similar bad sections 
of code as well as categorizing packages), using git, svn, etc to keep 
with upstream, allow hackability and maybe even bisection across an 
entire dependency graph.

Re: Vision for new platform

[Rich Felker]

On Mon, May 21, 2012 at 01:51:19PM -0700, nwmcsween wrote:
> I am also working on something similar but less ambitious - I want
> to reuse what's out there but based on code quality. I plan on using
> llvm, musl, compiler-rt, libc++, mclinker, toybox and a few required

I hope I didn't make it sound like nothing could be reused. The vision
I was describing doesn't involve replacing these components of the
system (although I *would* like to write a compiler, if I had the
background), just the FDO junk.

> covers mainly code quality based on analysis. There's also a whole
> whack of other ideas I have such as using LSH for hashing source (to
> find similar bad sections of code as well as categorizing packages),
> using git, svn, etc to keep with upstream, allow hackability and
> maybe even bisection across an entire dependency graph.

Nice!

Rich

Re: Vision for new platform

[Rich Felker]

On Mon, May 21, 2012 at 10:05:52PM +0200, aep wrote:
> FDO is the way it is, it's a pile of shit, but it's the only
> organization that managed to combine a zillion lines of code to some
> sort of consistent thing.
> Even if the thing is utter crap and only targets a specific audience
> (not me), it's as consistent as you can get.

I meant to address this... actually, a failure in this area is what
motivated me to consider the topic of replacing it again. I guess I
could be misinterpreting what you mean by "consistent", but the FDO
junk is anything but stable and interoperable. Just last week I had to
fight with a Debian upgrade in my spare time for 3 days (getting
almost nothing actually useful done) because NetworkManager,
PolicyKit, and/or ConsoleKit totally broke support for non-GDM
sessions: it started refusing to treat my session as "local", and
ignoring the seemingly correct XML-hell-configuration file requesting
that my user always have access to the network configuration, and so
far the only way I've been able to fix it is to waste >5% of my memory
running GDM.

This isn't the first time this has happened. The FDO junk
*superfically* interoperates with other window managers, desktop
environments or non-environments, etc., but when it comes down to it,
in order for anything to work _right_, you need GNOME. Lots of GNOME.
One example I faced a few years back (eventually stuff got fixed at
some other level so it didn't matter so much) was that XFCE could
automount USB devices, but had no way to control the mount options.
Filenames were not translated to UTF-8 correctly, permissions were
wrong, and 8.3 filenames were treated as ALL CAPS rather than
lowercase (very annoying for using digital cameras that only generate
8.3; this bug still has not been fixed, and seems intentional). But
the core problem is that the configuration of desired mount options
was not at the system level. Instead, the system left the desktop
environment to choose the mount options, subject to policies set by
PolicyKit for what options are allowed. This placed an unnecessary
burden on the desktop environment/file manager to get things right and
provide the right configurability to the user; only GNOME got it
right, so in effect, only GNOME was fully usable with the system.
As far as I can tell, it's still that way, but the defaults are less
broken so I don't care as much (actually I hexedited one binary to fix
the uppercase/lowercase issue... :).

So I take exception to the claim that FDO is "consistent" or "stable".
In my view it's only remotely consistent in one configuration: using
GNOME for everything. And it's completely unstable, constantly
deprecating one way of doing things in place of another (remember HAL?
and now I'm told ConsoleKit is deprecated too...), wasting all the
manpower of all the non-GNOME desktop projects playing catchup to work
with the latest new API so the FDO/GNOME folks can stay on top of
everything.

That's why I think, to be viable and relevant, a replacement needs a
foundation that's not built on the FDO junk (which they can keep
pulling out from under our feet every time some HS/college CS student
gets excited over whatever buzzword IPC mechanism they learned in Java
class) but independently stable.


Rich

Re: Vision for new platform

[aep]

On Mon, 21 May 2012 17:18:47 -0400, Rich Felker wrote:
> but when it comes down to it,
> in order for anything to work _right_, you need GNOME.

I'm afraid, that's the consistency i was talking about. Gnome or KDE 
are the only FDO choices available. I can fully understand the decision 
not to support my pile of hacks i call work environment,
because the only fully understood and properly researched (with actual 
real scientists, not bloggers) work environment is microsoft windows. 
There is nothing wrong with business decisions.
The only grudge i hold is that this entirely destroyed any fun in linux 
as a hobby for me.

> This placed an unnecessary
> burden on the desktop environment/file manager to get things right

The middleware bloatup here is just an artifact of the lack of policy 
in the lower stack, indeed.
It requires discipline that all of the free workforce out there just 
lacks, so you need guys like canonical to pour money in the pipe, and 
they typically fund the cheap high school kids with no experience in 
system design but lots of confidence. It also requires tons of manhours 
in testing, in order to get it working on all of the trillions of 
permutations of configurations. It's not something you just hack away in 
your lunch break.

> remember HAL?

It went away before i finished laughing.

> That's why I think, to be viable and relevant

Yes of course. I couldn't agree more.
All i'm trying to do is tell you, is that it's bloody hard. But talking 
to the guy who had the balls to rebuild a libc from scratch, it's 
possible you might just be able to pull it of.
Just put the bar a bit lower. Targeting existing desktop users isn't 
all that desirable. They're perfectly happy with the UI's that canonical 
provides for them. And it's a good thing these people like their 
universe and everything,
just like Drepper still has friends.


Arvid

Re: Vision for new platform

[Rich Felker]

On Mon, May 21, 2012 at 11:51:54PM +0200, aep wrote:
> >This placed an unnecessary
> >burden on the desktop environment/file manager to get things right
> 
> The middleware bloatup here is just an artifact of the lack of
> policy in the lower stack, indeed.

I think the problem is that the people writing this junk see
themselves as avoiding "imposing policy" (in the form of "here's how
your mount rules will work - deal with it!"), when in reality, they
imposed the most restrictive possible policy ("you must use GNOME!").

The sooner one realizes that almost everything imposes policy, and
that imposing policy is okay as long as:

(1) you're not in a position of authority/dominance over others who
are already dependent on your software and might not be able to accept
the policy change, and

(2) the policy does not seriously restrict the usage cases for the
system, just HOW you go about doing things,

the less work is involved in putting together a working system. (Look
at how much simpler musl's dynamic linker is than glibc's, mainly
because glibc's _pretends_ to be an independent component from glibc
with its own separate API, whereas in reality they're closely coupled
and the complex, not-necessarily-stable policy between the two
imposes a lot of bloat and code complexity.)

> >That's why I think, to be viable and relevant
> 
> Yes of course. I couldn't agree more.
> All i'm trying to do is tell you, is that it's bloody hard. But
> talking to the guy who had the balls to rebuild a libc from scratch,
> it's possible you might just be able to pull it of.

The biggest ingredient in pulling it off is having 1-4 people with the
determination to do it and a common (this condition is trivially
satisfied if it's just one) vision for how it should be done. That's
why I went fishing for people with the vision... :)

With that said, in hindsight I think libc is one of the hardest
possible things I could have set out to replace. Most individual
components are simple, but absolutely EVERYTHING depends on it, so in
order for things to work, EVERY detail needs to meet the specification
exactly (and often, also needs to meet unspecified requirements that
applications expect).

On the other hand, building the stuff we're talking about now does not
involve meeting the needs of any existant applications. The set of
existing "stuff" it needs to work with is not all current software,
but rather all possible (or at least all "important") hardware
configurations (and for network, VPN configurations). I'm not sure if
that's easier or harder in the grand scheme of things, but in terms of
getting it working for a particular device and user, it's much easier.

> Just put the bar a bit lower. Targeting existing desktop users isn't
> all that desirable. They're perfectly happy with the UI's that
> canonical provides for them. And it's a good thing these people like
> their universe and everything,

Are you sure? I guess there are various shades of "desktop". If I used
a quad-core 3Ghz whatever-the-latest-and-greatest-is desktop machine,
I'd probably be content with just using GNOME. (At least until I got
fed up with its treating me like an idiot...) But for laptops and
especially netbooks, DE bloat leaves your system stuttering, swapping,
and draining the battery much faster than it should.

Aside from some interface considerations (mainly screen size and touch
vs mouse/trackpad) I think a lot of the basic system component
requirements are the same for "desktop" and "mobile" platforms, and
anything in between. Especially the stuff handled by "dbus hell" in
the FDO regime now (network config, removable media, bluetooth, ...).
On the other hand, things like file managers are more different, and
might be a case where you should have completely separate applications
for each type of system. (And if the system stuff is not needlessly
coupled with this sort of app level stuff, you can mix and match them
with no problem.)

Rich

Re: Vision for new platform

[aep]

On Mon, 21 May 2012 18:25:23 -0400, Rich Felker wrote:

> I'm not sure if
> that's easier or harder in the grand scheme of things

Hehe. I can't compare. I've writen zillions of middleware and desktop 
components and ui frameworks, but i would have never imagined that 
something like libc even _can_ be rewritten without committing suicide 
halfway.
Things on top are mostly hard because the further you get on top of the 
stack, the more people think their opinion matters. Libc has the 
advantage that you can blame other people for their non standard code. 
One layer higher, there's just no standard. It's all crap, and everyone 
things their crap is the least crap. In short, it's a whole lot more 
about maintaining a kinder-garden then technical issues.
Those problems aren't even covered by a scientific field. Other then 
java-ipc research, which is just straight out worthless material. 
University degree profs fail at building a basic platform because it's 
so ridiculously hard to keep it together.

>> They're perfectly happy with the UI's that canonical provides for 
>> them.
> Are you sure?

No, i'm talking from subjective experience here.
However, from a user point of view, nettops are a non issue. The 
hardware will eventually be decent enough to drive ubuntu unity or 
whatever they call their nettop ui now. Users are very satisfied with 
it.
There's some percentage being pissed, but when you investigate further, 
it turns out they are just unhappy that things change in general. Can't 
really help those people.

> DE bloat leaves your system stuttering, swapping,
> and draining the battery much faster than it should.

I haven't used a DE for daily work in over 5 years, other then on test 
machines, because i just find the concept to be broken by design. But of 
the > 20 different vms i have at work, only kde4 on suse12 is unusable.
Progress isn't a bad thing at all, and neither is diversity in having 
different ways of working. Some people prefer having glow effects on 
their window borders, i prefer having no window borders.

The problem you might want to address, is that the diversity has a 
sharp cut when it comes to middleware. You either use the holy Ubuntu 
desktop, or you're left behind with some half baked crap. Well, i like 
sharp cuts because the positions are clear and there's no political talk 
like "well but we do kinda support your non-canonical-approved-desktop 
through these fugly undocumented xml hacks, so what are you complaining 
about?". Okay, so you're not supporting my setup, that's ok, i'll go 
build my own middleware. So here we are, all building our own hacks 
around the junk they throw at us. Might just as well rebuild the whole 
thing.


> Aside from some interface considerations (mainly screen size and 
> touch
> vs mouse/trackpad) I think a lot of the basic system component
> requirements are the same for "desktop" and "mobile" platforms,

Err, no, not really. The "Linux desktop" is a basically a copy of MS 
Window. Everything else is some basement kids dream that they matter.
Embedded platforms on the hand are engineered on unique experience. 
They'll eventually revert to mimic whatever mobile OS will dominate, but 
right now each of them has unique abilities.
They're very very different in requirements. Try to run  Windows 7 on 
128MB  RAM with a 800Mhz MIPS core. Well, they got it working, it's 
called WP7, except ... The UI is different, the MW is different, even 
the kernel is different.
It doesn't have plug and play, because it doesn't even have an usb 
host. There's no HAL, no fricking login manager, no borked .net 
delivery. I could go on and on. There's barely any code they share. Now 
for Linux. Look at the N900, that's gnome in your pocket right there. 
Then look at when a lesson was learned with the N9. No more gnome. No 
gconfd, no networkmanager, no dpkg, no weird ass X11, middleware 
entirely rebuilt. Woop all of the sudden i can actually use this thing 
to write an sms without getting a heart attack.
On the other hand, on the desktop, people enjoy these things (I don't 
know why. I really hate all of this crap getting in my way. I just want 
to open a terminal in the least painful way).


> anything in between. Especially the stuff handled by "dbus hell" in
> the FDO regime now (network config, removable media, bluetooth, ...).


Well yes. Independant of me not using a DE, i still want to be able to 
configure network in a less hacky way then writing a script that does 
ifconfig. This is what things like wicd attempt to address, but fail, 
since they're just that.. hacks around ifconfig. Here's something you 
can really get me committed with. Something that does NOT intend to be a 
an MS Windows copy, but still give me something more then the tools from 
1960 i have to use right now. Something like an actual system with an 
actual design.

> for each type of system. (And if the system stuff is not needlessly
> coupled with this sort of app level stuff, you can mix and match them
> with no problem.)

Very high goals again. Unsure how this statement differs from the goals 
of HAL. Also i wonder how you are capable of using any of these UI's 
that assume you have an IQ of zero, but to each their own.


Looking forward to it. I'm right behind you.



Arvid

Re: Vision for new platform

[Rich Felker]

On Tue, May 22, 2012 at 02:53:19AM +0200, aep wrote:
> >>They're perfectly happy with the UI's that canonical provides
> >>for them.
> >Are you sure?
> 
> No, i'm talking from subjective experience here.
> However, from a user point of view, nettops are a non issue. The
> hardware will eventually be decent enough to drive ubuntu unity or
> whatever they call their nettop ui now.

I'm not so convinced. Even if the hardware makes it smooth, having a
*good* system on a battery-powered machine could easily double the
battery life. Keep in mind that these broken DE's do things like loop
calling usleep(1000000); to update clock displays or make sure the
network is still connected... A well-designed system for battery
powered devices would have the cpu completely sleeping for minutes or
hours at a time until an external event caused an interrupt.

> The problem you might want to address, is that the diversity has a
> sharp cut when it comes to middleware. You either use the holy
> Ubuntu desktop, or you're left behind with some half baked crap.
> Well, i like sharp cuts because the positions are clear and there's
> no political talk like "well but we do kinda support your
> non-canonical-approved-desktop through these fugly undocumented xml
> hacks, so what are you complaining about?". Okay, so you're not
> supporting my setup, that's ok, i'll go build my own middleware. So
> here we are, all building our own hacks around the junk they throw
> at us. Might just as well rebuild the whole thing.

Yes.

> >Aside from some interface considerations (mainly screen size and
> >touch
> >vs mouse/trackpad) I think a lot of the basic system component
> >requirements are the same for "desktop" and "mobile" platforms,
> 
> Err, no, not really. The "Linux desktop" is a basically a copy of MS
> Window. Everything else is some basement kids dream that they
> matter.

I'd say it's a bit more complicated than that. A lot of more recent
stuff has been all about mimicing OSX eyecandy and design... I think
it's just a game of incorporating whatever's popular/fashionable, and
there's been a lot of mimicing between all sides over the past 20
years.

> Embedded platforms on the hand are engineered on unique experience.
> They'll eventually revert to mimic whatever mobile OS will dominate,
> but right now each of them has unique abilities.

This is a very healthy situation to be in with regards to evolution of
good interfaces.

> They're very very different in requirements. Try to run  Windows 7
> on 128MB  RAM with a 800Mhz MIPS core. Well, they got it working,
> it's called WP7, except ... The UI is different, the MW is
> different, even the kernel is different.

I bet most Windows users would LOVE to have that on their PCs..
Lightning fast boot, and all their ram free for bloated web apps or
gaming or whatever they do.

Basically, this is where I started 6 years ago with what led to musl:
the idea that 90% of what's happening on a typical Linux system is
crap that's not needed to get the desired results (in particular,
compare musl's UTF-8 support to glibc's locale hell and
gconv-module-based UTF-8 support), but that we still want to get
results (rather than just having a crippled system that only runs
15-year-old software and only speaks ASCII).

> there. Then look at when a lesson was learned with the N9. No more
> gnome. No gconfd, no networkmanager, no dpkg, no weird ass X11,
> middleware entirely rebuilt. Woop all of the sudden i can actually
> use this thing to write an sms without getting a heart attack.
> On the other hand, on the desktop, people enjoy these things (I
> don't know why. I really hate all of this crap getting in my way. I
> just want to open a terminal in the least painful way).

I'm not sure what all your "this crap" entails, but I'm doubtful of
the claim that all or even most desktop users enjoy it. I suspect most
_tolerate_ it because they want/need things like interactive
configuration, joining networks, notification of network/battery/etc.
status, familar volume controls and window switching, immediate access
to usb sticks they plug in, etc.

> >anything in between. Especially the stuff handled by "dbus hell" in
> >the FDO regime now (network config, removable media, bluetooth, ...).
> 
> Well yes. Independant of me not using a DE, i still want to be able
> to configure network in a less hacky way then writing a script that
> does ifconfig. This is what things like wicd attempt to address, but
> fail, since they're just that.. hacks around ifconfig. Here's
> something you can really get me committed with. Something that does
> NOT intend to be a an MS Windows copy, but still give me something
> more then the tools from 1960 i have to use right now. Something
> like an actual system with an actual design.

Exactly. Right now wicd is the only alternative to GNOME (connman is
up and coming, but has no frontend yet, and still seems to suffer from
dbus hell), and it's a bunch of ugly hacks. Basically, it was designed
in a rad-tool language as a mock-up for a network config applet, and
never got finished...

Then, NM on the other hand just sucks. There's no way to configure
preference/priority, so if I'm in range of both a slow public wifi
hotspot with ugly login procedures that I occasionally use and my
workplace wifi or the good wifi at a coffee shop I'm at, half the time
I'll end up auto-connected to the crap one.

Some things I'd want to put in a good system:

- Automatic classification of access point quality (login crap vs
  direct, speed, etc.) with manual override for particular networks if
  desired.

- Attempt to automatically bypass click-thru ToS/disclaimer junk on
  public access points, and avoid presenting the broken network with
  redirects to applications before login. (I believe this can be done
  by manipulating per-uid routing with iptables.)

- Uninterrupted service across suspend/resume if the access point is
  still present, but quick search for a new one if it's not.

> >for each type of system. (And if the system stuff is not needlessly
> >coupled with this sort of app level stuff, you can mix and match them
> >with no problem.)
> 
> Very high goals again. Unsure how this statement differs from the
> goals of HAL. Also i wonder how you are capable of using any of
> these UI's that assume you have an IQ of zero, but to each their
> own.

I'm not sure what the goals of HAL were except to make everybody's
life hell. But it's completely the opposite approach: the idea is that
everything just works by virtue of not touching (and not being able to
touch) things it has no business touching...

Rich

Re: Vision for new platform

[Christoph Lohmann]

Greetings.

On Tue, 22 May 2012 14:55:57 +0200 Rich Felker <dalias@aerifal.cx> wrote:
> > >That's why I think, to be viable and relevant
> > 
> > Yes of course. I couldn't agree more.
> > All i'm trying to do is tell you, is that it's bloody hard. But
> > talking to the guy who had the balls to rebuild a libc from scratch,
> > it's possible you might just be able to pull it of.
> 
> The biggest ingredient in pulling it off is having 1-4 people with the
> determination to do it and a common (this condition is trivially
> satisfied if it's just one) vision for how it should be done. That's
> why I went fishing for people with the vision... :)

Look at suckless.org for people already trying to change things.

> With that said, in hindsight I think libc is one of the hardest
> possible things I could have set out to replace. Most individual
> components are simple, but absolutely EVERYTHING depends on it, so in
> order for things to work, EVERY detail needs to meet the specification
> exactly (and often, also needs to meet unspecified requirements that
> applications expect).

Building a cargo cult.

> > Just put the bar a bit lower. Targeting existing desktop users isn't
> > all that desirable. They're perfectly happy with the UI's that
> > canonical provides for them. And it's a good thing these people like
> > their universe and everything,
> 
> Are you sure? I guess there are various shades of "desktop". If I used
> a quad-core 3Ghz whatever-the-latest-and-greatest-is desktop machine,
> I'd probably be content with just using GNOME. (At least until I got
> fed up with its treating me like an idiot...) But for laptops and
> especially netbooks, DE bloat leaves your system stuttering, swapping,
> and draining the battery much faster than it should.

People  are not happy using Ubuntu. But there the same schemes from Win‐
dows apply, that changes impose insults upon some people’s egos, because
the button size changed.

> Aside from some interface considerations (mainly screen size and touch
> vs mouse/trackpad) I think a lot of the basic system component
> requirements are the same for "desktop" and "mobile" platforms, and
> anything in between. Especially the stuff handled by "dbus hell" in
> the FDO regime now (network config, removable media, bluetooth, ...).
> On the other hand, things like file managers are more different, and
> might be a case where you should have completely separate applications
> for each type of system. (And if the system stuff is not needlessly
> coupled with this sort of app level stuff, you can mix and match them
> with no problem.)

The  only component that that hasn’t yet been replaced is Bluetooth, but
there are now changes in the kernel that streamline the API a bit, so it
should  be  possible to write a replacement. The current architecture of
bluez is pure SOA and can’t be understood by anyone but its developers.

Some components that are replaced: 

	udev -> nldev + mdev
	removable media -> mdev.conf
	network config -> various scripts
	systemd -> sysvinit, runit, simple scripts (conn)

Gnome  etc.  have  always  been  bloat. So if you complain now that they
somehow changed your ways, well, then use Gnome.

Maybe  instead  of  discussing  a  philosophy that already exists actual
utilities and replacements for core applications should be written.


Sincerely,

Christoph Lohmann

Re: Vision for new platform

[orc]

Want to refresh this.

> 1. Attempting to account for multiple "local users", possibly even
>   simultaneously, with complex policies controlling their access to
>   hardware and configuration.

I have such system. But multiple local users share their rights
via sudo.
If world is going singleuser again, then we need no such machinery
there. Or we need another approach.
One can leave a NOPASSWD switch in sudoers and don't think about it
anymore. Program with gui can simply execve() sudo or it's replacement,
and possibly ask user a password if he removed NOPASSWD, and pass it to
sudo. This is just an example how it can be done with sudo. I don't know
how fdo deals with it, I haven't tried it for years.

> (e.g. spying with the microphone or changing the network connection to
> intercept traffic)

This is really controlled with setuid bits or permissions to certain
device nodes. Am I wrong?

>  - pluggable devices such as: video capture/webcam, audio, printers,
>  scanners, obex/bluetooth file transfer, etc.

I really liked udev approach there: it monitors for new devices,
creates nodes and gives permissions. It can execute scripts or programs.
But udev is bloated today, it is going (or already) to be merged with
systemd, so mdev is future simple replacement.

> What I'd really like to end up with is something that's not just a new
> distro

About distros: many of them force their own vision on solving one
common problems, such as mounting devices or controlling wireless
connectivity. That's why I am, for example, using self-built one. That
is: dealing with stuff using only my hands and head was *for me* better
than dealing with stuff from certain distro. And the same for fdo junk:
instead of dealing with all it's complexity I use /bin/mount for
mounting today. I'm not saying that anyone should follow this, but it
actually *works* as manpage says. Of course it is not sufficient for
end-user nettops/mobile systems.
I don't say that distros are bad. If all is going as needed, fine! But
when undefined behavior occurs, then we try to solve it and see how
complex and buggy (in case of fdo software) that thing is.

> This is an area where traditional simple scripts (boot scripts,
> network scripts, etc.) horribly failed, using ugly things like pid
> files, killall commands, broken behavior when a device was quickly
> inserted then removed, etc.

I've dropped this ugly and slow stuff that anyone today calls 'SysV init
scripts' and written a more simpler and fast version based on idea of
BSD or Slackware ones. They can be used both in embedded and on a
regular system.

> pid files
Yup, when daemon dead (or someone cut off power), there is nothing to
kill
> killall
Horrible and harmful
Maybe pgrep/pkill sucks less and will replace that horrible approach to
store pidfiles and believe that daemon is still running.
Actually systemd is more, MORE harmful than this old stuff.

Well...
Reading your post I got an idea that we should begin to rework all
stuff from scratch. Crazy enough. But look: if you already know about
Rob Landley ideas about toybox and, in future, the QCC (a complete
busybox-like toolchain that will replace the whole GNU: gcc, binutils,
etc..), then we have a nice chance to start a new system, more just 'a
new distro that have compiled stuff and put some it's own view on how
things must be done'. You and contributors starting at point of glibc2
replacement that is better and lightweight, Rob writes a userspace
coreutils/util-linux/udev/archivers replacement that is better and
lightweight, then the gcc replacement appears that can compile Linux
kernel unmodified (or minimally modified). This can be a complete
review of stuff we are using today.

Quoting again,

> What I'd really like to end up with is something that's not just a new
> distro

And of course it will be a new platform.

I can be wrong in the ideas that I explained here. Please correct me.
Thanks.
* 'fdo' stands for freedesktop.org

Re: Re: Vision for new platform

[Isaac Dunham]

On Sat, 9 Jun 2012 19:27:56 +0800
orc <orc@sibserver.ru> wrote:


> I really liked udev approach there: it monitors for new devices,
> creates nodes and gives permissions. It can execute scripts or
> programs. But udev is bloated today, it is going (or already) to be
> merged with systemd, so mdev is future simple replacement.
Not to mention it expects files in  /usr, which is completely wrong.
gentoo is working to support mdev because of that.

> > What I'd really like to end up with is something that's not just a
> > new distro
> 
> About distros: many of them force their own vision on solving one
> common problems, such as mounting devices or controlling wireless
> connectivity. 
Or not solving, in the case of Ubuntu and wireless...
(that's a frequent issue on 11.10/12.04, from what I've
seen helping folks at the LUG)
> That's why I am, for example, using self-built one. That
> is: dealing with stuff using only my hands and head was *for me*
> better than dealing with stuff from certain distro. And the same for
> fdo junk: instead of dealing with all it's complexity I
> use /bin/mount for mounting today. I'm not saying that anyone should
> follow this, but it actually *works* as manpage says. Of course it is
> not sufficient for end-user nettops/mobile systems.
> I don't say that distros are bad. If all is going as needed, fine! But
> when undefined behavior occurs, then we try to solve it and see how
> complex and buggy (in case of fdo software) that thing is.
indeed....
mount -a does exactly the same thing as mountall, except maybe some
waiting/retrying. 
> > This is an area where traditional simple scripts (boot scripts,
> > network scripts, etc.) horribly failed, using ugly things like pid
> > files, killall commands, broken behavior when a device was quickly
> > inserted then removed, etc.
> 
> I've dropped this ugly and slow stuff that anyone today calls 'SysV
> init scripts' and written a more simpler and fast version based on
> idea of BSD or Slackware ones. They can be used both in embedded and
> on a regular system.
> 
> > pid files
> Yup, when daemon dead (or someone cut off power), there is nothing to
> kill
> > killall
> Horrible and harmful
> Maybe pgrep/pkill sucks less and will replace that horrible approach
> to store pidfiles and believe that daemon is still running.
> Actually systemd is more, MORE harmful than this old stuff.
IIRC, pkill is racey--it checks the PID for a name, then kills the PID 
(meaning that if you have almost all the processes supported running,
you use pkill, and something starts a few more programs, but the
daemon crashes before it gets killed, the new programs may end up
getting killed instead). This scenario is rather unlikely because of
time limits, but it could make for trouble occasionally.
Of course pidfiles can have the same problem unless they are
guaranteed to be removed on exit. 

I don't know if killall has the same issue, but there are certain
daemons where it is the ideal solution because only one should be
running...
(wicd sometimes starts multiple instances of wpa_supplicant, which does
not work right in a big way)

Of course, the issue is now "How on earth do you kill a
daemon?"--sometimes they stop working right, but don't realize it...
I know what wpa_supplicant does is allow IPC to send it a request to
exit, but that takes IPC.
I presume plain sockets will work for IPC, though? Or am I
underestimating the requirements?

> Well...
> Reading your post I got an idea that we should begin to rework all
> stuff from scratch. Crazy enough. But look: if you already know about
> Rob Landley ideas about toybox and, in future, the QCC (a complete
> busybox-like toolchain that will replace the whole GNU: gcc, binutils,
> etc..), then we have a nice chance to start a new system, more just 'a
> new distro that have compiled stuff and put some it's own view on how
> things must be done'. You and contributors starting at point of glibc2
> replacement that is better and lightweight, Rob writes a userspace
> coreutils/util-linux/udev/archivers replacement that is better and
> lightweight, then the gcc replacement appears that can compile Linux
> kernel unmodified (or minimally modified). This can be a complete
> review of stuff we are using today.
QCC is tcc + qcg; Rob says he's gotten all the license crap taken care
of but needs time to get it started.
I know some Puppy developers would try all of this as soon as it's
usable...if not a little sooner.
So implementations following these principles do have a chance of going
somewhere, though maybe not taking over mainline desktops.

Re: Re: Vision for new platform

[orc]

On Sat, 9 Jun 2012 07:44:26 -0700
Isaac Dunham <idunham@lavabit.com> wrote:

> gentoo is working to support mdev because of that.

I've seen gentoo folks just saying "It will be mainstream, so we will
not resist". Things got changed?

> I presume plain sockets will work for IPC, though? Or am I
> underestimating the requirements?

I think, yes. Here is a list of already existing unix IPC mechanisms:
http://unixbus.org/#unixipc

> QCC is tcc + qcg; Rob says he's gotten all the license crap taken care
> of but needs time to get it started.
The project is on hold, yes. He said that he will start it after toybox
1.0.
> So implementations following these principles do have a chance of
> going somewhere, though maybe not taking over mainline desktops.
> 

Having a little chance to change the situation completely is not the
same as 'just start Yet Another (useless) Distribution of my name'.
This (I believe) will be standalone platform if it will happen. Not a
Linux distribution. But a project aimed to rip out that all old,
bloated and buggy crap we have today.

Re: Re: Vision for new platform

[Rich Felker]

On Sat, Jun 09, 2012 at 07:44:26AM -0700, Isaac Dunham wrote:
> > > pid files
> > Yup, when daemon dead (or someone cut off power), there is nothing to
> > kill
> > > killall
> > Horrible and harmful
> > Maybe pgrep/pkill sucks less and will replace that horrible approach
> > to store pidfiles and believe that daemon is still running.
> > Actually systemd is more, MORE harmful than this old stuff.
> IIRC, pkill is racey--it checks the PID for a name, then kills the PID 
> (meaning that if you have almost all the processes supported running,

Almost all traditional uses of PIDs are racy and outright WRONG.
Unless you take extreme care, the *only* processes to which a PID
value is meaningful are the process itself and its parent process. The
parent process controls the lifetime of a PID; for the purposes of
robust resource management, child process PIDs should be treated
similarly to pointer's in the parent's address space: not something
you share with the outside world.

With that said, there are some legitimate ways to use PIDs elsewhere.
For instance if you have a process that never exits or crashes (i.e.
a proper robust daemon), then the only way the PID can be invalidated
is by explicitly terminating it, and assuming you only have one admin
or perform some sort of human-space synchronization with other admins
before killing anything, all is well and you can use the PID to kill
the process or send other signals (e.g. for reloading config).

There are also ways to mediate use of the PID through the parent
process, but these depend on the parent process being robust and not
exiting unexpectedly.

Where systemd is right is in deprecating pidfiles and other legacy
means of starting and stopping daemons based on searching the process
table. Where it's wrong is in putting all of this logic in pid #1
(init). A much better approach for systems that need automatic
stopping and starting of daemons would be to have a tiny
daemon-supervisor process to handle it; small systems with a very
"hands-on" admin not wanting to automate this could then skip the
supervisor daemon and start/stop manually.

Another approach would be for daemons to open unix sockets to control
their termination. The existence of the socket would reflect whether
the daemon is running, and serve as a race-free way to terminate the
current instance.

Rich

Re: Re: Vision for new platform

[Christian Neukirchen]

Rich Felker <dalias@aerifal.cx> writes:

> A much better approach for systems that need automatic
> stopping and starting of daemons would be to have a tiny
> daemon-supervisor process to handle it; small systems with a very
> "hands-on" admin not wanting to automate this could then skip the
> supervisor daemon and start/stop manually.

This is exactly what daemontools and variants do, with minimal code:
http://cr.yp.to/daemontools.html
http://offog.org/code/freedt.html

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Re: Vision for new platform

[Daniel Cegiełka]

2012/6/10 Christian Neukirchen <chneukirchen@gmail.com>:
> Rich Felker <dalias@aerifal.cx> writes:
>
>> A much better approach for systems that need automatic
>> stopping and starting of daemons would be to have a tiny
>> daemon-supervisor process to handle it; small systems with a very
>> "hands-on" admin not wanting to automate this could then skip the
>> supervisor daemon and start/stop manually.
>
> This is exactly what daemontools and variants do, with minimal code:
> http://cr.yp.to/daemontools.html
> http://offog.org/code/freedt.html


Chapter 4.1.1 Introducing procer:
http://mongrel2.org/static/book-finalch5.html

code:
https://github.com/zedshaw/mongrel2/tree/master/examples/procer

I think that using the code from the available solutions (like
daemontools, procer etc.) and based on our thoughts, we can prepare a
solution that would meet our expectations... secure and simple.

regards,
Daniel

Re: Re: Vision for new platform

[Rich Felker]

On Sun, Jun 10, 2012 at 02:53:49PM +0200, Daniel Cegiełka wrote:
> 2012/6/10 Christian Neukirchen <chneukirchen@gmail.com>:
> > Rich Felker <dalias@aerifal.cx> writes:
> >
> >> A much better approach for systems that need automatic
> >> stopping and starting of daemons would be to have a tiny
> >> daemon-supervisor process to handle it; small systems with a very
> >> "hands-on" admin not wanting to automate this could then skip the
> >> supervisor daemon and start/stop manually.
> >
> > This is exactly what daemontools and variants do, with minimal code:
> > http://cr.yp.to/daemontools.html
> > http://offog.org/code/freedt.html
> 
> 
> Chapter 4.1.1 Introducing procer:
> http://mongrel2.org/static/book-finalch5.html

Judging from its criticisms of daemontools, I suspect it might be just
as broken as all the traditional script/pidfile-based approaches:

    There’s just one catch: all of them suck. There’s daemontools,
    which barely builds (if at all) and then assumes that daemons
    don’t fork. Stupid.

Not stupid. Essential. If a daemon forks, there is no way to manage
its lifetime generically. Period. Any attempt to do so is full of
dangerous race conditions.

You can manage the lifetimes for forking daemons in non-generic ways
(like interfacing with them through a socket), but to make a robust
system, every daemon you use must have a "do not fork" option.
Thankfully, I think all of the mainstream ones already do, and if not,
it's not something hard to patch in. As far as I know, systemd is
pushing the same thing, so at least it's not an uphill battle to get
this fixed in real-world software that's broken.

Rich

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 09:22:46 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> You can manage the lifetimes for forking daemons in non-generic ways
> (like interfacing with them through a socket), but to make a robust
> system, every daemon you use must have a "do not fork" option.
> Thankfully, I think all of the mainstream ones already do, and if not,
> it's not something hard to patch in. As far as I know, systemd is
> pushing the same thing, so at least it's not an uphill battle to get
> this fixed in real-world software that's broken.

If we need no starting and stopping, than this can be already
implemented in init scripts. Only a simple program-wrapper that
forcibly daemonizes that daemons with "do not fork" option needed.
Optionally it can report a pid after fork() before execvp().

I just think that init subsystem must be as simple as possible,
without additional machinery like automatic starting and stopping and
watching for daemons status (but optionally it can be developed, of
course, there is no limits at all). If daemon segfaults for example,
than this is a daemon's failure that *must* be fixed in daemon, not in
init subsystem. Daemon restarts can result in data loss.
Otherwise you can't trust the daemon that is running from init scripts.
(I'm a bit paranoid here)

Re: Re: Vision for new platform

[orc]

> (but optionally it can be developed, of course, there is no limits at
> all).

* I mean here that this logic, if needed, must NOT be a part of process
  number one (init) as systemd does.

Re: Vision for new platform

[Jeremy Huntwork]

On 5/17/12 9:06 PM, Rich Felker wrote:
> What I'd really like to end up with is something that's not just a new
> distro (in fact it could be used on or by several of the distros this
> community is already working on as well as further new ones or perhaps
> existing ones), but a new "platform" of sorts, with the idea that it
> would be fully capable of running and interoperating with existing gui
> *applications* written for X/GNOME/KDE/whatever, but not necessarily
> compatible with any of the system-level junk these environments use.

I've been watching this thread with keen interest, and I'd love to see 
something like this happen.

I realize you were just opening discussion here and that you've also 
already listed several details about what you'd like to see and what 
you'd like to avoid, but perhaps it would be useful now to start drawing 
up a draft specification? Is there somewhere that we can collaboratively 
design a document that lists functional goals as well as design principles?

> I still see this all, at least the completion of it, as a mid- to
> long-range project, but I think it's something we could and should
> start discussing, and I hope some of you who are already into
> distro-building will be interested in experimenting with new
> approaches to the ugly guts of making a working user-facing system.

Absolutely.

> Maybe we can start with the daemon/script side of things and some CLI
> tools to work with them and just experiment and see how it evolves,
> and then solidify the design and polish the implementations once we
> have some results.

This might be a good first area to tackle (as the discussions seem to be 
heading there already anyway), but I still think it will be useful to 
have at least a document which provides guidance as to purpose and 
principles of design (i.e., why this effort and what pitfalls we're 
hoping to avoid).

JH

Re: Re: Vision for new platform

[Rich Felker]

On Sun, Jun 10, 2012 at 10:52:26PM +0800, orc wrote:
> On Sun, 10 Jun 2012 09:22:46 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > You can manage the lifetimes for forking daemons in non-generic ways
> > (like interfacing with them through a socket), but to make a robust
> > system, every daemon you use must have a "do not fork" option.
> > Thankfully, I think all of the mainstream ones already do, and if not,
> > it's not something hard to patch in. As far as I know, systemd is
> > pushing the same thing, so at least it's not an uphill battle to get
> > this fixed in real-world software that's broken.
> 
> If we need no starting and stopping, than this can be already
> implemented in init scripts. Only a simple program-wrapper that
> forcibly daemonizes that daemons with "do not fork" option needed.
> Optionally it can report a pid after fork() before execvp().

I don't think you're getting the issue at hand. Suppose you want to be
able to automatically bring down a particular daemon -- perhaps to
restart it with completely new configuration or to switch to a new
version of it. This could happen as part of an automated upgrade
process or under manual admin control.

Traditional init scripts DO NOT solve this problem. They are extremely
buggy, ranging from doing things as stupid as killing any instance of
the daemon (even one run by a user as opposed to by root with a
separate config file and running on a separate port) to killing
unrelated processes (by scanning /proc or reading a pid file, then
subsequently killing the pid which might not belong to a different
process).

> I just think that init subsystem must be as simple as possible,
> without additional machinery like automatic starting and stopping and
> watching for daemons status (but optionally it can be developed, of
> course, there is no limits at all). If daemon segfaults for example,
> than this is a daemon's failure that *must* be fixed in daemon, not in
> init subsystem. Daemon restarts can result in data loss.

I agree that the problem of daemons crashing or otherwise exiting
unexpectedly is one that should be fixed in the daemons. Unfortunately
that's much harder than it sounds. A large portion of the daemons in
modern use are using "xmalloc" type wrappers that abort
unconditionally on malloc failure, either directly or by virtue of
using atrociously-bad libraries like glib that abort without the
caller's consent.

If daemons really didn't exit unexpectedly, the only race condition in
pid-based approaches to lifetime management would be races between
multiple scripted administrative actions (e.g. 2 admins trying to down
the daemon at the same time) which could be fixed by locking at the
script level.

Still, I think the best approach if you want to be able to manage
scripted start/stop of daemons is to insist that they not fork and
have their direct parent be responsible. BTW, systemd cheats in this
regard: it's ALWAYS the direct parent of daemons that forked, because
orphaned processes get re-parented to PID #1.

Rich

Re: Re: Vision for new platform

[Daniel Cegiełka]

2012/6/10 orc <orc@sibserver.ru>:
> On Sun, 10 Jun 2012 09:22:46 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
>
>> You can manage the lifetimes for forking daemons in non-generic ways
>> (like interfacing with them through a socket), but to make a robust
>> system, every daemon you use must have a "do not fork" option.
>> Thankfully, I think all of the mainstream ones already do, and if not,
>> it's not something hard to patch in. As far as I know, systemd is
>> pushing the same thing, so at least it's not an uphill battle to get
>> this fixed in real-world software that's broken.
>
> If we need no starting and stopping, than this can be already
> implemented in init scripts. Only a simple program-wrapper that
> forcibly daemonizes that daemons with "do not fork" option needed.
> Optionally it can report a pid after fork() before execvp().
>
> I just think that init subsystem must be as simple as possible,
> without additional machinery like automatic starting and stopping and
> watching for daemons status (but optionally it can be developed, of
> course, there is no limits at all). If daemon segfaults for example,
> than this is a daemon's failure that *must* be fixed in daemon, not in
> init subsystem. Daemon restarts can result in data loss.
> Otherwise you can't trust the daemon that is running from init scripts.
> (I'm a bit paranoid here)


I think a lot depends on how we want to use our system. If its user
desktop, a solution such as systemd are very comfortable. If we want
to have a 'critical' system (RTOS/security) then it's better to keep
independent init as simple process.
Orc, I agree with your opinion...

Daniel

Re: Re: Vision for new platform

[Rich Felker]

On Sun, Jun 10, 2012 at 05:17:47PM +0200, Daniel Cegiełka wrote:
> I think a lot depends on how we want to use our system. If its user
> desktop, a solution such as systemd are very comfortable. If we want

Somehow I suspect that running systemd creates a situation where init
(and thus the whole system) crashes on low memory. This is not
appropriate behavior for ANY system, even if it is a user-facing
desktop system. Think too of things like phones; you don't want to be
rebooting your phone and unable to receive a phone call because some
crappy app is consuming all your memory...

> to have a 'critical' system (RTOS/security) then it's better to keep
> independent init as simple process.

I believe it's a mistake to consider robustness a requirement that
only applies to RTOS and similar.

With that said, I don't think we need to be in the business of saying
"To be system X you must use tools Y and Z!"; instead, we should
identify the tools necessary to make a robust and lightweight system,
document these choices, and show it in action. There's no reason to
preclude somebody who wants to crappify the system from using systemd,
dbus, etc. but the tools we select (and any new ones we write) should
avoid depending on broken stuff.

Rich

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 11:13:11 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Jun 10, 2012 at 10:52:26PM +0800, orc wrote:
> > If we need no starting and stopping, than this can be already
> > implemented in init scripts. Only a simple program-wrapper that
> > forcibly daemonizes that daemons with "do not fork" option needed.
> > Optionally it can report a pid after fork() before execvp().
> 
> I don't think you're getting the issue at hand. Suppose you want to be
> able to automatically bring down a particular daemon -- perhaps to
> restart it with completely new configuration or to switch to a new
> version of it. This could happen as part of an automated upgrade
> process or under manual admin control.

'Automated' often becomes the source of problems, if this automated
subsystem is not engineered properly. If we want daemon that will be
responsible for other's daemons status and it will start and stop them
automatically based on the admin's decision than it must be
well-engineered and tested in many types of situations first.

> 
> Traditional init scripts DO NOT solve this problem. They are extremely
> buggy, ranging from doing things as stupid as killing any instance
> of the daemon

Are you talking about traditional SysV init scripts? Yes, they're
buggy, I fully agree.

> (even one run by a user as opposed to by root with a
> separate config file and running on a separate port)

Killing processes based on uid/gid and cmdline can be achieved with
pkill already,

> to killing
> unrelated processes (by scanning /proc or reading a pid file, then
> subsequently killing the pid which might not belong to a different
> process).

Again, pkill much better than "traditional"
"kill $(cat /var/run/daemon.pid)" that most of init script use today
(Am I right?)

> I agree that the problem of daemons crashing or otherwise exiting
> unexpectedly is one that should be fixed in the daemons. Unfortunately
> that's much harder than it sounds. A large portion of the daemons in
> modern use are using "xmalloc" type wrappers that abort
> unconditionally on malloc failure, either directly or by virtue of
> using atrociously-bad libraries like glib that abort without the
> caller's consent.

I fully agree that the in reality we have no ideal daemons in this
question, many of them are unreliable.

> 
> If daemons really didn't exit unexpectedly, the only race condition in
> pid-based approaches to lifetime management would be races between
> multiple scripted administrative actions (e.g. 2 admins trying to down
> the daemon at the same time) which could be fixed by locking at the
> script level.

Hm, for me that situation sounds a bit strange: even script will exit
with 'daemon already stopped' or script will send an additional signal
to daemon that will not harm it such (I omit here talk about
sighandlers, most daemons did not crashed after a second signal if it
was not KILL signal).

I partially agree with approach that such daemon for monitoring status
of other daemons should be developed, but I think this daemon should
control only critical processes for admin, such as:
- syslog daemon (Such situation happened with me when rsyslog crashed
  for no reason)
- possibly various daemons for remote network access, such as sshd (?)
- other daemons, if their task is not to write/read something important
  from disk. For example, database daemons should NOT be restarted
  automatically.

P.S. If you talk about traditional init scripts that to be appear in
most distros today - then I fully agree with you in all aspects you
talked about here. I was paranoid, and rewritten them from scratch back
some time ago.

Re: Re: Vision for new platform

[Rich Felker]

On Sun, Jun 10, 2012 at 11:51:25PM +0800, orc wrote:
> > I don't think you're getting the issue at hand. Suppose you want to be
> > able to automatically bring down a particular daemon -- perhaps to
> > restart it with completely new configuration or to switch to a new
> > version of it. This could happen as part of an automated upgrade
> > process or under manual admin control.
> 
> 'Automated' often becomes the source of problems, if this automated
> subsystem is not engineered properly. If we want daemon that will be
> responsible for other's daemons status and it will start and stop them
> automatically based on the admin's decision than it must be
> well-engineered and tested in many types of situations first.

Without "automated", how do you intend for non-technical users to
upgrade important system components when their old version has a
critical vulnerability? Even if the system has a technically qualified
admin, nobody wants to go manually upgrading/restarting daemons on
tens, hundreds, or thousands of boxes...

I agree automation is a huge source of problems, but I think they're
fundamental problems you can't just pretend don't exist.

> > (even one run by a user as opposed to by root with a
> > separate config file and running on a separate port)
> 
> Killing processes based on uid/gid and cmdline can be achieved with
> pkill already,

No, it cannot. Before you can solve any of these problems you must
understand that you can't use resource handles that belong to another
process which could invalidate them behind your back. This is a core
principle of concurrency programming, and pids are such a resource.

As an aside, I used to really dislike the push towards multi-threaded
programming because concurrency is error-prone and hard to get right.
Then I realized that basically all unix systems programming is
concurrent programming, just disguised to look safe...

> > to killing
> > unrelated processes (by scanning /proc or reading a pid file, then
> > subsequently killing the pid which might not belong to a different
> > process).
> 
> Again, pkill much better than "traditional"
> "kill $(cat /var/run/daemon.pid)" that most of init script use today
> (Am I right?)

No. The pkill approach is the "doing things as stupid as killing any
instance of the daemon" in my text you quoted.

At least with pid files, you know the pid you kill _at one time_
belonged to the daemon you wanted to kill. With pkill, you'll pick up
completely independent instances of the same program binary.

> > If daemons really didn't exit unexpectedly, the only race condition in
> > pid-based approaches to lifetime management would be races between
> > multiple scripted administrative actions (e.g. 2 admins trying to down
> > the daemon at the same time) which could be fixed by locking at the
> > script level.
> 
> Hm, for me that situation sounds a bit strange: even script will exit
> with 'daemon already stopped' or script will send an additional signal

No. It will send a TERM/KILL signal to a new process that happens to
have the same PID as the already-killed daemon. If you get lucky, no
such new process exists, but that's called "getting lucky" which has
no place in robust systems.

> I partially agree with approach that such daemon for monitoring status
> of other daemons should be developed, but I think this daemon should
> control only critical processes for admin, such as:

My view is this:

1. On a hobbyist or fully self-maintained system where you're willing
to manually do all the work of upgrading/restarting things, or on
certain embedded systems where reboot-on-upgrade is acceptable or
where you're sure you won't need security updates (because the system
does not interact with potentially-dangerous inputs), just start all
the daemons from your init script with no management and be done with
it. Components should not be designed in ways that _preclude_ this
ultra-simple setup.

2. On everything else, use your choice of robust daemon management
tool that starts daemons as direct children and therefore can observe
their death and/or intentionally kill them without any race
conditions.

Rich

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 12:33:59 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Jun 10, 2012 at 11:51:25PM +0800, orc wrote:
> > > I don't think you're getting the issue at hand. Suppose you want
> > > to be able to automatically bring down a particular daemon --
> > > perhaps to restart it with completely new configuration or to
> > > switch to a new version of it. This could happen as part of an
> > > automated upgrade process or under manual admin control.
> > 
> > 'Automated' often becomes the source of problems, if this automated
> > subsystem is not engineered properly. If we want daemon that will be
> > responsible for other's daemons status and it will start and stop
> > them automatically based on the admin's decision than it must be
> > well-engineered and tested in many types of situations first.
> 
> Without "automated", how do you intend for non-technical users to
> upgrade important system components when their old version has a
> critical vulnerability? Even if the system has a technically qualified
> admin, nobody wants to go manually upgrading/restarting daemons on
> tens, hundreds, or thousands of boxes...

Okay, this will be sufficient for end users.

> At least with pid files, you know the pid you kill _at one time_
> belonged to the daemon you wanted to kill. With pkill, you'll pick up
> completely independent instances of the same program binary.

Aw. Missed this important about pkill/killall. Thanks, my fault.
* me really said some stupid things there.

> 1. On a hobbyist or fully self-maintained system where you're willing
> to manually do all the work of upgrading/restarting things, or on
> certain embedded systems where reboot-on-upgrade is acceptable or
> where you're sure you won't need security updates (because the system
> does not interact with potentially-dangerous inputs), just start all
> the daemons from your init script with no management and be done with
> it. Components should not be designed in ways that _preclude_ this
> ultra-simple setup.
> 
> 2. On everything else, use your choice of robust daemon management
> tool that starts daemons as direct children and therefore can observe
> their death and/or intentionally kill them without any race
> conditions.

But with pushing something new we should really understand that it will
not become a second 'systemd'.
Thank you very much for explanation.

Re: Vision for new platform

[Kurt H Maier]

On Sun, Jun 10, 2012 at 11:12:41AM -0400, Jeremy Huntwork wrote:
> draft specification? 
> collaboratively design a document
> design principles?
> guidance as to purpose 
> principles of design

Huntwork casts Debianize!

Re: Re: Vision for new platform

[Daniel Cegiełka]

>> 1. On a hobbyist or fully self-maintained system where you're willing
>> to manually do all the work of upgrading/restarting things, or on
>> certain embedded systems where reboot-on-upgrade is acceptable or
>> where you're sure you won't need security updates (because the system
>> does not interact with potentially-dangerous inputs), just start all
>> the daemons from your init script with no management and be done with
>> it. Components should not be designed in ways that _preclude_ this
>> ultra-simple setup.
>>
>> 2. On everything else, use your choice of robust daemon management
>> tool that starts daemons as direct children and therefore can observe
>> their death and/or intentionally kill them without any race
>> conditions.
>
> But with pushing something new we should really understand that it will
> not become a second 'systemd'.
> Thank you very much for explanation.

Do we have some conclusions? systemd+udev is resource hungry, so the
question is, what next? Do we have to think about preparing a new
solution?

Re: Vision for new platform

[Jeremy Huntwork]

Heh, I suppose the language I used is a lot more formal than I meant it. I simply want a way to define and agree on common goals so that actual work can be organized. Admittedly, though, I think some strong core goals and leadership is necessary so that any combined effort does not end up becoming a sloppy mess.

JH 


On Sunday, June 10, 2012 at 2:03 PM, Kurt H Maier wrote:

> On Sun, Jun 10, 2012 at 11:12:41AM -0400, Jeremy Huntwork wrote:
> > draft specification? 
> > collaboratively design a document
> > design principles?
> > guidance as to purpose 
> > principles of design
> 
> 
> 
> Huntwork casts Debianize! 

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 20:03:56 +0200
Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:

> Do we have some conclusions? systemd+udev is resource hungry, so the
> question is, what next? Do we have to think about preparing a new
> solution?

The problem with systemd is that it is not only bloated
all-in-pid-number-1 thing that depends on dbus, it *comes* from
freedesktop, which reputation is not so good at software engineering.
And udev is going to be merged with that codebase.
And important thing: not to repeat already repeated mistakes.

Re: Re: Vision for new platform

[Daniel Cegiełka]

>> Do we have some conclusions? systemd+udev is resource hungry, so the
>> question is, what next? Do we have to think about preparing a new
>> solution?
>
> The problem with systemd is that it is not only bloated
> all-in-pid-number-1 thing that depends on dbus, it *comes* from
> freedesktop, which reputation is not so good at software engineering.
> And udev is going to be merged with that codebase.
> And important thing: not to repeat already repeated mistakes.

I understand that and instead systemd I prefer to stay with
sysvinit+openrc... but the only solution is to prepare a new init
stuff from scratch (systemd+udev+dbus alternative). Do you see another
solution?

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 20:38:57 +0200
Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:

> >> Do we have some conclusions? systemd+udev is resource hungry, so
> >> the question is, what next? Do we have to think about preparing a
> >> new solution?
> >
> > The problem with systemd is that it is not only bloated
> > all-in-pid-number-1 thing that depends on dbus, it *comes* from
> > freedesktop, which reputation is not so good at software
> > engineering. And udev is going to be merged with that codebase.
> > And important thing: not to repeat already repeated mistakes.
> 
> I understand that and instead systemd I prefer to stay with
> sysvinit+openrc... but the only solution is to prepare a new init
> stuff from scratch (systemd+udev+dbus alternative). Do you see another
> solution?

Maybe new init stuff, maybe daemon that will control other daemons and
get launched from inittab for example.
I'm just trying to warn that this must not be a second systemd and
that's all. Sure that adequate non-bloated alternative should exist.
Maybe it should be developed as a part of new platform that we
all want to have, because as an alternative alone it will not be
accepted well.

Re: Re: Vision for new platform

[Daniel Cegiełka]

>> I understand that and instead systemd I prefer to stay with
>> sysvinit+openrc... but the only solution is to prepare a new init
>> stuff from scratch (systemd+udev+dbus alternative). Do you see another
>> solution?
>
> Maybe new init stuff, maybe daemon that will control other daemons and
> get launched from inittab for example.
> I'm just trying to warn that this must not be a second systemd and
> that's all. Sure that adequate non-bloated alternative should exist.
> Maybe it should be developed as a part of new platform that we
> all want to have, because as an alternative alone it will not be
> accepted well.

musl libc is an alternative to glibc etc. We talk about the vision of
a new platform, so if this new solution would arise, then its natural
that init stuff should be developed as a project related to musl. The
main question is whether we should start such a project (new init) or
may remain with existing init (sysvinid / systemd / runit etc.)?

Daniel

Re: Re: Vision for new platform

[Rich Felker]

On Sun, Jun 10, 2012 at 08:38:57PM +0200, Daniel Cegiełka wrote:
> > The problem with systemd is that it is not only bloated
> > all-in-pid-number-1 thing that depends on dbus, it *comes* from
> > freedesktop, which reputation is not so good at software engineering.
> > And udev is going to be merged with that codebase.
> > And important thing: not to repeat already repeated mistakes.
> 
> I understand that and instead systemd I prefer to stay with
> sysvinit+openrc...

sysvinit is really not a rational design. It does a lot of the same
stupid stuff as systemd (controlling process lifetime from pid 1, but
in this case it's only used for legacy console gettys, not for
daemons). And runlevels never really made any sense to me; they just
made init scripts a lot more complex and difficult to maintain by
having to handle the additional case of switching between runlevels
with different things in them and getting the order of stop/start
right..

> but the only solution is to prepare a new init
> stuff from scratch (systemd+udev+dbus alternative). Do you see another
> solution?

I think it's a mistake to think in terms of needing a replacement for
X+Y+Z instead of needing a solution to problems A,B,C. Especially when
X+Y+Z are poorly designed and it's not even clear what problems they
were intended to solve.

Let's instead start from the perspective of problems to solve:

1. Initiating/controlling the boot process.
2. Providing login prompts on console ttys.
3. Managing system daemons.
4. Handling insertion and removal of hardware.
5. Handling changes to hardware status.
6. Shutting down/rebooting the system.

I'm generally of the opinion that trying to tightly integrate these
(largely unrelated) tasks just creates a lot of complexity and lock-in
with little or no benefit. In contrast, for problems #1 and 2, I have
a 22-line (C) init program that does nothing but run the boot script
and reap orphaned zombies, and a 34-line (C) program that repeatedly
re-runs a program in a new session every time it exits. The latter,
combined with a 14-line (shell script) getty program, is sufficient to
handle all console logins.

I hope this doesn't come across as a claim that ALL of the above tasks
are trivial; indeed, they're not. But I think it is a motivation for
highly factoring different tasks...

Rich

Re: Re: Vision for new platform

[Daniel Cegiełka]

> I'm generally of the opinion that trying to tightly integrate these
> (largely unrelated) tasks just creates a lot of complexity and lock-in
> with little or no benefit. In contrast, for problems #1 and 2, I have
> a 22-line (C) init program that does nothing but run the boot script
> and reap orphaned zombies,

"ninit is an extremely small init daemon that does nothing more than
call shell scripts in response to events and reap zombies."

http://kain.us/nk/projects/


> and a 34-line (C) program that repeatedly
> re-runs a program in a new session every time it exits. The latter,
> combined with a 14-line (shell script) getty program, is sufficient to
> handle all console logins.
>
> I hope this doesn't come across as a claim that ALL of the above tasks
> are trivial; indeed, they're not. But I think it is a motivation for
> highly factoring different tasks...
>
> Rich

The key is that we have built a solution that will meet our
expectations. We discuss different ideas, but finally will need to
reduce everything to a single working solution.

Daniel

Re: Re: Vision for new platform

[orc]

On Sun, 10 Jun 2012 22:13:49 +0200
Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:

> "ninit is an extremely small init daemon that does nothing more than
> call shell scripts in response to events and reap zombies."
> 
> http://kain.us/nk/projects/
> 

Nice one, I tried it and I'm going to replace a traditional sysvinit
with it. More simpler and faster sysvinit alternative. Thanks.

Init system (Re: [musl] Re: Vision for new platform)

[aep]

I designed one based on the needs we had in previous embedded products, 
but got stuck because the project was killed and replaced by ubuntu 
upstart.

Still there's plenty things that are interesting in that area, so i 
kept working on it in my free time. Since it's written in a high level 
language (clay) it will never be accepted by most of you, but i's still 
love some dicussion on the actual design of these things.

We clearly agree that the general direction systemd is taking is very 
wrong. I believe they'll sooner or later realize on their own, and build 
another udev to fix it.

On Sun, 10 Jun 2012 15:33:48 -0400, Rich Felker wrote:

> And runlevels never really made any sense to me

They do not, on a desktop where you usually want exactly two: 1) "boot 
to my favorite UI" and 2) "Give me a recovery shell."

Hoever, on embedded devices, there are more init states which aren't 
covered by any currently existing software:

- Charging, but not powered on
- Fault recovery
- Update cycle
- Reboot from NVRAM

Boot states with numbers, are clearly from the 60s. Upstart correctly 
replaces them with init "groups", however the control interface through 
dbus is too broken to use them.
Neither can any of the existing software correctly make it's boot graph 
depend on hardware tables in the bootsector. This is very important for 
mass produced devices which get the same software for different hardware 
variants.
Instead there's usually a second and third init process involved. Just 
like on the desktop where there is a "high level init system" executed 
when you are logged into your desktop thingy.
My toy project solves this by putting the session controller in pid 1, 
and exposing the relevant bits to a comandline interface, which i call 
from .xinitrc
The actual problem of init groups is not solved, since i don't care. 
But in a "real" product, i'd do something very similar to upstart.


> Let's instead start from the perspective of problems to solve:
>
> 1. Initiating/controlling the boot process.
> 2. Providing login prompts on console ttys.
> 3. Managing system daemons.



> 4. Handling insertion and removal of hardware.
> 5. Handling changes to hardware status.

Don't mix them together. This is a much much bigger problem then "start 
some daemon when i plug in a printer"
Systemd solves this problem in a very crude and short sighted way. You 
still need a high level mechanic to actually do something with the 
printer.
They just fire a signal over dbus and let someone else worry with the 
problem while the "someone else" has to invent it's own hardware 
abstraction layer to get anywhere.
This is a receive for bloat and painful design.

Instead my toy init exposes no hardware events. It merely acts on 
behalf of any arbitrary hardware controller, which can be multiple. It 
assumes that there is something like mdev or udev.
It exposes all the "services that can be started" like "printing", but 
never starts them based on anything except an explicit call to the start 
interface. Since in the core it exposes a  ubus [http://unixbus.org/] 
service for each
service to be started, permissions are simply solved with regular unix 
modes. While this is elegant, it has one major flaw, that is domain 
sockets in linux have no permission checking, requiring an additional 
ugly layer of extra checking on SCM_CREDS. I never solved that problem 
after i realized what a kind of person al viro is. He'd never accept a 
fix to the kernel unless it comes with $$$ attached. But... different 
story i suppose.


> 6. Shutting down/rebooting the system.

Note that the lack of high level policy bites you here a lot. I just 
type "witch halt" which brings down my session cleanly too, but every 
other init system requires a secondary high level init to be shut down 
first, otherwise you get "Not exited cleanly" warnings on your favorite 
BloatDE. No idea how other distros solve it, but archlinux has a really 
ugly "Sending kill to remaining processes" at the end of shutdown. For 
me this is a clear indication that shutdown is just horribly broken.


> I'm generally of the opinion that trying to tightly integrate these
> (largely unrelated) tasks just creates a lot of complexity and 
> lock-in
> with little or no benefit.


I just read that after complaining that you did, haha.


> In contrast, for problems #1 and 2, I have
> a 22-line (C) init program that does nothing but run the boot script
> and reap orphaned zombies, and a 34-line (C) program that repeatedly
> re-runs a program in a new session every time it exits. The latter,
> combined with a 14-line (shell script) getty program, is sufficient 
> to
> handle all console logins.


As i said in the beginning of this thread, everyone has their favorite 
hack. Creating something that works for everyone is much much harder.
And clearly this is the part that needs to be solved. 22 lines C and a 
couple shell lines is how sysvinit started, and then quickly went out of 
control when trying to make the thing scale to every machine in the 
universe.

Re: Re: Vision for new platform

[Isaac Dunham]

On Sun, 10 Jun 2012 15:33:48 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Jun 10, 2012 at 08:38:57PM +0200, Daniel Cegiełka wrote:
> > I understand that and instead systemd I prefer to stay with
> > sysvinit+openrc...
> 
> sysvinit is really not a rational design. It does a lot of the same
> stupid stuff as systemd (controlling process lifetime from pid 1, but
> in this case it's only used for legacy console gettys, not for
> daemons). And runlevels never really made any sense to me; they just
> made init scripts a lot more complex and difficult to maintain by
> having to handle the additional case of switching between runlevels
> with different things in them and getting the order of stop/start
> right..

runlevels come in handy, if you know how to use them.
Debian mutilates them, though, so they seem less handy on
Debian/Ubuntu systems.
Here's what I'd do:
1. I just want to get into recovery (single-user) mode in a hurry; the
system is hosed as it stands.
2. I want a shell, quick (maybe because there's one file I need to copy
over to a flash drive)
3. Networking would be nice, but I don't want X just yet.
4. X is handy, but maybe not networking or printing...
5. Start the whole enchilada.

And yes, I do see a need for all 5 of those, including a way to start
the system in any of them (which runlevels allow, via kernel
parameters).
Sometimes, starting networking or not makes a minute or more of
difference (yes, I've timed it: 34 seconds vs 100+).  On one of my
computers, if I let the networking daemon run in the wrong area, it
reliably panics the kernel (madwifi 0.10.5.6 is the most functional
driver, except it panics if dhclient gets run too soon). So "turn off
networking via boot parameter" is mandatory for me.

In summary, if you remove runlevels, you'd have to do the same thing
another way to meet my needs.
Isaac Dunham

Re: Re: Vision for new platform

[Rich Felker]

On Mon, Jun 11, 2012 at 05:59:22PM -0700, Isaac Dunham wrote:
> runlevels come in handy, if you know how to use them.
> Debian mutilates them, though, so they seem less handy on
> Debian/Ubuntu systems.
> Here's what I'd do:
> 1. I just want to get into recovery (single-user) mode in a hurry; the
> system is hosed as it stands.

If you're just talking about booting, adding "init=/bin/sh" to the
kernel boot line is the way to do this..

If you're talking about taking down a running system "into single-user
mode", that's a hard problem to do correctly and it depends on all the
daemon stop/start stuff.

> 2. I want a shell, quick (maybe because there's one file I need to copy
> over to a flash drive)
> 3. Networking would be nice, but I don't want X just yet.
> 4. X is handy, but maybe not networking or printing...
> 5. Start the whole enchilada.
> 
> And yes, I do see a need for all 5 of those, including a way to start
> the system in any of them (which runlevels allow, via kernel
> parameters).
> Sometimes, starting networking or not makes a minute or more of
> difference (yes, I've timed it: 34 seconds vs 100+).  On one of my

Our aim should be <5 seconds (preferably <1 sec) from power on to full
UI. The reason I bring this up is that A LOT of the motivations for a
lot of the bad designs in legacy boot/init/etc. systems, including
systemd, is due to tolerating ultra-slow crap and then trying to make
it less hideous by doing it in the background, etc.

As such, I don't think "we need to be able to boot into profile X or
profile Y because profile Y might sometimes be too slow" is a good
argument for multiple boot profiles. Nonetheless, I think they could
be done as long as the kernel boot passes some environment to init
which can in turn be passed to the script init runs that starts the
daemons or daemon supervisor.

Speaking of which, if we end up writing a new program for that, how's
"daemon-visor" for a name? I can think of some nice logos for it.. :-)

> computers, if I let the networking daemon run in the wrong area, it
> reliably panics the kernel (madwifi 0.10.5.6 is the most functional
> driver, except it panics if dhclient gets run too soon). So "turn off
> networking via boot parameter" is mandatory for me.

This is extremely broken and needs fixing...

Rich

Re: Re: Vision for new platform

[idunham]

> On Mon, Jun 11, 2012 at 05:59:22PM -0700, Isaac Dunham wrote:
>> runlevels come in handy, if you know how to use them.
>> Debian mutilates them, though, so they seem less handy on
>> Debian/Ubuntu systems.
>> Here's what I'd do:
>> 1. I just want to get into recovery (single-user) mode in a hurry; the
>> system is hosed as it stands.
>
> If you're just talking about booting, adding "init=/bin/sh" to the
> kernel boot line is the way to do this..
> If you're talking about taking down a running system "into single-user
> mode", that's a hard problem to do correctly and it depends on all the
> daemon stop/start stuff.
Both.
init=/bin/sh is usually good; however, I have seen at least two systems
where it wouldn't boot (one Arch Linux and one Scientific Linux)
Also, I'd rather use the same command both times...
>> 2. I want a shell, quick (maybe because there's one file I need to copy
>> over to a flash drive)
>> 3. Networking would be nice, but I don't want X just yet.
>> 4. X is handy, but maybe not networking or printing...
>> 5. Start the whole enchilada.
>>
>> And yes, I do see a need for all 5 of those, including a way to start
>> the system in any of them (which runlevels allow, via kernel
>> parameters).
>> Sometimes, starting networking or not makes a minute or more of
>> difference (yes, I've timed it: 34 seconds vs 100+).  On one of my
>
> Our aim should be <5 seconds (preferably <1 sec) from power on to full
> UI. The reason I bring this up is that A LOT of the motivations for a
> lot of the bad designs in legacy boot/init/etc. systems, including
> systemd, is due to tolerating ultra-slow crap and then trying to make
> it less hideous by doing it in the background, etc.
Tell me how you plan to handle wireless+DHCP. It can take 5+ seconds to
associate, and 20+ to get a lease.  That's not negotiable, it's the facts
of life. dhclient defaults to 60 seconds timeout, IIRC.
There are other devices that will not initialize without a 3-5 second pause.


Anyhow, I still insist on a choice at boot time of X or text.  I could
list numerous reasons other than speed, but would rather not.

> As such, I don't think "we need to be able to boot into profile X or
> profile Y because profile Y might sometimes be too slow" is a good
> argument for multiple boot profiles. Nonetheless, I think they could
> be done as long as the kernel boot passes some environment to init
> which can in turn be passed to the script init runs that starts the
> daemons or daemon supervisor.
parsing /proc/cmdline is the standard approach.

>> computers, if I let the networking daemon run in the wrong area, it
>> reliably panics the kernel (madwifi 0.10.5.6 is the most functional
>> driver, except it panics if dhclient gets run too soon). So "turn off
>> networking via boot parameter" is mandatory for me.
>
> This is extremely broken and needs fixing.
I know, but it's beyond my knowledge, the madwifi developers have
abandoned this branch, and both ath5k and madwifi 0.9.4 (the official
version) drop connections multiple times per hour--and that's been a
"known issue" since 2008, IIRC (still not fixed in kernel 3.4).
ndiswrapper may not work these days (I've heard of connection drops that
way, too), it's a pain, and I'm not touching it.
In other words, it's not getting fixed, and it's still better than the
alternatives.
And you can bet that there will be more drivers that don't work right.

Re: Re: Vision for new platform

[Kurt H Maier]

On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@lavabit.com wrote:
> Tell me how you plan to handle wireless+DHCP. It can take 5+ seconds to
> associate, and 20+ to get a lease.  That's not negotiable, it's the facts
> of life.

For the record, this isn't a problem on all hardware.  My intel cards
all associate and pull IPs in less than ten seconds at most.  I don't
use anything but wpa_supplicant and dhcpcd.

Re: Re: Vision for new platform

[orc]

Some compromise can be reached here:

- User wants runlevels, boot profiles, etc... - a daemon that started
  by minimal init can be developed,
- User do not wants runlevels, his/her system is controlled by, for
  example, shell scripts - then daemon is optional, init starts shell
  script that will boot the rest system (as ninit does for example)

Daemon must not be overfeatured, must be highly configurable and
controllable, and should target only few platforms (generally only
platforms that use Linux as kernel). Daemon should not control hardware
status, this is a mdev/udev's job. Ideally, as udev/mdev is for
hardware, than this daemon is for processes.
Both daemon and init can be a part of one package, and when installing,
user should be able to select, which components it wants to install
(install daemon or not).
Init is critical process - when it dies, then whole system becomes
unusable.
Ideally init must not do anything than reap orphans/zombies, but
starting shell scripts does not require init to be expensive, so it
should be implemented too. Adding anything not related to this job to
the init will be the future source of undefined behavior and fatal
errors.

Re: Re: Vision for new platform

[aep]

On Tue, 12 Jun 2012 01:48:20 -0400, Kurt H Maier wrote:
> On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@lavabit.com wrote:
>> Tell me how you plan to handle wireless+DHCP. It can take 5+ seconds 
>> to
>> associate, and 20+ to get a lease.  That's not negotiable, it's the 
>> facts
>> of life.
>
> My intel cards all associate and pull IPs in less than ten seconds at 
> most.  I don't
> use anything but wpa_supplicant and dhcpcd.


2 seconds to assoc, 20 seconds to wait for the retarded dhcpcd "I got a 
dhcp response but let's broadcast to see if this ip is really free.".
Dhclient used to be better, but now it has the same broken idea.
Android is much faster, because like windows,  it backgrounds the stuff 
while already letting you use the network. I don't see why you'd want 
anything else.

Re: Re: Vision for new platform

[nwmcsween]

 > ...but starting shell scripts does not require init to be expensive, 
so it should be implemented too...

Please don't for almost all cases a shell script isn't needed and it 
makes things an unportable and / or a mess (debian, redhat, suse, arch, 
gentoo, LSB). What is needed is a simple configuration syntax similar to 
systemd.

Re: Re: Vision for new platform

[orc]

On Tue, 12 Jun 2012 01:27:50 -0700
nwmcsween <nwmcsween@gmail.com> wrote:

>  > ...but starting shell scripts does not require init to be
>  > expensive, 
> so it should be implemented too...
> 
> Please don't for almost all cases a shell script isn't needed and it 
> makes things an unportable and / or a mess (debian, redhat, suse,
> arch, gentoo, LSB). What is needed is a simple configuration syntax
> similar to systemd.
> 

Simple configuration syntax is a daemon's task. If we will put it into
init, we will end up like systemd, this will be systemd-lite. I think
this is a bad idea.

Re: Re: Vision for new platform

[aep]

On Tue, 12 Jun 2012 15:46:46 +0800, orc wrote:

> Daemon must not be overfeatured,
> highly configurable and
> controllable,
> not control hardware
> Init is critical process
> Ideally init must not do anything than reap orphans/zombies,
> starting shell scripts


this is the specification of sysvinit.

Re: Re: Vision for new platform

[orc]

On Tue, 12 Jun 2012 10:44:25 +0200
aep <aep@exys.org> wrote:

> On Tue, 12 Jun 2012 15:46:46 +0800, orc wrote:
> 
> > Daemon must not be overfeatured,
> > highly configurable and
> > controllable,
> > not control hardware
> > Init is critical process
> > Ideally init must not do anything than reap orphans/zombies,
> > starting shell scripts
> 
> 
> this is the specification of sysvinit.

What is your view of init boot process?

Re: Re: Vision for new platform

[aep]

On Tue, 12 Jun 2012 17:02:12 +0800, orc wrote:

> What is your view of init boot process?


did 3ac734d7f019d134fd9da7138092bf33@exys.org  Subject "Init system" 
get lost? :/
Many open questions and stuff i'd be interested in hearing opinions on 
in there.

Re: Re: Vision for new platform

[orc]

On Tue, 12 Jun 2012 12:28:07 +0200
aep <aep@exys.org> wrote:

> On Tue, 12 Jun 2012 17:02:12 +0800, orc wrote:
> 
> > What is your view of init boot process?
> 
> 
> did 3ac734d7f019d134fd9da7138092bf33@exys.org  Subject "Init system" 
> get lost? :/
> Many open questions and stuff i'd be interested in hearing opinions
> on in there.

Ah, did not noticed it.
Anyway, as you said in it, anyone who wants to control his system
beyond a vendor-provided way will have it's own hacks.
Or this holywars^Wdiscussions about 'how to start and stop daemons' will
continue forever and will not produce any working draft.

Re: Re: Vision for new platform

[Rich Felker]

On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@lavabit.com wrote:
> > Our aim should be <5 seconds (preferably <1 sec) from power on to full
> > UI. The reason I bring this up is that A LOT of the motivations for a
> > lot of the bad designs in legacy boot/init/etc. systems, including
> > systemd, is due to tolerating ultra-slow crap and then trying to make
> > it less hideous by doing it in the background, etc.
> Tell me how you plan to handle wireless+DHCP. It can take 5+ seconds to
> associate, and 20+ to get a lease.  That's not negotiable, it's the facts
> of life. dhclient defaults to 60 seconds timeout, IIRC.
> There are other devices that will not initialize without a 3-5 second pause.

Maybe I'm missing a usage case here. My view of wireless has generally
been that it's a transient connection you can't always rely on to be
up, and that it should always be handled in the background. Are there
some users who use wifi like a fixed ethernet line and expect it to be
configured and working before anything else gets started?

If the issue is just wanting applications not to fail with "no route
to host" type errors, I think this is something I want to solve even
for transient wifi. I'd like to end up with a connection manager that
(at least optionally) provides a fake route to a virtual device with
100% packet loss while the wifi is down or in the process of
associating/dhcp, so that connection attempts don't immediately fail
but keep trying until the timeout is reached when the wifi is not yet
up.

There are some issues with ip address changing, but I believe the
kernel has a feature to deal with this; I used to have something like
it setup with dialup pppd and dial-on-demand where connection attempts
that started the demand-dial initially did not have the public local
ip, but got it assigned once the connection was made.

> Anyhow, I still insist on a choice at boot time of X or text.  I could
> list numerous reasons other than speed, but would rather not.

Fair enough.

> parsing /proc/cmdline is the standard approach.

Got it.

Rich

Re: Re: Vision for new platform

[Rich Felker]

On Tue, Jun 12, 2012 at 10:20:28AM +0200, aep wrote:
> 2 seconds to assoc, 20 seconds to wait for the retarded dhcpcd "I
> got a dhcp response but let's broadcast to see if this ip is really
> free.".
> Dhclient used to be better, but now it has the same broken idea.
> Android is much faster, because like windows,  it backgrounds the
> stuff while already letting you use the network. I don't see why
> you'd want anything else.

Surely there's some way to disable this "feature", no? I've had lots
of frustration both with delays after apparently getting the lease,
and with failure to ever get any response (presumably because dhclient
is sending requests slightly different from the form some
windows-centric dhcpd wants..?)

Rich

Re: Re: Vision for new platform

[Isaac Dunham]

On Tue, 12 Jun 2012 01:48:20 -0400
Kurt H Maier <khm-lists@intma.in> wrote:

> On Mon, Jun 11, 2012 at 10:37:38PM -0700, idunham@lavabit.com wrote:
> > Tell me how you plan to handle wireless+DHCP. It can take 5+
I should note that "can" means 
"One of the worst cases".
> > seconds to associate, and 20+ to get a lease.  That's not
> > negotiable, it's the facts of life.
> 
> For the record, this isn't a problem on all hardware.  My intel cards
> all associate and pull IPs in less than ten seconds at most.  I don't
> use anything but wpa_supplicant and dhcpcd.
wpa_supplicant & dhclient.

Also, I'm dealing with very marginal connections (campus wireless on a
university farm, and Windows takes a minute to associate then still has
no internet...).
So if you have a connection manager that you want tested, I'm sure I
could give it a hard case... 

As far as ephemeral wifi goes, it's just annoying for me. I'm aware of
folks who use wireless for servers, though that's asking for trouble.

Isaac Dunham