core component?
|
| Author | Content |
|---|---|
| 750 Feb 02, 2015 6:46 PM EDT |
To me this list reads like systemd/linux more than anything else. One thing that goes unmentioned is that this minimal "firewall" blocks your ability to access iptables directly. If you attempt to do so, systemd will clobber your changes as it see fit. More and more systemd based distros reminds me of Android. It may have the same kernel, but hell no if it is Linux in the usual sense. |
| notbob Feb 03, 2015 12:02 PM EDT |
> this minimal "firewall" blocks your ability to access iptables directly. Scary enough, but what about the "allow Apache ... instead of saying "allow port :80″ access"". This sounds like systemd is setting up to name single brand requirements rather than making it openly generic. Bad mojo. |
| JaseP Feb 03, 2015 12:46 PM EDT |
Other scary stuff: auditing for NSA compliant apps, their own UEFI secure boot bootloader, networkd, timesyncd... |
| penguinist Feb 03, 2015 2:11 PM EDT |
Quoting:auditing for NSA compliant apps That caught my eye as well when I read this article. So if there really is a working relationship between the NSA and the systemd project, then I would like to know more about it. |
| rnturn Feb 03, 2015 5:47 PM EDT |
Re: "minimal 'firewall' " How difficult is it going to be to tell systemd to stay out of the firewall business altogether? Anyone know? I do not want systemd touching any firewall rules that I choose to put into effect. At. All. (Looks I might have to run Slackware on my firewall to keep these guys from tinkering^Wscrewing with my network's security.) |
| rnturn Feb 03, 2015 6:07 PM EDT |
This is a telling comment about the systemd developers' attitude:Quoting:All systemd developers have SSDs and no more spinning disks, nobody could/wanted to support this anymore. The idea was to read-ahead the bits needed during the boot process and remember it next time, for faster boots. But with SSDs, this support is dropped." (Emphasis mine) And if you choose to /not/ run your system on SSDs? No more Linux for you? Because the developers decided they didn't feel like supporting a hardware configuration they do not personally have on their desks? Great attitude. Where the heck is Red Hat management? (This reminds me a lot of the time we used a software package that was obviously written by developers using superuser privileges as their default. Nobody without superuser privs could use the software properly. Not the vendor's problem we were told. We had to adapt /our/ security policies to deal with it and satisfy the auditors. Somehow.) |
| BernardSwiss Feb 03, 2015 6:30 PM EDT |
Among other gems:Quoting: networkd: because networking is such a basic function of the OS, he believes it should be in systemd Seriously? |
| flufferbeer Feb 03, 2015 7:25 PM EDT |
@rnturn, >> And if you choose to /not/ run your system on SSDs? No more Linux for you? Because the developers decided they didn't feel like supporting a hardware configuration they do not personally have on their desks? Great attitude. Where the heck is Red Hat management? Maybe Red Hat management is urging on its Fedora/CentOS userbase to better hype all of its rpm-based distros containing the sinister systemd? Seems to me that many us would also ask where the heck is DEVUAN when we really need it!!?? 2c |
| penguinist Feb 03, 2015 8:19 PM EDT |
systemd is very clearly a "power grab". I like and use CentOS/RHEL, but I'm choosing to stay with version 6 where life is still good without systemd taking over the system. Fortunately the support cycle is _really_ long and maybe by that time the community will evolve beyond this. |
| JaseP Feb 03, 2015 9:15 PM EDT |
Quoting: And if you choose to /not/ run your system on SSDs? No more Linux for you? ... Not exactly,... What it means is that there is no more read ahead caching during the boot process. However, systemd changes so many things during the boot process, anyway,... For instance, many processes will be started in parallel (at least I think I remember seeing that somewhere). So, there will be speed ups in some places and slowdowns in others... What the lack of read-ahead caching during boot means for most people is that instead of taking, let's say... 11.75 seconds to boot, it will take 12.35 seconds, or some-such-thing... Nope... lack of read-ahead support is just about dead last on my list of scary things about systemd... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!