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.