Systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls

[MoonMoon]

I never said any such thing. Instead of putting words in my mouth, quote me. Present facts.

You want it, you can have it.
First the part where you complain about it:

dbus has always been a bad idea, and dbus in the kernel is an even worse idea. Not to mention dbus communicating between the kernel and userspace is the worst idea yet.

My dislike of dbus comes from an end user perspective and doesn't have any basis in technical merit. I've run into a ton of bugs deploying systems with dbus.

EDIT: based solely on how buggy it is, I just think we'd all be better off without it.

Then the part where you admit that you are not competent enough to make such a statement:

I'm just not good at coding. It is what it is. I accept my limitations.

And you willingly ignored the part where I'm not a coder.

So you admit not being competent enough to make such a statement, but nonetheless you have no problem to call it and kdbus a bad idea and blame it for causing the problems you have to deal with when deploying systems, when in fact you just don't know (as is pointed out by several others in this thread also).

So when you are called out for this behavior you start with backpedaling:

Well, I apologize for even bringing dbus up.

[snip]

I shouldn't have even mentioned it.

Like I said, My complaints (about dbus) are not based on technical merits. I shouldn't have even brought it up.

And the part where you mention that you don't even use it, but that still nothing else is at fault, implying that you still blame DBUS for your problems.:

The problem that I have with dbus doesn't have anything to do with technical merits. It's not gentoos fault, or openrc, or systemd. I'm not using dbus at all on my gentoo build anyway. One thing I like a lot about gentoo.

All in all it comes down to what I have said, here repeated in the short version: You don't have a clue about DBUS and if it is in fact DBUS that causes your problems, you badmouth it anyways and when called out for it you regret having brought it up, but obviously not because you see your error, but because you got called out for your statements.
Sad enough that I have to go ahead and quote you to show you what you have actually said, but even sadder that it is so obvious that you are not able to evaluate your own opinion based on the facts delivered to you. As was to expect, when one sees this:

I've already formed my opinions and they aren't going to change.

The question that remains is: When this is your modus operandi, why should we take you serious about your systemd statements?

[duby229]

You want it, you can have it.
First the part where you complain about it:

I have the right to comlain about things that have caused serious problems for me. Just as much as you do.

Then the part where you admit that you are not competent enough to make such a statement:

My own words prove I never said anything about competency. Skillsets on the other hand... It's true, I don't have the skillsets to argue the technical merits of dbus. So I won't, and I won't let you drag me into trying.

So you admit not being competent enough to make such a statement, but nonetheless you have no problem to call it and kdbus a bad idea and blame it for causing the problems you have to deal with when deploying systems, when in fact you just don't know (as is pointed out by several others in this thread also).

You don't know anything at all about it. You weren't there. Plus, as I've already said I was asked not to bring it up on a public forum, so I won't.

So when you are called out for this behavior you start with backpedaling:
And the part where you mention that you don't even use it, but that still nothing else is at fault, implying that you still blame DBUS for your problems.:

No that's me repeating myself over and over and over and over and over...... You just can't seem to get it through your thick ass skull.

All in all it comes down to what I have said, here repeated in the short version: You don't have a clue about DBUS and if it is in fact DBUS that causes your problems, you badmouth it anyways and when called out for it you regret having brought it up, but obviously not because you see your error, but because you got called out for your statements.
Sad enough that I have to go ahead and quote you to show you what you have actually said, but even sadder that it is so obvious that you are not able to evaluate your own opinion based on the facts delivered to you. As was to expect, when one sees this:

The sad part is that you're so ignorant that you can't see what's happening right in front of you. You think everything you believe is so correct, and whatever someone else experiences is so wrong. That's you're fault. Change it or deal with it.

The question that remains is: When this is your modus operandi, why should we take you serious about your systemd statements?

You can't say you don't think the same thing. Obviously you do.

[gilboa]

systemd is broken by design. It can be fixed if it will be moved out of PID 1 and rewritten using safer compiled language like Rust and scripting language like Perl, Python, etc.

Care the point out any solid statistics that proves that Perl/Python/Rust based PID1 is more secure than C/C++ based PID1 or are you just inventing stuff as you go along?
(Let alone the fact that biggest gaping security hole in 2014 was discovered in bash [Shellshock]).

- Gilboa

[gilboa]

Last I checked the Linux kernel was not an application.

In many senses, any security issues within the kernel networking layer, IP/UDP/TCP layers and/or iptables, can have far *worse* implications that a mere PID1 bug.
You are plain wrong.

- Gilboa

[TheBlackCat]

My own words prove I never said anything about competency. Skillsets on the other hand... It's true, I don't have the skillsets to argue the technical merits of dbus. So I won't, and I won't let you drag me into trying.

So you think you don't have the skillset to argue technical merits, but you still think you are competent to judge the technical merits. That is your problem right there:https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect.

Plus, as I've already said I was asked not to bring it up on a public forum, so I won't.

Too late. You already did.

[TheBlackCat]

Care the point out any solid statistics that proves that Perl/Python/Rust based PID1 is more secure than C/C++ based PID1 or are you just inventing stuff as you go along?

Don't forget that both Python and Perl are written in C, so it doesn't actually solve the problem, it just means you have the security problems of C and the other language.

[Veske]

https://www.youtube.com/watch?v=ZTdUmlGxVo0 Systemd haters in a nutshell.

[gilboa]

Don't forget that both Python and Perl are written in C, so it doesn't actually solve the problem, it just means you have the security problems of C and the other language.

I fully agree.
While "safe" programming language mitigate common/simple breaches such as string overflow (which can also be solved by using size-terminated strings or by using a long list of "safe" string libraries / classes), the complex VM used by these languages makes for a far larger attack surface. (Let alone the fact that C code can far easier to audit than a complex combination of 4'th generation language + complex VM).

- Gilboa

[nanonyme]

Don't forget that both Python and Perl are written in C, so it doesn't actually solve the problem, it just means you have the security problems of C and the other language.

Except Pypy which is not

[gilboa]

Except Pypy which is not

As far as I remember pypy generates C code, and is still bound to the Python VM (E.g. GIL).
Not sure how this makes it more secure than modern C/CPP code.

- Gilboa