Posted
by
timothy
on Tuesday December 17, 2013 @11:49AM
from the is-it-a-true-fedora? dept.

sfcrazy writes "The Fedora Project has announced the release of Fedora 20, code named Heisenbug (release notes). Fedora 20 is dedicated to Seth Vidal, the lead developer of Yum and the Fedora update repository, who recently died in a road accident. Gnome is the default DE of Fedora, and so it is for Fedora 20. However unlike Ubuntu (where they had to create different distros for each DE) Fedora comes with KDE, XFCE, LXDE and MATE. You can install the DE of your choice on top of base Fedora."

I've a spare motherboard and some HDs kicking around, maybe I'll have a go at installing a Redhat descendant for the first time in well over a decade (Has it really been that long a time?..ye gods..'one day you'll find' and all that.)

Just go for it. Fedora 20 is worth investing some time in, since it is systemd based and therefore shows the direction that most Linux distribution are heading. All the knowledge you gain about systemd and its tools like "journalctl" can be directly used in future Linux distro's like RHEL, CentOS, SUSE, etc.

So instead of wasting time getting to know a particular distros home made tools for eg. managing daemons, you can learn a set of standard tools that can be deployed exactly the same way across many diffe

> since it is systemd based and therefore shows the direction that most Linux distribution are heading

We would be happy if you'd stop spreading such unproven bs!

Red Hat, Fedora, CentOS, SUSE, OpenSUSE, Arch Linux, Mageia, Sabayon Linux all enables systemd as default. There are probably many more, and certainly many more to come in the future. Besides that, distros like Gentoo and Debian have systemd as an option. Hey, even a slacker is working on systemd support on Slackware.

All desktop environments like Gnome, KDE, LXDE are integrating systemd like crazy because it saves them from a lot of OS specific code. At present you can either use systemd in order to hiberna

The summary makes a (pretty much meaningless) distinction between Ubuntu requiring different base installations for different desktops, instead of a single base installation. So yeah, Ubuntu is different from most distros in that regard I guess. But no one really gives a fuck. But I guess distros will do anything these days to try to distinguish themselves from every other distro out there that's pretty much the same.

The problem with installing flavor A and then apt-getting DE B is always that you end up with a gazillion different utilities which clutter up your menus and are confusing even to the seasoned linux user. You can do it, and it may be reasonable if you are evaluating DEs prior to a decision, but it's not pretty. Given Ubuntu's targets they are doing it right IMHO.

More to the point, you'll still need to periodically log in to the original default DE to use the system configuration utilities, because the alternate DEs you add on from the repository later usually aren't complete installs of all the tools that can be used to configure the system.

Of course, if you're a long-time Unix/Linux hack, you don't use those fancy GUI tools in the first place, so it won't matter to you. And from what I've seen, people who are experienced enough to apt-get an alternate DE (or a

We (Fedora) didn't write anything comparing the way we provide desktops to how Ubuntu does it. That's something the person who submitted the story wrote. It's not a comparison we'd find particularly interesting, I don't think.

You *can* (submitter appears to be a bit confused) but there is certainly no guarantee it will work well. When you go against the Ubuntu way and start making your own decisions it's easy to get well outside of what is tested and supported.

Even KDE is IIRC only maintained by external volunteers, Ubuntu is built around the idea that they decide and you use what they decided on. If you want to make choices there are plenty of better distributions to use.

You *can* (submitter appears to be a bit confused) but there is certainly no guarantee it will work well. When you go against the Ubuntu way and start making your own decisions it's easy to get well outside of what is tested and supported.

From my experience, vanishingly little in the way of desktop-user vertical integrations (Ubuntu's strength) meets with rigorous testing on Fedora. In fact, much of that "ucky" obsessing over details and connecting code in the between layers is precisely the kind of thing they frown upon.

Even KDE is IIRC only maintained by external volunteers, Ubuntu is built around the idea that they decide and you use what they decided on. If you want to make choices there are plenty of better distributions to use.

More power to them, then. The kinds of choices you're implying concern only a thin sliver of the techie demographic. Once users feel they have a stable interface to their system, they start feeling more confident about makin

I think a lot of people don't realise how easy it is to switch desktops in Ubuntu - just install the appropriate packages from the standard repositories and choose whichever you want to use at login. Occasionally you run into minor conflicts, but the major DEs generally co-exist quite happily. You don't have to go with, say, Xubuntu just because you want Xfce. The spinoff distributions aren't just standard Ubuntu with alternative desktops, they also have very different collections of default packages, so th

Ubuntu isn't even really an exception. You can still install the barebones "server" flavor, then drop whatever DE you want on top of that. Or start with one DE, then install another DE alongside it. As far as I'm concerned it is just a nit-picky detail of what they happen to promote as the default distribution image.

Not in my experience. Over the last 4 years my PC has run every version of Fedora and has/home on a pair of mirrored drives which I set up using anaconda on what I'm guessing was F11. I don't always upgrade as new versions are released but it is running F19 right now.I grant that "not supported" is different from "it ain't gonna work" but for me at least; it worked.

I don't know if anyone's tested it recently. It may work with fedup. 'use software RAID' is a misleadingly vague statement of the problem, though; IIRC it was only ever broken if you *have/boot on RAID*, which is rather different from just 'using RAID'.

It's disingenuous of you to accuse me of being misleadingly vague when the very sentence [that you fail to quote] says " if you do something bizarre, like mirror your drives". It's clearly qualified - blame shifting is not becoming. The ironic 'bizarre' is there to indicate just how common this configuration is.

Yes,/boot is mirrored on mirrored drives, just like/,/home,/var, etc.. Every server I've ever seen with mirrored drives has

Is using bcache really this hard? [fedoraproject.org] I didn't see any mention of setting up bcache during an initial system install. Essentially like: install everything to/dev/sda and use/dev/sdb as cache? Couldn't this be done if/dev/sda1 was a LVM w/ / on it, maybe with/dev/sda2 as/boot?

I really like Fedora. Been using it since Fedora Core 1 (and Red Hat before that). It has been rock solid for me all these years, and it just keeps on improving.

The new "systemd" internal plumbing system is a joy to use. "journalctl" is the finest new system tool I have seen for many years; it is really fast, and its superb autocompletion reduces typing to a minimum.

"$ journalctl -F _SYSTEMD_UNIT" instantly show all systemd services that has ever written to the log file.

"$ journalctl -b -1 -p err" filters the log file, so that only errors are shown (-p err) from the previous boot (-b -1, current boot is just "-b" etc.).

A tremendous help for newbies who now doesn't need to learn 'cat', 'grep', 'less' and piping in order to do basic log file inspection.

Besides improving my systemd skills, the next spare time project I will try on Fedora 20 is lightweight containers. They seems like a useful addition to full blown virtual guests.

I noticed huge system slowdown with the introduction of journald. I noticed huge performance loss in reading and writing files on my hard drive. After some investigation I figured out that journald is the cause of all the slowness. After killing the process (multiple times) I figured out that the performance in writing and reading comes back to normal (used to know) speed. After investigating I figured out that after using the system that journald has created around 100-150mb of metafiles in/var/log/system

I think there was a systemd bug that caused syslog to freak out. But besides that, systemd-journald is lightening fast and lightweight on a proper systemd distro like Fedora. It on takes 300 K memory (+3 Megabyte shared mem) on my desktop system. I haven't seen it even suck up 1% CPU time ever.

systemd often keeps logfiles around for longer than many syslog implementations that uses a simple cron/time based logrotate. Since the journal is indexed size isn't really a issue.You can tweak the maximum size etc.,

I read his comment just fine, my comment about CPU, as you would have understood if you had read carefully what I wrote, was a general observation that systemd-journald is a really fast lightweight daemon that doesn't consume much memory, or _even_ CPU time. (BTW, I can't fathom any scenario where a daemon does so much RW that it causes a system slowdown, without that daemon sucking up CPU time.)

The OP may have experienced slowdown problems after his upgrade, but systemd-journald in it self wasn't the cause

Oh yes!I've struggled for months trying to use things like grep and less, you've no idea how many weeks I've been stumped trying to use cat!

I've been playing with journalctl, and I've managed to learn it all within about 3 days! It's a miracle! Now I can finally drop the endless nights spent scrolling through logs with less!!

If only we could have a tool to change plain text files to systemd log format, and I could use the wonder that is journalctl to parse and find things in them, instead of awful grep. There should be a text edit built in to systemd that does this and allows me to edit files and configurations, imagine how much better it would all be with this wonder of journalctl!

You are trying to be sarcastic but that doesn't help one bit. Some people don't seem to like systemd, and that is ok with me, but what I find hilarious about the systemd haters are that they can't seem to argue their case in any coherent technical way, they always seem to use ad hominem attacks combined with a considerable dose of paranoid conspiracy speculation. I think your problem is that you actually doesn't have any real knowledge or experience with systemd, that way you are bound to loose any technica

Your example shows exactly what is wrong:1. What error? How does the newbie know what to grep for without knowing what is written in the log? A 'grep "some error"' will of course miss both "Error" and "", but also miss errors indicated with "Failure" or "Warning".2. The newbie can be swamped with error messages since your simplistic grep (without -i switch and path, and no pager too) just dump every "some error" logged the last couple of months unto the t

> How does the newbie know what to grep for without knowing what is written in the log?

"journalctl -b -1 -p err" seems to be exactly what newbie knows out of his mind. Pathetic loser!

Ah, the ad hominem attacks begin. As said earlier, you systemd haters just seem unable to have a technical argument. I understand why you hide as an AC.

Sure, no UI is intuitive (excepting the nipple), you still have to learn something if you want use the CLI to inspect the log file. It is just that very basic 'journalctl' knowledge gives the newbie an easy and consistent way to obtain useful information.

Just one man page to look at, instead of several (and the man page for grep is pretty intimidating for a

I have no problem with people having different preferences. In fact my main problem with systemd haters are exactly that they continually slander open source developers like Poettering just for making a init system that they evidently doesn't use or have any real knowledge about.

Content free statements like "Unix philosophy means..." doesn't convince either. grep, sed, cp, diff etc. are all useful tools, but I have absolutely no problem with Linux users that doesn't know anything about them, but just uses

I don't think making syslog only register error levels above "Error" is a solution. After all, seeing that a service is starting correctly can be very useful debugging information too.

I don't share your view, that only people mastering awk, sed and grep should be allowed to use Linux, and while I love the power of e.g. GNU tools, I don't think they should be mandatory to learn just to perform basic system maintenance.

As a newbie desktop user coming from Windows, there are so many new concepts to learn, addi

The biggest differences between them are admin tools and init/rc stuff as well as the language the tools are written in. The packaging systems (RPM vs.DEB) are really not as great a difference since they accomplish essentially the same thing overall. The biggest packaging difference is how they name things and where they put them; this is also the most frustrating difference.

You'll notice that most general/new-release distro reviews are superficial, noting things like application/kernel version numbers and what DE is chosen and what default apps are installed -- all meaningless since any DE and most any app and most any kernel can be installed on any distro. These are reviews written by newbies for newbies. Apparently the people who know the significant underlying differences don't write reviews or don't know enough about other distros to draw a meaningful comparison.

Why not compare these to Ubuntu? Behind the scenes where it matters, it's too different from Fedora/Mageia for me to get a handle on it without obtaining a more intimate knowledge of Ubuntu, something I have no real need or desire to do. My only gripe about Ubuntu is that too much software is developed for it that is reliant on Ubuntu-specific scripts and such things that it cannot easily be used on other Linux distros; HOWTOs written for Ubuntu are so Ubuntu-specific that they are rendered almost useless for any other distro (they seem to be written by the same folks that write the superficial reviews).

sfcrazy and others do Fedora and Ubuntu a disservice by making these uninformed and superficial comparisons.

> The biggest packaging difference is how they name things and where they put them; this is also the most frustrating difference.

I find the Ubuntu/Debian packaging system is much weaker than the Fedora/RPM system. Firstly the Fedora packages are sensibly and predictably named (lib prefix for libs, -devel for the development packages, -static for static libs) while the Ubuntu packages are insane with odd version numbers rolled into the package names e.g. zlib1g, zlib32z1, zlib64z1, Fedora nicely has jus

Are where you will find syslogd and init scripts. Get away from your wibbly-wobbly daemony-waemony way of doing things, and let the admin adjust startup stuff and view logs via simple text edit commands.

Now that Fedora comes with systemd as default, I see more and more comments like "systemd is installed and default in more and more distributions" and I would like to use the opportunity to say that not only this is not true, but it will absolutely not happen for quite a few distros.

While I love the ideas behind systemd, and it undeniably works very well (it wouldn't have been adopted otherwise), it does have it's disadvantages. One of the most important ones is it is Linux-exclusive, which means that any d

"While I love the ideas behind systemd, and it undeniably works very well (it wouldn't have been adopted otherwise), it does have it's disadvantages. One of the most important ones is it is Linux-exclusive, which means that any distribution and any software that wants to be available for other platforms, simply cannot use it. That is the case, for example, for Debian."

That doesn't appear to be correct. Debian is currently actively considering a switch to systemd, which I don't think it'd be wasting time on

I do like Fedora, no doubt! Unfortunately having to maintain my system all 6 Months with a full update is a nogo!

That's why CentOS exists, no?

To GP: there is absolutely no reason whatever that you have to upgrade every 6 months. NONE. Every release is supported until one month after the SECOND release following. That means 13 months of life. You can upgrade as fast as every 6 months or as slow as every 12-13 months. Admittedly, that is still a pretty demanding rate.

GCC 4.4 is just the system compiler. Red Hat provides supported installations of GCC 4.8 as part of what they call Red Hat Developer Toolset. It includes modern versions of the GNU stack as well as the latest version of the Eclipse development environment.

RHEL is a bit slow but that's a feature if you're the kind of user that wants that kind of distribution. You install it once and it will continue to work reliably for years and years. It's of course a little bit extra behind right now since the next major release is expected $REALSOON. It's likely that Fedora 19 or so will be the base for RHEL 7. They originally planned to use Fedora 18 but decided to skip that release for some reason.

I only upgrade every couple of years, although most of the time you can upgrade in the background, and not have to change much, if anything on the front end. I went from 11, to 12, to 13 that way.

Why upgrade when it is very easy and usually much quicker to do a fresh install in your system file-systems. For me to do two machines it usually takes about 6 to 8 hours and that includes downloading the DVD, checking the download, creating the boot-able USB key, installing the new OS in the appropriate system file-systems making sure you don't clobber your personal data (ie/home) followed by customization and updates. Actually most of my time is spent surfing the web or playing a game rather than actuall

Fedora already supports releases for 12 months, as the most recent 2 releases are supported. Fedora 19 has been out for six months, and will be supported for a further six (or so!) months until Fedora 21 is released.
In contrast, Ubuntu only supports its releases for 9 months, except for the LTS releases.

I have two boxen with Arch and two with Fedora (19 and Beta20), I use the Fedora as my 'personal' machine and keep/home on a separate partition to make staying up with the 6 month cycle easier, although I do skip the occasional release.I had my parents on a Fedora box, but quickly saw that I needed a longer term, lower maintenance solution, and have them on Arch for several months now.I switched from Crux to Arch years ago but got off it when I had some update breakage issues or something that peeved me (o

We've been working on making non-stable Fedoras more manageable for day-to-day usage lately, with pretty good results. I'm on Rawhide (F21) already and it works fine, nothing is exploding. It's fairly feasible to run Rawhide day-to-day for an experienced user, these days - nirik (Kevin Fenzi) runs rawhide full-time, updated daily, on one of his workstations, and blogs about it at http://www.scrye.com/wordpress/nirik/category/rawhide/ [scrye.com] (as a part of the 'make rawhide suck less' efforts, a kind of long-term pu

Sounds like what Fedora really needs to do is simply fix FedUp so that it doesn't grow cluttered.

Personally it's been about 8 years since I used Fedora so I don't know what's up over there. But the aggravation of reinstalling every 6 months drove me from Mint to Kubuntu a couple years ago, and the latter has made the every 6 month upgrades a breeze. No need for a rolling release as long as the distupgrade can run in the background while you carry on as normal and applies with a simple reboot.

Fedora does not provide an LTS like release. Every release is maintained for 13 months, and new releases are usually released about every six months. The idea is that if you want a more long term release you should really go with Red Hat Enterprise Linux which is based on Fedora.