Re: Vision for new platform

[Isaac Dunham <idunham@lavabit.com>]

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.