That's because we've had them for decades. And no one person or team was responsible for all of them. I would be very surprised if a small systemd team could come up with their own alternatives in a matter of four years without introducing multiple bugs and vulnerabilities. I could be wrong of course, but their track record regarding bugs does not inspire confidence. There are multiple recent bug reports relating to the firewalld service failing to start. Even in Red Hat Enterprise Linux. How embarrassing. I suppose that's just one of those things which might be fixed when they feel like it and who cares for firewalls anyway? It's not as though that old crud enhances computer security in the 21st century, is it? And busy sysadmins have all the time in the world to fix these problems anyway.

comment filename
I am not taking the writer serious, when you don't write the context and the function with it

The developers of systemd lack some social skills imo.
That does not mean that systemd itself is bad.

and PS. the bug reports are debian packaging based, not a systemd bug

my funny part again:
Dont get me wrong here and not compare systemd with the next example literately.

If the Goverment calls everyone that they need a new flew shot (which cures all diseases),
they always say its Mandatory to take the shot, but not everyone is taking the shot.

If firewalld can't even protect the system, then what good is it? Sitting in the system looking pretty? Heck yeah red Hat should be embarrassed. This was their baby after all on some level.

Will this mean sysadmins will have to resort to using shell scripts to load a firewall module and rule set? [sarcasm]I thought systemd was supposed to do everything for people, not expect sysadmins to do more work.[/sarcasm]

Can you provide those bug reports.

@ReaperX7 (starting firewalld from shell script failed aswell)
The ones known by me, have nothing to do with systemd. (copy/paste from your journal will always include systemd)
and firewalld service failing to start, can have multiple reasons. and systemd refuses to start it because there is an issue (after all its a daemon-manager)
if I remove a library file on Slackware (LibEgl anyone ? ...) and I try to start something with systemd, it will refuse to start. (it isn't systemd's fault it doesn't start)

Well there's one here but you have to subscribe to see the solution. That's really funny: having to subscribe to see the solution to a problem that they themselves have created.

And there's another here.

The point of course is iptables and netfilter worked reliably. This systemd-related junk doesn't. But people will still say it's much better than existing methods. Meanwhile sysadmins around the world are abandoning Linux in droves because of this junk and the time they have been wasting trying to fix problems that would not have existed had the distros remained with the tried and true technology.

Bear in mind that while you're away checking whether this really is a systemd bug or not there's probably a sysadmin somewhere in the world right now having to deal with this exact issue. Meanwhile he doesn't have a firewall to protect his server. But because he now has to go and do his research to see if it's a systemd bug or a firewalld bug or a CentOS packaging bug he's not going to be able to troubleshoot the issue as quickly as he could have had it been, for example, an iptables configuration issue. And if it's the bug that was reported to Red Hat he's not going to be able to fix it at all, because the commercial vendor keeps the solutions to the problems it creates behind a paywall.

Of course he should just have used Slackware or Crux or one of the BSDs and avoided this rubbish altogether.

Thanks for defining System D for me. Sorry about that.

What is the standard way to check if your firewall has started in Slackware. Ooops, there is no firewall by default in Slackware. There is only a placeholder for rc.firewall. Its up to you to put something there. So sharing your rc.firewall script that notifies you in case something went wrong on start-up will be appreciated.


Cheers

iptables -L -n? Do i get points for that? :)
or you could check a log or send your self an email or multiple ways i can think of off the top of my head, and im not all that smart and havent done pro sysadmin work in quite a while.
And yes slackware lets you use the best script you can find or write yourself :)

Sure you don't. And you know it ;)


Cheers

But at least Slackware doesn't pretend to have a firewall only for the admin to find out it's not running. Hugely embarrassing for a costly "enterprise" Linux release, don't you agree?

I do understand what is required to get iptables-netfilter up and running on Slackware. I start rc.firewall from rc.local, because the virtual machines with their virtual NICs need to be up first. I don't have a test for it but indeed it would be a good idea to put one together. Just grab the pid and test for it with an if ! ps -p pid then .... Not too hard really, is it?

Of course this is just diverting people's attention from the subject we're discussing here, which is why systemd is causing the mass exodus of Linux sysadmins we have been seeing lately. Do you think it's a good idea to dump all this new firewalld and systemd crap on sysadmins and expect them to pick it up straight away, so that whenever the firewalld service fails to start next time on their enterprise Linux server they will be able to solve it with no downtime? Pretty important when it's a firewall, don't you think?

I'm sure if you work for someone like Red Hat you think it's a great idea, but I'm curious to know what the majority of sysadmins out there at the coal face think. Those who don't have the luxury of falling back on their big employer daddy, in other words, the employer who knows how to fix the problem because he created it in the first place.

No, certainly not. The crazy rate of systemd adoption is something that I don't like. It will take time for things to settle down.


Cheers

Linux will haemorrhage developers, admins and users in the meantime. I've been reading about Debian people who have been with Debian for 18 years moving to FreeBSD. Surely this can't just be brushed off? From what I can see some of them are the older ones. This will make the loss to Linux twice as bad, because, computing-wise, I don't see much maturity in the new generation, who have really just been building on the shoulders of giants. The programming is derivative; the new languages are derivative; the ideas are derivative. I don't see anything revolutionary in IT these days that is not a pale shadow of something already done. 35 years ago practically every development in IT was revolutionary. That's why it's not good to lose these people. They have a perspective which this hyped-up, breakneck generation don't seem to have.

shutdown -h now
 

Do it, close the damn thread.

You probably find it amusing, but I find it embarrassing as it just shows how a certain few Slackware kooks are down to just mudslinging and superficial intellectual gymnastics, regardless of whatever technical merit in their arguments; you guys are an embarrassment to the greater Linux community.

If I wanted trolling, I'd be in /b/, reddit, or SA, not here.

We need discussion Zak, but yes, we don't need mudslinging as unSpawn hinted at.

Anyways, in Slackware you have several options for a Firewall, but you have to implement it. Everyone has known this since day one, or should have. Nobody is going to create your Firewall script for you. Even AlienBOB's EFG requires you to do some gruntwork on your own, to create a CUSTOM firewall script, make it executable, and run it.

That's how you check your firewall.

GNU/Linux already is hemorrhaging developers and projects. Case in point: Byuu the developer of higan (formerly the bsnes emulator) stopped developing his emulator exclusively for GNU/Linux and redeveloped higan for FreeBSD.

http://www.byuu.org

It's one instance, but where one starts, others will follow.

The thread is already beyond discussion, might as well start another without the baggage; 100+ pages in a thread mix of actual discussion and shitposting? No thanks.

The behavior in this thread as well as the behavior in the PAM poll thread are simply embarrassing examples of how easily the more active keyboard warriors of this community can get riled up; I'm sorry for the newbies who'd want to use Slackware more but are turned off from the toxicity.

I am surprised over all the effort given to the systemd-api. Are any of you guys actually _using_ the api? Does it matter if the library functions are public or non-public?
Personally, it scares the sh?t out of me that it (ie systemd) presents a single attack-vector - and so should you all. Next in line - binary (and broken when things break/go awry) journals.
And no - I have not scrutinized the code (and yes, I _am_ a c-programmer first and foremost, script-kiddie next and sysadm for more years than I care to remember) - what concerns me more than code quality is the haughtiness of the devs and their attitude to problems/bugs - and then they want to take over the world.

I know none of you will ever ask _my_ opinion on it - so I'll give it to you for free. I wouldn't touch systemd with even a red hot poker.

I think if people would try to stop turning Slackware it isn't designed to be, we'd never have these issues. Slackware isn't Ubuntu, Fedora, or Arch, so trying to make it like them is going to raise some eyebrows.

Does Slackware need PAM to compete with other Server grade distributions? No it doesn't because you have all the tools to add PAM yourself, and there's tons of examples out there for setting it up.

Does Slackware need systemd to be a modern distribution? No it doesn't because systemd isn't even near completion yet in terms, and Slackware already is modern with it's packages and strong community support levels.

So what does Slackware need? Nothing but a willingness to learn to do for yourself with the tools provided.

There's no problem with creating optional packages, but when someone tries to push optional as required, it's going to draw criticism, and it could be harsh.

Systemd is a constitutional change. If this were politics you'd need an Amendment to get it accepted. Yet here we are having it applied by a few to the majority. This is rather familiar territory - large changes forced on the majority, at the behest of a minority, with all debate shut down or reduced to rock chucking matches. This is how politics is now run, it's therefore of little surprise that its bleeding into software - after all, it's the Corporate influence that has led to this situation, whether in politics or software.

there are people with strong opinions and rude language, if they have education and knowledge, like say Linus, than this is ok, but the people here that try to copy this and use rude language and share their strong opinions show only their lack of knowledge and education, telling every one stupid, using as* and F* words when someone points them to facts and bring proves, those people show only their bad education, limited knowledge and their bad habits.
The handful of people that here explaining the world how a Linux system has to be, from which most of course do not even spend their most time on Linux, floating each thread here with their FUD, paranoia, simple nonsense and technical incompetence are a shame for Slackware. If you want to bring Slackware user into a bad light you need just to quote from this thread was several people have written here, how embarrassing. You think you do something good to Slackware and Linunx, acting like radical ultra orthodox fanatics, arguing with FUD, paranoia, technical incompetence and strong cool language, scaring away everyone who is not on your radical trip? how disgusting, but of course you will have success.

Interesting that you should mention politics and corporate influence in the context of this discussion:

https://igurublog.wordpress.com/2014...ed-by-the-nsa/

Some interesting points in the article.

Let me add a last post before giving up on this ugly thread with its ugly Subject line.

You are ignoring the use-case for PAM.
If you have the time to tinker with your Slackware system and add PAM in a meaningful way, then that is not trivial, takes time, and introduces a maintenance burden because your computer may refuse to let you in after any official Slackware update if the "wrong" package gets updated and you did not notice. Also, this is a typical case where you are not going to have any use for PAM, since tinkering usually means, you are dealing with a single-user system.

Requiring someone like kikinovak to add PAM himself seems reasonable, because he can make a decision between the added work load of maintaining out-of-tree Slackware packages versus the increased functionality he can offer his customers (aka increasing revenue). Still, this strategy will introduce "islands" of non-standard Slackware setups that are hard to troubleshoot because if you post your issues here at LQ, none of us will be able to help because of the unknown implementation.
PAM is not evil despite rumors of the past. If implemented in a proper way, it will not add complexity to your computer. In its simplest implementation, you can just continue with your user management the way you are used even with PAM inbetween, while allowing others to add more complex authentication schemes without having to rebuild several core packages.

firewalld is not a part of systemd. If you have problems with firewalld you may better contact its author instead of bothering the systemd people.

Please present your numbers on that, I would really like to see them.

And someone who is willing to maintain the software that Slackware uses, in case the mentioned software is abandoned by the original developers. And someone who is willing to maintain the codepaths in the dependent projects that are using said software.

I read something like this over and over again, but I still don't get it. Please explain to me how the few systemd developers have applied (others would say "forced down the throat") systemd to all the distributions that have made the change.

Well, I think that they 'forced' people to change to systemd when they merged udev. If udev were still out there (it is now systemd) we wouldn't have this humongous thread discussing it since Slackware could continue to use it without being pushed down to systemd to get security updates and bug corrections. Options to udev are appearing, but a lot of distributions did not want to wait and rushed to systemd.

It is still possible to get the latest version of udev without systemd. Robby Workman provides Slackware packages, AFAIK.

Wait, I have already heard myself saying the very same thing several times. Yeah, I was in a bad dream, arguing with this guy :D


Cheers

The problem is the 'still'. Slackware try not to patch packages as many as possible, and so do others. Systemd never promised to keep udev compatible with the old one. Distributions were wanting to update sysvinit (systemd, upstart, etc) so that users without knowledge could more easily manage their systems, the announce of the merge of udev was just what they needed to rush to systemd since they was wanting for something like it and they do not want to patch udev. Of course they were not FORCED, but you can't say the systemd people made it easy for them merging udev and cutting the time that they would analyze the alternatives in about two years.

It boils down to the question of who is funding the whole FOSS/GNU/Linux show. Who makes all this "free" stuff possible? Just follow the money. And you know what is going on in the ecosystem and why. :)

It is, however, a service systemd is supposed to spawn and control, is it not? If systemd fails to do that what good is it? What's it giving us that we don't already have? From my own layman's perspective it seems for all the convulsions we're going to have to put up with we're getting very little, if anything, in return, that we don't already have.

And it does exactly that: It spawns the service and reports that the service bailed out with an error. What else should it do, bisect the firewalld code and try to find the bug? If there is a bug in [insert service name here] that prevents it from start, why is systemd to blame? If there is a bug in OpenSSH or its configuration on your Slackware system that brings the service down, do you start to blame sysvinit for it?

If you read my earlier post a little more carefully you will see I was talking about systemd and "systemd-related junk".

It's quite obvious ancillary software like firewalld has been developed with systemd in mind. The problem is not just systemd, but this flaky scaffolding around it as well. As you very well know.

I really do believe in free expression, but, this thread has given new life to beating a dead horse. After over 100+ pages and almost 1700 posts is it time to lock this train wreck? Just a suggestion.

And that is what I said, just more drawn out. We could have a semi-standardized Linux-PAM package in SBo, for example, with enough of a detailed README-Slackware file explaining everything anyone would need to know. Rebuilding and reinstalling packages, configuration files, etc. Yes it would be "work" but that's not the point. The problem is until someone is willing to take it up, all we'll have is private out-of-tree packages in personal repositories.

Bart has done an exemplary job with his work and is leading by example of doing hard work with high pay out. His packages may never go official, but at least he's stood his ground and let his package speak for themselves.

As far as the use-case... it all depends is the best answer I can give you, and depending on what can be simple or complex on a case by case basis.

And yes, I agree with hitest, this topic has ran for enough time. By now we all should have gotten the information we all need, learned what we needed to learn, and forged our paths for whatever scenario comes, if and/or when.

systemd is not at all a dependency of firewalld. systemd is not mentioned even once on the firewalld website. So claiming it has clearly been developed with systemd in mind is somewhat weird. Can you back up that claim? When you are at it, still waiting for the numbers for your claim that Linux sysadmins are leaving Linux in droves for BSD.

The foul language, hostile attitude and personal attacks contained in this thread are not acceptable here at LQ and will not be tolerated. I'm going to close this thread for some time to allow a cooling off period (Which is unfortunate; we should be able to respectfully and thoughtfully debated topics that we don't agree on). Additional threads created for the sole purpose of arguing over systemd will result in closures and/or bans. If you have any questions or comments on this, feel free to contact me directly.

--jeremy