Lately, we’ve all read a lot of articles about desktop Linux – so many that it’s getting hard to tell them apart. One says “Why Linux Sucks,” the next “My Success With Linux.” Even Michael Robertson of Lindows.com joined the fun with his “Why Desktop Linux Sucks, Today.” But very few people have proposed anything radical, and I believe that’s what’s needed to take GNU/Linux to the next level.
The polish that Red Hat and Mandrake have added to their consumer-grade Linux offerings have meant a lot to users like me, those who use it as their main desktop OS. Finally, these distributions are starting to look like a professional quality operating system. One of the main problems, the way I see it, is what I call “marketspace crowding.” There are so many distributions, so many flavors that are, when it really boils down to it, just semi-clones of one another with one good tool or one little tweak added or modified. The idea of roll-your-own distribution has left the market saturated with many similar distributions, and even those “in the know” don’t know how to properly choose a distribution. The solution should be to make your distribution stand out, and in order to do that, you can take advantage of the opportunity to do some things right.
So, if I had the capital and connections to make a new distribution, I’d take full advantage of the opportunity. The market doesn’t need another carbon copy of the current Linux market leaders. It needs something new, something fresh, something that really rocks the Linux community’s world. So I’m in charge of my own personal Linux distribution, DistroX, and here’s what I’m telling my staff and engineers.
Let’s start by delving right into it: let’s address some Unix-wide issues, that will make our development unique. The file system is a nightmare for a normal user. This has been covered in exhaustive detail by hundreds of articles, but if I’m going to run my own distribution, I’m going to make a sensible directory structure: /users, /apps, /system, /hardware, /downloads, /logs, /servers, /shared, and more. Then, using symlinks, we’re going to recreate the current basic layout of the standard Linux/BSD filesystem to assist developers in porting applications. For example, our system would probably include the following the symlinks:
/home -> /users
/var -> /logs
/var/www -> /system/websites/
/etc/httpd – > /servers/httpd/
/dev/hdc -> /hardware/cdrom/
/mnt -> /hardware/drives/
This will encourage new users to explore their computer, not fear it, as many do. Apple has this right – Mac OS X’s file system is human readable, and not intimidating at all. [Note: The above symlinks are just used to illustrate the mimicked filesystem, not final decisions. Please don’t comment on the actual links referenced above]
The next idea is fairly controversial, and it comes in two parts: first, our goal is not necessarily to follow LSB guidelines, nor to be compatible with other distributions. Our goal is ease. Dropping legacy support and not being dependant on RPMs will open up the doorway for my engineers to revolutionize Linux software installation. Again, this topic has been discussed in detail in the past, so I won’t get into the specifics, but a drag-and-drop software install/uninstall is clearly the preferred method by desktop users. I barely know hown to uninstall software on Linux past “rpm -e program” and on Windows, my control panel used to be filled with a number of programs whose uninstall failed, and in the process, wiped out that single .ini file that directed the uninstall (to get rid of them, registry tweaking was necessary). The second part of this step is to set up an actively developed software repository on the internet. Users aren’t stupid, they don’t need a hand holding front end, but they do need easy access to programs, and an online facility dedicated solely to my distribution is definitely a plus for me as a potential customer. Incidentally, I don’t know why this type of thing isn’t more popular with today’s large distributions – it would be nice if there was a single site where you could go for install packages specific to your distribution that were guaranteed to work.
In following that, a good amount of resources will be allocated to developing an online community a la Gentoo. Forums would be well maintained and cared for religiously. Help would be granted unconditionally. Contests would be held regularly and other promotional stunts to get and keep people interested. An active community means more developers, more porting, and more word-of-mouth. Conferences, training, certificatons would all be investigated. Anything we can do to make people try our distribution would be considered.
Choice. It’s what Linux and BSD offer that, to some, is the biggest draw. My developers are going to meet and agree on ONE desktop environment. Yes, we’ll include the libs for the other major one we leave out. But my distribution will not, as many large companies have, concentrate all of our resources on making one environment look nice and then include a second that pales in comparison. I’m going to remove a lot of choice from the user, because, to many, it’s more a gamble than a choice. If I customize Gnome to be unique for my distro, I don’t want people to unknowingly choose KDE. Or vice versa. If you’re an expert, and require the another DE, you can download the source and try to compile it yourself, visit our forums, or even assist us in porting it so we may offer a downloadable package customized for our distro. I’ll include one IM program (gaim), one FTP program (gFTP or Kbear), one e-mail client (Evolution), one office suite (OpenOffice.org, but also kedit and kwrite, which serve different functions). I may choose to include two or more browsers – as they are frequently used and that choice is not likely to cause confusion. I won’t list all my application choices, but the point is, I won’t include applicationss for the sake of including applications only. Only those that offer a different and distinct experience or that offer something unique will be considered for inclusion.
Installers have been a hot topic of discussion lately too – mainly because they’re all getting pretty good and now. It’s a race to who can make the one that the crowds feel make the most sense. Anaconda has come a long way and leads the pack, SuSE YAST has received praise, and Mandrake’s redesigned install is clean, fast, and easy. New breed distros like ArcLinux, LindowsOS, and Lycoris have really gotten the rapid install process down pat. I believe the perfect is somewhere in the middle – graphcal, heavy on eye candy, with few visible options but lots of “Advanced” buttons. Full control is necessary for experts, but simple steps for newbies. Some essential tools: NTFS resizing, coexisting with other Linux installs, and a configurable boot manager. I’d really like to see Linux boot on ATA RAID. When this project is more stable, we’ll incorporate that ASAP. Lastly, in the installation category, each step will have easy-to-read documentation on screen, such as ‘Which file system should I choose?’ along with recommendations – “DistroX recommends UFS file system for all desktop computers. This file system provides crash recovery/protection and has been thoroughly tested. If you intend to run your computer as a server, click here for more suggestions.” People should never get scared during an install, but I don’t want to remove all options from the install process. None of the BSD’s use graphical installs yet (though the OpenBSD project does have GOBIE under development). Many complain that installing a BSD with a DE is still one of the toughest tasks out there. Ours will be fully graphical and thoroughly tested. Public betas will solicit feedback until we’re convinced it’s as easy as a Windows install.
On the subject of installs, I’m not going to worry about “bloat.” I’m already stripping out a number of apps, so what I’m not going to worry about are libraries and system files. Even the minimal install will include every common system tool my develops can think of. We don’t want anyone, anytime, to have dependancy problems. We’ll include everything we can think of, and if we come upon and app that needs something not in the default install, we’ll include it in the install files on our application website. Dependacy problems are an issue of the ’90s – there’s no excuse for them today. On my home machine, I’ve come across this scenario: I download program A. In order to compile it, I need lib X, Y, and Z. I download them all. Library Y fails to compile because it requires B and C. I download B and have to upgrade C. But B depends on E. And E seems to be installed. 45 minutes later, I quit. On my distro this will never happen, because our install files will include everything. Hard disks are large and cheap these days. We will simply maintain: a worthwhile desktop system needs disk space. Broadband is increasingly common. Packages should include all files necessary for use.
Another thing I’m about which I’m concerned is after market add ons. Red Hat ships without mp3 support and may not be the last distro to do as such. I’ve maintained that the workaround here is to add a menu entry to the launch bar: “Install MP3 support.” The script that runs fetches the mp3 plugins, installs them, and then, after confirming successful install, removes the entry from the menu. Same with DVD plug-ins, nVidia drivers (if an nvidia card is detected), and other after-market add ons. This will allow further compliance with licenses. Perahps a “Run Once” menu should be present, or even a script that installs all the necessary after market add ons and then removes itself.
My distro would be available for download on throttled public FTP servers and also from some sort of contributor/buyer FTP servers. My contributors and paying customers can also download my apps at high speed. I don’t mind people seeding BitTorrent or anything, I just don’t want to pay for the bandwidth. Last I checked, availability was rarely the reason people did or didn’t try a distribution. On that note, my source code CDs are not available for public download either. That’s bandwidth I don’t care to pay for. Source, or what we release of our source, will be available to those that request it for postage only – I’ll GIVE it to anyone who wants it and is willing to pay for the postage – the CD’s are on me. The cost of CDs is negligible, and the cost of postage will weed out the “getting it ’cause it’s free” crowd. I don’t want to milk the developers, I just don’t want the whole world downloading 2 or 3 extra CDs by mistake. As a company, we want to be smart, we want to share, and we want developers to feel loved, but most importantly, we want to make money to stay afloat. So we need to be smart.
Defaults are very important – one thing I’ve noticed is that there are few system-wide defaults with most Linuxes. For example, click on a link in Evolution, I get Mozilla. Click on a link in gaim, I get Konqueror. Want to change that behavior? I change it in gaim. But Evolution’s default won’t change. And Mozilla always defaults to MozillaMail. There is a way around this. The way I understand it, pretty much everything on a GNU/Linux system runs commands terminal-style. Perhaps the way to get system-wide default is to have a given directory, say, /system/commands, that appears to be the equivalent of /usr/local/bin or /usr/bin – that contains the executables from the command line. Except, in our distro, the real files are kept in /system/bin. /system/commands is full of aliases. Then, when you change your default browser through our control panel – all the known browser commands – konqueror, mozilla, opera, galeon … they all change to aliases of your selected browser. Now, obviously, menu commands have to map to the hypothetical /system/bin, since we don’t want to effectively stop those programs from ever launching – just from launching via standard systems commands. This is all very complex, and would surely be an engineering feat, but until Linux/BSD as a whole is cleaned up and standardized, it’s a possible solution.
If this were reality, and I truly had a venture capitalist’s backing on this project, I should mention that I’d probably have to reconsider Linux as a whole. We’re a company first and foremost, and so our goal is to stay in business and make money. We’d have to achieve this in two ways:
a) first off, we should probably base our distribution on the FreeBSD system. FreeBSD has many drivers, boots much quicker than Linux, is very clean code, and most importantly, has a much more liberal license. The GPL provides little room for making money on software, only support (see many comments by RMS, Bruce Perrins, and Eric Raymond, as well as the history of Cygnus for more on this). In order to develop an OS and provide the right environment for it to grow, we need to be a viable commericial company. In order to do this, we must protect some of our code. The second part of this scenario, strangely, is the exact opposite.
b) we’re going to share some of our code. As much as we will borrow from other coders, we will share some of our improvements with the community. As we all know, companies that are reluctant to share source code are frequently shunned by the knowing community. We will be good open source citizens, but we will protect some of our investment. The decision to use FreeBSD may not be a popular one at first, but it would ultimately be what sets us apart from the pack. Our distribution will be based on years of proven rock solid stability fused with a modern approach to user interaction.
Now, let me be the first to say that much of what I propose here may not be technically, or more likely, financially, feasible. However, I believe that the open source community gets things done by discussing what we’d like to see and eventually, the most popular opinions make their way back to the developers and the commericial companies. Clearly, Linux and FreeBSD on servers is working and popular. Linux on the desktop has come a long way, but even companies with a novelty – Xandros and their integration into Microsoft domains, LindowsOS and their Click-N-Run, etc, still aren’t really making any noticeable dent in the desktop community. Linux can’t be scary, and all we’ve seen so far is a pretty face to the undecipherable mess underneath. If you don’t agree with me, show the filesystem layout to your mother and ask her where an application might be located. Even I couldn’t tell you for sure – /usr/bin? /usr/local/bin? /bin? ~/.appname? /opt? /etc? It’s a total guess. DistroX is going to make sense because it’s going to be built that way from the get go.
I’m of the belief that someone is going to have to do something drastic to see real change. There should be a real, distinct difference between a “packaging company” and an “operating system company”. The first step, in my mind, is to decide you’re not just going to release “YALD,” or “Yet Another Linux Distribtion.” What do you think?
About the Author:
Adam Scheinberg is a regular contributor to OSNews.com. He recently moved to Orlando, FL, where he is looking for a network administration position. He uses Mandrake Linux 9.1 as his main desktop OS.