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.
Do the phrases "designed by committee" and "political motivation" mean anything to you? The "other distros" are jumping on systemd as a "me too" reaction more than any real technical merit. (generally, the people making the call are not technical people.) GNOME and udev are two of the prime pushes to go with systemd -- as systemd has eaten udev, and GNOME requires logind. systemd does have a few pluses, but it also hauls in a truck load of unnecessary, and complex, bloat.
I don't give a shit what the systemd or upstart camps claim about shell scripts; writing, testing, and debugging init scripts is trivial. (making a single script for *every* distro can be trying, because they all do things a little different. if you think distros aren't going to do the same thing to systemd, think again.)
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.
Instead of actually getting together to make an alternative development stack to systemd
We don't need to. sysvinit WORKS; it's stupid-simple, small, and trivial for anyone with a brain to actually manage. I don't get the whole push for databases, binary logs, 100k+ lines of C code... to do what a few hundred lines of shell scripts and config files have done for decades -- with a shell that's going to be on the system anyway.
(I'm not saying the BSD way of *one* shell script (rc.conf) is the way to go, but systemd is the super-complex bazaaro version of rc.conf.)
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.
Heh, I would have phrased it a bit differently: "Until I threw my prudent caution about relying only on binary log files to the wind". But as long as I don't employ you in IT, it is only a preference. And hey, I don't rule out that I might evolve to the same preference.
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.
My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.
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.
A simple command like "yum install syslog" will deal with that.
Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.
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.
I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you can write an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable.
So your arguments in favor of binary log files seem quite moot.
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.
Modular filesystem permissions (I can mount/usr/ ro,nodev, / requires dev and write access
There are others, but that's just off the top of my head.
I've been watching Poettering's comments and attitude, and have to say I've got a bad feeling about this. Too complex. Not a sufficiently compelling use case.
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.
Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?
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)"
And because it is a db file, it can also get corrupted. And a corrupted db is almost impossible to extract anything useful from. A corrupted text file, which is only appended and never positioned ahead of EOF, can be read perfectly up to the point of corruption, and with some work can be read after the end of the corrupted section too.
All that aside, I grant the pluses of the journal, and as long as I can run syslog in parallel, I guess I don't have any sunstantial issues. It should never be mandatory to have the journal though.
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:
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.
Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?
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.
Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.
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.
How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it.
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.
If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).
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.
Additionally, it seems to be easy to break systemd's boot scripts in a way that prevent systemd from being able to boot the system (it's happened to me over and over again through what seemd like innocuous user actions), and I have never successfully gotten systemd to boot into its recovery shell.
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.
With a boot media it is a piece of cake to read the journald log files.
My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of those projects have to be aware and pick up updates.
That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.
If you run a distro using systemd, LVM, Btrfs, or any other such newish technology, you need a boot media to match, and not rely on your old 1995 edition of Yggdrasil Linux. Floppies just aren't reliable these days anyway.
I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.
It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling.
First of all, the systemd log file format is fully documented and covered by the interface stability promise. Look here for more information: http://www.freedesktop.org/wik... So it isn't going to change suddenly. So it isn't a problem at all.
Secondly, there are already many tools and programs that can directly read and manipulate the journald log files. Among these are of course good old syslog-ng that now handles such log files natively. There are more to come, especially since it is now possible to make GUI logviewers that actually work because of the structured file format.
The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.
I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.
Not sure what exactly you are complaining about here, so I am guessing.
Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way), and because the present logfiles effectively had become an API because of those many many log analysing scripts SA are using. Of course, there was also several different syslog variants too.
It is of course very easy to convert journald log files into text files if that is what you want, syslog will do this automatically, but it has excellent export tools too.
It is quite possible view MS-Windows event-log files from Linux. You can't use cat or less, but there are actually programs available.
I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring/usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.
No, systemd didn't break anything. It is merely the messenger that tells that a separate/usr is a broken idea on a modern Linux. systemd works fine with a separate/usr, but your Linux distro probably doesn't. Just use "initramfs" if you actually have a real need for a separate/usr.
Obviously, there's been a big push across the board by many various distros, but what are the real benefits of systemd? Is it better for average end-users (Easier? Faster?) or those more technically inclined (more stable, uses less resources, more configurable)? Or is this simply a case of it just being non-Canonical?
First, sysvinit sucks. All other Unix'es have abandoned it years ago. Only lethargy and lack of real improved Linux init-systems kept Linux on this sinking boat.
Linux distros have historically been extremely fragmented with no commonality between them for doing even simple things. It is impossible to make a simple distro agnostic gui that shows what the distro is called, or how to set time, or change the network values. There are probably 20 known different places that distros hide their name and release number.
There was also a widening gap between the development of Linux kernel features, and what user programs actually used. There simply wasn't any common infra structure.
systemd is an (very successful) attempt to create common Linux plumbing system that tries to solve the problems described above. It is incredible helpful towards all desktop environment developers with such a common and uniform platform, they can now easily make distro agnostic programs that can do interesting and useful things, and eg. both Gnome and KDE can remove huge chunks of fragile code concerning user and session management.
By tying the init system with the kernel, it suddenly becomes possible to do things impossible before, like logging from the second the kernel gets boot strapped, or using cgroups to ensure that important things gets priority (from desktop startup process, to give priority to foreground video's)
From logging, to program development, to speed and resource improvements, systemd is superior to anything else out there on every thing that is even slightly important. That is why almost every distro is embracing it, or is going to adopt it in the future (even Slackware will in the end). Disregarding rants against one of systemd main developers, Poettering* and empty platitudes about "UNIX philosophy" or "KISS", systemd is simply the most technical superior Linux init system in existence.
So the future Linux development stack is systemd, cgroups, kdbus and Wayland, It is an incredible powerful combo.
*Poettering, a main systemd developer among the +400 contributers, are often accused of making sound actually work on Linux with his Pulseaudio sound daemon. A crime not easily forgotten by those people that now posses useless knowledge about arcane Alsa rituals needed to do anything useful in the days before PA.
... If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
Anybody without a proper rescue boot media is up shit creek when a system is so broken that the binary tools doesn't work any more, be it journalctl or grep or cat. And frankly, working directly on system with a RW filesystem where fundamental tools doesn't work is simply bad practise anyway.
With a boot media it is a piece of cake to read the journald log files. You can even merge them with the boot media's log files to compare the boot processes. systemd and journalctl are designed to work with multiple log files from different machines at the same time, while doing wizard-like sorting and comparison, and integrity checking, and...
So even in this situation systemd is superior in functionality compared to old style syslog text files. Yeah, I thought that binary log files was an evil thing too, but systemd's implementation proved my prejudice wrong.
I think Pulseaudio was a great step forward for sound on Linux. Yes, it did uncover many sound card driver bugs, and bugs in Alsa back in 2004, but that also meant that those bugs got fixed. My internal sound chip was somewhat flakey before pulseaudio, and PA simply broke it completely, but that also meant, that when the bugs was fixed, the sound chip driver and Alsa layer worked perfectly ever since. I just used a popular and well supported SB compatible sound card instead while the bugs where fixed.
At the time, every other sound daemon was neither system wide, nor working properly. PA solved all problems in a rather elegant way, so for nearly a decade Linux have had an excellent and powerful sound deamon. Sound just work, and the "per application" sound volume is worth everything.
That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it. If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?
Sure, PA doesn't do low latency stuff like Jack, but it was never meant to. Instead PA works in perfect unison with Jack, in that it can suspend itself when certain programs need low latency sound operations, just like PA works on top of Alsa, not replacing it.
The problem for Gnome and KDE is, that systemd is vastly superior to anything out there, and that it will help them dump loads of hard to maintain code, and give them easy access to make powerful distro-agnostic programs.
systemd provides a a common, uniform Linux plumbing system that makes life easier for all user program developers. So of course Gnome and KDE will start to take advantage of systemd, why shouldn't they?
The main problem with those who for some reason or another doesn't like systemd, is that they are incredible lazy. Instead of actually getting together to make an alternative development stack to systemd, they rant against Poettering and spew empty platitudes about "UNIX philosophy".
The most pathetic example of this anti-systemd laziness, is of course "ConsoleKit". It has now been unmaintained for +1½ years, but it is a crucial piece of infra-structure for any Desktop. But instead of either maintain it or make an alternative, anti-systemd people just rant against Gnome for no longer making it a priority to support this piece of abandonware. All rant and no work.
I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible...
I was sceptical about binary log-files too in the beginning. However, I didn't have to play around with the journalctl tool before I realized that systemd's logging is far superior to any existing simple text logging.
stuff like "journalctl -b 2" (only show logs from previous boot) and "journalctl -F _SYSTEMD_UNIT" (show all systemd units that have ever written to the logs) are pure gold. The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values. You get logging info from much earlier in the boot process then previously, and with kdbus something that will get even earlier and later in the boot process and when shutting down.
journalctl works great with all the usual text tools like grep, just think of it as a super 'cat' with god-like sorting powers.
Forget what others sneers about Poettering and systemd, and give it a proper workout with a distro that supports it properly, like Fedora 20 or similar. Make up your own mind by actually using it.
To me it is clear that systemd simply is the future Linux plumbing system, and to me it is a quite brilliant solution as it is now.
Especially logging is a huge improvement. Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err" will reveal much of interest for the novice trying to debug a problem. (shows all messages of priority levels ERROR and worse, from the current boot).
And because the log is structured in db form, there will be GUI logviewers that are actually useful, and that can do filtering and sorting by eg. error levels, monotonic timestamps etc.
It has probably been said before, and probably better by many other posters here, but I would just like to add my voice to all the other people, who thinks the new beta.slashdot.org design sucks.
My main gripe is of course the comment system. It is so much harder to sift through the comments. I have a 20" monitor, but I can barely see three comments at a time in a font size I like. Yes, I know all usability experts will automatically quote the textbook saying that the lines on slashdot classic, are too long to read for many readers, but it works for me and other trained readers.
The new comment system simply doesn't work well as a comment system; it is not a matter of features or single deficits, but the overall design.
The general new design doesn't look promising either. It is not so much the design, but that it looks like a step for turning slashdot into yet another "click and gawk" site, with "funny" pictures of weird things. And videos too; that is so fresh!!!!
I am all for change and all that, and I wish that even more readers would like to read slashdot and comment on the stories, but I fear that present change is in the wrong direction.
Not sure if I, after +15 years of daily slashdot reading, will continue after this change. Not because of any bitter hate against the new design, but because I simply won't find slashdot an attractive place to come any more. I probably won't slam the door, but just vote with my feet, coming less and less frequently and then one day just stop.
I can get the stories elsewhere, it is for the comments that I come to read slashdot.
The Deskstar wasn't nicknamed Deathstar for nothing, back in the day...
The IBM Deskstar series was superb; faster than most other drives, excellent size/price ratio, and very reliable too. The entire OEM business cheered it, and IBM was solidly trouncing the competition, until that fatal release of the Desktar 75GXP around 2001 where a bad firmware combined with a faulty factory in Hungary started to kill the drives prematurely (too much cutting edge technology).
I owned a lot of IBM Deskstar drives and they all performed really well and none of them died before they were obsolete, including one of the affected GXP's (I think it was made in the Philipines.)
After IBM sold their storage unit to Hitachi, I started buying Hitachi branded Deskstars. Again. Superb drives, never had one fail me. To me "Deskstar" is a stellar brand name.
All the Hard disk drive manufacturers have had similar problems with certain series dying prematurely; Seagate, Quantum, WD, Maxtor have all made bad batches of hard disks, but they haven't entered public mind as a internet meme, because they didn't have a cool nickname like "DeathStar".
Memory and study technique are like all other efforts; they require regular training if you want to master them. There are no magic short cuts or pills that can remove the need of training. Some things like good sleep, exercise and not being stressed helps a lot, but you still need training.
The training will be hard and progress frustratingly slow in the beginning (think overweight ex-chain smoker taking up jogging or cycling; it is tough going in the beginning.).
Reading books is the key to success. You have to read regularly (like every day) and probably for more than an hour per day to make any difference (bed time reading excluded).
Memory is a complex thing, but for studying purposes I find it useful to distinguish between "passive" and "active" memory. "Active" memory is the stuff you can recall and talk about for some length. "Passive" memory is something where you can recall the meaning when you read about it again. Just reading a book usually just produce "passive" memory. Talking about the book (or movie, or show, etc.) afterwards converts the passive memory to active memory.
A good student is one that studies in such a way, that the most important stuff in the texts, are converted from passive to active memory.
There are several classic techniques to convert passive book knowledge into active; discuss the book afterwards with others, write you thoughts about the text down (making notes is useful even if you never look at them again), or use your inner voice to recapitulate what you have just read, or even talk aloud to a fictitious audience. The latter was a major technique for Roman orators because it improves rhetorical skills as well. It will improve your verbal exams considerably if you train the same way.
So try to start out with a small non-fiction book with a subject that you care for. Read a whole chapter, then reread it one page at a time, explaining to yourself with your inner voice using your own words, what was covered in that page and what parts were the important ones. Perhaps underline important passages. Afterwards, try to recapitulate major points from what your read, perhaps glancing at the index as a memory aid.
Read another book on the subject in the same manner, and compare it underways (from memory only at first) to the first book.
The above will not just convert passive memory to active memory, but it will also help you to actually understand in detail what was written instead of just reading the passage on autopilot without comprehension, it will help you focus on what is important, and the comparison will spawn memory connection between both text, so that one passage from one book, opens up the knowledge from the second book.
The above is very slow and time consuming in the beginning, and it is hard work too. But don't worry, as time goes by, the speed will increase; you will develop your own way of committing the stuff to memory, and knowledge will make it easier to see what is important, and what is secondary.
The point is to learn how to learn in a slow, systematic and thorough way in the beginning, later you brain will do much of the stuff automatically, and the speed will increase too.
Read, recapitulate to understand what was read and to convert it from passive to active memory, try to identify what is key points, compare and connect the knowledge with similar subjects, read slow and thoroughly at first, and don't be afraid to reread stuff later.
I think Krusader is the best file manager at all. Using drag-and-drop with multiple windows is just a pain on MS Windows and Mac OSX.
Almost everyone I know who doesn't use a twin panel filemanager have an incredible messy 'home' catalogue. Things just get dumped there, and because reorganising using MS Explorer sucks, the crust just accumulate.
Slashdot Mirror
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.
Do the phrases "designed by committee" and "political motivation" mean anything to you? The "other distros" are jumping on systemd as a "me too" reaction more than any real technical merit. (generally, the people making the call are not technical people.) GNOME and udev are two of the prime pushes to go with systemd -- as systemd has eaten udev, and GNOME requires logind. systemd does have a few pluses, but it also hauls in a truck load of unnecessary, and complex, bloat.
I don't give a shit what the systemd or upstart camps claim about shell scripts; writing, testing, and debugging init scripts is trivial. (making a single script for *every* distro can be trying, because they all do things a little different. if you think distros aren't going to do the same thing to systemd, think again.)
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.
We don't need to. sysvinit WORKS; it's stupid-simple, small, and trivial for anyone with a brain to actually manage. I don't get the whole push for databases, binary logs, 100k+ lines of C code... to do what a few hundred lines of shell scripts and config files have done for decades -- with a shell that's going to be on the system anyway.
(I'm not saying the BSD way of *one* shell script (rc.conf) is the way to go, but systemd is the super-complex bazaaro version of rc.conf.)
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.
Heh, I would have phrased it a bit differently: "Until I threw my prudent caution about relying only on binary log files to the wind". But as long as I don't employ you in IT, it is only a preference. And hey, I don't rule out that I might evolve to the same preference.
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.
My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.
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.
A simple command like "yum install syslog" will deal with that.
Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.
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.
I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you can write an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable.
So your arguments in favor of binary log files seem quite moot.
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.
There are numerous solid reasons for /usr
There are others, but that's just off the top of my head.
I've been watching Poettering's comments and attitude, and have to say I've got a bad feeling about this. Too complex. Not a sufficiently compelling use case.
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...
Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?
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)"
And because it is a db file, it can also get corrupted. And a corrupted db is almost impossible to extract anything useful from. A corrupted text file, which is only appended and never positioned ahead of EOF, can be read perfectly up to the point of corruption, and with some work can be read after the end of the corrupted section too.
All that aside, I grant the pluses of the journal, and as long as I can run syslog in parallel, I guess I don't have any sunstantial issues. It should never be mandatory to have the journal though.
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:
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.
'uniform Linux plumbing system' ?
Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?
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.
Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.
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.
How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it.
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.
If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).
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.
Additionally, it seems to be easy to break systemd's boot scripts in a way that prevent systemd from being able to boot the system (it's happened to me over and over again through what seemd like innocuous user actions), and I have never successfully gotten systemd to boot into its recovery shell.
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.
Ups, a paragraph sign wasn't made properly. The "My boot..." paragraph belongs to the OP of course.
With a boot media it is a piece of cake to read the journald log files.
My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of
those projects have to be aware and pick up updates.
That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.
If you run a distro using systemd, LVM, Btrfs, or any other such newish technology, you need a boot media to match, and not rely on your old 1995 edition of Yggdrasil Linux. Floppies just aren't reliable these days anyway.
I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.
It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling.
First of all, the systemd log file format is fully documented and covered by the interface stability promise. Look here for more information:
http://www.freedesktop.org/wik...
So it isn't going to change suddenly. So it isn't a problem at all.
Secondly, there are already many tools and programs that can directly read and manipulate the journald log files. Among these are of course good old syslog-ng that now handles such log files natively. There are more to come, especially since it is now possible to make GUI logviewers that actually work because of the structured file format.
The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.
I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.
Not sure what exactly you are complaining about here, so I am guessing.
Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way), and because the present logfiles effectively had become an API because of those many many log analysing scripts SA are using. Of course, there was also several different syslog variants too.
It is of course very easy to convert journald log files into text files if that is what you want, syslog will do this automatically, but it has excellent export tools too.
It is quite possible view MS-Windows event-log files from Linux. You can't use cat or less, but there are actually programs available.
I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring /usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.
No, systemd didn't break anything. It is merely the messenger that tells that a separate /usr is a broken idea on a modern Linux. systemd works fine with a separate /usr, but your Linux distro probably doesn't. /usr.
Just use "initramfs" if you actually have a real need for a separate
Look here for more information:
http://freedesktop.org/wiki/So...
Obviously, there's been a big push across the board by many various distros, but what are the real benefits of systemd? Is it better for average end-users (Easier? Faster?) or those more technically inclined (more stable, uses less resources, more configurable)? Or is this simply a case of it just being non-Canonical?
First, sysvinit sucks. All other Unix'es have abandoned it years ago. Only lethargy and lack of real improved Linux init-systems kept Linux on this sinking boat.
Linux distros have historically been extremely fragmented with no commonality between them for doing even simple things. It is impossible to make a simple distro agnostic gui that shows what the distro is called, or how to set time, or change the network values. There are probably 20 known different places that distros hide their name and release number.
There was also a widening gap between the development of Linux kernel features, and what user programs actually used. There simply wasn't any common infra structure.
systemd is an (very successful) attempt to create common Linux plumbing system that tries to solve the problems described above. It is incredible helpful towards all desktop environment developers with such a common and uniform platform, they can now easily make distro agnostic programs that can do interesting and useful things, and eg. both Gnome and KDE can remove huge chunks of fragile code concerning user and session management.
By tying the init system with the kernel, it suddenly becomes possible to do things impossible before, like logging from the second the kernel gets boot strapped, or using cgroups to ensure that important things gets priority (from desktop startup process, to give priority to foreground video's)
From logging, to program development, to speed and resource improvements, systemd is superior to anything else out there on every thing that is even slightly important. That is why almost every distro is embracing it, or is going to adopt it in the future (even Slackware will in the end). Disregarding rants against one of systemd main developers, Poettering* and empty platitudes about "UNIX philosophy" or "KISS", systemd is simply the most technical superior Linux init system in existence.
So the future Linux development stack is systemd, cgroups, kdbus and Wayland, It is an incredible powerful combo.
*Poettering, a main systemd developer among the +400 contributers, are often accused of making sound actually work on Linux with his Pulseaudio sound daemon. A crime not easily forgotten by those people that now posses useless knowledge about arcane Alsa rituals needed to do anything useful in the days before PA.
... If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
Anybody without a proper rescue boot media is up shit creek when a system is so broken that the binary tools doesn't work any more, be it journalctl or grep or cat. And frankly, working directly on system with a RW filesystem where fundamental tools doesn't work is simply bad practise anyway.
With a boot media it is a piece of cake to read the journald log files. You can even merge them with the boot media's log files to compare the boot processes. systemd and journalctl are designed to work with multiple log files from different machines at the same time, while doing wizard-like sorting and comparison, and integrity checking, and ...
So even in this situation systemd is superior in functionality compared to old style syslog text files. Yeah, I thought that binary log files was an evil thing too, but systemd's implementation proved my prejudice wrong.
I think Pulseaudio was a great step forward for sound on Linux. Yes, it did uncover many sound card driver bugs, and bugs in Alsa back in 2004, but that also meant that those bugs got fixed. My internal sound chip was somewhat flakey before pulseaudio, and PA simply broke it completely, but that also meant, that when the bugs was fixed, the sound chip driver and Alsa layer worked perfectly ever since. I just used a popular and well supported SB compatible sound card instead while the bugs where fixed.
At the time, every other sound daemon was neither system wide, nor working properly. PA solved all problems in a rather elegant way, so for nearly a decade Linux have had an excellent and powerful sound deamon. Sound just work, and the "per application" sound volume is worth everything.
That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it. If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?
Sure, PA doesn't do low latency stuff like Jack, but it was never meant to. Instead PA works in perfect unison with Jack, in that it can suspend itself when certain programs need low latency sound operations, just like PA works on top of Alsa, not replacing it.
The problem for Gnome and KDE is, that systemd is vastly superior to anything out there, and that it will help them dump loads of hard to maintain code, and give them easy access to make powerful distro-agnostic programs.
systemd provides a a common, uniform Linux plumbing system that makes life easier for all user program developers. So of course Gnome and KDE will start to take advantage of systemd, why shouldn't they?
The main problem with those who for some reason or another doesn't like systemd, is that they are incredible lazy. Instead of actually getting together to make an alternative development stack to systemd, they rant against Poettering and spew empty platitudes about "UNIX philosophy".
The most pathetic example of this anti-systemd laziness, is of course "ConsoleKit". It has now been unmaintained for +1½ years, but it is a crucial piece of infra-structure for any Desktop. But instead of either maintain it or make an alternative, anti-systemd people just rant against Gnome for no longer making it a priority to support this piece of abandonware. All rant and no work.
I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible...
I was sceptical about binary log-files too in the beginning. However, I didn't have to play around with the journalctl tool before I realized that systemd's logging is far superior to any existing simple text logging.
stuff like "journalctl -b 2" (only show logs from previous boot) and "journalctl -F _SYSTEMD_UNIT" (show all systemd units that have ever written to the logs) are pure gold. The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values.
You get logging info from much earlier in the boot process then previously, and with kdbus something that will get even earlier and later in the boot process and when shutting down.
journalctl works great with all the usual text tools like grep, just think of it as a super 'cat' with god-like sorting powers.
Forget what others sneers about Poettering and systemd, and give it a proper workout with a distro that supports it properly, like Fedora 20 or similar. Make up your own mind by actually using it.
This is a good starting point:
http://www.freedesktop.org/wik...
To me it is clear that systemd simply is the future Linux plumbing system, and to me it is a quite brilliant solution as it is now.
Especially logging is a huge improvement. Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err" will reveal much of interest for the novice trying to debug a problem. (shows all messages of priority levels ERROR and worse, from the current boot).
And because the log is structured in db form, there will be GUI logviewers that are actually useful, and that can do filtering and sorting by eg. error levels, monotonic timestamps etc.
It has probably been said before, and probably better by many other posters here, but I would just like to add my voice to all the other people, who thinks the new beta.slashdot.org design sucks.
My main gripe is of course the comment system. It is so much harder to sift through the comments. I have a 20" monitor, but I can barely see three comments at a time in a font size I like. Yes, I know all usability experts will automatically quote the textbook saying that the lines on slashdot classic, are too long to read for many readers, but it works for me and other trained readers.
The new comment system simply doesn't work well as a comment system; it is not a matter of features or single deficits, but the overall design.
The general new design doesn't look promising either. It is not so much the design, but that it looks like a step for turning slashdot into yet another "click and gawk" site, with "funny" pictures of weird things. And videos too; that is so fresh!!!!
I am all for change and all that, and I wish that even more readers would like to read slashdot and comment on the stories, but I fear that present change is in the wrong direction.
Not sure if I, after +15 years of daily slashdot reading, will continue after this change. Not because of any bitter hate against the new design, but because I simply won't find slashdot an attractive place to come any more. I probably won't slam the door, but just vote with my feet, coming less and less frequently and then one day just stop.
I can get the stories elsewhere, it is for the comments that I come to read slashdot.
The Deskstar wasn't nicknamed Deathstar for nothing, back in the day...
The IBM Deskstar series was superb; faster than most other drives, excellent size/price ratio, and very reliable too. The entire OEM business cheered it, and IBM was solidly trouncing the competition, until that fatal release of the Desktar 75GXP around 2001 where a bad firmware combined with a faulty factory in Hungary started to kill the drives prematurely (too much cutting edge technology).
I owned a lot of IBM Deskstar drives and they all performed really well and none of them died before they were obsolete, including one of the affected GXP's (I think it was made in the Philipines.)
After IBM sold their storage unit to Hitachi, I started buying Hitachi branded Deskstars. Again. Superb drives, never had one fail me. To me "Deskstar" is a stellar brand name.
All the Hard disk drive manufacturers have had similar problems with certain series dying prematurely; Seagate, Quantum, WD, Maxtor have all made bad batches of hard disks, but they haven't entered public mind as a internet meme, because they didn't have a cool nickname like "DeathStar".
Memory and study technique are like all other efforts; they require regular training if you want to master them. There are no magic short cuts or pills that can remove the need of training. Some things like good sleep, exercise and not being stressed helps a lot, but you still need training.
The training will be hard and progress frustratingly slow in the beginning (think overweight ex-chain smoker taking up jogging or cycling; it is tough going in the beginning.).
Reading books is the key to success. You have to read regularly (like every day) and probably for more than an hour per day to make any difference (bed time reading excluded).
Memory is a complex thing, but for studying purposes I find it useful to distinguish between "passive" and "active" memory. "Active" memory is the stuff you can recall and talk about for some length. "Passive" memory is something where you can recall the meaning when you read about it again. Just reading a book usually just produce "passive" memory. Talking about the book (or movie, or show, etc.) afterwards converts the passive memory to active memory.
A good student is one that studies in such a way, that the most important stuff in the texts, are converted from passive to active memory.
There are several classic techniques to convert passive book knowledge into active; discuss the book afterwards with others, write you thoughts about the text down (making notes is useful even if you never look at them again), or use your inner voice to recapitulate what you have just read, or even talk aloud to a fictitious audience. The latter was a major technique for Roman orators because it improves rhetorical skills as well. It will improve your verbal exams considerably if you train the same way.
So try to start out with a small non-fiction book with a subject that you care for. Read a whole chapter, then reread it one page at a time, explaining to yourself with your inner voice using your own words, what was covered in that page and what parts were the important ones. Perhaps underline important passages.
Afterwards, try to recapitulate major points from what your read, perhaps glancing at the index as a memory aid.
Read another book on the subject in the same manner, and compare it underways (from memory only at first) to the first book.
The above will not just convert passive memory to active memory, but it will also help you to actually understand in detail what was written instead of just reading the passage on autopilot without comprehension, it will help you focus on what is important, and the comparison will spawn memory connection between both text, so that one passage from one book, opens up the knowledge from the second book.
The above is very slow and time consuming in the beginning, and it is hard work too. But don't worry, as time goes by, the speed will increase; you will develop your own way of committing the stuff to memory, and knowledge will make it easier to see what is important, and what is secondary.
The point is to learn how to learn in a slow, systematic and thorough way in the beginning, later you brain will do much of the stuff automatically, and the speed will increase too.
Read, recapitulate to understand what was read and to convert it from passive to active memory, try to identify what is key points, compare and connect the knowledge with similar subjects, read slow and thoroughly at first, and don't be afraid to reread stuff later.
Good luck.
I think Krusader is the best file manager at all. Using drag-and-drop with multiple windows is just a pain on MS Windows and Mac OSX.
Almost everyone I know who doesn't use a twin panel filemanager have an incredible messy 'home' catalogue. Things just get dumped there, and because reorganising using MS Explorer sucks, the crust just accumulate.