Nope. None of those companies were telecommunication providers.

Similar rules have always been in place, it's just that the rules have only applied to the telecom provider. ISPs today are both the telecom company, the internet provider, and in many cases also a content source. Prior to about 2005 your ISP was just the internet provider - other companies did the telecommunications and still others provided content. The telecom companies have always been regulated by Title II, this regulation is "new" for the vertically integrated ISPs...who are undoubtedly providing a telecommunications service in addition to being an internet provider.

"30+ years without "net neutrality" regulations, 2 years with" - bzzzzzzt. Wrong.

For the 1990's to mid 2000's ISPs and telecoms were typically separate entities. Telecom access was dialup or DSL - both regulated by Title II. Since the ISPs weren't in the telecom business they didn't require regulation - they had no reason to block/throttle based on service/source/destination/whatever.

From then until 2014 various FCC rules and regulations (including the "Open Internet Order") governed ISPs. In 2014 Verizon "ruined it for everyone" by challenging the OIO and taking the FCC to court. They won, but the judge suggested that if the FCC was going to police ISPs it would have to classify them as common carriers. So the FCC did.

Most "software engineers" are not engineers. I also agree that programmers are also not engineers.

Many people (even those with the title "software engineer") believe that there are no software engineers....but they are wrong.
I work in the avionics industry, and regularly engineer software that runs on the aircraft's primary flight display. I can't compare the rigor of SW engineering to civil engineering, but I can compare it to electrical engineering (I work closely with teams of systems and electrical engineers). From an aviation certification perspective, software engineering is at least as rigorous as electrical engineering.

Actual software engineering (at least from my experience) is about 10% "writing source code". That 10% includes reviewing source code that others have written. I would guess that about 40% of effort is spent in iterations of requirements capture and generating designs, and the final 50% is testing. Designs includes things like "requirement says X action must occur no later than 4 ms after Y event is detected, and since the scheduler runs at 100 Hz we cannot use a thread to invoke the action - so the action must be called from the thread/task that detects the event". Unlike typical "cowboy programming", there is a lot of focus on minimum performance in worst case conditions, error handling, hardware fault detection etc. Testing includes the standard "requirement says transmit X packet when Y condition is met, so induce Y and check for X" to "manually verify that compiler generated the expected object code given the source code". Additionally, for the highest safety levels (think large commercial passenger aircraft) every line of code will be executed during test, every possible branch will be taken during test, and all "truth tables" will be fully exercised during test. Google DO-178C MCDC

The final software produced is of exceptional quality (obviously) and is written in C or Ada (no OO, no interpreted languages). If the system will use an OS (many don't - some are runtime executables instead of applications) it won't be Windows Embedded or Linux. It would be a certified OS (Integrity-178, LynxOS-178, or VxWorks Cert).

One final observation - there are basically no hipsters where I work. It's pretty much all 30-50 year old men, dress shirts and slacks.

I've been thinking this for years!

I think all new politicians should be issued a body camera the day they swear in, and the camera also functions as an RSA-token like authentication mechanism for email, access to state offices, official phone use, etc. No camera, no access for official dealings. Additionally, the camera has no power switch.

This way everything they do is "on the record", and the camera is downloaded daily to some webserver for the citizenry to access.

No more doge memes in China!

Such superlative. Best rights. Wow.

I'm pretty sure 78 will still go through RCOH...but again, that doesn't matter. It's make-up water and manual alignment of the tanks that is the limiting factor.

Most of the US Navy's nuclear ships are setup to be refueled at least once in the expected lifetime...but that's not the main thing here. The steam plants on these ships leak (clean, not radioactive) water/steam when they operate. So much so that they have built-in make-up systems to replace the lost water. Eventually the tanks that store the make-up water will run dry, and new tanks must be placed in service. Doing this is a manual operation - sailors turning valves.

I don't know how often this must be accomplished, but there's no way it's more than a week before it must be done. If it is not done, I'm pretty confident you have less than a day before some alarm/safety system detects low water levels and stops feeding the boilers. After that happens it won't be long (minutes?) before a different safety system shuts down the reactor.

The vendor and support market could be huge too. Think of all the protocol droids that will need to be manufactured just to speak their binary language!

A regular cause of early incandescent bulb death is vibration. I wonder if there is a way that opening/shutting your door or walking on your porch vibrates the light socket? I had the same kind of issue in my basement, walking in the kitchen would vibrate the basement ceiling, and if the lights were on in the basement one might burn out.

I replaced them with CFLs and everything has been good. I put the same kind of CFLs in my garage. The starters all died on them after about 6 months, presumably from either humidity (I live in the US midwest) or maybe it was the cold? Dunno.

Point of the post is that lifetime numbers given by the manufacturer are probably for the "best case" condition for the bulb to live in. I imagine in FL where they get far more lightning than in the US that LED bulbs might have a shorter life.

I've worked with PhDs in a hands-on environment as well (apps/drivers and low-level embedded stuff). Several of them were great, and at least one sucked enough to be let go. One of them (Physics PhD, not Comp Sci) was one of the most talented low-level embedded SW Eng's I've worked with. Sweeping generalizations...

You've got a point there. The summary article on Wikipedia has 21 nations listed as having some kind of Arab spring activity, but only 3 with good-ish outcomes.

Next way-out-there question: The US is pretty tired of middle east involvements right now...but if there was a significant revolt in Iran, would the US jump in? Fund rebels? Deliver arms?

Imagine if 3G (and "4G") was found to somehow be illegal in the US - I think there'd be a revolt. A good enough chunk of the nation expects to get FB updates and cat vids on demand anywhere they go. Maybe Iran is the same? It seems backwards, but I think this is the kind of thing that gets the average person to actually care about something. No cat vids = Arab spring in Iran? Maybe?

Given that the aircraft contains hundreds of thousands of parts, I'd be willing to bet more than just a few "China" parts have slipped in. It's one thing if it's some $10,000 part...but for a handful of $2 magnets (which if we did go to war with China could be found in stockrooms all across the US) who cares. Don't get me wrong - this should be avoided. It happened as an oversight and a waiver was granted. Thats the kind of thing waivers are for. We don't need Uncle Sam spending $100K to replace $2 magnets.

and the MPAA issues a successful DMCA takedown (automated) for something they do not own the rights to....nothing happens.