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.

So what were their titles, and where can I get a copy of the content?

Digital Watches, which are a pretty neat idea, were using ASICs in the 70's.

Yes; however, these were a different kind of ASIC. The kind of ASIC you would find in a watch is not performing a complex computational task by current standards.

You will also find certain ASICs in modern computers and servers which are part of the chipset.

When we are concerned about the difference between an ASIC-based forwarding architecture; we are primarily interested in tasks which cannot be executed efficiently at the same capacity on a general purpose FPGA or microprocessor, not the number of units which are being manufactured.

It turns out there are multiple different reasons ASICs become more cost-effective; when you would need a ton more general purpose processor wiring and power consumption to accomplish the same job that a well-designed application-specific processor constructed from ASICs could be more well-suited than a general purpose system using a generic computer board to complete the task, or a bunch of generic FPGAs and ICs glued together and programmed to do it in software.

considering they can easily take up less than a tenth of a square foot, plugging that into the average square-foot rate for real estate in the area where the customer lives would probably only amount to perhaps a only a few additional pennies per month.

You are referencing wrong rates; you are referencing residential real-estate rates, but Comcast is using the real-estate for a commercial purpose, and when you rent out a small bit of real-estate for a commercial purpose, the expected rates are higher than personal usage. Lookup colocation rates for 1U of rackspace in low-tier data centers. Comcast is colocating a modem, which is comparable to colocating a 1U router. Obviously, you don't expect them to pay for delivering a service to you, but if they are using their colocation to generate revenue by taking advantage of the prime location of your property to deliver revenue-generating services outside your customer relationship, then you are entitled to a share of the extra revenue that placement on your property is used to generate independent of their usage to deliver your service.

For example, to declare even a *portion* of your rent or mortgage as a business expense in a home business you have to actually almost *exclusively* dedicate some square footage of your home, such as a den or what have you, to that business, and not use it for any personal purposes

This is only true if you are both the owner of the home and the owner of the business. And it is nothing more than a rule designed to prevent self-dealing on your taxes where you claim some rent to be a business expense without actually sacrificing anything to the business. The IRS rules also have some differences from the actual law, and you could challenge them.

Since the 2nd modem is virtualized, it should not affect your transfer rates or bandwidth quotas.

WiFi can be fairly CPU intensive, and it can interfere with your own emitters.

This kind of interference is much more a problem than a neighbor's WiFi, as WiFi is low powered unlicensed emission, therefore a little bit of distance and walls tend to reduce the noise; this can increase the noise, resulting in worse throughput for wireless LAN clients in your home.

Unless there's a vulnerability in the router (which is possible)

Possible? It is almost certain. We just don't have the details yet.

Do you have a solution that doesn't require caller ID service?

ATT wants an arm and a leg to have caller ID svc.

why would there still be an additional public IP on the modem?

Just because your service is being bridged, doesn't necessarily mean that the modem isn't acting as a router for other services.

It can also be assigned an additional public IP outside the forwarding plane for your service for management purposes.

Plenty of reasons for a device made to act as a bridge to still have an IP. Also, seeing as its DOCSIS, the additional IP it has if any can be completely discrete and not discoverable by the subscriber of the bridged service