Slashdot Mirror

Not much chance of successful management when his idea of ignoring log corruption is to IGNORE it. Yes, literally, ignore it. Feature, not bug. In Poettering's own words,

Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.

This guy shouldn't be allowed anywhere NEAR system software!

Because systemd now has a replacement for ntpd.

The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!

Please notice that systemd-timesyncd is only a sNTP v4 client, not a full NTP server like NTPd.
A main focus for systemd is OS containers, and this sNTP client, like the DHCP client, was especially made for such OS containers: When starting 5000 OS containers in parallel the usual sNTP and DHCP clients wouldn't work properly (like in fast enough).

systemd's "timesync" isn't in any way mandatory, and it is easy to compile and run systemd without it.

Because systemd now has a replacement for ntpd.

The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!

Euh, are you aware that clamav-daemon can be socket activated (at least on debian) and that if any program is trying at access the socket will automatically start the daemon. Therea are a lot of other daemon that can be socket activated (syslog-ng, pcscd,...) that then requires (in most of the cases) no explicit dependencies and will only be started on demand. Also, systemd actually includes a lot of mechanism to know about the readiness of a service (see: http://www.freedesktop.org/sof...) and the different states are way more fine grained that what LSB initscripts could provide. It also has knowledge of the different mountpoint on the system (.mount unit files) and they can be used as dependencies.

I'm not sure if this meets your expectation, but a test can be accomplished using the option ExecStartPost. This method is being used in the current Fedora package for MariaDB to test for active database using an additional script called mariadb-wait-ready.

ExecStartPre=, ExecStartPost=
Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially.

If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.

systemd.service

mariadb-wait-ready described as:

# This script waits for mysqld to be ready to accept connections
# (which can be many seconds or even minutes after launch, if there's
# a lot of crash-recovery work to do).
# Running this as ExecStartPost is useful so that services declared as
# "After mysqld" won't be started until the database is really ready.

The mariadb-wait-ready script uses the following command:

/usr/bin/mysqladmin --no-defaults --socket="$socketfile" --user=UNKNOWN_MYSQL_USER ping

http://www.freedesktop.org/sof...
People are already starting on wrapping it: http://search.cpan.org/~lkundr...
so far writes log.

Correct me if I'm wrong but doesn't pulse running at the user level only allow ONE user and system-wide utilization is vehemently discouraged by the developers for SECURITY reasons?

No, it's the other way round: Running PulseAudio as a system daemon (as opposed to the default way of per-user sessions) has security implications.

It does do DNS setup (systemd-resolved)

Well, resolved now does DNS caching too...

you are telling us systemd is not monolithic, because the tools to control it are not? The thing itself is monolithic. Or can you just use the network part without initsytem und journald?

Several parts are written as libraries, so you can just rip them out and use them on your own. Almost everything in systemd can be removed at compile time. There is also documentation for removing even those things that doesn't have compile time configure switches (really tiny embedded systems may have special needs):
http://freedesktop.org/wiki/So...

You can't rip out random parts of the systemd package and expect them to work as intended (probably rare to do in any Linux project). That doesn't mean systemd is monolithic, but rather that it is modular, in the same sense that lego bricks are modular; you can't rip out random parts or bricks from a lego project, and effortless combine them with eg. Playmobil, or another brick system that isn't designed to be lego compatible. Systemd have well defined interfaces, just like lego bricks, so you can use the systemd API's, or even make you own tool variants or replacements if you want too.

You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools that does one thing a does it well. "hostnamectl" sets and displays hostname information, systemctl stops and starts services, "localectl" control the system locale and keyboard layout settings, etc.

All the systemd tools (*ctl) are just totally normal Linux tools; yes, you can use pipes, direct output, and combine them with all the standard tools like grep, tee, sed...

The systemd tools doesn't break any of those rules you listed.

Sure, some of the systemd daemons (not tools) are specifically designed to talk to each other, in order to have logging info from eg. early boot, or in order to prevent a daemon from forking if the kernel capabilities forbid it, but this behavior is quite common on all unix'es.

Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
This is a good place to start, together with a Linux distro that uses systemd:
http://www.freedesktop.org/wik...

I think you are imagining that systemd has a primitive auto restart feature. This isn't the case. It has a very granular and intelligent system of handling restarts, depending of exit code, signal, timeout, or a combination of these.
Look at the man page under "Restart=" here;
http://www.freedesktop.org/sof...

Also look at "StartLimitInterval=, StartLimitBurst=" As their names imply, they can abort restart attempts if the service is restarted too many times in a certain time period.

Furthermore, if you have a really fragile setup where a certain service never must be restarted unless the whole machine reboots, you can let systemd prevent all manual restarts of the service with a single keyword (or make it reboot the system etc).

It is of course the choice of the SA whether any services should be restarted at all. Systemd doesn't force anything.

You can also control coredumps and where to place them in a very granular way.

All in all, systemd allows for some really advanced service maintenance and supervising of services that far surpasses anything else on Linux with its combination of power and coherent ease of use.

Solaris started doing this in 1999 FYI - http://www.freedesktop.org/wik...

sysvinit script files were a simple solution for when the needs were simple. Every other Unix system have dropped sysvinit since, only Linux remained, solely because their wasn't any central core OS linux group, unlike *BSD or Solaris.

Come one, _executable config files_? People would laugh their butts of if Microsoft introduced such a silly concept. systemd is doing the right thing by separating the executable code from the config files.

systemd really is a massive improvement on how things are done in Linux. You should consider actually studying in all seriousness, instead of dpending on what other ignorant people rant about it online.

This is a good starting point;
http://www.freedesktop.org/wik...

The entire commercial and most of the non-commercial Linux industry is converting to systemd at the moment. In the near future, you either know systemd well, or your Linux skills will be in rapidly diminishing demand. Like it or not, systemd is the future of Linux.

(did you know systemd is trying to replace ntpd?)

I didn't know. I was curious so I looked into this.

A new "systemd-timesyncd" daemon has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd.

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019537.html

This seems pretty reasonable to me. This should be a significant improvement on small devices like the Raspberry Pi, will work just fine on the vast majority of computers, and ntpd will still be available for use cases beyond what the simple daemon provides.

P.S. Thank you for a very informative post. It deserves its +5 score.

>> What the heck is wrong with LibreOffice?

You want to know what is wrong with LibreOffice? How about this bug report: Attempting paste into find bar with Edit:Paste (or Cmd-V on OS X) pastes into document.

Reported over 2 years ago, ticket is marked with status "NEW" and "highest critical" importance, and has had more than 2 dozen duplicate tickets. Read the comments; the developers don't even have the slightest clue how copy/paste functionality is expected to work, making insane false claims that somehow OS X is completely different than Windows or *nix. The people making these comments would not be able to keep a software development job at any company I have ever worked for.

LibreOffice is the *only* piece of software I have ever seen where something as fundamental to the operation of a computer as copy/paste actions are broken. Normally when we see a problem with an application on OS X, it's due to a java framework doing something differently than the native operating system's toolkit. Yet this is the only Java application I use on OS X where copy/paste doesn't work.

Imagine using your keyboard shortcut to paste your clipboard at the location of your cursor. Then you find that your clipboard did paste, but to some other fucking location on the screen rather than at your cursor. This is the worst of the examples I have come across with LibreOffice. This is what the heck is wrong with it.

It would be *really, really nice* if someone would be able to finally add the "Insert Cut Cells" option of Excel into LibreOffice Calc.

Hmm... I don't immediately see a bug filed about 'cut cells' in our bugtracker. Could you please file one and mark the Severity as 'enhancement' ? Thanks for the suggestion!

Thanks and have a happy hackfest!

Will do! We're always interested in having hackfests in new places, so if you think that your city would be a good place for our next event, please get in touch. You can email me at [slashdot username]@libreoffice.org

Cheers,
--R

The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.

Either you have an actual user case for not using eg. RHEL's setup and version of systemd, and then you act upon that, or you don't have an actual user case, and there the problem just disappears.

You seem to try to make a problem out of nothing, what exactly is the precise problem you have since you want to configure systemd differently from RHEL?

The problem with discussing with systemd opponents like you is that you are hopelessly uninformed about systemd. That is why the critique seems so vague and imprecise.
Stop getting your information from ignorant systemd haters, and study the project itself. I can recommend the video talks on the systemd page if you want to understand the design of systemd. In a few years, all Linux distros will use it, so it is worth investigating.
http://www.freedesktop.org/wik...

> You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options.

"Compile switch options" are entirely irrelevant to published binary system components, such as systemd in RHEL 7. It's certainly possible to compile many system tools without specific features: this does not make them "separate" from the systemd monolith.

No, "Compile switch options" are entirely relevant for every distro. The distro has full control over which part of of systemd they want to include and with which options switched on as default. Systemd can be tailored in many different ways to fit both super computers and clusters, servers and VM's and OS containers, and desktops and tiny embedded systems. It is extremely flexible.
Just look at the documentation and the source code; it is all there for everyone to see.
http://www.freedesktop.org/wik...

If you don't want how RHEL are distributing systemd, just get another distro, or talk to Red Hat and explain you particular user case.

Yes, I am aware that RDP can send primitives. According to http://blogs.msdn.com/b/rds/ar... RDP under MS-WIndows is more-or-less implemented as a special graphics driver that simply relays the drawing primitive commands from a Windows application over the network to the RDP client.

X11 when being used with drawing primitives works in a similar manner - only the primitive commands are being sent.

However, the key feature that Wayland tries to hype itself on is client-side rendering - Wayland clients draw into a memory buffer (array of pixels) and then tell Wayland what parts of the buffer have changed, in order to force an update.
http://wayland.freedesktop.org...

The problem is that you have to expend more CPU time on the client to determine how to send those pixels to the remote machine in the most efficient manner. You have no insider knowledge on what sort of primitive was drawn (the app programmer will typically use a function call in the graphics toolkit to draw something - but Wayland won't know if the app just drew a 60deg arc, or plotted lots of little pixels all around the place?).

This is clearly a scalability problem on application servers as you add more users. Wayland refuses to go anywhere near remoting, so you have no way of /efficiently/ sending the toolkit primitive operations down the line, without having to rely on the toolkit designers themselves to design a common remoting protocol themselves.

This is a loss of progress - as I mentioned above, once app programmers have to go well out of their way to make remoting work, then many of them won't bother coding for it and you get stuck with useful (but not justified needing low-latency graphics) applications that can't be remoted in a corporate networked environment because the application programmer decided to use an amateur graphics toolkit that only uses Wayland.

Move on all you like, but one of two things will happen - either Wayland will be rejected by corporate environments, or it will eventually have to grow up and establish a decent common remoting protocol that takes no more CPU load than X11 - by which case you've essentially almost recreated X.

Lastly, relying on RDP is legally dangerous as it's patented by Microsoft and we don't know if/when Microsoft will assert the rights to their patents.
http://en.wikipedia.org/wiki/R...

As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.

As an example: systemd removes the ability to run a grep on the plain text log file. And replaces it with something else. Metro also takes away the ability to do some stuff and replaces it with something that the marketing department claims to be just as capable or even more. And perhaps it's all fine when you are within the boundaries that the marketing department envisions. But Linux was never about keeping yourself within some borders. We want tweak and poke, replace X with Y and customize to no end. You can't beat flexibility of a shell script combined with textutils/binutils/fileutils.

No it doesn't. If you need text files logs for some legacy reason, just direct all logging output from journald to syslogd. It enhances the logging info while keeping standard syslog text logs. It is a simple one liner in the systemd config file to enable that behavior.

Furthermore, the journal viewer, "journalctl" can easily be combined with any standard unix tool like grep; that way you can have all the advantages of having an indexed logfile while using standard GNU text utilities.

In fact, the standard pager for viewing log files is good old "less". You can easily disable the pager, or use another one of you like.

All the systemd tools are just normal Linux tools, just better implemented than average. So all the text utils and find utils etc. works absolutely fine with systemd tools. I really don't know where you got that idea that this wasn't the case.

Sure, you can't grep the structured journal directly, but that is what piping was invented for. "journalctl -b1 -p err | grep -i rpcbind" shows all instances of "rpcbind" in the previous boot log only, and only at error level "critical".
It is that easy.

Oh, and the structured journal is well documented with a interface stability promise, and many language bindings to read and write into it. Even rsyslog can read systemd journal files directly.
Here is how it is designed:
http://www.freedesktop.org/wik...

I don't think there are any aspect where shell scripting can't be used together systemd and its tools. In fact, systemd enhances the admins ability to gain secure knowledge about the system and executing programs depending on the state of the system.

No offense meant, but systemd opponents are usually badly informed about even basic points about systemd. They seem to get their opinions about systemd, not from the systemd documentation, but from other users on the net, and quite frankly, some of those users are just spewing random lies and made up stories about systemd because they are blinded by their hatred.

Do yourself a favor, and don't rely in random anonymous systemd haters for your information, but get it from the source instead.
http://www.freedesktop.org/wik...

It is worth getting a proper knowledge about systemd since this is the future of Linux, especially if one intends to poke around and make custom stuff.

As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.

As an example: systemd removes the ability to run a grep on the plain text log file. And replaces it with something else. Metro also takes away the ability to do some stuff and replaces it with something that the marketing department claims to be just as capable or even more. And perhaps it's all fine when you are within the boundaries that the marketing department envisions. But Linux was never about keeping yourself within some borders. We want tweak and poke, replace X with Y and customize to no end. You can't beat flexibility of a shell script combined with textutils/binutils/fileutils.

No it doesn't. If you need text files logs for some legacy reason, just direct all logging output from journald to syslogd. It enhances the logging info while keeping standard syslog text logs. It is a simple one liner in the systemd config file to enable that behavior.

Furthermore, the journal viewer, "journalctl" can easily be combined with any standard unix tool like grep; that way you can have all the advantages of having an indexed logfile while using standard GNU text utilities.

In fact, the standard pager for viewing log files is good old "less". You can easily disable the pager, or use another one of you like.

All the systemd tools are just normal Linux tools, just better implemented than average. So all the text utils and find utils etc. works absolutely fine with systemd tools. I really don't know where you got that idea that this wasn't the case.

Sure, you can't grep the structured journal directly, but that is what piping was invented for. "journalctl -b1 -p err | grep -i rpcbind" shows all instances of "rpcbind" in the previous boot log only, and only at error level "critical".
It is that easy.

Oh, and the structured journal is well documented with a interface stability promise, and many language bindings to read and write into it. Even rsyslog can read systemd journal files directly.
Here is how it is designed:
http://www.freedesktop.org/wik...

I don't think there are any aspect where shell scripting can't be used together systemd and its tools. In fact, systemd enhances the admins ability to gain secure knowledge about the system and executing programs depending on the state of the system.

No offense meant, but systemd opponents are usually badly informed about even basic points about systemd. They seem to get their opinions about systemd, not from the systemd documentation, but from other users on the net, and quite frankly, some of those users are just spewing random lies and made up stories about systemd because they are blinded by their hatred.

Do yourself a favor, and don't rely in random anonymous systemd haters for your information, but get it from the source instead.
http://www.freedesktop.org/wik...

It is worth getting a proper knowledge about systemd since this is the future of Linux, especially if one intends to poke around and make custom stuff.

But the main thing isn't so much that old style script init systems are inherently bad, but that they don't work well with modern day computing.

Strangely it reminds me of Metro UI on Windows that may be nice/useful on tablet/phone but was pushed by MS also to places where it does not belong: desktop or even server.

Similarly systemd may have it's uses for some specific systems and for all I care go ahead. But if systemd is going to take over my workstation and turn the boot process into something that is difficult to read/modify/log/... then I'm not going to be happy.

I don't think it is similar to the GUI formerly known as Metro. As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.
Also, systemd enhances both tiny embedded systems, servers and desktop systems. It doesn't have any weak points in that regard.

You shouldn't worry about "read/modify/log.." when it comes to systemd. It enhances early boot logging considerably since it is active from initramfs. All the config files are well documented text files with declarative statements that are easy to parse for both humans and programs. Systemd has a lot of really nice helper programs like "systemd-delta" that instantly tells which of the hundreds of service config files (unit files) that have been changed, and it is also smart enough to see whether it is a functional change, or just an added comment.

It is however a new way running and maintaining Linux. You can't avoid reading up on the subject if you want to modify or understand things. What many discussions on systemd makes clear is that many people are quite ignorant of its features and its design. They simply haven't studied it.

If you want to admin Linux in the future, it is simply mandatory to read up on systemd. The official systemd site isn't a bad place to start.
http://www.freedesktop.org/wik...

You are using the developer view of "modular", rather than the admin view of "a bunch of small programs each doing only one thing (the Unix model).

If systemd had followed the Unix model, people would be able to take good old init, the rc-replacement from systemd, and syslog, and hook it all together. As it is, if you want one thing systemd, you get all of it.

If not for the Gentoo people who forked udev, "if you want one thing from systemd" would have included systemd.

First of all, let me say that "Unix model" and all similar references to Unix philosophy etc, are totally content free platitudes in my opinion. There is no canonical "Unix" book where a Unix-pope have decreed ex catedra what "Unix" is. Heck, Unix was even born without support for "piping" between programs. The "Unix model" end up as 1990's time freeze because that keeps some old sysadmins happy that they don't need to learn anything new.

So it is easy to argue that systemd actually follows the "Unix model" in every way, and is modular, even in the "admin" sense of the word as you describe it.

Systemd is an umbrella project with many small programs collected in one utility box, just like "busybox" or "kernel-utils". It consist of many small binaries, like "systemctl" "localed" "timedated" etc. All these binaries behaves exactly like any other Linux/Unix binary tools; they tend to do one thing only (and do it very well), and can easily be combined with any other standard GNU tools like grep, sed, tee, ed, less and so on, by utilizing piping (eg. "systemctl | grep -i foobar") . They are in fact indistinguishable from any other Unix tool in the way they behave.

You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options. There is even an official page about how to reduce systemd even further http://freedesktop.org/wiki/So...
One of the key drivers behind systemd is the embedded market, and they want minimal systems. On desktop and servers, it doesn't make much sense removing systemd options, since they are basically zero-overhead and provides options that nobody else does.

And yes, systemd works fine with together syslogd, in fact it enhances it considerably because systemd is able to get early and late boot log info since it is active from early boot in initramfs.

What you can't do is ripping random elements out of the systemd toolkit and expect it to work unmodified together with any other random system.

Thus speaks someone who has never seen a crash/restart loop. Large apps like databases can take several minutes to start up and recover, and then immediately die again. The next morning you have several terabytes of core dumps, and a corrupt database, and have to restore the latest backup.

That situation is easily handled by systemd since it has total knowledge and supervision of all running processes and services, and has extensive capabilities for various ways of restarting crashed services. This included ways to limit restarts, so as if a services crashes more than eg. two times within eg. 10 minutes it wont restart that service again (or reboot the entire system, or many other actions). This is controlled by simple keywords added to the config files like "StartLimitInterval=, StartLimitBurst="

You can even make systemd clean up core dumps after a failure if that is what you want.

Here is a overview of the many fine grained service control mechanisms that systemd supports;
http://www.freedesktop.org/sof...

At the moment, http://www.freedesktop.org/wik... is the best site for systemd information. It could have a better organization, but there is an awful lot of information about systemd, even the nitty gritty details needed for developers.

I have always admired RH for it's feature set and pursuit of enterprise-related features.
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations? /etc/network/interfaces
vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).

Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... and "cgroup" https://www.kernel.org/doc/Doc...

All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.

So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik...

The TC license actually has the following text in it :

    NOTHING IN THIS LICENSE SHALL IMPLY OR BE CONSTRUED AS A PROMISE,
    OBLIGATION, OR COVENANT NOT TO SUE FOR COPYRIGHT OR TRADEMARK
    INFRINGEMENT.

A license is a promise not to sue, if you follow the licensing conditions. The license literally says 'there is nothing you can do to potentally stop us from suing you'. This makes it non-free because nothing in the license allows you to do anything more than regular copyright would allow (which is nothing) without risk of being sued. It's not only not FLOSS, it's literally not distributable or usable without a risk being sued.

http://lists.freedesktop.org/a...

I suppose now we're wandering into fiddly terminology territory here...my point is that saying "TC is NOT a FOSS project, never was." without any further qualifications seems, if not outright wrong, pretty misleading (we do like to argue technical correctness around here). We're saying it's Free Software but not necessarily Open Software at this point, yes? If FS is a stricter subset of OS, it would seem to be that we've proved that TC *is* in fact FOSS, then.

Looking at the Wikipedia article reference for the most-relevant-looking statement from my previous post, all I found was the president of OSI saying "TC license is bad! Bad bad!!" without actually giving any details. I really expected more from that article. And since Google cache doesn't seem to have a link to the old TC license page, I'm having a bit of a hard time referring to the license itself. More research digs up verbiage that ambiguously states that TrueCrypt (the binaries? the source? both?) must also be distributed "freely" (as in free of charge I believe).

It has been explicitly stated* before that open-source software does not necessarily have to be free as in beer. So if costed distribution is fine, without-cost distribution must be, too. The TCL *limiting* distribution to without-cost is the issue? As mentioned before, the Free Software core tenets don't seem to have a problem with this on the face of them. I imagine RMS wouldn't be too broken up about it if forced-without-cost distribution were the norm, either.

I would still call TC FLOSS, but if OSI/FSF don't give their stamp of approval it apparently can't ever be FLOSS.

* by /. people

It's mostly a case of missing hardware that has to be emulated to get something compliant with GL3.3.
See http://lists.freedesktop.org/a...

If the app is built on top of GTK+ (I assume Qt is the same?), the app will support both and the backend will be selected at runtime.

I.e. GDK_BACKEND will be wayland by default, but if you log in via ssh and set X forwarding, it can be set to "X11". It should be completely seamless.

RDP protocol support was merged into Wayland over a year ago. Wayland's original developer prototyped a remote display implementation almost two years go, before 1.0 was released. This is in addition to XWayland already providing an X server to host legacy X apps.

Wayland will have good remote display. The peanut gallery rant-fests around here not withstanding.

Anyhow. Now you know. If I'm wrong get a refund.

If DRM is really impossible to implement in F/OSS software, without closed source or the threat of political force... Then what's the worry?

It seems like the worst-case scenario is media providers get a false sense of security and start providing content without silly plugins that actually ARE closed and non-accessible (under the threat of legal action).

The DRM is effectively forced.

I going to just flat out state that you've obviously never attempted to run the Netflix plugin from a ChromeOS machine (ChromeBook/ChromeBox) on another Linux platform, and discovered it won't run.

The modules in this case do navel-gazing and examine the container program to verify that the container program ins an unadulterated official build, such that you can't just compile up your own version of the browser, and expect the module to continue operating.

For Netflix on Linux desktops, this Navel-gazing took the form of utilizing the HAL, which was deprecated by its authors in 2008: http://www.freedesktop.org/wik... which was then used to generate a unique device identifier, which was used in the authorization and decryption process for the data, after having been watermarked with the same identifier at the source so that you could tell who exactly rented the content that was then stripped of DRM, and uploaded to a copy site.

This same (deprecated) module was required by Adobe FlashAccess beginning in February 2012, and was the reason for the sudden failure of rented content from both Amazon and YouTube, which both used FlashAccess as a means of DRM'ing "premium content" starting on that date.

So it's about as true to say that the DRM "isn't forced" as it's to say that the HTML "trusted proxy" mechanism would not be forced in order to allow you to make HTTPS connections, should it be standardized, thus giving a centralized ISP choke point, nominally for caching content, but practically, for introspecting HTTPS streams to make sure they are not transporting "unapproved content". If you can't access content without DRM, or you can't access HTTPS without authorizing the proxy at your ISP to listen in on the conversation, effectively instituting an automatic MITM attack for all your communications, it's kind of hard to credit participation in the scheme as "unforced" (Sure... you could choose not to have encrypted internet connectivity at all, instead of encrypted activity your ISP or anyone who got a single FISA order into your ISP could listen in on, but is that really a choice?).

Just today installed Fedora 20 (KDE spin) on a HP 2230s laptop. After the initial installation of all system updates I restarted the computer. Now every time I login to my desktop, I'm greeted with "KWin crashed unexpectedly". I cannot start KWin at all and have no desktop effects. Please help.

At the same time I'm personally working with the Intel guys with an issue of backlight flickering on this same laptop under Linux.

I have to deal with problems like this all the time. Open source is garbage!!!

I'm not arguing it has to be syslog format, just text.

No argument from me there. I don't really understand the rationale of the binary log, so hopefully that will change in the future.

...until you don't GET the log because it wasn't *WRITTEN*,

In these situations you typically redirect the logs to a remote server, something that journald is supposed to be able to do very easily (I've haven't tried to do this yet). But I get your point. The problem with having only the console log, which was the case with most of the init scripts, is that you often don't have a console, or the console output is too long catch the error message. So the permanent log is a better place to put important messages. But I agree it is more convenient to have the console log as well as the permanent log in certain situations. Apparently this can be done with journald. Maybe it's worth a try.
http://log.or.cz/?p=327

Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log.

Agreed. Thankfully this is actually possible with systemd.
http://freedesktop.org/wiki/So...

How easy it is will depend on where the boot process failed, but it is possible to get to an emergency console in nearly every situation without rebooting.

don't *PREFER* an order, sometimes I *REQUIRE* an order.

Yes, you can require an order. But there is a difference between requiring a service (ex: apache requires net and syslog) and requiring an order (ex: net will probably come up first, but apache doesn't strictly require it to). If you do need a specific order, for example a service that requires a network filesystem to be mounted to get its config files, you use the Require combined with the Before or After directives.
http://www.freedesktop.org/sof...

In SysV, almost *nothing* happened before filesystems,

The thing is, not all filesystems can or need to be mounted at the same time, and this is not possible to encode within /etc/fstab. The hack to do this with sysV was to add the _netfs option to your mount to tell the mount command to wait until it thinks the network is up, which only worked maybe 50% of the time. If you think mounting root over nfs is fun, try a service that starts a service that is dependent on the availability of an iscsi target.

I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy.

That's the thing, though. It really isn't any more complicated than modprobe.d or pam.d or if-*.d or any of the other config systems that compose a typical modern linux system. It is just new, and will probably require some reading of the docs. But it doesn't take hours. For most, it takes about 10-20 minutes to figure out how to do something you need to do with systemd.

I've gained *no* capability that I didn't already have

I think that's the problem. Too many people have a "works for me" mentality and don't acknowledge the possibly complex needs of other users. Ultimately, linux aspires to be as useful to as many people as possible, not only to the people who have succesfully used it up to now.

I'm not arguing it has to be syslog format, just text.

No argument from me there. I don't really understand the rationale of the binary log, so hopefully that will change in the future.

...until you don't GET the log because it wasn't *WRITTEN*,

In these situations you typically redirect the logs to a remote server, something that journald is supposed to be able to do very easily (I've haven't tried to do this yet). But I get your point. The problem with having only the console log, which was the case with most of the init scripts, is that you often don't have a console, or the console output is too long catch the error message. So the permanent log is a better place to put important messages. But I agree it is more convenient to have the console log as well as the permanent log in certain situations. Apparently this can be done with journald. Maybe it's worth a try.
http://log.or.cz/?p=327

Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log.

Agreed. Thankfully this is actually possible with systemd.
http://freedesktop.org/wiki/So...

How easy it is will depend on where the boot process failed, but it is possible to get to an emergency console in nearly every situation without rebooting.

don't *PREFER* an order, sometimes I *REQUIRE* an order.

Yes, you can require an order. But there is a difference between requiring a service (ex: apache requires net and syslog) and requiring an order (ex: net will probably come up first, but apache doesn't strictly require it to). If you do need a specific order, for example a service that requires a network filesystem to be mounted to get its config files, you use the Require combined with the Before or After directives.
http://www.freedesktop.org/sof...

In SysV, almost *nothing* happened before filesystems,

The thing is, not all filesystems can or need to be mounted at the same time, and this is not possible to encode within /etc/fstab. The hack to do this with sysV was to add the _netfs option to your mount to tell the mount command to wait until it thinks the network is up, which only worked maybe 50% of the time. If you think mounting root over nfs is fun, try a service that starts a service that is dependent on the availability of an iscsi target.

I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy.

That's the thing, though. It really isn't any more complicated than modprobe.d or pam.d or if-*.d or any of the other config systems that compose a typical modern linux system. It is just new, and will probably require some reading of the docs. But it doesn't take hours. For most, it takes about 10-20 minutes to figure out how to do something you need to do with systemd.

I've gained *no* capability that I didn't already have

I think that's the problem. Too many people have a "works for me" mentality and don't acknowledge the possibly complex needs of other users. Ultimately, linux aspires to be as useful to as many people as possible, not only to the people who have succesfully used it up to now.

Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

I don't get where you think *text* is a lossy format, but ok. Lets add complexity and failure points to something that should be easy.

You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?

Apples and oranges. Text is never a lossy format.

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

Well, you do *mention* apache, so the most common approach is to just kill the master process, and all the child processes die. You know, unix systems. In case of apache, you even have an utility for it - apachectl. Other approaches would be 'service apache22 stop', kill -TERM `cat /path_to_apache_pidfile`, and of course, kill -9 $(ps -ef |grep apache2 |grep -v grep| awk '{print $2}') or any other variant (eg. in freebsd you could do a ps ax | grep Ss | grep httpd to determine the master apache process and its pid to kill). On many linux systems, you also have killall and/or pkill, that will achieve the same effect by process name, and easily usable with apache, nginx and the cgi wrappers you may have running.

I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

I did. FreeBSD 9.2. Most of the sleeps are for hardware settling. Replacing a shellscript sleep() with a binary version of it is not a solution anyway. Both rc.d and init.d approaches allows you to prioritize script startup, to achieve that same effect. In FreeBSD, the rcorder (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8) allows you to quickly visualize service dependencies. In OpenBSD I specify in rc.local the order I want my stuff to start. I'm assuming other systems provide vaguely the same funcionality, its not rocket science. (Again, a solved problem).

Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

I'm not against uniformization. What I don't see is the need for yet another tool that fragments even more the available options. And uniformization is pretty common in other operating systems - check eg. FreeBSD and OpenBSD: they are quite different in terms of setup, but not that different. Its not like it wasn't possible before. That approach exists for decades.

Check out http://www.freedesktop.org/sof... [freedesktop.org] , especially all the options starting with "Private" there.

It sounds like a meta-version of linux containers. Why would I want that implicit on a startup script? Its about doing one task and doing it good.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

You did not suggest. You touted it as solution to problems that, frankly, do not exist. It may have features that are very helpful, it may solve a lot of problems, but you mentioned none. Not one valid existing problem.

By then all the hotheads that are running for the BSDs now will be back

Probably not. BSD is not usually appealing to the linux crowd, at least server-wise (the guys that would actually take advantage of some of the features you mentioned). And the ones I know did t

What would have been lost by adding them to /etc/fstab?

Well, then it wouldn't be managing the mounts. It would be just executing mount -a, just like a sysV script. This works fine in some ways, but breaks in other ways. For example, a container that uses an iscsi target as its backing store. There is a complex set of dependencies that involves mounting local filesystems, starting network services, connecting iscsi devices, mounting network filesystems, starting the container. Another example is the udev system, which certain services interact with in different ways. There are a bazillion hacks to deal with these issues with sysV that aren't pretty. Systemd solves all of them.

That way you would be able to tell systemd not to mount them, if need be, or to mount them elsewhere.

You can still do that, you just have to do it the systemd way. I know its frustrating to have to learn a new way, but it is not as bad as you think.
http://www.freedesktop.org/sof...

Said standard being the systemd source code of the day. No external tools can handle the format.

Agreed. A major shortcoming. Hopefully a formal spec will be forthcoming. This will make it easier for external tools to parse the logs.

the journal instead of a set of randomly formatted text-dumps all over /var/log,

I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.

You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?

a convenient way to kill apache with all the crap that it started,

It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.

a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.

Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.

I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

a more secure system by being able to isolate daemons from one another and the rest of the system.

So, its a startup daemon AND a kernel, huh?

Check out http://www.freedesktop.org/sof... , especially all the options starting with "Private" there.

a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them

Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.

Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.

Actually, Bluetooth headphones are also broken in Linux since forever, and no one cares: https://bugs.freedesktop.org/s...

Finding "systemctl -xb" you just realise that there actually is something neat about the system being able to understand it's own logs. Finding out that your system is failing to boot because of one directory permission (/var to the wrong user) and that it doesn't start a shell at all or anything you can debug with is just disappointing.

I guess you mean "journalctl -xb". Even so, I had an issue with a mount failing (not a critical one), and systemd dropped me into a what it called a root shell. (See #733232 for a similar situation). Of course, then the system was practically fully up, so the shell was fully functional. However, I refuse to believe that systemd can't start a shell to debug. It might not do so by default, but it can. See http://freedesktop.org/wiki/Software/systemd/Debugging/ (and https://fedoraproject.org/wiki/Systemd_early_debug_shell for what I presume is an older guide).

So, this bug dates back six years, and that's just when someone finally decided to report it. It's still not fixed in 2014. The basic functionality isn't there. Nobody is willing to fix it, so as you say, it apparently isn't an issue. Because so few people use Linux for gaming? Perhaps. Because so few developers actually want to put forward the effort to fix it? Definitely. But it's just another example of something that Linux can't do, yet other systems handle it without a problem. So, someone should just do it themselves, or pay a developer to do it, but both of those options still leave the user asking, "Why the fuck does Linux even have this problem to begin with? It's something so basic and fundamental." But, not you. You don't ask such questions, because you're a fanboy.

Right. What would you consider a "non faulty OS, Linux? Then I guess Torvalds should be shot because when it comes to bugs here they come! . Oh and don't forget which OS it was that gave us heartbleed. Was it Windows? No no no no, was it OSX? No no nooo no, was it Linux? yeah yeah yeah yeah! BTW you should try to play the "how many year old Linux bug" game, its fun and easy! Simply type into any search engine " (X) year old Linux bug" with (X) replaced by a random number, see how far back you can go! I doubt you will be able to top 20 years old but single digits are easy peasy!

Anybody still on XP deserves what they get, they got 12 years of support, which just FYI is 10 years longer than the average Linux distro LOL, unless you consider the bi annual death march to be "support", and they have had more than enough time to switch over to a newer version of Windows. They can't even use the hardware excuse as the average XP box is a power piggie P4 and for less than $100 you can toss that P4 board for a Bobcat or jaguar board that will run rings around the P4 while using less power under load than the piggie P4 does at idle. they can even keep their old IDE drive using a $7 IDE to PCI converter so there really is no longer any excuses, anybody who hangs onto a thirteen year old OS (XP was released in 2001 and has more in common with NT4 than it does with a modern OS like 7/8) that is three and soon to be four versions behind? Deserves what they get.

Out of the hundreds of boxes I moved to 7, how many problems did I have? A grand total of THREE, and one of those doesn't count since the software in question (Quickbooks 07 IIRC, may have been 06) was "broken by design" and tied to a VERY insercure version of Flash (V7) and would refuse to install if ANY version of Flash other than 7 was on the system, but it took less than 30 minutes to turn the XP install into a VM and run it on Win 7 via Virtualbox. The other 2? A scanner from 2000 that was so low res a $35 all in one printer gave the guy a 300%+ increase in quality and an old ATI IGP that ran but was flaky, it cost a grand total of $8 to replace the IGP with an HD2400. That system was a first gen C2D with 2GB of RAM and was recently traded back in on a new quad, I turned around and sold it to my landlord who runs it 6 days a week and it purrs like a kitten. If a 8 year old system can run Win 7 so well the customer who buys it in 2014 says "I just love this machine,it runs my stock software and surfs like a dream" there really is no excuse, let XP die already.

Oh and just for shits and giggles I tried the "hairyfeet challenge" using that box before I reloaded Windows, since it would probably be considered high end of the XP era hardware and thus would give Linux a performance advantage over some dusty P4, result? Ubuntu crapped the video first update, PCLOS crapped out on the second, no point in continuing after that since it had already failed the test.

Easy. As much as I hate to say it. https://bugs.freedesktop.org/s... is the complete showstopper, not only for me. For the last 2 years, suddenly, SVG, EPS simply do not work anymore, at all. I have hundreds of lecturing slides that from yesterday to tomorrow cannot be shown any longer. And what has been done so far? Read the comments, and read the comments in the dup bug reports.
This isn't as dangerous as the Heartbleed, but similarly without any concern nor consideration by the people in the project. Though they keep rolling out new versions regularly, which have been suffering from this, known, bug for all versions since 4.X.

That's the great thing about open source, you can fix it yourself! /sarcasm

[my excuses for being redundant - please mod me down! - but I have to say this to this apologetic (?) parent:]
https://bugs.freedesktop.org/s... is the complete showstopper, not only for me. For the last 2 years, suddenly, SVG, EPS simply do not work anymore, at all. I have hundreds of lecturing slides that from yesterday to tomorrow cannot be shown any longer. And what has been done so far? Read the comments, and read the comments in the dup bug reports.
This isn't as dangerous as the Heartbleed, but similarly without any concern nor consideration by the people in the project. Though they keep rolling out new versions regularly, which have been suffering from this, known, bug for all versions since 4.X.

Easy. As much as I hate to say it. https://bugs.freedesktop.org/s... is the complete showstopper, not only for me. For the last 2 years, suddenly, SVG, EPS simply do not work anymore, at all. I have hundreds of lecturing slides that from yesterday to tomorrow cannot be shown any longer. And what has been done so far? Read the comments, and read the comments in the dup bug reports.
This isn't as dangerous as the Heartbleed, but similarly without any concern nor consideration by the people in the project. Though they keep rolling out new versions regularly, which have been suffering from this, known, bug for all versions since 4.X.

The entire PC platform as a consumer product is in danger.

Yeah, that's what Linux zealots like yourself have been preaching for some time now, knowing full well that Linux on the desktop is a complete failure, so the strategy became moving the goal posts to save face. Rather than fix bug like this, you'll just keep lying because it's easier.

As usual, trolls like you don't mention the whole story. While the Linux kernel may sometimes have major security problems patched yearly, bugs that affect usability of the entire GNU/Linux userland sometimes take years to get fixed, if at all. Of course, you don't mention that.

I read the mailing list thread as well as the bugzilla report...Kay certainly was certainly being a complete dick here.

He was definitely justified in bouncing the dude, nd "being a dick" is a very gentle term. I read the report, Sievers needs to go to Redmond, where bugs are actually features.

Your claim notwithstanding, my experience on several different machines with several different Nvidia video cards suggests that the Nvidia Linux drivers for those cards kick ass.

Were you perhaps referring to Nouveau, which quite frankly sucks rocks?

(Sorry, guys--I've work to do and that means my desktop needs to stay up a bit longer than 10-15 minutes at a time. I'll check back with you in a year or two.)

Is that the Kay Sievers reply?

Closed: Wontfix, Not a bug

Again, move discussions to the mailing list; this is a bug tracker, but there is no bug to track or fix here.