Re: Vision for new platform

[Rich Felker <dalias@aerifal.cx>]

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