Become a fan of Slashdot on Facebook


Forgot your password?
Polls on the front page of Slashdot? Is the world coming to an end?! Nope; read more about it. ×

Comment: Re:Minimum standards (Score 1) 63

by Peter H.S. (#49829119) Attached to: New SOHO Router Security Audit Uncovers Over 60 Flaws In 22 Models

Not necessarily. The alternative to no laws isn't bad laws.

As it is now companies can spew out insecure products with impunity and even silently drop any security support for devices consumers have just bought, not forgetting the classic tactic of not acknowledging security problems and just plain ignoring them. This can't go on.

Comment: Minimum standards (Score 4, Insightful) 63

Really, there ought to be some sensible minimum standards for commercial products that can be connected to the internet. This could include that the company had a decent policy for security fixes and a published contact point for people reporting such problems.

And how about a pre-published, minimum security support length, so that people buying a smartphone/router/etc. will know in advance how many years it will be supported with security fixes. There are "use by" dates on food, why not on all internet connected devices.

+ - Cool Tool: The Nuclear Fuel Cycle Cost Calculator->

Submitted by Lasrick
Lasrick writes: The Bulletin of the Atomic Scientists has launched a very cool new tool that will thrill energy wonks and anyone interested in understanding the per kilowatt cost of nuclear energy. Developed over the last two years in a partnership between the Bulletin and the University of Chicago, the Nuclear Fuel Cycle Cost Calculator estimates the cost of electricity produced by three configurations of the nuclear fuel cycle:

1. The once-through fuel cycle used in most US nuclear power plants, in which uranium fuel is used once and then stored for later disposal.; 2. A limited-recycle mode in which a mix of uranium and plutonium (that is, mixed oxide, or MOX) is used to fuel a light water reactor; 3. A full-recycle system, which uses a fast neutron spectrum reactor that can be configured to “breed” plutonium that can subsequently be used as either nuclear fuel or weapons material.

This online tool lets users test how sensitive the price of electricity is to a full range of components—more than 60 parameters that can be adjusted for the three configurations of the nuclear fuel cycle considered. The results provide nuanced cost assessments for the reprocessing of nuclear fuel and can serve as the basis for discussions among government officials, industry leaders, and public interest groups.

Link to Original Source

Comment: Re:Best example (Score 1) 244

by Peter H.S. (#49690683) Attached to: RTFM? How To Write a Manual Worth Reading

I suppose this bias toward old, good documentation is contributing to my dislike of Systemd, I don't see the same docs for Systemd that I saw for System V and BSD init structures.

systemd is a seriously well documented project. At the moment there are around 202 man-pages.

Every man-page I have used is done by the book: good examples, relevant "See also" references, and sometimes even links to further information. I really like the fact that all config files have extensive man pages too (man journald.conf fx), and that they also provide "big picture" documentation like "man bootup".

I have often seen how a question on the systemd devel list resulted in clarification of the documentation, so they take their documentation seriously.

On top of the man pages, there is also a huge amount of information on the projects homepage, spanning from overview videos, to low level developer information.

Comment: Re:The pain isn't in the switch (Score 1) 347

by Peter H.S. (#49681205) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why,

Yes, those are the basics for systemd to work. Again, rather simple requirements. It doesn't state what goes into what, because this is something the distros dictate, not systemd. The systemd developers can merely suggest where to put things, but distros won't necessarily follow those suggestions.

systemd is designed with different distro policies in mind, so they provide "Presets" to help facilitate the different policies and needs of different distros:

  Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".

The FHS is primarily concerned about directory layout, not so much the content of these. And there is nothing in FHS 3.0 that contradict the slightest that user attached storage is mounted in the /run hierarchy.
All such disc layout reorgs of the distro I have tried, have been discussed on mailing lists etc. before they are implemented. Again, this is something the distros dictate, not systemd.

Allow me to restate your comment:

> Systemd will continue to work for Linux distros that don't care for stateless boot etc

Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities.

Come on. It is the distros that dictates exactly what features systemd have turned on, and how the FH layout is. There are no systemd developers sneaking into the distro repos at night and secretly turning on features without documenting them.

You may not follow the eg. development mailing list of your distro where such things are discussed, nor care about reading release notes. But Linux distros have always evolved this way, with new ways of doing things, often from release to release.

  OTher examples abound. For example, the new replacement for /etc/resolv.conf says at

          Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.

I fail to see how this in any way breaks any stable subsystem.
1. systemd-resolved is an entirely optional feature. If the distros don't want it, they can just turn it off.
2. Whatever its /etc /run requirements is, this is a new feature, not a change of something old and stable. So it doesn't break anything at all.

I really don't think you can give just a single non-contrieved example of how systemd are breaking stable subsystems for users without warning.

While more documentation is always better, I think the systemd project is way better documented than most other software projects, and certainly much better documented than many people think it is.

I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.

Running two NTP-clients at the same time was an amazingly stupid thing to do even pre-systemd. AFAIK, systemd per default tries to avoid this by using "conflict" statements in the service files, so if one NTP client or daemon is run, the others are suppressed.
I don't think eg. SysVinit or Upstart ever had such measurements against accidentally running two NTP daemons at once.

The bottom line; yes, systemd developers are working towards stateless boot and other similar optional features. Yes, this will require some reorgs of how especially config-files are kept. There are good technical reasons for this (crypto verification, factory reset etc), and the layout changes seem to benefit all user cases, including those that won't be using the new features. Even those who doesn't use systemd would probably benefit from a layout with a clear separation between user, system and distro default config files.

The basic requirements for these new features are sketched out here:
But remember, this is very much a work in progress for the future, when things are are starting to actually work somewhat, I am sure that a more "official" documentation will appear that spells out all the details.
And the there is no dictate to make these features work for either distros nor upstream projects. This work will only be done if people think it is beneficial to their distro/project. systemd will work without being able to perform a factory reset or a crypto verified /usr.

Comment: Re:The pain isn't in the switch (Score 1) 347

by Peter H.S. (#49678035) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

The systemd requirements for the file system is documented here:
These are rather simple requirements and probably very close to the old FHS 3.0 proposal, I think /run is the only new thing here compared to FHS 2.3

AFAIK, all other changes of the FHS are merely suggestions like getting extra OS container features when using btrfs, and in case of stateless boot, something for the future. Systemd will continue to work for Linux distros that don't care for stateless boot etc.

Comment: Re:I like how this got marked troll (Score 1) 347

by Peter H.S. (#49673881) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

You mean boot logging? There are numerous ways to solve this which would have made more sense, including a small change to the linux kernel to make it stop throwing away boot logs when they are large.

The kernel ring-buffer size can be user specified, so no need to ever lose such messages. The problem is that during boot, only messages directed at /dev/kmsg is recorded until rootfs is mounted and syslogd is running. This is hard to do something about since it is a kernel limitation that only one device at the time can own /dev/log. journald catches all messages, including those to /dev/kmsg and /dev/log, and it does this from early boot. So a journal based system will always contain more info than a pure syslog system.

So use syslog-ng, which can be used in place of syslog without changes to other daemons, unlike journald. Which again, is the reason we're even having this conversation.

Regarding silently dropping messages: AFAIK all syslog daemons does this per design (or lack thereof). The main problem is that calls to syslog() would be blocking if implemented in a safe manner.

Wait, you don't care about human-readability, but you don't want the logs to become unreadably long? Make up your fucking mind. You're just making shit up, I can tell because that shit is contradictory.

You misunderstand; a reason why syslog messages doesn't contain monotonic timestamps etc. is that it makes the log entries extremely long and hard to read for humans. It is a kind of limitation of the "design".
journald doesn't have such limitations since it is field based, and the output format is easily adapted to what view you want. If you only want wall time stamps, you can get that, if you want monotonic time stamps, you get that, and only that.

So with the journal, you can add more fields in the future without making the log entries unwieldy, something impossible with syslog.

Regarding human readable: I only care about that for the subset of information I intend to read, and this is exactly what journalctl does. That way you can have logs that are easy to parse for both humans and machines; each consumer gets exactly the view of the data that they want in a form they can use.

that text logs simply don't scale

Still not an argument against text logs, only an argument for also implementing binary logs. And I wouldn't put them into their own shitty files with their own shitty format, I would put them into an RDBMS. Putting them into crappy, easily-corrupted binary log files is just asking for trouble, and guess what? It's causing trouble.

Yes, the scaling thing is a good argument against using flat file text logs. You really need indexes when analysing such huge amount of data, which is exactly what people are doing at the moment; they invest in often proprietary commercial solutions in order to massage their flat text file log data into something usable.

RDBMS have been tried for a long time and they are not a good general purpose solution for local logging. They are also much more prone to corruption than the journal's simpler binary storage format.

What? So now you don't like flat files or regex? Why don't you just fuck off to Windows and let us have our Linux? You clearly don't like Unix.

While regex is a powerful tool, the old joke about trying to solve a problem using regex, and then discover you now have _two_ problems, is true too. Discounting the many variations of regex that each program like grep /egrep uses, it simply becomes unwieldy when you are using regex epressions that are +120 characters long. Making ad hoc queries with regex really is painful when the complexity rises beyond the basics. The systemd journal is so much better regarding this since it is field based. It is so trivial to make complex ad hoc queries without any need of using regex.

Really, stuff like:
"journalctl --since -5m"
"journalctl -b-1 -p warning"
"journalctl /usr/sbin/smartd --since 2015-05-10"

Is so much easier than trying to construct regexes that does the same.

Comment: Re:The pain isn't in the switch (Score 1) 347

by Peter H.S. (#49672447) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

I assume you are talking about FHS 3.0 here, but remember, that is only a proposal, not a standard. Also note how the FHS 3.0 process has been stalled for years.
The bottom line today is that there is FHS 2.3, and then everybody doing their own thing , perhaps with some cross-distro cooperating. The end result is no common formal standard for the FHS among the distros.

Personally I don't think there will be a FHS 3.0 until the dust has settled regarding the current layout reorg,

The reorg of the FHS that the systemd developer are doing, are caused by good technical reasons. Unix and later Linux have had several of these reorgs over the decades, and it is a process that probably never stops.

So until the FHS reorg to make about OS containers, and stateless boot work in a sensible manner, the Linux FHS will be in a slight flux. Not a big problem really.
I guess at some point somebody will make a FHS 3.X out of what the systemd distros does at some point in the future. Personally I prefer this approach of practise getting formalized into a standard. That way you are sure to have both a good working standard, and a standard that people actually use.

Comment: Re:I like how this got marked troll (Score 1) 347

by Peter H.S. (#49670825) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

Judging by this thread, it does give at least one advantage, that being the ability to at least partially recover and analyze corrupted logs.

The same is very much true for systemd's journald files. They are just appended text files with another delimiter +index, so in worst case a hex editor or "strings" may read them.

"journalctl" is designed to cope with corrupted journals and read them very well. It should be noted here that corruption of journal files as discovered by the --verify option, mostly are very trivial errors like a monotonic timestamps of the wrong length etc. Such errors only affects a single log entry, and often even that log entry can be read without problems. Despite using journald since it became standard on Fedora (F15) I have never experienced any data loss nor having journal files that I was unable to read.

Comment: Re:I like how this got marked troll (Score 1) 347

by Peter H.S. (#49670727) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited.

No, that was a brilliant idea that Linux inherited.

Come on, syslog(3) wasn't even signal-safe and designed as dog slow too. It was crap. People have been working ever since to make syslog thread safe (still interim), etc.

What classic syslog problems? I haven't had a problem with log rotation, really the last remaining issue, in approximately forever.

That syslogd can't log until rootfs is started and most of the machine is up, that it is dog slow and silently drops messages under load, that there is no common API for accessing the content of the data, that the data is basically free form, deviating from machine to machine (an industry exist dedicated to this problem alone) also making it impossible to make a distro agnostic GUI log viewer, that meta-data like monotonic timestamps are basically impossible to add without the log entries becoming unreadable long, that text logs simply don't scale (again, an industry exist to solve this problem, see Splunk etc.), that using regex becomes intolerable and unwieldy above a certain point, that in order to grep for something in the log file, you basically already have to know the name of the function and what the problem is, this makes syslog log files basically impossible to use for newbies, so they have to resort to trawling through the logs like reading a book.

Really, flat file, un-indexed log files meant to be read by a human SA is something that belongs to another era. What the present and the future needs are binary, structured and indexed logs with a stable API that can be parsed by machines and that works even at mega-scales.

And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.

And syslog gets the messages late, and may not get them at all.

Well, these are know problems with syslogd implementations; they silently drop messages under even moderate load. It is their ancient design, so using pure syslog you will never know whether something was logged or dropped. With journald you will at least be informed if log messages are dropped. The latter should be a rare occurrence since journald is so much faster than syslogd.

journald goes to great lengths by using per app log rate limiting in order not saturate syslogd, but the inherent limitations in syslog means that this will always be an best effort. Still, it probably isn't worse than using syslogd alone.

Comment: Re:I like how this got marked troll (Score 1) 347

by Peter H.S. (#49670565) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

I'm curious: why not just make an indexed database logging system on top of, rather than instead of, text logs? i.e. write out log entries in some structured but still text-only format in one file, and then maintain an efficient binary index of entries in a separate file. That way you get all the nice search etc, while still being able to grep the raw text if you really need to.

There are several problems with solution: it isn't backwards compatible with syslog (journald strives for 100% backwards compatibility).

It doesn't solve the problems that combining meta-data with log entries in flat text files, makes the text logs hard to read for humans since the log lines become far too long and complex.

It doesn't really gives any advantage of pure binary data. Remember grep, sed, tee and every other standard Linux text tool works with systemd's journal through the standard Linux/Unix concept of piping, so there is nothing lost by going pure binary.

Comment: Re:The pain isn't in the switch (Score 1) 347

by Peter H.S. (#49670513) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

The reorg of the FHS is quite needed in these days of OS containers, sandboxing and virtualization, so while placing stuff under "/run" is something new (part of the proposed FHS 3.0 standard btw), there are good technical reasons for it, including that /run is guaranteed to available from early boot (initramfs).

I believe this re-org even predates systemd.

Comment: Re:Logs via network (Score 1) 347

by Peter H.S. (#49667625) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

Thanks for the links. Last time I looked into this, the remote features were still a feature request.

Maybe I'm not understanding you, but I thought journal was meant to be superior to syslog and eventually supplant it.

Well, yes and no. journald was meant as a total overhaul of _local_ Linux logging. It provides "metal-to-metal" logging by being able to operate in initramsfs before rootfs is mounted, and pivot back to initramfs (Dracut) after rootfs has been unmounted. It collates all logs into a single view, instead of the myriad of scattered legacy log files (including binary logs like utmp etc).
It also vastly improve the way programmers can use logging, since syslog(3) etc. have so many limitations regarding speed, messages per seconds etc.
It also provide structured logs with plenty of metadata like monotonic timestamps that are troublesome in syslog text logs.

Rsyslog and similar syslog implementation works both as a _local_ logging system _and_ as a remote log sink.

journald doesn't work as a general log sink for remote logging, nor does it provide DB interfaces and various other similar plug-ins. So for general log-sinks, Rsyslog was always meant to be choice.

journald was also designed to be 100% compatible with syslog since it was obvious that legacy requirements would make that a necessity. So again, for legacy setups, syslog was always the designed choice to run on top of journald.

Comment: Re:I like how this got marked troll (Score 4, Informative) 347

by Peter H.S. (#49667133) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

The issue is not with systemd corrupting the binary logs, or with the filesystem corrupting the binary logs, but with the fact that they are -binary- logs. A log file should be an ordinary text file. Nothing more, nothing less.

The glaring problems with flat file, unstructured text logs have been discussed for decades now. Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited. The main commercial selling point with any syslog implementation today is exactly that you can avoid several of these problems by using a DB.

An overhaul of the creaking legacy Linux logging system have been needed for a decade at least. Remember, the Rsyslog project was started exactly to fix such problems. They failed partly because distros and developers don't care about working together for a common goal and because there was no other central developer hub who would take the initiative.

systemd have finally fixed so many of the classic syslog problems. I don't care if you think syslog is perfect and never can be improved, and Rsyslog should be avoided for providing binary DB storing option, but please don't think that other people agree to this postulate.

And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.

"When in doubt, print 'em out." -- Karl's Programming Proverb 0x7