Because of reasons that could lead to a very bad PR nightmare for FTDI if they attack unwitting consumers vs. taking counterfeiters more head on. You know, maybe instead of immediately bricking the entire system, how about being nice to their cash-flow by popping up an alert for the user to contact the manufacturer of their motherboard about a counterfeit part and letting them know that full functionality is not supported by FTDI as opposed to outright destroying the device?

Except there's a difference between this and your example. When you update your BIOS there are ways to verify that the BIOS you have is compatible with the update you are going to use. With this FTDI crap, if you physically examine the chip, it has all the markings of a legit FTDI chip, down to the model stamp. When you look at the chip driver in Windows before the update, it reports back chip information for a chip that's legitimate. Upon verifying these things, you go ahead and run Windows Update with the new FTDI driver... OOPS! Your chip was misrepresenting itself to you and now you have bricked hardware. If you're lucky, your hardware vendor will supply you with a new board under warranty, and hopefully they've verified that the chip is truly legit. If not...you're screwed and FTDI just broke an otherwise perfectly working system that was paid for legally in good faith (that last bit is the important part when contemplating a lawsuit and who to go after; hint: same considerations for a BIOS update that goes awry because it misrepresented itself to the user/system prior to flashing).

The fact that this is an automatic Windows Update that can potentially brick a system without warning (thinking of the non-tech-savvy here), this can make for a very bad nightmare on FTDI's end. I wouldn't be surprised to hear something coming out of the FTC about this before long.

Don't get me wrong, it's not always reliable as it depends on the municipality or county to draw the lines and how long to make them, and better funded means better adherence to the guideline, but generally that is what can be found in Georgia, especially on more well traveled thoroughfares; and yes, their primary purpose is to discourage lane changes in the junction. The lines however are visibly longer the higher the speed limits of the roadway, and in most intersections applying the brakes just outside the bounds of the solid line will allow the vehicle to come to a nice easy stop at the stop line without much of any inertial throwback.

Travel on a US Highway in Georgia out between the towns (generally 30 - 60 miles between each). It's not uncommon where you have two major US or State Highways cross (not interstates) with a traffic light where the speed limits are 55 - 65 mph. As I stated somewhere above, the white lines that divide the lanes will go from dashed to solid at a point where if you're within the solid white lines while traveling within 5 mph of the speed limit, and the light turns yellow, the light should be timed properly that your vehicle can make it all the way through the intersection before the light turns red. Understand that this is for your average passenger vehicle. Busses, RV's and Semi's need to take special care and gauge their own safe stopping distance. These guidelines were written into State Law, and I've yet to see any small town communities violate this, since the State Department of Public Safety (DPS) is known to perform spot checks and actually fine the municipalities in violation.

Speed traps are a whole different story. Yes there are requirements in State Law dictating officer visibility, the use of speed detection equipment including the old two posts and a stopwatch method, minimum speed violation before a municipality can write a ticket (no less than 10 mph above the limit, and since equipment is rated to an accuracy of +/-1, reasonable doubt gives a total 11 mph buffer [State Patrol has no such limit, only County, Municipal, and Private officers]) as well as minimum notice between speed limit changes. However a lot of smaller communities can operate outside of these laws without being detected for quite a while, but woe to them if they're ever caught by DPS through court challenge of a ticket (often requiring appeal to the State system after losing in the local court, which would prompt investigation) or by State Patrol/Department of Drivers Services witnessing a violation. Communities can be fined by the State, lose their license to operate speed detection altogether, or, in some extreme cases of municpal corruption, have lost their ability to operate their own police departments for several years, having policing measures being taken over directly by the State Patrol (A division of DPS) in the interim.

I can't speak for everywhere, but many of the towns in Georgia the solid white lines that divide lanes before a stop light (as opposed to the normal white dashed lane dividing lines) are generally painted to a length where if you're outside of this region when the light turns yellow and you're travelling the speed limit you will need to stop. If you're inside the region of the solid line at the start of the yellow, you should have enough time to get through the intersection safely before the light changes (note I did not say get past the stop line, but through the entire intersection. It is illegal to be under the light when it turns red in Georgia, unless road conditions required it, which is difficult to prove.) Obviously if your speed is above or below the speed limit the safe distance is proportionately longer or shorter, respectively.

Um...you apparently missed the context of the parent completely. You even quoted the parent, called him wrong, then made the focus of your statement a point that agreed specifically with the part of the parent that you quoted; and all through that you completely did not show how the statement you quoted was in any way wrong.

The main focus of the parent that he showed examples of is on the sentence "They care about branding and image." Your rebuttal included the list of things that people use a computer to accomplish:

All of those things can be done on Windows, Linux, or Mac OS X. Which one a person uses is based completely on branding or image. The parent went into what most users would use based on their perceptions of specific brands. Most users would use MS Windows because that is "Normal" and "Conforms" to what they believe they should be using based on the requirements on the side of the box of the software they want to use for whatever they want to do. The ones who would use Mac OS tend to be the "hipster" type that want to appear different and call themselves superior to those who use Windows, even though they need to do all about the same things as their Windows brethren. The Linux/BSD crowd tend to be more independent thinkers than the above two, though they very well fall into conforming with themselves (for example, those who say "I use Debian. Yes it's Linux, but you'd never catch me dead using Gentoo." and vice versa.) These too will also get the tools to do all of the above functions from their package manager of choice, and have the heart and fearlessness to perhaps tinker with software under the hood

Your post did not make any claim that refutes any of these points that the parent made and I have outlined... therefore you did not prove how you thought he was wrong in his statement that you quoted.

On my servers, the current business week is in plain text and not compressed and archived until 11pm Sunday night for the next week. I keep a month's worth of archived logs. Now here's why: If a system goes down for some reason, the only logs that are going to have anything immediately useful are going to be the uncompressed ones that can easily be cat dumped or vi'd for initial troubleshooting. You're most likely going to need only the last few lines of the log just to find out what went wrong. If troubleshooting is greater than that and you find a longer history of problems that culminated in the panic, any liveCD distro will have the tools necessary to crack open your archives.

Binary log systems are a Disaster Recovery nightmare. The only reason you have a log system is that something went wrong and you need to do some form of troubleshooting/recovery. If your core system is still working fine and the native systemd is able to read the binary, great. What happens when a system partition crashes and won't boot back up? Please enlighten me on how a binary log file can be read on a system that won't boot itself? Can any liveCD using a systemd based distro read the binary file and translate it to a human readable format? Also, it's been said that using a config file, the journal system of systemd can write to a plaintext file. Please explain how that works? Using the config file, does the journal system completely turn off and each component individually writes to syslog, generating their own log file or adding to one of the already created pertinent log files, as it does with System V? Or, does each program send it's message to the journal system and it's this system that sends a message to syslog to write? If it's this latter case, what happens if during a system panic the journal system corrupts the data being written? What if the journal system itself craps out in a failure?

These are all questions that I legitimately do not have an answer to yet, and I haven't had time to research into it. Before I consider updating my systems to a systemd based distribution these questions MUST be answered satisfactorily, and it will be as I draw closer to that point that I will be making time to research it. I don't have time for FUD, fanboyisms, or anything else as such from either side. I have specific requirements that must be completely answered. If the answers are not forthcoming, I, and many many many sysadmins like me, will be keeping System V init systems on my servers by whatever means necessary.