I used to use plex. I've moved to emby.

Under linux, you might as well give up and run it under docker as they are very messy about their depedencies, but at least that's not too complicated.

For most places and efficient low cost configs, I'd say maybe 30-40/year in energy cost.

The upload bandwidth is killer. The performance of accessing the media is terrible (when I access a local rip, it's super high quality and *instant* seeking, versus streams from netflix and the like.

Actually, I'd say it would be more of a nightmare. Here we have the devils we know. In that scenario, it would be hellish even *knowing* what can't handle things.

Every hop in the network not being certain whether the next hop could or could not handle the conversation would be a nightmare in the making.

It seems funny, because that *ultimately* is the reality of IPv6.

The difference is that in the above scheme, *knowing* whether a hop in the network could or could not do 'big addresses' would be more difficult. With IPv6, it allows things to be very clearly delineated whether the communication is IPv6 capable or not.

The biggest obstacle to IPv6 was the stubborn resistance to any form of NAT. That IPv6 should be all or nothing. The piece needed to make IPv6-only *clients* possible was carrier grade NAT64. Yes, on the server and as a carrier, you need IPv4 *and* IPv6, but the vast bulk of endpoints can be IPv6-only now, taking the pressure off of IPv4. Of course this would have been nice to do a decade ago instead of the last two years or so, so that new servers could have a more comfortable time getting IPv4.

I personally would rather *not* have crypto at the IP or TCP layer. Reason being is that in practical terms, updates *must* be delivered through kernel updates. Given the nature of crypto updates, I'd much rather have librariers in userspace be the channel for updates.

I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.

The issues with DNS/DNSSEC are more reasonably addressed in the DNS layer. There is a lack of will to tackle that problem, but that's the same lack of will that would make implementing at a lower layer impractical as well.

When I pull up my cell phone ip information, it's IPv6.

Now that there's carrier-grade nat to allow ipv6-only endpoints to speak to ipv4-only hosts, it *finally* is plausible to offer most mobile/residential ipv6-only. So a lot of the people who are ipv6-only are precisely the ones that would never realize it.

For enterprise networks and internal networks, those are ipv4 and likely to stay ipv4-only (which is a bummer for software development, because IPv4/IPv6 agnostic code is still relatively rare, since there's so many subtle bugs trying to use AF_INET6 for both, and it's more complicated to have both AF_INET and AF_INET6 addresses).

It's an inefficiency that is very intentional.

The software industry realized that for a lot of their users, they couldn't extract upgrade licenses from customers readily because they had already done *too* good a job. Functionality wise, a lot of people don't need anything newer than Photoshop 6 (released 16 years ago). A lot of people could use Office 97. Of course some things have slowly evolved technology wise that *ultimately makes people need updates and there's some forced updates (e.g. fun incompatibilities in ms office formats), In general though, update revenue became a big uncertainty.

So the solution is to switch to rental models, subscriptions, et al. Licenses that terminate when you stop paying, rather than the 'old' way of transactional purchase that has indefinite usage rights.

Now a software company can much more efficiently milk their userbase for money without really having to figure out meaningful value add beyond what they already do.

Also, prior to 3.3, unicode strings couldn't be written in a python 2/3 agnostic way. Of course dealing with binary data as strings is a pain in 2/3 agnostic code still, but I can't see personally how they could have done it better than they did.

In any event, the fact that there is discomfort changing the 'python' to be a python 3 verifies that things aren't exactly rosy. If there *were* no mess, there wouldn't be so much fretting about concurrent installs and python3 and python2.

As a python developer in the real world, I still frequently have to fret about making sure my code does contortions to run in python2 and python3 concurrently. If I were writing internal tools, I wouldn't have to care so much as I could choose the one and only version to support. However, as an owner of pypi content and supporting customers that want to use whatever python interpreter they have installed already, it's a headache.

With some other languages, I could target the oldest reasonable version and testing is required, but rarely is there an issue that needs accommodation. In python terms, today that would be targeting python 2.6 (There are a *lot* of RHEL6/CentOS6 users out there). In practice, I only support 2.6, 2.7, 3.4, and 3.5, and generally have to continually develop against 2.6 and 3.4 (2.7 and 3.5 generally don't need such continual explicit attention beyond what is given 2.6 and 3.4)

That's an overly rosy picture of Python 3. Install most linux distros and run 'python'. Odds are overwhelming that it will be python 2.

There are plenty of modules that *still* are python 2 only. Most are developed to work with both python 2 and 3. Very very few are python 3 only.

Now it's not as bad as angular 1 -> 2, it's *generally* not too terrible to accomodate both python 2 and 3 in the same codebase. You only get to pulling your hair out if you do a lot with binary data, and even then it's not too terrible. Python 3 could have done some other nice things, like recognizing xrange as an alternative name for range, viewitems as a name for items, and other similar things that would make it much easier to go to python three without either doing your own interop or using six all the time. On the flip side, when dealing with a framework like angular, you are *generally* less worried about end-users (you provide the entire runtime) versus something like python, where the non-developer users bring their version of the interpreter to your code.

There's another headache when it comes to living in python 2 world. They decided 2.7 was going to be the last, end of story. As a consequence, 'minor' 2.7 updates are now introducing featurues causing the same sort of compatibility caveats that you historically only saw on 2.5->2.6 type updates.

While in this specific case, your frustration is misplaced (basically, modern Windows UI sensibilities start with DirectWrite), I share your frustration in the broader sense.

I have had some 1 line utility function to shorten some common idiom, and had developers insisting that the utility function should instead import some big framework that inflates execution time by 30% and memory consumption by 50% so I use their identical 1 line function instead of 'reinventing' one from scratch.

Also same mentality that caused some guy yanking some small thing from npm to freak out a gigantic part of the NodeJS ecosystem.

Some of our new developers complain that we create yum and apt repositories for things, saying the fact that publishing to gems, cpan, pypi, npm, etc is good enough and yum/apt are the old, slow way of doing things.

Note I'm not even that particularly crusty yet, I just actually have to deal with users who aren't full time software developers.

I know offtopic, but wanted to say I feel your pain (though not this example).

A click through EULA. I'm sure that was thoroughly reviewed and taken seriously.

The wider industry has several exmaples of being more careful. Tesla is *now* being more careful, like their competition, which is a good thing. I don't know what it buys to continue to defend their previous behavior, which they themselves have realized was wrong.

This may be true, but competitors all were more strict about lane assist and more reluctant to use the term 'auto' in any way associated with the technologies. Google has avoided anything other than trained professional testers to use their system, and has publicly stated their opinion that a system that's 90% there is more dangerous than one not there at all, because user expectations are problematic.

Again, people always say how people who know anything about piloting aircraft know that autopilot is far more limited than the public imagination thinks. The problem being the market is not people who know anything about aircraft, but about common drivers. In their world, they have the 'auto' transmission. In that case, they say 'go forward' and don't have to think about it as it completely takes care of itself. That is the level of expectation set for automobile operators.

If you get your pilot license, you know full well the limitations of the technologies as it's part of the required training. Before you can make a misconception and fail with it, you have gone through personal training, hands on with an experienced pilot. In the Tesla case, there's a click through EULA that is probably not read and not given much weight, because we are just inundated with EULAs. This competes with Tesla execs going around praising how much safer the system is than the human operators, and tossing out apples to orange comparisons to make the case that the user is better of surrendering their attention to the system (the 'deaths per driven miles' statistic).

Also, the 'all inclusive' number includes all ages and variety of vehicles. Tall SUVs, 15 year old cars with fewer safety features. Cars with much older pieces and different levels of maintenance.

It would be interesting to compare Tesla autopilot specifically to good-condition highway miles driven of 2014+ model year vehicles with forward collision alert type systems. That would be a more fair comparison.

I'm saying that, in the Mercedes article, people are still going to be jackasses and tape soda cans to the steering wheel. It's still going to happen.

However, in the Mercedes case they call it assisst and require folks to fool the sensors to be unsafe, so that's a bit excusable.

Mercedes even had to pull an ad that indirectly implied that maybe, possibly the lane assist feature was in the same ballpark of an autonomous car.

So Tesla bad: using autopilot and not being strict about user attentiveness, Mercedes better by using 'assist', being very careful about messaging, and being strict about user attention.

GM was crucified in the media for that. No one took GM's side on that. That is how reaction *should* be.

With Tesla, tons of folks are white knighting for a luxury car brand. It's insane.