Future and impact of ongoing projects in Linux world

[Xen]

Oliver Grawert schreef op 05-10-2016 14:41:
> hi,
> On Mi, 2016-10-05 at 04:05 +0200, Xen wrote:
>> Xen schreef op 05-10-2016 3:32:
>> 
>> >
>> > In short, the discrepancy between what a user can do and what root
>> > can
>> > do, is too big.
>> 
>> The result of this is that most services are installed completely 
>> system-wide and there is nothing less than that.
> 
> how would you deal with ... say 20 users all installing a mongodb
> server on your multi user system that all want to use the same
> privileged network port ?

The point is not that it would be the best solution in all instances but 
that it is not possible in any instance.

To do it differently (install something by a user).

Besides, what you say is incomprehensible: a user-installed package 
cannot use a priviledged network port, that is the whole point.

>> Now you may think containers are a solution to that but if you use
>> e.g. 
>> LXC for that you still have the same programs running equally 
>> system-wide but now they are just doing that inside of a container.
>> 
>> That doesn't change the programs, you know.
> 
> no, but it makes the above possible (by applying a container based sub-
> network like ubuntu-fan does for example)... though note that snaps
> have nothing to do with containers (quite the opposite actually).

Still doesn't answer whether they can be user-specific.

>> In terms of logging: why is there not a daemon that can run for a
>> user 
>> specifically?
> 
> there is ... see ~/.xsession-errors and ~/.cache/upstart/
> (and there will be a systemd one as well, once switched to systemd user
> sessions)

The first file is loaded with random errors but I see some services 
being started.

Of course there are probably "session" services but I have no clue how 
it works and 99% of users that have spent less than 5 years on Linux 
probably don't know how to do it either.


>> Why is there not a user fstab in which the user can specify mounts he
>> or 
>> she wants to use? It is possible for libpam-mount but not for
>> regular 
>> fstab.
> 
> simply because nobody had the balls yet to switch a system completely
> to systemd.mount units i guess, but also because it is a security
> nightmare to allow people to randomly mount/umount system disks (though
> there is fstab-free mounting of USB disks today with udisks2 on every
> standard ubuntu system (or flavour))... 

That's true but we have the "disk" group since long and the typical user 
just wants to mount network shares and USB sticks, as you mention.

In Windows any user (not even just an administrator) can take a network 
share and mount it on a drive letter. Just like that. Takes 5 seconds.

In Linux thus far it has been impossible.

Any accessible network share should be allowed to be mounted on any 
accessible user folder just like that (anything to which the user 
already has permissions).

The situation for USB sticks is pretty decent these days although the 
paths are horrible and for other types (e.g. camera) it doesn't quite 
work so well. My camera started working recently (in Kubuntu) before I 
needed gphotofs to mount it which had its own issues (won't dismount 
automatically if the camera is removed, which is also still true of usb 
sticks, you can have a lot of issues if you just pull a stick out). 
Reinserting the stick may not update the view that the user has.

So it is not really about system disks for the most part, there is no 
real great issue with having a user having to use sudo or gksudo or the 
like. Because to this day system maintenance really has to be done from 
the shell anyway.

I have spent like, years, first trying to get autofs to work and it 
often fails (just doesn't work all of the time) and now I have 
libpam-mount setup so that I can mount shares for every applicable user 
and also shares that become different for each user while having the 
same name (home directory on server).

However on Windows every user... you know.


>> Why are there so few user-oriented systems that a user can use in a 
>> convenient smaller environment?
>> 
>> - there is no user init system, unless you run stuff through e.g. 
>> .bashrc or some xinit script or whatever. That is extremely arcane
>> and 
>> impossible for a regular user to do.
> 
> this is possible since ages, see 
> http://upstart.ubuntu.com/cookbook/#session-job

Well upstart was better than SystemD I just had no experience with it. 
And I've been around for a while you know. I have also never seen anyone 
else mention it, ever, anywhere.


> also see https://cfp.systemd.io/en/systemdconf_2016/public/events/8
> it is actively being worked on for sysstemd sessions ...

I haven't thought much about user-centric vs session-centric but one of 
my main requirements has always been that the system must also work for 
console, ie. it must work even without a graphical system.

Graphical systems change and are often independable, so we need systems 
that will always be there and remain unsullied by anything being done in 
Gnome or KDE or Unity. It is no good if GUIs create their own systems: 
they should just interface with systems that already exist and that you 
can also access through the command line or console.

I don't like the hegemony of SystemD and being dependent on such a 
filthy system (all of its verbs are just plain wrong) (in equal 
measure... I dislike the verbs of the OpenSUSE package management system 
and the main reason I prefer the Debian line so much is apt).

But I would welcome it if, given current situations, the user-centric 
SystemD model would become dominant so we would at least have something 
useful. It is however not quite user-accessible in the way of having to 
use --user on every command (again, a verb problem).

Also the -ctl naming standard is just plain wrong, but maybe that's just 
me. Control commands should not be called control, just like filesystem 
commands should not be called fs, just imagine having to use "lsfs" and 
"fdiskfs" and "findfs" all the time, you would grow sick of it within a 
minute. There is no great reason why journalctl could not just be named 
journal, or, if that makes it too dominant and available, why it should 
be called journal in the first place and not something to do with log.

"journals" however would not be a bad choice I think. "journal" sounds 
like something you do, an action (a verb). If SystemD (or this part) 
gives access to multiple journals, then why not just call it journals?

Then you can have a system with an interface that allows you to specify 
or select from multiple log files. Equally systemctl does so many things 
that you might just as well call it "control".

If that is too broad and visible of a term (too general) then prefix it 
with something, but there already seems to be a long list of such 
programs. Dump the package that has "scontrol" in the name and then just 
use scontrol.

But if you are going to have an application that almost does everything 
to do with the entire system you are running, then maybe "control" is 
not even that bad.

It would be the only package existing today that could lay claim to such 
a name.

At that point you might also split the functionality it has (because it 
is too much) and create a "services" command or "control-services" (at 
which point: "control services <command>").

You know I am just mentioning some reasons why or how systemd is not 
very good of a system as it is today and how changing the verbs (the 
ways you interact with the system) would automatically inspire changes 
the the applications themselves (where do I put what functionality) such 
that in the end it becomes a bliss to use it even if you don't change 
much of the underlying model at first.

For me, personally:

- I type journalctl when I mean systemctl
- I type systemctl when I mean journalctl
- I type systemd when I mean systemctl

It is a mess. After you've used "systemd-analyze" the next thing you 
type is "systemd" and then you get:

Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

Or something of the kind. It's different before you fully boot up. But 
what *should* be called systemd is called systemctl.

The verbs are all messed up and you always intermingle them. At least I 
do, constantly.

Then the order: because systemctl has so much functionality (as opposed 
to upstart service) it needed to reorder the order of the verbs and 
objects such that "service <name> start" became "systemctl start 
<name>". But "service <name> start" is a /better idiom/. It is the 
object oriented model: select the object first, then do something with 
it.

I pick up a pair of scissors before I use it, I don't first decide its 
use and then only pick it up.

A service is something that should have a button that says "start", it 
shouldn't be something you perform start /on/ as if you have to walk to 
the service manager and say: hey, can you start that service for me?

An object oriented approach puts you more in control and means you can 
interact directly with the service whereas systemd is now in between. 
And it is in between a lot of things, I think. SystemD starts the 
service for you and you cannot ask the service to start itself, that is 
the difference, and the model we have today. Equally to shut it down you 
must first ask SystemD to do it for you. The middle man that can refuse 
you. Once someone has the keys to your residence, you cannot trust him 
anymore to leave you out when you want to. Suddenly there have to be 
"reasons". People abuse positions of power and SystemD does also. Many 
problems with SystemD are related to it being the middle man. Such as 
"promising" that a service will have no timeout and then the service 
itself does timeout.

As a control thing that causes shutdown of services that are hanging, 
that's fine. But SystemD should not be used to define timeouts for 
services when natively they could do the job better.

Meanwhile SystemD does an extremely poor job of killing services that 
are hang and preventing the booting of the system.

Or of continuing regardless or of simple offering some rescue prompt in 
case things don't work.

And SystemD should also not communicate constantly and after only a few 
seconds what those timeouts are. They are control-type timeouts, not 
inherent timeouts to the service. There is no point in constantly 
telling people when you will terminate something, particularly if you 
are not ever going to do it.



>> Suddenly your personal documents are maintained in
>> /var/lib/something!! 
>> I have been fighting this for a long time.
> 
> you should really read up about snaps ... no user data lands in /var,
> by default, user data goes to $SNAP_USER_DATA which is a subdir in your
> home (unless you run a system wide daemon that was explicitly set up
> for not doing that that indeed)

So how do you run a none-system-wide daemon?

Because a system-wide service (such as something running in a browser, 
normally) cannot distinguish between users.

It only could if it was running as that user.

>> error: access denied (try with sudo)
>> 
>> Oops, busted. You need a root prompt for that.
>> 
> the error is mis-leading ... if you use "snap login" to set up your U1
> account, you can install snaps without root privs.

I really don't like how they've chosen a name that is already in use in 
the broader culture (and more dominantly and prominently so, and also 
more usefully so).

If you tell someone you've installed a snap they will look at you with 
very weird eyes.

I think they would consider it cute and stupid.

They have more useful kinds of snaps ;-).

So, searching for "snap login" is impossible.

$ snap find shit
error: no snaps found for "shit"

Doesn't work :p.

Oh, you lie to me, it just doesn't require root privs because it is 
setuid, and you are still installing them system-wide.

The Click documentation states: "Nothing should require root, although 
it may be acceptable to make use of root-only facilities if available" 
(design constraints).

But that's only a sudo difference, it doesn't change anything to the 
system. It is a step in the right direction, I guess, certainly.

But the underlying model is still that only root can do anything.

The user doesn't actually have priviledges to anything. Everything is 
actually executed under user 0. And this will break down the moment you 
are not the system administrator or have not been granted such access.

There is also no way as far as I can see now and know now, to 
differentiate between system-wide packages and user-specific packages.

In Windows you can "install for every user" and "not install for every 
user". Not that it changes much underneath but it at least makes 
accessible to only a select group of users (through the start menu, 
usually).

Perhaps the unix home directory is no place to install programs, but I 
do so regularly (typically Java applications are installed this way) and 
I have upstream-derived tools (versions that don't work in Ubuntu, but 
do work upstream) installed there (~/bin) and one python application 
also (InstaRaider ;-)).

And my experience on the shell host that also hosts a website of mine 
has /always/ been better than a real Linux system for my own because I 
*never* have permission issues on my own home directory, I run every 
type of application there (PHP, alpine, user tools) and basically this 
home directory environment is a bliss compared to a full Linux system 
where I always wonder where I am going to put things.

- /usr/local?
- /opt?
- ~?
- /sbin?
- /root?

There is no end to it currently.


> along with that click packages are user packages and being used in
> ubuntu products on sale since 2015 (snaps will replace them
> eventually).

That just means a user can install them, not that they are installed 
specifically for a user?