In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.
“Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)
Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory. It is something specific to Intel CPUs.
In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register. That means that speculative execution might get pas memory protection.
Your run a piece of software, your piece of software tries to read stuff from the kernel, the CPU does it speculatively, touches a few cache, and only then kicks the execution out. You can guess stuff by measuring which caches were touchs.
It works to get across the kernel/user-space boundaries. Gives you ability to peek into the kernel memory space. It's madness that completely fucks up the base guaranties that memory protection is supposed to provide.
AMD CPU are confirmed to be not affected (they do the costly memory protection earlier and refuse to access protected memory).
Only a couple of ARM Cortex cores seem to be affected (basically only Cortex-A75 is affect in a way that is actually exploitable, according to ARM).
Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.
Please pay attention that there are 2 different Spectre attacks.
Variant 1 is just speculative execution working as it is supposed to do. If there's a condition (an "if" in the code) the predictor will try to guess which code path is the most likely to be taken, and speculatively execute that one. If the guess was wrong, the CPU throws the computation an restarts the correct branch. (but again, cache might have moved around and is something that is indirectly measurable).
If the condition is a boundary check, is might get skipped and CPU attempts to speculatively execute reads that are outside the bounds. That's still reads to memory that should be accessible to the application anyway (meh). That would just cause the application to read one of it other's variable, instead of the array. It's only a potentially exploitable situation when the application should not read it own data. Usually situations where arbitrary externally provided code reside in the same process as secret data. (And you basically deserve what you get for mixing sensitive data and arbitrary remote code in the same process). Google example is done by sending eBFP a special type of bytecode used by modern packet-filters to the kernel. It's get jitted to machine code, and such code can read past its boundary speculatively. Possible other exploit are sending specially crafted Javascript (there's a ASM.js demo floating on the web) or WASM, to a browser which JIT it and execute it. The code translate into a bound check, and could read any other part of the memory inside
Well at least, look on the bright side : even if you brick the mainboard into an unbootable state with the bad firmware upgrade, you can still log into the Intel ME / Intel AMT web-interface running on the ARC core in the chipset, and flash another version from there.
Better than needing to physically walk to the bricked machine, open it, remove the firmware EEPROM chip from the socket, put it into your own EEPROM programmer, reflash a different version and put it back together.
A.K.A.: the only time where Intel AMT works as it should and is actually useful. A.K.A.: even a stopped clock is right twice a day.
ARM is probably the only one of the chipmakers doing the right thing here. Information is quick, public, to the point and fixes are deployed as soon as they are done. There are performance issues with ARM patches but they are taken as necessary.
They just got lucky to be right most of the time. (Helps that they use a much simpler RISC architecture : Their engineer have probably less to review until they can give a definite answer about what is exploitable. They can mass-exclude any ARM core that doesn't do speculative execution at all (e.g.: RaspberryPi) ).
AMD is just ignoring it altogether until they no longer can. Regarding Spectre: near zero chance > microcode and software updates are coming, this you can read in statement on their page.
Mordern CPUs *are* complex, it's not impossible for not everybody in a company to know every single details.
Spectre variant 2 is the perfect exemple : Variant 2 Spectre works by relying on extremely precise gory detail of the implementation of speculative execution around indirect jumps whose destination isn't even known at execution time (e.g.: a jumptable whose index depends on a result that isn't computed yet. e.g: That's one possible form to compile a C/C++."switch" block into machine code. That's also what happens when you need to call the virtual overloaded member function of a C++ object member of an array and you haven't computed the index into the array yet)
The Google demo code relies on the format of the internal data that the branch predictor uses to makes it best guess to where this as of yet unkown destination isn't know. (Basically, the CPU keeps notes of where it jumped-to most of the times during the past when encountering this point of code. But the way the CPU write down "this point of code" in it notes is actually imprecise and can lead to confusion. More or less, it's a hash and Google has found a way to cause a hash collision. The attacker causes their own attack-program to jump to position A, whenever execution arrives at instruction B. Then the exploited program reaches a different instruction C, but the CPU is confused and thinks it's again at instruction B, and jumps to position A "out of habit" based on its notes, even if in the exploited program, there's no way this could happen ever (e.g.: there's no "position A" listed in the jump table). )
Should Intel admit that they are vulnerable ? Yes, Google caught them with their pants down on this one.
But, the Intel Xeon exploited by Google demo code certainly works completely differently than any AMD CPU. So for sure they can guarantee that the exact exploit code won't work for on AMD CPUs (It would be reasonnable guess, even without speaking to any engineer)
Now: is it definitely impossible to somewhat exploit the jump prediction in a globally similar way ? Well difficult to exclude. AMD would need to discuss it at lengths with their engineers experts in branch prediction on their CPU.
So first "nearly-zreo" (Shouldn't not work, but who knows ?)
And then, once AMD manages to get hold eventually of the guy who knows: Oh, shit, it turns out there could be a completely different method that could perhaps be applied to exploit indirect jumps on some recent architectures. So update the page to tell people to do the updates (while continuing to review with the engineer to try to give an actual answer whether there is actually a viable exploit).
AMD are trying their best, but CPUs are complex stuff, and it's not easy to give a definitive answer fast.
*YOU* get to chose which payment processor company you're paying fees to (you could be using Coinbase, or Bitpay, etc.) (Unlike if you choose to use PayPal as a system to send-money-over-internet. Then you can only use Pay Pal Inc. as the sole company that provides the service)
Or use an exchange market (Kraken, Bitstamp, etc.)
Or instead of a company you could exchange money-to-bitcoin your self. Either using a platform like localbitcoin or even redit/craiglist/irc to setup the cash/bitcoin hand-over.
Or you could mostly organise around your own tools (run your own wallet software, and be your own BTC bank, but then you're very much exposed to the BTC exchange rate volatility).
etc.
Open standard, distributed trust, means a lot of solution to the problems, instead of a single centralized go-to company. Which is entirely the purpose of bitcoin protocole to begin with.
(And the same reflections applies to bank-to-bank money transfer standards like SEPA. No central gateway company, you get to choose which ever bank you want to work with as long as it supports SEPA payment).
We'll have to ask the original poster, but I would presume that the capital's city university hospital could be decently staffed and equipped and/or there might be some up-class private hospital used by the elite in the capital city. These would probably seem very expensive to local people, but would seem affordable and still offering decent quality of service to someone with a US pay in the wallet.
If that's not the case, he might still be able to travel to another country where that's the case.
I use several of the Adobe apps, so the $50/month seems like a steal when you consider the Suite used to cost in the thousands of dollars.
If you suppose that they can break even on a $50/months subscription fee the same way the used to put food on their table with the multi-thousands dollars single-buy license (and I suppose they at least see both economically equivalent), that gives you an approximate idea of how few of their former customers were interested in buying yet another license, for this year's new edition, which basically offer the same feature set that they need and had already in the last version.
As I've said elsewhere in these discussions, we've reached the point where most of these software cover most of the needed feature, the remain are way too user specific, and it's getting harder and harder to add enough bullet points on the product description to justify the upgrade treadmill.
Force the users to move to a "keep paying to keep using" subsciption model, and try to get all their data stored in a "lock-in" cloud are the best solution these companies manged to think out to try to keep a revenue stream at a time where convincing the user to -rebuy the new versions of the same is becoming harder.
AMD doesn't provide drivers for game consoles -- they just provide the hardware.
XBox One basically runs a DirectX 12 (and before that a DirectX 11.2 a.k.a. "11.X") stack, that's almost the same as what you got on your Windows PC. What makes you think that Microsoft will rewrite an entirely different stack that clones what they already have from AMD for Windows ? Sure, they didn't just straigh install the same software, but chances are extremely high that they'll simply customize AMD's part work.
Same is very likely to happen on PlayStation : after all, it runs a FreeBSD fork, and AMD already provides a DRM/DRI stack for BSDs and Linux. Sony use they own APIs, but GNMX has been described very DirectX-like-ish, and GNM is a DirectX-12-ish low-level wrapper. So chances are high that the PS4 uses most of the lower stack of AMD, and maybe even some of the work that AMD has done on their high-level state tracker has found way into Sony APIs.
This seems corroborated by discussion with AMD devs on forums (see Phoronix) where they report that they share a lot more code than just between Windows and Linux (and some *BSDs which use the same stack).
Wii/Wii U's GX/GX2 APIs have strong similarities with OpenGL, chances are bits of the AMD stack (specially the R600 stack that targets the same chip as both PC hardware and Wii U) have found they way there, but that's more speculations from my part (without any sources, beyond the OpenGL-likeness of the APIs).
Anyway, my initial remarks concerning the dominance of AMD hardware in console land isn't as much regarding the software, as much as lots of game developer getting more used to how AMD hardware's special quircks handle and how to make the most out of that type of hardware. (This is even more relevant as most current development is moving to lower level API that are basically thin wrapper around the direct hardware: Vulkan, DX12, Metal, GNM, etc.)
AMD's drivers have been a source of anguish since they were ATI -- and don't even try to use their Linux drivers.
Which Linux drivers are you speaking about ? You might have not noticed, but FGLRX has completely disappeared from the Linux market.
The opensource (available in upstream vanilla linux kernel) drivers are the official AMD drivers, in the sense that some of the devs working on those are even on AMD's payroll. As the opensource driver got better, AMD has already considered them as the official drivers for older legacy hardware, and concentrated their binary drivers only to support current then-gen hardware.
As the drivers got even better, they went even further.
A couple of years ago, AMD has completely over-hauled their approach to drivers: they have decided to overhaul the opensource Linux lower-level DRM (radeon.ko) and use this new rewritten DRM (amdgpu.ko) as a base for all their drivers. It's shared by both the opensource Mesa stack (which they consider the current official and they way to go in the future), and the binary proprietary GL library (which AMD considers for covering special use-case in the professional workstation and CAD world). They are in the process of streamlining every thing around this stack. The stack it self, during the rewrite was made to expose the same kind of low-level functionality as also used on Windows and all the other platform they target (though that part was rewritten by their usual driver crew, not the seasoned Linux devs, so it took some time until the DAL/DC bits were considered good enough quality to get upstreamed into vanilla kernels). The stack is designed to share as much as possible : in addition the GL situation mentioned above, it's also used by the Vulkan stack, and AMD has recently opensourced their stack and added their AMDVLK library next to the independently made RADV (which is also very functional, by the way). AMD is in the process to opening their ROCm / OpenCL stack too (currently all the bit are released in the open, curr
And second, gamers might have a preference for nVidia today, but they will buy AMD if they can't get nVidia cards for a reasonable price. If the gaming market suddenly gets flooded with AMD cards, game makers will stop optimizing mainly for nVidia. If there are more people playing on AMD than on nVidia, game makers will optimize for AMD.
Which brings the related question : ever noticed the recent trend in gaming consoles ?
Microsoft : Since the XBox 360 all the way to the current XBox One X, uses ATI/AMD GPU hardware (and since the XBox One uses AMD CPUs too).
Sony: Since the Playstation 4, including the current Playstation 4 Pro, uses an AMD APU.
Nintendo: With the sole exception of the current Switch (which is Nvidia Tegra based) uses graphics core by ATI/AMD, either through acquisition (ATI did buy Art-X who were doing the GameCube's Flipper and Wii's GX) or by putting their own tech (The GX2 core of Wii U's Latte is a Radeon HD derivative core).
Nearly all hardware outputing graphics from gaming console has been some way or another related to AMD. Chances are, game developer, more precisely triple-A big studio that target multiple consoles in addition to Windows PCs, are paying attention to AMD hardware optimisation. (Though, due to the diverse jungle of graphical APIs. it doesn't necessarily translate into things applicable directly onto PC with AMD GPUs)
I wonder about option "C": Allow the user to pick their own review board. For example, have people from the Daily Kos, Breitbart, der Spiegel, CNN, MSNBC, Comedy Central, and other news organizations offer a review/weighting service for articles, with the ability for a user to pick and choose among them. This way, they are not stuck with what one groups deems as valid. This way, FB can't be accused of being partisan, since people can choose who (if any) reviews news articles and sets validity scores for them.
This is also how accidentally FB works now already.
The only difference is instead of paying professional for their view, it pools the data that it has for free : the opinion and behaviour of your friends.
It also has the same big draw-back : it creates a biased bubble. Except that currently the bubble isn't based on partisan media, but on what you talk with your friends and what popular in your circle. And currently the bubble costs nothing.
What you're proposing will just cost FB more money (gotta pay the reviewers) while not filtering that much bullshit out (to be broad you'll have to hire reviewer from all range of political inclination - and thus invariably you'll end up with lots of not so bright influencable people who have elected to rely most on media that has the same extremist bias).
In short: your racist uncle will just pick some alt-right media as they favorite reviewer, your whinny step daughter will pick her favorite feminazi SJW media. And they'll both end up re-posting/forwarding the same shit as before.
And fundamental problems are still fundamental problems. The reason practically every processor has the same issues is because the same optimizations we used to make processors faster had the same fundamental design error. I mean, either someone designed the core branch predictor block and everyone worldwide copied it for every processor, or everyone implemented it differently, yet it has the same Spectre flaw, implying that the flaw is inherent in the way branch predictors work.
Well, there are different level in the whole Spectre/Meltdown debacle. Not all CPU are affected the same.
(And nitpicking : only CPUs doing speculative execution are affected. Lots of RISC don't, only some recent like 64bits ARM cores do. And there are still CISC cores that don't even in modern days like older Atoms and Xeon Phi on Intel MIC boards).
Speculative execution, from the moment it was presented (around the era of Intel Pentium Pro) as a new technology, was criticised as potentially executing past important checks if the speculation goes wrong. But it was dismissed back then.
- because in the end, nothing is committed to memory/register, but instead is discarded. There are not (direct) permanent effect of the wrong speculation.
- nobody paid attention much to the indirect, less significant effects, that still could be measured (like bringing memory into cache).
-...because back in those days (in the era of RC4 and 3DES encryption, MD4 MD5 checksums, etc.), attacking cryptography was still done by breaking imperfect algorithms and brute forcing small search spaces. Timing side channel where something of academic interests only. Known to exist, but in practice there are simple way to attack encryption. (so nobody in the early-to-mid 90s would have though that cache could lead to useable exploitable attack).
"Spectre" is just some researcher figuring out a way to exploit this "known from the beginning" knowledge by putting it into the light of how crypto is attacked nowadays (side-channels, timing, etc.)
That's the thing which every single CPU is affected by and which is still speculative execution working as it should (and normally should still be contained to data that could be accessed by the application anyway).
But then, there are the cause of the "Spectre Variants / Meltdown" - due to "excessive" optimisations, suddenly the CPU not only access things that the application could already access anyway. It usually boils down to the CPU (and its designer) were trying to be way to smart.
Meltdown only exclusively affects Intel CPUs. On intel CPUs, to speed things up, memory protection check are post-poned. If something happens to be already available in the cache, speculative execusion might pick it up even if it violates memory protection. This runs countrary of how memory location works, is undocumented (unlike the base caracteristics of speculative execution). (AMD CPU, as a counter example, are guaranteed by AMD to not be affected, because they do the expensive checks at the beginning of the pipeline and never let speculation through if it reads from an unauthorised memory location. There everything works according to docs).
Spectre variants affects Intel CPUs: to speed things up, even if the destination of a jump is unknown (because it depends on a memory location that isn't even known yet: e.g. not-yet computed index of a jump table), an Intel will try to speculate where the execution would go (by keeping a list to remember where usually this poistion ends-up jumping to). Due to the specific way Intel CPUs work internally and keep this list of "possible destinations of a jump", it can get confused and jump to an impossible situation. the speculative execution will jump to an address that is not even in the jump table, it will execute at a position that could never be reach under normal circumstance. (AMD cannot exclude if their CPUs are affected. They definitely do not work the same wa
Or maybe starting up a serious open source hardware spec. He's probably one of the few people with the knowledge of what chips need to have, an audience,
Note: I'm just playing silly. I actually admire the guy for what his done (Linux, Git, etc.) but I couldn't resis pointing out that he DID already try making a CPU.
But you don't need A.I. for basic things like detecting obstacles in front of the car and slowing it down so you don't crash into said obstacle. {...} It's a good feature that doesn't require decades of work, powerful neural net processors and thousands of dollars of sensors and cameras all over the car.
Depends.
Ultra-sound sonars (the kind already equipped on cars for "Parking Assistance" type of feature) only get you that far (pun intended): they are short sighted (only the immediate vicinity around the car) very poor resolution/object recognition (can be easily foiled by grass, or event bursts of air emitted by other vehicles' active suspensions).
Radars are also limited. They can detect a big metallic object in front (The next car in line, that's why they were the first go-to technology in early iteration of "Adaptive Cruise Control" type of assistance)
At some point you'd need more capabilities to recognize more types of obstacles better. You need to throw cameras in the mix (MobileEye is a prominent provider of parts, including after market) or LIDAR (or LIDAR-ish not-so-expensive Laser sensors like the City Safety that Volvo uses a lot and which is standard across the range at VW). This kind of devices are better at recognising pedestrians, bicycle riders, etc. while not panicking when there's a plastic bag blown by the wind.
But making sense of these inputs require some data processing (LIDARs give you just a cloud of points), and integrating all those multiple signal to best infer the environment too. AI and DNN are a promising technology for that. (They are good at all situation where there isn't a clear easy rule, but where a human can visually notice a pattern by looking at the data)
I do agree that the price of the battery is the problem, what we need is a standardized battery that works in all brands of cars/trucks/SUVs/etc. Let Tesla, Panasonic, Sony, Energizer, Duracell and others compete.
I hope we reach such a situation. There are some promising signs that we might attempt to go this road (e.g.: the fact that lots of people in the industry standardise on the same 18650 Lithium cells that are already used in laptop and power tools batteries, instead of custom shaped constructor-specific blocks of Lithium-Polymer. Meaning that at lest the building blocks used to make the battery are a bit more standard and cheaper to obtain thanks to scaling production). But there are risk that we end up with several different standard of batteries, each incompatible and over-patented.
Forget {...} your A.I.-driving gadgets, what we need to make a difference is electric cars that anyone can afford, i.e. sub-$15K electric cars.
Several European car makers tend to disagree. Some of them tend to see driving-assistant gadget as essential tools to increase safety. As an example VW for the past few year has offered some form of forward collision avoidance as a standard on *all* of their cars, including the cheapest ones (e.g.: VW Up! - and electric variations thereof).
---
Regarding the price of electric cars themselves : the big barrier is the price of the battery it self. With most cars (Tesla being a prime example), you aren't as much buying an overpriced car, as you're actually buying an giant expensive battery, with the manufacturer adding a car chasis around that battery for a modest increase of price.
Though there *are* variation (Renault offers plans where you buy the car alone, sans the battery, for a more reasonable price, and then rent the battery for a monthly fee).
Fuschia can displace Android overnight if Google decide so. It is their call, their children. their control.
So, if Google snap their fingers, suddenly, all the hardware manufacturer that make embed SoCs will have stable Fuschia drivers (you know, the same manufacturer where you're still stuck with a 3.10 linux kernel, despite the current version being 4.15), all the manufacturer of boards will have all the other ancillary drivers for the rest of the chips ready too, and all the android manufacturers who takes ages to swtich between current versions of android (despite all of them being the same general Android/Linux structure) ?
Yeah... sure...
Nope.
If Google leverage their influence, they might manage to convince a certain subset of the chip manufacturer to accept keeping in mind to also write a Fuschia driver-daemon, next to linux kernel modules for the next chip that they are currently working on. (Forget about trying to persuade to shed any resources to write something for chips that they have sold) Meaning that 1-2 years down the line, the smartphone/tablet manufacturers would have a choice of ready-to-integrate PCBs that could also offer a Fuschia deamon to assemble into a Fuschio OS, in addition to an Android Linux kernel to install Linux onto. Meaning that within 3-4 year you would have a reasonable wave of cheap asian no-name smartphones with decent specs, available in big enough quantities that Fuschia would make a attempt at significant market share.
Until that point, you'll only be seeing "boutique" smartphone that Google can be custom making with a couple high profile tightly collaborating manufacturer. And it will have the exact same market-wide shattering effect that Samsung's Tizen has.
(Currently, any contender that even just try to "exist" on the market and that doesn't have the same influence as Google / their own manufacturing as Samsung / bought they way (=Nokia) into it like Microsoft, can only manage to quickly reach market by harnessing the general android Linux efforts. e.g.: Jolla's Hybris being used for Jolla's own Sailfish, Canonical's former/now UBports' Ubuntu Touch, etc.)
"the next Twitter", where their idiot employees spout off on camera about their magic privacy-violating powers.
On the other hand, Twitter's entire goal is to broadcast you short message to everybody (micro-blogging), with direct messages being only a after-though bolted-on minor feature. There shouldn't be much expected privacy to begin with (the whole point of twitter is to not be private, but shout out loud).
In short : Twitter is not the expected platform to send your dick pic, unless your goal *is* the whole planet to be subjected to it all the way to leaders in North Korea. (But please be aware that doing so might be an offense under your local jurisdiction)
Whereas Snap has always tried to present it self as a "your ephemeral message are guaranteed to remain private and un-seen" type of company (with varying degrees of actually managing to put it into practice - remember the "pics actually remain in the temp folder" scandal).
In short: Snap is (supposed to be) the platform where you can do all your sexting and expect that even the Mossad won't be aware of your and your s.o.'s intimate anatomies.
Employee announcing to abuse their all-seeing privileges can have different implication on both platforms.
And might be the ground on which the current assho^H... dictat^H... boss is trying to threaten with jail time: - if the specific leaks they are revealing is about all-seeing abuses, they might be implied to have access illegal-to-them content (e.g.: 2 european 15yo teens sexting with each other. Depending on the country it can be actually entirely legal. An employee bragging about tools to spy users' private messages could be suspected of having access nude pictures of said teens which is entirely illegal and a jailable offense in the US)
but Google already has written the world's most popular app platform, and it wouldn't be farfetched for them to do it again.
Then why aren't APK the current most popular way to run your word processor on your laptop ?
Part of the reason is that Google (an Apple with their AppStore - the *other* most popular app platform) didn't as much take over an existing eco-system, as they actually managed to build an entirely new eco-system and fill a void.
This void was due to the emergence of a new class of platform (specifically smartphone, the combination of former PDA and dumb phones in the same device). At that point, the former ecosystem that existed were either to old and a bit out place, or pretty much meh to begin with. (e.g.: PalmOS was a giant success on older PDA. By the time smartphone started emerging, it was a very old platform that didn't fill the needs anymore. Even Palm Inc started to ship WinCE on their smartphones.) Or where straigh killed by mis-management (Elop at Nokia).
But despite their tremendous success on the new platform, the same ecosystem didn't manage to displace older eco-system that where still successful. No matter how much we collectively hate Windows here on/., it's still dominating the classical laptop/desktop segment, because that's what every body is used to and that what everyone has already invested into - we Linux-running people are the odd guy out. The segment where Windows doesn't dominate are the new different segments that emerged since (Chromebooks, Smartphones, etc) where Windows didn't have any establishement to leverage.
I expect the same fate might be waiting Fuschia : - on newer emerging segment that didn't exist before and where there aren't already well established leader, it might create its place : IoT devices, wearables, etc. - on well established segment, the current iOS / Android will be hard to displace (Smartphone tablet). Any wannabe competitor will have to keep compatibility with them (e.g.: the various Android compatibility layer on minor smartphone OSes like Tizen, Blackberry, Sailfish OS... or failed attempt thereof: what WSL began its life as under Windows RT before being repurposed as "Bash in Windows").
Fuschia could only succeed if it basically "a different way to run android apps on your smartphone". And then being based on an entirely different kernel, it will also need to convince hardware manufacturer who have invested large amounts of know-how in Linux kernel (mainly for Android).
They will not be too thrilled bout having this tech in hospitals either.
Hospitals (specially those with a university nearby) (and in theory even pharmacy stores too - though in my limited US experience these seem to have been replaced by some type of supermarket that happen to sell a bit of medications too) already have small labs that can produce a limited amount of medication.
Such "lab-in-a-kit" approach could only be expanding a bit the kind of stuff they can produce locally. (Or in the case of hospital-with-a-university-lab-within-reach, reducing the time to bring the medication for the simpler molecule that are within reach of the "lab-in-a-kit" and don't require the full university lab).
In these contexts, it's not much a big change, and probably won't register on the pharma's radar.
but I don't think we're going to see such devices in homes in our lifetime, if ever.
Especially if the pharma lobby has its way.
You think, so? Nope. On the contrary. Home drugs is a giant market, and this is definitely a way to secure a foot in it. They'll patent it, run through certification projects (rising costs) and sell it, for a premium. THEN SELL THE EXCLUSIVE CONTRACTS to provide the necessary consumable for your home drug synthesizer.
You though inkjet cartridges were as expensive as if they were filled with unicorn blood ? Just wait to see the price the pharma companies are going to charge you for their "Drug-o-tron 3000" cartridge replacements. And as these are used for drugs manufacture, you bet there are doing to be heavy regulations by the FDA preventing you to refill the cartridges yourself. (Much better regulated than the current meager attempts to invoke DMCA regarding small counting chips emebed in inkjet cartridges).
This partially cures the pharma industries worst nightmare : The worst nightmare is not to have any new molecule to sell once your older patents run out, while your competitor manage to put something on the market. Suddenly you're the guy left out, not having anything lucrative to sell, and having missed the market the other managed to enter.
With this kind of "at-home-lab-kits", suddenly it doesn't matter as much. Even if your competitor is the one who lands the patent to sell a new drug, you can still make a chunk of money by selling the exclusive cartridges to the patient so they can fab-at-home it.
And unlike inkjet cartridges (which have basically used the same type of unicorn blood inside for the past decade), the "fab-a-drug-at-home" technology is bound to evolve over the next decades. Meaning new, freshly patented system requiring new cartridge contract everyfew year (think rebuying your smartphone every 2-3 years, except wich actual physico-chemical justification for newer synth tech).
Throw in remote data collection, and the insurance companies will happily jump together into the bandwagon.
Buying bitcoin, transferring it and selling it again is three transactions; That will take roughly four hours.
Which, by the way, is still faster than other form of "transfer without a central authority", like bank money transfer (from a day up to a couple of days).
As evidenced a few days ago, Bitcoin could easily gain or lose 10% or more of its value in those four hours.
Which, by the way, is still within the same kind of margin that some central authority money transfers end up costing.
No sane or intelligent person would attempt it, unless they were desperate to hide the movement of money.
How are you supposed to *hide* movements of money, on a system whose entire purpose of existence is to replace central authorities, with a system where every single movement of money is broadcast to the entire network and kept in a distributed ledger by all nodes ?
Well, okay, Joe Six pack your neighbor would have a little bit of difficulties mapping that transaction signed with public key "1XyZ" is actually you. But that absolutely not beyond the reach of state-level actor.
The whole point of bitcoin protocol is not to make transaction secret.
The whole point of the protocol is to remove the central authority. Only you and the other end-point of a transaction decide what's going on. There's no central "Bitcoin, Inc." that can decide to block your transaction on a whim (as opposed to PayPal, Visa, etc.). (Though in practice, some mining pools are dangerously close to that point, the protocol itself was initially designed with that goal in mind).
The problem to solve is why vendors, including Google's own Nexus devices, can't manage to keep hardware support going past about 2.5 years. We're supposed to dump our devices in a landfill every 2 years because they are saddled with unresolved security flaws?
The problem is that companies make money immediately when they sell a device. Not over the lifetime of a device. They have strong incentive to put immediately a new device out-of-the-door (sometime even not perfectly finished, with still bugs needing fixing), but not much incentive to write updates 2 years down the line (a that moment, writing an update won't translate in immediate money input, diverts ressources from getting the next money making device out, and might even create a competitor for the new device as the old one remains too much useful).
This is a bit alleviated if the company has a tighly concentrated line of device where work for updating one translate into "free" updates for another. Apple, by having a small set of relatively similar devices is one such example. A company such as Jolla making a OS like Sailfish is mostly dealing with user space software suite, and beside a few problems with kernels locked to whatever version the hardware manufacturer supports, can actual transfer their update efforts to the whole range too (Jolla1 smartphone is still benefiting of the updates effort and runs the same version of OS as the latest Sailfish X running on Sony Xperia X devices).
The hope of Google, by making their own OS and by making it micro kernel, is that most of the hardware-manufacturer dependant shit will be locked inside a few daemons with precisely set APIs and Google should be able to to replace all the other daemons as needed (file systems, etc.). As opposed to linux, which is in a constant flux of evolving, and on purpose only exposes an external API to the userland, but might break its own internal interfaces. (So it's hard to port a 4.4 kernel on a piece of hardware whose manufacturer only provided a 3.2 kernel and drivers set).
Of course, if hardware manufacturer took example of the desktop/laptop world, specially with AMD and Intel, and had opensource drivers stack maintained in the upstream vanilla kernel, things would be much more easy...
My expectation regarding Fuschia are actually rather low. There is a ginormous invested know-how in Linux in the embed world (which itself leverage the even more giant community around Linux). It would be hard to convince all the hardware manufacturer to switch to another completely different kernel and way to develop drivers. It's a very steep uphill battle.
Yes, it is roughly the same distance from the sun as Earth is (given that the moon orbits around the later, duh...). And yes, no significant atmosphere means even more light available to a moon base than to earth surface solar pannels...
But being tidally locked to earth and with a approx 28-day orbit around it means that the Moon base's solar panels are guaranteed to be in the dark for 2 whole weeks (unless you go even more crazy with orbital mirror reflecting light toward the solar panels, etc.)
Batteries could be a solution, adding a nuclear power source to supplement the solar specially during moon night is another.
2. If cheating is a problem, Tencent won't be selling as many units as they would like. It would mean commercial problems, loss of revenue. They need to do whatever they can to maintain (or in this case: guarantee future) profits (and this being China, they can actually a lot). So one guy in the giant multi-million corporation goes to talk to his neighbours' friend who happens to be a high ranking official. Some kick-backs are exchanged. New laws and policies are written. Tencent guy sees it as a good investment of money to secure profit. Gov guy sees it as nice side revenue to his gov job. The rest of the world pretends to be appalled to how much politicis is fucked up (even if nearly every one is doing it, though at a smaller scale and a lot less in the open, in their own home countries).
You would think that all three would be required to send out an emergency alert message.
Then in case of an actual emergency (say, when category 9 hurricane 'Zorro' hits Hawai in a couple of months), you'd be complaining that the alert wasn't sent because it relied on a complex validation procedure that required perfectly coordinated simultaneous action by 5 person, one of which was sick on that day, and the other lost his keyfob 12 months ago when his dog ate it.
That's the complex problem with emergency procedures, they need both at the same time be quick enough to execute in case of actual emergency, but have enough confirmation step to not be triggered by incident.
and a Russian, German, British, German, or Chinese company be more trustworthy?
At least, in the specific case of Germany (and to a lesser extent, other European countries - more often in the central-nordic. Switzerland is another such example. On the other hand France's controversial State of Emergency is a counter example), the laws happens to currently still be on your side. There are strong law regarding protection of customer privacy.
I'm not saying that none of these countries' secret services will never ever attempt to spy on their own population. (e.g.: Swiss secret sevices notoriously kept files on their own population)
I'm just saying that if a German company ends up in the same situation as Lavabit - i.e.: on the receiving end of a government order to hand out their customer case's private informations - and decides to take it to the court, they have a very high chance to actually win the case.
(And some countries like Switzerland are even more extreme, on ground of being a direct democracy : to reduce such customer protection law, it would take a significant chunk of the population to vote for a law against their own interests. The government cannot pass something like the patriot act unchecked. Lobbying is nearly useless in direct democracies. Though that doesn't prevent the population to be massively stupid every once in a while...cough... minaret construction...cough.. ).
but brakes are still mechanical and will continue to be so for the forseeable future due to FMVSS requirements. {...} Yes, I am aware there are cars with electric brakes that can stop themselves... just wanted to clear up that "most" is more "a special few".
And due to the high popularity of adaptive cruise control (ACC) and forward collision avoidance systems (FCAS), the "special few" is becoming "quite a big percentage of the cars present on today's street".
Slashdot Mirror
In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.
“Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)
Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory.
It is something specific to Intel CPUs.
In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register.
That means that speculative execution might get pas memory protection.
Your run a piece of software, your piece of software tries to read stuff from the kernel, the CPU does it speculatively, touches a few cache, and only then kicks the execution out. You can guess stuff by measuring which caches were touchs.
It works to get across the kernel/user-space boundaries. Gives you ability to peek into the kernel memory space.
It's madness that completely fucks up the base guaranties that memory protection is supposed to provide.
AMD CPU are confirmed to be not affected (they do the costly memory protection earlier and refuse to access protected memory).
Only a couple of ARM Cortex cores seem to be affected (basically only Cortex-A75 is affect in a way that is actually exploitable, according to ARM).
Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.
Please pay attention that there are 2 different Spectre attacks.
Spectre Variant 1 / "bounds check bypass" amd Spectre Variant 2 / "branch target injection"
The comment is only valid for the second one.
Variant 1 is just speculative execution working as it is supposed to do. If there's a condition (an "if" in the code) the predictor will try to guess which code path is the most likely to be taken, and speculatively execute that one. If the guess was wrong, the CPU throws the computation an restarts the correct branch. (but again, cache might have moved around and is something that is indirectly measurable).
If the condition is a boundary check, is might get skipped and CPU attempts to speculatively execute reads that are outside the bounds.
That's still reads to memory that should be accessible to the application anyway (meh). That would just cause the application to read one of it other's variable, instead of the array.
It's only a potentially exploitable situation when the application should not read it own data. Usually situations where arbitrary externally provided code reside in the same process as secret data. (And you basically deserve what you get for mixing sensitive data and arbitrary remote code in the same process).
Google example is done by sending eBFP a special type of bytecode used by modern packet-filters to the kernel. It's get jitted to machine code, and such code can read past its boundary speculatively.
Possible other exploit are sending specially crafted Javascript (there's a ASM.js demo floating on the web) or WASM, to a browser which JIT it and execute it. The code translate into a bound check, and could read any other part of the memory inside
Well at least, look on the bright side :
even if you brick the mainboard into an unbootable state with the bad firmware upgrade,
you can still log into the Intel ME / Intel AMT web-interface running on the ARC core in the chipset, and flash another version from there.
Better than needing to physically walk to the bricked machine, open it, remove the firmware EEPROM chip from the socket, put it into your own EEPROM programmer, reflash a different version and put it back together.
A.K.A.: the only time where Intel AMT works as it should and is actually useful.
A.K.A.: even a stopped clock is right twice a day.
ARM is probably the only one of the chipmakers doing the right thing here. Information is quick, public, to the point and fixes are deployed as soon as they are done. There are performance issues with ARM patches but they are taken as necessary.
They just got lucky to be right most of the time.
(Helps that they use a much simpler RISC architecture : Their engineer have probably less to review until they can give a definite answer about what is exploitable.
They can mass-exclude any ARM core that doesn't do speculative execution at all (e.g.: RaspberryPi) ).
AMD is just ignoring it altogether until they no longer can. Regarding Spectre: near zero chance > microcode and software updates are coming, this you can read in statement on their page.
Mordern CPUs *are* complex, it's not impossible for not everybody in a company to know every single details.
Spectre variant 2 is the perfect exemple : ."switch" block into machine code.
Variant 2 Spectre works by relying on extremely precise gory detail of the implementation of speculative execution around indirect jumps whose destination isn't even known at execution time
(e.g.: a jumptable whose index depends on a result that isn't computed yet.
e.g: That's one possible form to compile a C/C++
That's also what happens when you need to call the virtual overloaded member function of a C++ object member of an array and you haven't computed the index into the array yet)
The Google demo code relies on the format of the internal data that the branch predictor uses to makes it best guess to where this as of yet unkown destination isn't know.
(Basically, the CPU keeps notes of where it jumped-to most of the times during the past when encountering this point of code.
But the way the CPU write down "this point of code" in it notes is actually imprecise and can lead to confusion.
More or less, it's a hash and Google has found a way to cause a hash collision.
The attacker causes their own attack-program to jump to position A, whenever execution arrives at instruction B.
Then the exploited program reaches a different instruction C, but the CPU is confused and thinks it's again at instruction B, and jumps to position A "out of habit" based on its notes, even if in the exploited program, there's no way this could happen ever (e.g.: there's no "position A" listed in the jump table). )
Should Intel admit that they are vulnerable ? Yes, Google caught them with their pants down on this one.
But, the Intel Xeon exploited by Google demo code certainly works completely differently than any AMD CPU.
So for sure they can guarantee that the exact exploit code won't work for on AMD CPUs
(It would be reasonnable guess, even without speaking to any engineer)
Now: is it definitely impossible to somewhat exploit the jump prediction in a globally similar way ?
Well difficult to exclude.
AMD would need to discuss it at lengths with their engineers experts in branch prediction on their CPU.
So first "nearly-zreo" (Shouldn't not work, but who knows ?)
And then, once AMD manages to get hold eventually of the guy who knows: Oh, shit, it turns out there could be a completely different method that could perhaps be applied to exploit indirect jumps on some recent architectures.
So update the page to tell people to do the updates (while continuing to review with the engineer to try to give an actual answer whether there is actually a viable exploit).
AMD are trying their best, but CPUs are complex stuff, and it's not easy to give a definitive answer fast.
Yes, but, because the protocol is standardized,
*YOU* get to chose which payment processor company you're paying fees to (you could be using Coinbase, or Bitpay, etc.)
(Unlike if you choose to use PayPal as a system to send-money-over-internet. Then you can only use Pay Pal Inc. as the sole company that provides the service)
Or use an exchange market (Kraken, Bitstamp, etc.)
Or instead of a company you could exchange money-to-bitcoin your self. Either using a platform like localbitcoin or even redit/craiglist/irc to setup the cash/bitcoin hand-over.
Or you could mostly organise around your own tools (run your own wallet software, and be your own BTC bank, but then you're very much exposed to the BTC exchange rate volatility).
etc.
Open standard, distributed trust, means a lot of solution to the problems, instead of a single centralized go-to company.
Which is entirely the purpose of bitcoin protocole to begin with.
(And the same reflections applies to bank-to-bank money transfer standards like SEPA. No central gateway company, you get to choose which ever bank you want to work with as long as it supports SEPA payment).
We'll have to ask the original poster, but I would presume that the capital's city university hospital could be decently staffed and equipped and/or there might be some up-class private hospital used by the elite in the capital city.
These would probably seem very expensive to local people, but would seem affordable and still offering decent quality of service to someone with a US pay in the wallet.
If that's not the case, he might still be able to travel to another country where that's the case.
I use several of the Adobe apps, so the $50/month seems like a steal when you consider the Suite used to cost in the thousands of dollars.
If you suppose that they can break even on a $50/months subscription fee the same way the used to put food on their table with the multi-thousands dollars single-buy license (and I suppose they at least see both economically equivalent),
that gives you an approximate idea of how few of their former customers were interested in buying yet another license, for this year's new edition, which basically offer the same feature set that they need and had already in the last version.
As I've said elsewhere in these discussions, we've reached the point where most of these software cover most of the needed feature, the remain are way too user specific, and it's getting harder and harder to add enough bullet points on the product description to justify the upgrade treadmill.
Force the users to move to a "keep paying to keep using" subsciption model, and try to get all their data stored in a "lock-in" cloud are the best solution these companies manged to think out to try to keep a revenue stream at a time where convincing the user to -rebuy the new versions of the same is becoming harder.
AMD doesn't provide drivers for game consoles -- they just provide the hardware.
XBox One basically runs a DirectX 12 (and before that a DirectX 11.2 a.k.a. "11.X") stack, that's almost the same as what you got on your Windows PC.
What makes you think that Microsoft will rewrite an entirely different stack that clones what they already have from AMD for Windows ?
Sure, they didn't just straigh install the same software, but chances are extremely high that they'll simply customize AMD's part work.
Same is very likely to happen on PlayStation : after all, it runs a FreeBSD fork, and AMD already provides a DRM/DRI stack for BSDs and Linux. Sony use they own APIs, but GNMX has been described very DirectX-like-ish, and GNM is a DirectX-12-ish low-level wrapper.
So chances are high that the PS4 uses most of the lower stack of AMD, and maybe even some of the work that AMD has done on their high-level state tracker has found way into Sony APIs.
This seems corroborated by discussion with AMD devs on forums (see Phoronix) where they report that they share a lot more code than just between Windows and Linux (and some *BSDs which use the same stack).
Wii/Wii U's GX/GX2 APIs have strong similarities with OpenGL, chances are bits of the AMD stack (specially the R600 stack that targets the same chip as both PC hardware and Wii U) have found they way there, but that's more speculations from my part (without any sources, beyond the OpenGL-likeness of the APIs).
Anyway, my initial remarks concerning the dominance of AMD hardware in console land isn't as much regarding the software, as much as lots of game developer getting more used to how AMD hardware's special quircks handle and how to make the most out of that type of hardware.
(This is even more relevant as most current development is moving to lower level API that are basically thin wrapper around the direct hardware: Vulkan, DX12, Metal, GNM, etc.)
AMD's drivers have been a source of anguish since they were ATI -- and don't even try to use their Linux drivers.
Which Linux drivers are you speaking about ? You might have not noticed, but FGLRX has completely disappeared from the Linux market.
The opensource (available in upstream vanilla linux kernel) drivers are the official AMD drivers, in the sense that some of the devs working on those are even on AMD's payroll. As the opensource driver got better, AMD has already considered them as the official drivers for older legacy hardware, and concentrated their binary drivers only to support current then-gen hardware.
As the drivers got even better, they went even further.
A couple of years ago, AMD has completely over-hauled their approach to drivers :
they have decided to overhaul the opensource Linux lower-level DRM (radeon.ko) and use this new rewritten DRM (amdgpu.ko) as a base for all their drivers.
It's shared by both the opensource Mesa stack (which they consider the current official and they way to go in the future), and the binary proprietary GL library (which AMD considers for covering special use-case in the professional workstation and CAD world).
They are in the process of streamlining every thing around this stack.
The stack it self, during the rewrite was made to expose the same kind of low-level functionality as also used on Windows and all the other platform they target (though that part was rewritten by their usual driver crew, not the seasoned Linux devs, so it took some time until the DAL/DC bits were considered good enough quality to get upstreamed into vanilla kernels).
The stack is designed to share as much as possible : in addition the GL situation mentioned above, it's also used by the Vulkan stack, and AMD has recently opensourced their stack and added their AMDVLK library next to the independently made RADV (which is also very functional, by the way).
AMD is in the process to opening their ROCm / OpenCL stack too (currently all the bit are released in the open, curr
And second, gamers might have a preference for nVidia today, but they will buy AMD if they can't get nVidia cards for a reasonable price. If the gaming market suddenly gets flooded with AMD cards, game makers will stop optimizing mainly for nVidia. If there are more people playing on AMD than on nVidia, game makers will optimize for AMD.
Which brings the related question :
ever noticed the recent trend in gaming consoles ?
Microsoft :
Since the XBox 360 all the way to the current XBox One X, uses ATI/AMD GPU hardware (and since the XBox One uses AMD CPUs too).
Sony:
Since the Playstation 4, including the current Playstation 4 Pro, uses an AMD APU.
Nintendo:
With the sole exception of the current Switch (which is Nvidia Tegra based) uses graphics core by ATI/AMD, either through acquisition (ATI did buy Art-X who were doing the GameCube's Flipper and Wii's GX) or by putting their own tech (The GX2 core of Wii U's Latte is a Radeon HD derivative core).
Nearly all hardware outputing graphics from gaming console has been some way or another related to AMD.
Chances are, game developer, more precisely triple-A big studio that target multiple consoles in addition to Windows PCs, are paying attention to AMD hardware optimisation.
(Though, due to the diverse jungle of graphical APIs. it doesn't necessarily translate into things applicable directly onto PC with AMD GPUs)
I wonder about option "C": Allow the user to pick their own review board. For example, have people from the Daily Kos, Breitbart, der Spiegel, CNN, MSNBC, Comedy Central, and other news organizations offer a review/weighting service for articles, with the ability for a user to pick and choose among them. This way, they are not stuck with what one groups deems as valid.
This way, FB can't be accused of being partisan, since people can choose who (if any) reviews news articles and sets validity scores for them.
This is also how accidentally FB works now already.
The only difference is instead of paying professional for their view, it pools the data that it has for free : the opinion and behaviour of your friends.
It also has the same big draw-back : it creates a biased bubble. Except that currently the bubble isn't based on partisan media, but on what you talk with your friends and what popular in your circle. And currently the bubble costs nothing.
What you're proposing will just cost FB more money (gotta pay the reviewers) while not filtering that much bullshit out (to be broad you'll have to hire reviewer from all range of political inclination - and thus invariably you'll end up with lots of not so bright influencable people who have elected to rely most on media that has the same extremist bias).
In short: your racist uncle will just pick some alt-right media as they favorite reviewer, your whinny step daughter will pick her favorite feminazi SJW media.
And they'll both end up re-posting/forwarding the same shit as before.
And fundamental problems are still fundamental problems. The reason practically every processor has the same issues is because the same optimizations we used to make processors faster had the same fundamental design error.
I mean, either someone designed the core branch predictor block and everyone worldwide copied it for every processor, or everyone implemented it differently, yet it has the same Spectre flaw, implying that the flaw is inherent in the way branch predictors work.
Well, there are different level in the whole Spectre/Meltdown debacle.
Not all CPU are affected the same.
(And nitpicking : only CPUs doing speculative execution are affected. Lots of RISC don't, only some recent like 64bits ARM cores do. And there are still CISC cores that don't even in modern days like older Atoms and Xeon Phi on Intel MIC boards).
Speculative execution, from the moment it was presented (around the era of Intel Pentium Pro) as a new technology, was criticised as potentially executing past important checks if the speculation goes wrong. But it was dismissed back then. ...because back in those days (in the era of RC4 and 3DES encryption, MD4 MD5 checksums, etc.), attacking cryptography was still done by breaking imperfect algorithms and brute forcing small search spaces. Timing side channel where something of academic interests only. Known to exist, but in practice there are simple way to attack encryption.
- because in the end, nothing is committed to memory/register, but instead is discarded. There are not (direct) permanent effect of the wrong speculation.
- nobody paid attention much to the indirect, less significant effects, that still could be measured (like bringing memory into cache).
-
(so nobody in the early-to-mid 90s would have though that cache could lead to useable exploitable attack).
"Spectre" is just some researcher figuring out a way to exploit this "known from the beginning" knowledge by putting it into the light of how crypto is attacked nowadays (side-channels, timing, etc.)
That's the thing which every single CPU is affected by and which is still speculative execution working as it should (and normally should still be contained to data that could be accessed by the application anyway).
But then, there are the cause of the "Spectre Variants / Meltdown" - due to "excessive" optimisations, suddenly the CPU not only access things that the application could already access anyway. It usually boils down to the CPU (and its designer) were trying to be way to smart.
Meltdown only exclusively affects Intel CPUs. On intel CPUs, to speed things up, memory protection check are post-poned. If something happens to be already available in the cache, speculative execusion might pick it up even if it violates memory protection.
This runs countrary of how memory location works, is undocumented (unlike the base caracteristics of speculative execution).
(AMD CPU, as a counter example, are guaranteed by AMD to not be affected, because they do the expensive checks at the beginning of the pipeline and never let speculation through if it reads from an unauthorised memory location. There everything works according to docs).
Spectre variants affects Intel CPUs: to speed things up, even if the destination of a jump is unknown (because it depends on a memory location that isn't even known yet: e.g. not-yet computed index of a jump table), an Intel will try to speculate where the execution would go (by keeping a list to remember where usually this poistion ends-up jumping to). Due to the specific way Intel CPUs work internally and keep this list of "possible destinations of a jump", it can get confused and jump to an impossible situation. the speculative execution will jump to an address that is not even in the jump table, it will execute at a position that could never be reach under normal circumstance.
(AMD cannot exclude if their CPUs are affected. They definitely do not work the same wa
Or maybe starting up a serious open source hardware spec. He's probably one of the few people with the knowledge of what chips need to have, an audience,
He might have the knowledge of what a ship needs to have,
but the last time he tried making a chip it didn't work that well~
---
Note: I'm just playing silly. I actually admire the guy for what his done (Linux, Git, etc.) but I couldn't resis pointing out that he DID already try making a CPU.
But you don't need A.I. for basic things like detecting obstacles in front of the car and slowing it down so you don't crash into said obstacle. {...} It's a good feature that doesn't require decades of work, powerful neural net processors and thousands of dollars of sensors and cameras all over the car.
Depends.
Ultra-sound sonars (the kind already equipped on cars for "Parking Assistance" type of feature) only get you that far (pun intended): they are short sighted (only the immediate vicinity around the car) very poor resolution/object recognition (can be easily foiled by grass, or event bursts of air emitted by other vehicles' active suspensions).
Radars are also limited. They can detect a big metallic object in front (The next car in line, that's why they were the first go-to technology in early iteration of "Adaptive Cruise Control" type of assistance)
At some point you'd need more capabilities to recognize more types of obstacles better. You need to throw cameras in the mix (MobileEye is a prominent provider of parts, including after market) or LIDAR (or LIDAR-ish not-so-expensive Laser sensors like the City Safety that Volvo uses a lot and which is standard across the range at VW). This kind of devices are better at recognising pedestrians, bicycle riders, etc. while not panicking when there's a plastic bag blown by the wind.
But making sense of these inputs require some data processing (LIDARs give you just a cloud of points), and integrating all those multiple signal to best infer the environment too. AI and DNN are a promising technology for that. (They are good at all situation where there isn't a clear easy rule, but where a human can visually notice a pattern by looking at the data)
I do agree that the price of the battery is the problem, what we need is a standardized battery that works in all brands of cars/trucks/SUVs/etc. Let Tesla, Panasonic, Sony, Energizer, Duracell and others compete.
I hope we reach such a situation. There are some promising signs that we might attempt to go this road (e.g.: the fact that lots of people in the industry standardise on the same 18650 Lithium cells that are already used in laptop and power tools batteries, instead of custom shaped constructor-specific blocks of Lithium-Polymer. Meaning that at lest the building blocks used to make the battery are a bit more standard and cheaper to obtain thanks to scaling production).
But there are risk that we end up with several different standard of batteries, each incompatible and over-patented.
Forget {...} your A.I.-driving gadgets, what we need to make a difference is electric cars that anyone can afford, i.e. sub-$15K electric cars.
Several European car makers tend to disagree.
Some of them tend to see driving-assistant gadget as essential tools to increase safety.
As an example VW for the past few year has offered some form of forward collision avoidance as a standard on *all* of their cars, including the cheapest ones (e.g.: VW Up! - and electric variations thereof).
---
Regarding the price of electric cars themselves : the big barrier is the price of the battery it self. With most cars (Tesla being a prime example), you aren't as much buying an overpriced car, as you're actually buying an giant expensive battery, with the manufacturer adding a car chasis around that battery for a modest increase of price.
Though there *are* variation (Renault offers plans where you buy the car alone, sans the battery, for a more reasonable price, and then rent the battery for a monthly fee).
And risk missing the opportunity to witness a Darwin Award getting won on live TV ?
Fuschia can displace Android overnight if Google decide so. It is their call, their children. their control.
So, if Google snap their fingers, suddenly, all the hardware manufacturer that make embed SoCs will have stable Fuschia drivers (you know, the same manufacturer where you're still stuck with a 3.10 linux kernel, despite the current version being 4.15), all the manufacturer of boards will have all the other ancillary drivers for the rest of the chips ready too, and all the android manufacturers who takes ages to swtich between current versions of android (despite all of them being the same general Android/Linux structure) ?
Yeah... sure...
Nope.
If Google leverage their influence, they might manage to convince a certain subset of the chip manufacturer to accept keeping in mind to also write a Fuschia driver-daemon, next to linux kernel modules for the next chip that they are currently working on. (Forget about trying to persuade to shed any resources to write something for chips that they have sold)
Meaning that 1-2 years down the line, the smartphone/tablet manufacturers would have a choice of ready-to-integrate PCBs that could also offer a Fuschia deamon to assemble into a Fuschio OS, in addition to an Android Linux kernel to install Linux onto.
Meaning that within 3-4 year you would have a reasonable wave of cheap asian no-name smartphones with decent specs, available in big enough quantities that Fuschia would make a attempt at significant market share.
Until that point, you'll only be seeing "boutique" smartphone that Google can be custom making with a couple high profile tightly collaborating manufacturer.
And it will have the exact same market-wide shattering effect that Samsung's Tizen has.
(Currently, any contender that even just try to "exist" on the market and that doesn't have the same influence as Google / their own manufacturing as Samsung / bought they way (=Nokia) into it like Microsoft, can only manage to quickly reach market by harnessing the general android Linux efforts. e.g.: Jolla's Hybris being used for Jolla's own Sailfish, Canonical's former/now UBports' Ubuntu Touch, etc.)
"the next Twitter", where their idiot employees spout off on camera about their magic privacy-violating powers.
On the other hand, Twitter's entire goal is to broadcast you short message to everybody (micro-blogging), with direct messages being only a after-though bolted-on minor feature.
There shouldn't be much expected privacy to begin with (the whole point of twitter is to not be private, but shout out loud).
In short : Twitter is not the expected platform to send your dick pic, unless your goal *is* the whole planet to be subjected to it all the way to leaders in North Korea. (But please be aware that doing so might be an offense under your local jurisdiction)
Whereas Snap has always tried to present it self as a "your ephemeral message are guaranteed to remain private and un-seen" type of company (with varying degrees of actually managing to put it into practice - remember the "pics actually remain in the temp folder" scandal).
In short: Snap is (supposed to be) the platform where you can do all your sexting and expect that even the Mossad won't be aware of your and your s.o.'s intimate anatomies.
Employee announcing to abuse their all-seeing privileges can have different implication on both platforms.
And might be the ground on which the current assho^H... dictat^H... boss is trying to threaten with jail time:
- if the specific leaks they are revealing is about all-seeing abuses, they might be implied to have access illegal-to-them content
(e.g.: 2 european 15yo teens sexting with each other. Depending on the country it can be actually entirely legal. An employee bragging about tools to spy users' private messages could be suspected of having access nude pictures of said teens which is entirely illegal and a jailable offense in the US)
but Google already has written the world's most popular app platform, and it wouldn't be farfetched for them to do it again.
Then why aren't APK the current most popular way to run your word processor on your laptop ?
Part of the reason is that Google (an Apple with their AppStore - the *other* most popular app platform) didn't as much take over an existing eco-system, as they actually managed to build an entirely new eco-system and fill a void.
This void was due to the emergence of a new class of platform (specifically smartphone, the combination of former PDA and dumb phones in the same device).
At that point, the former ecosystem that existed were either to old and a bit out place, or pretty much meh to begin with. (e.g.: PalmOS was a giant success on older PDA. By the time smartphone started emerging, it was a very old platform that didn't fill the needs anymore. Even Palm Inc started to ship WinCE on their smartphones.) Or where straigh killed by mis-management (Elop at Nokia).
But despite their tremendous success on the new platform, the same ecosystem didn't manage to displace older eco-system that where still successful. No matter how much we collectively hate Windows here on /., it's still dominating the classical laptop/desktop segment, because that's what every body is used to and that what everyone has already invested into - we Linux-running people are the odd guy out.
The segment where Windows doesn't dominate are the new different segments that emerged since (Chromebooks, Smartphones, etc) where Windows didn't have any establishement to leverage.
I expect the same fate might be waiting Fuschia :
- on newer emerging segment that didn't exist before and where there aren't already well established leader, it might create its place : IoT devices, wearables, etc.
- on well established segment, the current iOS / Android will be hard to displace (Smartphone tablet). Any wannabe competitor will have to keep compatibility with them (e.g.: the various Android compatibility layer on minor smartphone OSes like Tizen, Blackberry, Sailfish OS... or failed attempt thereof: what WSL began its life as under Windows RT before being repurposed as "Bash in Windows").
Fuschia could only succeed if it basically "a different way to run android apps on your smartphone". And then being based on an entirely different kernel, it will also need to convince hardware manufacturer who have invested large amounts of know-how in Linux kernel (mainly for Android).
They will not be too thrilled bout having this tech in hospitals either.
Hospitals (specially those with a university nearby) (and in theory even pharmacy stores too - though in my limited US experience these seem to have been replaced by some type of supermarket that happen to sell a bit of medications too) already have small labs that can produce a limited amount of medication.
Such "lab-in-a-kit" approach could only be expanding a bit the kind of stuff they can produce locally.
(Or in the case of hospital-with-a-university-lab-within-reach, reducing the time to bring the medication for the simpler molecule that are within reach of the "lab-in-a-kit" and don't require the full university lab).
In these contexts, it's not much a big change, and probably won't register on the pharma's radar.
but I don't think we're going to see such devices in homes in our lifetime, if ever.
Especially if the pharma lobby has its way.
You think, so? Nope. On the contrary.
Home drugs is a giant market, and this is definitely a way to secure a foot in it.
They'll patent it, run through certification projects (rising costs) and sell it, for a premium.
THEN SELL THE EXCLUSIVE CONTRACTS to provide the necessary consumable for your home drug synthesizer.
You though inkjet cartridges were as expensive as if they were filled with unicorn blood ?
Just wait to see the price the pharma companies are going to charge you for their "Drug-o-tron 3000" cartridge replacements. And as these are used for drugs manufacture, you bet there are doing to be heavy regulations by the FDA preventing you to refill the cartridges yourself. (Much better regulated than the current meager attempts to invoke DMCA regarding small counting chips emebed in inkjet cartridges).
This partially cures the pharma industries worst nightmare :
The worst nightmare is not to have any new molecule to sell once your older patents run out, while your competitor manage to put something on the market.
Suddenly you're the guy left out, not having anything lucrative to sell, and having missed the market the other managed to enter.
With this kind of "at-home-lab-kits", suddenly it doesn't matter as much. Even if your competitor is the one who lands the patent to sell a new drug, you can still make a chunk of money by selling the exclusive cartridges to the patient so they can fab-at-home it.
And unlike inkjet cartridges (which have basically used the same type of unicorn blood inside for the past decade), the "fab-a-drug-at-home" technology is bound to evolve over the next decades. Meaning new, freshly patented system requiring new cartridge contract everyfew year (think rebuying your smartphone every 2-3 years, except wich actual physico-chemical justification for newer synth tech).
Throw in remote data collection, and the insurance companies will happily jump together into the bandwagon.
Buying bitcoin, transferring it and selling it again is three transactions; That will take roughly four hours.
Which, by the way, is still faster than other form of "transfer without a central authority", like bank money transfer (from a day up to a couple of days).
As evidenced a few days ago, Bitcoin could easily gain or lose 10% or more of its value in those four hours.
Which, by the way, is still within the same kind of margin that some central authority money transfers end up costing.
No sane or intelligent person would attempt it, unless they were desperate to hide the movement of money.
How are you supposed to *hide* movements of money, on a system whose entire purpose of existence is to replace central authorities, with a system where every single movement of money is broadcast to the entire network and kept in a distributed ledger by all nodes ?
Well, okay, Joe Six pack your neighbor would have a little bit of difficulties mapping that transaction signed with public key "1XyZ" is actually you.
But that absolutely not beyond the reach of state-level actor.
The whole point of bitcoin protocol is not to make transaction secret.
The whole point of the protocol is to remove the central authority. Only you and the other end-point of a transaction decide what's going on. There's no central "Bitcoin, Inc." that can decide to block your transaction on a whim (as opposed to PayPal, Visa, etc.).
(Though in practice, some mining pools are dangerously close to that point, the protocol itself was initially designed with that goal in mind).
The problem to solve is why vendors, including Google's own Nexus devices, can't manage to keep hardware support going past about 2.5 years. We're supposed to dump our devices in a landfill every 2 years because they are saddled with unresolved security flaws?
The problem is that companies make money immediately when they sell a device.
Not over the lifetime of a device.
They have strong incentive to put immediately a new device out-of-the-door (sometime even not perfectly finished, with still bugs needing fixing), but not much incentive to write updates 2 years down the line (a that moment, writing an update won't translate in immediate money input, diverts ressources from getting the next money making device out, and might even create a competitor for the new device as the old one remains too much useful).
This is a bit alleviated if the company has a tighly concentrated line of device where work for updating one translate into "free" updates for another.
Apple, by having a small set of relatively similar devices is one such example.
A company such as Jolla making a OS like Sailfish is mostly dealing with user space software suite, and beside a few problems with kernels locked to whatever version the hardware manufacturer supports, can actual transfer their update efforts to the whole range too (Jolla1 smartphone is still benefiting of the updates effort and runs the same version of OS as the latest Sailfish X running on Sony Xperia X devices).
The hope of Google, by making their own OS and by making it micro kernel, is that most of the hardware-manufacturer dependant shit will be locked inside a few daemons with precisely set APIs and Google should be able to to replace all the other daemons as needed (file systems, etc.).
As opposed to linux, which is in a constant flux of evolving, and on purpose only exposes an external API to the userland, but might break its own internal interfaces. (So it's hard to port a 4.4 kernel on a piece of hardware whose manufacturer only provided a 3.2 kernel and drivers set).
Of course, if hardware manufacturer took example of the desktop/laptop world, specially with AMD and Intel, and had opensource drivers stack maintained in the upstream vanilla kernel, things would be much more easy...
My expectation regarding Fuschia are actually rather low.
There is a ginormous invested know-how in Linux in the embed world (which itself leverage the even more giant community around Linux). It would be hard to convince all the hardware manufacturer to switch to another completely different kernel and way to develop drivers. It's a very steep uphill battle.
And similar problems emerge for the Moon.
Yes, it is roughly the same distance from the sun as Earth is (given that the moon orbits around the later, duh...).
And yes, no significant atmosphere means even more light available to a moon base than to earth surface solar pannels...
But being tidally locked to earth and with a approx 28-day orbit around it means that the Moon base's solar panels are guaranteed to be in the dark for 2 whole weeks (unless you go even more crazy with orbital mirror reflecting light toward the solar panels, etc.)
Batteries could be a solution, adding a nuclear power source to supplement the solar specially during moon night is another.
1. It's China.
2. If cheating is a problem, Tencent won't be selling as many units as they would like. It would mean commercial problems, loss of revenue. They need to do whatever they can to maintain (or in this case: guarantee future) profits (and this being China, they can actually a lot).
So one guy in the giant multi-million corporation goes to talk to his neighbours' friend who happens to be a high ranking official. Some kick-backs are exchanged. New laws and policies are written.
Tencent guy sees it as a good investment of money to secure profit. Gov guy sees it as nice side revenue to his gov job. The rest of the world pretends to be appalled to how much politicis is fucked up (even if nearly every one is doing it, though at a smaller scale and a lot less in the open, in their own home countries).
You would think that all three would be required to send out an emergency alert message.
Then in case of an actual emergency (say, when category 9 hurricane 'Zorro' hits Hawai in a couple of months), you'd be complaining that the alert wasn't sent because it relied on a complex validation procedure that required perfectly coordinated simultaneous action by 5 person, one of which was sick on that day, and the other lost his keyfob 12 months ago when his dog ate it.
That's the complex problem with emergency procedures, they need both at the same time be quick enough to execute in case of actual emergency, but have enough confirmation step to not be triggered by incident.
and a Russian, German, British, German, or Chinese company be more trustworthy?
At least, in the specific case of Germany (and to a lesser extent, other European countries - more often in the central-nordic. Switzerland is another such example. On the other hand France's controversial State of Emergency is a counter example), the laws happens to currently still be on your side.
There are strong law regarding protection of customer privacy.
I'm not saying that none of these countries' secret services will never ever attempt to spy on their own population. (e.g.: Swiss secret sevices notoriously kept files on their own population)
I'm just saying that if a German company ends up in the same situation as Lavabit - i.e.: on the receiving end of a government order to hand out their customer case's private informations - and decides to take it to the court, they have a very high chance to actually win the case.
(And some countries like Switzerland are even more extreme, on ground of being a direct democracy : to reduce such customer protection law, it would take a significant chunk of the population to vote for a law against their own interests. The government cannot pass something like the patriot act unchecked. Lobbying is nearly useless in direct democracies. Though that doesn't prevent the population to be massively stupid every once in a while ...cough... minaret construction ...cough.. ).
but brakes are still mechanical and will continue to be so for the forseeable future due to FMVSS requirements. {...} Yes, I am aware there are cars with electric brakes that can stop themselves... just wanted to clear up that "most" is more "a special few".
And due to the high popularity of adaptive cruise control (ACC) and forward collision avoidance systems (FCAS), the "special few" is becoming "quite a big percentage of the cars present on today's street".