Systemd In Ten Years Has Redefined The Linux Landscape

[k1e0x]

https://aboutthebsds.wordpress.com/2...curity-danger/
I stay well clear of talking about freebsd jails the above post covers why. This covers this history freebsd jails core design does not come from a trustworthy coder as well as performing badly. Performance problem cause lot of excess isolation.

Solaris Zones and Linux cgroups/namespaces suffer from basically the same set of problems.

1) The first problem type I can point to a recent example of it in Linux.

https://lkml.org/lkml/2019/9/5/1132

This is example were full isolation can turn rapidly into a hindrance this was one of the cgroup goof ups this is a particular class of goof up resulting in extra memory usage. But Solaris Zones have in their implementation many goof ups like this.

This type goof ups fairly much look the same you isolate process and effectively duplicate the memory incorrectly for some reason. This duplicate memory means you memory management has to work harder to defragment memory. Not being able to get large continuous allocations of memory starts effecting IO performance. At this point your performance disappears into hell.

k1e0x this is really the board game I talked about. Perfect security you are going to duplicate up the memory so that some missing memory protection flag is not going to allow a cross breach but doing this undermines stability and performance. So that deduplication fix in the Linux kernel for slabs is incorrect for perfect security. Maybe we want configuration here why this may not be the answer is 3.

2) Then you have like the Linux PID/network... namespace or the Solaris Non-Global Zones problem. This is like the first problem with a extra side of hell. The applications in these namespace/zones have to presented with information that looks like the a full system even that they are only seeing part information this is mandatory memory duplication that may come back and bite. This is duplication also has to be kept synced in many cases. This syncing takes extra cpu time.

The second one if your workload is hitting it can be faster to run you workload in kvm instead. Again maybe we want configuration here so we can avoid using these things when they make no security sense.

So it really hard working out how to do cgroups and zones exactly right. Get it wrong you can have massive performance hits that appear absolutely random.

Linux kernel did start over with cgroups once already why we have cgroupsv1 and cgroupsv2. Cgroups v2 is way better designed than the first one. Cgroupv1 broke apart zone design way to far allowing multi trees. But allowing users to use of the namespaces when they are not required that cgroups allow gives it performance advantage over zones.

Container on Linux is a theory construct built on top of cgroups and namespaces.

.Basically k1e0x there is no single absolutely right answer for every usage case. So for this stuff we need a stack of setting right.

3) Welcome to the third nightmare. As you add options for configuring the system you add cpu overhead possible to the complete system as you need to check what options apply. Something Solaris managed todo. leading to it being nicknamed Slowaris.

Basically this is one very hard game to win. Every path you can think is a solution to the zones or cgroups/namespace problem can in fact end up killing performance or security or both with a extra side of sometimes completely screwed up stability.

Problem is a perfect implementation cgroups/namespaces and zones for security will be slow. Redox OS cannot avoid this. So you need to make a imperfect solution to have performance the problem is how to achieve imperfection for performance without reducing security too much. Basically we do not want to do a intel with speculative execution.

I don't believe this at all. Where as I can see some of this is true in the right light, I think this is a retroactive spin for cgroups shortcomings. It's mostly due to it not having a clear design goal as with Jails and Zones.

You can be critical of Jails.. but remember Jails invented the idea and inspired Zones 20 years ago. The purpose of Jails and Zones are different than Linux cgroups. The intention for jails wasn't virtualization as much as it was security. Hence the name, Jail.. and yes.. it started out with a lot of incomplete parts. I believe FreeBSD 10 finally isolated System V IPC, and FreeBSD 11 finally isolated the network stack making it mostly a feature complete implementation now. You can say this development was slow.. but containers weren't really very popular till recent times too so.. they were far ahead of the curve in a world where most people were doing hardware based virtualization to solve this problem.

Before Jails was chroot, (if this counts) it's main goal was probably ease of development. (So it shares that with Docker and Linux. and thus shares the security shortcomings)

Sun, Inspired by Jails created Zones and engineered it from the ground up to be full isolation for security. They did this to sell big iron and do multi tenant. Memory isolation is intentional due to the goal being security. Although I don't even know if that is true in the case of shared libraries may in fact not be duplicated, a jail doesn't appear to take any memory.. and if it does it's very small (like kb small). personally I put 6 jails on a host with 1024 megs of ram, each running services and it still had 50% to spare. There was no difference in memory usage from running those same processes on the host. Jails are a lot of things.. slow and bloated they are not. They are extremely thin compared to hardware based virtualization.

KVM is never faster, two OS's are never faster than one. The idea it can be is absurd. OS level virtualization is always going to be faster.

All of this really highlights the major single biting problem with Linux is that it evolves with small chunks of stuff cobbled together to make larger constructs. It isn't designed by in large like FreeBSD, Solaris or Redox because nobody is in control leading engineering projects. They just throw stuff at the wall and that is why you get cgroups/namespace being called a "container" or btrfs as opposed to ZFS or systemd as opposed to launchd. That model works clearly if you want to get something easy done fast.. but when you get to hard topics like containers or filesystems or process accounting it falls apart and NEEDS engineering.

[Lizintacer]

As a desktop user...

Other than that, I just see stuff mostly targeted at servers.

I don't agree with this one. I'm using desktop system with systemd and utilizing heavily the user services for multiple things (including timers, services etc.) I actually start with "can this be a user service" before adding something as a system service. It works great and I've got nice statuses/logs & dependencies system to tie it all.

[cybertraveler]

I really don't get it

Indeed.

[arokh]

Remember to tell them where to put the script.
Place it in ~/.config/system.d.

Also: you should probably tell them how to name it too or they might name the script something like noob.ini instead of noob.service

Name it .service.

Also remember to tell them the command to make systemd incorporate the script.

systemctl enable autoexec.service

Lots of stuff needs networking too, so you might want to give additional instructions on how to ensure networking is up. For that matter, there may be a whole bunch of services which the "noob" might want to have already started before their script runs, but with your service file may start in parallel with.

Add network-online.target and any other dependencies to Requires= and After=.

You know what. Scratch all of the above. You might want to instead instruct the user on how to setup a custom target to ensure their script truly runs after all the services the script might need have already started. This guide may help that user: https://www.mauras.ch/systemd-run-it-last.html


Totally noob friendly

You must be f*cking joking. The argument for an rc.local to begin with is that they have all their custom stuff in there that should handle all they need. I don't see that they would require any other systemd function at all once they can run their script? In any case, what the hell is the problem? Dependencies and start order would need extra care in the script anyways. You haven't pointed out any fault in systemd at all, rather highlighted it's usefulness.

I really don't get it, you're asking for a "noob friendly" way to do lots of "complicated" stuff, noobs need to click an icon and open the browser that's all.

[Paul Frederick]

Lets get roll out I am just a user excuse. So you are person who uses a hammer to put in a screw then wonders why a screw does not hold its rated weight right. First thing todo is find out if the tools are in fact broken or is it simply that they are being used wrong/configured wrong.

There is every possibility that the DE you had trouble running is now fixed and works perfectly with systemd.



Bug reporting systems exist to end users who cannot fix problems can report faults in location that developers of projects and distributions hear about and then can fix them as well. So don't bring this garbage that you could have done nothing to fix them. You could have opened a bug and had a bug number to point to to say I reported X problem here and it was not fixed. So can I take this that you never attempted to get the problem fixed yet you want to complain about it and also don't know if the problem was fixed because some else could have reported it and you are dare to make noise. If that the case shut up you are wasting everyone time.

I submitted 3 bug reports. Try again!

[cybertraveler]

So basically what we're dealing with here is an army of newbies that are complaining because their equivalent of autoexec.bat is gone and they are incapable of reading the manual. It seems to me you are better off with a point and click type of OS, but I'll give you a helping hand:

[Unit]
Description=Noobexec

[Service]
Type=oneshot
ExecStart=/home/newbie/autoexec.bat

[Install]
WantedBy=multi-user.target

There, now you can put your script in there shut up and get off the internet talking about stuff you have no clue about.

Remember to tell them where to put the script.

Also: you should probably tell them how to name it too or they might name the script something like noob.ini instead of noob.service

Also remember to tell them the command to make systemd incorporate the script.

Lots of stuff needs networking too, so you might want to give additional instructions on how to ensure networking is up. For that matter, there may be a whole bunch of services which the "noob" might want to have already started before their script runs, but with your service file may start in parallel with.

You know what. Scratch all of the above. You might want to instead instruct the user on how to setup a custom target to ensure their script truly runs after all the services the script might need have already started. This guide may help that user: https://www.mauras.ch/systemd-run-it-last.html


Totally noob friendly

[aht0]

https://aboutthebsds.wordpress.com/2...curity-danger/
I stay well clear of talking about freebsd jails the above post covers why. This covers this history freebsd jails core design does not come from a trustworthy coder as well as performing badly. Performance problem cause lot of excess isolation.

You should have steered clear of the site too. It's FUD with pretty low standards to written English. Known Linux troll has been authoring it. Next time actually do check the background and data presented for "facts" before trying to use it as an argument. Tho, grammar errors and over-the-top remarks should have been dead giveaway that author is anything but objective and factual.

[oiaohm]

How does it say anything about me? I don't work on either project. I am just an end user.

Lets get roll out I am just a user excuse. So you are person who uses a hammer to put in a screw then wonders why a screw does not hold its rated weight right. First thing todo is find out if the tools are in fact broken or is it simply that they are being used wrong/configured wrong.

There is every possibility that the DE you had trouble running is now fixed and works perfectly with systemd.

The tools are simply supposed to work. When they don't there's nothing I can do to fix them either.

Bug reporting systems exist to end users who cannot fix problems can report faults in location that developers of projects and distributions hear about and then can fix them as well. So don't bring this garbage that you could have done nothing to fix them. You could have opened a bug and had a bug number to point to to say I reported X problem here and it was not fixed. So can I take this that you never attempted to get the problem fixed yet you want to complain about it and also don't know if the problem was fixed because some else could have reported it and you are dare to make noise. If that the case shut up you are wasting everyone time.

[Paul Frederick]

that says more about you than anything else i.e. workman blaming the tools .

How does it say anything about me? I don't work on either project. I am just an end user. The tools are simply supposed to work. When they don't there's nothing I can do to fix them either.

[arokh]

So basically what we're dealing with here is an army of newbies that are complaining because their equivalent of autoexec.bat is gone and they are incapable of reading the manual. It seems to me you are better off with a point and click type of OS, but I'll give you a helping hand:

[Unit]
Description=Noobexec

[Service]
Type=oneshot
ExecStart=/home/newbie/autoexec.bat

[Install]
WantedBy=multi-user.target

There, now you can put your script in there shut up and get off the internet talking about stuff you have no clue about.