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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.