Nope. Just because Mr Stewart isn't around doesn't mean new updates/reshuffles won't be coming out every year.

First of all.... he's probably already written the plan for next 2 to 3 year's worth of versions of the books

Second of all.... his editor can continue to make minor updates to the book ad infintium.

There is no good business reason for you to have my social security number on your computer to write out my paycheck.

99% of the information in the personnel file is stuff not used but once or twice a year that nobody has any legitimate business looking at.

Yes. Lets air-gap the email system. That would work well.

No, foo. It's called basic common sense -- keeping confidential medical records, SSNs, and personnel files in paper format only, and not allowing them to be scanned or placed in a system connected to the general business intranet, or "the cloud".

Which means the embedded device suddenly needs writable storage and routines for uploading said cert

Which is already needed to record configuration details such as hostname and IP address.

I don't need a certificate on my printer any more than I need auto-locking doors everywhere in my house.

Not using SSL for remote administration b/c you think SSL is weak is more like having an open doorway with no door installed, because you are concerned that intruders can just kick in the door.

Learn a little bit, you should notice most people do have locking doors outside their house, and they even have many privacy doors inside their house, many people have a deadbolt on their bedroom door as well, and these are useful home security mitigations when it comes to discouraging potential intruders and helping to protect homeowners.

You have to be horribly ignorant to trust that none of the CAs in your browser's or OS' key store have been compromised, or handed out to someone.

The primary purpose of SSL is to contend with passive sniffers. This is a much higher bar for the attacker. There are many potential attackers to whom gaining access to a compromised CA key or compromising DNSSEC is not even a possible option.

These are embedded devices.

You install the patch or firmware update from your appliance vendor to address the insecure transport security vulnerability (Failure to utilize secure protocols such as SSH or HTTPS over Telnet/HTTP for administrative connections; transmission of usernames and passwords in cleartext withotu encryption).

And Comcast has to be careful how it fights them or it can lad itself in trouble in ALL of it's other markets.

There is one simple way Comcast can fight them.... deliver a better service with better support at lower cost to the consumer, and do it in a way that makes the customers happier and more excited about their service than Tucows.

It does mean Comcast has to probably offer the 1 Gigabit or better service at a lower price than what Tucows is rolling out.

If Comcast uses any other method to fight them, then Comcast deserves to be more tightly regulated.

Of course if Comcast actually gets competitive and causes Tucows to fail fair and square, then once there is no effective competition once again, Comcast could raise their prices or take other new actions as a result of becoming a monopoly ---- in that case, I would expect the regulators to tighten their reigns heavily and create a cap on Comcasts' revenue and requirements similar to the Telco regulations requiring the phone companies to build-out and service all customers (no cherrypicking high-revenue customers; no excluding the "Top or Bottom 2% of users" who have been deemed unprofitable customers).

What is more, these cabbies should have their licenses threatened. A cab license is not a right.

Yes.... being a taxi gives you no right to obstruct usage of the roadways.

They should dispatch police to detain the offenders, and tow trucks to seize all the vehicles involved and impound them for at least 15 days.

Furthermore, their taxi license and their driver's license should be suspended until they pay costs of towing, storage, and a $1000 fine.

Most companies choose b) as their core business is not in the design of their own server equipment and they don't have the resources to do a).

This is somewhat of a false dilemma. There are very few companies in (a) who are willing to invest in resources to a truly thorough engineering job designing their own customized applications and servers for basic business needs, and there are plenty of companies who are in (b) which do not have the resources to design their own applications, let alone server equipment.

There are nevertheless numerous companies in (b) with IT management and staff who would like to at various times treat random projects as if the company were in (a); so Dell didn't spec the equipment with SATA drives, but now that our X application has new servers for it, we'll take this old storage chassis and toss some consumer drives in it. The key message is THAT will probably be a lot less reliable than the storage chassis outfitted with the disk drives that the vendor qualified, and what's more, even if the storage chassis doesn't do a firmware check on the drives to try and reject 3rd party drives to protect the customer from themselves; it is still likely to be completely unsupported by Dell when it eventually fails catastrophically.

And yet some of those companies have published individual drive data showing the exact reliability.

Yes, and they have a specific measurement of reliability and performance that applies to their environment, but not to most of mine or that of most enterprises. A hard drive has a reliability issue if it causes the storage system it is used in to fail; even if the hard drive itself is performing perfectly. Component failure is not the only reliability issue, so are bugs and unexpected behaviors.

In their environment; Backblaze would be concerned if a hard drive fails completely and stops reading or writing data with integrity while not idle, and a read/write test of the hard drive surface would fail, this would be how they define hard drive reliability: since they don't consider a hard drive to have failed if the entire disk can still be read or written.

In my environment I am concerned if a hard drive does anything or fails to do anything that causes it to be ejected from the RAID subsystem, or falls below a performance threshold, or accumulates bit rot, or causes a failure in the firmware-based health monitoring on the drive or in the storage chassis.

If a hard drive power cycles or resets itself just once unexpectedly and therefore shows up as "Ejected" or "Failed"; then I consider the drive to be unreliable, even though it would not meet Backblaze or Google definition of an unreliable or failed component, they would simply keep using it, as long as the drive continued to pass their tests.

No. Go look at an upper mid-sized enterprise, and ask what kind of hardware they have running their Microsoft SQL Servers, their Exchange server, or their Oracle cluster.

What Google, Facebook, and Yahoo are doing is not relevant at the enterprise level. These are super-colossal cloud-scale companies, that are 3 orders of magnitude larger than Enterprise computing, not ordinary enterprises.

Enterprise hard drives are designed for Enterprise use, not Google or Facebook's cloud or HPC clusters.

These massive companies also have their own custom hardware built at their disposal. They are not using RAID arrays like most enterprises are using, and they essentially have massive farms of workstations instead of servers running their computational workloads.

At sufficient scale, you can achieve reliability from consumer disk drives for in-house applications, by designing your application around your components, BUT the major requirement is that you are in control of the application stack, so you can actually use the disk drives like you want --- and not have to stick them in a tightly-coupled RAID array.

The consumer disk drives are not sufficiently unusable that you can't work around the limitations by having thousands of them in a cluster, with terabytes of cache spread over 5000 computers, and some smart application logic doing what ordinary RAID subsystems cannot.

There is no difference in reliability between "enterprise" and "consumer" drives. Those are purely marketing terms

The statement you have made is an overly broad genralization.

There are a multitude of differences between the average consumer drive and the average enterprise disk drive, which affect operational reliability of the drive in various scenarios.

For a consumer drive; the reliability has to be measured as correct operation of a single disk drive in a consumer workstation.

For an enterprise drive; the reliability has to be measured as correct operation within a larger storage subsystem, such as a hardware RAID environment, or a disk drive shelf being utilized by a Software or RAID subsystem e.g. Equallogic PS5xxx, Netapp FAS array.

One of the most important differences is the on-disk format and metadata.

Secondly, different types of disk drives have different proprietary firmwares, so they have different reliability footprints when in operational use in different scenarios.

Consumer disk drives cannot be substituted in while retaining the same level of reliability. Just like Enterprise disk drives cannot be substituted into a workstation while retaining the same level of reliability for that application.

Why would the interface change the reliability of the HDD?

Because a SAS drive is not identical to a SATA drive with a different interface attached.

That's not the message. The message is: that some security problems can be solved technically, but the solution is so problematic, that the solution can't reasonably be accepted.

The major problem with RPKI is the legalese, and the fact that operators have some reasons not to trust the RIRs to administer it.

We see some of the matters of policy as self-serving. We recognize that RIRs are not infallible, and we're concerned about giving a single organization too much power over the community-operated internet.

Yes, ARIN and other RIRs are in control of WHOIS and the official record, which are only of value due to the consensus recognizing them, but us operators remain effective control of the operational internet.

If ARIN craziness results in an IP address allocation being revoked for insane reasons, such as registrant forgot to pay a bill, well, their network just keeps working --- since the RIR has no power to stop a working network.

RPKI changes this.

Also, since IPv6 makes RIRs such as ARIN a lot less relevant, we are concerned about their "rent seeking" behavior from operators, not just today, but in the future, and possible exorbitant price increases to discourage IPv4 usage and promote "outreach programs" and conferences and parties and other excess spending of questionable relevance to resource holders.

No ARIN-administered RPKI keeps the power more in balance --- today the network operators have a "check" on ARIN's power, by simply ignoring resource revokations and refusing to disrupt network(s) ARIN says to disrupt.

These events continue, despite the ability to detect and prevent improper route origination

Locked cases with hardened glass are a technology that allow a store to protect products for sale from surreptitious pilfering. That is, assuming you can fit the products in the case. Lock manufacturers for the cases require stores to accept something called a "key security agreement", but the shop owner community seems unhappy with the inconvenience posed to customers, and is choosing not to implement it, just to avoid the KSA, leaving the goods on store shelves worldwide as a whole less secure.

I'm referring to taking people into custody under suspicion or with charges who were at the scene recording the officer.

If an officer beats / tazes someone, and evidence establishes there is no real justification for it and force was excessive and unwarranted, then the officer should be suspended without pay, and the victim given the opportunity to press charges and have the officer answer to them in court.

And get new ones. What's so difficult about that?

In general I agree with this, but first the officers should be given additional mandatory training to be completed within a short period of time.

If an officer fails to complete the training, they should be suspended until they do. If an officer does it after being trained appropriately about the new directive, then they should be penalized.