Have you actually looked at any of these shell scripts? The largest one in F14 is less that 400 lines and they are all straight forward to read. Where is the tangled mess and when have they ever not worked for you?
its adoption will force a *lot* of people who don't want it to either suffer through it or suffer through migration to another OS. That is reason enough not to adopt it.
How is it something to 'suffer through'. Read a man page or two, and you should be able to admin it and gain the benefits it provides (eg. cgroups configured by default).
Running systemd on all my personal machines and my workstation at the office, I haven't experiened any problems. We'll be upgrading systems in the coming months, and I see no reason to avoid systemd.
Which dependencies exactly? About the only new dependency vs. the previous init system on this distro is: dbus
There are separate projects out there that literally do every single thing systemd does without making it un modular and non posix compliant and have code that is readable.
Please provide a link or a name for one project that has at least all of the useful functionality that systemd has.
Then you have some major projects like gnome where are going to require systemd. Its not a big deal for BSD though. some developers are almost done with systembsd which emulates systemd without actually installing it allowing the depend software to be used without inheriting things like PAM for authentication and other things that are not liked and not actually giving control of the system over to it.
And GNOME developers will just ignore any bugs related to functionality not available on BSD and just stubbed in systembsd...
I have systemd on all of my personal linux boxes (my laptop, wife's laptop, media player, NAS), and it hasn't introduced any issues while resulting in all machines booting faster and provided many more features.
No consumer broadband ISP promises raw bandwidth without prioritisation on their cheapest ($/GB, $/Mbps) prices.
Why? Because it's impossible to ensure everyone can get DNS responses while 20% of the users are flooding the network with as many P2P packets as they can.
DPI doesn't need to berak SSL. Most broadband networks use DPI for managing traffic, and you don't get certificate validation problems when watching youtube.
Most Network Engineers I know work with routers, switches, load balancers and firewalls, and want to run the latest Cisco/Juniper etc. and haven't worked in detail with DPI-based traffic management solutions, so they still think you need to MITM the traffic to identify it.
This is taken from a production DPI-based traffic management device for my traffic while the kids are watching youtube on XBMC (still need to upgrade to Kodi), and clearly shows that youtube on port 443 is easily identified.
(Tried to paste it here, but the filter keeps telling me to use fewer junk characters, even after I removed all brackets, plus signs etc.)
The internet has never been a two-sided market where services have to pay for access to people that want to use them.
There are a number of ISPs in other countries which implemented the 'sponsored bandwidth' model a few years ago already, where the content costs more than the delivery, and to assuage concerns from users (in most cases users on Mobile data) about out-of-bundle costs, the content distributor pays for the bandwidth so that the user can be at ease in using large volumes of traffic to consume the content.
Net Neutrality means that the traffic comes through unimpeded, not everyone gets the same.
No, it doesn't mean that, it means "all traffic (and in some variations, of the same type) should be impeded to the same degree"
Someone who pays for 20Mbit, gets close to 20Mbit someone who pays for 40Mbit gets close to 40Mbit.
Whether you get the speed you pay for or not (assuming all traffic is as fast or slow) is unrelated to Net Neutrality.
It's how each user chooses to use their XXMbit bandwidth that is the focus of net neutrality.
No. It may be about whether the ISP can influence how the user chooses to use their bandwidth or not, and to what degree.
Preventing AT&T or Verizon from throttling Netflix or VOIP services to eek out more money.
Ah, yes, *this* is a Net Neutrality issue.
But, Net Neutrality rules won't fix all the silly problems you Americans have because of lack of competition. Requiring all access network operators to allow ISPs to use capacity on their networks (see IP Connect, IP Stream etc.) to drive competition would probably solve all of the problems.
Sure, but now we are already talking about paid professional developers. My criticism was directed to the original claim which was that the end-user can fix the bugs.
No, the original claim was: "at least the end-user isn't restricted from fixing bugs when they occur."
Paying/getting a different party to fix the bug is a valid application of "not being restricted from fixing the bug". In the case of proprietary software, if the original vendor doesn't fix it, you're stuck with the choice of being vulnerable or making significant changes (switching to a different proprietary software).
Seems a bit silly to store the details you need to access the internet (in the case you router dies) only accessible when you have working internet access. Maybe you should store just those details somewhere you can access without the internet?
On Linux? To connect to WPA2 networks (including WPA2+802.1X). That's an everyday scenario for a pretty much every laptop user.
Sure, you can also do it via cli (with more tools than just those you mentioned), but, do you remember all the steps? Can you teach them to your mum? Can you automate it?
Mandriva/Mageia have net_applet, which is capable of browsing WiFi networks, configuring wpa_supplicant correctly (including access-point roaming), to the point where the normal 'network service' could (depending on your configuration choices) connect to WiFi during boot (before a user is logged in), and be useable for average users.
This was first a useable solution in about 2005, and only stopped working perfectly with the migration to systemd (it still works better than NetworkManager in some respects, but automatic AP roaming after resume seems to not be reliable, didn't have time to track it down... have started using NetworkManager for this use case as it seems I should probably invest time in the future rather than the past).
Everything you needed to know about configuring an interface you could find with 'less/usr/share/doc/iniscripts*/sysconfig.txt', better than any network device where the configuration cli's built-in help is only useful if you've completed 3 weeks of expensive training courses.
Since about RHEL4, anaconda would have populated the HWADDR variables so devices don't get renamed, although the new approach in udev is probably better.
NetworkManager (in the stable versions of the distros I run) seems to still be incapable of: -setting a metric for a device (e.g. METRIC= in ifcfg-$ dev -pppoe over a wifi interface -doing static routes in openvpn like you can in an openvpn config file -sane handling of WiFi (e.g. WPA2-Enterprise where the credentials have other access) passwords like wpa_supplicant+wpa_gui, I don't want to enter it every time I associate to the network, but I don't want it stored on disk... prompt me once and keep it for this desktop session, because the sceeensaver locks on suspend or idle for 2 minutes,, but the desktop session can run for weeks at a time).
All of these features are either very important to me, or critical for me to my job, so NetworkManager is only used for the cases there is something I can't do the traditional way (mobile connection using the built-in 3g modem on my laptop which doesn't seem to work with ppp over the serial devices created by the qcserial driver like with the usb dongles I used before).
If you are concerned about security, you will have a boot loader password configured, no changing the kernel command line. Of course, you would also have ensured no removable media are bootable, and have set a bios password, and have kept the server physically secured (no removing the BIOS battery, removing any disks etc.).
I needed Flash to file my tax return last night. The bigger problem was viewing the calculated result, that needed Acrobat (all other PDF viewers show the content "this PDF musy be viewed in Adobe Reader 9 or later"), which you can't download anymore and my other laptop that should have a copy is out of action. That's when you need virtualisation of some kind... (kvm/virt-manager in my case).
No, require them (and all other fixed broadband access network operators) to wholesale their access network at regulated prices.
Many countries which have access network monopolies (e.g. UK where BT is almost the only provider of access lines) follow this approach.
If you allow competition over the existing infrastructure, you won't have to regulate the service providers, the market will.
I thouhht America was the land of the capitalists (where competition can result in better products and services as long as there is some minimal regulatory oversight).
although not yet enabled by default in jessie, it's causing a -lot- of disruption with basics like remote rebooting becoming an economical hazard (petrol costs), remote desktops not cranking up, auto logins not working (previously reliable packages like gdm3 break on upgrade due to forced dependencies to systemd related packages), endless hangs on startup/shutdown, many users complain about slow shutdowns, or machines not shutting down at all, services not starting.
Upgrades of other distributions from pre-systemd to partial systemd (e.g. systemd-sysvinit) to full systemd (units for all services) have worked fine for me. My personal machines (2 desktops, one xbmc box, one home server/NAS/virtualisation host, multiple VMs) that have been running with systemd for more than a year have no issues like this.
Maybe your problems are more due to Debian (testing) and less due to systemd.
That said, there are some problems reported with network filesystems mounted from/etc/fstab, my boxes are running autofs for network mounts which may be why I haven't seen any of those issues.
With systemd, one can't even remotely log a journal natively, which is par for the course in many server environments.
If you are referring to the feature enhancement tracking bug you link to below, the text of the bug states:
Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. This can be used as an alternative or in addition to existing log forwarding solutions.
I assume the 'par for the course' is normal log forwarding via syslog, which is noted as already available in the text above.
You can't make this stuff up, please see bug #1098132 (https://bugzilla.redhat.com/show_bug.cgi?id=1098132) At the time I'm writing this, that functionality still just *doesn't exist* in systemd/journalctl.
The feature linked to from the bug is a feature that doesn't exist in any logging solution I am aware of. It brings the benefits of the journal (being able to detect if there are missing messages) to remote logging. Yes, there are means to try and prevent an attacker from reaching your logging server, but can you *prove* your remote logging server has not been tampered with? No? With remote journal logging, you would be able to.
No, this will not remove journald from being the owner of/dev/log (as you imply in replies below). If you use this feature, you will have the 'binary logs' feature the rest of the anti-systemd crowd decries on your remote logging server.
The feature you want has been available since journald was availble in any released distribution (and I might add is usually the default in a server-oriented distribution such as RHEL7); the feature tracked by the bug you linked to probably isn't what you want.
Please provide a link to your patch or git repo with this feature.
Yes, I like this feature of systemd. None of the wonderful, stable, featureful init systems (I have maintained init scripts in linux distros with two different init systems before systemd) linux init systems has it.
Until one does, please acknowledge this as a feature systemd has that is nice, and is non-trivial on any other traditional init system (at least without invoking the wrath of the 'I don't want my init system to take over/dev/log' crowd).
I am concerned about more practical side which is to administer the servers at my responsibility *without* using systemd altogether - I do not use graphical interfaces, but it appears that after Jessie, there wont be alternatives.
Have you actually tried using a distribution that has fully migrated to systemd? What exact problems did you run into that would prevent you from administering your servers? Did you notice that it specifically has features for servers? Did you notice any conveniences (e.g. 'systemctl status foo' showing you the last few log entries from foo)? Did you notice your crappy init scripts (as long as they had LSB headers) still worked?
You also seem to imply that systemd requires a graphical interface... which is quite false. My home server is running a distro with systemd, and there is no X server installed, and systemd doesn't pull in any X libraries. Sure, if requires dbus, but soon dbus will be in-kernel:-p.
Similar logic applies to having the ISP cut off your connection entirely -- if they got statutory authority for one of them, I bet they could get the same kind of permission for the other (if the original language of the law doesn't cover both already).
I am not sure how it works in the U.S., but for example in South Africa, retail internet access products are usually provided subject to Terms of Service, which would allow for remedial action of some kind for abuses such as spamming, port-scanning etc.
Next up: Booting all of your connectivity -- mobile as well as hardline -- through one, integrated, Big Brother-ish app.
And the best way tools such as this have to communicate updates to those who shoupd get the updates is.... by email. And the Daimler solution would mean I wouldn't easily be able to see the updates I missed.
Surely there are other mechanisms to keep people stress-free while on leave? I just turn off email synching until the morning I return to work (with a suitable OoO message set).
On Android, access to the contents of the device requires the screen to be unlocked. Does iOS also require this?
(Access to the device without installing drivers isn't an issue, but the computer OS should prompt before automatically mounting the device too, which I believe Linux does but Windows doesn't).
Slashdot Mirror
Have you actually looked at any of these shell scripts? The largest one in F14 is less that 400 lines and they are all straight forward to read. Where is the tangled mess and when have they ever not worked for you?
RHEL6: /etc/rc.sysinit /etc/rc.sysinit
$ wc -l
662
RHEL5: /etc/rc.sysinit /etc/rc.sysinit
$ wc -l
980
This is what systemd actually *replaces*.
its adoption will force a *lot* of people who don't want it to either suffer through it or suffer through migration to another OS. That is reason enough not to adopt it.
How is it something to 'suffer through'. Read a man page or two, and you should be able to admin it and gain the benefits it provides (eg. cgroups configured by default).
Running systemd on all my personal machines and my workstation at the office, I haven't experiened any problems. We'll be upgrading systems in the coming months, and I see no reason to avoid systemd.
it's the dependencies thats a real problem.
Which dependencies exactly? About the only new dependency vs. the previous init system on this distro is: dbus
There are separate projects out there that literally do every single thing systemd does without making it un modular and non posix compliant and have code that is readable.
Please provide a link or a name for one project that has at least all of the useful functionality that systemd has.
Then you have some major projects like gnome where are going to require systemd. Its not a big deal for BSD though. some developers are almost done with systembsd which emulates systemd without actually installing it allowing the depend software to be used without inheriting things like PAM for authentication and other things that are not liked and not actually giving control of the system over to it.
And GNOME developers will just ignore any bugs related to functionality not available on BSD and just stubbed in systembsd ...
I have systemd on all of my personal linux boxes (my laptop, wife's laptop, media player, NAS), and it hasn't introduced any issues while resulting in all machines booting faster and provided many more features.
(it has network connections, so in theory, it can be remote rooted)
[root@buchan-laptop ~]# ps auxww|grep systemd|wc -l
12
[root@buchan-laptop ~]# netstat -plant|grep systemd
[root@buchan-laptop ~]#
No consumer broadband ISP promises raw bandwidth without prioritisation on their cheapest ($/GB, $/Mbps) prices.
Why? Because it's impossible to ensure everyone can get DNS responses while 20% of the users are flooding the network with as many P2P packets as they can.
DPI doesn't need to berak SSL. Most broadband networks use DPI for managing traffic, and you don't get certificate validation problems when watching youtube.
Most Network Engineers I know work with routers, switches, load balancers and firewalls, and want to run the latest Cisco/Juniper etc. and haven't worked in detail with DPI-based traffic management solutions, so they still think you need to MITM the traffic to identify it.
This is taken from a production DPI-based traffic management device for my traffic while the kids are watching youtube on XBMC (still need to upgrade to Kodi), and clearly shows that youtube on port 443 is easily identified.
(Tried to paste it here, but the filter keeps telling me to use fewer junk characters, even after I removed all brackets, plus signs etc.)
The internet has never been a two-sided market where services have to pay for access to people that want to use them.
There are a number of ISPs in other countries which implemented the 'sponsored bandwidth' model a few years ago already, where the content costs more than the delivery, and to assuage concerns from users (in most cases users on Mobile data) about out-of-bundle costs, the content distributor pays for the bandwidth so that the user can be at ease in using large volumes of traffic to consume the content.
Net Neutrality means that the traffic comes through unimpeded, not everyone gets the same.
No, it doesn't mean that, it means "all traffic (and in some variations, of the same type) should be impeded to the same degree"
Someone who pays for 20Mbit, gets close to 20Mbit someone who pays for 40Mbit gets close to 40Mbit.
Whether you get the speed you pay for or not (assuming all traffic is as fast or slow) is unrelated to Net Neutrality.
It's how each user chooses to use their XXMbit bandwidth that is the focus of net neutrality.
No. It may be about whether the ISP can influence how the user chooses to use their bandwidth or not, and to what degree.
Preventing AT&T or Verizon from throttling Netflix or VOIP services to eek out more money.
Ah, yes, *this* is a Net Neutrality issue.
But, Net Neutrality rules won't fix all the silly problems you Americans have because of lack of competition. Requiring all access network operators to allow ISPs to use capacity on their networks (see IP Connect, IP Stream etc.) to drive competition would probably solve all of the problems.
Sure, but now we are already talking about paid professional developers. My criticism was directed to the original claim which was that the end-user can fix the bugs.
No, the original claim was:
"at least the end-user isn't restricted from fixing bugs when they occur."
Paying/getting a different party to fix the bug is a valid application of "not being restricted from fixing the bug". In the case of proprietary software, if the original vendor doesn't fix it, you're stuck with the choice of being vulnerable or making significant changes (switching to a different proprietary software).
Seems a bit silly to store the details you need to access the internet (in the case you router dies) only accessible when you have working internet access. Maybe you should store just those details somewhere you can access without the internet?
And the wireless network name. And the wireless network username+password.
And then, I have to do it all again in two minutes when you walk out of range. And then again when you get home. And then again at a cafe.
NM might not be the nicest of things, but it sure beats the hell out of running several commands every time I relocate myself/my laptop.
You really haven't had to do it that way since 2004.
$ man wpa_supplicant.conf
On Linux? To connect to WPA2 networks (including WPA2+802.1X). That's an everyday scenario for a pretty much every laptop user.
Sure, you can also do it via cli (with more tools than just those you mentioned), but, do you remember all the steps? Can you teach them to your mum? Can you automate it?
Mandriva/Mageia have net_applet, which is capable of browsing WiFi networks, configuring wpa_supplicant correctly (including access-point roaming), to the point where the normal 'network service' could (depending on your configuration choices) connect to WiFi during boot (before a user is logged in), and be useable for average users.
This was first a useable solution in about 2005, and only stopped working perfectly with the migration to systemd (it still works better than NetworkManager in some respects, but automatic AP roaming after resume seems to not be reliable, didn't have time to track it down ... have started using NetworkManager for this use case as it seems I should probably invest time in the future rather than the past).
Everything you needed to know about configuring an interface you could find with 'less /usr/share/doc/iniscripts*/sysconfig.txt', better than any network device where the configuration cli's built-in help is only useful if you've completed 3 weeks of expensive training courses.
Since about RHEL4, anaconda would have populated the HWADDR variables so devices don't get renamed, although the new approach in udev is probably better.
NetworkManager (in the stable versions of the distros I run) seems to still be incapable of: ... prompt me once and keep it for this desktop session, because the sceeensaver locks on suspend or idle for 2 minutes,, but the desktop session can run for weeks at a time).
-setting a metric for a device (e.g. METRIC= in ifcfg-$ dev
-pppoe over a wifi interface
-doing static routes in openvpn like you can in an openvpn config file
-sane handling of WiFi (e.g. WPA2-Enterprise where the credentials have other access) passwords like wpa_supplicant+wpa_gui, I don't want to enter it every time I associate to the network, but I don't want it stored on disk
All of these features are either very important to me, or critical for me to my job, so NetworkManager is only used for the cases there is something I can't do the traditional way (mobile connection using the built-in 3g modem on my laptop which doesn't seem to work with ppp over the serial devices created by the qcserial driver like with the usb dongles I used before).
If you are concerned about security, you will have a boot loader password configured, no changing the kernel command line. Of course, you would also have ensured no removable media are bootable, and have set a bios password, and have kept the server physically secured (no removing the BIOS battery, removing any disks etc.).
I needed Flash to file my tax return last night. The bigger problem was viewing the calculated result, that needed Acrobat (all other PDF viewers show the content "this PDF musy be viewed in Adobe Reader 9 or later"), which you can't download anymore and my other laptop that should have a copy is out of action. That's when you need virtualisation of some kind ... (kvm/virt-manager in my case).
No, require them (and all other fixed broadband access network operators) to wholesale their access network at regulated prices.
Many countries which have access network monopolies (e.g. UK where BT is almost the only provider of access lines) follow this approach.
If you allow competition over the existing infrastructure, you won't have to regulate the service providers, the market will.
I thouhht America was the land of the capitalists (where competition can result in better products and services as long as there is some minimal regulatory oversight).
Upgrades of other distributions from pre-systemd to partial systemd (e.g. systemd-sysvinit) to full systemd (units for all services) have worked fine for me. My personal machines (2 desktops, one xbmc box, one home server/NAS/virtualisation host, multiple VMs) that have been running with systemd for more than a year have no issues like this.
Maybe your problems are more due to Debian (testing) and less due to systemd.
That said, there are some problems reported with network filesystems mounted from /etc/fstab, my boxes are running autofs for network mounts which may be why I haven't seen any of those issues.
Caveat: I am a server admin.
With systemd, one can't even remotely log a journal natively, which is par for the course in many server environments.
If you are referring to the feature enhancement tracking bug you link to below, the text of the bug states:
I assume the 'par for the course' is normal log forwarding via syslog, which is noted as already available in the text above.
The feature linked to from the bug is a feature that doesn't exist in any logging solution I am aware of. It brings the benefits of the journal (being able to detect if there are missing messages) to remote logging. Yes, there are means to try and prevent an attacker from reaching your logging server, but can you *prove* your remote logging server has not been tampered with? No? With remote journal logging, you would be able to.
No, this will not remove journald from being the owner of /dev/log (as you imply in replies below). If you use this feature, you will have the 'binary logs' feature the rest of the anti-systemd crowd decries on your remote logging server.
The feature you want has been available since journald was availble in any released distribution (and I might add is usually the default in a server-oriented distribution such as RHEL7); the feature tracked by the bug you linked to probably isn't what you want.
Please provide a link to your patch or git repo with this feature.
Yes, I like this feature of systemd. None of the wonderful, stable, featureful init systems (I have maintained init scripts in linux distros with two different init systems before systemd) linux init systems has it.
Until one does, please acknowledge this as a feature systemd has that is nice, and is non-trivial on any other traditional init system (at least without invoking the wrath of the 'I don't want my init system to take over /dev/log' crowd).
While phones (Jolla) running wayland have been on the market for about a year.
Have you actually tried using a distribution that has fully migrated to systemd? What exact problems did you run into that would prevent you from administering your servers? Did you notice that it specifically has features for servers? Did you notice any conveniences (e.g. 'systemctl status foo' showing you the last few log entries from foo)? Did you notice your crappy init scripts (as long as they had LSB headers) still worked?
You also seem to imply that systemd requires a graphical interface ... which is quite false. My home server is running a distro with systemd, and there is no X server installed, and systemd doesn't pull in any X libraries. Sure, if requires dbus, but soon dbus will be in-kernel :-p.
I am not sure how it works in the U.S., but for example in South Africa, retail internet access products are usually provided subject to Terms of Service, which would allow for remedial action of some kind for abuses such as spamming, port-scanning etc.
You say that as if there isn't a billion-dollar broadband policy (PCRF) and control (PCEF/"DPI") market
And the best way tools such as this have to communicate updates to those who shoupd get the updates is .... by email. And the Daimler solution would mean I wouldn't easily be able to see the updates I missed.
Surely there are other mechanisms to keep people stress-free while on leave? I just turn off email synching until the morning I return to work (with a suitable OoO message set).
On Android, access to the contents of the device requires the screen to be unlocked. Does iOS also require this?
(Access to the device without installing drivers isn't an issue, but the computer OS should prompt before automatically mounting the device too, which I believe Linux does but Windows doesn't).