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?
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.)
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.
LTS: See my comment below on upgrades. It should be minutes, not hours, and although Fedora does update every six months, we overlap intentionally and skip-a-release upgrades are supported. So this, I think, you should have now.
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?
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?
Snapshots: The ostree-based workstation some people are working on will provide this kind of functionality. We're also looking at providing development environments in containers, for better isolation of updates.
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.
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.)
> 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.
> 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.
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.
I'm sure there are some things that could be done better. In particular, DNF could do with better completion of interrupted transactions — the session dying is only one possible interruption.
Mixed DPI should ultimately be fixed under Wayland. Not sure what the current status is either, but at least it should be possible in theory, whereas mixed DPI goes against X protocol too fundamentally to be worth hacking on.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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:
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.
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?
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.
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.
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 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!
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/ (I've jokingly suggested we install this by default with a timer which shortens the animations the longer you have it installed.)
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?
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.)
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.
Not having to worry about upgrades. Major upgrades cost time, energy, and effort. I don't want to expend energy on it. I don't think playing sysadmin is a good use of my time.
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.)