Questions about Arch Linux

[MrCrispy]

Some of this stuff is over my head, no idea what DKMS is but I remember seeing that term before.

"I just booted into run mod 3" this is the kind of stuff that scares me. Its easy for you as an experienced user to say "Its not a major issue" but I never had to do anything like this in Windows.

I hear you on Gnome it certainly is a fresh take on things. I don't really mind it and I do like their 'overview' with running apps and desktops. I remember when Windows removed hierarchical start menu with a new style which favored search, everyone was up in arms about it. But then Unity and Gnome did the very same thing. I use search in my KDE too it works both in the menus and also on desktop.

I might even try out Gnome for a week again. But will have to be in a vm. I know theoretically they say you can add multiple DEs on Linux and switch between them but I have no idea how to do that and don't want to screw up my system.

 

[ChadD]

Some of this stuff is over my head, no idea what DKMS is but I remember seeing that term before.

"I just booted into run mod 3" this is the kind of stuff that scares me. Its easy for you as an experienced user to say "Its not a major issue" but I never had to do anything like this in Windows.

I hear you on Gnome it certainly is a fresh take on things. I don't really mind it and I do like their 'overview' with running apps and desktops. I remember when Windows removed hierarchical start menu with a new style which favored search, everyone was up in arms about it. But then Unity and Gnome did the very same thing. I use search in my KDE too it works both in the menus and also on desktop.

I might even try out Gnome for a week again. But will have to be in a vm. I know theoretically they say you can add multiple DEs on Linux and switch between them but I have no idea how to do that and don't want to screw up my system.

Dynamic kernel management system, its a system to manage kernel modules. The NV driver adds itself to the kernel. Most distros make NV drivers an easy install these days DKMS is one system to make that fairly painless.

Having said that I'm not sure what the current state of Tumbleweed is with Nvidia drivers or DKMS. My month with tumbleweed was pretty close to a year ago now, that situation may well have improved.

Runlevel is a unix thing... it allows you to boot without networking, boot to command line, command line with networking ect. If your from the windows world its almost like a safe mode. Run mode 3 is basically a normal boot that skips the display manager start... so you end up with a command prompt but networking ect all work fine. I believe technically systemd doesn't have runlevels but it translates the numbe requests into the right mode. Adding a 3 to your boot parameters and SystemD boots into its version of mode 3 (if you hit e in grub on your Linux boot option... where it says linux /boot/vmlinuz ect basically just look for where it says quite or splash those are your boot parameters... so if you hit e to edit, and add a 3, then press F10 to boot your changes you will end up on a command line only boot). You may well never need a command line boot but its helpful... in the case of Tumbleweed I would have to do command line to rebuild the NV driver to the kernel every time Tumbleweed updated the kernel. Outside that sort of stuff run mode 3 can be useful in fixing issues as you could imagine.

On Gnome hey it may grow on you it may not. Great thing about Linux use what you like.

In general you shouldn't really run into any issues installing mulitple DEs... most Login managers have a drop down or something to select which installed DE you want to fire up when you log in.
Antergos default installs LightDM for instance which handles all the major DEs with no issues. You can easily switch your login manager as well. Do some reading on it... but of course loading things in a VM isn't a bad way to go when messing around as well.
https://wiki.archlinux.org/index.php/LightDM

 

[Mazzspeed]

This discussion is wonderful, for the first time I don't feel on edge waiting to be attacked!

 

[naib]

And yes I've read some of those exchanges and people like Lennart, Kay Sievers come off as arrogant, but is Linus any better? pulseaudio and systemd solved hard technical problems that no one wanted to tackle. Regardless, things just dont get accepted into Linux because of one person, thats the beauty of open source. systemd has been accepted because of technical reasons, and is why everyone has switched to it, except for those refusing to do it just because. Every Linux server in the world runs systemd. That means a consistent interface thats predictable and powerful.

Here's a good post from a developer on why systemd is better than old init scripts -
Honestly all the people who think systemd should be replaced - do it! There's no shortage of smart people working on Linux. If someone comes up with a better solution it will be adopted.

because one person is an arrogant SOB isn't justification for someone else to be. The one key difference here is linus has proved himself and he only blows his top at those who should know better. The same cannot be said for pottering.
replacing init scripts was one of the initial selling points because a lot of distributions were using sysvRC and boy were redhat bad at writing sh/bash... so because they are unable to write sh/bash and other distro's made use of the init system init scripts are bad? no ... bad code is bad no matter what it is written in. Equally look into systemd unitfiles.. those nice [ini] files. For simple things that is more than enough to spawn a daemon but what you will find is it then spawns a bash script to initialize the daemon. So really it hasn't gotten rid of the issue.
Look at OpenRC they wrote in C what needed to be in C and left the RC in sh (it is sh to be POSIX compliant). Some init scripts are very simple as they list the service dependency and then the start-stop command. Some are more complex as it has to initialize some form of framework.

in one of those gentoo threads I ranted that OpenRC missed the boat in providing a framework for init scripts because distro's do not want to maintain such scripts and upstream developers want a consistent API. SystemD provided this ... sort of BUT the freedesktop foundation should have pushed such API as implementation agnostic such anything could have made use of the concept rather than being systemd specific and soo interlinked.

here is the content of /etc/init.d/rsyncd

#!/sbin/openrc-run
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"

depend() {
    use net

see how simple. Declare a few variables and then overload any function that you want to compliment.

even redmine isn't that complex..

!/sbin/openrc-run
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

RAILS_ENV=${RAILS_ENV:-production}
REDMINE_DIR=${REDMINE_DIR:-/var/lib/redmine}
REDMINE_ADDRESS=${REDMINE_ADDRESS:-localhost}
REDMINE_PORT=${REDMINE_PORT:-3000}
REDMINE_USER=${REDMINE_USER:-redmine}
REDMINE_GROUP=${REDMINE_GROUP:-redmine}
REDMINE_PIDFILE="/var/run/redmine/server.pid"

depend() {
    use git-daemon mysql net postgresql svnserve
}

start_pre() {
    if [ ! -e "${REDMINE_DIR}/config/initializers/secret_token.rb" ] ; then
        eerror "Execute the following command to initialize environment:"
        eerror
        eerror "# emerge --config www-apps/redmine"
        eerror
        return 1
    fi
    checkpath -q -d -m 0755 -o redmine:redmine /var/run/redmine
}

start() {
    ebegin "Starting redmine"
    start-stop-daemon --start --quiet \
        --user "${REDMINE_USER}:${REDMINE_GROUP}" \
        --pidfile "${REDMINE_PIDFILE}" \
        --exec /usr/bin/ruby "${REDMINE_DIR}"/bin/rails server -- \
        --daemon --environment="${RAILS_ENV}" \
        --binding="${REDMINE_ADDRESS}" --port="${REDMINE_PORT}" \
        --pid="${REDMINE_PIDFILE}" \
        ${REDMINE_OPTS}
    eend $?
}

stop() {
    ebegin "Stopping redmine"
    start-stop-daemon --signal INT --quiet --pidfile "${REDMINE_PIDFILE}"
    eend $?
}

There are a few "complex" init in openRC but they are more for openRC then for an upstream daemon



That said the openrc init files are very simple

 

[MrCrispy]

AFAIK there was no way using init scripts to schedule services based on dependencies, e.g. A depends on B, C depends on D, and use that info to decide start order etc. Also cgroups were not used which provide a hard kernel isolation of resources and guarantees and bad processes can be killed. Both of these seem like really important features to me. An even driven system is good in my eyes.

I've read a few of the bug reports and I agree some of the systemd devs are really arrogant jerks. But I have yet to see a technical argument why systemd is bad. Did you read Poetterings blog 'greatest myths' which I linked earlier?

 

[naib]

AFAIK there was no way using init scripts to schedule services based on dependencies, e.g. A depends on B, C depends on D, and use that info to decide start order etc. Also cgroups were not used which provide a hard kernel isolation of resources and guarantees and bad processes can be killed. Both of these seem like really important features to me. An even driven system is good in my eyes.

I've read a few of the bug reports and I agree some of the systemd devs are really arrogant jerks. But I have yet to see a technical argument why systemd is bad. Did you read Poetterings blog 'greatest myths' which I linked earlier?

The dependency thing is important but systemd was nowhere near the 1st

OpenRC - 2007
Systemd - 2010

OpenRC included startup dependency


CGroups is also important and that didn't appear in linux until 2007
so wind back to the original sysvrc scripts... they could never had made use of cgroups because the technology never existed. Likewise redhat were beyond poor at scripting so what they had was poor.


As to pottering blog... yes I had already read that when it was originally posted. His specific points have been refuted time and time again but I will quite happily write them here...

Myth: systemd is monolithic.
From what perspective? yes there were 69 individual binaries that *could* be built because systemd covers alot of things. HOWEVER... what makes systemd monolithic is how large PID1 is... go look at what it does and then re-ask yourself... what does PID1 really, really purely need todo. if that goes outside of 1)starting rc, 2) sweeping zombies THEN PID1 is too large. Ergo systemD is monolithic.
This "falsehood" claim is more moving the goalposts because it is a typical playing in an ontology that they have redefined.


Myth: systemd is about speed.
It was... go back and look at all the conferences, all the talks. It was all about ramming down the throats that systemd is about speed. Sure its moved on from there as systemd then showed it wasn't just an init replacement. The actual speed was then being shown... its a bit dishonest to then sweep aside one of the key selling points shouted out about...

Myth: systemd's fast boot-up is irrelevant for servers.
The majority of boot-up time of servers is actually the fsck because booting is so few and far between ... why do admin's care if systemd boots in 20seconds, OpenRC in 10seconds, sysvrc in 1min WHEN 5-10min is lost just FSCKing root...
WHAT they do care about is not being forced to reboot and with PID1 covering soo much they have to reboot if there is a change. So not instead of just rebooting due to a kernel update it is now kernel and/or systemd

Myth: systemd is incompatible with shell scripts.
Not actually ever stated as the unitfiles just launch whatever command is listed in ExecStart= or the other directives.

Myth: systemd is difficult.
Never seen that

Myth: systemd is not modular.
Completely disingenuous and again showing signs of a local ontology that is different from the general consensus.
*IF* systemd was modular I could build logind as a standalone binary just just use that WRONG
*IF* systemd was modular I could build journald as a standalone binary just to use that WRONG

Pottering is choosing to define modular as being able to disable components (note: at compile time... so its distro-specific). but modularity goes both ways.

Myth: systemd is only for desktops.
sort of a redundant statement when the server one is stated... its an init and service manager... desktop,servers, phones need this. I just choose not with systemd

Myth: systemd was created as result of the NIH syndrome.
I don't recall it ever being said it was originally created due to NIH... a more modern init system was needed to replace sysvrc and if they decided not to use openRC or upstart well... its a new build. I stated earlier there is a NIH syndrome because it was quicker and easier to state then describe what I really think is going on and that is pottering/SystemD coders just do not understand UNIX Those who do not understand UNIX are condemned to reinvent it -- badly. so they keep expanding what systemD does and they face an issue... rather than stopping and going "mmm other aspects of linux are fine" they go "oh the rest are wrong, we will rewrite locally" and absorb in as they are unable to play with other projects.

a common, massive libsystemd provides a nice rich environment to exploit a system. A simple DNS query pwned a system YET a system built from individual components does not result in a pwned system as it is isolated... it is clear the systemd projects cannot write software for a unix-like environment to co-exist with other project to create something exceeding the sum of their parts

Myth: systemd is a freedesktop.org project.
so what if it isn't, so what if it is.

Myth: systemd is not UNIX.
Well it isn't, its locking onto linux-only tech and have outright stated they would not target bsd. but why is this a myth? lots of things are only linux and nothing todo with UNIX. rememeber linux isn't POSIX compliant

Myth: systemd is bloated.
again disingenuous "lets debate what bloat means"
Here is a nice thread on the topic... https://forums.gentoo.org/viewtopic-t-1064510-highlight-openrcinit.html

sizedep() { stat --format=%s $1 $(ldd $1 | cut -d' ' -f3 | tr '\n' ' ') | awk '{s+=$1} END {print s}'; }



$ sizedep /sbin/openrc-init
65940
$ sizedep /sbin/runit
18668

$ sizedep /sbin/init  # This is sysvinit init, the default on gentoo unless you choose openrc-init
44588

#--- switch to Ubuntu VM
$ sizedep /sbin/init
2306855

$readlink /sbin/init
/lib/systemd/systemd

THAT IS BLOAT!. Why is PID1 soo massive! it just doesn't need to be over 120x larger than runit and 34x larger than openrc-init. This is bloat, no handwaving "what is bloat" that behemoth is massive! and this just just talking about PID1 ...

Myth: systemd being Linux-only is not nice to the BSDs.
why is this even here. you write code if it is cross-platform great... so what if it doesn't work on bsd.

Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.
Again so what.. and equally it doesn't they can have per-arch defaults,....

Myth: systemd could be ported to other kernels if its maintainers just wanted to.
so what.. a framework to build upon was chosen so be it.

Myth: systemd is not portable for no reason.
so what.. a framework to build upon was chosen so be it.

Myth: systemd uses binary configuration files.
no idea where that came from. binary logs however...

Myth: systemd is a feature creep.
not a myth if it actually happens now.

Myth: systemd forces you to do something.
I cannot just use logind. I might not be able to use udev in future (referring to the explicit threat from pottering). I can't be arsed to find it, but it was the kick for gentoo dev's to ensure there is an escape plan and they have the framework of one. NOw why would such a plan be needed if there isn't some hostility, some level of forcing their view/agenda?

Myth: systemd makes it impossible to run syslog.
again disingenuous... why it does permit you to use your chose of logger... it does not play nice. again read the gentoo threads, its all in there.


Well I am bored now... go read the gentoo thread's. Pottering is toxic and incompetent and the smoke & mirrors he and systemd dev's played didn't fool all distro's. It says something when an NSA coder had to jump in and pull apart KDBUS, something that pottering/systemd stated absolutely had to be included



I personally do not care what you use as that is your choice... I am a gentoo user, its all about choice... I use openbox ONLY because that's all I want from my desktop. but when such overhandedness start impacting my choice (re. udev and the threats) then i will start looking over everything. When decisions start impacting other gentoo users choice (ie gnome without systemd) then I have a serious issue with the philosophical existence of such a project and I will quite happily use my spare time to bring to people attention the incompetence of those that influence the project

 

[MrCrispy]

Thanks for your detailed post naib, I will try to understand. As an end user and not an expert I'm not in a position to try Gentoo, maybe some day. I will just say that many of the criticisms applied to systemd can probably be applied to the Liniux kernel itself, and from what I've read Linus is ok with systemd's design but not the attitude of its devs. In any case it looks like its here to stay for the forseeable future.

I am more interested in seeing how Linux (and other OS's) evolve and what new technologies are in the future. Computing keeps getting more and more complex instead of simpler.