Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f/var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
'systemctl status dhcpd' shows me the logs I need to see 95% of the time.
If you don't know what the service name is, or just want to see recent logs or failures, try journalctl -b|tail or journalctl -x.
It really isn't that hard to run journaltcl --help, but these days it seems no-one on slashdot is able to do that, they are only able to use commands that existed in the previous century...
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not,
Then there is a problem with the service unit file. A common one is not setting the correct Type= value
or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Then the service unit file should have a suitable TimeoutStartSec= specified.
Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwritten on a package upgrade.
And getting anything of value out of the log is a pain in the ass.
Really? 'systemctl' to find failed services, 'systemctl status foo' or 'journalctl -b' to see why services failed are quite easy to use and remember, and will find most boot issues.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons.
It sounds more like the daemons are unreliable, or haven't got useful defaults in their service unit files, but that is very easy for you to fix (copy the original unit shown in 'systemctl status foo' to/etc/systemd/system/foo.service, edit as necessary, run 'systemctl daemon-reload'). See systemd.unit for more info.
Nothing has been gained with systemd, at least not on servers.
My experience so far has been that systemd has saved more time than it has cost, and the 'cost' is a once-off investment, and the savings continue.
A big ol ball? My init.d was about 13 scripts big which were readable and editable.
On what distro was this?
Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in/etc/fstab mounted. For example, is/var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is/usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.
Ever tried to edit systemd files?
Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.
You copy the existing file from/usr/lib/systemd/system to/etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).
However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.
According to it's documentation, FreeBSD behaves the same way (thought the option name is different):
If the option ``failok'' is specified, the system will ignore any error
which happens during the mount of that filesystem, which would otherwise
cause the system to drop into single user mode. This option is imple-
mented by the mount(8) command and will not be passed to the kernel.
The best part is how they want to use systemd to save 12 seconds of boot time on my servers that take 5-10 minutes to boot, once every few years.
Boot time reduction wasn't the primary goal of systemd.
The alternative to your servers taking 5-10 minutes to boot, is having them boot incorrectly (like not mount their boot-from-SAN root filesystem because the FC card took too long to log into the fabric after you a power failure to the rack that included the FC switch), and require manual intervention (30 minutes+ additional boot time) to boot correctly.
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
I have seen enough failure modes to agree that this is better.
I can't get out my mom's basement, she never had one, and her house is about an hour's drive from mine.
It's interesting that you are resorting to insults when you got constructive feedback.
Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your/etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Type= parameter in their service file, in which case the default of simple (which is intended to replace the xinetd behaviour) applies and results in systemd assuming that it should not log stderr from the service's process. In this case, using Type=forking would probably have done what was expected. For example, on one of my systems, ntpd, dhcpd etc. use Type=forking, and they log correctly so that systemctl status dhcpd shows any errors in starting dhcpd.
One nice feature of systemd here is that you don't have to go hunting for log files (and possibly add new rules to your syslog daemon to log the facility in question first) to find the other lines of log files about you need to fix the problem, almost all services now have useful logging easily accessible by default.
If you have other examples where systemd behaves incorrectly (according to documentation of the services/features in question), maybe you could provide them.
Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
So, you were relying on bugs to boot your systems?
I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
I think you are confused.
Here is the service unit file for systemd-timesyncd From this it should be quite apparent that: 1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions. 2)The service doesn't run as root, but as a dedicated user. 3)There is a separate, dedicated service, that can be stopped and started without touching the pid 1.
The same goes for the DNS resolution service/daemon.
I am not aware of any NFS-related service that is built into systemd.
I think you've been reading too much anti-systemd FUD, and believing it.
"We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."
The author states that this is a Linux problem, but only reports using systemd on Debian and Ubuntu, and complains about optional features that are not enabled on "Enterprise" or stable distros.
I have used systemd on a number of distros on a variety of hardware (production bare-metal servers, production VMs, desktops, laptops) and have never experienced the problems the Debian and Ubuntu users complain about here.
All of the "examples" I have seen were obviously due to the user having spent mote time trying to manufacture a bug than reading the very good documentation.
"That's backhoe power. That's why we need net neutrality."
No, that's why the U.S. needs to split "backhoe power" from "internet service" power, by requiring last-mile providers to offer reasonably-priced wholesale products, so that available last-mile provider doesn't dictate only available internet srervice provider.
Then you could regulate internet service less (and let the market address it).
Many other countries have models like this that have wirked well for over a decade..
"Is this the same Sandvine whose business model included spoofing data packets to discourage bittorrent activity, regardless of whether the content being torrented was legal?"
Sandvine is a network equipment vendor, their business model is to provide technology and services (consulting, support etc.) to ISPs that allow the ISPs to manage the utilisation of their network.
Their products are quite comprehensive and flexible.
For example, their products also support integration with bittorrent caching/acceleration solutions (in some markets this can provide customets faster bitttorrent downloads while saving costs for the ISP).
The business pratice of slowing down torrents would be that of the ISP in question, and if Sandvine didn't offer it, they would have chosen another vendor (Allot, Procera, Cisco etc.).
"Linux isn't really an option, especially with so many distros including systemd. I hate to say this, but I've found Windows 10 to boot more reliably for me than the versions of Debian and Ubuntu that use systemd!"
The only Linux users I see complaining about systemd are Debian and/or Ubuntu users, and with issues I haven't seen and in some cases tried to reproduce and couldn't.
Have you tried one of the other distros that uses systemd? Fedora, SUSE, Arch, Mageia etc.?
"Make no mistake, the extension is going on right now. Linux isn't getting.Net Core because Microsoft wants Linux servers to run ASP.Net sites. That's laughable."
Oh, so SQL Server 2016 for Linux is actually intended for Android? Thanks, now I won't even consider it...
The Ubuntu kernel for AWS also includes the ENA (Elastic Network Adapter) driver (source code: https://github.com/amzn/amzn-d...), which allows you to get 20Gbps networking on certain instance types (https://aws.amazon.com/about-aws/whats-new/2016/06/introducing-elastic-network-adapter-ena-the-next-generation-network-interface-for-ec2-instances/).
I believe RHEL 7.4 also added the ENA driver, and the Amazon Linux image has it of course.
"With VISA, a bank basically tells VISA you have the money or credit, but if you don't, they simply give you a negative balance and the merchant is guaranteed to get the money."
That would depend on how the bank has implemented authorisation processing. Maybe U.S. banks aren't able to do real-time accurate authorisations, but that isn't a limitation in Visa/Mastercard's side. My bank seems to do it real-time. For example I recently had a transaction declined (while filling up at a gas/petrol station), Itransferred sufficient funds from my phone, and re-tried the transaction and it succeeded immediately, less than 2 minutes after the first attempt. In this case it was a MasterCard card.
"It's very evident when you do overseas transactions, even transaction holds, which show up in a matter of seconds/minutes in the US won't show up on your card for days"
We get text/SMS notifucations of any credit card activity. I paid my hotel bill by Visa card lst time I travelled overseas (a few years ago), and received a text from by bank (including an accurate balance of available credit on the card) before the credit card machine printed the receipt. I think that was a Visa card.
So, it seems the capability is there (on both major card networks), but the U.S. banks lag even the banks in African countries in the implementations of their side of the authorisation (like they also seem to do with 3D-secure/VerifiedByVisa for card-not-present transactions).
The bug you linked to (Bug 35622 - misrenders http://www.angryflower.com/) was opened in 2001 and closed in 2002.
Are you sure that was the right one?
(I happily use KDE 5 8 on a desktop - with Intel graphics - with no issues, it is quite a bit better than 4.x in many ways, and quite pleasant to use. $work issues Macbooks, so I haven't run KDE 5 on a laptop, in my previous job I ran KDE4 on my work-issued laptop with radeon graphics and had no issues)
"I'm having fantastic luck with Virtualbox these past few years. I can move images from Linux to Windows to MacOS hosts no problem."
Being required to use a Mac for work at present, Virtualbox (while it's GUI support is a bit better) feels quite limiting and I am missing the flexibility KVM provided, but docker works for some of those use cases (although of course on Linux I would have had all 3 options plus potentially Xen my disposal).
"KVM has some nice properties, but it's Linux-only so who cares? VMWare is your enterprise virtualization anyway."
In my previous job, Red Hat Virtualisation (the commercially supported version of oVirt, which uses KVM) was our "Enterprise Virtualisation", and some NFV environments (provided and supported by network equipment vendors) were Openstack on KVM. RHV can import VMWare images, or copy from a vCenter Server, so "Linux-only" (I assume you mean where KVM can run) is irrelevant. You may want to give oVirt (on CentOS 7 or Debian) a try, if you have 3 spare machines to play with.
"If your company can't afford VMWare, you're probably not being paid well anyway."
My current company doesn't run VMWare, and they pay better than any company I have worked for that does run VMWare...
It sounds like your Thonkpad has some hardware issues, and if you have issues with NetworkManager messing with your KVM bridges, maybe you should opt for training or use a solution made for KVM (e.g. RHV or one of the others) rather than blame the kernel/distro...
"Multihoming. I'd imagine Google provides transit service, but only for their own IP blocks. Each Google datacenter almost certainly has multiple Internet connections to the world. As a result, they have multiple netblocks provided by multiple ISPs."
No, multi-homing doesn't require netblocks from multiple ISPs. Doing this is a hack and only feasible for very trivial networks. A much better approach is BGP multi-homing.
Google (along with thousands of smaller "Enterprise" businesses) have their own autonomous system number(s) and IP allocations, and advertise these IPs to everyone they peer with. Google peers at about 180 internet exchanges, with most retail ISPs. Probably quite soon they won't need to buy transit...
Google fibre is definitely a separate AS from Google (Search, Youtube etc.) AS15169, not sure about GCP.
AS15169 doesn't provide transit, so Verizon could have easily prevented this with just as-path filters (although prefix filters in addition would be better, but may incur more maintenance).
"But today, Linux is pretty much dead to me. Systemd and GNOME 3, among other changes, have effectively ruined it for me. Nothing ruins a Linux user's experience more than having their system not boot fully due to some obscure, and usually stupid, problem involving systemd."
It is interesting that almost all the complaints about systemd seem to be from Debian users.
I use a number of systemd-based distros, from desktops to productiom servers, and have never seen problems like this.
Maybe you shouldn't be blaming systemd and assuming that all Linux users habe these issues, but rather file bug reports with Debian?
"Other vendors have similar, or allow you to run your own manager that the devices contact for provisioning, but Cisco's is all cloud."
I believe it is more correctly "Cisco's Meraki product line is all cloud", as last I checked (granted, that was a year ago) Cisco is still developing, selling and supporting their more traditional Wireless LAN Controller product (that they had since before they aqcuired Meraki) for their AiroNet APs running the "managed" (default these days) version of the firmware. IIRC WLC came in appliance, virtual appliance, and feature licence (depoyable on on some routers) options.
"They're actually worse. In a traditional brick and mortar store, every customer sees the same price on the shelf. But e-Commerce stores like Amazon are increasingly turning to customer analytics to fine tune pricing on a per customer basis."
In my country, many "brick-and-mortar" shops (stores) have moved from paper price labels to smart price labels (yay, IoT), and the vendors selling the solutions have been talking up the ability to do the same thing (with WiFi hotspots or bluetooth beqcons tracking shoppers)...
These days, audio on linux just works (including things like auto-switching an audio stream to a bluetooth headset whrn connected).
I haven't had to fix buggy init scripts in years (only to have them overwritten on upgrade), and unit files provide all customisation options I need (e.g. increasing file limits).
If you have real problems, post links to the bug reports so there can be more eyeballs looking at the problem.
Slashdot Mirror
Why would you put a USB hard drive in /etc/fstab? And if you had a valid reason, why wouldn't you use either the noauto or nofail options?
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration.
You *think* so, but how can you know for sure?
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f /var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
'systemctl status dhcpd' shows me the logs I need to see 95% of the time.
If you don't know what the service name is, or just want to see recent logs or failures, try journalctl -b|tail or journalctl -x.
It really isn't that hard to run journaltcl --help, but these days it seems no-one on slashdot is able to do that, they are only able to use commands that existed in the previous century ...
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not,
Then there is a problem with the service unit file. A common one is not setting the correct Type= value
or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Then the service unit file should have a suitable TimeoutStartSec= specified.
Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwritten on a package upgrade.
And getting anything of value out of the log is a pain in the ass.
Really? 'systemctl' to find failed services, 'systemctl status foo' or 'journalctl -b' to see why services failed are quite easy to use and remember, and will find most boot issues.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons.
It sounds more like the daemons are unreliable, or haven't got useful defaults in their service unit files, but that is very easy for you to fix (copy the original unit shown in 'systemctl status foo' to /etc/systemd/system/foo.service, edit as necessary, run 'systemctl daemon-reload'). See systemd.unit for more info.
Nothing has been gained with systemd, at least not on servers.
My experience so far has been that systemd has saved more time than it has cost, and the 'cost' is a once-off investment, and the savings continue.
A big ol ball? My init.d was about 13 scripts big which were readable and editable.
On what distro was this?
Remember on many systems running sysvinit, you used to have something like rc.sysinit, which was a few thousand lines of shell script written to try and get every possible ordering possible dependencies to get all required filesystems in /etc/fstab mounted. For example, is /var on RAID on local disks? Or is it on LVM on top of local software RAID? Or is it LVM on FC? Or is it LVM on top of LUKS on top of RAID? Or LUKS on LVM on iSCSI? And is /usr on NFS accessed over a tagged VLAN interface? The dependency-based approach systemd takes for this simplifies a lot of things, but can be a bit more confusing when something isn't working.
Ever tried to edit systemd files?
Yes, and it is much easier having a pre-defined, well-documented set of features I can use (like trivially set LimitNOFILE when the distro's package maintainer didn't ever think about supporting this) and be sure that my changes won't be clobbered by a security update.
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Since I started using systemd (which was before the release of RHEL7), the file locations documented in the current systemd.unit man page have worked.
You copy the existing file from /usr/lib/systemd/system to /etc/systemd/system, make any changes you want, and run systemctl daemon-reload. This provides an easy mechanism to ensure that your changes don't get overwritten by a future package upgrade, and it is very easy to see what has been customised, or mass-customise a lot of systems.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Sure, one of my pet peeves is that I don't know why sshd isn't configured with fewer dependencies, but I don't think this is a specific limitation of systemd, but just with people optimising the sshd.service unit file for different use cases (like "don't start sshd until my users with NFS homes can log in", or "don't start sshd until my network-based user-management is accessible because then nscd negative caches my users and they can't log in for an hour).
However, if you want your system to boot when a device is not available, state that (as documented in fstab(5) as 'nofail'. The behaviour systemd has is correct, and avoids systems with non-local filesystems (e.g. boot from iSCSI or boot from SAN) failing to boot due to transient issues when retrying a few times would make it succeed.
According to it's documentation, FreeBSD behaves the same way (thought the option name is different):
If the option ``failok'' is specified, the system will ignore any error
which happens during the mount of that filesystem, which would otherwise
cause the system to drop into single user mode. This option is imple-
mented by the mount(8) command and will not be passed to the kernel.
The best part is how they want to use systemd to save 12 seconds of boot time on my servers that take 5-10 minutes to boot, once every few years.
Boot time reduction wasn't the primary goal of systemd.
The alternative to your servers taking 5-10 minutes to boot, is having them boot incorrectly (like not mount their boot-from-SAN root filesystem because the FC card took too long to log into the fabric after you a power failure to the rack that included the FC switch), and require manual intervention (30 minutes+ additional boot time) to boot correctly.
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
I have seen enough failure modes to agree that this is better.
I can't get out my mom's basement, she never had one, and her house is about an hour's drive from mine.
It's interesting that you are resorting to insults when you got constructive feedback.
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting.
So, it behaves correctly according to the fstab(5)man page from the release before they switched to systemd?
Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your /etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Type= parameter in their service file, in which case the default of simple (which is intended to replace the xinetd behaviour) applies and results in systemd assuming that it should not log stderr from the service's process. In this case, using Type=forking would probably have done what was expected. For example, on one of my systems, ntpd, dhcpd etc. use Type=forking, and they log correctly so that systemctl status dhcpd shows any errors in starting dhcpd.
One nice feature of systemd here is that you don't have to go hunting for log files (and possibly add new rules to your syslog daemon to log the facility in question first) to find the other lines of log files about you need to fix the problem, almost all services now have useful logging easily accessible by default.
If you have other examples where systemd behaves incorrectly (according to documentation of the services/features in question), maybe you could provide them.
Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
So, you were relying on bugs to boot your systems?
I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
I think you are confused.
Here is the service unit file for systemd-timesyncd From this it should be quite apparent that:
1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions.
2)The service doesn't run as root, but as a dedicated user.
3)There is a separate, dedicated service, that can be stopped and started without touching the pid 1.
The same goes for the DNS resolution service/daemon.
I am not aware of any NFS-related service that is built into systemd.
I think you've been reading too much anti-systemd FUD, and believing it.
"We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."
The author states that this is a Linux problem, but only reports using systemd on Debian and Ubuntu, and complains about optional features that are not enabled on "Enterprise" or stable distros.
I have used systemd on a number of distros on a variety of hardware (production bare-metal servers, production VMs, desktops, laptops) and have never experienced the problems the Debian and Ubuntu users complain about here.
All of the "examples" I have seen were obviously due to the user having spent mote time trying to manufacture a bug than reading the very good documentation.
"That's backhoe power. That's why we need net neutrality."
No, that's why the U.S. needs to split "backhoe power" from "internet service" power, by requiring last-mile providers to offer reasonably-priced wholesale products, so that available last-mile provider doesn't dictate only available internet srervice provider.
Then you could regulate internet service less (and let the market address it).
Many other countries have models like this that have wirked well for over a decade ..
"Is this the same Sandvine whose business model included spoofing data packets to discourage bittorrent activity, regardless of whether the content being torrented was legal?"
Sandvine is a network equipment vendor, their business model is to provide technology and services (consulting, support etc.) to ISPs that allow the ISPs to manage the utilisation of their network.
Their products are quite comprehensive and flexible.
For example, their products also support integration with bittorrent caching/acceleration solutions (in some markets this can provide customets faster bitttorrent downloads while saving costs for the ISP).
The business pratice of slowing down torrents would be that of the ISP in question, and if Sandvine didn't offer it, they would have chosen another vendor (Allot, Procera, Cisco etc.).
"Linux isn't really an option, especially with so many distros including systemd. I hate to say this, but I've found Windows 10 to boot more reliably for me than the versions of Debian and Ubuntu that use systemd!"
The only Linux users I see complaining about systemd are Debian and/or Ubuntu users, and with issues I haven't seen and in some cases tried to reproduce and couldn't.
Have you tried one of the other distros that uses systemd? Fedora, SUSE, Arch, Mageia etc.?
"Make no mistake, the extension is going on right now. Linux isn't getting .Net Core because Microsoft wants Linux servers to run ASP.Net sites. That's laughable."
Oh, so SQL Server 2016 for Linux is actually intended for Android? Thanks, now I won't even consider it ...
The Ubuntu kernel for AWS also includes the ENA (Elastic Network Adapter) driver (source code: https://github.com/amzn/amzn-d...), which allows you to get 20Gbps networking on certain instance types (https://aws.amazon.com/about-aws/whats-new/2016/06/introducing-elastic-network-adapter-ena-the-next-generation-network-interface-for-ec2-instances/).
I believe RHEL 7.4 also added the ENA driver, and the Amazon Linux image has it of course.
"With VISA, a bank basically tells VISA you have the money or credit, but if you don't, they simply give you a negative balance and the merchant is guaranteed to get the money."
That would depend on how the bank has implemented authorisation processing. Maybe U.S. banks aren't able to do real-time accurate authorisations, but that isn't a limitation in Visa/Mastercard's side. My bank seems to do it real-time. For example I recently had a transaction declined (while filling up at a gas/petrol station), Itransferred sufficient funds from my phone, and re-tried the transaction and it succeeded immediately, less than 2 minutes after the first attempt. In this case it was a MasterCard card.
"It's very evident when you do overseas transactions, even transaction holds, which show up in a matter of seconds/minutes in the US won't show up on your card for days"
We get text/SMS notifucations of any credit card activity. I paid my hotel bill by Visa card lst time I travelled overseas (a few years ago), and received a text from by bank (including an accurate balance of available credit on the card) before the credit card machine printed the receipt. I think that was a Visa card.
So, it seems the capability is there (on both major card networks), but the U.S. banks lag even the banks in African countries in the implementations of their side of the authorisation (like they also seem to do with 3D-secure/VerifiedByVisa for card-not-present transactions).
The bug you linked to (Bug 35622 - misrenders http://www.angryflower.com/) was opened in 2001 and closed in 2002.
Are you sure that was the right one?
(I happily use KDE 5
8 on a desktop - with Intel graphics - with no issues, it is quite a bit better than 4.x in many ways, and quite pleasant to use. $work issues Macbooks, so I haven't run KDE 5 on a laptop, in my previous job I ran KDE4 on my work-issued laptop with radeon graphics and had no issues)
"I'm having fantastic luck with Virtualbox these past few years. I can move images from Linux to Windows to MacOS hosts no problem."
Being required to use a Mac for work at present, Virtualbox (while it's GUI support is a bit better) feels quite limiting and I am missing the flexibility KVM provided, but docker works for some of those use cases (although of course on Linux I would have had all 3 options plus potentially Xen my disposal).
"KVM has some nice properties, but it's Linux-only so who cares? VMWare is your enterprise virtualization anyway."
In my previous job, Red Hat Virtualisation (the commercially supported version of oVirt, which uses KVM) was our "Enterprise Virtualisation", and some NFV environments (provided and supported by network equipment vendors) were Openstack on KVM. RHV can import VMWare images, or copy from a vCenter Server, so "Linux-only" (I assume you mean where KVM can run) is irrelevant. You may want to give oVirt (on CentOS 7 or Debian) a try, if you have 3 spare machines to play with.
"If your company can't afford VMWare, you're probably not being paid well anyway."
My current company doesn't run VMWare, and they pay better than any company I have worked for that does run VMWare ...
It sounds like your Thonkpad has some hardware issues, and if you have issues with NetworkManager messing with your KVM bridges, maybe you should opt for training or use a solution made for KVM (e.g. RHV or one of the others) rather than blame the kernel/distro ...
"Multihoming. I'd imagine Google provides transit service, but only for their own IP blocks. Each Google datacenter almost certainly has multiple Internet connections to the world. As a result, they have multiple netblocks provided by multiple ISPs."
No, multi-homing doesn't require netblocks from multiple ISPs. Doing this is a hack and only feasible for very trivial networks. A much better approach is BGP multi-homing.
Google (along with thousands of smaller "Enterprise" businesses) have their own autonomous system number(s) and IP allocations, and advertise these IPs to everyone they peer with. Google peers at about 180 internet exchanges, with most retail ISPs. Probably quite soon they won't need to buy transit ...
Google fibre is definitely a separate AS from Google (Search, Youtube etc.) AS15169, not sure about GCP.
AS15169 doesn't provide transit, so Verizon could have easily prevented this with just as-path filters (although prefix filters in addition would be better, but may incur more maintenance).
"But today, Linux is pretty much dead to me. Systemd and GNOME 3, among other changes, have effectively ruined it for me. Nothing ruins a Linux user's experience more than having their system not boot fully due to some obscure, and usually stupid, problem involving systemd."
It is interesting that almost all the complaints about systemd seem to be from Debian users.
I use a number of systemd-based distros, from desktops to productiom servers, and have never seen problems like this.
Maybe you shouldn't be blaming systemd and assuming that all Linux users habe these issues, but rather file bug reports with Debian?
"Other vendors have similar, or allow you to run your own manager that the devices contact for provisioning, but Cisco's is all cloud."
I believe it is more correctly "Cisco's Meraki product line is all cloud", as last I checked (granted, that was a year ago) Cisco is still developing, selling and supporting their more traditional Wireless LAN Controller product (that they had since before they aqcuired Meraki) for their AiroNet APs running the "managed" (default these days) version of the firmware. IIRC WLC came in appliance, virtual appliance, and feature licence (depoyable on on some routers) options.
"They're actually worse. In a traditional brick and mortar store, every customer sees the same price on the shelf. But e-Commerce stores like Amazon are increasingly turning to customer analytics to fine tune pricing on a per customer basis."
In my country, many "brick-and-mortar" shops (stores) have moved from paper price labels to smart price labels (yay, IoT), and the vendors selling the solutions have been talking up the ability to do the same thing (with WiFi hotspots or bluetooth beqcons tracking shoppers) ...
If OpenBSD wasn't vulnerable, why did they issue a patch:
https://ftp.openbsd.org/pub/Op...
?
These days, audio on linux just works (including things like auto-switching an audio stream to a bluetooth headset whrn connected).
I haven't had to fix buggy init scripts in years (only to have them overwritten on upgrade), and unit files provide all customisation options I need (e.g. increasing file limits).
If you have real problems, post links to the bug reports so there can be more eyeballs looking at the problem.