[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 22:05:52 +0200
From: aep <aep@...s.org>
To: <musl@...ts.openwall.com>
Subject: Re: Vision for new platform
Rich,
I started a similar approach in 2011, called HereticLinux, and
antidesktop.org. An attempt to write linux userspace and ui from
scratch, after being pissed from all the FDO junk for too many years.
Then i learned during my current work that more then half of the linux
ecosystem is driven by less then a dozen megacorps, and that any vision
different then theirs is just not relevant.
Not to mention that most of the code is the way it is because a large
workforce like that can just not create anything clean by definition.
The other side of the story are scattered communities like
suckless.org, tending to isolate themselves in their religious island.
In between, there's a whole lot of nothing. Random bits of code on
random git repos by random people not cooperating due
to the lack of any common ground other then "well the shit sucked, so i
just removed networkmanager and wrote what i need in 20 lines <favorite
language>"
If you put them in one room, then they start fighting over which
language is the best, and what color the bikeshed should have. Boring.
FDO is the way it is, it's a pile of shit, but it's the only
organization that managed to combine a zillion lines of code to some
sort of consistent thing.
Even if the thing is utter crap and only targets a specific audience
(not me), it's as consistent as you can get.
So instead of trying to rebuild every single piece they fucked up (my
original over-the-line experience was when archlinux put dbus to the
default base install for basic system services), i nowadays go with the
crowd of "random code on random git repos". I wrote the 100-billionth
network thing, the 400-zillionth initsystem, etc, etc. Nothing you could
ever reuse due to the lack of an actually consistent design. Just like
99% of the junk on github.
At a different project, we started to approach the problem the other
way round and are building isolation chambers for each piece of software
(e.g. bluez) so it's shitty design doesn't affect the system too much.
The bridges between the components are well engineered from senior
system designers, rather then from some teenager who thinks xmlrpc is
the next cool thing to put in a cpu scheduler.
However, this is a commercial activity, and i don't see any FOSS
project for that to appear out of the blue any time soon. If it would,
it'd certainly help. But working on the 101-billionth network manager
just isn't very interesting.
I will always prefer my 500 line hack over someone elses 500 line hack.
Creating new, modern building blocks that reduce my 500 lines to 10,
because someone did all the hard work for me, now that would be really
cool.
On the note of your (technically correct) set of standards: Instead of
enforcing a specific view which eventually turns into a defunct religion
because the views are outdated, i prefer making generic mission
statements and handpick smart people.
So long.
Arvid
On Thu, 17 May 2012 21:06:20 -0400, Rich Felker wrote:
> 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.
