Given how much cheaper the Chinese can be; one can't really blame Samsung for wanting to avoid becoming an undifferentiated board-stuffer for Google.
One can(and should) blame them for attempting to avoid this by making their atrocious software as mandatory as possible; rather than trying a bold experiment in not sucking at software.
They also have the minor problem of existing vending machines. I wouldn't be surprised if they actually believe that the tendency of current vending machines to mostly stock a tiny selection of soda, snacks, and candy is just because it's an ossified legacy industry that does not understand the glory of 'apps'; nor would I imagine that finding some VCs who share this belief will be tricky; but I would strongly suspect that they will either learn the hard way that current vending machine selection sucks because that's what keeps the cost of keeping the things stocked to acceptable levels; or (if they do have some amazing logistical plan), will find that existing vending machine operators will be much happier to adopt the new plan than they be to go out of business.
I'm aware of the various unofficial options; which work alright as long as the application you are trying to use doesn't actually rely more or less heavily on Google Play Services-provided APIs, in which case things tend to go downhill; but that isn't really an option if you are large enough for legal exposure to be a problem.
As for 'isn't really designed to be turned into an end-user-ready phone"; I agree that it can be done; and the experience can actually be pleasant in a minimalist sort of way; but without at least hitting F-Droid or the like, AOSP is pretty spartan; and there is a fairly long history of feature development in AOSP freezing in time at whatever point GPS started doing that feature; so stock AOSP is about as solid as Android gets in terms of being an OS; but can be kind of a history trip if you try to use the included applications.
Unless you just have to run every random thing in the Play store; you can certainly do without; and for purpose-build business widgets like the stuff in this article it's certainly more than viable as a convenient platform to dump your application on; but I'd stand by the assessment that someone who had previously only experienced commercial Android handsets would find an AOSP build to be a bit of a surprise; and note that while some of the 3rd party additions that really save the day are perfectly legal; the various 'and this is how you bodge in the Google components' FAQs aren't really an option outside of XDA.
Yes and no: the breach was down to a password, rather than an exploit; but designing with security in mind means keeping the weaknesses of your materials in mind:
Apple's enthusiasm to make iCloud the has-all-your-stuff-and-controls-all-your-devices cool convenience hub was understandable in terms of creating a feature that users who barely know about backups, much less make them, would find valuable(especially in the context of mobile devices which get replaced/lost/broken/stolen a lot and don't tend to have "insert flash drive, drag and drop 'my documents' level backup/transfer features).
From the perspective of security, though, putting all that high-value stuff behind a single password(with basic cheap 'n awful consumer password recovery options) is sort of like building a safe with no bottom; then arguing "it's up to the customer to put it on a floor at least as breach resistant as the safe!". Doesn't mean that the lock on the door is flawed; but it isn't a good design.
At any scale(even a small business IT operation); users periodically fucking up passwords/getting phished/etc. is just something you have to expect and design around. Apple's iCloud security arrangement really didn't do that.
Unless Target is developing their in-house(or contracted; but with more say over the product than your basic shrinkwrap consumer) against Google Play Services (or, even more foolishly, some OEM's pet extensions); they aren't really all that dependent on Google.
AOSP isn't really designed to be turned into an end-user-ready phone; and lacking Play store, the various Google apps and services, etc. is typically a deal breaker unless you swap in your own (as with Amazon); but if you are treating it as a substitute for the WinCE that historically powered these sorts of fancy-inventory-scanners; or as an easier-to-go-from-BSP-to-graphics-and-a-well-known-platform alternative to rolling a custom Linux frmware; you don't really depend on Google much.
They don't develop AOSP terribly openly, it's pretty much periodic dumps of their project and their plan; but the licensing is open, so you can just keep using it until you can't get hardware for that version anymore, or doing your own security patches gets to be too much; and the AOSP base isn't missing anything particularly glaring for supporting network, barcode scanner, QR/other interpretation from the camera, some dodgy frontend application that supports talking to your inventory system and displaying bits of your web site.
Once you connect something to a network, you aren't going to get nigh-endless support without paying a vendor to care(since the cost of just ignoring security flaws is so much higher); but, especially if you are only using a subset of features, AOSP doesn't exert much control over you if you use it as a base for your firmware.
And, given the specific requirements of retail inventory(durability, battery life, high speed barcode scanning, etc.) you are probably pushing the bounds of what makes sense to try to COTS with just a custom phone case of some sort(unless you are running an operation small enough that the low prices and economies of scale persuade you to forgive a few sins in exchange for being able to buy replacements in quantity one at any cellphone pusher.
At least with POS systems, this seems to have been much what has happened: Square and their imitators blew the bottom out of the market by allowing you to turn normal phone into a cellular card processing terminal(normally a surprisingly pricey item); and there are some mostly small-business focused "iPad embedded in stand/card reader" products; but your Micros and NCR and the like seem to have substantially gone with clearly tablet inspired(and tablet component based, I'm sure they appreciated having touchscreens become cheap and ubiquitous; even if Elo almost certainly didn't) custom hardware running some generic Android based firmware that does nothing except support their application. Once you stamp out enough of them, being stuck with somebody else's product launch cycle, endless changes, and irrelevant features just doesn't make up for the low cost of small quantity orders.
What you describe is(for the most part) what 'airplay' is(but only if you are fully immersed in the Apple universe); and what 'miricast' is slightly wonkier and less predictable about being; but widely available across Windows and Android(not actually sure if Macs can do it; though it requires no hardware features except a modestly recent wifi chipset, so if they can't it's for want of software, not a hardware thing).
Things aren't all rosy(as noted, miricast devices and support; since just about anyone can offer them, are a bit uneven; and since 'airplay' appears to have been designed around home users with a handful of devices on one router; bodging it into a large network can be annoying; and trying to get the right conference room; rather than the other 50 that are on the same LAN, to display can be fiddly); but as long as the modest latency and compression introduced by the arrangement being an H.264 stream over a wifi connection aren't an issue; these give you most of the 'connect to the display without wires!' experience with basically no special requirements on the client side and a relatively cheap little box on the monitor side.
To the degree that there is actual demand for wireless video; I suspect that both of these helped bury the fancy 60GHz version; which is better under specific circumstances; but pricey, works only with specific hardware, has poorer range and LoS constraints, etc. Mediocre and adequate has a way of doing that. That, and VGA is too dumb to know that it is obsolete, so just keeps on working.
Their enterprise support still has moments of competence. It's usually a good sign if you run into part of it that still hasn't had the IBM badges filed off; I'm not sure if this represents actual institutional inertia that has spared these areas; or whether there are pockets of resistance among the employees that have made failing to update their paperwork a signal of adherence to the old ways; but in my experience it is a good sign when you get one of them.
Anything explicitly Lenovo, without a history of once having been better, though...
The concept had its uses(though, without some wireless charging arrangement, the utility of a 'dock' that made your laptop battery drain a bit faster(because running that multi-Gb wireless link isn't free) was always a bit troublesome.
For the things that already have reasonably sane and standardized 'over-IP' or bluetooth flavors; a wireless dock doesn't make a whole lot of sense because 'no dock' is pretty close to a wireless dock: you just dump your laptop on your desk, wifi connection handles network, file shares, printers; bluetooth peripherals reconnect in pretty short order when you come into range and you are 'docked'.
The Intel 60GHz thing(it was a pair of SKUs, one card for adding support to the client system, plus the W13100 "Wireless Gigabity Sink" part designed to build a docking station around) was aimed mostly at shoving the interfaces without good wireless abstractions over a wireless link: video(yes, 'airplay', 'miricast', etc. can do an OK job of 'wireless display' by sending an H.264 stream to a device that expects it; but they don't work with dumb monitors; and don't tend to work with software that isn't explicitly expecting them; so they aren't really an option for the "dump laptop in dock, receive dual monitors" use case) USB(there are various vendor specific hacks; but unless the USB device can be shared out at a higher level, like a printer or a mass storage device, there isn't really network-transparent USB support; the USB network extenders that do exist can be pretty dodgy and generally require fiddly drivers) and ethernet(probably the least useful for end users; since wifi is a direct substitute; but when IT wants to PXE boot...)
Even so, the niche was pretty limited, when you could get the same features, plus charging, for less money(and without a fan in your docking station; most models had a nice noisy 60mm, users loved that) in exchange for going to slightly more effort and mechanically docking. Plus, while fast, the WiGig link wasn't fast enough for fully transparent transport of things like video; and range was severely compromised if line of sight wasn't available. Plus, there were some very unpleasant Gen1 quirks and power management bugs, depending on the model.
Not really a surprise that it didn't do so well. It did offer capabilities that other things didn't(and still don't); but wired docks were doing all of that better and cheaper, with charging; and since the arrangement relied on the 60GHz radio(I'm not sure if falling back to the more usual wifi bands just wasn't implemented, or didn't offer nearly enough bandwidth to handle things like dock video without egregious compression; either way it wasn't an option); you had to be pretty close to the docking station for it to work, so the extra effort of mechanical docking was limited.
If it had gained broader acceptance; it probably could have been a winning 'enterprise' equivalent of miricast/airplay for conference room video and the like; but since those work with mostly cheap and common hardware at the expense of some relatively minor H.264 artifacts, they are a hard target for an expensive, model specific, fancy interconnect to compete with. For docking; things were bad enough with the various proprietary(but mostly functional) docks sold with 'business' laptops since forever; and they are worse now that TB3 and USB-C allow you to get full dock bandwidth out of a single connector.
There's also an inherent tension: a technique for making the gathering and retention of highly granular metadata, allowing you to watch the final song/other media thing come together like it's a program under revision control would be pretty cool. Some people wouldn't like it because it would be a dig against their theory that they are a freestanding genius or whatever; but it would be pretty cool information; and making it not a giant PITA to gather would be step #1 in ever having it gathered.
However, if you tie that plan to 'so we can get a micopayment for every last bit'; you suddenly create a gigantic incentive for people to deliberately munge the metadata/break the chain of custody, by whatever means are available (whether it be simple metadata stripping over analog hole stuff). That sort of pervasive tracing has been a 'trusted computing'/DRM wet dream since forever; and that has never helped it's popularity. People hate taking notes as it is; why expect better recordkeeping if you get financially punished for it?
This seems like a situation where 'blockchain' is both hopelessly outmatched and overkill.
Even the most elegant and fastidious cryptographic verification methods do absolutely nothing to prevent your metadata from being garbage; people can still fail to enter it, enter it inaccurately or dishonestly, enter it correctly for an entity that will be impossible to find two decades from now(or have its own byzantine chain of custody; as in the case of the assets of a dissolved corporation, say); and without people thoroughly, accurately, and honestly filling out a bunch of tedious paperwork, the crypto does little more than help make the garbage look authoritative.
It is certainly true that some metadata schemes are too constrained to track all the information one would like(ID3 tags, say, especially the early versions, are pretty limited); but anyone who thinks that the problem of people not filling out and maintaining basic records is a problem that can be solved by throwing advanced record technology at it should really ponder the shattered dreams of the 'semantic web' for a few minutes.
It's not as though this is a surprise or anything; but it's a pitiful follow-up to their, um, 'optimistic' pricing practices.
The whole selling point of their product is reliable delivery even by an unskilled user under duress. The epinephrine is a cheap generic; the autoinjector is $600 of mechanism wrapped around it.
For that kind of money you deserve excellence; and they don't even appear to be delivering enough to avoid credible charges of negligence. That's just pitiful.
I'd be pleased to see it work; but also apprehensive about whether being able to achieve kills against specific tumors(the well defined, encapsulated ones) translates into better survival of cancer.
Something you can do by injection is cheaper and less traumatic than surgery; and alcohol may well be an agent with a nice combination of being amply lethal to cancer cells at high concentration; but pretty well tolerated by humans in modest concentrations(which would make any leaks from the tumor into surrounding tissue a lot safer than those of other chemicals chosen for lethality); but even an absolutely ideal mechanism for killing neatly encapsulated tumors is orthogonal to the problem if the cancer in question is metastasizing and/or invading healthy tissue in much smaller, more widely diffused, growths that can't be neatly targeted in the same way.
You also have a problem if either the injection process or the death of the tumor allow tend to dislodge cancer cells and send them back into circulation to seed tumors elsewhere. That's one of the reasons why surgical removal can be particularly messy: you take a margin of healthy tissue around the tumor because you Do Not want to either leave a bit of tumor that can just regrow; or risk little tumor fragments being liberated during surgery and leaving the patient with an even more serious problem once they've had time to grow a bit.
If it does work, all well and good, certainly seems preferable to surgical excision; but "the problem is one, or a small number, of well defined and encapsulated tumors" is a comparatively well behaved instance of cancer.
I think your argument should take opportunity cost into account: it is true that the poor often have kids(generally higher fertility rates than the middle class; not sure about the wealthy, though they simply aren't numerous enough to be a terribly important population-level supply of children); but consider the difference in opportunity costs.
If you are middle class, or at least on the right side of poor, the message(and it isn't entirely a lie, though the student debt will hurt; and some majors aren't worth much) is "stay in school, work hard, get into a decent college, get a real job, then you'll have a chance at economic stability, living somewhere safe and with decent schools, etc. If you don't do that; people with a high school diploma or less are basically screwed, you'll be doomed, and so on." Sometimes exaggerated; but strongly emphasized and by no means entirely false. In the face of those incentives, unless you are particularly dumb, impulsive, or powerless enough that it isn't a choice, deferring children is pretty sensible behavior(both for men and women; though the fact that pregnancy and child rearing are time consuming as well as expensive likely means that women are even more likely to have to halt school or work because they just don't have time for both; while child support will be a real punch in the wallet; but not directly time consuming; and a situation where they want you to be working and earning as much as possible).
Among the poor, by contrast, the message is vastly less optimistic about the rewards of deferring children(one can blame 'culture'; bad role models, etc; and that may have a role; but it is hard to deny that people educated in really lousy school districts and with limited means to pay for college(scholarships and aid tend to cover tuition and room and board; but incidentals and foregone wages because of the time you aren't working still hit harder) simply have less reason to expect that their situation will improve if they defer children: your earning potential doesn't just magically increase with age; you need to obtain the appropriate degree, experience, promotion, etc.
Obviously, children are themselves expensive, so having them tends to make you poorer; but approximately a zillion years of evolution have left people, on the whole, liking children and the idea of reproducing, so just trying "tell them not to breed" doesn't work all that well. The poor face an overall grimmer situation; but also have little to gain by deferring children if they do want them. The middle class is offered much more convincing assurances that having children later might actually leave them better off.
Given that fertility medicine is also quite expensive; and somewhat tepidly effective(and the various child medical issues that become more of a risk with parental age are wildly expensive), I'm not sure how many decades of room this trend has to continue... The economic pressures sure don't seem to be going away; but attempts to bend the biological constraints have only been somewhat effective.
Anyone know how the kill is implemented? Was the original firmware set with an expiration date, in anticipation of it receiving an exciting and mandatory upgrade; so the deadline was baked in from day one? Did some earlier, smaller, update quietly add this 'feature' to be announced at a later time? Is there no change whatsoever in the drone's behavior; but some companion app does a version check before it issues any flight commands; and will be updated to refuse to talk to the older version?
Regardless of implementation, this is a fine testament to the advantages of products that spend their entire lives phoning home to the vendor; but some implementations are even worse than others.
I wouldn't be surprised if the combination of bitrate, codec, resolution, and other merely technical playback details could actually be pretty revealing with a little inferential work: even if you count only the strictly standard ones, there are tons of variations, levels and optional features under the heading of "H.264"; more still if you are looking at implementation specific oddities(which you probably have to for the data to be useful for debugging/development purposes). For suing purposes, it would definitely be easier to explain filenames or maybe hashes to a judge; but I strongly suspect that picking out that guy with a collection of media that are encoded with Leaks Release Kr3w's favorite encoder settings wouldn't be all that difficult.
One can understand why Plex would have an interest in what corner cases need attention; but this is one of those "metadata, actually pretty much just data." situations; and it would be seriously disingenuous of them to exaggerate how 'anonymized' it is in practice; and unacceptable for them to collect it on a mandatory basis. If it's so beneficial to customers, surely they'll opt in? Or you can offer a more targeted "playback of this was screwed up. report media details?" option(just as crash reporting has traditionally been handled).
I wonder if they are just optimistic about the buy-in; or if they are angling for a specific flavor of customer: someone whose IT setup requires the ability to get a vendor specific FRU swapped out in short order is probably better served just putting it in a less hostile location. You'll pay slightly more; but it's not like finding a colo in the cheaper suburbs of a large number of nontrivial cities is terribly difficult; and those will be in range of your vendor's warranty coverage and your preferred shipping service's overnight offerings(and if you choose the one near you, you can have one of your people go poke it in person without it turning into a business trip). If your IT setup involves container loads of semi-expendable, identical, hardware with most of the redundancy in your fancy software layer; then the possibility of paying less to feed and cool it, at the cost of only having access to spares you provide and repairs you train the staff on, is a more interesting possibility. Only relatively standardized, mature, offerings would be viable; but if you happen to be one of the big 'cloud' types who needs to run ten zillion instances of the same thing at the absolute lowest cost...
If there were anything worth bothering with here, I might be slightly concerned about it's apparently questionable viability. Luckily that isn't a problem.
It seems like an especially strange choice given that nothing else about Apple's campus says "we are trying to save money by scrimping on the building here". Their HQ employees(not counting retail workers and indirect employees at contract manufacturers) are also relatively few, relatively expensive, and involved in making the highly profitable stuff happen.
It's hard to think of a less sensible place to go open-plan. Was their kool-aid during the architectural planning session? Some understimulated extrovert in management just dreaming of having his own noise-drome to stride through, bothering people? What possible advantage is there?
Meh. If everything goes fine, that just proves that regulation is unnecessarily burdensome. If not; it's just "disrupting legacy infrastructure", and the investors love that. Can't lose!
If anything, they seem like an even more sensible target for careful permitting. Even if this wasn't in LA, with the accompanying seismic issues, drilling around under people's foundations, buried lines and pipes, etc. is something you have to do rather carefully if you don't want to cause considerable damage, run into unexpected stuff, or both.
Slashdot Mirror
This article is clearly a lie. How can a mythological entity have a PGP key?
Given how much cheaper the Chinese can be; one can't really blame Samsung for wanting to avoid becoming an undifferentiated board-stuffer for Google.
One can(and should) blame them for attempting to avoid this by making their atrocious software as mandatory as possible; rather than trying a bold experiment in not sucking at software.
They also have the minor problem of existing vending machines. I wouldn't be surprised if they actually believe that the tendency of current vending machines to mostly stock a tiny selection of soda, snacks, and candy is just because it's an ossified legacy industry that does not understand the glory of 'apps'; nor would I imagine that finding some VCs who share this belief will be tricky; but I would strongly suspect that they will either learn the hard way that current vending machine selection sucks because that's what keeps the cost of keeping the things stocked to acceptable levels; or (if they do have some amazing logistical plan), will find that existing vending machine operators will be much happier to adopt the new plan than they be to go out of business.
I'm aware of the various unofficial options; which work alright as long as the application you are trying to use doesn't actually rely more or less heavily on Google Play Services-provided APIs, in which case things tend to go downhill; but that isn't really an option if you are large enough for legal exposure to be a problem.
As for 'isn't really designed to be turned into an end-user-ready phone"; I agree that it can be done; and the experience can actually be pleasant in a minimalist sort of way; but without at least hitting F-Droid or the like, AOSP is pretty spartan; and there is a fairly long history of feature development in AOSP freezing in time at whatever point GPS started doing that feature; so stock AOSP is about as solid as Android gets in terms of being an OS; but can be kind of a history trip if you try to use the included applications.
Unless you just have to run every random thing in the Play store; you can certainly do without; and for purpose-build business widgets like the stuff in this article it's certainly more than viable as a convenient platform to dump your application on; but I'd stand by the assessment that someone who had previously only experienced commercial Android handsets would find an AOSP build to be a bit of a surprise; and note that while some of the 3rd party additions that really save the day are perfectly legal; the various 'and this is how you bodge in the Google components' FAQs aren't really an option outside of XDA.
Yes and no: the breach was down to a password, rather than an exploit; but designing with security in mind means keeping the weaknesses of your materials in mind:
Apple's enthusiasm to make iCloud the has-all-your-stuff-and-controls-all-your-devices cool convenience hub was understandable in terms of creating a feature that users who barely know about backups, much less make them, would find valuable(especially in the context of mobile devices which get replaced/lost/broken/stolen a lot and don't tend to have "insert flash drive, drag and drop 'my documents' level backup/transfer features).
From the perspective of security, though, putting all that high-value stuff behind a single password(with basic cheap 'n awful consumer password recovery options) is sort of like building a safe with no bottom; then arguing "it's up to the customer to put it on a floor at least as breach resistant as the safe!". Doesn't mean that the lock on the door is flawed; but it isn't a good design.
At any scale(even a small business IT operation); users periodically fucking up passwords/getting phished/etc. is just something you have to expect and design around. Apple's iCloud security arrangement really didn't do that.
Unless Target is developing their in-house(or contracted; but with more say over the product than your basic shrinkwrap consumer) against Google Play Services (or, even more foolishly, some OEM's pet extensions); they aren't really all that dependent on Google.
AOSP isn't really designed to be turned into an end-user-ready phone; and lacking Play store, the various Google apps and services, etc. is typically a deal breaker unless you swap in your own (as with Amazon); but if you are treating it as a substitute for the WinCE that historically powered these sorts of fancy-inventory-scanners; or as an easier-to-go-from-BSP-to-graphics-and-a-well-known-platform alternative to rolling a custom Linux frmware; you don't really depend on Google much.
They don't develop AOSP terribly openly, it's pretty much periodic dumps of their project and their plan; but the licensing is open, so you can just keep using it until you can't get hardware for that version anymore, or doing your own security patches gets to be too much; and the AOSP base isn't missing anything particularly glaring for supporting network, barcode scanner, QR/other interpretation from the camera, some dodgy frontend application that supports talking to your inventory system and displaying bits of your web site.
Once you connect something to a network, you aren't going to get nigh-endless support without paying a vendor to care(since the cost of just ignoring security flaws is so much higher); but, especially if you are only using a subset of features, AOSP doesn't exert much control over you if you use it as a base for your firmware.
And, given the specific requirements of retail inventory(durability, battery life, high speed barcode scanning, etc.) you are probably pushing the bounds of what makes sense to try to COTS with just a custom phone case of some sort(unless you are running an operation small enough that the low prices and economies of scale persuade you to forgive a few sins in exchange for being able to buy replacements in quantity one at any cellphone pusher.
At least with POS systems, this seems to have been much what has happened: Square and their imitators blew the bottom out of the market by allowing you to turn normal phone into a cellular card processing terminal(normally a surprisingly pricey item); and there are some mostly small-business focused "iPad embedded in stand/card reader" products; but your Micros and NCR and the like seem to have substantially gone with clearly tablet inspired(and tablet component based, I'm sure they appreciated having touchscreens become cheap and ubiquitous; even if Elo almost certainly didn't) custom hardware running some generic Android based firmware that does nothing except support their application. Once you stamp out enough of them, being stuck with somebody else's product launch cycle, endless changes, and irrelevant features just doesn't make up for the low cost of small quantity orders.
What you describe is(for the most part) what 'airplay' is(but only if you are fully immersed in the Apple universe); and what 'miricast' is slightly wonkier and less predictable about being; but widely available across Windows and Android(not actually sure if Macs can do it; though it requires no hardware features except a modestly recent wifi chipset, so if they can't it's for want of software, not a hardware thing).
Things aren't all rosy(as noted, miricast devices and support; since just about anyone can offer them, are a bit uneven; and since 'airplay' appears to have been designed around home users with a handful of devices on one router; bodging it into a large network can be annoying; and trying to get the right conference room; rather than the other 50 that are on the same LAN, to display can be fiddly); but as long as the modest latency and compression introduced by the arrangement being an H.264 stream over a wifi connection aren't an issue; these give you most of the 'connect to the display without wires!' experience with basically no special requirements on the client side and a relatively cheap little box on the monitor side.
To the degree that there is actual demand for wireless video; I suspect that both of these helped bury the fancy 60GHz version; which is better under specific circumstances; but pricey, works only with specific hardware, has poorer range and LoS constraints, etc. Mediocre and adequate has a way of doing that. That, and VGA is too dumb to know that it is obsolete, so just keeps on working.
Their enterprise support still has moments of competence. It's usually a good sign if you run into part of it that still hasn't had the IBM badges filed off; I'm not sure if this represents actual institutional inertia that has spared these areas; or whether there are pockets of resistance among the employees that have made failing to update their paperwork a signal of adherence to the old ways; but in my experience it is a good sign when you get one of them.
Anything explicitly Lenovo, without a history of once having been better, though...
The concept had its uses(though, without some wireless charging arrangement, the utility of a 'dock' that made your laptop battery drain a bit faster(because running that multi-Gb wireless link isn't free) was always a bit troublesome.
For the things that already have reasonably sane and standardized 'over-IP' or bluetooth flavors; a wireless dock doesn't make a whole lot of sense because 'no dock' is pretty close to a wireless dock: you just dump your laptop on your desk, wifi connection handles network, file shares, printers; bluetooth peripherals reconnect in pretty short order when you come into range and you are 'docked'.
The Intel 60GHz thing(it was a pair of SKUs, one card for adding support to the client system, plus the W13100 "Wireless Gigabity Sink" part designed to build a docking station around) was aimed mostly at shoving the interfaces without good wireless abstractions over a wireless link: video(yes, 'airplay', 'miricast', etc. can do an OK job of 'wireless display' by sending an H.264 stream to a device that expects it; but they don't work with dumb monitors; and don't tend to work with software that isn't explicitly expecting them; so they aren't really an option for the "dump laptop in dock, receive dual monitors" use case) USB(there are various vendor specific hacks; but unless the USB device can be shared out at a higher level, like a printer or a mass storage device, there isn't really network-transparent USB support; the USB network extenders that do exist can be pretty dodgy and generally require fiddly drivers) and ethernet(probably the least useful for end users; since wifi is a direct substitute; but when IT wants to PXE boot...)
Even so, the niche was pretty limited, when you could get the same features, plus charging, for less money(and without a fan in your docking station; most models had a nice noisy 60mm, users loved that) in exchange for going to slightly more effort and mechanically docking. Plus, while fast, the WiGig link wasn't fast enough for fully transparent transport of things like video; and range was severely compromised if line of sight wasn't available. Plus, there were some very unpleasant Gen1 quirks and power management bugs, depending on the model.
Not really a surprise that it didn't do so well. It did offer capabilities that other things didn't(and still don't); but wired docks were doing all of that better and cheaper, with charging; and since the arrangement relied on the 60GHz radio(I'm not sure if falling back to the more usual wifi bands just wasn't implemented, or didn't offer nearly enough bandwidth to handle things like dock video without egregious compression; either way it wasn't an option); you had to be pretty close to the docking station for it to work, so the extra effort of mechanical docking was limited.
If it had gained broader acceptance; it probably could have been a winning 'enterprise' equivalent of miricast/airplay for conference room video and the like; but since those work with mostly cheap and common hardware at the expense of some relatively minor H.264 artifacts, they are a hard target for an expensive, model specific, fancy interconnect to compete with. For docking; things were bad enough with the various proprietary(but mostly functional) docks sold with 'business' laptops since forever; and they are worse now that TB3 and USB-C allow you to get full dock bandwidth out of a single connector.
There's also an inherent tension: a technique for making the gathering and retention of highly granular metadata, allowing you to watch the final song/other media thing come together like it's a program under revision control would be pretty cool. Some people wouldn't like it because it would be a dig against their theory that they are a freestanding genius or whatever; but it would be pretty cool information; and making it not a giant PITA to gather would be step #1 in ever having it gathered.
However, if you tie that plan to 'so we can get a micopayment for every last bit'; you suddenly create a gigantic incentive for people to deliberately munge the metadata/break the chain of custody, by whatever means are available (whether it be simple metadata stripping over analog hole stuff). That sort of pervasive tracing has been a 'trusted computing'/DRM wet dream since forever; and that has never helped it's popularity. People hate taking notes as it is; why expect better recordkeeping if you get financially punished for it?
This seems like a situation where 'blockchain' is both hopelessly outmatched and overkill.
Even the most elegant and fastidious cryptographic verification methods do absolutely nothing to prevent your metadata from being garbage; people can still fail to enter it, enter it inaccurately or dishonestly, enter it correctly for an entity that will be impossible to find two decades from now(or have its own byzantine chain of custody; as in the case of the assets of a dissolved corporation, say); and without people thoroughly, accurately, and honestly filling out a bunch of tedious paperwork, the crypto does little more than help make the garbage look authoritative.
It is certainly true that some metadata schemes are too constrained to track all the information one would like(ID3 tags, say, especially the early versions, are pretty limited); but anyone who thinks that the problem of people not filling out and maintaining basic records is a problem that can be solved by throwing advanced record technology at it should really ponder the shattered dreams of the 'semantic web' for a few minutes.
It's not as though this is a surprise or anything; but it's a pitiful follow-up to their, um, 'optimistic' pricing practices.
The whole selling point of their product is reliable delivery even by an unskilled user under duress. The epinephrine is a cheap generic; the autoinjector is $600 of mechanism wrapped around it.
For that kind of money you deserve excellence; and they don't even appear to be delivering enough to avoid credible charges of negligence. That's just pitiful.
I'd be pleased to see it work; but also apprehensive about whether being able to achieve kills against specific tumors(the well defined, encapsulated ones) translates into better survival of cancer.
Something you can do by injection is cheaper and less traumatic than surgery; and alcohol may well be an agent with a nice combination of being amply lethal to cancer cells at high concentration; but pretty well tolerated by humans in modest concentrations(which would make any leaks from the tumor into surrounding tissue a lot safer than those of other chemicals chosen for lethality); but even an absolutely ideal mechanism for killing neatly encapsulated tumors is orthogonal to the problem if the cancer in question is metastasizing and/or invading healthy tissue in much smaller, more widely diffused, growths that can't be neatly targeted in the same way.
You also have a problem if either the injection process or the death of the tumor allow tend to dislodge cancer cells and send them back into circulation to seed tumors elsewhere. That's one of the reasons why surgical removal can be particularly messy: you take a margin of healthy tissue around the tumor because you Do Not want to either leave a bit of tumor that can just regrow; or risk little tumor fragments being liberated during surgery and leaving the patient with an even more serious problem once they've had time to grow a bit.
If it does work, all well and good, certainly seems preferable to surgical excision; but "the problem is one, or a small number, of well defined and encapsulated tumors" is a comparatively well behaved instance of cancer.
Looks like it isn't just Hollywood trying to turn old franchises into blockbusters this year.
I think your argument should take opportunity cost into account: it is true that the poor often have kids(generally higher fertility rates than the middle class; not sure about the wealthy, though they simply aren't numerous enough to be a terribly important population-level supply of children); but consider the difference in opportunity costs.
If you are middle class, or at least on the right side of poor, the message(and it isn't entirely a lie, though the student debt will hurt; and some majors aren't worth much) is "stay in school, work hard, get into a decent college, get a real job, then you'll have a chance at economic stability, living somewhere safe and with decent schools, etc. If you don't do that; people with a high school diploma or less are basically screwed, you'll be doomed, and so on." Sometimes exaggerated; but strongly emphasized and by no means entirely false. In the face of those incentives, unless you are particularly dumb, impulsive, or powerless enough that it isn't a choice, deferring children is pretty sensible behavior(both for men and women; though the fact that pregnancy and child rearing are time consuming as well as expensive likely means that women are even more likely to have to halt school or work because they just don't have time for both; while child support will be a real punch in the wallet; but not directly time consuming; and a situation where they want you to be working and earning as much as possible).
Among the poor, by contrast, the message is vastly less optimistic about the rewards of deferring children(one can blame 'culture'; bad role models, etc; and that may have a role; but it is hard to deny that people educated in really lousy school districts and with limited means to pay for college(scholarships and aid tend to cover tuition and room and board; but incidentals and foregone wages because of the time you aren't working still hit harder) simply have less reason to expect that their situation will improve if they defer children: your earning potential doesn't just magically increase with age; you need to obtain the appropriate degree, experience, promotion, etc.
Obviously, children are themselves expensive, so having them tends to make you poorer; but approximately a zillion years of evolution have left people, on the whole, liking children and the idea of reproducing, so just trying "tell them not to breed" doesn't work all that well. The poor face an overall grimmer situation; but also have little to gain by deferring children if they do want them. The middle class is offered much more convincing assurances that having children later might actually leave them better off.
Given that fertility medicine is also quite expensive; and somewhat tepidly effective(and the various child medical issues that become more of a risk with parental age are wildly expensive), I'm not sure how many decades of room this trend has to continue... The economic pressures sure don't seem to be going away; but attempts to bend the biological constraints have only been somewhat effective.
Anyone know how the kill is implemented? Was the original firmware set with an expiration date, in anticipation of it receiving an exciting and mandatory upgrade; so the deadline was baked in from day one? Did some earlier, smaller, update quietly add this 'feature' to be announced at a later time? Is there no change whatsoever in the drone's behavior; but some companion app does a version check before it issues any flight commands; and will be updated to refuse to talk to the older version?
Regardless of implementation, this is a fine testament to the advantages of products that spend their entire lives phoning home to the vendor; but some implementations are even worse than others.
When he said "just plain illegal to possess"; I suspect he meant kiddie porn. MPAA doesn't care; but the feds do.
I wouldn't be surprised if the combination of bitrate, codec, resolution, and other merely technical playback details could actually be pretty revealing with a little inferential work: even if you count only the strictly standard ones, there are tons of variations, levels and optional features under the heading of "H.264"; more still if you are looking at implementation specific oddities(which you probably have to for the data to be useful for debugging/development purposes). For suing purposes, it would definitely be easier to explain filenames or maybe hashes to a judge; but I strongly suspect that picking out that guy with a collection of media that are encoded with Leaks Release Kr3w's favorite encoder settings wouldn't be all that difficult.
One can understand why Plex would have an interest in what corner cases need attention; but this is one of those "metadata, actually pretty much just data." situations; and it would be seriously disingenuous of them to exaggerate how 'anonymized' it is in practice; and unacceptable for them to collect it on a mandatory basis. If it's so beneficial to customers, surely they'll opt in? Or you can offer a more targeted "playback of this was screwed up. report media details?" option(just as crash reporting has traditionally been handled).
I wonder if they are just optimistic about the buy-in; or if they are angling for a specific flavor of customer: someone whose IT setup requires the ability to get a vendor specific FRU swapped out in short order is probably better served just putting it in a less hostile location. You'll pay slightly more; but it's not like finding a colo in the cheaper suburbs of a large number of nontrivial cities is terribly difficult; and those will be in range of your vendor's warranty coverage and your preferred shipping service's overnight offerings(and if you choose the one near you, you can have one of your people go poke it in person without it turning into a business trip). If your IT setup involves container loads of semi-expendable, identical, hardware with most of the redundancy in your fancy software layer; then the possibility of paying less to feed and cool it, at the cost of only having access to spares you provide and repairs you train the staff on, is a more interesting possibility. Only relatively standardized, mature, offerings would be viable; but if you happen to be one of the big 'cloud' types who needs to run ten zillion instances of the same thing at the absolute lowest cost...
If there were anything worth bothering with here, I might be slightly concerned about it's apparently questionable viability. Luckily that isn't a problem.
It seems like an especially strange choice given that nothing else about Apple's campus says "we are trying to save money by scrimping on the building here". Their HQ employees(not counting retail workers and indirect employees at contract manufacturers) are also relatively few, relatively expensive, and involved in making the highly profitable stuff happen.
It's hard to think of a less sensible place to go open-plan. Was their kool-aid during the architectural planning session? Some understimulated extrovert in management just dreaming of having his own noise-drome to stride through, bothering people? What possible advantage is there?
Meh. If everything goes fine, that just proves that regulation is unnecessarily burdensome. If not; it's just "disrupting legacy infrastructure", and the investors love that. Can't lose!
If anything, they seem like an even more sensible target for careful permitting. Even if this wasn't in LA, with the accompanying seismic issues, drilling around under people's foundations, buried lines and pipes, etc. is something you have to do rather carefully if you don't want to cause considerable damage, run into unexpected stuff, or both.
I can't imagine why people think that "move fast and break things" isn't a suitable standard for civil engineering. Must be communist influences.