[personal profile] mjg59
There's a piece of software called XScreenSaver. It attempts to fill two somewhat disparate roles:
  • Provide a functioning screen lock on systems using the X11 windowing system, a job made incredibly difficult due to a variety of design misfeatures in said windowing system[1]
  • Provide cute graphical output while the screen is locked
XScreenSaver does an excellent job of the second of these[2] and is pretty good at the first, which is to say that it only suffers from a disastrous security flaw once very few years and as such is certainly not appreciably worse than any other piece of software.

Debian ships an operating system that prides itself on stability. The Debian definition of stability is a very specific one - rather than referring to how often the software crashes or misbehaves, it refers to how often the software changes behaviour. Debian is very reluctant to upgrade software that is part of a stable release, to the extent that developers will attempt to backport individual security fixes to the version they shipped rather than upgrading to a release that contains all those security fixes but also adds a new feature. The argument here is that the new release may also introduce new bugs, and Debian's users desire stability (in the "things don't change" sense) more than new features. Backporting security fixes keeps them safe without compromising the reason they're running Debian in the first place.

This all makes plenty of sense at a theoretical level, but reality is sometimes less convenient. The first problem is that security bugs are typically also, well, bugs. They may make your software crash or misbehave in annoying but apparently harmless ways. And when you fix that bug you've also fixed a security bug, but the ability to determine whether a bug is a security bug or not is one that involves deep magic and a fanatical devotion to the cause so given the choice between maybe asking for a CVE and dealing with embargoes and all that crap when perhaps you've actually only fixed a bug that makes the letter "E" appear in places it shouldn't and not one that allows the complete destruction of your intergalactic invasion fleet means people will tend to err on the side of "Eh fuckit" and go drinking instead. So new versions of software will often fix security vulnerabilities without there being any indication that they do so[3], and running old versions probably means you have a bunch of security issues that nobody will ever do anything about.

But that's broadly a technical problem and one we can apply various metrics to, and if somebody wanted to spend enough time performing careful analysis of software we could have actual numbers to figure out whether the better security approach is to upgrade or to backport fixes. Conversations become boring once we introduce too many numbers, so let's ignore that problem and go onto the second, which is far more handwavy and social and so significantly more interesting.

The second problem is that upstream developers remain associated with the software shipped by Debian. Even though Debian includes a tool for reporting bugs against packages included in Debian, some users will ignore that and go straight to the upstream developers. Those upstream developers then have to spend at least 15 or so seconds telling the user that the bug they're seeing has been fixed for some time, and then figure out how to explain that no sorry they can't make Debian include a fixed version because that's not how things work. Worst case, the stable release of Debian ends up including a bug that makes software just basically not work at all and everybody who uses it assumes that the upstream author is brutally incompetent, and they end up quitting the software industry and I don't know running a nightclub or something.

From the Debian side of things, the straightforward solution is to make it more obvious that users should file bugs with Debian and not bother the upstream authors. This doesn't solve the problem of damaged reputation, and nor does it entirely solve the problem of users contacting upstream developers. If a bug is filed with Debian and doesn't get fixed in a timely manner, it's hardly surprising that users will end up going upstream. The Debian bugs list for XScreenSaver does not make terribly attractive reading.

So, coming back to the title for this entry. The most obvious failure of the commons is where a basically malicious actor consumes while giving nothing back, but if an actor with good intentions ends up consuming more than they contribute that may still be a problem. An upstream author releases a piece of software under a free license. Debian distributes this to users. Debian's policies result in the upstream author having to do more work. What does the upstream author get out of this exchange? In an ideal world, plenty. The author's software is made available to more people. A larger set of developers is willing to work on making improvements to the software. In a less ideal world, rather less. The author has to deal with bug mail about already fixed bugs. The author's reputation may be harmed by user exposure to said fixed bugs. The author may get less in the way of useful bug fixes or features because people are running old versions rather than fixing new ones. If the balance tips towards the latter, the author's decision to release their software under a free license has made their life more difficult.

Most discussions about Debian's policies entirely ignore the latter scenario, focusing more on the fact that the author chose to release their software under a free license to begin with. If the author is unwilling to handle the consequences of that, goes the argument, why did they do it in the first place? The unfortunate logical conclusion to that argument is that the author realises that they made a huge mistake and never does so again, and woo uh oops.

The irony here is that one of Debian's foundational documents, the Debian Free Software Guidelines, makes allowances for this. Section 4 allows for distribution of software in Debian even if the author insists that modified versions[4] are renamed. This allows for an author to make a choice - allow themselves to be associated with the Debian version of their work and increase (a) their userbase and (b) their support load, or try to distinguish what Debian ship from their identity. But that document was ratified in 1997 and people haven't really spent much time since then thinking about why it says what it does, and so this tradeoff is rarely considered.

Free software doesn't benefit from distributions antagonising their upstreams, even if said upstream is a cranky nightclub owner. Debian's users are Debian's highest priority, but those users are going to suffer if developers decide that not using free licenses improves their quality of life. Kneejerk reactions around specific instances aren't helpful, but now is probably a good time to start thinking about what value Debian bring to its upstream authors and how that can be increased. Failing to do so doesn't serve users, Debian itself or the free software community as a whole.

[1] The X server has no fundamental concept of a screen lock. This is implemented by an application asking that the X server send all keyboard and mouse input to it rather than to any other application, and then that application creating a window that fills the screen. Due to some hilarious design decisions, opening a pop-up menu in an application prevents any other application from being able to grab input and so it is impossible for the screensaver to activate if you open a menu and then walk away from your computer. This is merely the most obvious problem - there are others that are more subtle and more infuriating. The only fix in this case is to nuke the site from orbit.

[2] There's screenshots here. My favourites are the one that emulate the electrical characteristics of an old CRT in order to present a more realistic depiction of the output of an Apple 2 and the one that includes a complete 6502 emulator.

[3] And obviously new versions of software will often also introduce new security vulnerabilities without there being any indication that they do so, because who would ever put that in their changelog. But the less ethically challenged members of the security community are more likely to be looking at new versions of software than ones released three years ago, so you're probably still tending towards winning overall

[4] There's a perfectly reasonable argument that all packages distributed by Debian are modified in some way

Date: 2016-04-05 09:20 am (UTC)
From: (Anonymous)
Nice explanation. As a (hypothetical) user I would probably have struggled to see the problem.

I agree it's confusing. "@mjg59: I think the real problem with Xscreensaver is that JWZ thinks it's an app and Debian think it's critical infrastructure." But I expect there's plenty other packages with similar status.

It seems clear that strong wishes from upstream should be respected. It's not exactly too hard to fork and rename etc. The problem is that the expression of this wish by upstream was somewhat aggressive _and we should have been able to handle this without pushing the upstream to be so aggressive in the first place_.

The first mention of changing the name, it sounded like a pointless obfuscation to me, but on second thoughts I think it could work quite well.

Upstreams like Firefox maintain the ability to make similar demands through trademark law. I suppose we should have a way to respect similar requests without the legal fees. Either to prevent downstream removing update notifications. Or to simply request removal from a downstream. The stability policy creates a problem here too. I don't think current Debian policy really accommodates switching to a forked package half way through the stable support period, even if it was bug-for-bug-compatible.

-- Alan

Date: 2016-04-05 09:39 am (UTC)
From: (Anonymous)
And that's exactly the reason for the Mozilla trademark policy too... they're happy for you to do what you want, as long as you don't risk tainting their name by releasing your own version of their application. Call it something else, and they're fine.

Renaming = forking

Date: 2016-04-06 07:05 pm (UTC)
From: (Anonymous)
The argument can be made that any time they backport fixes, they should rename the package, and consider it a fork. "Here's YScreenSaver, an app which is very similar to some old version of XScreenSaver."

Re: Renaming = forking

From: (Anonymous) - Date: 2016-04-07 06:25 am (UTC) - Expand

Date: 2016-04-05 10:09 am (UTC)
From: (Anonymous)
Application developers expect to be in control of there software version, and on nearly all platforms this is true. On android this is true, on iOS this is true, on window this true, on Mac OS this is true on windows phone this is true. Linux desktop is the only platform where a dev has no control over the version used.

Debian's definition of stable is rather out dated. By locking down the version you don't increase stability, you just lock in the current instability. Well maintained software gets better with time, bugs get fixed, security holes get fixed, the developer tests, then decides when there software is stable and then releases it. When they make the new release they do so because they believe the new version is better, if this was not so they wouldn't bother releasing it they would have just left it as it was.

The trend now is towards always using the latest stable version of software (decided by the developers not the OS). Browsers update themselves, webpages have only one version, the latest. And increasingly this is required for security. Most security improvements are not published they just happen as part of development, often not making it into the change log at all. Not running the latest stable version of software as defined by its devs slash publishers is just plain irresponsible.

Date: 2016-04-05 10:13 am (UTC)
From: (Anonymous)
"Debian's definition of stable is rather out dated."

"Not running the latest stable version of software as defined by its devs slash publishers is just plain irresponsible."

As a Debian user: no thanks. I appreciate 'stableness', I eschew shiny new features, I trust the Debian Security Team to handle security issues.

@mjg59, do you think it is possible to allow name/link along with Anonymous comments?

Date: 2016-04-05 10:19 am (UTC)
From: (Anonymous)
The amount of “Well maintained software” gets smaller over time.

I very much prefer Debian’s stability over any other, as, while *what* they ship is not the best thing one could ship as stable software, they ⓐ do it, ⓑ do it consistently and reliably.

(no subject)

From: [personal profile] vatine - Date: 2016-04-05 10:24 am (UTC) - Expand

No control?

Date: 2016-04-05 01:18 pm (UTC)
From: (Anonymous)
>Linux desktop is the only platform where a dev has no control over the version used.

There is something stopping him from creating a deb/rpm or other package with the new version?

Re: No control?

From: (Anonymous) - Date: 2016-04-05 10:56 pm (UTC) - Expand

Date: 2016-04-05 02:10 pm (UTC)
From: (Anonymous)
> Application developers expect to be in control of there software version, and on nearly all platforms this is true

The system belongs to the user, not to the developers, and the users should be in control.

(no subject)

From: (Anonymous) - Date: 2016-04-05 03:07 pm (UTC) - Expand

(no subject)

From: (Anonymous) - Date: 2016-04-05 09:40 pm (UTC) - Expand

Point releases not wanted

From: (Anonymous) - Date: 2016-04-05 10:08 pm (UTC) - Expand

Re: Point releases not wanted

From: [identity profile] aigarius.livejournal.com - Date: 2016-04-11 07:52 pm (UTC) - Expand

Date: 2016-04-05 02:24 pm (UTC)
From: (Anonymous)
> By locking down the version you don't increase stability, you just lock in the current instability.

Locking down versions brings stability to the user experience: on a system-wide scale, known and static issues are better than unknown and ever-changing issues, obviously.

> Well maintained software gets better with time, bugs get fixed, security holes get fixed, the developer tests, then decides when there software is stable and then releases it.

This is simply false. There are bugfix releases and feature releases, unless you are implying that your definition of "well maintained" allows for bugfixes only.

Date: 2016-04-05 09:36 pm (UTC)
From: (Anonymous)
> Debian's definition of stable is rather out dated. By locking down the version you don't increase stability, you just lock in the current instability.

You are neglecting to consider libraries and tools. If you use certain python libraries (or puppet, or C++ libraries, or ... anything?), for instance, you are likely to be severely disappointed when you are forced to rewrite your code (or maybe just recompile it) due to a routine update.

Maintaining API and ABI stability is hard, and Debian stable's approach to stability is one of the few (only?) that can actually avoid unanticipated work to fix breakages across the ecosystem. Everyone has a different set of packages that they can't handle changing without a major effort, and the only "stable" solution is to avoid changing any of them (more than is needed for security fixes).

(no subject)

From: (Anonymous) - Date: 2016-04-14 05:53 pm (UTC) - Expand

intermediate way

Date: 2016-04-05 01:38 pm (UTC)
From: (Anonymous)
As many other, I prefer much more the Debian way of managing the updates than the dev way of breaking things constantly.

But there is an intermediate way: The backports repository is open for providing new stuff for Debian stable. Maybe it's something to discuss with the package maintainer? It may be less frustrating for you and the users to have an up to date version of xscreensaver in backports ?

Re: intermediate way

Date: 2016-04-05 02:11 pm (UTC)
From: (Anonymous)
Clearly he doesn't want to discuss.

Re: intermediate way

From: (Anonymous) - Date: 2016-04-05 03:11 pm (UTC) - Expand

Re: intermediate way

From: (Anonymous) - Date: 2016-04-06 07:43 pm (UTC) - Expand

Date: 2016-04-05 02:56 pm (UTC)
From: (Anonymous)
You've mentioned at length how a downstream can potentially make upstream look bad, damage their reputation, or similar. But on the flip side, upstream adding a time-based warning to the software makes downstream look bad and damages their reputation.

Date: 2016-04-05 03:15 pm (UTC)
kraig: Salty+Zack (Default)
From: [personal profile] kraig
downstream has two choices there: cease to distribute the software, or "fix" it to remove the warning - which was what the original bug report was about. There was a fair bit of discussion in the bug report about your very point.

(no subject)

From: (Anonymous) - Date: 2016-04-05 10:57 pm (UTC) - Expand

(no subject)

From: [personal profile] kraig - Date: 2016-04-05 11:20 pm (UTC) - Expand

Stable names

Date: 2016-04-05 02:57 pm (UTC)
From: (Anonymous)
Renaming may be an option for a screensaver, but it would defeat the purpose of a stable system to rename command-line tools, e.g., breaking the user’s scripts in the process. Aliases can’t be desirable, either, as the user would still think they are running foo and report bugs to foo upstream even though it’s really bar that only has an alias of foo …

Date: 2016-04-05 03:07 pm (UTC)
From: (Anonymous)
Debian is a distribution which prided itself on its policy, in spite of technical requirements. Discussions on what init system might be best (even when quite vocal) could be settled on the basis of technical considerations, but discussion on what policy is more suitable just go on for ever with the content to noise ratio going to zero fairly quickly. This is also the reason why I avoid debian images: I just do not want to have to suffer all the implied bickering.

In an ideal world, it would be possible to simultaneously follow all of the local bylaws and good common sense. To "spite the developer in favor of the user" is just as counter-productive and illogical as presuming to be able to supply goods without any supplier - even more so, on such a minor issue as a screensaver (dura lex sed lex: stable means obsolescing if not obsolete).

The solution are clear: either
a) remove the package (why bother? it is not as if it is the kernel or some essential part of the infrastructure; yet this breaks the promise of stability)
b) rename the package and patch (breaking the promise of stability once more)
c) update the files (the horror: what about any other package which might be in a similar position? how to guarantee fairness and who can interpret the law in this case?)
d) spite the developer and patch the file
e) follow the letter of all licenses and requests by providing a new package which installs a binary patch on the compiled object code as to remove any call to the offending code. This would be unsatisfactory for everybody (which counts as fairness for some measure of "fair) but
1. would NOT alter the stable package
2. would NOT alter the source code of the relevant file
3. would remove the message
4. could be provided with source (i.e. a script patching the .o file in a reproducible way)
What is there to complain?

Renaming of packages

Date: 2016-04-05 03:17 pm (UTC)
From: (Anonymous)
AFAIK the renaming clause was done because of TeX license, which explicitly requires renames (IIRC originally for all forks, now only if a fork don't pass the upstream validation tools).

Note: TeX was a large code base at beginning of Debian, and also required by GNU info files.

XScreenSaver is a screensaver

Date: 2016-04-05 05:22 pm (UTC)
From: (Anonymous)
XScreenSaver is primarily a screensaver, not a screen locker as you put it. I use it to make my screen dark after a while, not to lock the computer.

Re: XScreenSaver is a screensaver

Date: 2016-04-05 11:38 pm (UTC)
From: (Anonymous)
I basically do the opposite: I use it to lock the screen, with animations disabled. There are other programs to do this, but some want to pull in huge "desktop environments" and many have horrific CVE histories. XScreenSaver has had some security bugs, but handles screen-locking better that any other program I've seen. And probably about as well as one can manage without redesigning X.

I Disagree

Date: 2016-04-05 07:24 pm (UTC)
From: (Anonymous)
I've been using Debian stable since 2007. Before that (2000-2007), I used RedHat, Mandrake, and Gentoo, among others. I teach, therefore my only requirement is that printing must not, under any circumstance, fail. Debian stable is the ONLY distribution which comes even close to guaranteeing this, in my years of experience. The common practice of updating a package and all its dependencies nearly destroyed my career (OK, I'm exaggerating). Teachers, and others who work on long-term projects, can not tolerate these random "minor" hiccups that result from constant updates.

Your point about security is well-taken, but I'd like to see proof that constant updates provides better security, as a whole. For certain types of workers, there has to be a distribution which provides some guaranteed level of security with near zero chance of updates screwing things up.

Also, you failed to emphasize the upside of Debian working with/against upstream authors. Here's an example of "antagonizing upstream", as you say:


The author of Apophenia (statistical library) used FSF licenses combined in a way one Debian developer considered invalid for distribution. Upstream disagreed, of course, but the situation was resolved. Even though the subject line of the bug was somewhat rude, upstream nevertheless adjusted the license. This is good for everyone, in my opinion.

I think the auditing done by Debian developers is an invaluable public service. And as far as I know, Debian does way more helping than "antagonizing".

Re: I Disagree

Date: 2016-04-13 05:45 pm (UTC)
From: (Anonymous)
I would agree in principle, except that Debian is very inconsistent.
Minor projects get almost "harassed" about the licensing stuff, while big libraries get away with not only many licenses it uses not listed in the file that needs to list them, but in addition distributing files with no license at all (and thus no right to distribute) included in the default package!
And that, to put it plainly, then pisses off the developers of said "minor projects" if others get a free pass to utterly mess up their licensing (much worse than they ever did) just because they are big.

I *am* an upstream maintainer

Date: 2016-04-05 10:02 pm (UTC)
From: (Anonymous)
And I strongly disagree. Debian users and maintainers are by far the most helpful and pleasant people to work with and there would be way less annoying bug reports if other distros would work the same way.

"make it more obvious that users should file bugs with Debian and not bother the upstream authors" Uhm, how much more obvious should they make it? If you go to https://bugs.debian.org, click on the "how to report a bug" link then you will get to a page that concisely explains all the important points about bugs (which is a really hard to do actually!). The headline of the fourth note reads "Don't file bugs upstream".

Re: I *am* an upstream maintainer

Date: 2016-04-07 09:49 pm (UTC)
From: (Anonymous)

No, Matthew

Date: 2016-04-05 10:40 pm (UTC)
From: (Anonymous)
This is the first time I've read your blog and thought you were just plain wrong. Hopefully the Debian project responds to this, because your opinions do carry weight on the Internets.

Thanks for the laughs

Date: 2016-04-05 11:26 pm (UTC)
From: (Anonymous)
> and everybody who uses it assumes that the upstream author is brutally incompetent, and they end up quitting the software industry and I don't know running a nightclub or something.

I actually laughed out loud. You’re funny. Thank you.

Lacking context

Date: 2016-04-05 11:46 pm (UTC)
From: (Anonymous)
It's a pity that what is, for the most part, a well-argued opinion contains no context at all.

One paragraph about the issue, with links both to the Debian discussion (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703) and the thread on Jamie Zawinski's blog (https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/) would have provided at least some context.

Else, the post is very insular; only a minority can understand the provocation that led to the post.

Also, running a spellchecker before posting would be a good idea; for example, "disasterous" would be spelt correctly as "disastrous".

Sam Varghese

Re: Lacking context

From: (Anonymous) - Date: 2016-04-07 10:54 pm (UTC) - Expand

Re: Lacking context

From: (Anonymous) - Date: 2016-04-15 05:27 am (UTC) - Expand
From: (Anonymous)
For all the time I have used Linux there has been something like appimage to make Distribution neutral packages by doing what you do on OS X, Windows and Android of bundling up all the dependencies your application users.

What is going on is not like you have described Matthew Garrett.

Reality lots upstream projects don't make linux binaries so then palm the problem of making binaries on to Distribution maintainers and end users. Yes just because upstream version releases a new X version does not mean it will in fact build without errors. Lots of up-streams don't have build servers or test-suite solutions testing every update. So upstream suffer from a lot more regression errors than they should so this is pushed down on to distributions to design plans to deal with.

Even worse a lot of upstream instead of fixing coding bugs just alter gcc flags until the program builds anyhow.

1) Upstreams need to get serous about releasing binaries users can directly install if they want to protect reputation. All the tools todo this exist yet upstream don't for Linux.
2) Upstreams need to get serous about in fact running testing frameworks.
3) Hosting companies of Upstreams need to take some role in mandating that they only host project that are undertake quality control processes like build servers and test suites and code auditing tools.
4) Distributions do need to make it clearer to end users what they have modified.

XScreenSaver is a super bad example because X11 can never do screen locking properly because its not designed to. The screen locking issue with X11 is why we need KMS locking. Think about it screen is locked yet you can cntrl-alt f1 log into terminal kill Xscreensaver and unlock the screen. Yes killing the screen locker without unlocking should be terminate session not result in logged in. Yes OOM killer of the Linux kernel can also unlock a locked session if you are using XScreenSaver solution.

So 5 is we need to serous-ally start looking at graphical security.

There's a perfectly reasonable argument that all packages distributed by Debian are modified in some way
In fact this is not true as some of the maintainers of debian packages are the upstream developers themselves. So modified in some way excuse does not really fly. The question is why is Debian and other distributions having to build applications from source in the first place and cannot get by wrapping the upstream made package. Wait there is no upstream made binary packages in most case for Distributions to consider just wrapping.
From: (Anonymous)
You can hit Ctrl+Alt+Fx to open a terminal, but if you can log into that terminal as someone who can kill the screen locker, you could have unlocked the screen. If someone's left it logged in, that's their own mistake outside the scope of screen locking.

Re: If you left the back door open, the lock is useless.

From: (Anonymous) - Date: 2016-04-07 12:24 am (UTC) - Expand

Re: If you left the back door open, the lock is useless.

From: (Anonymous) - Date: 2016-04-10 08:57 pm (UTC) - Expand

Re: If you left the back door open, the lock is useless.

From: (Anonymous) - Date: 2016-04-13 11:38 pm (UTC) - Expand

On the reason to run Debian in the first place

Date: 2016-04-07 12:22 pm (UTC)
From: (Anonymous)
I like it that Debian manages to run a pure-community distro and I like it that they keep the Free for community honest in terms of licensing. It really bugs me, though, that Debian dogmatically ships outdated software.

You say:
"Backporting security fixes keeps them safe without compromising the reason they're running Debian in the first place."

It would be interesting to have actual research data about why people run Debian stable in the first place. Do they run it because they want a community distro? Do they run it because of Free Software ideals? Do they run it because their friends do? Do they run it because they mistakenly think that "stable" means "doesn't crash"? Or do they actually run it in order to have out-of-date software?

For each of the questions above there are probably people who say "yes", but it would be very interesting to know in what percentages of the user base.

Does such research exist?

Henri Sivonen

Date: 2016-04-09 07:44 pm (UTC)
From: (Anonymous)
I prefer well known bugs than to deal with unknown bugs and the feature creeping of the new version.

A great overview of Debian

Date: 2016-08-22 02:42 pm (UTC)
From: (Anonymous)
Although I think many of the problems you addressed either (partially) fixable or a reasonable trade off, your argument show many realistic problems faced by a Debian user (me)!

First, I agree that a security problem is usually fixed in a new release, typical examples will be buffer overflow, array out of bound, and it really takes some effort to back-port it. I think the Debian partial respond to it is to have dedicated team working on essential, popular packages, like Linux, Bash, Firefox, Chromium ... The problem is of course that less popular package doesn't get this treatment and the security bugs are left unfixed for long time.

Second, about that Debian stable is too old, there is also an obvious fix, which is to install the testing distribution, which is really what you should do as a desktop user. Stable distribution is actually for server user, which don't want things change that often, for example my university allows us to ssh into Debian stable VM running on top of QEMU.

Third, regarding the reputation and report-bug-to-upstream, I think you are absolutely right. It is up to the users to figure out the right way to report bug. Sure, there is a lot of info available in Debian Wiki, but I see that often happen, especially with popular packages.

Fourth, you said that it would be too much work for upstream to package software for Debian. I think this is why we have Debian Developers and Debian Maintainer. These guys knows Debian better than average developers and can help or even do the job for you if the package is sufficiently interesting to them. Also, I think packaging for Debian worth the effort IMO not because that Debian is quite popular, but because Debian has many downstream distros, so you are essentially packaging for them as well.

Finally, there is a trick that fits my personal needs of running latest version of packages (like youtube-dl). I runs a custom package manager (Gnu Guix) on top of Debian. It is really the best of both worlds for me. Normally, I install packages from Guix. But if it doesn't work, I fall back to install from Debian. This way I get a sufficiently stable base OS (Debian testing) and bleeding edge packages (Gnu Guix master branch). Of course, it is perhaps too much work for a typical desktop user. At this stage, I would recommend simply install Debian testing.

Hope this help!


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags