I Switched (Back) Over To Fedora As My Main OS & It's Going Great!

[Hugh]

There are dozens of such articles. Lennart Poettering is the lead developer for systemd, and his own blog is a good starting point: http://0pointer.net/blog/archives.html

a few years ago I spent more time than I wanted reading his blog posts. They got obsoleted. I want an overview but not a trivial one.

I think his initial post on systemd, "Rethinking PID 1" is excellent for explaining why he started the project and how systemd works. http://0pointer.net/blog/projects/systemd.html

I don't need to be sold on the need. That's been clear to me for a few decades.

One objection to systemd that his "The Biggest Myths" don't address is the idea that the Unix philosophy emphasizes small, self-contained components that interact with each other and not large, complex systems.

Well I think that it is a legitimate criticism of much that came after Seventh Edition UNIX. Maybe of Seventh Edition itself. BSD and USG were major sinners.

(Almost any other objection you can imagine is listed in that post, I'm just throwing in this objection and my counter argument myself.) While that is true in general, there are exceptions to that guiding principle that are in wide use in Linux, BSD Unix, OS X, Solaris, and elsewhere:
1. The Linux kernel is a giant monolithic structure instead of a collection of interoperating parts like GNU HURD. This is a direct violation of the Unix philosophy.

The Lyons book's Sixth Edition kernel is just under 10,000 lines.[quote]

But really, my fear is that systemd is too complex and not modular enough. I don't know. I want a nice map to learn about it. I think we deserve a Royal Road to understanding it so that we don't just have to accept the opinion of koolaid drinkers.

Ideal free software projects are inviting to contributors. Part of that is ensuring that there are reasonable on-ramps.

Modularity comes in many flavours. But the bits need well defined stable interfaces or it doesn't count.

One complaint about the Linux kernel is the lack of stable interfaces internally. I don't care about ABIs, but about APIs.

\I have mixed feelings about systemd and I'd like to resolve them. Our local LUG has requested a talk about systemd but nobody feels qualified. That's not healthy.

[Luke_Wolf]

There are dozens of such articles. Lennart Poettering is the lead developer for systemd, and his own blog is a good starting point: http://0pointer.net/blog/archives.html

I think his initial post on systemd, "Rethinking PID 1" is excellent for explaining why he started the project and how systemd works. http://0pointer.net/blog/projects/systemd.html

His post "The Biggest Myths" addresses most of the common criticisms of systemd. http://0pointer.net/blog/projects/th...est-myths.html

One objection to systemd that his "The Biggest Myths" don't address is the idea that the Unix philosophy emphasizes small, self-contained components that interact with each other and not large, complex systems. (Almost any other objection you can imagine is listed in that post, I'm just throwing in this objection and my counter argument myself.) While that is true in general, there are exceptions to that guiding principle that are in wide use in Linux, BSD Unix, OS X, Solaris, and elsewhere:
1. The Linux kernel is a giant monolithic structure instead of a collection of interoperating parts like GNU HURD. This is a direct violation of the Unix philosophy.
2. Earlier filesystems for Unix and Linux did not have journaling. This has since been added, even though it's something that could be done separately from the filesystem layer itself, because it just made sense to link a filesystem with its journal.
3. Early file revision control systems like RCS dealt with one file at a time in one location. Then CVS was created, adding complexity - more components in one place - but it supported multiple files as part of one project. The current world standard for revision control, git, has digital signature verification of changes and works with distributed copies of files. No one is seriously suggesting that the Unix philosophy alternative to git is shell scripts that use RCS + rsync + ssh + sha256sum.
4. Early data storage and retrieval systems used flat files. A relational database is tremendously more complicated for the sake of providing the famous 'ACID' features - Atomicity, Concurrency, Isolation, and Durability. Newer distributed data storage solutions have been created that lose one or more of the ACID features in return for the ability to do things like have distributed upgrades, live adding and removal of nodes, improved speed, etc... Again, you don't see anyone seriously suggesting that all of these systems be discarded in favor of flat files because a system architected on flat files is more true to the Unix philosophy.

Well the biggest problem is that the people who go on and on about the "UNIX philosophy" are non-programmers, and so they don't understand how the concepts have evolved and been updated, and thus how they are applied in modern software development, and are not up to date with the terminology used by modern developers and how they map.

Instead of at the program level, the Single Responsibility Principle ("Do one thing and do it well") is applied at the Class and Member level, and instead of a series of reusable programs we use a series of reusable classes and so on, and choosing structured text over binary data unless you have a reason not to is still really a best practice. etc, etc, etc... One only need to have it and an OOAD book side by side to see this.

[blackiwid]

Well the biggest problem is that the people who go on and on about the "UNIX philosophy" are non-programmers, and so they don't understand how the concepts have evolved and been updated, and thus how they are applied in modern software development, and are not up to date with the terminology used by modern developers and how they map.

Instead of at the program level, the Single Responsibility Principle ("Do one thing and do it well") is applied at the Class and Member level, and instead of a series of reusable programs we use a series of reusable classes and so on, and choosing structured text over binary data unless you have a reason not to is still really a best practice. etc, etc, etc... One only need to have it and an OOAD book side by side to see this.

I was first just open/not caring about systemd much and now am a fan of it because I used it for about a year. But saying that only OO Development is modern development I disagree deeply. At least it sounds like that, I did not even know that systemd is written in C++ or did they use C made OO or something else?

If that were true, the biggest most successful projekt the linux kernel would not be possible in C. Maybe I have to bad feelings about OO, even I developed much OO programs. I have at least something against the extremistic viewpoint of this. I hear people that find a language bad because it uses no static typing (at least by default). I see it different, if you want something really fast, you use C or assambler, if you want to be able to code something really fast so machine speed is not so limited like development time you use a scripting language without static typing.

And then there is functional languages or styles, I am a bit new to this, but so far I really like it.

Maybe my usecases differ from kernels and pid 0 problems but to see OO as the solution of all/most problems I do not agree. Especialy for OS stuff that need to be fast I think most of the time pure C should be better.

[Michael_S]

a few years ago I spent more time than I wanted reading his blog posts. They got obsoleted. I want an overview but not a trivial one.

Most of what they contain isn't obsolete. systemd is still pid one. It still uses parallel launching. It still uses files and sockets for communication. You can still change which components are included by using compile-time flags. The convention is still to write services in C and govern them with a standard format configuration file, with the same format shared across all services. You can still write services in other languages, including shell scripts, and launch, stop, monitor, and restart all with that.

The documentation at http://www.freedesktop.org/wiki/Software/systemd/ is extremely thorough, what is missing?

I don't understand what you're asking for, otherwise.

Ideal free software projects are inviting to contributors. Part of that is ensuring that there are reasonable on-ramps.

Modularity comes in many flavours. But the bits need well defined stable interfaces or it doesn't count.

http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

While I agree with you in principle, in practice if we demanded stable interfaces from open source software there's an awful lot of projects that fail - including, as you yourself mentioned, the Linux kernel itself.

Proprietary software projects tend to be better about maintaining interface compatibility. They're not universally better, but in my somewhat educated opinion they're often better. They're better because it boosts sales and subscriptions for the vendor when the customer has to do less work when they upgrade to a new version. Open source software projects don't get that benefit. Maintaining interface compatibility might make it easier for people making third party plugins and maintaining forks of the software, but it doesn't directly put more money into the developers' pockets.

I have mixed feelings about systemd and I'd like to resolve them. Our local LUG has requested a talk about systemd but nobody feels qualified. That's not healthy.

Fair point - but then I honestly while I don't feel qualified to talk about systemd, I know even less about kernel, GCC, or LLVM internals and I use those all of the time.

[Guest]

Been DE and distro hopping for the past few days. Was hopping between XFCE, LXDE, KDE 4, and 5. Ended up eventually ditching Ubuntu and went for openSUSE Tumbleweed. Plasma 5 wasn't as-polished as I would have preferred, and 4 had some weird lock-up issue I couldn't figure out. XFCE worked fine, but I can't stand how it looks out-the-box on openSUSE (spoiled by Xubuntu a bit ), so I eventually gave GNOME a try. Not sure why I didn't try it sooner!

Still had some weird instability issue on Tumbleweed, so I just went over to Fedora 21. Had to learn how to do some stuff, but so far everything is working correctly, and everything I want to do is working fine. Looks like this could be the DE/distro that works for me

One really weird thing though is how GNOME (I assume it's GNOME since no other DE does it, and it happens on both openSUSE and Fedora regardless of graphics stack/kernel) mis-arranges my triple-monitor setup out-the-box. My monitors are arranged with how the ports are laid-out on my GPU, and Windows, and all the other DEs and distros I've tried respect it. GNOME however wants to place my first monitor on the far-right though (so it's [2] [3] [1]). Can't seem to find any reports of this happening elsewhere, and have no idea why it happens to begin with.

I can use the display app to re-arrange it properly without issue, and it sticks after reboots, so it's not a huge issue at all or even noticeable as an issue after that. But it's still strange.

[blackiwid]

One really weird thing though is how GNOME (I assume it's GNOME since no other DE does it, and it happens on both openSUSE and Fedora regardless of graphics stack/kernel) mis-arranges my triple-monitor setup out-the-box. My monitors are arranged with how the ports are laid-out on my GPU, and Windows, and all the other DEs and distros I've tried respect it. GNOME however wants to place my first monitor on the far-right though (so it's [2] [3] [1]). Can't seem to find any reports of this happening elsewhere, and have no idea why it happens to begin with.

I can use the display app to re-arrange it properly without issue, and it sticks after reboots, so it's not a huge issue at all or even noticeable as an issue after that. But it's still strange.

How should a fresh installed linux installation know how you phisicly place your monitors? maybe it could assume that displayport 1 is left from displayport 2 but thats just a wild guess and if you mix hdmi and displayport its completly over...

But kernel 3.18 gets new dockingstation and randr abilities, so next gnome/fedora version maybe makes here something better. or at least for non-gnome users its easier to script it. What real bugs are that at least on intel gpus randr zooming or what you calll it does not work gread would find it cool to have everything scaled 20% if you sit on a monitor instead of a laptop as example. depending on the distance, not automaticly but manualy setup...

[Guest]

How should a fresh installed linux installation know how you phisicly place your monitors? maybe it could assume that displayport 1 is left from displayport 2 but thats just a wild guess and if you mix hdmi and displayport its completly over...

I assume the GPU presents it's ports in some kind of order (in the case of my GPU, it's DisplayPort-0, DIsplayPort-1, HDMI-0, DVI-0), and both Windows and most Linux DEs respect that order (so if I have 3 monitors as [1] [2] [3] with the ports being 1 = DP-1, 2 = HDMI 3 = DVI, the order by-default will go with that, and have DP on the far-left, HDMI in the middle, and DVI on the far-right).

GNOME is the only DE (out of the ones I tried anyway; and I've tried KDE 4, 5, XFCE, LXDE, and Unity) that doesn't follow this rule, and it places my DVI monitor on the far-left, DP in the middle, and HDMI on the far-right.

All my monitors are the same (and afaik give the same EDID information), so I'm not entirely sure what causes this arrangement. This is also with the open-source graphics drivers.

[blackiwid]

I assume the GPU presents it's ports in some kind of order (in the case of my GPU, it's DisplayPort-0, DIsplayPort-1, HDMI-0, DVI-0), and both Windows and most Linux DEs respect that order (so if I have 3 monitors as [1] [2] [3] with the ports being 1 = DP-1, 2 = HDMI 3 = DVI, the order by-default will go with that, and have DP on the far-left, HDMI in the middle, and DVI on the far-right).

GNOME is the only DE (out of the ones I tried anyway; and I've tried KDE 4, 5, XFCE, LXDE, and Unity) that doesn't follow this rule, and it places my DVI monitor on the far-left, DP in the middle, and HDMI on the far-right.

All my monitors are the same (and afaik give the same EDID information), so I'm not entirely sure what causes this arrangement. This is also with the open-source graphics drivers.

I doubt that the bios knows in which order your outputs are aranged so either there is some hardwaredatabase linux/the driver has access to, or it was just random luck and guesses that they were right in other instances.

dp1 to dp2 placement you can guess maybe easy the rest is no way for a developer to know how its positioned except a big big hardware database.

[Guest]

I doubt that the bios knows in which order your outputs are aranged so either there is some hardwaredatabase linux/the driver has access to, or it was just random luck and guesses that they were right in other instances.

dp1 to dp2 placement you can guess maybe easy the rest is no way for a developer to know how its positioned except a big big hardware database.

The ordering doesn't seem random, so there has to be some logic as to how displays are arranged. I'm assuming the VBIOS prioritizes/orders ports. xrandr also lists the ports in the correct order they're laid-out on the GPU.

The thing is, Linux nor Windows actually "know" how my monitors are arranged. I simply have them arranged in the order of the ports on the GPU itself, and this works out in all cases, except with GNOME.

If GNOME itself isn't doing it, maybe GDM is? My screens are also not arranged properly on the login screen. LightDM seems fine out-the-box. KDM and XDM mirror the outputs at login. If I assume correctly, Ubuntu GNOME probably uses LightDM, so possibly firing that up should give me some feedback.

[blackiwid]

The ordering doesn't seem random, so there has to be some logic as to how displays are arranged. I'm assuming the VBIOS prioritizes/orders ports. xrandr also lists the ports in the correct order they're laid-out on the GPU.

The thing is, Linux nor Windows actually "know" how my monitors are arranged. I simply have them arranged in the order of the ports on the GPU itself, and this works out in all cases, except with GNOME.

If GNOME itself isn't doing it, maybe GDM is? My screens are also not arranged properly on the login screen. LightDM seems fine out-the-box. KDM and XDM mirror the outputs at login. If I assume correctly, Ubuntu GNOME probably uses LightDM, so possibly firing that up should give me some feedback.

that seems more likely with gdm, my monitors gets somethimes also rearanged after boots or suspends. Even I dont use gnome, I use gdm and use different tailing wms, at the moment stumpwm. And I have somethimes after boots also switched outputs before I call my xrandr script, even I have the left monitor on DP2 and the right on DP3.