Date: Thu, 17 May 2012 23:26:11 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Vision for new platform On Thu, May 17, 2012 at 08:11:43PM -0700, Isaac Dunham wrote: > 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. :) The functional thing it corresponds to, sadly, is probably Windows... > > 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. > > 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? 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). > > 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. Well if we design and implement it rather than just wishing for it, it can happen. > I doubt that anyone else had the intent of making something *un*stable, No, but it happens from copying (and cargo-culting) bad examples. > and software *always* has bugs (unless you call them all features). > Not that it's a bad goal, just that it may not happen. The vast majority of problems like this do not come from bugs like typos in the source, signedness mismatches, off-by-one logic errors, etc. They come from fundamentally wrong assumptions about the behavior of interfaces used, ignoring the possibility of failure, not considering concurrency, etc. I.e. they are major design bugs and systemic implementation errors, not "innocent" bugs. > > - no java-style namespaces (the ones that look like backwards dns) > That's actually what Java used (hence the com.sun namespace). That's why I called it java-style. Seeing it in software almost surely means the software was designed by people who learned on Java, meaning they're almost surely unqualified to write working code, much less efficient code... > 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) I have no problem with using Python to implement local scripts or even standalone applications. What I have a problem with is using it to implement core system components that everything else depends on. > > 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.. 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.