2008年12月3日星期三
Fixing Linux: What's Broken And What To Do About It zz
Despite the fact that it's been around since 1991, Linux remains a work in progress. It's not perfect, nor does anyone pretend it is. The places where it needs the most immediate improvement are also a matter of debate: what's crucially important to some is only marginally important to others.
Still, there's no question that there are key areas where Linux is lacking -- not just missing individual features, but things that are actively dysfunctional and which need immediate attention. I'm going to run down several major areas where Linux, as an operating system and as a platform, needs work. linux缺乏个性。
The software that goes into a Linux distribution is dealt with in chunks called "packages" -- whole applications, support libraries for apps, programmer's tools, and so on. Firefox and OpenOffice.org, for instance, are present in most every Linux distribution's software repository as package sets.
Package Management
The way packages are managed within any individual distribution is entirely up to the maintainers of that distribution. Red Hat (NYSE: RHT) uses its own RPM system, the Debian distributions have their own .DEB format; and so on. Within the context of any one distribution, this isn't a problem: if you're using only Red Hat or Debian, odds are you obtain the software you need from that distribution's repository and are done with it.
This is one of the many fragmentation problems that makes it difficult for commercial software vendors to offer their products for Linux. No one package format will do the trick across distributions -- not without hassle, anyway.
To that end, potential program vendors have three choices: 1) devote time and effort -- and money -- to ensuring that their program installs, runs, and stays cohesive on a variety of distributions (maybe just Red Hat, Ubuntu, and SUSE to keep things simple); 2) make their programs available in a given distro's repositories; or 3) provide source-code packages so that the user can compile the code on any target platform. 解决包管理有三种方法：1）投入时间、精力和金钱，保证程序可以在不同发行版本安装、运行和驻留。2）使程序出现在给定发行版本的repository中。3）提供原代码级程序，使用户可以自己编译。
Option #3 is pretty much out of the question for any proprietary software vendor. #1 multiplies the amount of work involved to get any given program out the door -- not to a degree that makes it wholly unfeasible, but it does add more work. That leaves #2, which has the advantage of making applications immediately available to the user of any given distribution, and cuts down on the amount of work needed by an end user to get something installed.第三种选择对于专利软件商是不可能的。选择一使一款软件的出笼的工作量几倍化，虽然不至于完全不可行，但是增加很多工作。选择2使某一发行版本的用户可以立刻得到该软件，减少了终端用户为了使用一款软件而付出的努力。
Because the demand for commercial apps on Linux is relatively slender right now, the problem isn't as pronounced: most people just get their offerings from their local repository. In the long run, though, if commercial apps take root on Linux, it will become that much bigger an obstacle to making Linux a platform for same, especially where downloading apps freely from the Web is concerned.因为商业软件在linux上的需求还比较少，这个问题还不是太突出。大多数用户都从本地repository取得软件。从长远来看，如果商业应用要扎根linux，这个问题将更加突出。
One thing that might help is a kind of meta-package format: a file which, when downloaded, is run by a client native to the given distribution. The client then goes to the software repositories for the program maker and obtains all the right packages to make that program run on that particular machine. The folks at BitRock have something vaguely like this, where you can package a given open source application in such a way that it will run natively across multiple platforms, Linux included.一种解决方式是元包格式，它是一个文件，下载后被给定发行版本原生客户运行。（这一段不能很好的理解） Another major way this is being addressed is through the Linux Standards Base. In order to be LSB-compliant, a Linux distribution must either use Red Hat's RPM natively or have support for RPM. Given that the most popular distribution out there right now is Ubuntu -- a Debian-derived distribution that doesn't have much support for RPM -- there's been criticism that the LSB is "too Red Hat-centric" for this to work.
Configuration Files Any given Linux distribution is an agglomeration of components from thousands of different programmers, projects, and architectural initiatives. To that end, there's little or no centralized configuration: everything in the system is controlled through a welter of files, and there's no guarantee that the syntax of any one configuration file will apply to any other.各种配置文件的语法不同。 The problem is not as pronounced if you limit your exposure to only a few files and follow their internal formatting, but that's not a sustainable solution. A lot of this is due to retention of compatibility with legacy UNIX applications. One of the worst offenders has been sendmail, whose configuration files traditionally reached new lows of complexity and obscurity.配置文件语法多样性主要是因为unix的遗留。最典型的就是sendmail，他的配置文件复杂又晦涩。 There needs to be a consistent -- and whenever possible, self-documenting -- configuration system throughout, from the kernel to userland tools and user applications. Aside from making it easier for the user (and the programmer) to deal with, it might also simplify central administration issues.需要一个连续的、如果需要自己文档话的配置系统，从内核到用户态的工具及用户程序。同时也减轻了系统管理员的工作量。 Dictating something like that by fiat is probably impossible; a better approach would be to popularize the use of a toolset that makes it easy for applications to have a unified configuration approach. The GNOME project's Gconf is a good example of this sort of thing; even if the current iteration is intended for user preferences rather than system-wide configuration options, it's still a good real-world example for how to create such a thing.Gconf这个项目做了这方面的努力，但主要是在用户preference上。
Kernel Application Binary Interfaces（ABI）
If there is one complaint that comes up more often than any other about developing for Linux, it is the way the kernel application binary interfaces are a moving target.
The Linux kernel has been designed from the perspective that what's inside the kernel can change, but what's available to user applications through the ABIs cannot and must not break. The problem is not only philosophical, but also practical: the sheer breadth of kernel interfaces means it's entirely possible for something to break (or "regress") in a way that might not even show up in a fairly rigorous code review.
To that end, when something does break, it creates two problems: it means the exact source of the problem is sometimes a matter of argument (i.e., is this a kernel issue or a user-application issue?), and time and effort is lost in the process of fixing it.
There are a few ways to work around the problem in the short term. One of the most immediate and promising workarounds for certain projects is FUSE -- short for "Filesystem in Userspace" -- which allows file systems, normally the domain of the kernel, to be set up in the same space where user applications run. In the long run, though, Linux needs an ABI set that's not only stable but capable of handling long-term growth without becoming a rat's nest of potential compatibility issues.
Native File Versioning Native file versioning is another feature that can be added to Linux distributions, but does not yet exist by default. The concept is simple: an earlier iteration of a file can be produced on demand in case the current version is overwritten, damaged, or sabotaged. Windows users have this in the form of shadow copies, but no default incarnation yet exists in the standard-issue Linux file systems (e.g., ext2/3/4). It's obviously not intended as a substitute for file backups, but the ability to roll back a file to a given point in time as a default piece of functionality isn't a frivolity. It is possible to add this functionality to a Linux distribution after the fact. That said, the different projects that provide this each use a slightly different implementation: Wayback, ext3cow, copyfs, Tux3, and so on. Having a standard, "kernel-approved" methodology for versioning would provide a solid base on which to build and branch out, although a good argument can be made for providing these features as a non-kernel add-on.
I should also add that future iterations of the Linux file system (probably the forthcoming BTRFS) are intended to do all this and more -- but for now, there's no one direct solution that can serve as a starting point.
Audio Application Programming Interfaces
Look no further than Linux's implementations, plural, of audio for an example of how too many cooks can spoil the broth. The diversity of audio APIs and subsystems means that, yes, you can pick and choose one that suits your needs best -- but it also means a rat's nest of incompatibilities.
The kernel-level audio API, ALSA, is where most everything begins, but there are others -- primarily PulseAudio (used mainly to mix audio from multiple applications) and JACK (for pro-audio, low-latency settings). And then there are a slew of other audio tools for developers -- Gstreamer, PortAudio, and so on. Don Marti, at the Linux Plumber's conference in September, wrote a good summary of how conflicted and confusing the whole issue is. The quote that sums it up best: "If someone comes and says, 'I want to write an audio application. Which API should I use?' I don't have a good answer." (This fellow does, to some degree, but the fact that the whole jungle exists at all is depressing.)
In short, the audio API issue affects programmers more than end users. That said, everything that affects programmers also affects end users in the long run. PulseAudio is probably the best general-purpose solution and has enjoyed wide adoption. But in the long run, what's needed is a single kernel-up approach to audio that does not require use-case analysis on the part of an application developer.
With the kernel, there's little if any doubt about who's in charge: Linus and the kernel developers. With the Linux desktop -- maybe better to say free and open source software, or FOSS, desktop -- it's far more anarchic.
Before I go any further, let me define my terms. "Desktop" doesn't just refer to "whatever GUI conveniences make Linux/FOSS easier for non-technical users," but rather a graphical user interface that makes using and managing the system all the easier no matter what your level of technical expertise. This is not a matter of integrating the GUI completely with the system; no one is foolish enough to advocate that. Part of the problem is that kernel and desktop development in Linux took place in a highly parallelized fashion, and it was a one-way street to boot. There was no guarantee the kernel developers would implement features useful to desktop developers, but desktop devs had to hew to whatever happened in the kernel if it affected them. To that end, what's needed is a single steering committee for all GUIs that work on Linux, so that whatever GUIs are created -- be they GNOME, KDE, or not-yet-invented -- will have a consistency of implementation on the backend, and make it possible to have tight integration of features with the kernel, a la BeOS. The kernel would publish a generic series of hooks that a GUI could make use of, and the GUI would be free to represent them to the user in any number of ways. Another important thing Linux needs is clearer guidelines for how to implement default behaviors on the desktop, which requires people with UI design experience to make decisions that have lasting weight. This isn't about "dumbing down" the UI: what's often needed is not simpler controls, but better default handling of those controls so that the user does not have to make endless adjustments to achieve something comfortable.
Integration Of X11 With Apps
Most people who have used Linux for some time have probably encountered this problem: an X11 application, or the whole of X11 itself, freezes, and the only way to get things back is to kill and restart X11. The good news: it isn't hard to do that. The bad news: killing X11 means every other X11 application, problematic or not, dies along with it.
What would be useful is the option to have applications running under X killed along with it, so that if X needs to be killed and restarted, you don't wind up losing your entire user session. Failing this, it would also be useful to have a window-manager API that allows for the easy storing and resuming of a session in the event of a crash -- something that does happen on an app-by-app basis (Firefox, for instance, does this), but which would be useful to have available in a global implementation.
Commercially Hosted Backup And Restore If Linux will continue to draw regular PC users away from Windows, it'll need to have many of the same features as Windows. That includes for-pay network services that require Linux clients, such as remote backup.
A Linux user who wants to perform offsite backups generally has to resort to using a native Linux application (such as the Simple Backup Suite in Ubuntu) to back up to a remote server that isn't specifically for data protection. There's no shortage of Linux backup clients that can speak to a remote server, like the Simple Backup Suite that's available in Ubuntu, but again, integration with a commercial backup provider for regular users is what's missing.
One very likely possibility is that as things become that much less platform-centric, the idea of needing a platform-specific client to perform robust backups (not just data, but whole system states) may become as quaint as, say, only being able to access specific Web sites with specific types of Web browsers. The other, more likely possibility, is that full-state backup services dedicated to supporting Linux clients will step up.
Conclusions
Most of what's wrong with Linux isn't fatal: if it was, Linux would scarcely have achieved the degree of adoption it now enjoys (with the general exception of consumer computing). But there's little question these problems need to be fixed, and that doing so may require some challenges to the conventional Linux way of doing things and defending the results.
订阅 博文 [Atom]