[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120517201143.19c7bee7@newbook>
Date: Thu, 17 May 2012 20:11:43 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Vision for new platform
Rich Felker <dalias@...ifal.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
