[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 May 2012 21:06:20 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Vision for new platform
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
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.
