Fedora 20 released(docs.fedoraproject.org) 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. |
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
- 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.
http://www.freedesktop.org/software/systemd/man/sd-journal.h...
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.
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
yum install rubygem-rails
Fedora seems to have one of best ruby support. Way to go!
What's the typical time lag before a package get updated after a gem does?
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.
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 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.)
- 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.
I'm sure I'm going to forget about that... I can't wait for the first WTF :)
Retina and retina-like users rejoice!
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.
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.
http://download.fedoraproject.org/pub/fedora/linux/releases/...
(Might still give a 404 until your mirror is in sync.)
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.
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.
If you opt for #2 submit it here.
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.
$ grep shiz /var/log/messages
grep: /var/log/messages: No such file or directory
$ 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:
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).
You mean the unity stuff? I installed the KDE Desktop package and it's great and works great =)
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.
Cool that you didn't run into the various issues that systemd makes easy. But various others have. Suggest giving it a try.
That's what RedHat (or CentOS) is for...
http://harmful.cat-v.org/software/java http://harmful.cat-v.org/software/OO_programming
> 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?
This is heavily disputed[1]. Please do not misrepresent your opinion as fact.
[1] Example: https://wiki.debian.org/Debate/initsystem
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"
journalctl -F
I don't get what you're complaining about, the fragmentation has been reduced :P
[1] http://www.freedesktop.org/software/systemd/man/systemd.serv... [2] http://www.freedesktop.org/software/systemd/man/journald.con...
How does this affect something like a remote syslog? Could I send the syslog output of my router to journalctl?
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.
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?
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.
`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.
systemd is not hard, it's just different. Those configuration files are a lot easier to generate and get working correctly.
It just baffles me whenever I look at it.
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.
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.
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.
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.
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.
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.)
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
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.
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.
If services dies, there is a problem that is still going to exist after restarting.
systemd will kick it back into gear if it drops.
No software is entirely bug-free, so I do like having them relaunch on failure rather than stay dead.