"but they have a virtual monopoly around here."
I envy you... where I live, in Los Angeles, they have an *actual* monopoly on high speed service.

Can I get Verizon here? No. (Not in a Verizon area.)
Can I get AT&T U-Verse service here? No. (Not available in my area.)
Can I get any other cable company service? No. (Local monopoly.)

It's TWC or nothing.

For the record I'm not "demanding" their top tiers because their pricing is ridiculous, not because I don't want it.

Every extra point of contact adds significant rolling (or sliding) friction.
It's perfectly plausible that the energy cost of a ludicrous mechanism to minimize points of contact could end up more efficient than the straightforward solution of "more wheels".

That said, I'm skeptical of the big single flywheel working out well, since it seems like it would have a crazy effect on the handling (like old rotary biplanes, which could turn tighter in one direction because of the gyroscopic effect of the engine on the plane.)

I'm usually big on trying new things, but I think I've been in Gnome-land a little too long now (ever since I gave up FWVM) for that too work out well.
Plus they borrowed a little too much from CDE, which I loathe with the burning passion of a thousand suns.

There is pretty much zero chance than my college project ended up in any consumer device, unless my advisor was seriously more evil and manipulative than I have been led to believe. I went into systems admin and most of the "hard" EE is a pleasant memory.

I recently moved from Fedora to Ubuntu because I'm trying to do more dev work and -all- the development tools and library releases these days seem to be more Ubuntu-friendly.

I was more Fedora-friendly because I came from a RedHat admin background, but I kept running into more and more projects/games/libraries that interpreted "LInux support" to mean Ubuntu, so I gave in. Since then it's actually worked out pretty well, although I still prefer yum to apt-get...

Hah!

This is why my EE Senior project (long, long ago) was an inline box that would translate rotary pulses to DTMF so that you could use your cool old phones with modern systems. The trick was in the loop isolation, so voice could get passed through but not the dial breaks which modern systems interpreted as hanging up.

If I was doing it today, I'd make a rotary phone to VoiP converter instead. Actually an easier project, all things considered...

Of course, while this was long ago, it wasn't the 70s, so they still wouldn't have my device available.

You know the material of the shield doesn't matter, when someone suggests it as a possibility.

"...the winter in temperate climates due to artificial heating."

Is anyone else missing the lower humidity we generally have in the winter -outside- in temperate climates due to it, you know, being cold?

If I'm concerned about the data, I either encrypt it before transmitting or encrypt the pipe, both things you SHOULD BE DOING ANYWAY, regardless of who owns the last mile that happens to connect to your house/business.

Yeah, it still might not stop the NSA, but Google is NOT the NSA.

Post++.
Whatever cool things you may do are infinitely less /. worthy than SHARING them in an entertaining, useful, and inspiring fashion.

It's fallout from the recent idiotic Supreme Court decisions, to wit:
1) Corporations and "groups" deserve the same free speech rights as actual human beings.
2) How you spend money politically is "speech".

Go back and seriously re-assess either one of those and we're 90% on the way back to sanity.

As long as your system uses milliseconds since the epoch internally, daylight savings (and leap years, and leap seconds) are all simple problems of translation for human-readable display and will not effect functionality.

It's the difference between what we "call" a particular point in time and how much time has physically elapsed.

That said, I'm completely not sure how to properly deal with computers in highly accelerated reference frames who will have experienced a different quantity of elapsed time than their stationary compatriots...

I found an "amusing" bug in a software deployment system recently that will break horribly on Jan 1, 2022. (Much sooner than the usually announced doom-dates of 2038 and such).
It's a fairly simple cock-up, so I wouldn't be surprised to find it elsewhere.

Step 1: Make decisions based on a datestamp.
Step 2: Define that datestamp as "YYMMddHHmm".
Step 3: Somewhere along the line, shove that string into a 32bit signed integer.

The maximum value we can store is thus "2147483647", so the "2201010000" of Jan 1, 2022 will overflow to a negative value. Hooray!

Completely stupid. Completely avoidable. Using the standard "milliseconds since the epoch" we're still only at "181825596", and would have made it all the way into 2038 before running into a similar failure. My only solace is that we'll have abandoned this particular software by then. YOU may not be so lucky...

There's a hard upper bound on "expensive" organs (those that require more energy to function) based on the amount of energy a creature can consume and process.

Some creatures (like cows) spend more on having a larger and more efficient digestive tract so that they can extract more nutrition and energy from a simple diet.
Others (bears, us) spent more on this thinking organ so that we can selectively pick out more energy-dense foods to eat and get by with a simpler digestive system.

In any case, if you're an animal with an average caloric intake of 2000 kcal/day, you can't sustain 500kcal/day of muscle, 1000 kcal/day of brain, AND 1000 kcal/day of digestive system. The totals need to add up - or you die. So yeah, I guess you COULD select for a big brain and big guts, but you still need to give up something else somewhere...

[Repost due to expired login.]

HAhahahahahahahahahahhahahaah....

Ow, my sides.