Ask HN: What do you as a developer want from a desktop Linux distro in 2017?
With Fedora 25 almost out the door, it's time to start planning for our next release, which will be sometime May/June 2017. We'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't easily get today?
59 comments
[ 72.8 ms ] story [ 892 ms ] threadIn 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.)
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.
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?
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!
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.)
Background updates: needs work. It's a good suggestion.
Backup: ditto.
Patches: I'm not quite sure what you mean. We do attempt (and I believe usually accomplish) patching security updates and severe bugs quickly. Sometimes, we backport security fixes rather than advancing the version number.
Sane defaults: That's hard to argue with. :) Do you have anything specific in mind?
Thanks for the feedback.
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.
https://www.gnu.org/distros/free-distros.html
https://www.gnu.org/distros/common-distros.html
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.
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
We could look at making it switch automatically; I know it does for headphones.
- 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.
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.)
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?
App Store: Can you elaborate? Something different from what we have in Software today?
* Security updates separate: yes, we separate updates into new package, enhancement, bugfix, and security. You can can configure dnf-automatic to install just security updates automatically. Opt-in rather than opt-out.
* Keeping the X you care about on the version you care about, and separating the dev stack from the OS. Yes, absolutely. We have Coprs as an equivalent to Ubuntu's PPAs, but I don't think that's very satisfying. We have a big initiative called Modularity which is aimed at delivering this for everything across the distro. See https://www.youtube.com/watch?v=xNLhcYEMgO0 for a quick intro.
* Look nice: yes, we definitely try. Everyone has different ideas, though.
* Cisco: Doesn't this work? If it doesn't require something proprietary, I think it _should_. Point me to any open bugs if it doesn't. :)
* DNF: Officially does not stand for anything. "Dee en eff" is what I hear.
Did not finish, apparently: https://lists.fedoraproject.org/archives/list/devel@lists.fe...
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.
This claim is not matched by my personal experience. Recovery is usually possible, but depending on the particulars may require non-trivial efforts.
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.
Gentoo or GTFO. :-)
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.
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!
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!
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/ (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.
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!
This is sort of implemented already by sharing the X socket with the docker container
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.
Some things like "better look and feel" are not very actionable. :)