It Looks Like Canonical Will Soon Publish Vulkan Mir Support On Mesa

[jrch2k8]

boy i miss the old days when lennart haters had decent arguments instead of beating endlessly the same dead horse but i still love how those wanna be experts try to expose the strongest point of systemd as a flaw and after all this time they still fail so miserably.

If at this point in time you cannot understand why systemd is (practically speaking like in production) is at least 5X more resource friendly/secure and performant than any SYSV clone ever was, please go back to your facebook games and stop humiliating yourself or put some actual effort into understanding properly how Linux handle resources(like SMP/memory allocations as on Hot and Cold, caches, preloading, scheduling, etc) and why exactly the interfaces used on systemd are actually important(namespace, cgroups, seccomp, affinity, RT niceness, etc).

Btw, systemd is KISS compliant and way less bloated than any SYSV clone, in fact is more efficient than BASH actually, again try to actually understand why instead of quoting some hater that probably know less about it than you do.

anyway i won't reply to trolling or any other form on non-educated rants and/or comparisons based on personal feelings without actual facts.

mmm, to saves some time. Yes journald had issues with binary format and tooling, this day tools are good enough and since i use ZFS(including root partition at boot with zraid) everywhere this days the corruption issue is gone for me, so yeap lennart was right it is a FS issue(in the FS defense is not a common scenario either since what journald does is factually impossible to do with SYSV)

[cj.wijtmans]

Because it was a crappy OS. Later designs didn't have the need to "optimize" anything. That's what I was saying.

I wouldnt say it was a crappy OS. Insecure yes but ran well if you knew what you were doing. That you dont feel the need to optimize things with "later designs" doesnt mean others feel the same.

"wasting disk space" is another thing that comes from the XP era, that makes no kind of sense in the modern world. Linux system per-se + standard applications occupes a few GBs, 99% of the space in the disk is my stuff and my programs.

SSDs are not that cheap. And you most likely want to limit disk reads/writes even if its once and in theory they last a lifetime. bloat is bloat.

What you say has any importance only on embedded devices, where things like CPU and disk schedulers have some effect on performance. There are at least 30 different cpu schedulers for Android devices, and at least 10 disk schedulers.

I wish you would stop this argument, just because you dont feel like you latency issues on your desktop doesnt mean i feel the same. In fact kernel 4.6 and 4.7 concentrated quiet a bit on these issues which i am excited for these releases.

On desktop, not so much (of course as long as you don't use powersave duh!).

Your needs are not same as for others.

"bloat" implies a performance impact.

False.

If there is no performance impact, it's not bloat.

False.

Vista does not exist anymore, anywhere. There are orders of magnitude more XP than Vista.

Bloatware eventually dies when something better can replace it.

You quoted this:

So you are saying you "looked under the hood" in order to notice "slower boot times". You know someone is a fanboy when they are making incoherent statements.

boy i miss the old days when lennart haters had decent arguments instead of beating endlessly the same dead horse but i still love how those wanna be experts try to expose the strongest point of systemd as a flaw and after all this time they still fail so miserably.

I fail to see how duplicating work is a strong point. Absorbing udevd which led other inits to fork it eventually is not unix-like. Remember very well when openrc just took systemd-udevd out of systemd even though supposedly "it all depended on eachother and couldnt work without eachother", which was a false statement (for some time) and also not a strong point at all or unix-like.

If at this point in time you cannot understand why systemd is (practically speaking like in production) is at least 5X more resource friendly/secure and performant than any SYSV clone ever was

Right now its using about 500mb, partially probably because a lot of files are cached and i have 32gb. I dont remember any other init system using that much.

please go back to your facebook games and stop humiliating yourself

I dont know where you are getting idea from that i play facebook games. Maybe you looked me up on the net and are getting some false ideas, good for you.

or put some actual effort into understanding properly how Linux handle resources(like SMP/memory allocations as on Hot and Cold, caches, preloading, scheduling, etc)

I actually spend days on these things tweaking the kernel, sys conf and testing to see how the latency works out. Just to get more responsiveness on mah videa games.

and why exactly the interfaces used on systemd are actually important(namespace, cgroups, seccomp, affinity, RT niceness, etc).

These things sound nice in theory, but what i found is that they actually mess up my gaming performance. Maybe it works out well for you but not for me. I just want a nice and lean init system and systemd could be exactly that if its removes some unnecessary clutter.

Btw, systemd is KISS compliant and way less bloated than any SYSV clone

Thats an outright lie. In fact its the opposite. Especially now with the kdbus controversy.

, in fact is more efficient than BASH actually

that is probably the only true statement you have said.

again try to actually understand why instead of quoting some hater that probably know less about it than you do.

I never quoted anyone and the one whom doesnt seem to know what he is talking about is you with your outright false "facts".

anyway i won't reply to trolling or any other form on non-educated rants and/or comparisons based on personal feelings without actual facts.

Projection?

mmm, to saves some time. Yes journald had issues with binary format and tooling, this day tools are good enough and since i use ZFS(including root partition at boot with zraid) everywhere this days the corruption issue is gone for me, so yeap lennart was right it is a FS issue(in the FS defense is not a common scenario either since what journald does is factually impossible to do with SYSV)

not true. and journald is still a mess.

[linuxforall]

I thought the integration with Amazon and other web services was only of Unity shell (so any search you do is also sent to them).

Always came with option of turning it off.

[starshipeleven]

I wouldnt say it was a crappy OS.

It was shit on performance because its RAM management was designed when 256MBs were a lot so it was paging like crazy for no reason even if the machine had 4 GB, device drivers could bluescreen it easily (Vista and later the GPU drivers get restarted without a bluescreen), disks had to be defragged or it would slow down, the goddamn registry accumulates crap and slows down the POS unless you run cleaners, and the aggravation of having to tune a piece of trash in the first place.
Ah yes, it didn't even have Sata drivers in the CD until SP3, so I had to slipstream them.
Let's leave the safety aside.

All these issues were solved with Win7 and later.

Insecure yes but ran well if you knew what you were doing.

You seem to like losing weeks tuning shit. I don't. I always automated that, defragging and crap cleaning were run on a schedule, removed all shit services from the installation image alltogether, slipstreamed drivers, and so on.

SSDs are not that cheap.

Irrelevant, saving a few hundred megabytes tops isn't going to change anything.

bloat is bloat.

Our definitions of bloat differ then. Yours seem to be more extreme than average.

Your needs are not same as for others.

The same can be said of anyone else (also you), if you recognize that your usecase is not anywhere near the average, you will understand why I'm saying that your claim that "systemd is bloat" is bs.

So you are saying you "looked under the hood" in order to notice "slower boot times". You know someone is a fanboy when they are making incoherent statements.

I admit that it wasn't a terribly good edit. I wanted to say that the only way to notice anything beyond "slower boot times" (which are obvious) was to look under the hood, so saying "bloat" requires some more explanation.

Right now its using about 500mb,

That's not normal. MIGHT perhaps make sense for a max virtual ram requested (usually irrelevant), but not for actual RAM used.

Here on Debian Jessie after a couple hours from powerup I see around 6 MB used and max virtual RAM requested is 170-ish MB (it's Linux Mint Debian MATE tho, Systemd wasn't its main init system), while on a Manjaro (Arch) install I see around 5 MB used and 110 MB max virtual ram.

I'm using "htop" command line process viewer as most GUI task managers are shit and top is meh.

[starshipeleven]

Always came with option of turning it off.

I know, it was also on by default, letting it get through would have set a bad precedent.
So even if it wasn't the end of the world it had to receive a STRONG message.

[linuxforall]

I know, it was also on by default, letting it get through would have set a bad precedent.
So even if it wasn't the end of the world it had to receive a STRONG message.

I agree and its high time for Ubuntu to go the Red Hat way to survive.