Fedora 20 released

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.

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

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

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.

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

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

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.

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.)

Please, let's not discuss Java EE.)

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 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

    $ 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:

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).

> * Ubuntu: decent base system, lousy desktop

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

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

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".

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

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.