Transparent won a couple of Golden Globes, but "Bosch" hasn't started streaming yet and Chris Carter's "The After" mysteriously got cancelled almost a year after it was a winner in the same pilot voting "election" as Bosch.
I think someone trying to reinvent the "system" of creating filmed content is laudable and worthwhile, I'm just curious if Amazon really has put more thought into this than "vertical integration" and assuming that whatever insight they have into package delivery logistics and cloud computing is somehow universally applicable to something like film/tv production. They wouldn't be the first "geniuses" to take hubris to a new level only to discover that doing A well means nothing when it comes to doing B well. We see plenty of that when A and B aren't all that different.
I think faster (and more complete) turnaround of announced content would definitely help, I also wonder if it would make sense to rethink some of the streaming assumptions -- like, why straightjacket yourself into the one hour episode format? Why not two hour episodes, but fewer of them? Does the entire series have to available all at once, or could faster release cycles from pilots to episodes be accomplished by releasing a group of episodes every 60-90 days to allow for simultaneous shooting and releases?
Should they dilute their resources producing a bunch of one-hour pilots, or should they be a little more discriminating and look at a pilot instead as a more complete story arc and make 3 episodes? That way even failures that didn't become series could at least be watchable, self-contained miniseries adding value to the catalog instead of just becoming trivial ephemera? Maybe the desire to make more typical "movies" is part of this.
It's a gamble between two opposing forces of insurance:
1) On one hand, insurance companies are bureaucracies and handling claims is a bureaucratic process with a certain amount of inertia, where obvious fraud needs to be caught but time/people/resources don't exist to fine-grain protect against all possible marginal fraud, otherwise the system would grind to a halt. A tracking device with a minor deviation from observed damaged may just get written off as the strangeness of physicals or the brittleness of plastic cars -- I mean, we have the data, right?
2) On the other hand, IMHO, the insurance company is almost in the primary business not of supplying insurance or processing claims, but in DENYING claims. Insurance fraud is a huge risk, the more claims they can deny the more money they make and they have deep and long-term investments in actuarial data and statistics. They may already have enough tracking device data in their databases to *know* that your physical damage doesn't align with the tracking data.
Regardless of the reason (Amazon's missteps or typical TV timelines), it's kind of problematic. A year turnaround kind of kills momentum and interest, although given the thin creme at the top of the shitpile that is a streaming content catalog, maybe it won't matter because streamers will watch almost anything even if its not that good.
It could also be a limitation of the "instant binge" model where the entire series is available at once versus a weekly release that allows them to actuallly shoot the series as it runs.
Maybe they could do some kind of combination, shooting 3 episodes of every series they ballot and then actually starting production on the rest of the series immediately after the voting window ends. In theory, a 60 day delay between the end of balloting and the "start" of the series should allow them time to shoot an additional two episodes, and the whole thing could be setup to be released in 4 episode batches every 90 days.
They'd end up shooting episdes they don't need, but pehaps they could structure the 3 episode narratives in a way that made them more or less complete even if they didn't get voted for a season. A three-episode triptych could become some kind of new streaming-only format and maybe it would serve as some kind of an incubator for new talent or genre fiction.
And the Chris Carter sort of post-apoc sci fi thing, too, Which will probably suck and be like everything else, with predictable, formulaic episode structures where *tiny* amounts of the bigger conspiracy are revealed, stringing viewers along forever and then never really having a point, like "Lost".
Anyway, the pilot at least held my interest and binging without commercials makes it somehow less annoying. And the Bosch series looks good, too. The books are above everage mysteries and Welliver is pretty perfect for Bosch.
I don't understand Amazon's long window between pilot and series, though. It seems that traditionally when a pilot was aired if new episodes were to be aired, they aired fairly closely. Maybe traditional pilots and series' had long windows, too, you just didn't know about them because only TV suits saw the pilots and Amazon had that voting scheme.
Or maybe this is tech industry hubris, where they think beause they have a handle on cloud computing and fulfillment logistics that they can just step into making TV shows, too, and then find out that everything they think they know is worthless.
I kind of hope it's the latter; not for the comeuppance, but maybe there's some slim chance that an application of money and disconnection from traditional media can kind of reinvent the process for making filmed entertainment.
And while I'm ranting on the topic, I wonder why they stick with the traditional 60 minute episode. If people can binge watch it anyway, why not 7 two hour episodes instead of 13 hour episodes?
It may be cheaper to drop the setpoint down when power is comparatively cheaper (and how much cheaper are we talking -- a couple of cents per kWh?) but it is it more energy efficient to drop the setpoint down so that it can cycle less and gain temperature above optimal when the power is more expensive? Eg, if optimal is 36F and I drop it to 34 when power is cheap but let it rise to 38 when its expensive only to need to drop it back to 34 when its cheap.
In my experience, doing something similar with my central air conditioner in the summer usually seems like a mistake. If I raise the setpoint from 72F to 75F during the day it seems to take constant running for hours to get back those 3 degrees, more running than it would seem to take just to keep it at 72F.
It seems like it takes more energy to drop a box a few degrees than it does to keep it at a constant temperature. Of course all I know about refrigeration and thermodynamics is that it means we can't have nice things.
Something's wrong if your pipes will freeze with the furnace off for a couple of hours.
I also live where it can hit -35C (although -30C is more common) and I have my thermostat automatically setback to 60F at night and unless it really is -30C, the inside temperature never hits the setpoint, usually sinking to the low 60s from a normal setpoint of 69.
In my experience in order to freeze pipes, your furnace would have to be completely off for many hours, in extremely cold temperatures (-30 or colder), your house would have to be extremely poorly insulated (lots of heat loss) and you'd have to have uninsulated pipes in an exterior wall which was itself nearly uninsulated. For internal pipe runs your entire house would have to fall below freezing for hours before you burst pipes.
I think there is some risk in the latter in many kitchens, as sinks tend to be on outside walls in many houses and often the supply plumbing is run up in the exterior wall void which some idiot builder/installer/plumber/remodeler doesn't re-pack with insulation. I've known a couple people who have had this happen when on vacation -- set back thermostat really low (like 55F for the duration of their trip) and 5 days of serious subzero weather. Always shut off the water main when leaving like this -- that way at least a burst pipe is a minor mess versus a total disaster.
Putting foam insulation on the exterior wall pipe runs helps a lot. I found that insulating the entire hot water line from the hot water heater to the kitchen sink was beneficial just for faster hot water to the sink. It seems I get max hot water much faster when my pipes aren't basement cold and nearly instantly if I've used the hot water within the last few hours.
There are roughly 1.6 billion Muslims in the world but only 320 million Americans. There are five Muslims in the world for every one American. It's not clear that there would be any point to an all out war between the all the Muslims of the world and the USA (i.e. both sides would lose far more than they could hope to gain). But it's also far from clear that the USA could win such a war with brutality alone. Most likely other countries would get involved and the outcome would be determined by which side could build the strongest alliances.
Total warfare is an overarching military philosophy, it is not a specific campaign strategy.
We speak of Islamic extremism, but most generally we experience a particular flavor of Arab-dominated Islamic extremism made possible right now by a handful of weak and failed Arab states, bounded by Lebanon on the North and West, Syria and Northern Iraq in the Center and Yemen in the South. Arab states with functioning governments and effective central control have little problems with jihadis, they are treated as an internal problem.
Imposing order on these areas would vastly minimize the breeding ground for this kind of terrorism.
but the real war won't be won on the battlefield any more than the war against the Soviets was won on the battlefield.
It all depends on what kind of battlefield warfare you're willing to fight.
The TV news friendly, politically popular war where we're real careful about the destruction we cause and the collateral damage and winning hearts and minds is a sure loser.
Scorched earth total warfare where you ring a population center and utterly bomb it to rubble without any consideration for civilians is winnable. You win a war by utterly destroying your enemies ability AND their will to fight. And you do by inflicting massive death and destruction.
The of the firebombing of Tokyo and the A-bomb strikes. The Japanese were infamous for fighting to the last man and never surrendering. Once we demonstrated the ability and willingness to just level cities until they capitulated, they capitulated. The alternative was not capitulating and risking the reduction of the Japanese nation to the same footnote status of Carthage.
How do you think Julius Ceasar won the Gallic campaign? By building roads and schools and promising H1-B visas? You were given an offer to disarm and pledge allegiance to Rome. Your alternative was to have your people killed, your treasure seized and anyone left standing sold into slavery or crucified.
No, it is not nice in any sense of the word. It is utter brutality and bloodshed. Which is why we should never, ever get into these conflicts unless we're willing to do what successful armies for centuries have done to actually conquer a people.
Somehow it seems like an even worse version of the Gilded Age's above the law mentality. You might argue that era really was a "wild west" in which there wasn't much in terms of law and regulation and people really kind of did what they wanted. The Federal Government was much weaker than it is now and the concept of regulation was pretty weak at any level.
These days there's more government and regulation (for good or for ill) and it should come as no surprise to anyone that many things are subject to rules and regulation. But what seems to happen is that corporations know things are illegal but assume that political payola or huge legal retainers will protect them.
My favorite gimmick is knowing something is prima facie illegal, but paying some lawyer a pile of money to offer a "legal opinion" of pretzel logic that says its illegal, but the intent of congress was that's only illegal for other people to do for reasons other than what we're doing it for, and since we're operating within the "spirit" of the law its OK.
Then when they get caught there's a whole bunch of "Who, me? But I got a legal opinion from my lawyer, and he said it was OK. You can't hold it against me because I intended to follow the law as I understood it."
The bitch fest about iOS8 on iPhone 5 which is dual core and has 1 GB RAM was pretty damn loud.
I do think that as each device rev usually gets a pretty significant SoC change which inevitably leads to performance tuning focusing on the new hardware platform. Sure, they backport to older hardware but there's a lot of diminishing return in tuning the new OS for older hardware.
It's even worse for Android than iOS because of the wide range of platforms used for any given Android release.
I think there's an awful lot of "port and pray" going on which is probably coupled with more than a little cynicism on the part of vendors that shitty performance is an acceptable state to motivate new handset purchases.
I just think a more modular platform would make it more difficult for OS vendors to focus their OSes as much as a single-platform target and be so half-hearted about platforms that aren't the OS launch platform.
A lot people I know who aren't obsessed with having the latest and greatest have the Galaxy S3 (released 2.7 years ago) and have zero reason to upgrade.
You've just defined your sample population axiomatically. People who don't want the latest features are by definition people who don't want to upgrade. You can write it backwards as "people who don't want to upgrade don't want the latest features" and it means the same thing.
Smartphones are pretty close to the point where you can buy one and use it until it breaks.
Now just do a Google search for people bitching about what the latest mobile OS release (if they can even get it) does to their 2 year old device. I hear more from Apple iOS users than Android users but that's often a function of the fact that Apple devices can get iOS without waiting for carriers to approve them, unlike many Android devices which get abandoned by the carriers and never see an update. Lots of complaints about how slow the devices are.
Sure, you can use it as it came out of the box, but app vendors often follow OS releases and can abandon older OS releases pretty easily because so many people have updated devices with updated OSes. I flow my iPhones downward (my wife get's last years, the home phone is the one before that, the one before that is used as an iPod for my son on long trips). At one point the iPod lost half its apps when I updated it because the device couldn't run iOS 7 and couldn't run apps that now required 7.
IMHO, a modular phone will solve much of this by letting users get a faster processor / memory module without replacing what (at least since "retina" displays) is a great display. Networking modules could get replaced if/when there was a network feature everyone wanted -- I have an iPhone 6+, but IMHO the 802.11ac is lost on me and any incremental upgrades to LTE are probably worthless without widespread carrier support for the enhanced LTE features (if I would notice them at all).
It also adds to user choice -- a lot of iPhone users were put off by newer, larger phones or the lack of a choice on any platform for something that wasn't Galaxy sized or bigger. Deciding you want a smaller display would be trivial on a modular phone.
I also think that the highly integrated SoC hardware model adds to OS performance hits on older systems and lack of extended OS support by the large number of architecture changes and required driver and OS tuning. If the devices were more modular you either wouldn't get stuck (new CPU module) and it would push OS makers into thinking more modular about their OSes rather than tailoring an OS release to whatever the latest hardware in the current model is.
More importantly than any of this, however, is that phone hardware is rapidly getting to PC performance levels and its getting very close to the idea that a smartphone could become a base module itself in a PC, possibly with a wide range of crossover (where PCs would actually use smartphone modules by default). Sure, you can do a bluetooth keyboard and HDMI output now, but it's less than what it could be.
Everyone always says the cars will charge late at night when demand is low, but is that a function of the charger gizmo on my garage wall or the car itself? I see people coming home from work and just plugging in the car to the wall as a matter of habit unless they have immediate plans to go someplace that evening because it will be a bitch to wake up and go to work and find that you didn't plug in and your battery doesn't have enough power to get you to work.
So in theory you could have a huge demand from 1730-1830 until 2200 or so. Maybe they will have some way for the car to query the grid to find out what the optimal amount of power it can draw at any given time.
Is it Slashdot or some new release of Chrome? I now notice I have my google account name on the top of the window and several pages don't render right, including slashdot five minutes ago (although it now looks right).
I'm curious if the neighborhood electric grid is scaled to support swapping out half or more of the 70-odd cars on the block for electric cars. Assuming a generic assortment of random cars charging at an average rate of 5kW that's a new load of 160kW.
It's probably not an issue in a cold climate in the winter (since it would balance out the power we'd normally use for air conditioning) but what about the summer?
And then I think, well, scale that up to the entire city and suddenly it seems like a whole power plant's worth of power.
Microsoft could have been a long way towards this if they had *focused* on this instead of just sucking on Office revenue, trying to become a phone/tablet vendor and destroying desktop Windows with their bullshit Metro UI.
2012 could have been the OS where they introduced transparent application-specific VMs and Windows 10 could have been the OS where they added transparent DR/Azure migration and replication.
Instead they're still playing catch-up to VMware and I don't think they can be VMware anymore than they can be Apple.
The advantage they could have over VMware with application-level virtualization is that it would eliminate the need for the expensive VMware licensing and the expensive Windows licensing needed to isolate applications. But MS would probably fuck that up to and limit it to some lame level of virtualization per OS license.
I sure run into a lot of medium sized organizations that do nothing of the sort.
Most talk about it but when they see the price tag they get cold feet. The "better" ones will do some kind of off site setup, but it's often done with old equipment retired from production and some kind of copying/replication from the production site with little or no solid plan on how to actually bring up the remote site in a way that's useful.
The ones that seem the best off are the ones running VMware SRM.
But overall, yes, the situation isn't great. I think some kind of sandboxing of software should be available and the default on every OS.
I sometimes wonder if the infinite monkeys concept applies here -- one one where if an infinite number monkeys have typewriters they will eventually write the works of Shakespeare.
Eventually, Microsoft will re-invent VM/CMS and we will have a system where every application can run or share a VM as determined by the operator.
For much of the Mac's history this was also the case. If you wanted an application, you just copied the damn thing from one media to another.
IIRC, it got worse over time on the Mac as apps got bigger (more supporting crap, stuff to copy to the System Folder, maybe a control panel or init, etc).
One in a while you run into applications, often utilities, that are truly standalone -- you can copy it to a new system and just run it. And then there are the various techniques for making portable apps, some kind of hand-done with a wrapper, others that scan a system before install and after and package all the deltas and use a wrapper after running to redirect all the various accesses.
I kind of blame shared libraries myself versus static linking. I've never quite groked the attraction of shared libraries. I get pilloried on Slashdot for saying this, of course. Usually its "ZOMG how will I patch my system when $library has a security weakness and 69 apps all use it" or "it takes too much disk space".
#1 is a fair criticism, I guess, but means little on Windows which seems to use less of that kind of a shared library, but I also wonder if there isn't a counter argument by which not every app statically linked to a common library will have the same bug and won't need updating. And it's not like updating a shared library is always risk-free; there's always the chance that an updated dependent library may change in some way that borks some of the apps that depend on it or some of the problems and cruft from several versions of the same library on the same system.
#2 seems like a bullshit criticism in this day and age. I'm curious what a "typical" OS install would be like space-wise if it was all statically linked.
And if you had all-statically linked applications, updating them to new versions would be just a matter of copying in a new version which seems simpler and more manageable to me for some reason.
Of course, none of this means much to apps which legitimately have a shit-ton of included resources which need to be shared system wide. Those have to go in their right places somehow, but if they are app specific they could just be in the same directory as the application. Maybe apps could um, register, their shared capability with the system so it would know to look for a resource in a virtual directory/app/resource/shared instead of a system-wide/resources directory -- the app itself remains self-contained, no installer required, and it could just register its capability at runtime with the system.
I'm not sure dedupe and compression are arguments for all-flash. Both of those things are heavily CPU bound, dedupe requires a block checksum computation and a lookup to find a match and compression takes computation.
My experience with dedupe is limited, but inline dedupe writes take a serious performance hit without relying on massive RAM cache to hold writes. Post-write dedupe makes for faster writes and doesn't really cost I/O because it can be done on a deferred basis when there is low I/O loads, which also helps with CPU consumption. Post-write dedupe can then be done to whatever disk with little penalty since it's background I/O.
I think deduped reads benefit from flash because the nature of deduped blocks is that they're not aligned with any file(s) and require a lot of random I/O -- the file request, a lookup for the deduped blocks that belong to file and then the random I/O of reading the non-aligned deduped blocks from dedupe store and the non-deduped blocks from the actual file.
This obviously would thrash spinning disk, but if you go back to the logic behind most tiered systems with flash disk it is unlikely to be a penalty for frequent reads since that data will already be on flash. Obviously flash/disk sizing ratios matter here, but the hybrid systems I've worked with usually have 1:5 ratios.
I don't see where all flash specifically aids snapshots -- most snapshots just collect write deltas, not complete duplicates of the LUN. Working with a handful of snapshots of a LUN isn't any more performance hit unless you regularly promote a snapshot to a complete volume.
And none of this is an argument against flash -- obviously it adds huge performance gains, my thought is just that in most cases the performance of hybrid flash gives nearly the same experience as all flash, provided that adequate flash tiers are provided and that the controller tiers blocks and not entire files.
Obviously there will be corner cases -- levels of I/O where tiering activity can't keep up, situations where nearly all data is read at about the same frequency where it can't be tiered efficiently, or massive flood writes that overwhelm flash landing zones and force writes to spinning disk. Tiering fails in these cases or is marginal in its effectiveness.
On paper at least, USB3 is supposed to support 625 MBytes/sec while the LTO6 is only capable of 160 MBytes/second, so in theory as a data bus, USB3 should be able to handle it.
IIRC, USB2 was polling driven and run at full rate would cause noticeable spikes in CPU utilization. My guess is that changed in some way for USB3 to support faster data rates, but I don't know how.
I use a USB3 gigabit NIC on my Surface Pro and I don't notice any network performance issues at all.
Most storage vendors make a big deal out of the fact (sometimes with actual data) that a lot of data isn't accessed often enough to warrant spending a premium on the storage medium it sits on and sell products that automatically track and tier blocks based on access frequency and writes.
As long as there is a big price gap between large 10k spinning disks and solid state, won't hybrid arrays still make economic sense? Unless you do something weird, you'll mostly have an all-flash experience but at $/TB prices closer to all disk. In this space, going all flash is just a waste -- 1,000,000 IOPs is great if you need 1,000,000 IOPS, but if you can only do 10k IOPS, isn't it just wasted IOPS?
If reliable SSD comes far enough down in price, dumping all spinning disk might make economic sense even if it isn't 1:1 parity in price because you can then ditch the complex block tracking and tiering systems which add a bunch of cost.
LTO3 isn't big enough to be worth the headache of 2-3 tapes per TB. LTO5 would be very usable, but requires an annoying SAS card which are just expensive enough to make the whole solution a little spendy.
I'm mostly kidding about USB3, but I sort of wonder why you couldn't have a USB3 interface for a connection medium.
I think it would make a ton of sense for every organization to do a DR "drill" periodically where they attempt to actually use their DR plan (restore a group of servers, reload a switch configuration, etc).
This just seems like a sensible part of that.
What worries me, though, is how they will know when to actually implement a security plan and deal with the consequences. A lot of security breaches are subtle, and you don't know they've happened or at least not always with a definitive sign like a defacement page, etc.
I would assume a "real" security response would be something akin to putting a lot of resources "in lockdown" -- shutting down servers, cutting network links, etc, which could have major business consequences. I can see where uncertainty about a breech and hesitancy to isolate key systems (perhaps necessary to contain a breech) could lead to a real clusterfuck.
I think a key part of developing the plan is deciding when you know there is a real breach and making sure that the responses are well-known ahead of time to avoid a lot of head-scratching and internal conflict.
As much as I like to bash carriers, Google, handset makers, etc, much of the crux of this problem is that "progress" in the world of smartphone technology moves at such a rapid clip that by and large many things out there 2+ years old are in many ways obsolete and there's no easy way to go back and fix problems without just replacing devices on the consumer end.
I'm curious if smartphone technological advancements will slow down enough in the foreseeable future where this gets addressed sufficiently and you can expect fixes. By and large the PC world has been like this for a while, although it lacks the structural issues (ie, Google/Handset maker/carrier) that complicate it. Handsets are still advancing from a hardware perspective fairly quickly in terms of new chipsets that even if issue X could get fixed, the hardware itself isn't supported anymore.
Slashdot Mirror
Transparent won a couple of Golden Globes, but "Bosch" hasn't started streaming yet and Chris Carter's "The After" mysteriously got cancelled almost a year after it was a winner in the same pilot voting "election" as Bosch.
I think someone trying to reinvent the "system" of creating filmed content is laudable and worthwhile, I'm just curious if Amazon really has put more thought into this than "vertical integration" and assuming that whatever insight they have into package delivery logistics and cloud computing is somehow universally applicable to something like film/tv production. They wouldn't be the first "geniuses" to take hubris to a new level only to discover that doing A well means nothing when it comes to doing B well. We see plenty of that when A and B aren't all that different.
I think faster (and more complete) turnaround of announced content would definitely help, I also wonder if it would make sense to rethink some of the streaming assumptions -- like, why straightjacket yourself into the one hour episode format? Why not two hour episodes, but fewer of them? Does the entire series have to available all at once, or could faster release cycles from pilots to episodes be accomplished by releasing a group of episodes every 60-90 days to allow for simultaneous shooting and releases?
Should they dilute their resources producing a bunch of one-hour pilots, or should they be a little more discriminating and look at a pilot instead as a more complete story arc and make 3 episodes? That way even failures that didn't become series could at least be watchable, self-contained miniseries adding value to the catalog instead of just becoming trivial ephemera? Maybe the desire to make more typical "movies" is part of this.
It's a gamble between two opposing forces of insurance:
1) On one hand, insurance companies are bureaucracies and handling claims is a bureaucratic process with a certain amount of inertia, where obvious fraud needs to be caught but time/people/resources don't exist to fine-grain protect against all possible marginal fraud, otherwise the system would grind to a halt. A tracking device with a minor deviation from observed damaged may just get written off as the strangeness of physicals or the brittleness of plastic cars -- I mean, we have the data, right?
2) On the other hand, IMHO, the insurance company is almost in the primary business not of supplying insurance or processing claims, but in DENYING claims. Insurance fraud is a huge risk, the more claims they can deny the more money they make and they have deep and long-term investments in actuarial data and statistics. They may already have enough tracking device data in their databases to *know* that your physical damage doesn't align with the tracking data.
Regardless of the reason (Amazon's missteps or typical TV timelines), it's kind of problematic. A year turnaround kind of kills momentum and interest, although given the thin creme at the top of the shitpile that is a streaming content catalog, maybe it won't matter because streamers will watch almost anything even if its not that good.
It could also be a limitation of the "instant binge" model where the entire series is available at once versus a weekly release that allows them to actuallly shoot the series as it runs.
Maybe they could do some kind of combination, shooting 3 episodes of every series they ballot and then actually starting production on the rest of the series immediately after the voting window ends. In theory, a 60 day delay between the end of balloting and the "start" of the series should allow them time to shoot an additional two episodes, and the whole thing could be setup to be released in 4 episode batches every 90 days.
They'd end up shooting episdes they don't need, but pehaps they could structure the 3 episode narratives in a way that made them more or less complete even if they didn't get voted for a season. A three-episode triptych could become some kind of new streaming-only format and maybe it would serve as some kind of an incubator for new talent or genre fiction.
And the Chris Carter sort of post-apoc sci fi thing, too, Which will probably suck and be like everything else, with predictable, formulaic episode structures where *tiny* amounts of the bigger conspiracy are revealed, stringing viewers along forever and then never really having a point, like "Lost".
Anyway, the pilot at least held my interest and binging without commercials makes it somehow less annoying. And the Bosch series looks good, too. The books are above everage mysteries and Welliver is pretty perfect for Bosch.
I don't understand Amazon's long window between pilot and series, though. It seems that traditionally when a pilot was aired if new episodes were to be aired, they aired fairly closely. Maybe traditional pilots and series' had long windows, too, you just didn't know about them because only TV suits saw the pilots and Amazon had that voting scheme.
Or maybe this is tech industry hubris, where they think beause they have a handle on cloud computing and fulfillment logistics that they can just step into making TV shows, too, and then find out that everything they think they know is worthless.
I kind of hope it's the latter; not for the comeuppance, but maybe there's some slim chance that an application of money and disconnection from traditional media can kind of reinvent the process for making filmed entertainment.
And while I'm ranting on the topic, I wonder why they stick with the traditional 60 minute episode. If people can binge watch it anyway, why not 7 two hour episodes instead of 13 hour episodes?
It may be cheaper to drop the setpoint down when power is comparatively cheaper (and how much cheaper are we talking -- a couple of cents per kWh?) but it is it more energy efficient to drop the setpoint down so that it can cycle less and gain temperature above optimal when the power is more expensive? Eg, if optimal is 36F and I drop it to 34 when power is cheap but let it rise to 38 when its expensive only to need to drop it back to 34 when its cheap.
In my experience, doing something similar with my central air conditioner in the summer usually seems like a mistake. If I raise the setpoint from 72F to 75F during the day it seems to take constant running for hours to get back those 3 degrees, more running than it would seem to take just to keep it at 72F.
It seems like it takes more energy to drop a box a few degrees than it does to keep it at a constant temperature. Of course all I know about refrigeration and thermodynamics is that it means we can't have nice things.
Something's wrong if your pipes will freeze with the furnace off for a couple of hours.
I also live where it can hit -35C (although -30C is more common) and I have my thermostat automatically setback to 60F at night and unless it really is -30C, the inside temperature never hits the setpoint, usually sinking to the low 60s from a normal setpoint of 69.
In my experience in order to freeze pipes, your furnace would have to be completely off for many hours, in extremely cold temperatures (-30 or colder), your house would have to be extremely poorly insulated (lots of heat loss) and you'd have to have uninsulated pipes in an exterior wall which was itself nearly uninsulated. For internal pipe runs your entire house would have to fall below freezing for hours before you burst pipes.
I think there is some risk in the latter in many kitchens, as sinks tend to be on outside walls in many houses and often the supply plumbing is run up in the exterior wall void which some idiot builder/installer/plumber/remodeler doesn't re-pack with insulation. I've known a couple people who have had this happen when on vacation -- set back thermostat really low (like 55F for the duration of their trip) and 5 days of serious subzero weather. Always shut off the water main when leaving like this -- that way at least a burst pipe is a minor mess versus a total disaster.
Putting foam insulation on the exterior wall pipe runs helps a lot. I found that insulating the entire hot water line from the hot water heater to the kitchen sink was beneficial just for faster hot water to the sink. It seems I get max hot water much faster when my pipes aren't basement cold and nearly instantly if I've used the hot water within the last few hours.
There are roughly 1.6 billion Muslims in the world but only 320 million Americans. There are five Muslims in the world for every one American. It's not clear that there would be any point to an all out war between the all the Muslims of the world and the USA (i.e. both sides would lose far more than they could hope to gain). But it's also far from clear that the USA could win such a war with brutality alone. Most likely other countries would get involved and the outcome would be determined by which side could build the strongest alliances.
Total warfare is an overarching military philosophy, it is not a specific campaign strategy.
We speak of Islamic extremism, but most generally we experience a particular flavor of Arab-dominated Islamic extremism made possible right now by a handful of weak and failed Arab states, bounded by Lebanon on the North and West, Syria and Northern Iraq in the Center and Yemen in the South. Arab states with functioning governments and effective central control have little problems with jihadis, they are treated as an internal problem.
Imposing order on these areas would vastly minimize the breeding ground for this kind of terrorism.
but the real war won't be won on the battlefield any more than the war against the Soviets was won on the battlefield.
It all depends on what kind of battlefield warfare you're willing to fight.
The TV news friendly, politically popular war where we're real careful about the destruction we cause and the collateral damage and winning hearts and minds is a sure loser.
Scorched earth total warfare where you ring a population center and utterly bomb it to rubble without any consideration for civilians is winnable. You win a war by utterly destroying your enemies ability AND their will to fight. And you do by inflicting massive death and destruction.
The of the firebombing of Tokyo and the A-bomb strikes. The Japanese were infamous for fighting to the last man and never surrendering. Once we demonstrated the ability and willingness to just level cities until they capitulated, they capitulated. The alternative was not capitulating and risking the reduction of the Japanese nation to the same footnote status of Carthage.
How do you think Julius Ceasar won the Gallic campaign? By building roads and schools and promising H1-B visas? You were given an offer to disarm and pledge allegiance to Rome. Your alternative was to have your people killed, your treasure seized and anyone left standing sold into slavery or crucified.
No, it is not nice in any sense of the word. It is utter brutality and bloodshed. Which is why we should never, ever get into these conflicts unless we're willing to do what successful armies for centuries have done to actually conquer a people.
Somehow it seems like an even worse version of the Gilded Age's above the law mentality. You might argue that era really was a "wild west" in which there wasn't much in terms of law and regulation and people really kind of did what they wanted. The Federal Government was much weaker than it is now and the concept of regulation was pretty weak at any level.
These days there's more government and regulation (for good or for ill) and it should come as no surprise to anyone that many things are subject to rules and regulation. But what seems to happen is that corporations know things are illegal but assume that political payola or huge legal retainers will protect them.
My favorite gimmick is knowing something is prima facie illegal, but paying some lawyer a pile of money to offer a "legal opinion" of pretzel logic that says its illegal, but the intent of congress was that's only illegal for other people to do for reasons other than what we're doing it for, and since we're operating within the "spirit" of the law its OK.
Then when they get caught there's a whole bunch of "Who, me? But I got a legal opinion from my lawyer, and he said it was OK. You can't hold it against me because I intended to follow the law as I understood it."
The bitch fest about iOS8 on iPhone 5 which is dual core and has 1 GB RAM was pretty damn loud.
I do think that as each device rev usually gets a pretty significant SoC change which inevitably leads to performance tuning focusing on the new hardware platform. Sure, they backport to older hardware but there's a lot of diminishing return in tuning the new OS for older hardware.
It's even worse for Android than iOS because of the wide range of platforms used for any given Android release.
I think there's an awful lot of "port and pray" going on which is probably coupled with more than a little cynicism on the part of vendors that shitty performance is an acceptable state to motivate new handset purchases.
I just think a more modular platform would make it more difficult for OS vendors to focus their OSes as much as a single-platform target and be so half-hearted about platforms that aren't the OS launch platform.
A lot people I know who aren't obsessed with having the latest and greatest have the Galaxy S3 (released 2.7 years ago) and have zero reason to upgrade.
You've just defined your sample population axiomatically. People who don't want the latest features are by definition people who don't want to upgrade. You can write it backwards as "people who don't want to upgrade don't want the latest features" and it means the same thing.
Smartphones are pretty close to the point where you can buy one and use it until it breaks.
Now just do a Google search for people bitching about what the latest mobile OS release (if they can even get it) does to their 2 year old device. I hear more from Apple iOS users than Android users but that's often a function of the fact that Apple devices can get iOS without waiting for carriers to approve them, unlike many Android devices which get abandoned by the carriers and never see an update. Lots of complaints about how slow the devices are.
Sure, you can use it as it came out of the box, but app vendors often follow OS releases and can abandon older OS releases pretty easily because so many people have updated devices with updated OSes. I flow my iPhones downward (my wife get's last years, the home phone is the one before that, the one before that is used as an iPod for my son on long trips). At one point the iPod lost half its apps when I updated it because the device couldn't run iOS 7 and couldn't run apps that now required 7.
IMHO, a modular phone will solve much of this by letting users get a faster processor / memory module without replacing what (at least since "retina" displays) is a great display. Networking modules could get replaced if/when there was a network feature everyone wanted -- I have an iPhone 6+, but IMHO the 802.11ac is lost on me and any incremental upgrades to LTE are probably worthless without widespread carrier support for the enhanced LTE features (if I would notice them at all).
It also adds to user choice -- a lot of iPhone users were put off by newer, larger phones or the lack of a choice on any platform for something that wasn't Galaxy sized or bigger. Deciding you want a smaller display would be trivial on a modular phone.
I also think that the highly integrated SoC hardware model adds to OS performance hits on older systems and lack of extended OS support by the large number of architecture changes and required driver and OS tuning. If the devices were more modular you either wouldn't get stuck (new CPU module) and it would push OS makers into thinking more modular about their OSes rather than tailoring an OS release to whatever the latest hardware in the current model is.
More importantly than any of this, however, is that phone hardware is rapidly getting to PC performance levels and its getting very close to the idea that a smartphone could become a base module itself in a PC, possibly with a wide range of crossover (where PCs would actually use smartphone modules by default). Sure, you can do a bluetooth keyboard and HDMI output now, but it's less than what it could be.
Everyone always says the cars will charge late at night when demand is low, but is that a function of the charger gizmo on my garage wall or the car itself? I see people coming home from work and just plugging in the car to the wall as a matter of habit unless they have immediate plans to go someplace that evening because it will be a bitch to wake up and go to work and find that you didn't plug in and your battery doesn't have enough power to get you to work.
So in theory you could have a huge demand from 1730-1830 until 2200 or so. Maybe they will have some way for the car to query the grid to find out what the optimal amount of power it can draw at any given time.
Is it Slashdot or some new release of Chrome? I now notice I have my google account name on the top of the window and several pages don't render right, including slashdot five minutes ago (although it now looks right).
I'm curious if the neighborhood electric grid is scaled to support swapping out half or more of the 70-odd cars on the block for electric cars. Assuming a generic assortment of random cars charging at an average rate of 5kW that's a new load of 160kW.
It's probably not an issue in a cold climate in the winter (since it would balance out the power we'd normally use for air conditioning) but what about the summer?
And then I think, well, scale that up to the entire city and suddenly it seems like a whole power plant's worth of power.
So what's the actual impact on a given real system? How much extra memory would be consumed system-wide?
It would be interesting to do a statically linked build of FreeBSD to see how it would actually shake out in real life.
Microsoft could have been a long way towards this if they had *focused* on this instead of just sucking on Office revenue, trying to become a phone/tablet vendor and destroying desktop Windows with their bullshit Metro UI.
2012 could have been the OS where they introduced transparent application-specific VMs and Windows 10 could have been the OS where they added transparent DR/Azure migration and replication.
Instead they're still playing catch-up to VMware and I don't think they can be VMware anymore than they can be Apple.
The advantage they could have over VMware with application-level virtualization is that it would eliminate the need for the expensive VMware licensing and the expensive Windows licensing needed to isolate applications. But MS would probably fuck that up to and limit it to some lame level of virtualization per OS license.
I sure run into a lot of medium sized organizations that do nothing of the sort.
Most talk about it but when they see the price tag they get cold feet. The "better" ones will do some kind of off site setup, but it's often done with old equipment retired from production and some kind of copying/replication from the production site with little or no solid plan on how to actually bring up the remote site in a way that's useful.
The ones that seem the best off are the ones running VMware SRM.
But overall, yes, the situation isn't great.
I think some kind of sandboxing of software should be available and the default on every OS.
I sometimes wonder if the infinite monkeys concept applies here -- one one where if an infinite number monkeys have typewriters they will eventually write the works of Shakespeare.
Eventually, Microsoft will re-invent VM/CMS and we will have a system where every application can run or share a VM as determined by the operator.
For much of the Mac's history this was also the case. If you wanted an application, you just copied the damn thing from one media to another.
IIRC, it got worse over time on the Mac as apps got bigger (more supporting crap, stuff to copy to the System Folder, maybe a control panel or init, etc).
One in a while you run into applications, often utilities, that are truly standalone -- you can copy it to a new system and just run it. And then there are the various techniques for making portable apps, some kind of hand-done with a wrapper, others that scan a system before install and after and package all the deltas and use a wrapper after running to redirect all the various accesses.
I kind of blame shared libraries myself versus static linking. I've never quite groked the attraction of shared libraries. I get pilloried on Slashdot for saying this, of course. Usually its "ZOMG how will I patch my system when $library has a security weakness and 69 apps all use it" or "it takes too much disk space".
#1 is a fair criticism, I guess, but means little on Windows which seems to use less of that kind of a shared library, but I also wonder if there isn't a counter argument by which not every app statically linked to a common library will have the same bug and won't need updating. And it's not like updating a shared library is always risk-free; there's always the chance that an updated dependent library may change in some way that borks some of the apps that depend on it or some of the problems and cruft from several versions of the same library on the same system.
#2 seems like a bullshit criticism in this day and age. I'm curious what a "typical" OS install would be like space-wise if it was all statically linked.
And if you had all-statically linked applications, updating them to new versions would be just a matter of copying in a new version which seems simpler and more manageable to me for some reason.
Of course, none of this means much to apps which legitimately have a shit-ton of included resources which need to be shared system wide. Those have to go in their right places somehow, but if they are app specific they could just be in the same directory as the application. Maybe apps could um, register, their shared capability with the system so it would know to look for a resource in a virtual directory /app/resource/shared instead of a system-wide /resources directory -- the app itself remains self-contained, no installer required, and it could just register its capability at runtime with the system.
I'm not sure dedupe and compression are arguments for all-flash. Both of those things are heavily CPU bound, dedupe requires a block checksum computation and a lookup to find a match and compression takes computation.
My experience with dedupe is limited, but inline dedupe writes take a serious performance hit without relying on massive RAM cache to hold writes. Post-write dedupe makes for faster writes and doesn't really cost I/O because it can be done on a deferred basis when there is low I/O loads, which also helps with CPU consumption. Post-write dedupe can then be done to whatever disk with little penalty since it's background I/O.
I think deduped reads benefit from flash because the nature of deduped blocks is that they're not aligned with any file(s) and require a lot of random I/O -- the file request, a lookup for the deduped blocks that belong to file and then the random I/O of reading the non-aligned deduped blocks from dedupe store and the non-deduped blocks from the actual file.
This obviously would thrash spinning disk, but if you go back to the logic behind most tiered systems with flash disk it is unlikely to be a penalty for frequent reads since that data will already be on flash. Obviously flash/disk sizing ratios matter here, but the hybrid systems I've worked with usually have 1:5 ratios.
I don't see where all flash specifically aids snapshots -- most snapshots just collect write deltas, not complete duplicates of the LUN. Working with a handful of snapshots of a LUN isn't any more performance hit unless you regularly promote a snapshot to a complete volume.
And none of this is an argument against flash -- obviously it adds huge performance gains, my thought is just that in most cases the performance of hybrid flash gives nearly the same experience as all flash, provided that adequate flash tiers are provided and that the controller tiers blocks and not entire files.
Obviously there will be corner cases -- levels of I/O where tiering activity can't keep up, situations where nearly all data is read at about the same frequency where it can't be tiered efficiently, or massive flood writes that overwhelm flash landing zones and force writes to spinning disk. Tiering fails in these cases or is marginal in its effectiveness.
On paper at least, USB3 is supposed to support 625 MBytes/sec while the LTO6 is only capable of 160 MBytes/second, so in theory as a data bus, USB3 should be able to handle it.
IIRC, USB2 was polling driven and run at full rate would cause noticeable spikes in CPU utilization. My guess is that changed in some way for USB3 to support faster data rates, but I don't know how.
I use a USB3 gigabit NIC on my Surface Pro and I don't notice any network performance issues at all.
Most storage vendors make a big deal out of the fact (sometimes with actual data) that a lot of data isn't accessed often enough to warrant spending a premium on the storage medium it sits on and sell products that automatically track and tier blocks based on access frequency and writes.
As long as there is a big price gap between large 10k spinning disks and solid state, won't hybrid arrays still make economic sense? Unless you do something weird, you'll mostly have an all-flash experience but at $/TB prices closer to all disk. In this space, going all flash is just a waste -- 1,000,000 IOPs is great if you need 1,000,000 IOPS, but if you can only do 10k IOPS, isn't it just wasted IOPS?
If reliable SSD comes far enough down in price, dumping all spinning disk might make economic sense even if it isn't 1:1 parity in price because you can then ditch the complex block tracking and tiering systems which add a bunch of cost.
I like this idea, but:
LTO3 isn't big enough to be worth the headache of 2-3 tapes per TB. LTO5 would be very usable, but requires an annoying SAS card which are just expensive enough to make the whole solution a little spendy.
I'm mostly kidding about USB3, but I sort of wonder why you couldn't have a USB3 interface for a connection medium.
I think it would make a ton of sense for every organization to do a DR "drill" periodically where they attempt to actually use their DR plan (restore a group of servers, reload a switch configuration, etc).
This just seems like a sensible part of that.
What worries me, though, is how they will know when to actually implement a security plan and deal with the consequences. A lot of security breaches are subtle, and you don't know they've happened or at least not always with a definitive sign like a defacement page, etc.
I would assume a "real" security response would be something akin to putting a lot of resources "in lockdown" -- shutting down servers, cutting network links, etc, which could have major business consequences. I can see where uncertainty about a breech and hesitancy to isolate key systems (perhaps necessary to contain a breech) could lead to a real clusterfuck.
I think a key part of developing the plan is deciding when you know there is a real breach and making sure that the responses are well-known ahead of time to avoid a lot of head-scratching and internal conflict.
As much as I like to bash carriers, Google, handset makers, etc, much of the crux of this problem is that "progress" in the world of smartphone technology moves at such a rapid clip that by and large many things out there 2+ years old are in many ways obsolete and there's no easy way to go back and fix problems without just replacing devices on the consumer end.
I'm curious if smartphone technological advancements will slow down enough in the foreseeable future where this gets addressed sufficiently and you can expect fixes. By and large the PC world has been like this for a while, although it lacks the structural issues (ie, Google/Handset maker/carrier) that complicate it. Handsets are still advancing from a hardware perspective fairly quickly in terms of new chipsets that even if issue X could get fixed, the hardware itself isn't supported anymore.