Dbus Broker 17 Released - No Longer Depends On Glib, Better Isolation With Systemd

[tuxd3v]

do what you want, others are capable to cope and can restart nodes without downtimes because an application as important as you pretend has redundancy and no downtime even if a physical node burns down in flames

Like I said, I am not talking about your personal website,
I am not talking about websites neither, you are using http or small databases backends has an example...its what you know.
Another ones here gives examples os small apps self contained with no real risk impact, above the average well known risck factor for any basic application..

Your knowledge about business, is very limited, and there are tons of things behind what you think that are the real scale business.
And like you there are a ton of users that thinks the same, because they think that their website or their desktop application has its the maximum risk...
They don´t know more about...

And this is what I already said, that the Project managers that manage systems like a Init one, have no clue, what they are messing with..
They look at an Init as a desktop thing... when that init will be then placed in the real risk places, were they don´t feet..

Its pure incompetence..

Linux haven´t grown up in the desktop, Linux is deployed in datacenters for a lot of high risk business now.
The idea of bringing it to desktop, is killing the real business in datacenter...look to Microsoft, its an example.
We don´t have Microsoft products in Risky places, only end users..

Aix, Solaris and some Gnu/Linuxs,
But there are already a lot of talks running inside the company, that maybe Linux is starting to be NOT ready for prime time... which lets me very very said, Gnu/Linux used to be rock solid,
With the revolutionary aproach changing things like the Init completly,( for the worst ), the SysAdmin cannot solve problems that before were possible to be solved, without down time, now we are systemd dependent, that makes a lot of magic things in the meadle, and we have downtimes with that..and dowtime for us means millions per hour

Gnu/Linux, come to substitute some Aixs, and I was very happy, but it came because the systems had the reliability that the SysAdmin knowledge allowed, and so they were always at maximum reliability, because of that, Linux gaines a reputation, that could be used in critical places..
Now SystemD is the meadle man, that do things, we don´t want it to do, and when something starts to misbehave, you cannot recover the same way.

We are in a dead end,
I will not proceed this discussion further because its very difficult to speak with someone, that is, or Desktop focused, or small low risk business oriented.

[tuxd3v]

Now imagine - everybody but you knows how to provide HA and testing before deployment

What is the part you haven´t understood?
I am not talking about webservices, that are constantly deployed, haven´ t you figured that already?
I am talking about STABILITY.

A new product has always its dropbacks, bugs to solve, and takes years and years, to mature, at this scale,
And no company that provides this types of services, will take the risk of 1 million€/per hour, of downtime plus technical disaster recovery, because that would mean bankrupt, in less than nothing!

I am speaking of RISK calculation here...you don´t even know what I am talking about,
I am not speaking about your personal website, with minimal impact on downtime..

[DanL]

I think freedom...it not for everybody...Get used to it

Uh, no. Other uses reported problems, so this is not case of the evil, evil SJW's taking over and censoring everything. But don't worry, they could do that tomorrow. Sleep with one eye open.

[malkavian]

I try to resist, but sadly i will have to abandon Debian after 18 years using it, and a year trying other distros. Devuan is great, and maybe I am just being too romantic...

Systemd work and development philosophy doesn't fit with my expectations neither for my personal use, nor for the servers I manage.

[oiaohm]

Now imagine,
A particular application that is massively deployed, and its the only one approved by that country, they work with SysVinit Systems of course...
Does you think they will develop for SystemD?

Of course NOT

The of course NOT is false presume. We are seeing items design for systemd only that use to have sysvint scripts. Service management turns out to be important in multi service services. We have seen some that use to release freebsd and Linux versions of their services now only releasing Linux with systemd unit files only. If the developers of that application decide that service management like systemd provides is more important than supporting sysvinit systems sysvinit support will disappear and worst at times cross platform disappears as well.

I know the exact prices to pay, for some critical services when they are down in some Countries, and a very known case, it costs 1 million €/ hour, of fines from the Government, if that services are down for an hour, this is an example in one of the countries I work with..

This is exactly why we are seeing the change in critical multi service services. The cgroup wrapping of systemd allows you to be sure that all parts of a service have been stop so there is no random part left running jamming up service restart as sysvinit and upstart suffered from.

Why solaris stayed alive as long as it did was party due to SMF that is a another service manager. Systemd and SMF from solaris have a lot in design common. Commerical Unix systems have have integrated service managers into their boot process for quite some time.

The reality here is that sysvinit needs to die. If you like the sysvinit script style you need to make openrc fully functional with cgroupv2 support or some other replacement that includes a proper service manager.

Please note there is a prototype of openrc that uses sysvinit and systemd unit files.

[tuxd3v]

your only problem is that nobody asked you in detail - it was implicit agreed by all and for guys like you a own distribution was created, shut up and help there to keep it alive because otherwise it will be gone soon

No it was NOT implicit Agreed by all...
What is that of implicit agreed?

Are yo joking?
It was forced down on us, with some RedHat Trojan Horses in Debian voting in favor...
But they don´t represent the majority of Debian code base, not even close.

I would like you to answer.. what is implicit agreed?
Because the lack of an agreement doesn´t mean it was implicit agreed... on the contrary!

[tuxd3v]

CREEP AWAY - now you have no problems at all?
so what is all your bullshit about?

"Looks like he's been having trouble with half of his audience there. So why should I bother replying further to him"
why don#t you shut up at all with your uneducated crap

For what I see, you are the one been uneducated here...
The truth is that no one here has the Obligation to educate you( only your own fathers.. )

But some people born, grow up and continue behaving like just pure animals..
Remember,
We born just animals, our fathers have the responsibility to turn us, in Human beans, but even in the lack of them, any adult person should use the brain and understand when he his doing things outside limit.. and try to correct himself, to a more human way..

you are in overflow mode..

[tuxd3v]

your opinion, not more and not less

i run a whole comapny environment on Fedora for a whole decade
Firwall, NAT, VOIP, Database, Fileserver, Spamfilters, Webservers, DNS and what not else

that all was installed in 2018 with F9 and made every dist-upgrade *online* with a reboot just like after a random kernel/glibc update and never installed from scratch

So you have a uptime of about an year, and you thing that is good?
That says a lot about your comment to address the faced problems discussed..

[tuxd3v]

That's exactly the situation that *we* are facing with Red Hat (RHEL) systems atm. Fedora allowed associate developers (these young ones) to mess around with *what we call* the core heart of the distribution (yum). We ended up in big troubles for the past 3 years now. Somewhere in the middle we managed to get along with dnf. But this took us a long journey to get there. A lot of rewriting of code from our own infrastructure was necessary because nothing fit - dnf changed much. Now a new bigger regression has shown up and even slipped into a stable distribution like Fedora 28. Again our infrastructure is broken for weeks now. But at the end I can't blame the associate developers - who are paid by Red Hat. The true problem is their floor manager or project leader (in charge of dnf), that let all this nonsenese happen.

A lot has changed within the past 2 decades that I've been using Linux. Some stuff for the better, some stuff for the worse.

I clearly can not recommend any RHEL product anymore within a corporate environment - based on the development of Fedora. A new convervative approach is needed. Maybe Windows 2019 Server or Debian.

I agree that RedHat Project Managers are the ones that we should blame, in first place.
They were lacking the necessary skills to manage complex projects, with the responsibility like a Init System..

They take young kids, and put them in places were they clearly don´t belong at least yet( to save in cost per developer ),
They don´t understand the complexity "of one solution to fit them all".. also they don´t understand the workflow of unix systems, and the possibilities that OS could be used for a plethora of things..

They look to them for such tasks, has if it were like "designing a Regular Application"( self contained, with no damage for the ecosystem), ...which is clearly pure incompetence, from the personnel above them to put them in charge of something like that..

There are parts of the OS, that need evolutionary approach, not a revolutionary approach,
Because there are tons of services that need to continue to run in different versions,archs, and so on.. a lot of critical services are updated with less frequency, we could be here a month discussing that, because its a ton of things..

Some people managing this projects, seems to have no clue of what they are doing..
To give an example,
I know the exact prices to pay, for some critical services when they are down in some Countries, and a very known case, it costs 1 million €/ hour, of fines from the Government, if that services are down for an hour, this is an example in one of the countries I work with..

Now imagine,
A particular application that is massively deployed, and its the only one approved by that country, they work with SysVinit Systems of course...
Does you think they will develop for SystemD?

Of course NOT,
The risk when that application is deployed could cost them 1 million/hour plus my company work( to solve the problem, when service is down )..
There seems to be a lack of Responsibility or mature enough people, managing that type of projects..

[Candy]

So exactly where are your problems then (systemd supports SysVinit scripts out of the box just fine)?

We don't have any problems with systemd. hreindl quoted a reply of mine to another user where I agreed to him about the problems of having associates changing stuff. I further responded that we ran into issues with dnf, that - during that time - was developed by associates working for RH.

I suggest following the exact reply that I gave, so the content can be understood better. hreindl responed to that reply of mine without properly reading the issues that I wanted to address to that respond that I gave to that other person. But don't worry. I ended up googling hreindl and found his twitter account. Looks like he's been having trouble with half of his audience there. So why should I bother replying further to him ?