LWN.net Weekly Edition for November 13, 2014

The Grumpy Editor's guide to surviving the systemd debate

The systemd debate appears to be one of those gifts that keeps on giving; whenever it seems that the issues are approaching resolution and things might calm down, a new flame war starts up. Most recently, this dispute is threatening to tear apart the Debian community. Your editor would like to suggest that such an outcome would be far too high a cost to pay for a disagreement over a system initialization and service management system.

In the end, it comes down to this: it just is not that important. It is just a system initialization utility. There is plenty of experience by now to show that Linux systems still work when systemd is installed; indeed, they are still even recognizable as Linux systems. The distributions that have moved to systemd have not been destroyed or rendered less useful; many would argue that they have been improved by the change. But even if systemd turns out to be a wrong turn in the end, the current level of anxiety and heat is not called for.

Some of us will remember the multi-year dispute over the devfs filesystem, which was perhaps the first serious attempt to deal with the failure of static /dev directories to deal with contemporary hardware. After numerous heated discussions, some of which made the systemd debates look calm indeed, devfs was merged into the 2.3.46 kernel. Some distributions adopted it fully, others held back. Over time, devfs turned out to not be the best of ideas, but, by then, it had worked its way deeply into the kernel. The patch set that removed devfs required 22 individual patches touching over 200 files in the kernel tree; we'll never know how much work was required to wean user space away from devfs. The removal took some time and effort, but, since we had all the code and sufficient will, we achieved it.

If systemd turns out to be an equally bad idea, it can be removed in the same manner. It is entirely possible that we'll eventually look at it the way we look at devfs — as an experiment in the wrong way to solve a problem. Or perhaps it will be seen more like sendmail: the best solution available at the time, but one that few of us wish to deal with now. However things turn out, if it becomes clear that there is a better solution than systemd available, we will be able to move to it.

Of course, it could also happen that systemd works out well and becomes just another part of our software mix.

With this in mind, your editor would like to venture forth with some humble suggestions for the people involved in the systemd debate. Starting with the systemd developers themselves: things are going for now, systemd has been adopted by most of the major distributions out there. Please try to be gracious in your success and to take into account the concerns felt by those who are not fully on board with your vision. Working harder to accommodate those who want a more loosely coupled plumbing layer — or, even better, encouraging them to join your community to make that looser coupling work better — would be a good thing. Avoiding "not our problem" responses when things break would be helpful.

And, it should be said, postings like this can easily be viewed as trolling. It should be possible to celebrate one's successes without being snide.

For those who are not systemd fans, it would be good to get away from the siege mentality that many of you seem to have adopted. This is not the final battle to save Linux from the depredations of the evil systemd empire. Nobody is forcing you to put systemd on your computers; they are simply offering you distributions using systemd that you are free to not install. This is not a conspiracy by any group to destroy Linux as we know it.

It is a group of developers with a vision for where they would like to improve Linux going forward. Linux has always moved quickly; these developers are simply continuing that tradition. The difference, arguably, is that we are long past the days of trying to catch up with other systems and are, instead, exploring new paths with little to guide us. It is natural that there will be more disagreement in this phase, and more mistakes too. Perhaps systemd is a mistake, but, if it is, we'll survive it, just like we have overcome our mistakes in the past.

It would be better if we all could assume that the systemd developers are acting in good faith to try to make a better Linux. If some of their ideas seem misguided to you, there are (at least) a couple of useful ways to respond. One is to join their community and work to push things in new directions; that is how free software works, and the systemd community seems to be reasonably inclusive. The alternative is to show a different solution that works better. Note that talking about such things tends not to impress people in this community; working code is the way to demonstrate a better idea.

For the trolls out there who seem to delight in trying to stir up systemd flame wars, we could ask you to go away but we know that's a futile request. Meanwhile, the rest of the community has, for the most part, been doing an admirable job of ignoring the inflammatory emails, comments, "songs," and more. Keep up the good work, please.

There will come a day when we will wonder what all of the fuss was about. Systemd will either be established and successful, or it will have been replaced by something better. Either way, we will be unable to comprehend why we subjected ourselves to so much stress over an init system; it couldn't possibly be as important as the battle over (say) choice in C libraries or Wayland compositors that we might be fighting at the time. If we can all relax a bit, we'll figure this one out without tearing our communities apart. We are, after all, still working on the same goal: producing the best free operating system we can. We'll never all agree on the best tactics to get to that goal, but we don't have to; it all tends to work out in the end.

Comments (330 posted)

GNOME versus Groupon

While the patent system isn't exactly popular among free-software developers, the privileges accorded by trademark law remain valuable for some free-software projects. For example, Mozilla has benefited from being able to control its brands. There remains a conflict, though, between the redistribution and modification rights that free software accords its users, and the restrictions imposed by a trademark on that software, with the dispute between Debian and Mozilla (that led Debian to rebrand Firefox as Iceweasel) as a classic example. A recent (and apparently resolved) disagreement between the GNOME Foundation and the daily-deals web site Groupon reflects how valuable trademarks can be in the open-source world, as the conflict illustrated the goodwill in the marketplace that the "GNOME" trademark enjoys.

Last May, Groupon issued a press release announcing "Gnome, a new tablet-based platform that will provide sophisticated tools to local merchants to run their businesses more effectively and understand their customers better". Groupon decided to trademark its use of the word "Gnome", variants like "G-NOME", and the phrase "GNOME BY GROUPON" in association with goods and services involving, among other uses, "computer hardware and software for processing point of sale transactions".

But, back in 2006, the GNOME Foundation had already registered a trademark on the word "GNOME" used in association with goods and services involving "downloadable computer software", "computer software development", and other related products. According to the GNOME Foundation, on a call-for-help page it posted online on November 10, efforts to communicate with Groupon about its concerns over the GNOME brand identity were made soon after Groupon's product announcement. The Foundation alleged that these talks broke down and that Groupon continued to seek the registration of additional trademarks.

The Foundation faced a deadline of December 3 to file legal paperwork starting formal opposition proceedings against some of Groupon's trademark applications. On the call-for-help page, it asked the open-source community to donate $80,000 to fund its battle: "Our counsel has advised us that we will need $80,000 to oppose the registration of the first set of 10 applications. If we are able to defend the mark without spending this amount, we will use the remaining funds to bolster and improve GNOME". At the end of the Foundation's statement, there was a link to PayPal to donate, as well as a note that "GNOME can also accept donations by check, bank/wire transfer, Flattr and Bitcoin". As of the morning of November 12, over $100,000 has been raised.

After the issue became more public, and donations started to roll in, Groupon responded by announcing its stance:

As the outcry continued, Groupon relented. A few hours after the initial announcement, Groupon declared it was no longer interested in registering trademarks on the word "Gnome": "After additional conversations with the open source community and the Gnome Foundation, we have decided to abandon our pending trademark applications for 'Gnome.' We will choose a new name for our product going forward". GNOME and Groupon released a joint statement soon after, announcing that the two organizations will be collaborating to ensure that there will be no trademark issues between them in the future:

An examination of US trademark law shows that it was likely prudent of Groupon to abandon its pursuit of these trademarks. In the US, a trademark is considered to be infringed by a similar trademark if there would be a "likelihood of confusion" caused in the marketplace by the trademarks co-existing. There are a number of different tests for "likelihood of confusion" across the different Circuits of the US court system, with considerable variety between them. An empirical study [PDF] of these tests, done by New York University law professor Barton Beebe, criticized both their lack of harmony and inconsistencies in their application by the courts. The US Supreme Court will likely clear up the confusion within the next year when it makes a ruling in a case that addresses the issue.

Until the Supreme Court makes a decision, we can turn to Beebe's study to see how this case might have played out in the courts. Beebe found that likelihood-of-confusion cases tend to turn on the following factors: the similarity of the marks; the likelihood consumers would believe, incorrectly, that the products branded with the trademarks are sold from the same organization; and bad faith on the part of the defendant. If Groupon hadn't capitulated, it would be reasonable to predict that Groupon would not fare well in a legal battle over trademarks with the GNOME Foundation.

The trademarks use the same word, disposing of the first factor in the Foundation's favor. Groupon's brand presence with the general public in the US is much stronger than GNOME's: if Groupon launched "Gnome"-branded devices and services, it would be more likely than not that an "average" consumer would assume, on first encounter, that the GNOME desktop environment was designed by Groupon. This disposes of the second factor against Groupon. While GNOME might not have been able to show bad faith (the third factor) on the part of Groupon, its strong case for likelihood-of-confusion on the first two factors would probably have been enough for the Foundation to prevail in court.

Nonetheless, this David and Goliath story could have been avoided, if Groupon had acted more ethically. Any search for the use of the word "GNOME" in connection with software would have quickly led to the GNOME project and proof of its trademark rights. Groupon must have been aware of that trademark while it decided to apply for its own marks. The fact that Groupon almost immediately caved in after the GNOME Foundation went public with the conflict is strong evidence that either Groupon did not have a case, or it was unwilling to bear the sharp criticism from the open-source community. If Groupon had acted honorably in its discussions with GNOME from the beginning, it would seem that this could have all been resolved quietly—or avoided altogether.

GNOME's call-for-help page remains online, with an update at the top indicating that the matter has been settled. This hasn't deterred GNOME's supporters from continuing to donate to the Foundation through that page, however. It remains to be seen if Groupon will indeed follow through on its commitment to rename the offending goods and services, but it would seem difficult for the company to back out now. Nevertheless, open-source enthusiasts and GNOME fans can breathe a sigh of relief: a potential threat to the name and brand of a major open-source project has been defused.

Comments (5 posted)

High-DPI displays and Linux

Your editor's laptop recently started to fall apart, to the point that some sort of action was required. Duct tape was considered as a solution; it would show that LWN is making careful use of its subscription revenues, but would also convey an impression that is, arguably, not 100% professional. The alternative was to get a new laptop; that costs money, but the idea turned out to be awfully shiny and distracting. So your editor ended up with a ThinkPad X1 Carbon. This machine has a number of nice features and a few weird quirks, but one of the more interesting options it came with is a high-DPI, 2560x1440 display. That was an ideal opportunity to investigate the state of Linux support of high-DPI screens; it turns out that, while quite a bit of progress has been made, this problem has not yet been fully solved.

There are certainly a lot of advantages to high-DPI displays (generally considered to be those with at least 200 pixels per linear inch). Text is rendered in an especially clear and readable fashion. Photos from digital cameras can be displayed at something resembling their native resolution. And, for those of us with sufficiently sharp eyes, high-DPI allows more work to be crammed onto a screen, increasing productivity. But, if the desktop environment and associated applications are not aware that a high-DPI screen is in use, the result can be unreadable text and unusable, microscopic screen elements.

High-DPI display support

So how have the Linux desktop environments responded to high-DPI displays? There appear to be two different basic approaches. The one used by GNOME and some web browsers is to hide the display resolution behind pixel scaling; in essence, the environment lies to applications, then turns each application pixel into a 2x2 array of screen pixels. It's a relatively quick solution, but, as we'll see, it leads to some unfortunate behaviors.

The alternative is to have applications deal with display-independent units (points, centimeters, inches, whatever) and hide the scaling required. KDE appears to have taken this approach. It seems to work well enough as long as applications play along, but here, too, the problem is not entirely solved.

Your editor's experiments have mostly been with GNOME, so this article will have an unavoidable bias in that direction. In GNOME, pixel scaling is managed with the inevitable gsettings registry value; to turn on 2-to-1 scaling, a command like this can be used:

    gsettings set org.gnome.desktop.interface scaling-factor 2

Setting the scaling factor back to one turns off scaling. Scaling should be enabled by default if GNOME detects a high-DPI display; otherwise a command like the above can be used. This value can also be adjusted in gnome-tweak-tool. Should you run into bugs or weirdness (like only a quarter of the screen being used), setting the scaling factor to one then back to two will often straighten them out; your editor has ended up creating a fixscaling script for just this eventuality.

Firefox implements a similar sort of pixel scaling, but it doesn't seem to figure out when to use it on its own. The solution is to go into about:config and set the layout.css.devPixelsPerPx knob to a value like two. Alternatively, one can make things work by configuring the use of 30-point fonts, but that will make a mess of a lot of web sites.

In the KDE world, there seem to be a couple of parameters to set if the desktop doesn't figure things out on its own. The "application appearance" dialog has an option to set the dots-per-inch resolution used for font rendering; setting that to a value close to your screen's pixel density (or lower; 150 seems to be a recommended value) will make text readable. The size of icons is also nicely configurable in KDE; its use of SVG icons helps to make this option work well. Obviously, one will want to make icons larger on high-DPI displays.

Difficulties

So it seems that some support for high-DPI displays is in place for Linux. But there are still a lot of nagging little details — some perhaps not so little — that pop up when using a system with such a display.

For example, what happens when one plugs an external monitor (or projector) into such a system? That display almost certainly is not also high-DPI. The techniques used to make the high-DPI screen will have the effect of turning the lower-DPI screen into an extra-low-DPI screen. In your editor's case, this problem has made the use of external monitors on the new laptop nearly impossible. The word is that this behavior is the results of limitations built deeply into the X Window System which, after all, was developed when 75dpi was a high-DPI screen. Things will be much better under Wayland, we are told, but there doesn't appear to be a lot of relief in store before then.

Pixel scaling can also cause a lot of confusion with applications that are not prepared for it. Here is an old version of gthumb (the version shipped with Fedora 20) with scaling in effect:

With scaling turned off, the result is rather more satisfying:

(It should be noted that gthumb 3.14.x handles high-DPI displays in a much better manner. Your editor will reserve comment on some of the other user interface changes made during that time, though.)

Over time your editor has found a few applications that do better with pixel scaling turned off. Happily, there is an easy way to do that on a per-application basis: simply set the GDK_SCALE environment variable to the desired scaling value.

Another problem with pixel scaling is that it can cause even the high-DPI screen to appear to have a low pixel density. As a result, for example, gnome-terminal believes it's running with 7-point fonts, something that would normally be illegibly small. The sizing is confusing, but it also makes it hard to get that perfect size: seven points is too large, but a 6-point font, being quite a bit smaller, is illegible. All of this is somewhat unfortunate, since points are supposed to be real-world physical dimensions, but that connection has been lost for now.

There is no shortage of web sites that come through badly on high-DPI displays — including this one in many cases. User-interface elements can be so small as to be unusable, and images are reduced down to postage stamps. Xkcd becomes unreadable in such a setting. Turning on pixel scaling in Firefox makes a lot of these problems go away at the cost of losing a fair amount of screen space to the expanded icon bars at the top — and to larger advertisements. The Chromium browser, surprisingly, appears to have no high-DPI awareness at all at the moment; the sad result is that even Google sites can look terrible there.

In general, any web site that is trying to manage its page layout using pixel sizes is going to run into trouble on high-DPI displays. Fixing that problem will take a long time, and involves some interesting tradeoffs. The tiny-image problem can be fixed by shipping higher-resolution images and getting the browser to scale them to the desired size, but that can increase bandwidth consumption considerably. The alternative — sensing the screen resolution and shipping appropriately sized images — is a lot more work to support.

Some closing thoughts

Naturally, the new machine came with Windows preinstalled, so your editor had the chance to see how that system copes with the high-DPI display. The situation there is perhaps a bit better, but Windows has not fully solved the problem either. The basic system user interface works well, but web pages can run into trouble there, and some applications, even popular, high-profile applications, have not yet made the adjustment.

Making applications work properly in an environment where displays can have widely varying densities — even on the same system — is not an easy problem to solve. The good news is that we are much of the way there; the bad news is that there is still a lot to be done, and, in some cases, a change of approach may be needed. In particular, approaches based on pixel scaling have all the appearance of being a short-term kludge that gets things working while a real solution is being worked on.

That real solution, it seems, almost has to involve divorcing applications from the individual pixels on the screen. Once applications are working in pixel-independent units almost all of the time (there may need to be exceptions for image editing, video playback, etc.), the underlying environment can work on rendering in a visually similar way on all possible screens.

Until then, it is good to see that developers are working on making high-DPI screens work better with Linux. A fast rate of progress is arguably not surprising; after all, desktop developers hardly seem like a crowd that would be resistant to the allure of a beautiful new screen. So we can probably count on those developers to fix up the remaining problems in relatively short order.

Comments (83 posted)