Slashdot Mirror

Apparently in the "exec" part of a service, change StandardOutput or StandardError to one of:

inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console or socket

I disagree. Wayland is essentially a subset of what X11 can do. It is based on sending messages over a unix domain socket and sharing buffers. This is exactly what modern X clients also do. This is no surprise: It was designed to support exactly what is needed for modern clients and no more with the explicit goal to get rid of everything else. But it does not add anything which you cannot also do in basically the same way with X.

Trying to say that just because it uses sockets makes it like X11 doesn't make it so.

This is true. This is about retaining backwards compatibility.

Right... so we must maintain backwards compatibility for barely used functionality even when it impacts on performance in the every day use case. And even when you can have backwards compatibility by running Xwayland or by running X11 without Wayland while everyone else enjoys a better experience.

Extensions are nice way to make modern rendering possible without breaking backwards possibility. "fool" "2D-centric" "1980" is just FUD to make it sound bad, but X supports modern applications just fine. You have no technical argument.

It's not FUD, it's true. X11 is from an age where the screen screen was a bitmap and every window to be a region in that bitmap. When you moved one window over another the server would throw out damage events and every client would repaint their areas. And x, y coordinates for mouse moves were simple transforms from screen to window coords.

This model is totally discordant with a modern compositing desktop. X11 has gained a compositor extension which is hacked into this model but underneath it still thinks the same way. So the compositor must duplicate state from X11 except sometimes windows might be scaling or otherwise not where X11 thinks they are. So all the x, y mouse coords are screwed up and don't map properly. Oh and because the compositor is a separate process it means extra context switches in and out of the damage event so the server can preserve its worldview.

In Wayland the compositor, server and window manager are the same process. So the state isn't duplicated or mismatched and compositing does not require a context switch.

Because modern clients work essentially in the same way on X as on Wayland,nothing is slower or less efficient. Just because some API is based on an extension or not doesn't make it faster or slower. This is simply FUD.

Wrong. X11 incurs more context switches than Wayland to recomposite or to handle input messages. There is a simple diagram that demonstrates this point.

No. Mostly, it will break backwards compatibility, and remove features. The few kilobytes on unused drawing API in X11 will not make any noticable different on desktops (or mobiles) with gigabytes of ram.

Run X11 over Wayland if you want backwards compatibility or start the desktop with the X11 backend. There's no reason your esoteric needs should impact on the experience everyone else suffers from. And thankfully that reality will soon be realized.

I guess non-Linux is doomed to an eternity of Enlightenment-less X11 then?

Examples of systemd breaking the kernel include the "debug" logging option, and the inevitable failures of such a complex weave of components killing PID 1.

              https://bugs.freedesktop.org/s...
              http://ewontfix.com/14/

Unfortunately, "running syslogd in parallel" doesn't work well as new daemons or services are compiled for one or the other. And I'm afraid the code to integrate with systemd logging is a tar-baby: it becomes very difficult, very quickly, to maintain separate logging, but the logging is not portable to UNIX based operating systems. And that change is breaking portability for new projects even as I write. If you're willing, take a good look at the latest httpd source code to see what's happening to logging there.

And yes, systemd is trying to replace "su". See the comments by systemd's core author, Leonart Pottering, at:

              https://github.com/systemd/sys...

It's particularly amusing in those comments that Lennart Potteroing thinks that Linux is UNIX. UNIX is trademarked, licensed, and applies only to systems that follow various POSIX standards, and there's a fascinating history of lawsuits about this involving the SCO Group, which tried to claim that Linux was a UNIX descendant. Old material on this is at:

              https://www.groklaw.net/

I can understand why hearing these issues voiced again could be tiresome, and not all concerned developers are well informed. But rejecting all concerns as being "information from trolls" ignores the very real and often unnecessary problems systemd is creating.

I think that these kind of wearable devices would really benefits from the Firefox OS. First, the Firefox OS is from Mozilla, and Mozilla is known for making the best softwares. Second, the Firefox OS embrace open web technologies like JavaScript, HTML5 and CSS3, which are the best there are. Third, the Firefox OS is open because it's from Mozilla and because it uses open web technologies. Fourth, the Firefox OS uses Linux kernel. Fifth, the Firefox OS can be used for the embedded softwares and hardwares. Sixth, the Firefox OS is big show in India, the country of softwares. Seventh, the Firefox OS is use important w3c standards. Seven points make me thinking that the Firefox OS is good choice! It is be best choice even!

Why isn't this post modded up?? This is the most hilarious post I've seen on Slashdot all year. And that includes Bennetts drivel.

I think that these kind of wearable devices would really benefits from the Firefox OS. First, the Firefox OS is from Mozilla, and Mozilla is known for making the best softwares. Second, the Firefox OS embrace open web technologies like JavaScript, HTML5 and CSS3, which are the best there are. Third, the Firefox OS is open because it's from Mozilla and because it uses open web technologies. Fourth, the Firefox OS uses Linux kernel. Fifth, the Firefox OS can be used for the embedded softwares and hardwares. Sixth, the Firefox OS is big show in India, the country of softwares. Seventh, the Firefox OS is use important w3c standards. Seven points make me thinking that the Firefox OS is good choice! It is be best choice even!

Like I think all of the Systemd stories, sensational article is sensational. If you actually read what machinectl is, you'll see it has nothing to do with the su command, and it's also not suppose to replace it. Basically, from reading for about 1 minute, machinectl is to execute operations on VMs and containers. Last time I checked, the su command don't do that and have nothing to do with it. Probably someone asked Poettering, "Hey, would be nice to have root shells in a VM"

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

machinectl may be used to execute operations on machines and images. Machines in this sense are considered running instances of:
        Virtual Machines (VMs) that virtualize hardware to run full operating system (OS) instances (including their kernels) in a virtualized environment on top of the host OS.
        Containers that share the hardware and OS kernel with the host OS, in order to run OS userspace instances on top the host OS.
        The host system itself

Because there are other features of machinectl like
machinectl status which give you information about VMs and containers
machinectl enable which enables or disables containers ....

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

machinectl shell is only incidentally similar to su. Its primary purpose is to establish an su-like session on a different container or VM. Systemd refers to these as 'machines', hence the name machinectl.

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

su cannot and does not do that sort of thing. machinectl shell is more like a variant of rsh than a replacement for su.

The Chrony comparison page compares ntpd, Chrony and OpenNTPd. Another yet to be finished alternative is ntimed (which seems to currently be around 6000 LoC). On some Linux's if you don't care about accuracy or trying to weed out false time you can always use an client such as systemd-timedated.

There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

You can't do it through a capabilities interface, even?

No, it is different from dropping privileges. Here is a short explanation. In this case the user case is being able to use revoke on devices:
https://lwn.net/Articles/54653...

The Linux kernel simply have limitations when it comes to device handling, especially when it comes to security.

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.

Because cgroups track all processes that are initiated, this is why systemd can track and kill all processes and its subprocesses reliably. It also provides process isolation needed for security (and user sessions).
Cgroups is therefore extremely tightly integrated into the systemd-daemon.

Here is a quote from the mailing list where Poettering explains:

"Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted."
http://lists.freedesktop.org/a...

Things will get even more complicated with the new cgroup API, since that only allows one "writer" on the system, and that writer is supposed to abstract away the low level API so it doesn't expose "kernel knobs" anymore.

There are also the usual reasons for why it really can be limiting to freeze internal API's, and over the time some stuff have moved into "logind" and other stuff out, which wouldn't have been possible if the API had been frozen.

But as said, even if the API was frozen, logind would still require session and cgroups management, and nothing outside systemd really provides that.

systemd really provides a lot of external API's that are frozen and stable, but logind isn't one of them.

Personally I don't see the need either. It has been quite clear for years that the non-systemd distros needed to develop and maintain their own software stack. Both Gnome and KDE developers have repeatedly pleaded for this over the years.

There are a few differences. First, symlinks are a property of the filesystem. This means that the normal filesystem APIs just work with them and you need special APIs for things that care about whether it's a link or not. In contrast, shortcuts are just another kind of file and everything that wants to follow them needs to know what the target is. Second, shortcuts contain a lot more information than just a path: they include the path to the destination file, an icon, the set of command-line arguments to pass, and some other flags. For example, I used to have a load of different shortcuts to the WinQuake (and, later, GLQuake) executable that all had different -game flags, for launching different mods. Many of them also had different icons, if the mod came with its own icon. You can't do that with symlinks.

The closest thing to symlinks on *NIX systems is .desktop files.

Most open source licenses, by definition, must allow distribution. There are outfits that provide source code for other reasons. Microsoft and Apple are good examples. Microsoft often provides code examples that are intended to illustrate the use of a particular feature. I am not sure if that is the kind of license you want or not.

Another option is to examine how nVidia handles their Linux driver. They basically provide large chunks of source code for interfacing the driver, but also distribute a core binary object that must be linked into the driver. That binary object implements the proprietary magic while the remaining files are mostly glue. Of course, there is a community out there looking to obsolete the need for that proprietary magic. Note that the NVidia license is not considered "open source" either (by definition).

Usually one would involve lawyers for an endeavor involving the production of legally binding documents. Your company should consider doing so in this case.

Citation very much needed.
Here is a documentation of the binary log format:
http://www.freedesktop.org/wik...
Systemd offers a C API to access those, an export format for easier parsing, and of course you can access the binary logs directly.
http://www.freedesktop.org/sof...
http://www.freedesktop.org/wik...

Citation very much needed.
Here is a documentation of the binary log format:
http://www.freedesktop.org/wik...
Systemd offers a C API to access those, an export format for easier parsing, and of course you can access the binary logs directly.
http://www.freedesktop.org/sof...
http://www.freedesktop.org/wik...

Citation very much needed.
Here is a documentation of the binary log format:
http://www.freedesktop.org/wik...
Systemd offers a C API to access those, an export format for easier parsing, and of course you can access the binary logs directly.
http://www.freedesktop.org/sof...
http://www.freedesktop.org/wik...

Maybe, but when you have something that prevents you from properly debugging said kernel, it may be a problem:

https://bugs.freedesktop.org/s...

What distro are you using? 'stderr' for a service by default should go to the same place that 'stdout' goes to. http://www.freedesktop.org/sof...

Such as? I've never had any problems.

I adore the power of using sql queries on logs.

How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?

The classic problem was speed. A DB was fine for storing and analysing, but could be severe bottleneck for log sinks.
It isn't so great for local system logging either since DB's tend to appear rather late in the boot sequence.

With journald you can have system logging before the rootfs is even mounted, and since both systemd and journald can pivot back to initramfs after the rootfs has been unmounted, you can potentially have logging after that.

These days it seems that people are using a mixture of DB's and heavily data massaged text logs (JSON etc) combined with a special index (Splunk etc).

There will never a single log storage solution for all, since the tools chosen will reflect the problems trying to be solved. For some it is auditing that is important, for others it is analysing website usage.

But since systemds journal is structured and field based, it is very easy to convert its log entries to standard JSON etc that consistently fits other storage means. A huge improvement over the many different syslog implementations.

Re: triggers. You don't use "journalctl" for that, but the API/libraries/language bindings. systemd provides a really good and well documented framework for making triggers, but don't provide them as such. You can have instantly triggered events on file systems that supports it.
"man sd_journal_get_events" documents the C API:
http://www.freedesktop.org/sof...

But there are also Ruby, Python, Go bindings etc. All in all I think systemd/journald is a major upgrade when it comes to log watchers; stable API, field based filtering, many language bindings, instant notifications etc.

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.

It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

try that with grep!

Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.

Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.

how can systemd ever make it harder for non-systemd distros

If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.

It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.

1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"

2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design

Until they have to debug a boottime issue (which crops up quite frequently in production environments with systemd).

You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable.
Besides, systemd systems are so much nicer to debug than distros glued together with shell scripts.

Just the fact that you can have full logging and the systemd tools working from initramfs is a vast improvement, and the systemd journal beats all other Linux logging options by a huge distance; field based filtering and monotonic timestamps are just great when debugging boot problems.

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).

Unfortunately, by then their strategy of subsuming other projects (sianara ntp, it was nice knowin' you)

You are seriously misinformed here; systemd provides a sNTPv4 client, not a ntp-server. It is a compile time option, so no distro ever needs to use it instead of their preferred sNTP-client. It is included in the systemd project for two main reasons; clock-less ARM boards and OS containers. Both have special timing needs since eg. an OS container can be "frozen" and "unfrozen" without warning. systemd provides them both with a solution so they don't gets confused by time jumps.

But perhaps you think choice is bad and there are too many sNTP clients so systemd developers should be banned from providing one?

, enforcing dependencies

Like what? systemd have extremely few external dependencies. And don't try the provable falsehood that systemd inserts "hard dependencies" in other projects like Gnome/KDE.
That Gnome have had problems supporting non-systemd distros was because those distros didn't care to maintain ConsoleKit. Gnome kept on supporting CK despite it having been abandoned for +1½ year with no upstream to provide bug-fixes or security fixes.

But thanks to systemd, there are now several alternatives to ConsoleKit. Choice is good.

, making it more difficult to maintain alternatives (dropping support for biosdevname=0 for example) will have made it difficult if not impossible for those who wake up to switch to something that adheres to more sensible unix norms.

Again, you are really misinformed here; how can systemd ever make it harder for non-systemd distros that are using mdev or vdev or eudev?

If a non-systemd distro wants to use unpredictable network names they can do so.
With systemd distros here is how you turn off predictable network interface names:
http://www.freedesktop.org/wik...

Again, thanks to systemd the Linux ecosystem went from just having udev and mdev, to also having eudev and vdev and probably several more. So if you like choice, praise systemd for providing it.

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.
http://www.freedesktop.org/sof...

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.
http://www.freedesktop.org/wik...

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.
http://www.freedesktop.org/sof...

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.
http://www.freedesktop.org/wik...

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:
http://freedesktop.org/wiki/So...

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 http://www.tin.org/bin/man.cgi...

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

The systemd requirements for the file system is documented here:
http://www.freedesktop.org/wik...
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.

Binary logs are a different matter. To read them at all, you need a matching decoding program.

Of which there are many, and it is open source so you can even write your own or write a systemd patch to write the logs to text files rather than binary ones. It's all free software and still there's people just throwing their arms up and crying that it's all hopeless. What the hell was the point of free software if nobody can be arsed to actually do anything besides whining?

And the damage to the logfiles must be within the limits of the decoding program's ability to skip around damage. You're probably not going to get anything usable from a raw sector dump.

Of course you are, even most corrupted audio and video files just result in small glitches in the stream and even one codec implementation has a problem there's usually another that can recover it. The disadvantage they have is that most are closed-source protocols, the systemd log implementation is open source and free software.

Here is a good resource for understanding journal files and as you can see, reading them is not particularly difficult, nor is validating it and skipping over any corrupted parts.

SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.

Of course you can push journald logs over the network in several different ways, and you can also receive them using the journald. But the systemd journald isn't substitute for syslog, but meant to complement it. Just use rsyslog when it is relevant, or just systemd's journald when that suffices.

Here is the document info for "journal export format"
http://www.freedesktop.org/wik...

Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
http://www.freedesktop.org/sof...

Here is how to serve journald log entries across the network:
http://www.freedesktop.org/sof...

SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.

Of course you can push journald logs over the network in several different ways, and you can also receive them using the journald. But the systemd journald isn't substitute for syslog, but meant to complement it. Just use rsyslog when it is relevant, or just systemd's journald when that suffices.

Here is the document info for "journal export format"
http://www.freedesktop.org/wik...

Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
http://www.freedesktop.org/sof...

Here is how to serve journald log entries across the network:
http://www.freedesktop.org/sof...

SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.

Of course you can push journald logs over the network in several different ways, and you can also receive them using the journald. But the systemd journald isn't substitute for syslog, but meant to complement it. Just use rsyslog when it is relevant, or just systemd's journald when that suffices.

Here is the document info for "journal export format"
http://www.freedesktop.org/wik...

Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
http://www.freedesktop.org/sof...

Here is how to serve journald log entries across the network:
http://www.freedesktop.org/sof...

In this case, the systemd detractor claims that systemd's log files become unreadable when they're corrupted . But the systemd supporter claims that the log files are readable with journalctl. Unfortunately, the supporter does not mention whether journalctl still works when the binary log file is corrupted . So, the systemd supporter may not be addressing the original concern of the detractor. Can somebody fill in the missing details?

The theory is:

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3

Bug report: Logs keep getting corrupted and cannot read them at all
Rejected with reason: Delete the corrupted logs and move on
SystemD - works well when it works, fails spectacularly when it fails.

Except that isn't the bug report at all.

The real one was Bug 64116 - How does one fix journal corruptions?.

It was closed "RESOLVED NOTABUG" because you don't need to fix journal corruptions -- journalctl can read the corrupt files and journald rotates the file it's writing if corruption is detected. Nobody suggested you delete the logs.

To provide a consistent, reliable way of tracking who is logged in, and interfaces for doing various things related to user sessions - this includes providing controlled access to things logged-in users might want to do, such as suspend, reboot, power off, access input devices (separately from those in use by other users who may be logged in to the same machine), switching between different sessions, inhibiting suspend (because I'm watching a movie), and so on. A whole load of stuff which has traditionally been unreliable on desktops, or only worked for one user at a time, or worked differently for each distribution, or had no consistent mechanism for controlling access to the functions.

It has a man page: http://www.freedesktop.org/sof... ... and a detailed description of the interfaces it provides, should you wish to provide an alternative implementation: http://www.freedesktop.org/wik...

Desktop environments choose to depend on logind because it frees them of the responsibility to implement all this stuff themselves - which has traditionally been a mess, because the way these things are handled across different distributions has always been subtly different. Which group do I need to be in to be allowed access to reboot? What are the permissions on the device node for the keyboard? How does a generic video player app tell the system not to turn the screen off, without individual support for the methods used by various disparate desktop environments? If you have a common interface which all the DEs can use (and other apps with no specific DE affiliation), it becomes very tempting to, you know, *use* it.

Its access control goes via Polkit, which is itself a generic system to controlling access to privileged things. Polkit itself is not part of systemd.

To provide a consistent, reliable way of tracking who is logged in, and interfaces for doing various things related to user sessions - this includes providing controlled access to things logged-in users might want to do, such as suspend, reboot, power off, access input devices (separately from those in use by other users who may be logged in to the same machine), switching between different sessions, inhibiting suspend (because I'm watching a movie), and so on. A whole load of stuff which has traditionally been unreliable on desktops, or only worked for one user at a time, or worked differently for each distribution, or had no consistent mechanism for controlling access to the functions.

It has a man page: http://www.freedesktop.org/sof... ... and a detailed description of the interfaces it provides, should you wish to provide an alternative implementation: http://www.freedesktop.org/wik...

Desktop environments choose to depend on logind because it frees them of the responsibility to implement all this stuff themselves - which has traditionally been a mess, because the way these things are handled across different distributions has always been subtly different. Which group do I need to be in to be allowed access to reboot? What are the permissions on the device node for the keyboard? How does a generic video player app tell the system not to turn the screen off, without individual support for the methods used by various disparate desktop environments? If you have a common interface which all the DEs can use (and other apps with no specific DE affiliation), it becomes very tempting to, you know, *use* it.

Its access control goes via Polkit, which is itself a generic system to controlling access to privileged things. Polkit itself is not part of systemd.

Interesting... Googling around backs up your memory - systemd's readahead implementation was removed in v217.

Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files

systemd's journal is a basically a textfile that uses another line delimiter and have an index. Try "strings" on it, or a hex editor.

Well if so, that's new. It never used to be the case that the binary format was stable. So, I'm going to ask you to provide a link to the description of the binary structure.

Here is is the systemd interface and portability chart. Notice sd_journal and the journal file format:
http://www.freedesktop.org/wik...

Here is the file format;
http://www.freedesktop.org/wik...

There are loads of other developer information about accessing the journal with Python language bindings etc.

Jesus fucking H. Christ on a stick what is wrong with you? I specifically went into detail about how noisy the pro-systemd people like you insist on a dichotomy between unstructured text files and binary file formats. There is no fucking dichotomy you moron. If you actually read my sodding post instead of going off on a rant then you would actually become marginally more informed and stop spouting the same old shit repeatedly.

Well, you are not the first person to think about how to extend text logs with some kind of index, and it would be nice if it could have microprecision timestamps, and monotonic timestamps like the journal does. The problem is that is unworkable.

As I said, several projects have tried to fix this without any luck for the last couple of decades.
Another problem with such a solution is that standard Linux text tools like grep, tee, sort etc. won't work with such a solution where the index isn't part of the text file, and metadata like microsecond time stamps tend to make the log lines unreadable long.

With systemd's journal all standard text tools work with the index and metadata, so you can grep monotonic timestamps by a simple pipe.

If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.

Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files

systemd's journal is a basically a textfile that uses another line delimiter and have an index. Try "strings" on it, or a hex editor.

Well if so, that's new. It never used to be the case that the binary format was stable. So, I'm going to ask you to provide a link to the description of the binary structure.

Here is is the systemd interface and portability chart. Notice sd_journal and the journal file format:
http://www.freedesktop.org/wik...

Here is the file format;
http://www.freedesktop.org/wik...

There are loads of other developer information about accessing the journal with Python language bindings etc.

Jesus fucking H. Christ on a stick what is wrong with you? I specifically went into detail about how noisy the pro-systemd people like you insist on a dichotomy between unstructured text files and binary file formats. There is no fucking dichotomy you moron. If you actually read my sodding post instead of going off on a rant then you would actually become marginally more informed and stop spouting the same old shit repeatedly.

Well, you are not the first person to think about how to extend text logs with some kind of index, and it would be nice if it could have microprecision timestamps, and monotonic timestamps like the journal does. The problem is that is unworkable.

As I said, several projects have tried to fix this without any luck for the last couple of decades.
Another problem with such a solution is that standard Linux text tools like grep, tee, sort etc. won't work with such a solution where the index isn't part of the text file, and metadata like microsecond time stamps tend to make the log lines unreadable long.

With systemd's journal all standard text tools work with the index and metadata, so you can grep monotonic timestamps by a simple pipe.

If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.

It wasn't just that you couldn't write to the log, but the entire log was lost.

Are you sure? This is the most quoted bug about journal corruption: https://bugs.freedesktop.org/show_bug.cgi?id=64116

I see no sarcasm.

Is that any excuse for just hanging indefinitly (5 minutes my arse - saw one hang overnight) without any output to anywhere to tell you what is going on?

Well, SysVinit systems aren't magic either, if there is a kernel-GPU bug or similar low level error, systems may hang forever without any useful output, and without rootfs there isn't any logging done.

But did you try VT9 etc.? Was crash shell enabled? I find that systemd with initramfs like Dracut is a breeze to debug when it comes to boot problems; stuff like "rd.break=pre-mount" is great if there are serious rootfs problems, or appending "1" or "emergency" to the kernel cmd-line. This is a good start page about debugging systemd machines:
http://freedesktop.org/wiki/So...

Playing around with a systemd-nspawn OS container is also a good way of simulating various boot errors and how to recover from them.

All in all, systemd is a great improvement when it comes to boot problems, not at least because there can be full logging from initramfs already.

Really?

I found the systemd documentation installed on my machines tgst have systemd to be very comprehensive.

But it seems the anti-systemd crowd don't know how to find or read man pages, so I'll provide a link to one they can read: here .

"systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."

journal - captures Syslog messages, Kernel log messages, initial RAM disk and early boot messages as well as messages written to STDOUT/STDERR of all services, indexes them and makes this available to the user. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslog or syslog-ng.

for more info http://www.freedesktop.org/wik...

Temporarily ignoring the age of your GPU:

You aren't going to get the AMDKFD without a (currently) bleeding edge kernel, and mesa/xorg stack. It's just not going to happen; at that point you won't have /any/ released version of RHEL.

The new driver is for newer GPUs:

Looking up the GPU you mention here:
http://xorg.freedesktop.org/wi...

The decorder ring pins your card as being based on the Evergreen chipset; which is 4 generations behind the chipsets that the new AMDKFD is targeting.

It is exceedingly unlikely that the AMDKFD will ever support your card; the existing open source drivers are probably the primary support target for your aged hardware, with occasional updates to the binary drivers your only choice if the open source drivers don't fulfill your needs (for a card this old, the performance of the OSS drivers supposedly has caught up).

Except that the new driver is open source. See the official announcement for more info.

That's funny. They had no trouble ignoring these problems before last September, which is when they started requiring signed firmware images.

Nobody is asking for source code or intellectual property rights related to firmware, all they need is the single signed blob of otherwise unreadable code which the new GM20x cards require before doing anything more complicated than simple mode switching. The kind of thing that nVidia said they would provide last year, but haven't.

automatically encrypt your data locally and upload it to multiple locations. These locations can be public locations as only your private key can decrypt the incremental (or full) backups.

Some backends:

• azure backend (Azure Blob Storage Service) Microsoft Azure SDK for Python - https://github.com/Azure/azure...
• boto backend (S3 Amazon Web Services, Google Cloud Storage) boto version 2.0+ - http://github.com/boto/boto
• cfpyrax backend (Rackspace Cloud) and hubic backend (hubic.com) Rackspace CloudFiles Pyrax API - http://docs.rackspace.com/sdks...
• dpbx backend (Dropbox) Dropbox Python SDK - https://www.dropbox.com/develo...
• copy backend (Copy.com) python-urllib3 - https://github.com/shazow/urll...
• gdocs backend (Google Docs) Google Data APIs Python Client Library - http://code.google.com/p/gdata...
• gio backend (Gnome VFS API) PyGObject - http://live.gnome.org/PyGObjec...
• D-Bus (dbus)- http://www.freedesktop.org/wik...
• lftp backend (needed for ftp, ftps, fish [over ssh] - also supports sftp, webdav[s]) LFTP Client - http://lftp.yar.ru/
• mega backend (mega.co.nz) Python library for mega API - https://github.com/ckornacker/..., ubuntu ppa - ppa:ckornacker/backup
• OneDrive backend (Microsoft OneDrive) python-requests - http://python-requests.org/ python-requests-oauthlib - https://github.com/requests/re...
• ncftp backend (ftp, select via ncftp+ftp://)
• NcFTP - http://www.ncftp.com/
• Par2 Wrapper Backend par2cmdline - http://parchive.sourceforge.ne...
• rsync backend rsync client binary - http://rsync.samba.org/

Yeah, I'm not totally sure myself, but it seems to me it's not even available on Gentoo, where we use the MAD Gstreamer decoder plugin for MP3 decoding...

From http://fedoraproject.org/wiki/Installing_the_Fluendo_MP3_plugin the plugin should be located at: /usr/lib/gstreamer-1.0/libgstflump3dec.so (and I don't have it, even with gst-plugins-bad and media-libs/gst-plugins-ugly installed).

From https://bugs.gentoo.org/show_bug.cgi?id=281083 they say the plugin was included in gst-plugins-bad, but this dates back to 2009, so things may have changed...

Hmmmm... http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mpegdemux actually says the plugin originated from Fluendo, but is this really the version talked about in the very (intentionally?) limited report, or a simple fork for which the issue may have been fixed long ago, while not fixed in the official Fluendo version which apparently few really use?

Or does Mozilla ships the plugin themselves? It does not seem to be included in the files installed by Firefox on Gentoo, unless it's been statically linked inside some other file... Even if Mozilla ships it, it's very possible Gentoo does not install it, to use the libraries available on the system...

The Mozilla bug report is still private even though the fix is supposed to be already shipped in Firefox 37...

The relation between Fluendo and Gstreamer is quite blurry too... They employed the main Gstreamer devs for some time, then they left and founded another company, but gstreamer.com is still owned by Fluendo, but they link to the Freedesktop servers to get Gstreamer...

If they actually forked the kernel I'm pretty sure it would be in their repository and not one that's 11 days old.

News like that just feels like an April fools joke to me and I would assume it would to others. I mean, the systemd developers don't operate like that at all. That people would think it to be true at all shows how strange of a perception there is around the systemd project (take that as you want, one way or another people think the systemd devs would be crazy enough to do a full out fork of the kernel--does that mean people are deluded about systemd's goals or that systemd has put off indications that they would do such a thing).

Simple. Don't use SystemD! Get one of the BSD's.

At least spell ir right, you guys, so you don't look like idiots. It's systemd, not "SystemD". Sheesh! Does anyone write FtpD or HttpD or SmtpD?

According to their website (or at least, the Australian version), you get the choice of Win7 or Win8.

As for Linux support, it seems that the mouse buttons don't work. Apparently there's a patch for the kernel which will be included in the next release.

...the bug that prevents me from having accelerated graphics in Linux, I'd be among that 1%. Until then? Reboot... reboot.... reboot... reboot...

Dude, do you even bountysource ?
https://www.bountysource.com/issues/9591789-x-server-called-sharepixmapbacking-on-a-pixmap-that-was-not-created-with-the-usage_shared-flag

systemd-timesyncd
http://www.freedesktop.org/sof...
It's only the client side of NTP, but enough for diskless machines it is designed for.