Surprisingly little for an entire OS ecosystem (those bugs include packaged software). I wish there were only 3k bugs and minor annoyances on other platforms.

Win10 boot is plenty slow through either BIOS or UEFI. The trick it does with UEFI however is keeping the UEFI boot screen active while booting the entire OS. On a brand new 32-core Intel Xeon machine with NVM SSD and 64GB RAM it takes about 30-45s to get to the login screen after UEFI has handed over control. That's slow. In comparison, Fedora with SELinux and systemd takes ~5-10s

Not just Microsoft which is one thing but it advertises itself aggressively on the network, similarly discovery and pulls in a lot of data from 'apps' and 'tiles'

European countries have the same spectrum 'tax'. The issue is that the governments here don't promote competition. Fines and even spectrum should be a function of a companies income or net worth. That way a startup can compete to get spectrum. Also, European countries make spectrum and sometimes even customers non-transferable so you can't buy out a competitor that provides better service.

Transfer doesn't cost money, bandwidth does. So free transfer is indeed possible because the infrastructure has to run regardless of how many bits you send in a month.

Oh please, the government isn't putting nearly as much criminals away as necessary. If we had a bit harder punishments for actual crimes and less 'soft' punishments (rap sheets that follow you for the rest of your life), we wouldn't have nearly as much problems. These days the courts and prisons are simply a revolving door that create better criminals while locking away civilians that need help and/or made a simple mistake. You get more time in prison for drinking a bit too much and walking in the street than vandalizing someone's property (which police won't even come out for)

Early 3G was ~200kbps, only double of what the 2G standard could do (128kbps). Back when 1G/2G was available, ~56/128kbps was maintained on the network. The current average for 3G/4G across carriers is 0.5Mbps and 1.5Mbps respectively. It's hard to find actual historical data because after the iPhone, the marketing drones started redefining bandwidth as the amount of GB (the amount of transit, not the amount of bandwidth) you were allowed per month.

Also, 20Gbps seems to be an aggregate of all connections in a given geographical area. It is just the amount of bandwidth the radio waves make available before all the demux and filtering has been done. No way in hell, anyone in the US is going to outfit a cell tower with a 1Gbps connection, let alone 10 or 20.

100kbps before you're throttled, 9600bps afterwards?

You forgot to include the yearly $400 for Adobe so that they can create PDF's of said screenshots and Word documents so people with other versions or missing fonts can also see the Outlook e-mail.

Why would you need MS Office to communicate with others. That's what we have e-mail and phones and a number of other tools for. Using a Word document to communicate something generally gets ignored. Also, most people have evolved to be able to use more than just MSOffice, they can use LibreOffice, Google Docs etc. If your HR drones fail to recognize the technological process since 2000, their performance needs reviewing.

Pick one, make sure your systems run against it. If you always use NTP sourced data, you cannot assume your GPS sourced data (or local nuclear clock data) will give you the same results.

You can never assume that time will not change due to external factors. That could be due to a sysadmin executing the 'ntpdate' command, leap years, leap seconds or even daylight savings.

You're talking mainly about human representations of time though and although the conversion should be handled delicately, they should not be used for internal time representations (a major mistake I see very often is to handle/parse hh:mm:ss strings back and forth between a model and a controller).

The testcase however is one that does need handling though if you do require such reliance on time. It may not be simple but yes, it is possible to fake the clock (ntpdsim). External (live/production) data within a test environment is likewise a 'bad thing', you most likely will not handle outliers if you assume the current external data includes improper data.

Most, if not all of them. Unix time is leap second-ignorant and there are a number of other time sources that likewise handle leap seconds. If you do for some reason, require solar seconds or GPS time, there are other solutions for that. Most likely though, it's your platform that needs to handle the leap seconds and Linux, Mac, BSD, Solaris is more than capable of that, don't know about Windows or other esoteric systems though.

The issue is in human date/time representations and/or bad programming. I've seen many times programmers parsing a MM-DD-YYYY HH:mm:ss string rather than a proper timestamp. I've also seen programmers implement timers even in lower-level languages like C by simply subtracting "$current time" - "$past time" or having a timestamp with a "unique" requirement. If you've ever worked on platforms that do not keep accurate track of time or have no hardware clock such as embedded devices, virtual servers etc, then you know that it's a bad idea.

If you're relying on mm:ss to progress 'properly' during these time events, then you're in trouble. The article gives the example of timers as well which just gives me the heebie-jeebies.

Slow news day? Software dependent on accurate timing should be able to handle such exceptions such as leap seconds, leap years etc. It is a simple test case and is well documented. So if your software fails, you have a bug in your software, which shows you either didn't test or you're simply incompetent.

Also, most if not all languages have libraries that can handle accurate timing very well.