
Ask HN: What do you as a developer want from a desktop Linux distro in 2017? - mattdm
With Fedora 25 almost out the door, it&#x27;s time to start planning for our next release, which will be sometime May&#x2F;June 2017. We&#x27;d particularly like Fedora Workstation, our main desktop offering, to be a favorite choice for software developers (from students to freelancers to startups to large organizations). What can we do that would make _you_ excited? What would you like to see in a Linux desktop that you can&#x27;t easily get today?
======
trebor
LTS – I don't have time to fool around upgrading and taking my system down.
Maybe I can budget time for this yearly, but only if it takes a couple hours
max.

Background updates – don't prompt me unless it's a breaking change; do it over
night, lunch, any time I'm not actually using the app/library.

1-click backup – give me a brain-dead simple way to configure automatic
backups to an external HD, Amazon S3/Glacier, etc; provide built-in support
for MySQL/MariaDB backups, and similar sensitive applications.

Actually keep up with patches! For instance, I set up PHP/Apache and PHP is
still on patch-level 15 — when p43 is available. Actually keep up. I don't
have the time necessary to build my PHP versions from source just to keep them
patched.

Sane defaults. Fast boot. Make it work out of the box with _few choices_ , and
simple to add on development environments.

Just some scattered thoughts for y'all. (Thanks for asking.)

~~~
mattdm
Update: I just upgraded my main workstation, which is heavily customized and
has a lot of random stuff installed. Took 26 minutes and 40 seconds from the
time I started until I was back in Firefox and able to tweet about it. About 5
minutes of that was downloading and I could keep working, so there was really
only about 20 minutes of downtime.

------
cuddlybacon
Hi, thanks for asking! :)

Some background: I've used Linux since 2004. I think I mostly used Ubuntu,
Fedora, and Arch. Recently (2013) I've move to macOS as my primary OS.

* Snapshots. Many of my co-workers are actually afraid to run 'dnf upgrade' (or equivalent) out of fear of it breaking the system. About half wait about a month after a major release, then upgrade to that, get it working, then never touch it. If dnf could take a snapshot and print "if you experience issues, you can revert back by running 'snapshot --revert-to $snapshot_name'". Similar for the GUI.

* App Store style interface for the repos.

* I can't remember if Fedora separated updates into 'new version' vs 'security update' vs 'bugfix'. I would like if security and bugfix installed silently and without intervention (with opt-out provided). I would also like it if new version updates could be marked auto-install on an individual basis and if it would also notify me about what it did. Android does this well, imo.

* Better ability to keep up with the lastest version of package X, particularly when X is related to my dev stack. If the next version has some features you're excited about, it is really unsatisfying to have to wait 4 months because that's when the next Fedora is. Ubuntu has tackled this with PPAs. Chakra (dunno if it is still around) was a semi-rolling release (it updated the base-OS in one go every few months, but everything else would just chase the latest version). Having to setup rvm and the like is just a pita.

* This will be a bigger/long-term thing: separation of my dev stack from the OS. One thing I really like about macOS (homebrew) is that I can chase the latest python/ruby/vim/etc without worrying about that breaking a Gnome app that happens to be written in Python.

* Look nice. A lot of people will write this off as frivolous, but I think it matters. If you are going to be staring at something all day, why not have that thing be nice to look at? Fedora has generally done well here. I don't know how it stands when you throw hi-DPI and mixed-DPI at it though.

* Be able to connect to Cisco VPN and Cisco wifi out of the box.

BTW: What does 'dnf' stand for? How is it pronounced? 'dee-en-eff' or 'dunf'
or something else?

~~~
kasabali
> What does 'dnf' stand for?

Did not finish, apparently:
[https://lists.fedoraproject.org/archives/list/devel@lists.fe...](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7ULAG243UNGTOSL6URGNG23GC4B6X5GB/)

~~~
mattdm
This isn't really DNF specific — it can happen with any package manager.
Whenever I run a DNF update that is going to affect X or my GNOME session, I
run it in tmux. There's not really a good solution _other_ than that, which is
why the desktop team promotes the reboot-to-apply-updates approach for the
general case. It's annoying to have to do that, but it's very reliable. (Or,
if you're more tech savvy, the tmux or switch-to-a-VT thing is just fine.)

~~~
kasabali
> This isn't really DNF specific — it can happen with any package manager

I don't know about other package managers, but please don't generalize dnf's
behavior here to the others, because apt-get and dpkg would be just fine in
this case. You can even disconnect from the ssh session and apt-get will
continue until it is finished. In the worst case scenario you would call apt-
get -f install and it would continue where it's left.

> There's not really a good solution _other_ than that,

Of course offline updates are valuable for the 0.001% scenarios but there are
basic resiliency measures one should take while writing the basic building
block of the distribution, before throwing in the towel and suggesting running
it inside tmux or to use offline updates for everything.

~~~
the_why_of_y
> I don't know about other package managers, but please don't generalize dnf's
> behavior here to the others, because apt-get and dpkg would be just fine in
> this case.

This claim is not matched by my personal experience. Recovery is usually
possible, but depending on the particulars may require non-trivial efforts.

~~~
kasabali
apt-get -f install is hardly non-trivial.

~~~
the_why_of_y
My point is that "apt-get -f" works less than 100% of the time, contrary to
the "would be just fine" claim.

~~~
kasabali
> works less than 100% of the time

I can't say much about that without seeing some examples. Of course it may not
calculate&offer an ideal strategy or even outright choke if the system is put
into a manually induced dependency hell, but that's a different scenario than
resuming an interrupted process which was otherwise progressing OK.

------
kevinherron
It needs to be a better "out of the box" experience than Ubuntu currently is -
fonts, available packages, hardware compatibility (wifi and gfx especially),
look and feel...

I don't care about free vs non-free I just want everything to work.

I stick to Ubuntu LTS versions, but I'm not sure that's a deal breaker like it
is for some other people.

~~~
mattdm
Can you be more specific on what "better" might mean to you particularly as a
software developer?

Some things like "better look and feel" are not very actionable. :)

~~~
kevinherron
What is your email? I'd like to give this some fair thought, and in order to
do so I want to install Fedora 25 and give it a test drive.

~~~
mattdm
[http://mattdm.org/email](http://mattdm.org/email) — but, really, comments in
public are more valuable to the project overall.

------
ni-hil
That the sound, the wifi, the sleep and wakeup, the connection to an external
monitor and all those tiny little things just works.

~~~
karmajunkie
Second to this... power management, fonts, hibernation—all the things I take
for granted using a mac that I'm suddenly reminded of as soon as I try to use
a linux-based notebook. 7 hour battery? Hah—good luck with that when your
distro kicks it into performance mode for no apparent reason randomly. These
are all the things that keep me using linux on a VM instead of as the host. I
could live with it when I was single and had a ton of time on my hands in my
20s. Those days are (sadly!) long gone.

~~~
partisan
The Dell Chromebook 13 (i5) has about 7 hours of battery life under Linux in
my usage. It went down a bit when using something heavy like IntelliJ but
otherwise it is pretty good.

~~~
karmajunkie
Thanks for the rec, looking at purchasing a new machine in the near future,
I'll check that one out.

~~~
partisan
The Linux experience on the Chromebook should be researched before buying it.
The best experience comes through removing the write protection on the
motherboard and flashing the BIOS. I haven't done that myself yet.

------
b3nj4m
Better support for high-DPI/mixed-DPI setups. I.e. I want to connect my
external monitor to my laptop and have everything be readable on both
monitors.

~~~
mattdm
Working on it with Wayland. I think this wish, at least, will come true. :)

------
dman
1\. Ability to recompile packages with setting some flags. (make.conf from bsd
/ gentoo). Example use case - I am investigating a hard to track issue and
would like to run some system packages with address sanitizer.

2\. Ability to easily patch / hack an installed package. Example use case -
lets say I want to change my installed ruby runtime to fix a small bug / add
some instrumentation.

3\. Ability to have my local software be available as a package. Example use
case - Have automated tooling to take a CMake based library / executable
project and have it be built as an installable rpm package.

4\. C++ is changing fairly rapidly currently, having gcc / clang trunk
available as a package would allow more users to try out cutting edge
features.

5\. Having a performant / good looking GDB frontend. Something like DDD for
the modern era.

I fully appreciate that one or more of those might be possible today, but it
would be nice if the barrier to entry to do these things would be lowered via
some tooling / tutorial style documentation.

~~~
mattdm
Like you say, these are all possible today (with the exception of #5, I'm
afraid!) but with a lot of hoops. I'm not sure if the recompile/patch of
system libraries is a general enough need to make really slick tooling
something we can invest in, but better documentation is certainly possible.

------
lukaslalinsky
I'd like cross-distro packaging to become much easier. Most projects that
bother to provide Linux binaries at all typically only do Ubuntu packages.
That's fine with me, as I use Ubuntu, but it would be great if there was some
new packaging format that worked across distros, that would be so ridiculously
easy to use (from both developer and user sides), that there would be
practically no reason not to do it. I guess this would require some definition
of what libraries are included in the system and things like that, but the few
popular distros today are quite similar anyway.

~~~
shakna
AppImage [0] solves this in a way similar to macOS apps.

Inkscape and a few others have adopted it.

End User downloads and runs. Its an executable.

As a dev, its easy. They have good docs, and even a jail for sandboxing.

[0] [http://appimage.org](http://appimage.org)

------
bjourne
Can you make HDMI just work (tm) please? I want to be able to connect my
laptop to a tv using HDMI and automatically have all audio being redirected to
it. I've been able to use xrandr to get the tv to show the desktop, but sound
just does not work. There are a few layers in the Linux sound stack, so
knowing which knob to turn isn't easy.

~~~
mattdm
For whatever it's worth, I just plugged my F25 laptop into my TV via HDMI, and
it basically just worked. Sound didn't automatically switch, but I hit the
overview key, typed "sound", hit enter, and built-in speakers vs. HDMI was an
easy choice.

We could look at making it switch automatically; I know it does for
headphones.

------
amirouche
Functional package management is the feature of the XXIe century (like guix
and nix). Knowing that I can tweak my system and be able to reboot in the
previous configuration is very pleasent.

~~~
mattdm
We're looking at using ostree for something like this. Probably not in F26,
but stay tuned.

------
mixmastamyk
Windows XP (in classic mode) was about the best it got on the power to
simplicity ratio, it's been downhill from there:

\- Stop fucking with the GUI, I need a workstation with extensive hotkey
support, not a tablet interface. Menus are not to be feared.

\- Finish it---NT 4 had better GUI tools to manage services, while the XP
Explorer is still better than file managers on Linux. CLI is great, but
nothing wrong with a visual approach when called for.

\- Bulletproof suspend and resume.

I'm guessing these won't be particularly easy or they would have been done by
now.

~~~
mattdm
Suspend and resume is _particularly_ not easy, as the hardware vendors aren't
going to have our needs in mind until we get a much bigger marketshare, making
it a gigantic chicken and egg problem.

On the other things: the GUI we have (GNOME, for Fedora Workstation) has
really settled down in core design from how it was a few years ago, with more
room for the polish you're looking for. (Despite the superficial appearance as
a tablet interface, GNOME is actually pretty awesome from the keyboard, and I
actually think of it as a keyboard-primary UI, at least for how _I_ use it.)

------
tjr
Might not be exciting to everyone, and I understand you might not want to
release _only_ this, but I think it would be nice if you could release a free-
software-only variant of Fedora:

[https://www.gnu.org/distros/free-
distros.html](https://www.gnu.org/distros/free-distros.html)

[https://www.gnu.org/distros/common-
distros.html](https://www.gnu.org/distros/common-distros.html)

~~~
mattdm
We get a lot more people telling us that this would be nice than people
willing to step up and do it. :) If we had the latter, I wouldn't be opposed
at all to such a Fedora variant. We also make it very easy to make a Fedora
Remix which follows stricter interpretation like this (and some of those on
the list above are based on Fedora).

The practical problem is that very little hardware today will even work,
making it a kind of academic exercise.

There's also an _academic_ question which I find makes the particular line
drawn here somewhat odd. All non-trivial hardware today requires
firmware/microcode of some sort. Loading that at runtime vs. having it baked
into an EEPROM doesn't seem like a really important distinction to me.

------
snehesht
Containerization ( and isolation ) of GUI software

This is sort of implemented already by sharing the X socket with the docker
container

~~~
mattdm
Absolutely in the works — check out
[http://flatpak.org/](http://flatpak.org/). The plumbing for this is in F25,
although we're not shipping anything that way yet.

------
0xFFC
Better and smoother font experience.

------
vital
My favorite Linux desktop TODO list:
[http://itvision.altervista.org/why.linux.is.not.ready.for.th...](http://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html)

~~~
mattdm
This is an interesting list, and in scanning it quickly, I know we have
various people interested in and working on various parts. We definitely
recognize that developers are people, and all of these general-desktop-user
hardships are hard for developers too.

Is there anything you would suggest, either additionally or as specific areas
of interest on the list, for the developer desktop use case in specific? Or
would you say that "make it work better for the general user" is the
overwhelming priority?

~~~
pzone
I think it is worth reading that article in depth after scanning it quickly.
It captures my own feelings about the state of the linux desktop very very
well.

~~~
slrz
So that's what I just did. It has some very reasonable points but much of it
is utter crack. I can't help but feel reminded of dmr's foreword to The UNIX-
Haters Handbook:

 _Here is my metaphor: your book is a pudding stuffed with apposite
observations, many well-conceived. Like excrement, it contains enough
undigested nuggets of nutrition to sustain life for some. But it is not a
tasty pie: it reeks too much of contempt and of envy._

 _Bon appetit!_

------
sigmaml
Nice that you solicit this feedback. Thanks! Here is my personal list.

Very, very important:

* LTS - this cannot be overstated

* Ubuntu-level font rendering

* Laptop driver situation improvement - graphics, wi-fi, power management

Important:

* First-class, deep support for KDE

Highly desirable:

* Easy installers for Broadcom wi-fi, nVidia cards, etc.

~~~
mattdm
Can you elaborate on LTS? Does my answer below about upgrade pain address your
concern?

On font rendering, we are hampered in some areas by patents. We have made some
adjustments starting with F24 (changes to the rendering and improvements to
the default system font) which you might appreciate. Good news is that higher
DPIs make some of those issues irrelevant, and we're working on good hiDPI
support, so.... the future is looking up.

I appreciate that you like KDE, but that's a technology / environment rather
than a problem/solution. What does KDE give you that you like?

On drivers, like any Linux distro, we're hampered by the difficulty in getting
vendors to even care about us. Red Hat's hardware enablement teams _do_ put in
a lot of effort here, and that work generally lands upstream in
X/Wayland/kernel, and is enabled in Fedora quickly.

For enabling proprietary drivers without too much pain (while still supporting
and promoting open source!)... we're working on ideas.

Thanks for your feedback!

~~~
sigmaml
Thanks for responding! My concerns are (almost) all in the context of use in
laptops.

1\. LTS: In my experience, the issue that has caused most trouble is kernel
version changes within a Fedora version. Why? Because drivers break. The
laptop works fine just before the update. After the update, I get a blank
screen. This has happened with different hardware, at least a dozen times in
the last six years. CLI tweaking was needed every single time, to restore X or
revert to a previous version. At other times, wi-fi no longer works after an
update. At yet other times, random wake ups happen from sleep.

Maintaining the same kernel version (and associated stack) throughout a given
Fedora release, in my humble opinion, can do wonders.

2\. Font rendering: Yes, I realise that you have some patent issues. Please do
the maximum that is legally possible. Fedora's font rendering hurts eyes after
a few hours of work.

3\. KDE: Desktop discussions can be subjective, of course! KDE's menu
accelerators and accessibility help in minimising the need for trackpad/mouse
use. In my laptop, KDE's responsiveness is uniform and smooth; GNOME
experiences random freezes (Cinnamon has the same problem; so, I suspect it is
GTK-specific). Also, on all of my laptops (HP, Dell), battery lasts noticeably
longer under KDE.

4\. Drivers: Yes, this is an Achilles' heel. Convenient installers for
proprietary drivers go a long way in making the experience more pleasurable.
Particularly, when we need to install, configure and support multiple laptops
(including those of family).

Thanks, again, for soliciting feedback! I look forward to improvements on
multiple fronts!

~~~
mattdm
1\. We're almost certainly going to keep the aggressive kernel updates. It's
very expensive to maintain a long-term kernel fork with bugfixes, and users
benefit from the constantly-rolling hardware enablement. That said, we are
working on making automated testing of these updates better, so we can block
ones with serious regressions. I think the experience you are describing is
likely due to proprietary drivers not matching the new kernel; we have some
work in flight to keep the old kernel the default if you have proprietary
drivers installed and they aren't updated to match. (Except in the event of a
critical security bug.)

2\. Have you looked at the font changes in F24? What do you think?

3\. I know the GNOME team is working on battery life. I haven't experienced
random freezing, but for subjective responsiveness, I recommend the Impatience
extension which shortens animation time
[https://extensions.gnome.org/extension/277/impatience/](https://extensions.gnome.org/extension/277/impatience/)
(I've jokingly suggested we install this by default with a timer which
shortens the animations the longer you have it installed.)

4\. Thanks; I'll definitely consider that.

~~~
sigmaml
> we have some work in flight to keep the old kernel the default if you have
> proprietary drivers installed and they aren't updated to match

That is reasonable, and should reduce the number of such problems.

> Have you looked at the font changes in F24? What do you think?

Certainly better than earlier versions!

> I recommend the Impatience extension

I shall try that; thanks for the pointer.

Thanks, again, for the active conversation!

------
autognosis
Portage. I can handle everything else from that point forward.

Gentoo or GTFO. :-)

------
coreyp_1
LTS.

~~~
mattdm
What does LTS mean to you? Is it _support_ you want? Is it interfaces not
changing for many years? Is it not having to worry about upgrades? Something
else?

~~~
coreyp_1
Specifically, I hate doing upgrades, and when I manage multiple machines, I
don't want the headache of continuously breaking the development flow just up
update to a "supported" version, after which I have to learn a new interface,
etc. Even worse is if I have to ask individuals to update their own
machines... there is a day (at least) of lost productivity!

In fact, this is the main reason that I have stuck with Ubuntu despite the
fact that I ABSOLUTELY ABHOR Unity. (Yes, I know that I can use a different
window manager, and I do, but I also hate having to constantly re-implement
the changes when upgrading, so I only use LTS releases.)

~~~
mattdm
This is a pain point I hear about a lot, usually with the suggestion that we
should do LTS or a rolling release. LTS is very expensive — and I think
prohibitively so for our volunteer community. It's also at odds with our
desire to get new upstream software to users quickly. You didn't mention
rolling release, but I can get into that if someone wants.

In any case, we _definitely_ hear this and our approach is make upgrades as
painless as possible. We've put a lot of work into this over the last few
releases, and the feedback right now is very positive; I'm seeing a lot of
"wow, that only took 10-15 minutes" on twitter from beta upgraders.

From the command line, it's one command to prep the update another to reboot
into the offline update itself, and then you boot into the upgraded system.
When F25 final is out, users of earlier releases can even launch this from the
Software GUI, just like a regular security update.

As for UI changes... I think GNOME 3 has really settled down here, and most
changes you see will be minor tweaks and usability improvements. As of Fedora
25, there's no longer version checking for extensions — we expect them to just
keep working for the most part. That's both a result of increased stability in
the shell interface itself, and a sort of stability feature in itself.

