The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Tag: linux

Debian’s init Options

Posted in linux by Adam
Posted on

A look at the choice that Debian faces in choosing a new init system and process.

The Debian Project will choose a new default init system for its next major release (codename Jessie). The debate details (Debian Wiki: Debates: initsystem) include the following proposals:

  1. sysvinit (status quo)
  2. systemd
  3. upstart
  4. openrc
  5. One of the above for Linux, other(s) on non-Linux
  6. Multiple on Linux, at least one for every other kernel

The chief goal in switching? Bring modern boot functionality (speed and lower resource use). Others include lowering the bar for packaging and maintenance, and taking advantage of newer kernel features.

The matter of choosing an init system mainly deals with the amount of work and amount of benefit available. Unfortunately, some aspects of this debate must focus on other things.

The main contenders, systemd and upstart, both have at least one strike against them:

  • systemd looks technologically superior, but that superiority makes it a non-option for at least some non-Linux kernels (owing to using Linux-specific features), and support for other kernels would require much effort. It also takes a different approach to being pid 1, namely rolling in some functionality that has long been outside of init‘s domain.
  • upstart can be supported more readily, but similar if slightly less effort would be required for non-Linux. Worse, Ubuntu’s stewardship of upstart hampers it with the Canonical Contributor License Agreement problem.

A Contributor License Agreement basically states that by signing it, you grant rights of your contributions to the project maintainer. But the Canonical CLA goes a step beyond, in claiming for Canonical the right to relicense the contributions in a non-free manner.

In the Free/Open Source world that makes it as attractive as poison ivy. Also important, some who contribute as part of their work may actively be barred from participation. A company that sees benefit in open source will probably see hostility in their employee’s work being tied into a CLA of this sort (or any sort).

It all adds up to one difficult decision. The fact that both major contenders do not reduce Debian’s workload means the decision will boil down to technical merits. That makes systemd more likely.

What of non-Linux, then? openrc or sticking with sysvinit both seem plausible. Debian likely will not abandon their work with other kernels, so they will likely bite their tongues. Debian will put up with the extra work of dual systems for now. That will also mean that their Linux decision will remain a technical hybrid for the time being.

But not forever. Post-Jessie, I expect Debian will re-evaluate and hopefully find a more useful option to shed some of the extra weight they will take on in the short-term, whether that means configuration conversion tools, or something else.

The main reason that upstart seems unlikely, Ubuntu and Canonical never took the time to lead the way on non-Linux and while some Debian packages might have easier times adopting upstart configurations, the feature set of systemd seems to be a bit more powerful.

Canonical’s Place

Posted in linux by Adam
Posted on

A look at Canonical and Ubuntu and the future of UI on Linux.

Canonical: the main commercial force behind the Ubuntu Linux Operating System. Lately some bad blood flowed in the greater free/open source community over decisions and directions in Ubuntu; these decisions fell from the sky like bombs, in that the larger community received no communiques indicating the missions or their timing.

Mir fell out of the clear blue just recently. The project aims to replace the X Window System, one of the longest running projects and biggest workhorses of desktop UNIX systems. The age and legacy support of X mean some of its design blocks progress for free desktops and other free computing devices.

But Wayland already staked their claim to be the replacement. A lot of positive effort continues to go into Wayland and supporting it on existing Linux applications. The existing contributors wear boots with the mud of X encrusted on them. The community knows the project by name, much like the Compiz put X compositing on the tip of our tongues some years back.

This development comes as one of several incidents in which Canonical failed to work with the community, or at least clue the community into its plans. The inclusion of Ubuntu Shopping Lens, searching commercial websites directly from Ubuntu raised the question of Ubuntu’s commitment to privacy. Ubuntu One, a cloud storage service among other features, raised questions about Ubuntu’s approach to markets more generally. Other projects like Unity and Upstart (the main Ubuntu UI and a replacement initialization system, respectively) made the community feel like Ubuntu decided to go it alone on key parts of their system.

Mir’s announcement again raises questions about whether Ubuntu and Canonical want to be part of the community, or a parallel entity. They once again failed to engage with the community, and instead the community finds out about the direction Ubuntu moves after the fact. But maybe Mir will be different.

The best difference to hope for: a driver specification that allows competition. If the next generation of display server for Linux keeps its driver specification short and sweet, avoiding the possibility for the proprietary drivers to become bloated messes that do too much, they truly bless us with their presence.

For too long a performant driver meant a proprietary one. That meant ceding too much control of the system to said driver. In short, it grew into letting lobbyists write the laws. A tainted system. More importantly, it meant X entrenchment. The driver worked for X and only X. Writing a replacement for X would either require being too X-like or relying solely on free drivers (missing out on performance). The latter stands as the current state for Wayland and Mir.

But if Mir (or Wayland, or both) provides new driver models that leave us with a small driver with minimal-yet-performant capability, and the rest of the code can be open, that will place the whole system on much firmer ground. We would face a day where we could write a non-X, non-Mir, non-Wayland system and still be able to fall back on proprietary drivers for their performance. It might also encourage the (partial or complete) opening of the proprietary drivers, with far less code for lawyers to worry over.

At present the prospect remains dim. But as both newcomers continue to mature (assuming that Mir gets the resources needed from Canonical), there will inevitably be compatibility layers between them, and some convergence may occur around the driver space. It remains possible that better free software can come of this. I hope it does.

Canonical ought to lead the larger community, rather than stalk it as prey. That leadership means working with the community, contributing to it where possible, and where the community and Canonical must diverge, they should diverge only to the least possible distance. That would make Mir a fork of Wayland, or maybe Wayland plus some special extensions.

But even if it couldn’t be, the least possible distance would still require some feedback to the Wayland developers. Where and why does their model fail? And why couldn’t those details come out months ago, at least when Mir started? If valid concerns exist, give them voice. As it stands, from my reading on the situation, misunderstandings brought the concerns. That’s lamentable.

We need more companies doing Linux hands-on. Canonical deserves stewardship that grows it and the software community. Times like these allow companies like Canonical to define themselves, and I hope they will learn the lesson and move forward with the community.

Open Beta for Steam on Linux

Posted in linux by Adam
Posted on

Brief look at the Steam platform as it exists on Linux as of 22 December 2012.

A welcome, if expected surprise, Valve opened up their Linux beta of their Steam gaming platform, along with the Linux version of Team Fortress 2 in time for the end of the long count of the Mayan calendar (sorry, I know everyone’s made and heard enough Mayan calendar jokes already, and I’m even late to the apocalypse, but with it being the busy-busy holiday season I didn’t have time to get by the joke store to restock).

It takes a little administrating to install if you’re not on their preferred platform of Ubuntu. On Debian it’s mostly down to version number discrepancies between Ubuntu and Debian (eg, Ubuntu might have a specialized version number for a package that’s based on Debian’s, but different). The biggest pain is that you basically have to either rely on a private repository or disable apt-based updating (typically by commenting out the repository in /etc/apt/sources.list.d/[specific list]) to avoid complaints every time their package changes.

This is okay for the short term, but will need to be fixed if they intend to support multiple distros in the long term, possibly by looser depends specifications, or maybe by working with distros to have a steam metapackage that their package can depend upon.

So I finally played some Team Fortress 2 again. I’ve played it a bit under WINE, but had stopped some time back (I believe around the time of the release of the Pyrovision update) for various reasons. This was the first time I saw the Man v. Machine game mode (or MvM/Cooperative as it might be referred). It seemed fun except for having to return and upgrade after every wave of machines had been rendered nonfunctional.

That has to be my biggest peeve about the direction Team Fortress 2 took, or any game for that matter: don’t make me weigh so many options. Do I want to spend that much time deciding what weapons I scrap and which ones I add nametags? It just gets silly, having to manage hundreds of items, or not wanting to switch classes during MvM because I bought upgrades for a different class.

Maybe it’s just the gaming generation I came from, but it used to be you got random upgrades, and you liked them, dammit!

The Steam service runs well so far, as does Team Fortress 2. It will probably take a few months before other Source games are available, and the roadmap for non-Valve games isn’t clear yet, but the first piece of the puzzle is just about there.

No discussion of Linux gaming is complete without another look at graphics drivers. In any general thread about Steam on Linux, you’ll see them brought up, with people lamenting performance, stability, and closedness of the drivers. My experience with nVidia has been decent performance with near-satisfactory stability. That is to say, I do have some stability issues with the graphics driver, including things like my virtual terminals occasionally being rendered as artifacts in X (little 10-20 pixel squares), and sometimes my browser (Iceweasel, which is GPU-accelerated) will flicker all-black while playing games.

I’d imagine the troubles are at least this bad for AMD-based graphics, as in the past I used their cards/drivers and had problems as well.

Intel graphics and drivers are probably the smoothest except for performance. I say probably, as I don’t have any direct experience there.

It is the hope of the community that Steam will push all the graphics vendors to fix their problems, but even if that happens, that’s short of the true best outcome: completely open, performant drivers.