Well maybe for combustion, but wait til we put fusion plants in every car...

In the TV market, they were valued because the cable/broadcast/satellite services had no idea what frequency band users were paying attention to and thus no idea what was effective and what was not without some proactive examination of the viewer base. This was important for the program producers to value product placement, integrated advertising, and for the cable/satellite people to know what content was worth/not worth licensing.

For unicast streaming, the streaming service knows *precisely* what the users are paying attention to. For content producers, they control the licensing terms so they should be able to force Hulu, Amazon, and netflix to provide data as part of the deal of licensing it, in order to have data for soliciting things like product placement.
The streaming services themselves have all the data they need to entice advertisers that are independent of the content. Additionally, the advertisements are in no way hard linked to the streaming media. If the service wants to show you that ad, they don't need to give a rat's ass about *which* program you are watching.
Certainly the people providing the service know which pieces of content they license and how much they are watched to evaluate relative value of their library.

So the two remaining purposes are to let Amazon know which parts of Netflix library are valuable enough to fight for versus not bothering, and academic curiosity of the viewership. Of course, the former might be workable by requesting the data from the content owners as part of negotiations, and the latter doesn't really mean revenue...

Neither side is being particularly constructive in helping fix systemd's issues.

Those in the systemd camp largely plug their ears and just think doubters are merely stubborn or unsophisticated enough to understand just how *awesome* it is and that it is worth the downsides (if they'll even admit something is a downside).

On the other side, mostly the criticism is just roll back and leave things as-is. Which leaves systemd advocates unhappy because they don't get their shiny capabilities at all. Not much discussion is had on how to amend certain strategies to placate the sensibilities of today while delivering the capabilities of something new. For example, if journald simply made plaintext logging alongside (not as a downstream add-on by piping to syslog, natively doing it alongside binary data), people would probably not balk nearly so much. If a systemd unit could degrade to start without being able to talk to pid 1 or cgroup support available (with loss of function), then some debug activity is made more straightforward in a rescue environment that may chroot (yes, spawning a container is usually possible, but why not degrade to cope to the extent possible). If open ended init scripts were better accommodated and didn't try to forcibly constrain sysv init scripts to force it to fit the only models that systemd understands.

Of course some concerns are more fundamental (bringing everything possible under one monolithic development effort rather than modular design that has discrete owners using simplistic yet consistent vocabulary to communicate with each other). But a lot of the specific technical issues could be alleviated by modification of systemd while preserving the stuff that there is to like.

It's like predicting how these 'automobiles' will be a big part of our lives (news is 100 years too late, but at least accurate). Predicting the future by simply stating the present, brilliant!

xbmc can do what plex does... if you mess with advancedsettings, apply a ton of special filename recognition patterns, set it up to store things in a shared sql database, and trick it into having an instance running somewhere headless and prod it to update library ever so often. For plex, they have a naturally headless server that takes care of all of that.

On the flip side, there is a gob ton of stuff I can do with xbmc that I can't with Plex. One painful one for me is integrate with my mythbackend *kind of* (still missing the closed captioning of ATSC streams, only mythfrontend seems to handle it).

I think my ideal world would be for xbmc to have a headless, auto-indexing library server that shares it's 'advancedsettings.xml' in a more trivial fashion and subtitle support for ATSC streams. The etensibility and community of xbmc with the simplicity of Plex and a tiny amount of capability from mythfrontend that is lacking...

But my ISP provides an SMTP relay. I configured postfix to use my ISP relay. This doesn't really impact my mail service or how it's stored or how it may be addressed/migrated in the future, but it gets me past the common blackhole filtering.

SMTP has just not scaled well and the mitigations have impaired the openness of the network somewhat, but SMTP relay facilities are usually available.

E7 is useful for areas where extremely large memory per core is mandatory (some parts of HPC)

In general, E5 strikes the balance between having adequate amounts of cache and SMP interconnect, compute capability (Haswell E5 is available, E7 is still Ivy bridge, AVX2 being a big thing there), and per-unit cost (E7 carries a huge premium for its benefits, most of which are generally not needed in HPC of this scale).

Even in places where you do see E7, it's usually in a special portion of the cluster for big-memory jobs that can't be split into multiple nodes as easily as most HPC workload, with the majority of the clusters employing something more like E5.

ARM won over in the mobile device space because of solid engineering around a low power envelope, without trying to compete with x86 performance in any way. Basically Intel made a mistake by not having *any* appropriate chips for that space at all. Performance per watt was never demonstrated to be better if you followed the curve up to desktop/server class energy consumption. Intel has actually competently answered in their Atom space, and has secured some mindshare among Android vendors (which I never would have guessed could be possible). Intel is second comer to the party and thus the ecosystem is clearly stacked against them, but they still managed to get their components in the market.

Some vendors are starting to tout ARM based competitors to Xeon. The problem being their energy consumption numbers at this point are actually higher and achieve lower performance numbers in compute and have worse I/O capability.

It's not that difficult. But after setting it up for a group of people and then setting up seafile, I prefer seafile. If you aren't an admin user in owncloud, things are pretty tough when it comes to knowing what groups you are in and what groups can be shared with and such. seafile does a much better job on that front.

Plus the owncloud sync client doesn't seem very good. And the mobile platform clients cost money where seafile is free.

ownCloud might have gotten the 'good name', but they don't have the best implementation sadly.

Yes, it's the fear of Ebola that's the bigger practical problem. However, the remedy for that fear is precisely doing things like declaring an Ebola 'Czar' and promising to deploy the National guard 'if necessary'. Note they didn't actually call up the national guard, just promised the obvious, if the national guard is warranted (it won't be) it will be called up. The nomination of a 'Czar' is pretty much free and convening ' a two-hour emergency meeting with every top federal official involved in public health and safety.' is actually not that terrible either. These measures are not a big deal in cost, but are important in their significance to the general populace.

So someone who is well informed may rightfully see all this as silly from a practical perspective, but I don't think they would perceive a significant investment of real resources in any of it.

Meanwhile those inclined to not be so well informed are assured by some response that really doesn't cost much.

Though that pales in comparison to having the secret number to take as much of your money as someone wants printed in plain on paper checks or stamped into a little piece of plastic that you share with anyone that you give money. If a mobile banking app would help me spend money in a more secure fashion at vendors, I'd gladly take it over a credit card to swipe. It could actually be substantially be incredibly more secure than chip and pin in some ways (e.g. the account holder fully controls the input and display device and can communicate with financial institution without going through vendor provided equipment.

Admittedly, before making a formal business commitment, we wouldn't play 'guess the actual requirements from vague problem descriptions, but:
"his organization has a one large event per year with roughly 1400 volunteers total." suggests the need is highly seasonal and admittedly one month is a bit specific, but you get the idea.

Actually, that case was not site development, but I'm well versed with precisely how much work it involved and even given the benefit of their familiarity with the codebase being modified, I'd wager easily it's more work than this question is detailing. It's also work my team could have done, but we were short on time. My team reviewed the code and only accepted it after we were comfortable that we knew the code provided as well as if we had written it ourselves. This is commercial for profit, but also not in the critical path for potential fiscal catastrophy (and I work those scenarios too, and those are a nightmare and warrant high cost, but you can't be so jaded as to assume *every* trivial piece of work should be treated as such).

I get a different read: " In the past two years, they have used a site written by a volunteer that has worked fine for them, but that volunteer is unavailable to maintain or enhance his site this year. " Note that the client seems *relatively* content with what one guy bothered to do in his spare time that was almost certainly done on very short notice, just probably looking for someone to go in and add a field here, or combine two forms there, or something relatively simple like that.

Even with the obvious editorial bias trying to spin it to state that is the case, I just don't get that feeling from the description and my work with non-profits. They probably have a simplistic site that they want to evolve a little, not raze everything to the ground and start over.

I am very familiar with how enterprise projects work. However you slice it, this is *not* of that pedigree. Small non-profits generally know they get what they pay for and don't have complex needs or unrelenting demands over even trivial cosmetic stuff like is common in enterprise land. There is just a huge world of difference between a production internet presence of an international Fortune 100 company with a labyrinth of inter-departmental nightmares to navigate with a potentially huge revenue amounts, market perception, or liability on the line at any given time and a volunteer sign up site for a local non-profit that only handles about 1,400 volunteers.

Well, two factor doesn't mandate two channels (for example a door access system that requires both a badge and a keycode is also two factor), but yes, two distinct devices needing to be hijacked is better. However, in your example that's not assured either. If the mobile device is used to access the website then it's still one device. There's no guarantee that the user used a different device to access the web and process the text message. It's at the discretion of the user to take care of their circumstances appropriately.

Ultimately, the point I was trying to make is that this is an improvement over the usual state of things and should not be discouraged just because it isn't perfect. This aspect of security is trying to find the right balance between 'secure' and 'friendly'. It's easy to be secure if you don't care how hard it is to use, but making two-factor authentication as the norm for authentication has thus far eluded us due to acceptance issues, rather than technical failings. We have dozens of viable two-factor authentication approaches, just none that most people would tolerate.

The dominance of computer's as something for men in 80s pop culture was probably reflecting the trend rather than causing it. The timeline seems too short for so few pop culture things to influence.

The market for coding evolved at first primarily from 'data entry', which required nearly no training. Women of the time (disadvantaged or disinclined from training depending on your opinion) could take those jobs and men who needed to 'provide' sought higher trained jobs with higher pay. Basically straightforward data entry started to become 'advanced data entry' that started incorporating things like formulas and continued on from there. Perhaps because it started to demand more and more skills, narrowing the labor pool and driving up compensation, enticing men to start participating more heavily and an overall male-favorable social bias started to take effect. Or perhaps the nature of the work fundamentally changed enough in a way that drive a different male/female interest. Or some other factor, these are all guesses.

I just doubt that a handful of 80s movies changed the entire landscape of female participation in the market basically within a couple of years of the first movie's release, and there's a lot of alternative explanations that are quite viable.

Use FreeOTP or Google Authenticator? It's simple yet pretty well secure and allows an arbitrary mobile device to provide keycodes? Sure, you have to actually type a few numbers (the horror), but at least you don't need yet another security dongle that, despite the current hype, will probably be obsolete in a couple of years.