My only experience with maemo comes from my old n800. I have to say I wasn't a big fan. The hardware had some nice features but the software interface was not well suited to touch.
OLPC's sugar is an interesting one. That is genuinely different (if perhaps not unique) and is highly targeting their realistic audience (unlike GS's absurd personas).I tried sugar a few years ago and had some issues with it but, overall, that seemed a genuine advance in thinking. I also liked the old moblin interface (back when it was based on clutter and gtk). They were using categories at the top and interesting symbolic icons, along with developing their own toolkit (mx). If you haven't tried it you might be surprised (it was always buggy, though).
The problems I had in mind with Gnome/KDE/Enlightenment/Unity/etc is their completeness. You HAVE to have graphical sysadmin tools (even if not intended for enterprise) b/c problems will occur and clis, as they are generally made now, are just not discoverable (a few exceptions are fish and final term, along with an older project from Colin Waters that built a shell that made heavy use of python instead of bash and had significant graphical capabilities---those projects are all pointing the way to the future of graphical clis and the ideas really need to be brought to fruition).
I haven't played with metro as much. My biggest concern is the "root-less" aspect of moving around. I believe you need a root to move from. A "homescreen" is a great way to act as a launchpad to activities. Eventually I'd love to move away from even that, but, for now, the rootless aspect of metro bugs me. To be clear, when I say rootless I am referring to the homescreen being something that you freely move side to side (I'm not a big fan of side-to-side screen movement b/c it leaves you disoriented and without a fast way to return to a specific place) without a SINGLE frame that acts as HOME. Rather it is home extended across a navigable strip of uncertain length.
That nit aside, metro is incredibly interesting and I think it could be pointing a way forward.
OSX works well, but they've really stagnated over the last five or so years. Expose was a really nice idea, as was quicksilver (not apple's invention, but still developed FOR osx) but other than those I struggle to think of very useful, and unique, ui elements.
Looking at number of distros is less useful than percentage of users per distro, imho. I don't think debian itself has a massive user base (smaller than ubuntu, suse, fedora, mint, maybe even mageia, afaict), so we need to look more towards ubuntu. I'm not too worried about ubuntu since I don't think they'll be a force for much longer. Their move to unity, and worse, mir, has caused brought about serious problems with the spins. I think those distros will increasingly ask the question "is using ubuntu as our upstream the best choice?" I think you'll see some movement away from ubuntu/debian and towards, the hopefully accepted, new fedora ring scheme. That is basically designed to act as platform for builders. Along with them you have the excellent suse studio service and obs (the later of which fedora MIGHT be moving to as well).The best technology doesn't always win. I'd like to see wider systemd adoption, but for the time being there are compelling reasons for Debian to not make the switch, and for the time being Ubuntu continues to stand behind Upstart, and as I've already mentioned in an earlier post, over 60% of the distributions listed on distrowatch.com are either Debian or Ubuntu based. In the future, all of this can of course change. The Debian project might decide that Debian misses out on too much functionality when not using systemd and this can lead to an upsurge in interest in switching to systemd, or Canonical might decide that continued Upstart development does not provide a sufficient return on their investment and that continued development of systemd compatibility layers is just not worth the effort when a switch to systemd would eliminate the need for these layers. But those are just two speculative scenarios. Right now, it does not appear that either project is going to be switching to systemd.
That was mostly speculation backed by hope, but I do think it is a very possible, and reasonable, path forward that would also go a long ways towards making the linux ecosystem both more robust (by having more standard, flexible, well designed components) and a better target for proprietary development.
You could have started with something like puppy. That's been designed to load completely into memory (with a gui, but you could always strip out the gui). I would be willing to bet you could work from debian to puppy without a great deal of trouble, but I haven't actually tried itNot too long ago I got it into my head that I wanted a CLI-only OS in a 512MB volume to handle boot management and do system recovery without a live USB. I started with Debian, as that's what I was most familiar with, but the standard installation image failed to create an install that fit. Next, I tried Arch Linux and ended up having to delete the localization files, the man pages, and mount the package cache in tmpfs in order to get a useable system without sacrificing useful tools like procps. Then I tried Slackware and got a fully useable system with all of the nice desired tools, with no hacking, in about half the space. That, to me, is a sign of fundamental philosophical differences that have real, practical consequences*. There are many projects that I feel do not bring anything significantly new or different to the table, but I feel that the major meta-distros all have something unique and worthwhile about them. As for specialty projects like ClearOS and BackTrack / Kali: sure, any meta-distro can do what they do, but sometimes it's nice to just get something that can perform such a specialized purpose with minimal hacking.
*The philosophical differences that I learned about from that experiment is that Arch Linux's philosophical focus on the bleeding edge has caused the project to make sacrifices with other core philosophies like simplicity and minimalism, whereas Slackware, which values practicality over rapid technology adoption, has not had to sacrifice its own simplicity and minimalism philosophies.
The fedora ring system I was talking about would've been hugely helpful to you. Ring 0, provides the BARE minimum for a bootable system (https://lists.fedoraproject.org/pipe...ly/186323.html).
So, the issue doesn't seem insoluable, but needs a robust enough design that it can accomodate the VAST majority (as I recall, fedora.next was even intended to be a base for embedded systems, eventually).
I'm mentioning fedora b/c that's what I'm most familiar with, and they have the most money behind them to actually enact these projects, along with people who are hugely passionate about open source and not hindered by someone like Shuttleworth.
FDO is a great example. It is hard, but it can be done. Moving to systemd (or at least supporting their api) ALONE goes so far to help matters that I wonder if that is at least in the back of their minds.Yes, you are right about consensus reached through deliberation. The XDG/Portland/freedesktop.org standards, for example, required both GNOME and KDE developers to make compromises in the name of interoperability. But deliberations like that are kinda an exception. Normally, it is really hard to "force" consensus. You need various stakeholders to compromise, and the standard will fail if too many of them do not make the necessary compromises. I think it is more likely for Debian to switch to systemd, for example, out of necessity than as a voluntary compromise in the name of interoperability.
Packaging is the area with, perhaps, the most duplication of effort. Each distro shouldn't have to repackage every damn thing. That's a massive waste of resources (if you can package apps, you can/do program), and this problem, as you note, isn't just for proprietary software. The fact that there are at least two (I'd guess many more) glibcs being packaged for every release is insane. Distros could be so much more reliable, and be able to focus on what they really want if they relied on some Common Base.Well, packaging is traditionally the responsibility of each distro and its packagers, not of upstream projects. The reason things have turned out that way is because for the longest time, the proprietary software vendors shunned free operating systems, so as a result the GNU project, the *BSD projects, and the Linux ecosystem developed a very rich library of free and open software that provided reasonable alternatives to the proprietary software. So packaging for a specific distro was a task best handled by the distro in question. But then proprietary software vendors start expressing an interest, and the established way of having the distros handle their own packaging is no longer an option because the source code is not available, and in that model it's the upstream vendors themselves who end up having to package for the various distros. See, it's a manageable problem as long as the distros have access to the source code. Then the distros can just say, "Well, 'foo' works on Ubuntu, but it takes us extra effort to package 'foo' for our distro because we're not completely compatible with Ubuntu so we have to solve some problems in order to get 'foo' to run on our system. Is it really worth the extra effort, or should we instead focus on removing the differences between our distro and Ubuntu so that it's easier to get programs like 'foo' running on our distro with less effort?" And they can then decide if their differences are really that important or not, because they're the ones who are having to pay the price of incompatibility. But when it's upstream that has to do the packaging, then it's not the distros' problem anymore, so the distros are not as motivated to remove the differences anymore, either. But I'm a supporter of free and open source software, and I try to avoid using proprietary software as much as possible, so to me the only interest in making it easier for proprietary software vendors to make software for Linux-based OS'es is in that it might bring greater attention to the ecosystem at large and hence lead to the improvement of the free and open software as well. So I'm in favor of seeing more proprietary software running on free OS'es, but it's not as important for me given my priorities, and I don't like the idea of compromises to free OS'es that mainly benefit proprietary vendors.
Yes, I agree that there is currently enough for marketing people to get excited about...and they do. There are plenty of companies that cater to enterprise that spend big marketing dollars (don't forget that IBM has just pledged to spend $1 000 000 000 over the next decade on linux). Then you have something like Tivo, or roku, which are linux based, and, of course, android, but there are many others. If we're talking about DE's, however, I am simply not convinced any are quite ready yet.The main reason I am still kinda hung up on marketing is because I think Linux-based and *BSD OS'es already have so much to offer to the world's computer users. I think that there is already so much here, there is definitely enough material for marketing experts to sink their teeth into if there was financial incentive for them to do so.
I do think that Valve's attention to a Linux base, and the upcomming Steam OS, are doing a heck of a lot of the marketing that I'm hoping for. Google Chromebooks benefit from marketing. Presumably Intel's Tizen laptops will be backed with marketing efforts from Intel as well. All of this kind of marketing raises user awareness for Linux-based OS'es in general, and projects like Debian who rely on no budget and a tiny team of volunteers for their marketing will end up benefiting from this as well.
So part of the reason why I keep coming back to marketing is because I think it's important, part of the reason is because I think we already have so much that is worth marketing, and finally part of the reason is because I see that marketing coming our way already. (And that's good news!) But it's as you say, otherwise we largely agree. There's plenty of room for improvement across the board, and I don't think that efforts in one area, like marketing, are mutually exclusive with efforts in another area, like continued efforts at standardization.