Slashdot Mirror

Poppler is used in okular, evince, gimp ... ( source )

https://www.freedesktop.org/wi...

The case for merging is not convincing.

Shortening the search path is a more convincing argument than the nonsense they put forth. Including the isolation from upstream compatibility bullshit.

https://www.freedesktop.org/wi...

So you're mad that you might have to read a manual to a highly complex system? I'm impressed that you do "real work" on a system that you have no idea how it works!

If you don't want to bother reading manuals because you're too busy doing "real work". Why did you even bother upgrading to RHEL7? Stick with RHEL6, which is supported until 2024.

And yes, systemd is incredibly well documented. Just the man pages alone on the system:
$ man -k systemd | wc -l
147
But for online documentation: https://www.freedesktop.org/wiki/Software/systemd/

In almost every way systemd is better than sysv, upstart or other init systems, and it fixes many long standing issues SysV had.

I'm sure RedHat wouldn't mind taking over exclusive maintenance of the kernel. Maybe they have a developer or two that are finished working on certain mature projects. I guess they'd rather have them as kernel developers than what they are doing right now.

Just kidding (maybe)

I'm sure RedHat wouldn't mind taking over exclusive maintenance of the kernel. Maybe they have a developer or two that are finished working on certain mature projects. I guess they'd rather have them as kernel developers than what they are doing right now.

Just kidding (maybe)

He doesn't let political crap into the kernel. One example here.

and I really don't think it should matter that I have a 7870 LE.

Interesting fantasy land you live in, where hardware details don't matter. Also interesting how you come in throwing around insults without having done a bit of research yourself.

The 7870 LE s an oddball using the Tahiti chipset instead of the more popular and well supported Pitcairn chipset. Bugzilla: Tahiti LE: GFX block is not functional, CP is okay

It seems, some people got it working, but if it were mine I would just junk that 2012 card. If you want something really minimal, HD 6450 is perfectly servicable, and fanless. If you want something powerful but cheap, RX 400 series or RX 500. That particular card is, unfortunately, a bit of an orphan. It happens.

You still don't know that systemd is modular?

Speaking of belly-laughs...

Modular software requires well defined interfaces that separate abstraction from implementation.

A good anti-example is DBus, a "module" that most of systemd cannot live without.
Go ahead, try to write something compatible with DBus without looking at that list of "D-Bus secret internal implementation details".

Modular ... You keep using that word. I do not think it means what you think it means.

The differences are :

- On Windows, the use of .ini files has completely disappeared. Instead the registry hives being an opaque format that can be only access (in theory) with Windows' API of regedit. This would make it impossible to hand access them manually, say from a boot stick. (Well, in practice, there are 3rd party Linux tools able to access the hive format, so fixing from a boot stick is possible, but you got the idea).

  - In gnome with gconfig the configuration is still stored in sets of plain XML files. Only they are now stored in an organized fashion in a specific set of subdirectories, and there's a centralized API and tool set to access them. But they are still human readable (you could still edit them with your favorite editor - emacs/vim/nano/ed) and easily machine readable (e.g. with your favorite Perl module such as XML::Twig).

The windows equivalent would have been if the .ini were kept, but now Microsoft defined a specific path to store them (e.g.: in a specifc subfolder tree within %USER_PROFILE% or whatever, instead of all over the place like in good old Win 3.x days) and mandated a specific API to manipulate them.

The closest thing to Windows' registry in Linux-land would be journald's internal database format, except that it has a very well documented format and journald forwards messages to any of your favorite system logger as soon as that deamon startsup - and it is configured to do so by default on virtually all the GNU/Linux distributions except for the most storage-starved ones in embed systems (e.g.: mercore/Sailfish OS doesn't have a syslog forwarding setup by default because it has to run on your smartphone limited internal flash. But Raspbian forwards to syslog by default).

Come on. Give the Gnome bloatware pushers time. Windows had a huge head start.

But Gnome will get to Windows levels of impenetrability, unmaintainability, and unreliability soon enough.

The differences are :

- On Windows, the use of .ini files has completely disappeared. Instead the registry hives being an opaque format that can be only access (in theory) with Windows' API of regedit. This would make it impossible to hand access them manually, say from a boot stick. (Well, in practice, there are 3rd party Linux tools able to access the hive format, so fixing from a boot stick is possible, but you got the idea).

  - In gnome with gconfig the configuration is still stored in sets of plain XML files. Only they are now stored in an organized fashion in a specific set of subdirectories, and there's a centralized API and tool set to access them. But they are still human readable (you could still edit them with your favorite editor - emacs/vim/nano/ed) and easily machine readable (e.g. with your favorite Perl module such as XML::Twig).

The windows equivalent would have been if the .ini were kept, but now Microsoft defined a specific path to store them (e.g.: in a specifc subfolder tree within %USER_PROFILE% or whatever, instead of all over the place like in good old Win 3.x days) and mandated a specific API to manipulate them.

The closest thing to Windows' registry in Linux-land would be journald's internal database format, except that it has a very well documented format and journald forwards messages to any of your favorite system logger as soon as that deamon startsup - and it is configured to do so by default on virtually all the GNU/Linux distributions except for the most storage-starved ones in embed systems (e.g.: mercore/Sailfish OS doesn't have a syslog forwarding setup by default because it has to run on your smartphone limited internal flash. But Raspbian forwards to syslog by default).

Wayland (display server protocol) From Wikipedia, the free encyclopedia Wayland Wayland Logo.svg Screenshot of a Wayland demonstration Screenshot of a Wayland demonstration Original author(s) Kristian Høgsberg Developer(s) freedesktop.org et al. Initial release 30 September 2008; 9 years ago[1] Stable release Wayland: 1.14.0[2], Weston: 3.0.0[3] / 8 August 2017; 7 months ago Preview release Wayland: 1.13.93, Weston: 2.99.93[4] Repository https://cgit.freedesktop.org/w... Edit this at Wikidata Development status Active Written in C Operating system Linux, FreeBSD, DragonFly BSD Type Windowing system Display server License MIT License[5][6][7] Website wayland.freedesktop.org Wayland is a computer protocol that specifies the communication between a display server (called a Wayland compositor[clarification needed]) and its clients, as well as a reference implementation of the protocol in the C programming language.[8] Wayland is developed by a group of volunteers initially led by Kristian Høgsberg as a free and open community-driven project with the aim of replacing the X Window System with a modern, simpler windowing system in Linux and other Unix-like operating systems.[8] The project's source code is published under the terms of the MIT License, a permissive free software licence.[9][5] As part of its efforts, the Wayland project also develops a reference implementation of a Wayland compositor called Weston.[8] Contents 1 Overview 2 Software architecture 2.1 Protocol architecture 2.2 Protocol overview 2.2.1 Wayland core interfaces 2.2.2 Wayland extension interfaces 2.3 Extension protocols to the core protocol 2.3.1 XDG-Shell protocol 2.3.2 IVI-Shell protocol 2.4 Rendering model 3 Comparison with other window systems 3.1 Differences between Wayland and X 3.2 Compatibility with X 4 Wayland compositors 4.1 Weston 4.2 libinput 4.3 Wayland Security Module 5 Adoption 5.1 Desktop Linux distributions 5.2 Toolkit support 5.3 Desktop environments 5.4 Other software 5.5 Mobile and embedded hardware 6 History 6.1 Releases 7 See also 8 References 9 External links Overview The evdev module of the Linux kernel gets an event and sends it to the Wayland compositor. The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what is on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events. As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens by the client via EGL, and the client just sends a request to the compositor to indicate the region that was updated. The Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an ioctl to schedule a pageflip with KMS. In recent years,[when?] Linux desktop graphics has moved from having "a pile of rendering interfaces... all talking to the X server, which is at the center of the universe" towards putting the Linux kernel and its components (i.e. Direct Rendering Infrastructure (DRI), Direct Rendering Manager (DRM)) "in the middle", with "window systems like X and Wayland ... off in the corner". This will be "a much-simplified graphics system offering more flexibility and better performance".[10] Kristian Høgsberg could have

I am on a laptop and synclient no longer works because they are using a different touchpad driver. I suppose it is a matter of time before this is the situation on Debian too.

Yes! You triggered the correct memory. I've encountered this. Synclient was superseded by libinput as a more generic system. Try here:

https://wiki.archlinux.org/ind...

The arch documentation for Linux is excellent by the way, even if you don't use arch. TL;DR, you use xinput now, not synclient.

Gnome Shell - the default (AFAIK) for Debian.

I don't use GNOME, but I believe you can put scripts in somethig like .config/autostart

Here's the spec:

https://specifications.freedes...

The documentation has the flavour of the Isla de Muerta: it cannot be found save by those who already know where it it, but now you know too.

We have too many bad standards as it is.
The Linux Standard Base requires a bunch of useless crap that is applicable to only 1 overly controlling vendor (Debian distros need `rpm` to comply because Redhat) There are plenty more examples: https://refspecs.linuxfoundati...
On the opposite side, you have POSIX, which is held back by another big industry vendor (this time Oracle because Solaris) Most shells have support for a large percentage of "bashisms", yet no useful sh features have been added to the standard.
Then you have pseudo standards that are woefully un-maintained at https://www.freedesktop.org/wi... which by their own admission isn't a standards body. Half the links are either 404 or completely dead URLs

This is a prime example for the necessity of libre drivers.
The good news is, libre drivers for Nvidia GPUs exist, and they continue to work on 32-bit Linux.
AMD Radeon GPUs have much better open source compatibility, though.

Yes, DisplayPort...

Boot time reduction wasn't the primary goal of systemd.

The very first feature touted on the systemd website is the "aggressive parallelization capabilities".

I'm not going to argue over the semantics whether or not it was a "primary goal" which I never even claimed. Reducing boot time is very obviously a goal of systemd.

I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not,

Then there is a problem with the service unit file. A common one is not setting the correct Type= value

or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.

Then the service unit file should have a suitable TimeoutStartSec= specified.

Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwritten on a package upgrade.

And getting anything of value out of the log is a pain in the ass.

Really? 'systemctl' to find failed services, 'systemctl status foo' or 'journalctl -b' to see why services failed are quite easy to use and remember, and will find most boot issues.

Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons.

It sounds more like the daemons are unreliable, or haven't got useful defaults in their service unit files, but that is very easy for you to fix (copy the original unit shown in 'systemctl status foo' to /etc/systemd/system/foo.service, edit as necessary, run 'systemctl daemon-reload'). See systemd.unit for more info.

Nothing has been gained with systemd, at least not on servers.

My experience so far has been that systemd has saved more time than it has cost, and the 'cost' is a once-off investment, and the savings continue.

A big ol ball? My init.d was about 13 scripts big which were readable and editable.

On what distro was this?

Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in /etc/fstab mounted. For example, is /var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is /usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.

Ever tried to edit systemd files?

Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.

Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.

Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.

You copy the existing file from /usr/lib/systemd/system to /etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.

Systemd makes every system into a dependency mess.

Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.

Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).

However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.

According to it's documentation, FreeBSD behaves the same way (thought the option name is different):

If the option ``failok'' is specified, the system will ignore any error
          which happens during the mount of that filesystem, which would otherwise
          cause the system to drop into single user mode. This option is imple-
          mented by the mount(8) command and will not be passed to the kernel.

THE PROBLEM IS: That systemd throws away what's good about traditional init systems (like "everything is a file"; modularity; being able to do things with a simple file manager, text editor and maybe a script.).

I take it you've never looked at /etc/systemd/system then? Because that's exactly what you'll find there. Files. Plain text files. That control systemd's init behaviors and dependencies.

It could have done the event/trigger thing *without* sacrificing modularity (tools that do *one* thing, and do it right!).
It could have acted less like a dominatrix on a power trip, swallowing everything.

A) Except, randomly firing off process threads asynchronously, and the dephell doing that causes, is the exact reason why systemd was made in the first place. You need some level of process management to do any form of dependency resolution for services. Which was the main issue.

Users have their own services, such as VPN connection daemons, input method editors, midi synths, ID management daemons, SSO, xeyes, etc. that need to run as well, and they have their own dependencies. Some even depend on system services. (For example, Timidity requires the sound system to be running before it starts or say good bye to anything requiring PCM support. Another would be my workplace's proxy daemon which informs the corporate proxy of the user's login.) So systemd needed to be able to reliably tell when a user logged in and logged out to be able to perform dependency resolution for those services as well. Hence the seat management.

B) You are right about some portions of systemd. For example it's DNS resolver. We always have to disable that on new installs due to it breaking DNS resolution of our domain controllers, forcing sssd to fail to log in network users. Why? Because it has "memory" that if the DC doesn't respond immediately when it asks it something, it will never query the thing again. Worse, it breaks TSIG updates because it makes itself the host's only DNS server.

That's the first real gripe I've ever had about systemd. Most of the time it's always been "My ancient initscript that has improper dependencies is broken by systemd, wahhh! Why couldn't they just leave well enough alone???" To which my response was: Maybe because it's those quirks that cause endless amounts of head scratching and claims of "works for me, not for you", due to obscure errors that keep linux from becoming the desktop OS it desperately wanted to be. Now it seems a bit more justified, though nowhere near as much as people would have you believe.

The real issue with linux has been it's lack of standards. Doing something as simple as changing the desktop wallpaper to be something specific, or as complicated as deploying certs to a system's various browsers and hitting all of them with any level of guarantee isn't, and never has been, easy with linux. Every single program has it's own config hidden away in multiple places. (Is it /etc, ~/.config, ~/.local, gconf, or DBUS that I need to change? Are we sure it's not baked into some shared library?) Some even have different config locations and methods depending on the distro. (libreswan Ubuntu: config in /etc plain text files, libreswan Fedora: config is in some nss database stored in /etc.) Others have overriding configs in different places. (Is the order of preference ~/.local => ~/.config => /etc , ~/.config => ~/.local => /etc, or ~/.bad_program_specific_dir => ~/.config => ~/.local => /etc?) Finally some issues are just plain weird and are causing others. Need to add a network user to plugdev? Fat chance of that happening anytime soon. Apparently that's been resolved as WONTFIX because of API issues involving libc. (Yeah, the cause of that issue is apparently the one standard th

I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).

I think you are confused.

Here is the service unit file for systemd-timesyncd From this it should be quite apparent that:
1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions.
2)The service doesn't run as root, but as a dedicated user.
3)There is a separate, dedicated service, that can be stopped and started without touching the pid 1.

The same goes for the DNS resolution service/daemon.

I am not aware of any NFS-related service that is built into systemd.

I think you've been reading too much anti-systemd FUD, and believing it.

I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).

I think you are confused.

Here is the service unit file for systemd-timesyncd From this it should be quite apparent that:
1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions.
2)The service doesn't run as root, but as a dedicated user.
3)There is a separate, dedicated service, that can be stopped and started without touching the pid 1.

The same goes for the DNS resolution service/daemon.

I am not aware of any NFS-related service that is built into systemd.

I think you've been reading too much anti-systemd FUD, and believing it.

You will often hear the Windows guru say "have you tried shutting it off and turning it back on?" Yes, sounds like a joke but it happens. But you don't hear that from the Linux guru.

You're right, the Linux guru knows that systemd might keep the server from booting for some fuckall reason if he power cycles it, and it's on with the shoes and coat at 3am as you're off to the data center.

If you experience SERVER problems due to systemd, you can look at the documentation on their website at https://www.freedesktop.org/wi...

freedesktop... every time it makes me chuckle

This is completely false:
https://www.freedesktop.org/so...

Why do you lie?

https://www.freedesktop.org/wi...

The output is paged through less by default, and long lines are "truncated" to screen width. The hidden part can be viewed by using the left-arrow and right-arrow keys.. You could also use 'alias' to change the default behavior, or use other methods. As usual when people hate on systemd, you are complaining about systemd because you don't understand it and couldn't be bothered to learn what you could have learned with 2 minutes of googling. It literally would have taken less time to learn about it than complain about it.

Actually, it uses interval; as for your continued unfortunate misunderstanding, QED, I guess.

This following is a reconstruction of what actually took place:

Poettering: Dbus should move to SystemD.

Dbus developers: How do we get Dbus working under SystemD?

Poettering: That's low level stuff, we don't have the skills, besides that's not my problem.
--

See also what SystemD does to /etc/hostname. There are now three different hostnames: static, pretty and transient. ref Again it's a curious decision and understanding the logic behind it fails me.

"I believe it is that they have by now gotten away with so many bad decisions"

Such as embedding the Google DNS addresses into the make file of the SystemD compile script - yea really. Have these people any idea of the security implications of embedding a fixed IP address into the DNS resolver. For instance disabling the local DNS server, blocking 8.8.8.8 and firing up your own box at 8.8.8.8. What F*****G genius thought of this particular hack. "This setting is hence only used if no other DNS server information is known" ref. If no DNS information is known then that should really mean that no DNS information is known.

https://lists.freedesktop.org/...
Specifically:
> Unless the systemd-haters prepare another kdbus userspace until
> then this will effectively also mean that we will not support
> non-systemd systems with udev anymore starting at that point.
> Gentoo folks, this is your wakeup call.
>
> Lennart

Now another thing in there. Just because I prefer not to run systemd, I have been characterized as a "hater". Other than the fact that I'm also not into Taylor Swift, I'm not that much into the whole "hater" thing, but I recognize that I'm being categorized and insulted.

I actually tried being an early adopter of systemd, years before its widespread adoption, and found that it didn't work for me. By the time it started getting widespread adoption, the THERE CAN BE ONLY ONE! attitude really annoyed me. If it were just the attitude I could probably get over it, but I also have technical and software-philosophical objections. But none of that appears to matter in discourse, because it all comes down to haters and steamrollers, instead of real discussion.

See for example systemd.exec(5) for a list of directives that can be used in service and some other unit files.

With some simple directives in unit files (which are simple INI style data files, not scripts) you can access some powerful features, for example ReadOnlyPaths, PrivateNetwork, PrivateUsers, ProtectHome.

systemd also brings instantiated services, socket activation, a simple cgroups interface. Want to limit CPU for a running service, or for everything currently running for a user without restarting any processes? "systemctl set-property" can be used for both because of the way cgroups are abstracted. There's even a simple native container system that's integrated with systemctl and journalctl so you can use -M $CONTAINER to control or view logs for that container, or "-m" to see all logs for host and container.

It's not just that systemd can do these things, but that it does them in a way that is easy to understand. Unit files are clear and easy to read compared to what you'd need to do in an init script to accomplish things that systemd can do with simple directives.

journald/journalctl is also a pretty radical improvement once you start to use it, and on Debian journald is used to supplement syslog not replace it, so the text log files are still there.

If you haven't experienced any of these improvements, go check them out! Seriously give systemd another try if you haven't used it recently. It's not perfect, but it's a powerful tool and in retrospect will probably be recognized as the most important improvement since dependency resolution in package managers IMHO at least.

See for example systemd.exec(5) for a list of directives that can be used in service and some other unit files.

With some simple directives in unit files (which are simple INI style data files, not scripts) you can access some powerful features, for example ReadOnlyPaths, PrivateNetwork, PrivateUsers, ProtectHome.

systemd also brings instantiated services, socket activation, a simple cgroups interface. Want to limit CPU for a running service, or for everything currently running for a user without restarting any processes? "systemctl set-property" can be used for both because of the way cgroups are abstracted. There's even a simple native container system that's integrated with systemctl and journalctl so you can use -M $CONTAINER to control or view logs for that container, or "-m" to see all logs for host and container.

It's not just that systemd can do these things, but that it does them in a way that is easy to understand. Unit files are clear and easy to read compared to what you'd need to do in an init script to accomplish things that systemd can do with simple directives.

journald/journalctl is also a pretty radical improvement once you start to use it, and on Debian journald is used to supplement syslog not replace it, so the text log files are still there.

If you haven't experienced any of these improvements, go check them out! Seriously give systemd another try if you haven't used it recently. It's not perfect, but it's a powerful tool and in retrospect will probably be recognized as the most important improvement since dependency resolution in package managers IMHO at least.

Systemd's issues are only getting worse with time.

The scales on this chart for the secondary vertical axis makes it unreadable.

don't blame me, blame the people who made it.

With slices and scopes systemd directly interfaces with the cgroup mechanism in the kernel. The advantage is that with this mechanism you can fence off part of your session, or even a single process into its own environment, anything up to short of running it in a container (and then systemd can also manage containers). Resource usage can be limited on both the scope and the slice, and can be set for CPU, memory and I/O. The official documentation will provide more details.

We saw a part of that in the debate on the setting that kills all apps on session end. While I disagree with making that the default (at least for now), the idea that if you want something to keep running in the background you have to explicitly assign it to a background scope, so both the system and the sysadmin can see it's a background task and keep it constrained if necessary, is a good mechanism in my eyes.

I need that kind of fine-grained control in my work, and there are simply no alternatives that handle this as easily as systemd.

This, and event-based service handling is worth it for me. systemd feels a little overengineered to me, but since I haven't even seen half of what it cant do I am quite willing to entertain the thought that this is a mistaken impression on my side. Or it might be that it actually is overengineered.

It has faults; the event-based nature means that dependency cycles are hard to debug and can be frustrating; a number of units have timeouts that are far too long and make your system hang for ages if something goes wrong, and interrupting them is hard if not impossible. But I've dealt with SysV breakage too, professionally, and systemd's warts are certainly not worse.

So, it's not actually worse than SysV, and it brings some stuff to the table I like and need in daily work. And most of the objections are people blindly parroting echo chamber talk, and that is what pisses me off to no end: people pretending to be intelligent not being any better than Alex the Parrot.

Uhhh... Being dead probably means you're not a developer - but, sure, not writing code for a project does reflect on the source.

For an example of attitude reflecting the source, using the same kernel command line variable to debug your application that the kernel uses to switch on debug and closing as "not a bug" will result in different code than changing the code. This can reflect the attitude of the maintainers.

I've noticed the guys working for me just can't grasp the concept of this: systemctl start openvpn@server.service

That is an example of instantiated services which are a pretty handy feature.systemd.unit(5) documents this feature. If your 'guys' aren't into reading manuals for the tools they use, it's not that hard to figure out what's going on just reading the openvpn@.service file.

We use four different Linux distributions and six other UNIXes, so that small inconsistency turns into a big thing.

systemd is becoming standard, so there will be *fewer* inconsistencies between distros. One of the biggest drivers behind all the systemd hate seems to be resistance to learning new things, which is a shame because systemd is actually pretty cool.

You run an X server as a Wayland client: https://wayland.freedesktop.or...

That's fine until people start writing apps directly to Wayland, rather than as X clients. Or, rather, until toolkit support for X begins to bit rot due to lack of attention, and eventually gets removed. Hopefully enough *nix OSes will continue using X to keep that from happening, but...

This problem was resolved 3 years ago, run Xwayland, an X server for Wayland.

You assume that because the Wayland protocol isn't concerned with networl transparency that Wayland developers don't understand your use case. They do, they just don't think the network interfaces belong in the same binary as access to the display drivers.

You run an X server as a Wayland client:
https://wayland.freedesktop.or...

There's no hand-waving. Wayland isn't meant to replace every X11 feature, and the devs explicitly say the reason Wayland doesn't have network transparency is because it's beyond its scope and Wayland can support it over an X11 session on top of Wayland -- or through any current VNC/RDP protocol... or even a new one that bypasses X11 entirely and accesses Wayland at a lower level than an X11 session would (which might be superior to an X session since it would allow less overhead and more optimizations). X isn't going away just because Wayland appears. It's going to take a long time to switch everything over to Wayland, and in the process, we may find some things just stay on X11 or migrate to a newer protocol that runs on top of Wayland.

https://wayland.freedesktop.or...

X's main flaws are serious design flaws -- like the horrendous security issue of not sandboxing data in open windows, and the more severe issue of screen tearing that's holding Linux back from serious gaming, VR, and 3D displays.

Wayland is coming -- and it's designed by X.org members who want it to replace X wherever possible. I trust since they've been the maintainers of X for ages that they know its limitations and created Wayland to resolve those issues.

You're arguing for ancient spaghetti code that's been hacked on for decades and given plugins for everything under the sun... so much cruft that's ridiculously outdated. They're not re-inventing the wheel... they're replacing the old wooden wagon wheel with vulcanized rubber tires on steel rims.

The man pages for systemd are excellent. No fooling. Tell me what you want to do with the systemctl command to manage and query services that you can't figure out from https://www.freedesktop.org/so...

you could start here https://www.freedesktop.org/wi...

Are you kidding? https://www.freedesktop.org/wi... is excellent. Man pages, FAQs, tips and tricks, debugging errors, Howtos for converting a SysV Init service to systemd, etc... The man pages are huge and highly detailed. If you mis-type a command, the error message is usually helpful.

You can hate the project and find technical fault with design decisions. That's fine. But don't tell me the documentation is bad. I think one of the reasons it conquered the Linux landscape is specifically the documentation.

It's LennartCode. As long as it works on his machine and at least 90% of machines out there, it's going to be adopted. Kind of like systemd. I'm only a hater because there's a severe problem on my laptop which I can't debug and no one has been able to offer any advice on.

Now I'm not one to easily take offence (despite what many here seem to think), but THIS is offensive:

https://www.freedesktop.org/wi...

Quoth the page:

"As PulseAudio forms part of what is typically preferred to as the plumbing layer of Linux userspace, it is a non-trivial job to integrate it fully to form a complete system. This is why we strongly encourage you to go via your distribution whenever possible."

When did hell did Linux become a "fuck you don't touch the innards" system?

You can definitely embed Windows Metafile images in LibreOffice on Windows; but I'm not entirely sure if that is enough to make it vulnerable. WMF is dangerous because it is basically a package of GDI function calls, which might be good for efficiency or compactness; but has led to a number of creative and executable things being shoehorned in(as in this case; and repeatedly over the years).

However, there are several image handling libraries that can render or convert WMF images without access to GDI; so in those cases GDI bugs wouldn't be a problem(though you probably have other things to worry about).

This Libreoffice VCL documentation suggests that LibreOffice uses its own VCL WMF filters; but I sure wouldn't bet anything remotely important on that without testing it first; or knowing rather more about how LibreOffice is put together.

What were they thinking? I guess the product is better than the name if it's gaining traction, but for the love of God, fix the name. There's one thing in computing that's Pascal, and these chips are not it.

Here at Nvidia we unfortunately suffer from marketing sometimes being lazy and by default naming some products the same as our internal project code names to avoid being confusing.

FWIW, Blaise Pascal's first published written work was called, Essay on Conic Sections. The writings constituted an important advance in projective geometry, (representing a 3-D object onto a 2-D field). Perhaps a reasonable internal codename for a 3d graphics chip project? Arguable. A name collision? Unfortunate. Are concept name collisions uncommon with prolific scientists? No. For example Galios, Gauss, Euler, etc

It's not like computing doesn't do stuff like that all the time. Witness JavaScript and C-shell... JavaScript is definitely not Java and C-shell is definitely not C.

In own words of AMD driver developer:

"We don't happen to have the resources to pay someone else to do that for us."

https://lists.freedesktop.org/...

AMD does hardware, but they dont support it with software.

Writing drivers needs two things: specs

The nouveau project demonstrates that isn't the case. Your claim is flatly false. What you want learn about is reverse engineering. That's how to get it done in the real world.

Time is easier said than done

Only if you waste it having a whinge on Slashdot instead of doing your driver development work. Harden up, son.

That's sort of already been done. You might not want to read about it right before bedtime, though. Bad dreams, man. -PCP

Who would download anything from softpedia, esp open source? Why not get from mesa3d.org?
ftp://ftp.freedesktop.org/pub/...