I have heard meteors making real time sounds as they streaked across the sky. It was during the 2001 Leonids meteor storm. It was in a city with not a blade of grass in sight. This particular meteor storm was widely reported as emitting crackling and hissing sounds:
http://www.spaceweather.com/me...

There has been some speculation about what could cause such sounds. Some have suggested that “electrophonic meteors” can cause secondary lower frequency vibrations to be heard simultaneously, but it is just a suggestion since good quality data is missing.

The RTFA discovery is just a part of a new series of discoveries that shows we know a lot less about meteors and comets than we thought we did.

What? The ZX Spectrum keyboard was years ahead of the competition with its square, flat, chiclet keys. It took decades before the PC industry realized its potential instead of emulating old typewriter keys. These days even Apple's Macbook Pro has flat and square keys, a clear tribute to the ZX "Speccy" chiclet keyboard.

On a more serious note, while the ZX Spectrum keyboard wasn't for touch typists, it had its advantages too: all the BASIC commands was printed on or above or below the keys, so it worked as a BASIC "cheat sheet". You only had to press "G" to print the command "GOTO" so it saved key presses and removed typos in the commands and functions etc.

The ZX Spectrum worked very well as an entry level PC with an emphasis on learning BASIC programming. I know several people who made a career in the IT business because of what they learned from programming the ZX Spectrum.

That CentOS must remove all traces of Red Hat branding is due to trademarks and what not. Not really a problem to do for any serious distro anyway. Red Hat has apparently been quite happy with CentOS for quite a while, since it generates new costumers and people knowing RHEL-like environments and developers too.

The corporate motive for getting directly involved in CentOS isn't trying to control a free edition of RHEL (there are many others besides CentOS), but is much more likely to be directed against Oracle who allegedly uses CentOS as Upstream for their Linux distro. Oracle haven't been smart enough to actually employ CentOS developers en masse, but with this move Red Hat can keep Oracle out of a controlling position in CentOS.

Red Hats direct involvement in CentOS has many benefits for its users; The steering and participation in CentOS have been opened up (it was a small, rather closed group before). The concept of "variants" seems most promising, since it allows people to work on CentOS variants without the need to actually fork away and become their own little distro island. So Sci-Linux are contemplating becoming a CentOS Variant so they can work on the software they care about, instead of all the extra work there is in maintaining your own distro.

Those phrases are totally content free. "political motivation" can mean sinister hidden agendas, or an impetus to stop social wrong doings. Accusing developer driven distros like Arch Linux for "political motivated mee-too" following is just plain laughable.

I don't find it credible that you, unlike all the really, really smart people involved in Linux distributions, are gifted with special clear sight, that makes you see the hidden caballistic plot behind systemd.

Sure, systemd is a new way of doing things on Linux, but it is worth it. There seriously isn't any love among developers or users for sysvinit anymore. It is a dead end that survived far too long in Linux.

Consider the possibility that you may be wrong, and that you just align your judgements along what is comfortable and known for you. And even though you like sysvinit very much, it wouldn't hurt you learn about systemd either.

There are two options here; either you are the bright and really informed person, that knows better than all enterprise Linux distros from Red Hat/CentOS, to Suse and Debian and all the other Linux distros switching to systemd, or else, they may have some knowledge and insight you don't have.

The fact is, that systemd, together with Wayland, kdbus, and cgroups, are the future Linux plumbing system and development stack.

sysvinit is simply on life support now, together with X. They both served well in the past, but they should both have been retired from Linux years ago. Now there are alternatives, superior in every way, which is why people join up behind them.

Don't get left behind when the future arrives.

Prudent caution and all that is all good and well. In the end is all about risk and risk assessment, and the first step to that is to be enabled to make informed assessments based on technical knowledge.

Most people react to binary log files with understandable scepticism, especially people who have been around some time. But initial scepticism isn't an informed position either. We are talking systemd here, the future Linux plumbing system on Red Hat/Fedora/CentOS/Sci-Linux, Suse, Debian, Arch Linux etc, etc. The future is likely to arrive where you work too, if you deal with Linux.
So I have been reading up on systemd and journald. I don't think you really have, and that is a shame.

My main point in any risk assessment is, that even if it possible to construct contrived scenarios where binary log files can be a problem, these freakish events are far, far outweighed by that many huge improvements systemd and journald gives the SA every day, on every machine, in all situations, from debugging to development.

So don't let prudent caution turn you into a technophobic Luddite.

Mixing binary metadata and text, well that sounds nasty to me. I wouldn't trade in the advantages of pure text log files for binary ones, unless there was huge improvement; a small, or even partially large improvement wouldn't sway me.

I think that journald is a huge improvement on all important matters over simple text log files; I was sceptical at first, but it is really well designed full of small features that shows it is made by people who cares about people working with CLI UI's. Tab completion everywhere, including switches like "journalctl --(TAB)" shows all full length switches. Nice.
It also knows about every field and record and their values, so you no longer have to plod through the log files just to see what the daemons are called, or even what daemons have written to log files. It just goes on and on with features that doesn't exist in syslog systems.

You may claim that some if not all these features could have been implemented in syslog, I personally don't think so. I have seen many syslog implementations come and go over the years, all hoping to improve the messy Linux logging. There have been improvements, but nothing comparable to journald.

It is not that syslog developers are stupid and lazy; I happens to think that many of them are quite sharp, like Rainer from Syslog-NG. So there are probably other reasons why they didn't improve things to the level that journald does.

Not sure what scenario exactly you are describing here, but if it is possible to mount /var in any way, or exports its contents with NFS or similar, or even copying files manually through USB, then it is possible to read the journald logfiles in that rather singular event that journalctl for some reason doesn't work.

I am sure that you can construct a contrived scenario where neither thing from above is possible, but that doesn't convince me at all. In the real world (and yes, I know how sucky it is to admin other peoples stupidly broken setups), it just isn't a problem that journald log files are binary.

It is on the other hand, easy to argue, that debugging broken systems are incredible more easy and powerful on systemd enabled machines; you get logging much earlier than syslog provides. Stuff like "systemd-delta" shows in an instant, exactly what non-default config files are used by the daemons and so on. The "-x" switch that enables Journal Message Catalogues; think how nice it would be, if the daemons error messages where explained in some detail, intertleaved with the actual log messages, but only when needed. Oh, including (click-able) links directly to those responsible for the daemon for further information.
Monotonic timestamps when comparing to different server's intertwined service and daemon startup, is a piece of cake on systemd. The list just goes on and on.

My point is, that for every contrived scenario where binary log files may be a problem, I can give multitudes of everyday scenarios where they and systemd, is a vast improvement over the existing Linux init and logging systems.

Oh, I can see you are quite new to Linux log files, they are basically free form dumps of whatever anything wants to write to syslog in any which way they please. It is impossible to make anything else than a crude GUI; a 'less' just with windows decorations. This is exactly why both Gnome and KDE dropped their previous attempt on making such a GUI.

I won't bother discussing the advantages of systemd and journald with you anymore, you have already made up your mind without any real technical knowledge or experience with systemd. This is sadly the attitude I see with many Linux users these days; gone are the glory days of curiosity and hacking, when new Linux technology was exciting, and people eagerly read the LKML for news. Today it is all about sneering at open source developers, and blankly rejecting what other claim should be rejected.

systemd fully support a separate /usr .

There may be solid reasons for a separate /usr, and Lennart agrees on that. His whole point is, that actual Linux distros no longer support a separate /usr, which result in spurious and hard to track and debug bugs, which is why systemd issues warnings with such setups, unless you use initramfs. You can always ignore the warnings.

He actually have a very fine technical explanation here:
http://freedesktop.org/wiki/So...

Oh, you miss one of the great joys of journalctl. Get the "bash-completion" package and try again. Basically every field, record and their values is tab-able.

try "journalctl (TAB)" and it will show you some field names like _PID, _EXE etc.
You can tab all the way in these examples:
journalctl _EXE=/usr/bin/umount (shows what umount has written in the log)
journalctl _TRANSPORT=stdout (journald captures all stdout, so this shows all log entries generated this way)
journalctl _KERNEL_SUBSYSTEM=usb (shows all usb messages generated by the kernel)

journalctl _MACHINE_ID=5644ac089b164945bfdc47a77f74324d (every machine has UUID, since hostname and what not changes. This is mostly useful when when working with multiple computer logs at the same time. The point is, that even with +100 computers in the loq file, it only requires a single tab after the "=" to show each and every one. And you may only need to key in the first digit or two, before you can use tab to complete the entire UUID.

Of course there is also full tab support for all switches
Try "journalctl --(TAB)"

Sure db's may get corrupted, but are useful too, or otherwise we would all use flat file text databases for everything.
Anyway, the journald log files isn't a pure db, it just feels like it because it is structured and indexed. Here is what it says on the label:
"The systemd journal stores log data in a binary format with several features:

        Fully indexed by all fields
        Can store binary data, up to 2^64-1 in size
        Seekable
        Primarily append-based, hence robust to corruption
        Support for in-line compression
        Support for in-line Forward Secure Sealing"

So it appears to work exactly the same way as you describe text log files, with its append based approach.

Corruption in syslog text files happens all the time. The process may be killed in mid write, a hard shutdown may truncate a message etc. But it is extremely hard to verify loosely structured text files. journald OTOH have internal verification: "journalctl --verify" (don't drop your pants when it shows corruption, it just shows those dead writes you never notice in the text log)

While journalctl have some ability to read corrupted fields, there is still room for improvement according to Lennart Poettering with the exact problem of reading after the corrupted place, so they are working on being able to salvage as much information as possible from a corrupted entry/file, no matter where the corruption occurs.

I can only recommend to spend some hours going through the documentation and examples on this site:
http://www.freedesktop.org/wik...

Examples on how to use journaltctl
http://0pointer.de/blog/projec...

Man pages:
http://www.freedesktop.org/sof...

Description of some field values:
http://www.freedesktop.org/sof...

About the journal file format:
http://www.freedesktop.org/wik...

Enjoy.

Well, I don't think the rescue shell sees much action then, and if nobody file a bug report, then it could take a while before it is fixed.

Just run syslog alongside journald, and you will have all what you are used to have. You even gain many benefits like earlier logging in the boot and other things. You can even turn of that journald uses any storage space or binary logs, but just let it forward everything directly to syslog.

Personally I don't find it needed, though I ran my Fedora desktop like that in the beginning until I weaned off my old fear of binary log files.

Yes, that is true last time you checked, and next KDE edition (KDE SC 5/Plasma 2) will of course also run on *BSD. But with reduced functionality on all non-systemd systems, compared with the systemd version.

This is not because of some sinister conspiracy, but because systemd offers easy use of many nice features that KDE and Gnome (and LXQT etc) would like to use, and non-systemd systems doesn't provide.

The point is exactly, that systemd is a very nice uniform Linux plumbing system, and that DE's are starting to take advantage of that.

systemd is going to make your life so much easier in the future. I suggest you take your time to do some serious study on it, it will really pay off.

But to the point: you don't have to support a myriad of Linux's. If the rescue boot media can booth the hardware and read the filesystem, then you can read the journald log files. If the original system is up, then if NFS or similar works, you can also export the journald log file directory and work on it on a remote machine.

systemd solves this problem in a rather elegant way. It could in theory then just dump the log files in a semi structured text format, but then you would lose the power of an indexed log file. That index is insanely useful and extremely fast. And there is transparent auto compression, integrity checking, sealing, and all sorts of nice things you can do with a structured database.
The many advantages of a binary log file format, far outweighs any advantages by using a text format.

Come on, that syslog isn't included isn't a problem for anybody remotely interested in having a text file copy of the logfiles. A simple command like "yum install syslog" will deal with that.

But the fact is that syslog just isn't needed on most Fedora installations. Syslog-ng is still useful as a log sink, but isn't needed on systemd systems.
journalctl is simply such a good tool, that I fail to see what benefit a duplicate text copy of the log files will provide, unless there are some legacy stuff that needs support.

This is most likely because the system is waiting for a disk that actually aren't there or a variant of that. So use "nofail" , "nobootwait" or "x-systemd.automount" if you mess with fstab and aren't sure your changes will actually work on boot, or if it is a removable drive etc.
There is a short discussion of it here:
http://www.reddit.com/r/archli...

IMHO, systemd is doing this the correct way; if a disk is suddenly missing at boot, it is considered a critical failure that must be fixed from eg. the rescue console, before the system continue. That sysvinit would plod along with booting without system critical disks coming online may be convenient for those who makes error in their fstab, but may be a outright disaster for other users.