Announcement

Collapse
No announcement yet.

Systemd Gains IP Forwarding, IP Masquerading & Basic Firewall Controls

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by TAXI View Post
    But please point your critics where they belong: Your distributior. It wasn't systemd that choosed your distribution should use it.


    So its systemds fault that nobody other wanted to maintain the software that started to rot? The options where to either let the software rot but continue to use it, find an alternative or maintain it for yourself. Systemd chooed the last while everybody other choosed the second and found systemd. Still not systemds fault.
    Of course you're right, distributors do have a certain amount of guilt. They do need to carry some blame. They could have just told systemd devs to fuck off, but they didn't, and that certainly is their fault.

    On the other hand systemd has incorporated so much essential functionality that adopting it is the only thing that's feasible. systemd bares the full brunt of that blame.

    EDIT: Actually let me rephrase that... I don't think distributors should tell systemd to fuck off. Rather I think there should be choice.
    Last edited by duby229; 14 January 2015, 02:54 PM.

    Comment


    • #72


      One of the best posts about systemd I think, worth a read.

      Comment


      • #73
        Originally posted by duby229 View Post
        What other options are there? Every other option there once was got sucked into systemd. I'm still flaming over udev.

        I'll bet you any amount of money that sooner or later networkd will become the ONLY way to run a firewall on systemd systems. It's just how that camp does things.
        Actually, udev is the only component that was "sucked" into systemd (actually the developers of both projects agreed to do this to reduce unnecessary duplication of code), no other component.
        What really is forcing the adoption of systemd is the large amount of time wasted by systemd opponents with creating boycott websites, making useless forums posts or demanding from distributions that they have to work the way that those people want without contributing to them, instead of using that time to come up with alternatives for functionality that is wanted by other projects and only delivered by systemd (it seriously takes the pragmatism of OpenBSD developers to start a project like systembsd to provide that functionality, they don't just whine on forums like a certain kind of Linux users), creating alternatives that are clearly needed in the future (kdbus userspace) or simply maintain existing solutions that provide that kind of functionality (Consolekit anyone?).
        It is not systemd or its developers that is forcing itself on other developers, it is people like you that always shout their anti-systemd propaganda without ever even thinking about providing alternatives for its functionality.

        In short: If you want to have other options that stop whining and start coding. If you can't code than pay someone to it. That is how OSS works.

        Comment


        • #74
          Originally posted by MoonMoon View Post
          Actually, udev is the only component that was "sucked" into systemd (actually the developers of both projects agreed to do this to reduce unnecessary duplication of code), no other component.
          What really is forcing the adoption of systemd is the large amount of time wasted by systemd opponents with creating boycott websites, making useless forums posts or demanding from distributions that they have to work the way that those people want without contributing to them, instead of using that time to come up with alternatives for functionality that is wanted by other projects and only delivered by systemd (it seriously takes the pragmatism of OpenBSD developers to start a project like systembsd to provide that functionality, they don't just whine on forums like a certain kind of Linux users), creating alternatives that are clearly needed in the future (kdbus userspace) or simply maintain existing solutions that provide that kind of functionality (Consolekit anyone?).
          It is not systemd or its developers that is forcing itself on other developers, it is people like you that always shout their anti-systemd propaganda without ever even thinking about providing alternatives for its functionality.

          In short: If you want to have other options that stop whining and start coding. If you can't code than pay someone to it. That is how OSS works.
          So if the majority of people that are forced to use something hate it, then it's their fault? Um, no, that's not how it works.

          And you clearly don't know the story about what happened with udev. It was only a handful of devs that had the majority of power that made that decision. It was only made because the systemd devs didn't want to do the real work. I've never been a big fan of udev. I don't like it. It's not good enough, it never has been. But, there is no alternative, (besides a static /dev) and now there isn't even that.

          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.

          And Consolekit? That buggy piece of junk should never have been deployed anywhere.

          And of course the BSDs can do whatever they want to do.

          Is there any other point you want to try to make that doesn't make any sense?

          Comment


          • #75
            Originally posted by duby229 View Post
            Well, hell.... That alone is a huge flaw. They don't listen to anybody. They do what they want and everybody else be damned.

            If you don't see a problem with that....
            So now they are at fault for not listening to the random forum guy/girl and changing their project accordingly instead of doing what they want? Would you also call it a flaw that Patrick Volkerding does not implement automatic dependency resolution in Slackware despite many people (funnily all of them not even using Slackware) asking for it in the Slackware forum, basically, as you would put it "He does what he wants and everybody else be damned"?
            Why do you think that these developers should develop their project like you want it to be instead of doing it their way? Now it is a bad thing to create and maintain their project as they see fit?
            Wow, just wow, this sense of entitlement is strong in you.

            Comment


            • #76
              Originally posted by Krejzi View Post
              It uses libiptc, which is the library provided by iptables and utilizes libip4tc and libip6tc, much like iptables executables do (in addition to libxtables, which I have no idea what's it for). Better than poking the netfilter kernel subsystem on their own if you ask me. I don't know what nftables is supposed to do, does it use different subsystem than netfilter in the kernel?
              nftables *is* the netfilter subsystem, and the next generation of the (soon to be obsolete) iptables: http://netfilter.org/projects/nftables/ The kernel options it's using are: https://wiki.gentoo.org/wiki/Nftables

              Comment


              • #77
                Originally posted by MoonMoon View Post
                So now they are at fault for not listening to the random forum guy/girl and changing their project accordingly instead of doing what they want? Would you also call it a flaw that Patrick Volkerding does not implement automatic dependency resolution in Slackware despite many people (funnily all of them not even using Slackware) asking for it in the Slackware forum, basically, as you would put it "He does what he wants and everybody else be damned"?
                Why do you think that these developers should develop their project like you want it to be instead of doing it their way? Now it is a bad thing to create and maintain their project as they see fit?
                Wow, just wow, this sense of entitlement is strong in you.
                I can easily choose not to use slackware. It's not easy to choose not to use systemd. It's really a simplistic ideal. That's why systemd has no choice but to listen to their userbase.

                EDIT: when they don't listen to their userbase, which is always, they virtually slap everyone of them in the face...
                Last edited by duby229; 14 January 2015, 04:49 PM.

                Comment


                • #78
                  Originally posted by duby229 View Post
                  That would be ok of course, but what he's talking about is seriously wrong. There are plenty of good reasons why you don't want multiple operating systems installed on the same partition. And even more good reasons why you don't want a booted OS to mess around with an unbooted OS.
                  So you seriously never heard of containers or are you just ignoring them because they would make your argument invalid?

                  Comment


                  • #79
                    Originally posted by duby229 View Post
                    No, I just have a different opinion than you do.
                    If your opinions would be based on facts that would be OK. Sadly, they are not.
                    I've already formed my opinions and they aren't going to change.
                    And this is the core problem. You are basically saying: I came to a conclusion and no amount of facts or changes in the circumstances will ever change them, I am stuck with them forever. A sane person would re-evaluate those opinions in those cases.

                    Comment


                    • #80
                      Svchost for Linux

                      systemd will one day be known as the downfall of Linux. The potential for vulnerabilities is already staggering. This needlessly complicates Linux. Too bad it WAS an awesome init system. If only it had stopped there. The law of unintended consequences shall have the last word.

                      Comment

                      Working...
                      X