Fedora 20 released | Hacker News Reader

Fedora 20 released

docs.fedoraproject.org

124 pointsdrill_sarge101 comments

Download: https://dl.fedoraproject.org/pub/fedora/linux/releases/20/

More mirrors here, but not all servers are synced with 20 yet: https://mirrors.fedoraproject.org/publiclist/Fedora/20/

No announcement yet, link in title leads to release notes.

Open articleView on HN

Here are the torrents: http://torrent.fedoraproject.org/

x86_64 DVD: http://torrent.fedoraproject.org/torrents/Fedora-20-x86_64-D...

magnet:?xt=urn:btih:724bcc8a53b854daa844e6bc204b95124a1074d6&dn=Fedora-20-x86%5F64-DVD&tr=http%3A%2F%2Ftorrent.fedoraproject.org%3A6969%2Fannounce

i386 DVD: http://torrent.fedoraproject.org/torrents/Fedora-20-i386-DVD...

magnet:?xt=urn:btih:d6d123d9a9b108971ecb09ca6593d2593cd564a4&dn=Fedora-20-i386-DVD&tr=http%3A%2F%2Ftorrent.fedoraproject.org%3A6969%2Fannounce

Seeing the removal of syslogd, getting more than a bit grumpy here at the continuing direction Redhat is dragging the Linux world. Journald may serve the basic user well, it can't do half the stuff a good syslogd configuration can do; it can't pipe messages to other processes, it can't send messages to remote servers, it can't send messages to multiple places. If redhat had put in services to let journald do the things syslogd's been able to do since forever, I'd be more ok with its direction, but as it stands, it's proprietary in all but name.

AFAIK it's quite easy to hook up rsyslog to it and then it doesn't make a difference.

That seems a bit inefficient to me, you'd end up with both binary and textual log files.

Presumably if you want syslogd's features, it's for something other than the text log files (logging to SQL, network logging, ...).

If you're doing this, you probably want to disable saving the binary logs -- journald will still retain recent logs from the current boot, so the status commands will still work.

Personally, I uninstalled syslog and enabled binary log retention back when I was running F18, and I'm wishing my Ubuntu and Debian boxes had the same ability.

If you need syslogd, isn’t it as simple as yum install syslogd and then you’re sorted?

I can, however, again, it's a pretty poor direction that only serves to fragment systems. Many of the complaints that drove the creation of journald could have been better solved through a better default syslogd configuration. Additionally, the journald solution for needs such as remote logging or logging to multiple locations means that you now need to pipe through a process that has a near sole job of piping to another process. It just gives a very bad feeling of hackishness to me.

I don't think the fragmentation claim stands up to scrutiny.

It's so far been adopted by redhat, suse, arch, coreos and with some consideration by debian. The only big name not thinking about it is Ubuntu.

I don't think that many of the journald drivers could have been solved by better syslogd configuration, for example journald cryptographically signs each log entry. Even if you get root on my box, you can't edit an entry without me knowing. That's not possible in any meaningful way with syslog.

I don't share the view of a hack, the speed improvements of introducing journald have been tremendous and usability is mostly better.

For example, the number 1 thing done with syslog output is probably either grep it, so journald improves on this:

    journalctl _COMM=sshd --since yesterday --until "08:30"
    OR
    journalctl /usr/sbin/sshd --since yesterday --until "08:30"

Or tail it

    journalctl -F

The places i don't like the user interface are around starting and stopping services. However the old interfaces work fine for now.

Think bigger than Linux. Think those with freebsd boxes, netbsd boxes, solaris boxes, etc. They're all very much relevant, but left out in the cold by deliberate decisions of the systemd folks to eschew compatibility. Functionality-wise, journald has no way of acting on the messages it receives. With syslogd, it's fairly trivial to write a script that will send a nagios alert every time a service is restarted, for example. How does one do that with journald?

systemd itself provides the functionality to run commands at points during the lifecycle of a service[1]. As for the people in mixed environments, you can forward journald to syslog [2].

[1] http://www.freedesktop.org/software/systemd/man/systemd.serv... [2] http://www.freedesktop.org/software/systemd/man/journald.con...

That's a tiny sliver of what you can do with syslog piping. For example, fail2ban works by piping the contents of the auth stream of syslog -- usually also put into auth.log -- into a script that monitors for bruteforce attempts. This kind of reactivity is a lot harder on journald configurations.

ehm. no. it can just stream the output of `journalctl -f`.

it can filter even better than before, because fail2ban usually does not care about everything in `auth.log`. i guess i don't see the problem.

There have been various tools which have done this. And a lot had huge security bugs. Despite what you claim, this is also easily doable with journal plus similar solutions are available for journal.

The init system differed a lot across distributions. Systemd made it more the same within distributions. Solaris uses something systemd like. *BSD use their own thing.

I don't get what you're complaining about, the fragmentation has been reduced :P

Sensible command line UIs? You've made a believer out of me.

How does this affect something like a remote syslog? Could I send the syslog output of my router to journalctl?

RedHat Fedora makes no apologies for dropping legacy support. Heck, they threw out ifconfig in Fedora 19.

It's good to be dropping things like syslogd from the default distribution, and the only reason it was ditched was because syslogd is behind the times.

Yes, syslogd does more. If you want those features, install it. Forcing it on everyone, regardless, serves no purpose.

> RedHat Fedora makes no apologies for dropping legacy support. Heck, they threw out ifconfig in Fedora 19.

WTF? Is that because Linux was becoming too easy to use? They have to keep changing it up, so the certification classes have new material to teach. Why wouldn't they keep the command around and wrap whatever re-invented mousetrap replaces it so millions of people can keep typing ifconfig?

It's because change.

Change is how you abandon things that are holding you back. It's how you get rid of the various albatrosses, of which there are many, and clean up the environment for new users.

ifconfig is absolutely not easy to use.

ifconfig was deprecated on linux long ago. While it is compatible with other unixes, it doesn't really map onto the capabilities of the modern linux stack well.

`ip` really is a better tool, and you're doing yourself a disservice if you're not using it, especially if you have anything more than the basic single IP/default gateway network.

> ifconfig was deprecated on linux long ago. While it is compatible with other unixes, it doesn't really map onto the capabilities of the modern linux stack well.

Long ago? Centos 6.4 still has it. My Mac (BSD) has it. I never suggested that it is stupid to add software (ip) that is better, but why would they deliberately remove it when it is such an expected command and works across other unixes? I have trouble believing that it consumes much disk space.

CentOS is not removing deprecated things and Fedora is. This is the difference here.

See: http://en.wikipedia.org/wiki/Ifconfig#Current_status

"Modern Linux distributions are in the process of deprecating ifconfig and route..."

Deliberately removing something means you don't have to maintain it any more and can spend your time improving the better tool rather than bug-fixing the legacy one.

I understand improving, but it wouldn't take much effort to make it user friendly, by wrapping over the ifconfig command for at least the reporting functionality. It could still call ip underneath.

There are ways to handle it that make it backwards compatible and user friendly without only a little extra effort. It's not a sexy task, so who cares about usability.

Its only removed from the default install. A lot of fedora users (e.g. desktops) don't really need most of what syslog can do, and those that do can easily install it.

Fedora is the distro Red Hat uses to test stuff like this. I imagine the full functionality will be available and well understood before a RHEL release incorporates it.

It's not a direct replacement. Journald does stuff that syslog can't do, but it doesn't reimplement everything. Instead, you can pipe to syslog if you want syslog features.

- Journald logs the whole boot process

- Journald can make sure that an item really came from some process. It also tries to seal the journal so that it can't be tempered with.

- It's built into the other systemd tools. For example, when you notice a daemon doesn't start through systemctl, it'll show you the error messages in systemctl status.

Note that the second point is quite important -- it provides a rolling hash of the journal contents that you can send to another machine, so that in the event of a break-in, you can detect any tampering with the syslogs. As I recall, this was inspired by the break-in to the kernel.org servers, where the attacker tampered with the log files. That would be impossible with journald.

There are syslog daemons that can provide cryptographic security as well. Alternatively, they can also log directly to an SQL database, use SSL client certificates, etc. Modern syslog daemons are quite powerful.

Yeah, but journald works even on plain stdout, stderr. It's hard to beat that.

It also provides a pretty sensible API for walking through the log from programs.

http://www.freedesktop.org/software/systemd/man/sd-journal.h...

It isn't what you want, but that certainly doesn't make it proprietary!

It's an obvious power play by RedHat to force people to use SystemD which is nearly liblinux at this point. As the project subsumes other projects and adds more and more functions that directly rely on SystemD you'll be harder and harder pressed to run a system without it.

One needs to look no further than what their plans for cgroups are to see the future. Not to mention the plans to get rid of /bin/login and VTs.

It's systemd. The way the project is spelled has been explained multiple times. Your criticism is bit weak if you insist on spelling things incorrectly seemingly on purpose. Gives the impression you might also not be completely showing things in an objective light. But oh well.

Anyway, your entire complaint is explained at every systemd presentation. The maintainers want to have something which can be used as the basic building block for Linux. Various other projects now rely on that.

So systemd is successful, but surely it is a conspiracy! hahaha

With Gnome 3.10. Nice. Even nicer with the Phosphene theme: http://hdni.github.io/rice/assets/phosphene_preview.png - https://github.com/hdni/Phosphene

Looks really nice! How jarring are non flat designed windows such as chrome/evolution etc? Do they look a bit "too" ill fitting?

The dialogs definitely look nicer than your standard Gnome dialogs.

Ruby Devs, Take note, Fedora 20 has ruby 2 & rails 4 available. to get started with rails, all you need to do is:

   yum install rubygem-rails

and Bam, it will install latest ruby, rails & other dependencies. That's not all, they have more than 2thousand ruby related packages(all recent versions).

Fedora seems to have one of best ruby support. Way to go!

https://apps.fedoraproject.org/packages/s/ruby

How does one decide whether to install from a package repository, or directly via gems?

What's the typical time lag before a package get updated after a gem does?

Package repository may bump versions without warning, and lags behind gems. There is no typical lag time, it's updated whenever the packager feels like it. You can file bugs at redhat bugzilla to try and motivate them to update packages sooner, if you want something specific.

On the plus side, you get security updates, and any gems that are packaged should be compatible with each other to some extent. In general, I think ruby packages are good for end-users, but maybe not great for developing ruby applications or other gems.

(I don't mean to rag on Fedora packaging here — I'm a Fedora packager! I just want people to be aware of the limitations of distro packaging.)

I avoid package gems like the plague. It makes dependency management a gigantic pain in the ass and forces you to target your code to a specific version of an operating system. You can't take a system that works just fine in Fedora and move it to Debian without making sure the gem version differences don't break anything.

In today's cloud-based hosting environment, you want to preserve mobility whenever possible, and Bundler does a better job of managing Ruby dependencies than dpkg/yum does. You can then use configuration management to get a system bootstrapped to a base where all your Ruby projects can run, then Bundler can take care of project-specific dependencies. It's not perfect, a lot of times a project gem will require system dependencies, like MySQL, but the separation of concerns does help a bit.

You should, however, use system Ruby because using RVM / Rbenv in production vastly increases complexity, and because the system dependencies that your gems have will be the right versions. It's much easier now that the latest Ubuntu packages Ruby 2. It took me all of an afternoon to redo the configuration management and provisioning and migrate my projects when Ubuntu 13.10 came out.

''syslog is no longer included in default installations. journald logging serves most use cases as well as, or better than, syslogd.''

I think it has lots in common with this:

"Fedora 20 includes the WildFly 8 Application Server, formerly known as the JBoss Application Server, a very popular Java EE platform. WildFly is a very fast, modular and lightweight server."

keep producing more and more bloatware, without any other reasons than "because we have done it".

I think that blindly allowing freedesktop guys to mess up all the traditional Unix startup and now logging tools with some MS-inspired crap for a very questionable reasons is quite a step back.

It is also an example of an over-engineering bias (which comes from OO-only approach) - building up an unnecessary complexity. syslog and shell script based startup procedure are good-enough (and still good enough for sane systems such as BSDs or Plan9), while those who need a specialized logging (or startup) service could create it for themselves, as so many do.

Changing reasonable defaults just because someone is cocksure that we need more xxxxctl and xxxxx-bridge instead of plain old text-files looks like ignorant over-confidence. Those who cannot live without journald could install it manually, why to cause a headache to the rest of us.

I do remember that commercial variant of Suse Linux have tried "an innovative approach" to what a Linux server is. They introduced a set of some in-house made utilities (inspired by Netware I suppose) with non-intuitive logic and millions of command line options no one knows (which cannot be googled). Why, it is a way to success, now you could teach courses, do certification, issue meaningless titles, etc. Thank god its dead. ESX servers, btw, were (or still are) even bigger mess.

I doubt that Fedora is going this way, but the signs are bad.)

1. you don't have to upgrade 2. fork it and "fix" it

If you opt for #2 submit it here.

What the fuck are you going on about? WildFly is now included as an _available package for install in the repositories_. This is why it is in the release notes.

This is like complaining that any disto is "bloatware" because their repositories include software that you happen to dislike and think is "bloat". $distro is bloated because KDE/GNOME/whatever is an option, right?

Get a grip.

Please, let's not discuss Java EE.)

I don't know what experience you have with modern Java EE, but it's incredibly modular these days and is no more than a collection of components that can operate independent of each other.

Of course, I am nobody to criticize the sacred things, so there are few links to the people who are worth of paying attention to (and who gave us golang).

http://harmful.cat-v.org/software/java http://harmful.cat-v.org/software/OO_programming

So with a handful of out of context citations and some rather retarded points of view (Greenspun WTF?) you are trying to convince people? Really? At least give it _some_ effort. This way it is rather boring...

I just gathered that he's a PL design and theory zealot.

I had similar sentiments when Arch made the move to systemd but I think I've come to like it. Things seem to be a lot more stable than with initscripts.

For me it looks like a fix for what wasn't broken.

I think that the only reason to re-write something that is good-enough is to make it even simpler, more clear and, in some rare situations, more general (but what could be more general than text files and pipes?)

Imagines someone in physics would say "this equation is not clever-enough, it lacks linear algebra, let's rewrite it using vector notation". Guys in physics are using vectors because it is the most convenient way to represent some aspects of reality, not because it is clever or popular. Similarly, the mantra should be "simplify" (and generalize).

Anyway, thank god, they didn't bring some nice, little "real-time, non-blocking log collector" written in a nice, object-oriented, modular NodeJS with some nice little MongoDB-powered clustered storage.

As mentioned in many of the previous threads: Did you ever had to maintain services? Debug why openldap wouldn't startup? Then figure out what the actual command it would run? This all to get to the stdout&stderr output? While journal makes this available by default? Aside from just reliably stopping services and reliably being able to configure services (configuring, not editing shell scripts which all are similar but different enough to be annoying).

Cool that you didn't run into the various issues that systemd makes easy. But various others have. Suggest giving it a try.

Just for the record:

- I've been using Fedora (VM, test, production server) since release 4 or 5. - I have a VM that has been updated without full reinstall since release 11. It will be destroyed soon, as I'm reinstalling the host. - I've been using Fedora as my main desktop since Fedora 16.

My experience varies, depending on the sh*t they decide to push (like Gnome 3 or systemd). It takes time so that things get stable (or I get more used to them).

As a full stack developer, I almost never use distro packages like gems or python libs or java libs. Even tools like Eclipse I prefer to install them separated.

Overall, I'm satisfied.

What excellent docs, I don't think I've ever read all the release notes like that. I'm wooed, gonna install this on something.

"Syslog removed from default installation" and "Users accustomed to checking /var/log/messages for system logs should instead use journalctl."

I'm sure I'm going to forget about that... I can't wait for the first WTF :)

It's quite an audacious release note. As if millions of users are suddenly going to forget about cat, head, tail, more, less, grep, awk, sed, fmt, etc. etc. that are only still useful if you learn how to journalctl and convert those binary logs back into plain text.

I'd like to install Fedora 20 and use it as my main desktop, but both systemd and journald will somehow have to be avoided and worked around because I don't want to touch those with a ten foot pole.

As far as mainstream Linux distributions go, it's like choosing between 2 evils nowadays:

* Ubuntu: decent base system, lousy desktop

* Fedora: lousy base system, decent desktop

The former is almost fixed by Elementary OS, but the latter I'm still looking for a spin or derivative that fixes it. What attracts me most to these mainstream distributions is the vast amount of available packages and their ease of maintenance.

I don't usually have the need to check syslog in my desktop, unless I'm doing development, and in that case I will install syslog-ng (and systemctl enable syslog-ng). Not a big deal.

As for servers, I wouldn't use Fedora. Each release is supported for only 13 months and upgrades are not as seamless as in Debian.

So for me Fedora is a very decent desktop if you want the new shinies with ease of use. Most of the time works and it's great (even with the "Gnome 3 surprise factor", that keep _breaking_ things every now and then).

> As for servers, I wouldn't use Fedora.

That's what RedHat (or CentOS) is for...

Or Scientific Linux.

You can do "yum install rsyslog". However I agree that it shouldn't have been removed.

That's nice, but can you "yum install upstart"?

No. Why would you want to? Upstart is inferior to systemd in every way and if Fedora supported both then it would have to test every package that contained a daemon twice.

Because upstart is easy and systemd is difficult.

Linux is hard, let's go shopping!

Removing upstart is a feature.

systemd is not hard, it's just different. Those configuration files are a lot easier to generate and get working correctly.

As a user, I can't tell what service is started when by which config file and where it should go. multi-user.target.wants? default.target.wants? Why are there windows-style .ini files and why are they all symlinks to /usr? Is it forbidden to make changes now? Really, RedHat?

It just baffles me whenever I look at it.

You're just grasping at straws.

Not really, I just prefer the Unix philosophy of doing one thing and doing it well. I hated upstart when it was introduced too, it broke stuff so I had to replace it with the unsupported (but fully functional) sysvinit every time. I still don't like the fact that it obsoleted /etc/inittab and that it has both old fashioned /etc/init.d and a /etc/init, because I have to look in 2 places to find a config or script. But it does give me a getty on whatever I set as console on the kernel commandline and it's definitely not broken out of the box any more, so I'm game.

You might think of a tiling window manager as being the greatest invention since sliced bread, but having to configure it in Haskell FFS (I'm looking at you, xmonad) just doesn't jive with me. Nor does any other tiling window manager except WindowMaker (oh, pardon me, that's a tiled window manager). KDE is just as bad because it has too many bells and whistles, it doesn't follow KISS principles. Is that a straw man to you?

Gnome managed to create a nice iteration of gnome-shell with 3.6, but it was riddled with bugs (it still is, albeit to a lesser extent). Then they had to ruin it in 3.8. Categories are for losers, right? Let's remove that. And no one ever needs accessibility, right? Let's git rid of that, too. And what's with all these keyboard layout options? Can't have that, way too useful! Yeah we put some of them back in gnome-tweak-tool but not all because obviously no one ever used them for anything. The final straw for Gnome (for me) was when shell extensions that were never meant to appear in the lock screen, did in fact, appear in the lock screen. The gnome-screensaver they got rid of did one thing really well, but they couldn't find a way to let it display notifications so they axed it.

I'll do my best to make Fedora 20 work because it offers the option of installing MATE, which is Gnome 2.x based. So it packages all of the latest gizmo's (for better or worse) and presents it with a friendly face without an identity crisis (it knows it's a PC, not a tablet). Though I'm on my 3rd install now, at some point the installer stops working resulting in a blinking cursor when I turn it off and on. It works perfectly in a VM, but I want the real deal. (It did pass verification.)

Right, so Bash is Unix right? Bash does tcp connections. Oops!

Anyway, blindly following some theory is a bit strange. Systemd is several different components. Maybe you're heard of coreutils, kind of important on any Linux system. It doesn't do just one thing. I guess you think coreutils should be removed as well?

Anyway, no clue what GNOME has to do with systemd. As said: seems you're grasping at straws. Haters gonna hate :P

I just got off on a tangent and ranted away. Coreutils is a package, you're comparing apples and oranges. Fedora works as a baus now and it's very usable out of the box, it even packs the latest version of Eclipse! Except for a few forbidden items, it's pretty much a laid back (feet on desk, cigar locked in fingers) operating system (to use that is, the devs are probably working tediously).

What else would you wish for? A registry that can get randomly corrupted, complete with nonsensical keys?

It's baffling, but there's reasoning. systemd is actually pretty slick at the core. A lot of the complexity comes from how flexible it is.

What else would you wish for? A registry that can get randomly corrupted, complete with nonsensical keys?

That makes no sense. We had a perfectly working init called System V init. That's an alternative here, you may be looking at the wrong operating system.

A lot of the complexity comes from how flexible it is.

I think the complexity comes from trying to do too much at once. It's an init, but also cron. It's still an init, but also inetd. But it is still init, yet also acpid. Although it is in fact, still init, it's also atd.

And all of its functionality is available as a DBUS API. The only users are developers writing programs, not anyone banging their keyboards at the commandline prompt. That flies into the face of everything that made GNU/Linux great. Dbus is the death of GNU as we know it. The *sh oneliner that uses pipes and plain works is much better than the far more efficient C (or programming language du jour) program, even if it's only 10 lines of code.

System V init was decent enough for the time, but today it's relatively garbage compared to the alternatives.

Services die? Oh well, I guess they'll just stay dead. At least systemd has a wrapper that restarts them.

Also the "write a shell script with magical comments in it and lots of low-level bash" is not an elegant solution to any problem.

Fedora's been pretty good about supporting legacy sysvinit style scripts and there will always be a way to use them.

System V init could restart a service, that's how you got to log in after logging out. Even so, you actually need init to restart your important service process that should never die in the first place? Now that's just sloppy ;)

> Services die? Oh well, I guess they'll just stay dead. At least systemd has a wrapper that restarts them.

If services dies, there is a problem that is still going to exist after restarting.

I've had named blow out and it doesn't get restarted, it just stays dead. Rebooting the server is a heavy handed fix.

systemd will kick it back into gear if it drops.

Use nsd and/or unbound, they're more robust and faster than bind.

Good to know, hadn't really had a chance to explore those yet but will.

No software is entirely bug-free, so I do like having them relaunch on failure rather than stay dead.

Before systemd, Nagios was employed to do that and alert you when it happens. It's still a good idea to have proper monitoring set up, be it Nagios/Icinga, Zabbix or something you know will fit the bill. In good fashion of Unix philosophy, a combination of components works really well. This repository has most of them: https://github.com/monitoringsucks/tool-repos

> No. Why would you want to? Upstart is inferior to systemd in every way...

This is heavily disputed[1]. Please do not misrepresent your opinion as fact.

[1] Example: https://wiki.debian.org/Debate/initsystem

> * Ubuntu: decent base system, lousy desktop

You mean the unity stuff? I installed the KDE Desktop package and it's great and works great =)

Xubuntu is very nice as well (13.10). I'm dual booting with Debian 7 XCFE to try to reverse engineer the font rendering on Xubuntu which is much nicer to my eyes.

> As if millions of users are suddenly going to forget about cat, head, tail, more, less, grep...

    $ grep shiz /var/log/messages
    grep: /var/log/messages: No such file or directory

WTF?

    $ ls /var/log
    README    dnf.log wtmp Xorg.log.0    ...
    $ head /var/log/README
    You are looking for the traditional text log files in /var/log, and
    they are gone?
    
    Here's an explanation on what's going on:

Crisis averted!

Millions of users will have "Logs", an UI for the journal. Because journal logs more and allows more things, the UI will be more useful. Easy to do with journal (log attributes with each message), impossible with "/var/log/messages".

You mean a CLI-UI?

Yeah, it's got a really handy CLI interface, called journalctl.

The original person (maybe you, too lazy to check) was worried about millions of users. So I talked about a GUI, not a CLI. The CLI has existed for a long time as mentioned by someone else.

Are you talking about this quote?

> As if millions of users are suddenly going to forget about cat, head, tail, more, less, grep, awk, sed, fmt, etc. etc. that are only still useful if you learn how to journalctl and convert those binary logs back into plain text.

How does one use a GUI with cat, head, tail, more, less, grep, awk, etc? If they are needing to use normal unix commands, why could you think they have access to a UI?

Also note, this is the first Distro (that I know of) that is resolution-independent out of the box -- thanks to Gnome 3.10.

Retina and retina-like users rejoice!

OpenSUSE 13.1 released with GNOME 3.10 already :P

OpenSUSE renders the fonts horrible, I don't know why is that.

Download: https://dl.fedoraproject.org/pub/fedora/linux/releases/20/

More mirrors here, but not all servers are synced with 20 yet: https://mirrors.fedoraproject.org/publiclist/Fedora/20/

No announcement yet, link in title leads to release notes.

Quick question:

Anyone has succeeded dual botting Fedora 20 with Windows 8.1 in a UEFI system with secure boot?

When I tried the beta it made Windows 8.1 unbootable.

Are you sure it didn't just replace the UEFI default boot entry? You should still be able to boot Windows after getting into GRUB, but if it messed up your EFI partition, that's a bug.

That's what it did, it messed with my EFI partition, so, that's why Im askin if someone has succeded with the latest reléase.

Direct link to ISO:

http://download.fedoraproject.org/pub/fedora/linux/releases/...

(Might still give a 404 until your mirror is in sync.)

Alternative Mirror; http://fedora.mirror.nexicom.net/linux/releases/20/

Better update, I am behind. I run Fedora on my powerpc machine (Mac Pro) as it is the only distro (well and RH itself) with decent ppc64 support, as IBM pays Redhat still.

While on the topic, does any one have a good strategy for building the gstreamer-bad/ugly plugins on Fedora? I don't like the rpmfusion repository as it always seems to mess up the system sooner or later.

Why not grab the SRPM and just rebuild it yourself?

I always have rpmfusion (http://rpmfusion.org/) enabled, and I've never seen it mess up anything.

This is great. :-) This is still in beta.

Reply on news.ycombinator.com