Language Selection

English French German Italian Portuguese Spanish

Consumer hardware shipping too many Linuxes by default

Filed under
Linux

At the top of my head now, Linux is hitting the mainstream desktop market, in many variants:

  1. Xandros, on the ever popular Asus EeePC’s

  2. Foresight Linux, on the new Shuttle KPC’s (USD$199), which are basically small form-factor desktops
  3. Fedora, a modified variant anyway, running on the OLPC’s
  4. gOS, a variant of Ubuntu, running on the gPC’s
  5. Maemo, via scratchbox, on the Nokia n-series handhelds (n770, n800, n810, and presumably more in the future)
  6. Ubuntu shipping on some Dell laptops, in select regions

I’m sure I’ve missed out some really amazing devices. But that’s not the point. Do you see a problem with the above?

Xandros, gOS, Ubuntu and Maemo run DPKG, using APT/DEB’s for package management. Fedora, uses RPM. Foresight uses their own Conary based system. OK, lets scratch the package manager woes, now noting that they’re all different. Let’s focus on the desktop environment.

Xandros is some form of KDE, locked down on the Asus. Foresight presumably ships with GNOME by default, as do the Ubuntu on Dell machines. The OLPC ships with Sugar (granted, its market is specific). gOS ships with XFce. Maemo uses GTK, but is remarkably different from a regular GNOME desktop. So now we’ve got different desktop environments too.

Should I then go into package managers? Or down to the nitty gritty, where the init scripts are in a different location? Or that they all use a different method to connect to a wireless network?

So what am I getting at? Complexity.

More here




More in Tux Machines

NHS open-source Spine 2 platform to go live next week

Last year, the NHS said open source would be a key feature of the new approach to healthcare IT. It hopes embracing open source will both cut the upfront costs of implementing new IT systems and take advantage of using the best brains from different areas of healthcare to develop collaborative solutions. Meyer said the Spine switchover team has “picked up the gauntlet around open-source software”. The HSCIC and BJSS have collaborated to build the core services of Spine 2, such as electronic prescriptions and care records, “in a series of iterative developments”. Read more

What the Linux Foundation Does for Linux

Jim Zemlin, the executive director of the Linux Foundation, talks about Linux a lot. During his keynote at the LinuxCon USA event here, Zemlin noted that it's often difficult for him to come up with new material for talking about the state of Linux at this point. Every year at LinuxCon, Zemlin delivers his State of Linux address, but this time he took a different approach. Zemlin detailed what he actually does and how the Linux Foundation works to advance the state of Linux. Fundamentally it's all about enabling the open source collaboration model for software development. "We are seeing a shift now where the majority of code in any product or service is going to be open source," Zemlin said. Zemlin added that open source is the new Pareto Principle for software development, where 80 percent of software code is open source. The nature of collaborative development itself has changed in recent years. For years the software collaboration was achieved mostly through standards organizations. Read more

Arch-based Linux distro KaOS 2014.08 is here with KDE 4.14.0

The Linux desktop community has reached a sad state. Ubuntu 14.04 was a disappointing release and Fedora is taking way too long between releases. Hell, OpenSUSE is an overall disaster. It is hard to recommend any Linux-based operating system beyond Mint. Even the popular KDE plasma environment and its associated programs are in a transition phase, moving from 4.x to 5.x. As exciting as KDE 5 may be, it is still not ready for prime-time; it is recommended to stay with 4 for now. Read more

diff -u: What's New in Kernel Development

One problem with Linux has been its implementation of system calls. As Andy Lutomirski pointed out recently, it's very messy. Even identifying which system calls were implemented for which architectures, he said, was very difficult, as was identifying the mapping between a call's name and its number, and mapping between call argument registers and system call arguments. Some user programs like strace and glibc needed to know this sort of information, but their way of gathering it together—although well accomplished—was very messy too. Read more