This is pretty much the way I see it, working in the field. On the "pro-net-neutrality" side there are those with reasonable views on balancing common carriage with legitimate needs for priority, some with a basic level of network literacy with a wide range of conflicting specific suggestions who don't usually understand the consequences of what they are asking for, and a whole lot of people who don't even understand what it is they are asking for and prefer to converse in vague terms and catch phrases. I doubt there are even 3 million Americans who know what "statistical multiplexing" means so how are they supposed to weigh in on the issue.

Being a progressive my peers are generally surprised when I answer :"it depends" when asked whether I support "net neutrality" rather than "yes."

...or run the alternative userspace driver, which linux supports doing as well.

What really should be the question is why can't even Microsoft, which despite their software reputation generally is well reguarded for input accessories, not present a consistent interface across different generations of controllers. It's not like there isn't an enumeration standard they could follow.

Well, if the Microsoft would fix the damn surface so MFP doesn't break it and operators have to disable MFP, and the hotel sets things up right, nothing, just a bit of congestion.

What happens when conventioneers start using MFP? That's the real fun, there.

I work in a university IT department and we never go near those vendor features because of legal concerns. I don't know how the vendors get away with offering them.

I have thousands of hosts on the same L2 network over WiFi. Works fine. Just turn off broadcast/multicast, use proxy ARP, and pinhole/convert the bare essential multicasts/broadcasts to unicast. RF is indeed a big problem with density, which is why stadium setups use directional antenna arrays, but the biggest problem is consumer-grade wifi drivers that lose their s**t if they see too many APs, die horribly in the face of modern roaming assist standards, and if they are even lucky to have a 5GHZ antenna to drive, can't do DFS channels right.

Naw I can still smell just fine.

Actually thermophotovoltaics, like stirling engine collectors, have the advantage that you can use them as a an electricity generator from natural gas at night instead of using a dedicated natural gas plant. Not sure if TFA is a technology that enables that use case, but it has been looked at as a way to combine the installation costs of solar arrays and natgas plants. Also there's been speculation as to whether they can be made into a more efficient way for hybrid cars to burn gas than an ICE.

TFA, though seems like it is more focused on photo-thermo-photovoltaics. No pun intended.

It's actually pretty simple logic:

Either A) there will be an unavoidable "heat death" which no race may survive or B) Some undiscovered aspect of the universe will prevent A)
and Either C) we get off this rock or D) we stay on this rock.

A and C -- we are doomed
A and D -- we are doomed
B and D -- we are doomed
B and C -- chance of survival.

No this is more reasonable than SDN. SDN pretends to be a road to virtualizing the capabilities of actual grunt-work networking equipment, without being arsed to actually be able to enumerate said capabilities and thus is doomed to never fully succeed. This, however, is for the higher level intelligence well suited to virtualization -- basically the stuff thateats all your RSPs' CPU.

Wiring LEDS in series for use with a household voltage makes sense, (as long as you can precisely batch-match the LEDs.) Then you don't have to step down the voltage as much so you can use less expensive and failure-prone electronics and achieve higher efficiency.

That said, given the progress of increasing LED efficiency, it might not be such a bad thing if the early models didn't last so long, because they last so long that by the time they are replaced, they may have burned off more electricity relative to an earlier replacement than the cost of that replacement.

The connotation of "Dashboard" is that it may give you a trendline, but not necessarily be able to pull up trendlines for arbitrary time intervals.

There are of course dashboards that do so, but it is reasonable to argue that those are really dashboard/reporting hybrids.

It sounds like TFA is referring to a dashboard that is fully featured in that department. Few are, even these days.

In any case, if the product doesn't make autodefinition of intervals and side-by-side comparisons as easy for managers as pulling up two PDFs side-by-side from their email or (if they are old school) printouts, then there's a deficiency compared to the traditional reporting solution, despite any advantages in other areas. And, if a dashboard-oriented product cannot present a nice list of autopopulated intervals, then either you need to go the report route, or instead of making reports you'll find yourself logging in every morning to manually create those intervals for the front row.

Also depending on the nature of the data, reports can sometimes be used as supporting documents in legal/business procedings, and so must be presentable in a the form of a document.

Finally when your data gets large enough to become cumersom. the report model starts to make sense in that it schedules DB resources.

Not the only one (nor is systemd entirely desktop driven). Before systemd ate it, DBUS gave us the session bus, and many applications would only ever use the session bus, and could not be used without a login (usually X) session, even if they really didn't need it. In many cases one had to at least recompile and sometimes even hack the source to change it to use the system bus (or disable DBUS support entirely.)

Then there are the various attempts to unify configuration across large suites of applications, which usually devolved into a system that was XML or some such crap just on principle and hence tedious to manage from the CLI/text editor -- but the authors of those didn't care as log as they had a control-panel workalike GUI.

And there were lots of individual groupware oriented network services that seemed to think they had to be intrinsically tied to a desktop login to work.

As to TFA, I doubt there will be a convergence onto a single "thin" distro, since so many levels exists allready ranging from OpenWRT/busyboxish systems all the way up to "server" editions that are really quite bloated.

Yeah, well, outside of a corporate IT despotism there is nearly no such thing as a "consumer space" at all. You can usually convince management to kick off everything that simply won't do WPA enterprise to get rid of the hassle of AAA web portals, but excluding Androids is not going to happen, so you fire up wpa-enterprise and let the chips fall where they may and try not to worry that all the Androids can get themselves phished. So it's been a more than just a "pain" but an actual security threat to millions of educational sector users. For several years.

There is actually a sort of sad irony/schadenfreude to be had here, if I could just get myself to stop chronically sobbing in a quivering ball in the corner about the general state of IT security.

The biggest conceptual mistake people make about encryption is that it is only for protecting read access. It's also for protecting against write access. Specifically to your live sessions, so that you don't merrily think you are talking to your bank when you're actually talking to a thief.