Systemd In Ten Years Has Redefined The Linux Landscape

[oiaohm]

Nope tis a DE. Come on there aren't that many of them. You can guess.

I am not guessing. Because there is no DE in that time frame that cleared there issue/bugzilla list. If I am wrong its time for you to put up. Other wise you have been lieing.

I bet the moron here is wanting me to pick something like Unity that in fact was not a DE the DE of Unity was Gnome and it was only a Shell.

If it was unity you claim was absolutely wrong. There are many others like it you could have chosen that not Desktop Environments but shell modifications to existing Desktop environments.

[Paul Frederick]

No guessing there has been zero DE that cleared there issue/bug list since 2017. Maybe you were using something that is officially called a Windows Manager or a shell there is a strict differences here.

Nope tis a DE. Come on there aren't that many of them. You can guess.

[oiaohm]

My issue happened in 2017. Keep guessing.

No guessing there has been zero DE that cleared there issue/bug list since 2017. Maybe you were using something that is officially called a Windows Manager or a shell there is a strict differences here.

Really its about time you name up. Because your statement was absolute sure false. You said systemd had a issue with DE that did not happen in 2017 at all. There were some shells and Windows managers with issues. There was a display manager made by one minor party with a issue as well. Notice something here not a DE. So you first statement without question was wrong. Cannot give you correction if you don't name the project.

This is why it pays to name the project not guess if something is a DE/DM/WM/Shell or not because novices get this wrong all the time.

[Paul Frederick]

There were cases where systemd has screwed emulation of old console-kit interfaces there were real fixes that went into systemd so those worked.

Distribution providing packages is also has a bugzilla/issue place to report integration issues.



Ok so your a lier. At least on one point. It was not DE. You had to change windows manger to windows manager. Only 3 DE to clear their issue/bugzilla lists since systemd appeared are no more. And you are raising a +7 year old issue that really as no current day reverence just to back your pointless hate of systemd.

My issue happened in 2017. Keep guessing.

[oiaohm]

You're right. I reported it to the DE maintainers. Why should the SystemD devs care if some dumb DE doesn't work with their software? Now keep checking DEs to see which one has deleted their old reports. I'll let you know if you've found the right one. This is fun. I never said I was running a major DE, did I? I will say it still exists though. But no more clues. Good luck!

There were cases where systemd has screwed emulation of old console-kit interfaces there were real fixes that went into systemd so those worked.

Distribution providing packages is also has a bugzilla/issue place to report integration issues.

I will say it still exists though. But no more clues. Good luck!

Ok so your a lier. At least on one point. It was not DE. You had to change windows manger to windows manager. Only 3 DE to clear their issue/bugzilla lists since systemd appeared are no more. And you are raising a +7 year old issue that really as no current day reverence just to back your pointless hate of systemd.

[Paul Frederick]

Funny part from this I know you must not have reported against systemd itself because hello they have not in fact deleted a single issue. Locked from future posts deleted no. Also I know that you did not take out a bug with a major distribution. Like Ubuntu, Redhat, Fedora, Debian as the major distributions have not deleted a single issue/bug since their creation.

Also I know that the DE in question is not KDE, Gnome, LXDE or XFCE because their last issue/bugzilla clean out was before 2010 or before systemd existed. So no bug reported to those have been deleted.

See my problem what project are you referring to because anything major rarely deletes old bug/issue reports. So unless you can name project that has had a clean out of it issue tracking saying that it been deleted is highly suspect and sound like you were caught lieing and you decided to cover it with another lie. Yes when projects clean out their bug reports they normally archive them as well so a person like me with a old bug number normally can still access that bug report by talking to the right people.. 3 things I need is bugnumber/issue number, project and year of reporting and most cases I can get the bugreport just asking the right people.

You're right. I reported it to the DE maintainers. Why should the SystemD devs care if some dumb DE doesn't work with their software? Now keep checking DEs to see which one has deleted their old reports. I'll let you know if you've found the right one. This is fun. I never said I was running a major DE, did I? I will say it still exists though. But no more clues. Good luck!

[oiaohm]

Maybe it does work now. But it did not when I needed it to. I do not have your kind of time. I reported the bug and it was ignored. The project has deleted all of their old bug reports too. Now be more wrong. I find it rather amusing.

Funny part from this I know you must not have reported against systemd itself because hello they have not in fact deleted a single issue. Locked from future posts deleted no. Also I know that you did not take out a bug with a major distribution. Like Ubuntu, Redhat, Fedora, Debian as the major distributions have not deleted a single issue/bug since their creation.

Also I know that the DE in question is not KDE, Gnome, LXDE or XFCE because their last issue/bugzilla clean out was before 2010 or before systemd existed. So no bug reported to those have been deleted.

See my problem what project are you referring to because anything major rarely deletes old bug/issue reports. So unless you can name project that has had a clean out of it issue tracking saying that it been deleted is highly suspect and sound like you were caught lieing and you decided to cover it with another lie. Yes when projects clean out their bug reports they normally archive them as well so a person like me with a old bug number normally can still access that bug report by talking to the right people.. 3 things I need is bugnumber/issue number, project and year of reporting and most cases I can get the bugreport just asking the right people.

[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.

Maybe it does work now. But it did not when I needed it to. I do not have your kind of time. I reported the bug and it was ignored. The project has deleted all of their old bug reports too. Now be more wrong. I find it rather amusing.

[oiaohm]

I submitted 3 bug reports. Try again!

To the correct projects and you had made your you where not having hammer hit in screw problem. Since there are 3 bug reports include them in your next post. I suspect the problems are most likely solved or you reported them in completely the wrong place because you were blaming the wrong thing.

[oiaohm]

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.

Yes not that can measure simple. The extra memory usage of Jails or cgroup is kernel based stuff normally not directly linked to process accountancy. This is where you logic is wrong as at times it can be way heavier than hardware base 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.

This is one of those horible thinks that people think is true but in reality is only sometime true. Yes the majority of cases it true but there are examples where it false..
https://indico.cern.ch/event/384358/...aru_takase.pdf
Page 11 here done with docker vs kvm there are old ones with solaris zones vs hypervisor I cannot find that were done by vmware that show the same kind of strangeness.

Notice the ping with docker is way faster than kvm but the sshd is way faster with kvm than docker. So one of those very warped things where a VM can be faster running 2 Linux instances or two freebsd instances than using cgroups/namespaces or jails

Its really horrible that KVM have such a wide performance profile with hardware acceleration is somewhere between the 0% to 80% performance loss . The advantage of docker, jails and zones you don't have this horrible wide profile normally 1 percent to 50% performance loss . So like it or not there are cases that docker, jails and zones lose vs kvm or other virtual machines.

It isn't designed by in large like FreeBSD, Solaris or Redox because nobody is in control leading engineering projects.

But when it comes to process isolation due to the performance problems we see we know that FreeBSD and Solaris did not have the design right.

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.

Kind of true.

They just throw stuff at the wall and that is why you get cgroups/namespace being called a "container"

This is kind of what you call R&D. Thinking at this stage we don't have a design that is perfect for this the R&D process still has it place.

Btrfs was in fact designed by oracle funded developer so both Btrfs and ZFS were fully designed implementation of both have run into major problems like ZFS absolutely horrible memory usage. https://lwn.net/Articles/747633/ XFS lead developer is taking a different route that may render both Btrfs and ZFS design ideas totally invalid. XFS one asks a really good question if the Unix old saying that everything is a file as true why have we not been able to just straight up use file system drivers on files. Why is snapshotting not designed around files as well.

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.

The horrible problem is the solution may not be exactly engineering. It may be the total inverse.

Think about this you give 2 art classes just a block of clay no tools. One class turns in all bricks because the clay was baked solid before you gave it to them and only 1 student is in fact happy because they did not have to do anything because it was exactly what they wanted this is kind of the engineered solution you made sure you got the result you wanted. The other class get unbaked clay and you have huge lot of variation and most of the students are happy bar the 1 that did not want to do anything.

What would be the equal of clay. This kind of would be bpf in the Linux kernel so you can upload highly optimised configuration for what you are doing.

These problems are serous-ally not simple.