1) All other distros that are defaulting to systemd (Arch, Fedora/RHEL/CentOS, Opensuse, Mageia etc.) seem to have generated fewer uograde issues (percentage wise) than Debian. Maybe Debian rushed through the switch-to-systemd testing because they were stuck debating it for so long. 2) To be a vslid comparison, you shoulf have started with FreeBSD9, applied any customisations you had on your Debian installation, and then upgraded.
Systemd has some minor issues in some situations, bit on the whole I think it is a huge improvement (using it on multiple distros and multiple use cases such as office laptop, media player, home NAS/server, production servers at work).
"I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh"
So if you are an ISP providing a secondary DNS service, you're happy to create accounts with ssh/rsync access for 10 000 customers who all have more lax security than you do?
Talk about attack surface... (even with forced command etc.).
That said, assuning the complexity isn't in serving thr afxr requests, I see no reason why the function to retrieve the zone needs to be inside the daemon listening on port 53. Of course it would need to trigger transfers based on notifies, but that could be done quite easily (a simple file or a named socket).
I use the vSphere Web console on Chrome/Linux, because it doesn't work with the npapi version of flash. There are still some things that the Web console doesn't do well (e.g. copy a generated mac address) that the thick client does better. But was the thick vSphere client available for OS X?
Red Hat Enterprise Virtualisation is a better in that regard, requires a (spice) plugin for the virtual kvm, but doesn't require flash.
The other thing I need flash for is submitting my tax return (in South Africa). About 4 or 5 years ago they used PDF forms (only fillable in the browser using Acrobat, no other PDF plugin would work). About 3 years ago their forms required Acrobat X (not available on Linux) or Flash > 11 (not available on Linux except with Chrome).
In this case I don't know what to hope for... I don't want the hassle of booting up a windows VM to do my tax.
"no hardware or software fault occurred *on the spacecraft*"
There may have been a hardware or software fault on the ground, that resulted in an invalid command sequence. The desired behaviour in this case may be to enter a safe mode, so that you have a known means to recover (rather than bricking).
One of the main objectives of systemd is to take advantage of linux-specific features (such as cgroups) that existed before systemd did.
The servers I am building at present have a minimum of 256GB ram, I couldn't care about a few MB of "bloat", what I *do* care about is resource limits at various levels, which cgroups gives me and systemd makes useable but default.
if you were trolling, you're the worst systemd troll I've seen this year.
Depending on the features the ISP needs, there may not be a suitable upgrade yet.
For example half-duplex vrf isn't available on Cisco ASR9K (Cisco's IPV6 and RFC compliance first platform) and on Cisco ASR1K it doesn't support IPV4. As far as I know, ALU BNG also doesn't support IPV6 in HD VRF.
This is the reason for no native IPV6 over ADSL in South Africa
Depending on the features the ISP needs, there may not be a suitable upgrade yet.
For example half-duplex vrf isn't available on Cisco ASR9K (Cisco's IPV6-and-RFC-compliance-first platform) and on Cisco ASR1K it doesn't support IPV4. As far as I know, ALU BNG also doesn't support IPV6 in HD VRF.
This is the reason for no native IPV6 over adsl in South Africa
Except the 'security appliance' line does not run IOS. These are servers (originally re-badged Dell PowerEdge, but now Cisco UCS C-class rack-mounts) running AsyncOS (a proprietary FreeBSD-based platform), which used to be branded as Ironport.
It doesn't seem to affect any IOS flavour (IOS, IOS-XE which is Linux-based, IOS-XR) or the Nexus NX-OS (Linux-based).
Cost wise, a customer consuming 1TB via torrent is about the same as one consuming 100Gb via Netflix.
This may have been the case before Net neutrality.
Most high speed dedicated links are billed based on 95th percentile, which means the peak 1.5hours.
Before net neutrality, it was feasible to limit the peak, and have torrents consume the unused capacity off-peak. With net neutrality, this isn't as practical.
(I work for an ISP in a region that doesn't have 95th-percentile billing, we have to provision/pay capacity for peak demand, even if that is the 8 hours per quarter of iOS release day, or 2 hours per month of Patch Tuesday).
Some init systems used on linux supported the LSB init script headers which do a similar thing. Some of them also supported parallel start-up (start all services whose dependencies are satisfied).
For example, Mandrake/Mandriva/Mageia used prcsys from around 2004 to 2013 (when Mageia switched to systemd).
But, there are a lot of advantages to systemd and most complaints about it are FUD that have been debunked.
Don't use Type=simple (the default) in a service unit if you don't want the 'simple process intended for use with inetd-style systems' behaviour. See the relevant man page (I think systemd.service) for other options that would be more appropriate for your use case (but I am not sure there is one for "anti-systemd FUD").
Is this really a net neutrality issue? Did anyone verify whether they are injecting across-the-board or only specific sites of competing services?
Disclaimer: I work for an ISP that does JS injection to notify users on quota-based accounts when they have used all of their data, the alternative is to hard redirect http and block all traffic until they log in to a portal.
Really, they could have offered gigabit fibre-based internet before GPON or Active Ethernet became commercially viable to deploy (which was a year or two before Google Fiber launched)? Or before it was developed?
"CEOs get their bonus by raising the stock price."
Even if everyone below them knows that in order to achieve the sudden increase they have destroyed the ability for the company to operate for more than another 5 years.
The usual approach by American MBA CEOs is to cut every conceivable operational expense that isn't required in the short term of their contract's huge bonus conditions (like stop maintaining equipment, getting rid of staff who work on future products or research etc.).
There is one thing the vSphere Web Client does exceedingly better than the (thick) vSphere Client: allows vSphere admins who don't use Windows on their laptops to work more effectively.
While there are some differences in functionality and where features reside, vSphere Web Client is fantastic (except that on Linux it only works on Chrome due to requiring a newer version of Flash than is available as a NPAPI plugin). The fact that the vCenter appliance supports bigger environments now actually allows one to run a non-Windows vSphere shop.
Red Hat's RHEV (vSphere competitor) only has a web app, and this has counted in its favour in the past when vSphere was limited to Windows only. We will be migrating to RHEV for other reasons though...
It seems Mozilla wants to move away from http, but here are some use cases they will be breaking:
I have a slow and expensive Internet connection used by a few people on a few different devices, I use a proxy-cache to improve page load times and reduce network traffic.
I am a parent, and while I try to be present whenever the kids use the internet, I run a proxy-filter (e.g. DansGuardian) to prevent them from stumbling across less suitable sites.
I am a service provider, and I use a transparent proxy to cache large files downloaded from international sites. This saves me about 10% of my running costs.
I am a service provider provoding internet access with high input costs, in order to provide reasonably-priced services I have quota-based products. In order to be friendly to my customers and avoid them incurring over-use charges, I inject JS notifications at various thresholds. With only HTTPS, I will just have to wait until they are over quota and then block all HTTPS traffic and hope I can redirect some HTTP traffic to a page informing them that they are over quota.
I am a security engineer for my company, for various reasons we need to be able to inspect http traffic (prevent users from visiting malicious sites, enforce productivity controls etc.).
Sure, there are technical means around some of these challenges (e.g. devices that ship with/use CA certs and dynamically generate SSL certs to MITM the traffic), but this initiative is just going to increase costs for everyone.
And who will benefit? Well, most of the main sponsors of Let's encrypt. Cisco will be selling you more network equipment that can MITM SSL, Akamai will get more business as ISPs will not be able to cache on their own and content owners will have to pay Akamai instead.
Maybe some affected parties will start blocking Firefox (or block ssl upgrade checks), or some service providers may start charging Firefox users more.
I am a supporter of open source and have used Firefox as my primary browser since before the 1.0 release, but some of the supposed security braindeadness has made life more difficult, and this is just another example, and may be the one that forces me to change to a web browser, instead of an HTTPS-only browser.
If you don't need the feature, it doesn't listen on any socket.
The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.
1) All other distros that are defaulting to systemd (Arch, Fedora/RHEL/CentOS, Opensuse, Mageia etc.) seem to have generated fewer uograde issues (percentage wise) than Debian. Maybe Debian rushed through the switch-to-systemd testing because they were stuck debating it for so long.
2) To be a vslid comparison, you shoulf have started with FreeBSD9, applied any customisations you had on your Debian installation, and then upgraded.
Systemd has some minor issues in some situations, bit on the whole I think it is a huge improvement (using it on multiple distros and multiple use cases such as office laptop, media player, home NAS/server, production servers at work).
"I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh"
So if you are an ISP providing a secondary DNS service, you're happy to create accounts with ssh/rsync access for 10 000 customers who all have more lax security than you do?
Talk about attack surface ... (even with forced command etc.).
That said, assuning the complexity isn't in serving thr afxr requests, I see no reason why the function to retrieve the zone needs to be inside the daemon listening on port 53. Of course it would need to trigger transfers based on notifies, but that could be done quite easily (a simple file or a named socket).
Depends how much the 500 people are paying me for the use of the room, and whether I vake their business or not.
Why would the EU do that, when BS1363 is almost exclusively used in UK,Ireland?
http://www.worldstandards.eu/e...
I use the vSphere Web console on Chrome/Linux, because it doesn't work with the npapi version of flash. There are still some things that the Web console doesn't do well (e.g. copy a generated mac address) that the thick client does better. But was the thick vSphere client available for OS X?
Red Hat Enterprise Virtualisation is a better in that regard, requires a (spice) plugin for the virtual kvm, but doesn't require flash.
The other thing I need flash for is submitting my tax return (in South Africa). About 4 or 5 years ago they used PDF forms (only fillable in the browser using Acrobat, no other PDF plugin would work). About 3 years ago their forms required Acrobat X (not available on Linux) or Flash > 11 (not available on Linux except with Chrome).
In this case I don't know what to hope for ... I don't want the hassle of booting up a windows VM to do my tax.
"no hardware or software fault occurred *on the spacecraft*"
There may have been a hardware or software fault on the ground, that resulted in an invalid command sequence. The desired behaviour in this case may be to enter a safe mode, so that you have a known means to recover (rather than bricking).
"Systemd is causing massive bloat in Linux."
One of the main objectives of systemd is to take advantage of linux-specific features (such as cgroups) that existed before systemd did.
The servers I am building at present have a minimum of 256GB ram, I couldn't care about a few MB of "bloat", what I *do* care about is resource limits at various levels, which cgroups gives me and systemd makes useable but default.
if you were trolling, you're the worst systemd troll I've seen this year.
Did you actually bother reading up about IPv6 (like you probably had to to switch from IPX to TCP/IP)?
You can't just treat IPv6 as IPv4 with longer addresses, some concepts (such as broadcast address) simply don't exist in IPV4.
There are some very good free training materials available, such as from afrinic.
http://learn.afrinic.net/en/co...
Depending on the features the ISP needs, there may not be a suitable upgrade yet.
For example half-duplex vrf isn't available on Cisco ASR9K (Cisco's IPV6 and RFC compliance first platform) and on Cisco ASR1K it doesn't support IPV4. As far as I know, ALU BNG also doesn't support IPV6 in HD VRF.
This is the reason for no native IPV6 over ADSL in South Africa
Depending on the features the ISP needs, there may not be a suitable upgrade yet.
For example half-duplex vrf isn't available on Cisco ASR9K (Cisco's IPV6-and-RFC-compliance-first platform) and on Cisco ASR1K it doesn't support IPV4. As far as I know, ALU BNG also doesn't support IPV6 in HD VRF.
This is the reason for no native IPV6 over adsl in South Africa
Except the 'security appliance' line does not run IOS. These are servers (originally re-badged Dell PowerEdge, but now Cisco UCS C-class rack-mounts) running AsyncOS (a proprietary FreeBSD-based platform), which used to be branded as Ironport.
It doesn't seem to affect any IOS flavour (IOS, IOS-XE which is Linux-based, IOS-XR) or the Nexus NX-OS (Linux-based).
Cost wise, a customer consuming 1TB via torrent is about the same as one consuming 100Gb via Netflix.
This may have been the case before Net neutrality.
Most high speed dedicated links are billed based on 95th percentile, which means the peak 1.5hours.
Before net neutrality, it was feasible to limit the peak, and have torrents consume the unused capacity off-peak. With net neutrality, this isn't as practical.
(I work for an ISP in a region that doesn't have 95th-percentile billing, we have to provision/pay capacity for peak demand, even if that is the 8 hours per quarter of iOS release day, or 2 hours per month of Patch Tuesday).
So, net netrality will result in price increases or degraded services across the board. And non-leachers will subsidise leachers.
Doesn't sound very neutral to me, seems biased against non-leachers.
Some init systems used on linux supported the LSB init script headers which do a similar thing. Some of them also supported parallel start-up (start all services whose dependencies are satisfied).
For example, Mandrake/Mandriva/Mageia used prcsys from around 2004 to 2013 (when Mageia switched to systemd).
But, there are a lot of advantages to systemd and most complaints about it are FUD that have been debunked.
Don't use Type=simple (the default) in a service unit if you don't want the 'simple process intended for use with inetd-style systems' behaviour. See the relevant man page (I think systemd.service) for other options that would be more appropriate for your use case (but I am not sure there is one for "anti-systemd FUD").
Is this really a net neutrality issue? Did anyone verify whether they are injecting across-the-board or only specific sites of competing services?
Disclaimer: I work for an ISP that does JS injection to notify users on quota-based accounts when they have used all of their data, the alternative is to hard redirect http and block all traffic until they log in to a portal.
Really, they could have offered gigabit fibre-based internet before GPON or Active Ethernet became commercially viable to deploy (which was a year or two before Google Fiber launched)? Or before it was developed?
"CEOs get their bonus by raising the stock price."
Even if everyone below them knows that in order to achieve the sudden increase they have destroyed the ability for the company to operate for more than another 5 years.
The usual approach by American MBA CEOs is to cut every conceivable operational expense that isn't required in the short term of their contract's huge bonus conditions (like stop maintaining equipment, getting rid of staff who work on future products or research etc.).
Because of the limited scope (doesn't need to be able to open network sockets, access files etc.) the browser can sandbox it more effectively.
There is one thing the vSphere Web Client does exceedingly better than the (thick) vSphere Client: allows vSphere admins who don't use Windows on their laptops to work more effectively.
While there are some differences in functionality and where features reside, vSphere Web Client is fantastic (except that on Linux it only works on Chrome due to requiring a newer version of Flash than is available as a NPAPI plugin). The fact that the vCenter appliance supports bigger environments now actually allows one to run a non-Windows vSphere shop.
Red Hat's RHEV (vSphere competitor) only has a web app, and this has counted in its favour in the past when vSphere was limited to Windows only. We will be migrating to RHEV for other reasons though ...
It seems Mozilla wants to move away from http, but here are some use cases they will be breaking:
I have a slow and expensive Internet connection used by a few people on a few different devices, I use a proxy-cache to improve page load times and reduce network traffic.
I am a parent, and while I try to be present whenever the kids use the internet, I run a proxy-filter (e.g. DansGuardian) to prevent them from stumbling across less suitable sites.
I am a service provider, and I use a transparent proxy to cache large files downloaded from international sites. This saves me about 10% of my running costs.
I am a service provider provoding internet access with high input costs, in order to provide reasonably-priced services I have quota-based products. In order to be friendly to my customers and avoid them incurring over-use charges, I inject JS notifications at various thresholds. With only HTTPS, I will just have to wait until they are over quota and then block all HTTPS traffic and hope I can redirect some HTTP traffic to a page informing them that they are over quota.
I am a security engineer for my company, for various reasons we need to be able to inspect http traffic (prevent users from visiting malicious sites, enforce productivity controls etc.).
Sure, there are technical means around some of these challenges (e.g. devices that ship with/use CA certs and dynamically generate SSL certs to MITM the traffic), but this initiative is just going to increase costs for everyone.
And who will benefit? Well, most of the main sponsors of Let's encrypt. Cisco will be selling you more network equipment that can MITM SSL, Akamai will get more business as ISPs will not be able to cache on their own and content owners will have to pay Akamai instead.
Maybe some affected parties will start blocking Firefox (or block ssl upgrade checks), or some service providers may start charging Firefox users more.
I am a supporter of open source and have used Firefox as my primary browser since before the 1.0 release, but some of the supposed security braindeadness has made life more difficult, and this is just another example, and may be the one that forces me to change to a web browser, instead of an HTTPS-only browser.
If you don't need the feature, it doesn't listen on any socket.
The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.
Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.
I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..
It didn't install xinetd systemd is the default :-p
# apt-cache search xinetd
?
First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.
Every modern Unix-like system has inetd or xinetd available, many install one of them by default.
The service we require xinetd for on every production server is: Netbackup's bpcd.
Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.
# readlink -f $(which init)
# netstat -plant|grep systemd
#
How is systemd any different?
(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.
# systemctl status rsyncd.socket
rsyncd.socket - Rsync Server Socket
Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled)
Active: inactive (dead)
Listen: [::]:873 (Stream)
Accepted: 0; Connected: 0
# cat
[Unit]
Description=Rsync Server Socket
Conflicts=rsyncd.service
[Socket]
ListenStream=873
Accept=yes
[Install]
WantedBy=sockets.target
What is this, a non-text file? How is systemd controlling this, any more than xinetd was?