Interesting read
|
| Author | Content |
|---|---|
| SidHymes Dec 01, 2008 5:05 PM EDT |
While no one would dispute that Linux is a work in process, the same could certainly be said for Windows (any version) as well as for the Mac or any other operating system. I would argue that Linux is not "broken" but rather continues to evolve. That said, the author raises some valid points in the context of Linux becoming a "mainstream" product: consistency is an important key to acceptance. It would be nice if each distribution used the same file structure and locations for the basic files. Is it critical? Probably not for the current Linux crowd but for acceptance in a large organization, ease of administration is a major selling point. |
| Sander_Marechal Dec 01, 2008 7:33 PM EDT |
You're kidding right? A few specialty distros excepted they already do this. It's called the FHS or Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ Linux distros are already pretty consistent. It may not appear so to Windows refugees, but to us it makes sense. Where distros are not consistent they usually have a good reason for not doing so. The points that the article points out are in reality not a problem. 1) Package management: Not really a problem. FOSS applications go in the main repository. See to it that you get packages for e.g. Debian and Fedora and from there you'll spread to the other distros. Closed source applications can maintain packages for the two/three biggest distros themselves if they want and provide static packages for everyone else. There are also a variety of distro-agnostic packaging formats to choose from, such as autopackage. 2) Configuration files: Not a problem. Text files in /etc rule. See "The Art of Unix Programing, Chapter 5: Textuality": http://www.faqs.org/docs/artu/textualitychapter.html 3) Kernel Application Binary Interfaces: This point makes no sense. The userland API is extremely stable and has none of the issues that the author points out. FUSE has nothing to do with that. The author has probably heard something about the kernel module and driver API/ABI which does change quite rapidly. There is a very good reason *not* to make this stable. See the Linux kernel source code: http://www.mjmwired.net/kernel/Documentation/stable_api_nons... 4) Native File Versioning: Bad idea. It's a nice thing to have on some occasions but usually it causes more problems than it solves. Ask any admin that used OpenVMS systems. Can be implemented using a specialty filesystem though, but you don't want this "across the board" so to speak. 5) Audio Application Programming Interfaces: API diversity is a pain, yes. But you do not solve it by moving it into the kernel. That's just a silly idea. 6) Graphical User Interface: This part makes *no* sense at all. Does the author even understand what a kernel is? I get the feeling that he doesn't. All GUI is userland. 7) Integration Of X11 With Apps: This already exists and has for a long time. In Linux, signals are used to tell applications to do certain things, like shutting down nicely, possibly while saving state. Also, GNOME has the gnome-session-daemon which all GNOME applications use. I'm pretty sure that KDE has something similar. 8) Commercially Hosted Backup And Restore: Excuse me? There's a ton of commercial offerings that do remote Linux backup. In short: The author of the article doesn't know what he's talking about. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!