From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/840 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Vision for new platform Date: Thu, 17 May 2012 20:11:43 -0700 Message-ID: <20120517201143.19c7bee7@newbook> References: <20120518010620.GW163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1337310721 17921 80.91.229.3 (18 May 2012 03:12:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 May 2012 03:12:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-841-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 18 05:12:00 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SVDbj-0008Ga-TG for gllmg-musl@plane.gmane.org; Fri, 18 May 2012 05:12:00 +0200 Original-Received: (qmail 22321 invoked by uid 550); 18 May 2012 03:11:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22313 invoked from network); 18 May 2012 03:11:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=sRtxKZn/DqTI1KBQnz9fnI7aixYoICxxdLseufXC8iTXqRinRrONOvniq5pDzJ2nnKL+CLmPRIOeDgqKVbpLZ9LinWxJGw68xKARaWuFafj5If7UtneltIzMsf+/HD/5au5Ku6abG6hWjqfqPTkRX31KYmmn94VoH8xhX3nCC7k=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20120518010620.GW163@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:840 Archived-At: Rich Felker 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