Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 18:25:23 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Vision for new platform

On Mon, May 21, 2012 at 11:51:54PM +0200, aep wrote:
> >This placed an unnecessary
> >burden on the desktop environment/file manager to get things right
> 
> The middleware bloatup here is just an artifact of the lack of
> policy in the lower stack, indeed.

I think the problem is that the people writing this junk see
themselves as avoiding "imposing policy" (in the form of "here's how
your mount rules will work - deal with it!"), when in reality, they
imposed the most restrictive possible policy ("you must use GNOME!").

The sooner one realizes that almost everything imposes policy, and
that imposing policy is okay as long as:

(1) you're not in a position of authority/dominance over others who
are already dependent on your software and might not be able to accept
the policy change, and

(2) the policy does not seriously restrict the usage cases for the
system, just HOW you go about doing things,

the less work is involved in putting together a working system. (Look
at how much simpler musl's dynamic linker is than glibc's, mainly
because glibc's _pretends_ to be an independent component from glibc
with its own separate API, whereas in reality they're closely coupled
and the complex, not-necessarily-stable policy between the two
imposes a lot of bloat and code complexity.)

> >That's why I think, to be viable and relevant
> 
> Yes of course. I couldn't agree more.
> All i'm trying to do is tell you, is that it's bloody hard. But
> talking to the guy who had the balls to rebuild a libc from scratch,
> it's possible you might just be able to pull it of.

The biggest ingredient in pulling it off is having 1-4 people with the
determination to do it and a common (this condition is trivially
satisfied if it's just one) vision for how it should be done. That's
why I went fishing for people with the vision... :)

With that said, in hindsight I think libc is one of the hardest
possible things I could have set out to replace. Most individual
components are simple, but absolutely EVERYTHING depends on it, so in
order for things to work, EVERY detail needs to meet the specification
exactly (and often, also needs to meet unspecified requirements that
applications expect).

On the other hand, building the stuff we're talking about now does not
involve meeting the needs of any existant applications. The set of
existing "stuff" it needs to work with is not all current software,
but rather all possible (or at least all "important") hardware
configurations (and for network, VPN configurations). I'm not sure if
that's easier or harder in the grand scheme of things, but in terms of
getting it working for a particular device and user, it's much easier.

> Just put the bar a bit lower. Targeting existing desktop users isn't
> all that desirable. They're perfectly happy with the UI's that
> canonical provides for them. And it's a good thing these people like
> their universe and everything,

Are you sure? I guess there are various shades of "desktop". If I used
a quad-core 3Ghz whatever-the-latest-and-greatest-is desktop machine,
I'd probably be content with just using GNOME. (At least until I got
fed up with its treating me like an idiot...) But for laptops and
especially netbooks, DE bloat leaves your system stuttering, swapping,
and draining the battery much faster than it should.

Aside from some interface considerations (mainly screen size and touch
vs mouse/trackpad) I think a lot of the basic system component
requirements are the same for "desktop" and "mobile" platforms, and
anything in between. Especially the stuff handled by "dbus hell" in
the FDO regime now (network config, removable media, bluetooth, ...).
On the other hand, things like file managers are more different, and
might be a case where you should have completely separate applications
for each type of system. (And if the system stuff is not needlessly
coupled with this sort of app level stuff, you can mix and match them
with no problem.)

Rich

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.