1) Cutting Edge - Rolling releases of Arch or Gentoo
2) Stable - Debian (Slow and Steady on the Main Release)
3) Cutting Edge and Stable - OpenSUSE (One I mostly use)
4) Ubuntu - Ubuntu (Not sure where to place it, since is its own thing now to me compared to the rest of Linux blazing its own whatever it wants to do)
I am hoping that Fedora isn't just the break things fast and often it has been for me in the past.
I still remember the frustrations of having a good Fedora that ran out of updates. I would skip to the current version and not be happy with my computer for months. Last version I have tried to use for my own personal use is Fedora 14 (Used it since Core through 14). Fedora was never my main distro and I always had hopes for it to work for me, but alas ...
Wait what? Fedora20 is chock full of bugs. Most that I found were trivial (a programme having three different names, for example) but some were more important. Yum package lock was pretty annoying.
It's fine for what it is, but peoples definitions of "reasonably stable" are probably different.
I haven't had too many issues running Fedora as a main workstation OS... I'd say it's something like Cutting Edge and Stable-enough.
I've been using it since 19. The only issues I usually run into are related to Nvidia graphics drivers. I'm always a bit wary of updating the kernel or drivers and usually leave those updates along until I have time to deal with potential headaches.
From experience, I think GP is referring to being a few years into a RHEL/CentOS lifecycle and no third parties are packaging RPMs for your OS/version anymore. RHEL has been taking longer between major releases the last few times (but they've also extended support lifetime)[1].
Edit: Oh, and RHEL's policy of back-patching (and back-porting features on point releases) does lead to quite old versions after a few years. An on a product with a 10-year support lifecycle, stuff can feel pretty stale. But that's a feature when looked at the right way (which generally isn't the way you see it from a desktop/workstation vantage).
As other reply had mentioned, with their LTS you are stuck with fairly old software. For example with RHEL 6.x (surpassed just a year ago and still supported) you still have python 2.6 on there, even though 2.7 was released in 2010 (actually before the release of 6.0). You can find similar cases for pretty much every piece of software, from kernel to desktop environment.
It's not a bad thing in enterprise world, it sucks on desktop.
Redhat knows they messed up regarding newer stuff in RHEL5-6. That shouldn't ever happen again thanks to scl, which makes it quite trivial to get super new stuff in supported RHEL instances.
I think the Fedora philosophy/positioning is pretty well summarized right there on the project page.
> Freedom. Friends. Features. First.
Fedora is a cutting-edge distribution, but a Linux distribution is too large a thing to have only one cutting edge. Sure, if you want the latest applications and higher level libraries/frameworks, you might find them in another distribution first. On the other hand, if you want the latest core/infrastructure bits - e.g. system daemons, compilers, hypervisors - you'll probably find them in Fedora first because that's the distribution in which those kinds of developers do most of their work. Those other "cutting edge" distributions you mention might not have to wait for an actual release, but they still have to wait for the patch from the original developers plus the repackaging into their own native formats and repositories. "Cutting edge" is contextual. It all depends on what you're doing.
Disclaimer: I'm a Red Hat employee and some-time Fedora contributor. But at least I'm not being gratuitously negative about others' work.
If I'm not mistaken, that's because Red Hat funds a lot of work in those areas. Even where it doesn't fund it, those are the really interesting bits for a server/enterprise OS, and that's what Fedora is a feeder for, so they get a lot of attention.
Our policy at Red Hat is upstream first. Work is being done upstream and benefiting Arch and everyone else. It's not on Fedora. Fedora just benefits from an extremely good QE cycle compared to other distros, and a well-integrated set of packages, which is something rolling-release distros don't offer, not that there's anything wrong with that.
RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas.
Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.
I didn't mean to imply that changes were going directly into Fedora and not upstream, just that it both shows where the emphasis is, and it's likely to result in a disproportionate amount of time spent making sure those changes are both quickly available and very tested and stable (you want to see a return on your investment ASAP).
A nontrivial amount of bugs fixed upstream are found and reported against in-support versions of RHEL. But in a broader sense, there's no "immediate return on investment" pressure here.
We work with upstream communities. So there are upstream planning meetings which set feature development, which anyone is free to participate in, or we directly participate in apache/openssl/gnome/openstack/whatever meetings. New features are set and developed by the upstream product, where we (as developers) spend a lot of our time. We're not doing it in-house and pushing it back.
We try to make sure they're tested and stable through CI and QE testing (foo-1.2.3.noarch gets marked as the version in which bug #1234 is fixed in -- QE tests and verifies this before release).
There's some emphasis there because Satellite, Openstack, RHEV, and other "server" product entitlements and support are our revenue stream, but there's a significant desktop team, and kernel team, etc. We as a company are much less focused on what makes money and more interested in "what's the best tool for this job" and "how can we push Linux forward".
To that end, there's a heavy lean towards GTK/GNOME solutions over QT, but that's more culture than corporate direction. And there's a "disproportionate" amount of effort towards server products because that's what people use Linux for and that's what we work on, but the community drives our priorities, not the other way around. We're a relatively small company (for our revenue), and people work in one area. If I'm working on Openstack (upstream and downstream), pretty much all my effort is going there and none is going towards Firefox (or whatever). But being on a product team/niche isn't any different at Red Hat than anywhere else.
I didn't mean to make it sound like a business strategy (entirely), I mean it more as a natural progression of how people function. If as an engineer you are spending a lot of time working on Openstack, I'm sure you want to see the new advances and features in the product that you've invested so much time and effort into get into the distro ASAP, as long as they are stable (egg on your face is much worse than delays). I just view that as a facet of human nature, and one that has worked for Red Hat's advantage (whether on purpose or serendipitously) quite well.
> I didn't mean to make it sound like a business strategy (entirely), I mean it more as a natural progression of how people function. If as an engineer you are spending a lot of time working on Openstack, I'm sure you want to see the new advances and features in the product that you've invested so much time and effort into get into the distro ASAP, as long as they are stable
That's not really up to us, though. We still have product managers and project managers and project leaders who decide that Feature XYZ is going into Openstack Zeta, which comes back around to the original issue.
If I'm an engineer spending a lot of time working on Openstack, it's likely that I'm spending all of my time (other than hobby projects and side projects) on Openstack, just like you may be spending it on whatever your mainline product is (if you're a dev).
All devs probably want to see their features hit stable as soon as possible with wide consumption, but Openstack is a good analogue to Fedora, in the sense that things are operating on a schedule. We aren't releasing new versions of Nova/Neutron/whatever whenever we want or whenever we think it's stable or cool. We try to orchestrate that.
Absolutely, that is a big part of the reason. For anyone who ever has to work on RHEL systems, Fedora offers the most comfortable familiarity. Context-switching between multiple distributions' ways of doing things (especially packaging) is a pain. Some do it anyway. My little micro-server upstairs is running Ubuntu right now, because that was easier to get running than the equivalent Fedora ARM bits when I bought it. It has largely supplanted my desktop system which is running Arch. OTOH, this laptop is running Fedora, and when I set up a new server in the cloud for some testing, I'll generally go for Fedora or CentOS out of habit. That's just the default for a lot of systems-focused people, whether they work at Red Hat or not.
I don't really see a point in separating Ubuntu from the others. Normal releases should go in the "cutting edge and stable" category, and LTS releases in the "stable" category.
With that said, I'd place Fedora in "cutting edge and stable". It has a six-month release cadence just like Ubuntu.
Canonical is developing their own desktop environment (unity), their own windowing system (mir), their own package manager (snappy), etc. I think that is what the author was referring to when it said Ubuntu is doing "their own thing." That makes them a bit hard to compare to other distributions that are largely adopting the same technology at different paces.
And their own init system. But I agree with you, that's not all that different than some other big players such as Red Hat (systemd, pulseaudio, gnome, etc), even if the details of how they go about it are different. Investing time/manpower into a technology (whether you created it or not) and then pushing adoption through inclusion in the distro is a tried and true technique at this point.
They dropped Upstart for systemd in 15.04, after the decision was already made over a year earlier. They're also going to replace it in Ubuntu Touch as well.
It's worth noting that Upstart came at least four years prior to systemd, so it wasn't NIH.
I'm aware, but whether they are currently still using it doesn't really change whether or not they started the project, which is all I thought mattered for the discussion. I wasn't casting any negative judgement against Canonical/Ubuntu for that, just the opposite actually (even if my limited dealings with upstart were not pleasant), that's a big way distro innovation happens.
I've been using Fedora pretty solidly since 20. I use it in a VM to get all of my "actual work" done and just use my host machine for email and web browsing. It's been pretty stable for me.
The main reason I use it is that our production environments run CentOS and I want to get used to upcoming features before they're included in mainline (systemd, firewalld, dnf, python3, iproute2, etc).
Fedora has actually gotten a lot better since around Fedora 19. If you haven't given it a shot in a while you might be pleasantly surprised.
Same for me, use it in a VM, etc. I've been doing this since 18 and have found it to be very stable. My only complaint would be Fedora 21 seemed like the filesystem was a bit slow. But I yum update pretty regularly and it seems good now. This is all anecdotal, just noticing startup times of the product I work on and other programs I use daily.
EDIT: I just remembered something important about my use and might be why that you say it wasn't good before 19. I use MATE mostly because 18's Gnome3 was really bad. I still don't like Gnome3 and stick with MATE. Gnome3 is just too slow for me and some of the workflows get in my way.
That was what I was digging for. I liked the idea of Fedora but I always seemed to get in trouble with stability. I just might give it a try again on a secondary machine.
I don't find Arch to have many hurdles (Until there is something broken and placed on the webpage). They should have some tie in with Pacman to say read the front page before updating or front page was updated on date so and so ... Would fix the last hurdle that Arch has over other ditros.
It fits in at 3, just a different package manager and different philosophy on what to include and exclude by default.
For debian-based systems:
1. Cutting edge - Debian sid (also aptosid/sidux)
2. Stable - Debian Release
3. Less Stable but more modern - Ubuntu, Mint
4. Broken/Insecure - Debian Testing
For red hat:
1. Cutting edge - Fuduntu
2. Stable - RHEL/CentOS
3. Much less stable but more more modern - fedora
For arch/pacman
1. Cutting edge - Arch Linux
2. Slightly less cutting edge - Manjaro
3. Stable - no such thing, they're all rolling-release AFAIK
For Gentoo
1. gentoo
Don't know much about SUSE-based, but I know that OpenSUSE:Tumbleweed is the rolling release version containing the latest stable versions of software, while OpenSUSE is stable/fixed release.
Often, testing gets security patches at the same time as stable + unstable (dependent on the scope of the issue). Sometimes it takes a few days for a package update to make it's way from unstable to testing.
Obviously you wouldn't run testing on a server, but for a dev workstation it's not a bad choice. Far from 'Broken/Insecure'..
Debian Testing may have a nice "in-between" ring to it, but it is more likely to be broken and insecure for longer than either Unstable or Stable. All bug fixes have to go through unstable first (usually 10 days, but may often take longer). Because of this any breakage might take at least 10 days to be fixed.
from Debian Testing Wiki[0]:
> Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.
also, from Choosing a Distribution[1]
> testing could be broken for months [...]
>The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 10 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 10 days.
>The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps the testing in an usable state for most period of the time. Overall a brilliant concept, if you ask me. But things are alwasy not so simple. Consider the following situation:
>Imagine you are interested in package XYZ.
>Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7
>After 10 days, XYZ-3.7 from unstable migrates into testing.
>So on June 20, both testing and unstable have XYZ-3.7 in their repositories.
>Let's say, The user of testing distribution sees that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7
>Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS.
>The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30. Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version. The number 5 should not be taken literally. It could be less or more, depending upon the severity of the RC-bug at hand.
>This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 10th.
>But on July 5th some other person, discovers another RC-bug in XYZ-3.8
>Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days.
>So on July 10, testing has XYZ-3.7 while unstable has XYZ-3.9
>This new version XYZ-3.9 is now rescheduled to enter testing on July 20th.
>Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 20th. That is you essentially ended up with a broken XYZ for about one month.
>The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to unusable testing distribution for months
I use Fedora for my day-to-day development and love it. 21 seemed a bit bad on performance initially, but I keep upgrading and it now feels about right. When I saw this, though, I thought "Isn't it a bit early? 21 just came out in December and they're on yearly releases." Then I read the link:
Also with this release, we return to our traditional six-month cadence —
we’ll see you back here sometime around Halloween!
Am I old fashioned in that I usually run CentOS for my workstation? After a year or two it can be a pain getting some third party RPM, but generally I find that's a pain I'm willing to deal with to not have to worry about updating my workstation until I want to.
Although, I do port my highly customized Fvwm2 config every time I update, so maybe it is just me being old fashioned. Although I think anyone that thinks most modern WM are "fast" really is missing a bit of perspective. You haven't seen fast or efficient until you've custom tweaked a Fvwm2 config (or something equivalent).
The definition of "stable" is different between something like Arch and CentOS (and even Fedora).
When it comes to "bleeding edge" distros, stability might mean, "it doesn't crash". When it coems to stability for an enterprise/server focused distro like RHEL/CentOS, it not only means "it doesn't crash", but that package versions stay similar, major configs don't change, etc... so you scripts you write today will work on that system 3 years from now, no update will change some dependency you relied on, etc.
However mostly configs doesn't need to change even on bleeding edge, only major upgrades to gnome like gnome2 to gnome3 broke something, however that doesn't happen too often.
Also I was on CentOS a long time ago, even on servers, but it isn't good for projects with a dependency hell, i.e. when the project has some dependencies on newer operating system libs.
I used to run CentOS on my laptop for couple of years, very stable and did everything I needed. It was one of the very few distros that never gave me any issues. Latest software can be a problem but nothing major.
Hey, I still have the Yggdrasil CD, ca. 1994, Linux 1.06 as I recall. (CD is at home in the "archives".) Walnut Creek was the big supplier in those days.
In the mid-90's I used Red Hat, later other distros. At work still have one really old box with Stampede Linux from 1999. Also one of our servers runs on FreeBSD 6.0 installed in 2005.
Often enough, the most dangerous thing to do is "upgrade".
Yes, but if your work or hobby doesn't depend on staying on top of the latest (or even the last few decades' worth of) developments, then it probably doesn't matter. I still like KDE for its old-fashioned start menu and windows with title bars, etc.
> Files. The updated layout in Files gives a better view of your files and folders, and a new view popover makes it easy to change the zoom level and sort order from a single place. You can also now move files and folders to the trash intuitively using the Delete key, rather than the Ctrl+Delete keyboard combination.
It's 2015 and it still baffles me that a basic file manager still need such tweaking, rewriting and brainstorming.
Is there no such thing as a `problem solved, let's not touch it again' in the FOSS world [0] ?
I say that as someone using Debian with xfce and awesome everyday.
[0] Don't know why I specifically mentionned FOSS. Closed source is plagued as well as mentionned bayle a child poster. Chalk it up to fatigue.
> Is there no such thing as a `problem solved, let's not touch it again' in the FOSS world ?
Is there such a thing in the closed-source world?
Because Windows 1... err, Windows 3 (now with tiling windows!), uhhh... Windows 95 (now semi-3D!) uhhh... Metro! That's it!... is certainly a case study in how nothing changes and UI is a solved problem, right?
Oh, and I've used WindowMaker across multiple distros, from Red Hat (pre Fedora) through Slackware and now Ubuntu. (Yes, Ubuntu without Unity. Shock and horror and "Can such things be?!?!" line starts on the left.)
Desktop UI has barely budged since WIMP became the dominant paradigm in the 80s. There have always been alternatives (Oberon, rio, Cedar, zoomable UIs, etc.), but they've never had any widespread adoption.
As of more recent, there have been attempts by various parties (Microsoft, GNOME, Canonical...) to create these tablet-centric, opaque but outwardly simple UIs that are positioned as being groundbreaking and challenging norms, but in reality are some subset of WIMP with certain properties being given more weight than others (e.g. menus and icons over windows and pointers), but with little in the way of any true improvements in discoverability and interaction. Nothing like how all the text on screen is programmable, like in Oberon. That's groundbreaking.
Because the desktop shell is what most people ever see, it's a decent proxy for programmers to use providing an illusion of change and progress.
Honestly, this is one area I don't really want change.
Windows 95 nailed the desktop perfectly, and any attempt to significantly depart from its UI feels like a step backwards. Even Windows 98, with its webby bastardization of Explorer, wasn't as good as Windows 95.
I like KDE because I can use it as "Windows 95 with pretty graphical effects", and that's exactly what I want.
> It's 2015 and it still baffles that a basic file manager still need such tweaking, rewriting and brainstorming. Is there no such thing as a `problem solved, let's not touch it again' in the FOSS world ?
This isn't exactly unique to free software. You don't have to search very hard on HN to find threads of people complaining about Finder on OS X and Explorer on Windows, and enumerating the things they wish they could change about it.
Recently installed the Fedora 22 beta on my desktop and am blown away. It even automatically resized my Windows partition for me and works with my UEFI BIOS. 3D, printer, sound, all my mouse buttons worked out of the box. Thanks to systemd, the whole system boots up in a few seconds. Everything feels really smooth and polished. There's even a maps and software app now! The new GNOME is really beautiful and easy to use, easier than mac even, and I didn't have to tweak anything. You can even download RPMs and double click them to install.
I've had really good experience with systemd on Debian stable too. Suspend has worked flawlessly, and the bootup time is quite a bit faster too. I kind of miss seeing the startup scripts output to stdout what they were doing during boot time, but I suppose that if I really care, I can always go digging in binary logs.
I upgraded my main workstation to the recent Ubuntu with systemd, and sadly that has turned into a big problem. I use btrfs, and have several subvolumes as well as multi-drive filesystems. At some point systemd decides to filesystem check something it doesn't need to, and then times out. Sadly this kind of thing is really difficult to diagnose. The exact same devices are already mounted - the second mount is just a different subvolume. If it just went ahead and mounted instead of outsmarting itself, then all would be good. Thankfully I can make it boot using upstart which works fine.
It is very frustrating that /etc/fstab has just worked for several years, but now systemd does the wrong thing. I really want to like and use systemd.
To the best of my knowledge, the intention is to deprecate fstab(5) entirely in favor of automatic GPT partition discovery. Where this isn't possible, systemd-fstab-generator(8) will translate the contents of fstab(5) into native systemd units (mount, automount, swap...) and henceforth the semantics will be subject to the ordering and scheduling policies of systemd itself.
Mount and swap units are in theory supposed to just be wrappers to the regular system tools that merely extend them to the Unit semantics, but as a whole I'm unsurprised that these assumptions may not play well with more complex storage configurations. That's always been a recurring systemd pain point.
My frustration is that systemd isn't working in this case, that it is trying to do something pointless (check an already mounted filesystem), AND that I have no way to diagnose or correct it since there is no useful information to work with.
When I had my drives on different controllers things were even worse because btrfs device scan didn't complete running before systemd then tried to mount an incomplete filesystem.
Automatic partition discovery is going to have its own issues. For example plugging in a drive from another system/backups is not something you want mounted in the right places on the wrong system! fstab is also a nice place to put non-physical filesystems like tmpfs (I use it for /tmp /var/tmp $HOME/.cache $HOME/.ccache /space/work). Having to create separate .mount files for each of those would be a big pain.
I really want to use and like systemd, but it does fundamentally need to work first.
There is no need to create mount units, all those thing will work from /etc/fstab, which overrides the generator. And I don't think the intent is to deprecated /etc/fstab.
The list of possible automounts is limited:
http://www.freedesktop.org/software/systemd/man/systemd-gpt-...
the point really being that of having a system that can boot without /etc.
I've read quite a few complaints about Ubuntu 15.04+btrfs problems, for what is worth I had no problems with Fedora22 and Opensuse Tumbleweed.
I have been using btrfs for several years and it has been fine, except for the few occasions it ran out of space. The problem here is a switch from upstart to systemd has somehow resulted in the latter not behaving as the former wrt to /etc/fstab.
Have you been away for the last decade? This is pretty standard for decent linux distributions. UEFI support has been around for a few years now (I first used it almost three years ago). 3D has worked fine for a very long time unless you're on ati or nouveau.
I'm running Fedora 20 as my main home desktop/dev platform (upgraded from Fedora 19, it worked just fine this time!).
Fedora 22 means 20 will be EOL soon and I've been thinking what to do next.
I've realized that I don't use many things from the default install, and Debian Jessie provides reasonable versions for the important software I use every day (XFCE, Mesa libraries, Python, pip, gcc, vim; things like that), and for the other software I can install it from 3rd party repos (Chrome and Skype mainly) or compile it (I track SFML git repo, for example; and pip is amazing), so I won't be upgrading or reinstalling Fedora any more (since Fedora 12, I've been mostly a happy user after moving from Ubuntu -Debian before that-).
To be honest, I don't know what's going on. May be is the OSS I use that is now mature enough to not care any more if I'm running the latest version or not, or if it's me that is mature enough to just get things done (I was going to say "boring", but I'll stick with mature).
Fedora has been very useful for me when it was bleeding edge and I needed the new an shiny stuff, and because Fedora was a great community effort and it was really open to contributors (and I contributed!).
Since Gnome 3 and Unity, I'm not interested in the new stuff, and tired to see how any non-mainstream opinion makes you a hater (like anyone was interested in my blog; tip: nobody); but I digress.
Nice to see Fedora going strong, but please give me stability and something I can use every day without changing things because there's a vision and a plan and I'll be happy!
EDIT: I said when it was bleeding edge; and it still is. I guess other distros are catching up and that's not that relevant.
just upgrade to Fedora 21 as soon as 20 is EOL or use ArchLinux, thats what I did after I had enough from too many things that didn't worked out of the box in Fedora (like propriatary WLAN drivers, my current wlan stick is still really old stable, but it isn't inside the Fedora Kernel, however its already inside the arch linux kernel).
Also I would still be happy if ANY linux distribution could fix monitor plug & play, thats already really screwed. I mean things gotten better, but as soon as you deal with a retina display and plug in two 1920x1080 monitors in and out things getting screwed up really really fast. Also 3 monitors didn't worked out really well on login managars in the past years, however thats fixed now when you have the same resolution. That makes me really sad.
I've written a script that looks at the output of xrandr and reconfigures the screen layout, based on which outputs are plugged in and what the resolutions are. This is then bound to a key via the window manager so I can seamlessly move between laptop only, laptop+1 external, laptop+2 externals, or 2 externals only with just a keypress after coming out of sleep. This has been pretty solid on MacBookPro10,2, running the XFCE spin of Fedora 21. Some people have questioned if I'm running Linux when they see this work.
The background on the login screen doesn't always render correctly, but I look at that as often as I reboot (which is like once a month), so that doesn't impact me much (just like boot time, ahem).
My main concern is that as things become less shell-scriptable (like requiring complex dbus interactions), doing this will be less accessible to work around design or implementation quirks to achieve the desktop experience one wants. This is the price we pay for progress, I suppose.
Have a look at CentOS 7, the no-cost binary equivalentish(1) version of RHEL 7. Has long term support. Has familiar package management and administration. I don't follow this aspect closely but there was talk of 'software collections' allowing more recent versions of programming languages &c
(1)CentOS is compiled from the RHEL source code distributed by RedHat but the checksums for each binary will be different as branding/images are changed to remove copyright material.
New Linux releases always remind me that I'm in the minority (??) for not giving a single ...care... about the desktop version of the OSes.
Mac OS is great for a workstation OS (better user experience, application support). Linux for me is very much a CLI-only experience.
Edit: I mean to say that I only use linux for servers, typically web servers. I personally have no use for linux desktops. In theory they'd be nice (Docker running natively on Mac would be a dream) but I need Photoshop/Word products and really do not need to deal with the random issues of Linux desktops (e.g. getting wifi to work, dealing with sound driver funkiness, getting drivers/off-brand productivity apps, etc)
> Linux for me is very much a CLI-only experience.
What's it like in 1999?
>really do not need to deal with the random issues of Linux desktops (e.g. getting wifi to work, dealing with sound driver funkiness, getting drivers/off-brand productivity apps
Personally I have bigger problems with Apple products. OS X has all sorts of random issues(and even worse driver support). People like to pretend like Apple products "just work" but the reality is that OS X is just as buggy (if not more so) as Linux. The fact that Apple curates the hardware for their devices and has their OS coupled tightly to their ecosystem means these problems are inexcusable, they only need to ensure the OS works on around 5 models but they can't even get that right:
There are over 500 Ubuntu Certified PCs whereas there are ~5 current Apple models.
It's astonishing that apple users go out of their way to buy specific hardware just to get OS X up and running but refuse to do the same thing for other OS's, then go and claim that OS X "just works". I assume most apple users attempt to install Linux on their macbook only to find that Apple has made this process extremely hard and deliberately chosen hardware that uses closed source drivers that are hard to get on other operating systems, then they blame Linux.
Imagine if the situation was turned around and you were trying to install OS X on your Ubuntu Certified PC. Would it still "just work"? I'd wager installing OS X on anything that isn't a mac is a bigger headache than installing any other OS anywhere.
It would be like me building a custom computer, creating my own OS that only works on that computer, and then claiming my OS is good because it "just works" on my one specific machine.
OS X has the worst hardware support of any OS. You can get better hardware support and a computer/OS that "just works" by taking the time and energy you took to buy a PC specifically made to run OS X and use it to buy a PC specifically made to run Linux.
I find that I care very much about desktop versions whether I'm on Mac or Linux. On Mac OS, it's been "is my CAD app ready for me to upgrade to Yosemite yet? Because I really need that weird behavior with system app X fixed." On my Linux desktop sitting next to the MacBook, it's been "I have everything just right, but the latest version fixes the memory leak in cups-browser!" In both cases the version question is very much in play.
I used to tweak and customise, now I use defaults and transfer what I laughingly refer to my 'environment' over to a new install by copying some dotfiles a few scripts and my actual work files across (I'm not a programmer).
I use GNU\Linux because I can install it on recycled commodity hardware (currently Thinkpads with the older longer travel keyboards) without hackintoshing around, and the desktop software available supports my needs.
There are server-relevant changes in this new Fedora release.
I'm pretty sure that's a first generation, as there is no 'Fn' mod key on the left.
2nd gen has the 'Fn' key but still has the fingerprint reader on the right margin like the 1st gen. 2nd gen is also distinguished by having the split middle button on the trackpad.
3rd gen (the current one?) moves the fingerprint reader below instead of to the right from the keyboard.
That's a GIMP'd up version of the 1st gen Lenovo Thinkpad x1, or some knockoff build.
You can tell from some hints of red highlight on the trackpad where the buttons on the old X1 are.
Other indicators are the keycaps, webcam position, and screen rim being identical to the X1.
There's also the oddly clipped fingerprint reader off on the right side, and the fact that the X1 has a somewhat unique profile. Here's a comparison picture of one not shooped up: https://blog.hboeck.de/uploads/x1carbon.jpg
What's the attraction of antique, buggy software which no one is maintaining?
If you're responsible for a power station, satellite etc. then OK, better the devil you know than the possibility of a destabilising bug among all the new features and bug fixes. But for your laptop?
Tip: use ansible to configure your personal machine. Once every six months you boot into the live media, install, reboot, run ansible, reboot, done. You'll spend more time boiling a kettle and drinking a beverage than fettling a new release, and no more time trying to hand install the latest version of package X on a 3 year old base OS.
This is what I use to configure my Fedora workstation. It also has a few roles for other stuff and might seem a little confusing at first, but it's a good starting point, I guess.
Tried Fedora 22 on my laptop - installed from the live image dd'ed to a USB stick
Gnome 3.16 looks well slick although those new scroll widgets take a bit of getting used to (middle click for drag-scroll), e.g. Terminal | Edit | Profile then try changing the terminal font.
Playing mp3 music: gstreamer1-plugins-ugly package not available in Fedora repository. RPMFusion repository does not seem to work at present, the /etc/yum.repos.d entries refer to rawhide as well as Fedora 22. So I just used an old copy of the Fluendo mp3 codecs from Centos 6 installed with rpm -i --nodeps. I find it strange that in the second decade of the 21st Century playing a music track should take a significant amount of tweaking. Just works on Debian, who are very careful about licensing.
NTFS format external hard drive: ntfs-3g and fuse installed, but my (harmless) 500Gb external drive does not automount. Entry present in dmesg but can't see it in Files.
'Software' application reports failure to install just about every package, command line install using '# dnf install foobar' works much better.
91 comments
[ 4.0 ms ] story [ 296 ms ] thread1) Cutting Edge - Rolling releases of Arch or Gentoo
2) Stable - Debian (Slow and Steady on the Main Release)
3) Cutting Edge and Stable - OpenSUSE (One I mostly use)
4) Ubuntu - Ubuntu (Not sure where to place it, since is its own thing now to me compared to the rest of Linux blazing its own whatever it wants to do)
I am hoping that Fedora isn't just the break things fast and often it has been for me in the past.
I still remember the frustrations of having a good Fedora that ran out of updates. I would skip to the current version and not be happy with my computer for months. Last version I have tried to use for my own personal use is Fedora 14 (Used it since Core through 14). Fedora was never my main distro and I always had hopes for it to work for me, but alas ...
It's fine for what it is, but peoples definitions of "reasonably stable" are probably different.
I've been using it since 19. The only issues I usually run into are related to Nvidia graphics drivers. I'm always a bit wary of updating the kernel or drivers and usually leave those updates along until I have time to deal with potential headaches.
Edit: Oh, and RHEL's policy of back-patching (and back-porting features on point releases) does lead to quite old versions after a few years. An on a product with a 10-year support lifecycle, stuff can feel pretty stale. But that's a feature when looked at the right way (which generally isn't the way you see it from a desktop/workstation vantage).
1: http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Produc...
It's not a bad thing in enterprise world, it sucks on desktop.
http://developerblog.redhat.com/tag/developer-toolset/
Redhat knows they messed up regarding newer stuff in RHEL5-6. That shouldn't ever happen again thanks to scl, which makes it quite trivial to get super new stuff in supported RHEL instances.
> Freedom. Friends. Features. First.
Fedora is a cutting-edge distribution, but a Linux distribution is too large a thing to have only one cutting edge. Sure, if you want the latest applications and higher level libraries/frameworks, you might find them in another distribution first. On the other hand, if you want the latest core/infrastructure bits - e.g. system daemons, compilers, hypervisors - you'll probably find them in Fedora first because that's the distribution in which those kinds of developers do most of their work. Those other "cutting edge" distributions you mention might not have to wait for an actual release, but they still have to wait for the patch from the original developers plus the repackaging into their own native formats and repositories. "Cutting edge" is contextual. It all depends on what you're doing.
Disclaimer: I'm a Red Hat employee and some-time Fedora contributor. But at least I'm not being gratuitously negative about others' work.
RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas.
Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.
A nontrivial amount of bugs fixed upstream are found and reported against in-support versions of RHEL. But in a broader sense, there's no "immediate return on investment" pressure here.
We work with upstream communities. So there are upstream planning meetings which set feature development, which anyone is free to participate in, or we directly participate in apache/openssl/gnome/openstack/whatever meetings. New features are set and developed by the upstream product, where we (as developers) spend a lot of our time. We're not doing it in-house and pushing it back.
We try to make sure they're tested and stable through CI and QE testing (foo-1.2.3.noarch gets marked as the version in which bug #1234 is fixed in -- QE tests and verifies this before release).
There's some emphasis there because Satellite, Openstack, RHEV, and other "server" product entitlements and support are our revenue stream, but there's a significant desktop team, and kernel team, etc. We as a company are much less focused on what makes money and more interested in "what's the best tool for this job" and "how can we push Linux forward".
To that end, there's a heavy lean towards GTK/GNOME solutions over QT, but that's more culture than corporate direction. And there's a "disproportionate" amount of effort towards server products because that's what people use Linux for and that's what we work on, but the community drives our priorities, not the other way around. We're a relatively small company (for our revenue), and people work in one area. If I'm working on Openstack (upstream and downstream), pretty much all my effort is going there and none is going towards Firefox (or whatever). But being on a product team/niche isn't any different at Red Hat than anywhere else.
That's not really up to us, though. We still have product managers and project managers and project leaders who decide that Feature XYZ is going into Openstack Zeta, which comes back around to the original issue.
If I'm an engineer spending a lot of time working on Openstack, it's likely that I'm spending all of my time (other than hobby projects and side projects) on Openstack, just like you may be spending it on whatever your mainline product is (if you're a dev).
All devs probably want to see their features hit stable as soon as possible with wide consumption, but Openstack is a good analogue to Fedora, in the sense that things are operating on a schedule. We aren't releasing new versions of Nova/Neutron/whatever whenever we want or whenever we think it's stable or cool. We try to orchestrate that.
Fedora tries to orchestrate projects.
With that said, I'd place Fedora in "cutting edge and stable". It has a six-month release cadence just like Ubuntu.
The windowing system, maybe, but remember that Mir isn't even used by default yet. And Snappy isn't out yet at all.
It's worth noting that Upstart came at least four years prior to systemd, so it wasn't NIH.
The main reason I use it is that our production environments run CentOS and I want to get used to upcoming features before they're included in mainline (systemd, firewalld, dnf, python3, iproute2, etc).
Fedora has actually gotten a lot better since around Fedora 19. If you haven't given it a shot in a while you might be pleasantly surprised.
EDIT: I just remembered something important about my use and might be why that you say it wasn't good before 19. I use MATE mostly because 18's Gnome3 was really bad. I still don't like Gnome3 and stick with MATE. Gnome3 is just too slow for me and some of the workflows get in my way.
I've been using as my main OS for some time now, and with the exception of rpmfusion breakage, Fedora been quite stable.
So, I'd say it's close do OpenSUSE Tumbleweed, with some release cadence and support.
For debian-based systems:
1. Cutting edge - Debian sid (also aptosid/sidux)
2. Stable - Debian Release
3. Less Stable but more modern - Ubuntu, Mint
4. Broken/Insecure - Debian Testing
For red hat:
1. Cutting edge - Fuduntu
2. Stable - RHEL/CentOS
3. Much less stable but more more modern - fedora
For arch/pacman
1. Cutting edge - Arch Linux
2. Slightly less cutting edge - Manjaro
3. Stable - no such thing, they're all rolling-release AFAIK
For Gentoo
1. gentoo
Don't know much about SUSE-based, but I know that OpenSUSE:Tumbleweed is the rolling release version containing the latest stable versions of software, while OpenSUSE is stable/fixed release.
Often, testing gets security patches at the same time as stable + unstable (dependent on the scope of the issue). Sometimes it takes a few days for a package update to make it's way from unstable to testing.
Obviously you wouldn't run testing on a server, but for a dev workstation it's not a bad choice. Far from 'Broken/Insecure'..
from Debian Testing Wiki[0]:
> Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.
also, from Choosing a Distribution[1]
> testing could be broken for months [...]
>The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 10 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 10 days.
>The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps the testing in an usable state for most period of the time. Overall a brilliant concept, if you ask me. But things are alwasy not so simple. Consider the following situation:
>Imagine you are interested in package XYZ.
>Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7
>After 10 days, XYZ-3.7 from unstable migrates into testing.
>So on June 20, both testing and unstable have XYZ-3.7 in their repositories.
>Let's say, The user of testing distribution sees that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7
>Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS.
>The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30. Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version. The number 5 should not be taken literally. It could be less or more, depending upon the severity of the RC-bug at hand.
>This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 10th.
>But on July 5th some other person, discovers another RC-bug in XYZ-3.8
>Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days.
>So on July 10, testing has XYZ-3.7 while unstable has XYZ-3.9
>This new version XYZ-3.9 is now rescheduled to enter testing on July 20th.
>Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 20th. That is you essentially ended up with a broken XYZ for about one month.
>The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to unusable testing distribution for months
[0]:https://wiki.debian.org/DebianTesting
[1]:https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en...
Although, I do port my highly customized Fvwm2 config every time I update, so maybe it is just me being old fashioned. Although I think anyone that thinks most modern WM are "fast" really is missing a bit of perspective. You haven't seen fast or efficient until you've custom tweaked a Fvwm2 config (or something equivalent).
When it comes to "bleeding edge" distros, stability might mean, "it doesn't crash". When it coems to stability for an enterprise/server focused distro like RHEL/CentOS, it not only means "it doesn't crash", but that package versions stay similar, major configs don't change, etc... so you scripts you write today will work on that system 3 years from now, no update will change some dependency you relied on, etc.
Its also convenient when workstation and servers are based on the same distribution.
In the mid-90's I used Red Hat, later other distros. At work still have one really old box with Stampede Linux from 1999. Also one of our servers runs on FreeBSD 6.0 installed in 2005.
Often enough, the most dangerous thing to do is "upgrade".
It's 2015 and it still baffles me that a basic file manager still need such tweaking, rewriting and brainstorming.
Is there no such thing as a `problem solved, let's not touch it again' in the FOSS world [0] ?
I say that as someone using Debian with xfce and awesome everyday.
[0] Don't know why I specifically mentionned FOSS. Closed source is plagued as well as mentionned bayle a child poster. Chalk it up to fatigue.
Is there such a thing in the closed-source world?
Because Windows 1... err, Windows 3 (now with tiling windows!), uhhh... Windows 95 (now semi-3D!) uhhh... Metro! That's it!... is certainly a case study in how nothing changes and UI is a solved problem, right?
Oh, and I've used WindowMaker across multiple distros, from Red Hat (pre Fedora) through Slackware and now Ubuntu. (Yes, Ubuntu without Unity. Shock and horror and "Can such things be?!?!" line starts on the left.)
As of more recent, there have been attempts by various parties (Microsoft, GNOME, Canonical...) to create these tablet-centric, opaque but outwardly simple UIs that are positioned as being groundbreaking and challenging norms, but in reality are some subset of WIMP with certain properties being given more weight than others (e.g. menus and icons over windows and pointers), but with little in the way of any true improvements in discoverability and interaction. Nothing like how all the text on screen is programmable, like in Oberon. That's groundbreaking.
Because the desktop shell is what most people ever see, it's a decent proxy for programmers to use providing an illusion of change and progress.
Windows 95 nailed the desktop perfectly, and any attempt to significantly depart from its UI feels like a step backwards. Even Windows 98, with its webby bastardization of Explorer, wasn't as good as Windows 95.
I like KDE because I can use it as "Windows 95 with pretty graphical effects", and that's exactly what I want.
This isn't exactly unique to free software. You don't have to search very hard on HN to find threads of people complaining about Finder on OS X and Explorer on Windows, and enumerating the things they wish they could change about it.
It is very frustrating that /etc/fstab has just worked for several years, but now systemd does the wrong thing. I really want to like and use systemd.
An Ubuntu bug report did not help (ignore the wrong title) https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/14478...
Mount and swap units are in theory supposed to just be wrappers to the regular system tools that merely extend them to the Unit semantics, but as a whole I'm unsurprised that these assumptions may not play well with more complex storage configurations. That's always been a recurring systemd pain point.
When I had my drives on different controllers things were even worse because btrfs device scan didn't complete running before systemd then tried to mount an incomplete filesystem.
Automatic partition discovery is going to have its own issues. For example plugging in a drive from another system/backups is not something you want mounted in the right places on the wrong system! fstab is also a nice place to put non-physical filesystems like tmpfs (I use it for /tmp /var/tmp $HOME/.cache $HOME/.ccache /space/work). Having to create separate .mount files for each of those would be a big pain.
I really want to use and like systemd, but it does fundamentally need to work first.
I've read quite a few complaints about Ubuntu 15.04+btrfs problems, for what is worth I had no problems with Fedora22 and Opensuse Tumbleweed.
Changing the default filesystem on your OS is, imo, setting your self up for trouble.
But then one wonder why the F systemd is involved with mounting at all.
Or a whole lot of other things...
Have you been away for the last decade? This is pretty standard for decent linux distributions. UEFI support has been around for a few years now (I first used it almost three years ago). 3D has worked fine for a very long time unless you're on ati or nouveau.
Fedora 22 means 20 will be EOL soon and I've been thinking what to do next.
I've realized that I don't use many things from the default install, and Debian Jessie provides reasonable versions for the important software I use every day (XFCE, Mesa libraries, Python, pip, gcc, vim; things like that), and for the other software I can install it from 3rd party repos (Chrome and Skype mainly) or compile it (I track SFML git repo, for example; and pip is amazing), so I won't be upgrading or reinstalling Fedora any more (since Fedora 12, I've been mostly a happy user after moving from Ubuntu -Debian before that-).
To be honest, I don't know what's going on. May be is the OSS I use that is now mature enough to not care any more if I'm running the latest version or not, or if it's me that is mature enough to just get things done (I was going to say "boring", but I'll stick with mature).
Fedora has been very useful for me when it was bleeding edge and I needed the new an shiny stuff, and because Fedora was a great community effort and it was really open to contributors (and I contributed!).
Since Gnome 3 and Unity, I'm not interested in the new stuff, and tired to see how any non-mainstream opinion makes you a hater (like anyone was interested in my blog; tip: nobody); but I digress.
Nice to see Fedora going strong, but please give me stability and something I can use every day without changing things because there's a vision and a plan and I'll be happy!
EDIT: I said when it was bleeding edge; and it still is. I guess other distros are catching up and that's not that relevant.
Also I would still be happy if ANY linux distribution could fix monitor plug & play, thats already really screwed. I mean things gotten better, but as soon as you deal with a retina display and plug in two 1920x1080 monitors in and out things getting screwed up really really fast. Also 3 monitors didn't worked out really well on login managars in the past years, however thats fixed now when you have the same resolution. That makes me really sad.
The background on the login screen doesn't always render correctly, but I look at that as often as I reboot (which is like once a month), so that doesn't impact me much (just like boot time, ahem).
My main concern is that as things become less shell-scriptable (like requiring complex dbus interactions), doing this will be less accessible to work around design or implementation quirks to achieve the desktop experience one wants. This is the price we pay for progress, I suppose.
(1)CentOS is compiled from the RHEL source code distributed by RedHat but the checksums for each binary will be different as branding/images are changed to remove copyright material.
Mac OS is great for a workstation OS (better user experience, application support). Linux for me is very much a CLI-only experience.
Edit: I mean to say that I only use linux for servers, typically web servers. I personally have no use for linux desktops. In theory they'd be nice (Docker running natively on Mac would be a dream) but I need Photoshop/Word products and really do not need to deal with the random issues of Linux desktops (e.g. getting wifi to work, dealing with sound driver funkiness, getting drivers/off-brand productivity apps, etc)
What's it like in 1999?
>really do not need to deal with the random issues of Linux desktops (e.g. getting wifi to work, dealing with sound driver funkiness, getting drivers/off-brand productivity apps
Personally I have bigger problems with Apple products. OS X has all sorts of random issues(and even worse driver support). People like to pretend like Apple products "just work" but the reality is that OS X is just as buggy (if not more so) as Linux. The fact that Apple curates the hardware for their devices and has their OS coupled tightly to their ecosystem means these problems are inexcusable, they only need to ensure the OS works on around 5 models but they can't even get that right:
Sound not working after upgrade on OS X:
[the list could go on]Wifi not working in OS X:
[the list could go on]Upgrade disasters:
There are over 500 Ubuntu Certified PCs whereas there are ~5 current Apple models.It's astonishing that apple users go out of their way to buy specific hardware just to get OS X up and running but refuse to do the same thing for other OS's, then go and claim that OS X "just works". I assume most apple users attempt to install Linux on their macbook only to find that Apple has made this process extremely hard and deliberately chosen hardware that uses closed source drivers that are hard to get on other operating systems, then they blame Linux.
Imagine if the situation was turned around and you were trying to install OS X on your Ubuntu Certified PC. Would it still "just work"? I'd wager installing OS X on anything that isn't a mac is a bigger headache than installing any other OS anywhere.
It would be like me building a custom computer, creating my own OS that only works on that computer, and then claiming my OS is good because it "just works" on my one specific machine.
OS X has the worst hardware support of any OS. You can get better hardware support and a computer/OS that "just works" by taking the time and energy you took to buy a PC specifically made to run OS X and use it to buy a PC specifically made to run Linux.
http://rob.pike.usesthis.com/
I used to tweak and customise, now I use defaults and transfer what I laughingly refer to my 'environment' over to a new install by copying some dotfiles a few scripts and my actual work files across (I'm not a programmer).
I use GNU\Linux because I can install it on recycled commodity hardware (currently Thinkpads with the older longer travel keyboards) without hackintoshing around, and the desktop software available supports my needs.
There are server-relevant changes in this new Fedora release.
https://getfedora.org/static/images/workstation/workstation-...
2nd gen has the 'Fn' key but still has the fingerprint reader on the right margin like the 1st gen. 2nd gen is also distinguished by having the split middle button on the trackpad.
3rd gen (the current one?) moves the fingerprint reader below instead of to the right from the keyboard.
You can tell from some hints of red highlight on the trackpad where the buttons on the old X1 are.
Other indicators are the keycaps, webcam position, and screen rim being identical to the X1.
There's also the oddly clipped fingerprint reader off on the right side, and the fact that the X1 has a somewhat unique profile. Here's a comparison picture of one not shooped up: https://blog.hboeck.de/uploads/x1carbon.jpg
If you're responsible for a power station, satellite etc. then OK, better the devil you know than the possibility of a destabilising bug among all the new features and bug fixes. But for your laptop?
Tip: use ansible to configure your personal machine. Once every six months you boot into the live media, install, reboot, run ansible, reboot, done. You'll spend more time boiling a kettle and drinking a beverage than fettling a new release, and no more time trying to hand install the latest version of package X on a 3 year old base OS.
This is what I use to configure my Fedora workstation. It also has a few roles for other stuff and might seem a little confusing at first, but it's a good starting point, I guess.
BTW here are some good ones for Debian / Ubuntu: http://debops.org/
Gnome 3.16 looks well slick although those new scroll widgets take a bit of getting used to (middle click for drag-scroll), e.g. Terminal | Edit | Profile then try changing the terminal font.
Playing mp3 music: gstreamer1-plugins-ugly package not available in Fedora repository. RPMFusion repository does not seem to work at present, the /etc/yum.repos.d entries refer to rawhide as well as Fedora 22. So I just used an old copy of the Fluendo mp3 codecs from Centos 6 installed with rpm -i --nodeps. I find it strange that in the second decade of the 21st Century playing a music track should take a significant amount of tweaking. Just works on Debian, who are very careful about licensing.
NTFS format external hard drive: ntfs-3g and fuse installed, but my (harmless) 500Gb external drive does not automount. Entry present in dmesg but can't see it in Files.
'Software' application reports failure to install just about every package, command line install using '# dnf install foobar' works much better.