But it was a bit of a sham. Their '40 megaray' camera had an actual still image equivalent resolution of 0.4 megapixels
That's inherent to the technology.
The whole idea behind this light field photography, is that the 40mega pixel sensors receives an array of ~1000 (a matrix of 16x16) sub images. That gives you ~400k pixels per sub-image, but the final image that you get out isn't just on of the 400k pixel of the image, it's what you get by doing computations based on all the 40m pixels that the sensors captured.
That's why the 400k pixels aren't much relevant (they weren't kept "hidden in a conspiracy", they where mostly non relevant to the quality of the image).
That's also why they definitely cannot call the 40mege pixel of the sensors "40 mega pixels", because they won't directly translate into pixels of the final image (unlike a classical camera). It's artificially generated picture which use an array of 40 million of data point to infer it. Hence the funny "40 mega rays" name.
Now whether this is useful and can be actually leveraged for the en user ? meh...
Probably not in the current form (big expensive camera, as huge and heavy as top DSLR, but producing less high quality pics, but with the added gimmick that you can do the focus *in-post* instead of before taking the picture) - it was basically a technological curiosity wrapped in a way to much expensive shell.
But it can *definitely* have some success in *smartphones*.
No matter how much high you pump the number of (theoretical) pixels in the sensor, there's only so much light that can cover a given surface. Current smartphones are hitting physical len limitations hard (even more so because they have even thinner bodies).
Light field photography could be also away to get more image quality out of thin smartphone bodies (Instead of have 1 or 2 pinholes over corresponding tiny sensors, future smartphone could have a huge area at the back of the phone covered by a whole array of micro lens. Think the combined dual-camera tendency turned up to eleven) and doing the focusing in post-processing being as common as picking up instagram filters.
Except that the app is not his (OpenWhisperSystems, by Moxie Malinspike), and it is not exactly new either (4 years old).
In fact, given that Signal uses an open documented protocol, you're free to use any other compatible software (e.g.: running on Jolla's Sailfish OS).
Unlike with WhatsApp which also have switched to the same encryption protocol, but actively tries to detect and kickban 3rd party apps. (So you *have* to run a proprietary blob and hope that they have implemented encryption protocol properly and didn't leave a giant backdoor)
---
And Signal protocol is also usable on Facebook's Messenger and Google Allo when these are switched into private or incognito mode. But those aren't open source so there's no way to test that they don't do things behind your back.
At least facebook isn't actively hunting 3rd party apps, giving rise to stuff as purple-facebook plugin that taps into the same proprietary JSON interface as the Android app - but currently, this plugin lacks the manpower to maintain signal protocol. And even if purple-facebook starts supporting encryption, you would need *both end-points* to be secure (thus both of them running opensource auditable apps).
There isn't a 3rd party implementation of Google Allo, for now you need to stick with the official blob (and are dependent on their honest and correct implementation of encryption).
I'm trying to recall if there is anything I have to do after a dist-upgrade on Ubuntu once it reboots,..
And sometime you don't have even to reboot.
Have a look at 'needrestart' package. It's a plugin to dpkg that can automatically identify which services use files (such as libraries) that got overwritten during the upgrade, and give you the possibility to restart them.
So if it's not a big upgrade (like between two refreshes of the same LTS on Ubuntu, or a point release of Debian stable), you might postpone the reboot.
openSUSE has the ' zypper ps' command doing a similar detection (but you have to type the 'systemctl restart {blah}.service' yourself), which is pretty much useful on a rolling release distro like Tumbleweed which has extremely frequent but tiny updates (do these updates affect any executables that are currently running ?)
thinking that bitcoin was anonymous then they were fooling themselves.
...and also completely ignoring the specs.
By *design*, the whole "distributed trust" of bitcoin comes from the blockchain, a public ledger of which each (full) node on the bitcoin network has a full copy. What did you expect ?
The point of the bitcoin protocole was never anonymity, it was always the absence of a central authority (in theory - some big mining pool are close to it).
---
(yup, it uses cryptographic public key, instead of your actual real-world identity, so there some minimal level of pseudonymity. That just means that your neighbor Joe Sixpack will have a hard day to guess your transactions. A large actor with enough ressource (motivated police force) can unmask transaction by correlating with real world events (bitcoin payment leading to product shipped to real-world addresses). For an even larger actor with even more ressources - like the NSA - unmasking bitcoin transaction is probably a walk in the park).
beside PC compatible running Windows, there is this other small thing in a corner also used to play games. It's called "consoles" (Surprise: It's actually a sizeable market. You might want to gloat that consoles are dead and PC/Windows killed them. But in practice its still a market that bring a lot of cash in).
Except for a few studio that only produce exclusives, a technology that is only available on a single platform (e.g.: PC/Windows) is shutting away a lot of potential profits from other platforms.
You can expect that ray-tracing won't gain much traction until there are also similar technology on other platforms. (i.e.: Microsoft port DXR to whatever clone of Windows/Direct X runs on XBox, Sony puts some local similar stuff for their playstation line, etc. and Khronos announces some new "OpenTrace" API to be used cross platform, implemented atop of the former or atop of Vulkan low-level APIs)
But Firefox isn't using SHA-1 as a password hash; it's being used to generate deterministic noise for generating an encryption key, at which point the hash is thrown away. So if you generate billions of hashes that won't help you because you don't have the original hash to compare against.
Until you find a situation where you at least know 1 password stored in a database (stolen through other channels - e.g.: one of the webserver database leaks mentionned regularily on haveibeenpwnd.com) or rely on password reuse (there's bound to be at lest 2x the same entry over the whole password data base).
At that point, the idea is to brute force the master password, until either two entries decrypts to the same content or until at one entry in the data base matches the 1 clear password you know.
Of course it's much slower (every single entry in the database uses a different salt, so you need to iterate over the whole database every single time for every iteration of the brute force attack), so it's definitely not the situation of "brute force a 6 characters password for 2 dollars on EC2", but it's still within the realm of possibilities.
If someone leaves a major highway to try a back road, isn't that a hint that the major highway is full of traffic? So I'm interpreting this report as noticing that all the extra cars on the road are filling up the back roads, since the major highways are about as full as they can handle.
Yup, that was also my impression, specially regarding apps that try to be "smart" and guess where traffic is stuck. Be it apps that leverage big data (Waze is supposed to autolearn traffic fluidity). Or plain old normal GPS apps that rely on the traffic announcement over FM RDS (and whatever its upcoming DAB+ successor is) to offer alternate course like almost any in-car built-in satnav.
Also : other very mundane reasons : - not so smart apps.
not every single app has precise fluidity information for every last metet of road. some of them fall back to plain old "speed (based on official limitation) x distance (on map)" heuristic to determin optimal path. And thus end up advertising completely stupid routes, just because they happen to look shorter on the map, and are tagged with the same speed limit (e.g.: 50 km/h in residential area), but one is a large arterial road, the other is a tiny passage way.
Google Maps has been an offender in my experience (probably I live on the wrong side of the atlantic pond regarding to where has their cloud the most informations about), as from time to time even specialised satnav vendor such as Tomtom (Yes, I know that the pass through the montain seems much shorter on the map than taking the highway aroudn the whole mountain. But it's winter and the pass might not even be open)
---
Last, regarding the whole part autonomous cars :
Remember that the whole big advantage touted behind autonomous cars and any other shared form of transportation (shared cars as in lots of big cities including plain old non-autonomous shared cars, and even ride sharing systems as the mentioned Uber and Lyft), is that it *reduces* the number of cars on the road. (Has been even studied, with some studies showing that 1 single shared (non-autonomous) car, replaces 4 cars).
So if autonomous cars rise in numbers, that will decrease the total flow of car and actually result in lest congestionned small streets. Not more. (as is already the case with car sharing systems)
except that not until the 32bits (some) / 64bits (most) game console era did those start to have any FPU. (with maybe some custom DSPs embed in some cartridge and the FM synthetisers being exceptions)
so building a SNES reimplementation in FPGA is about the only situation where you don't need floating points.
the editors should stop writing summaries one their phone (with autocomplete on).
If the changes are persistent, as at least some of the sources have indicated, then this *is* a serious problem,
It's a serious problem that require flashing the UEFI/BIOS firmware. If you have the capacity to flash firmware, you *already at that point* have the capability to do a ton of awful and persisting damages. The fact that these peculiar variants happen to attack the AMD PSP is just a small foot note detail.
To put it into perspective, this has nothing to do with the numerous bugs and exploit that have plagued IntelAMT and IPMI (those were more of the type "the lights-out remote management system is so buggy and fucked up, that you can basically use it as a backdoor"). Here, it's more "if you upgrade and put a buggy lights-out remote management tool, you'd be openning a backdoor" - Well no shit.
(Except that the AMD PSP isn't used for Light-out-management. But for handling stuff like DRM, TPM, boot firmware signing, etc. But still, if you install a crappy one, yes, the system will be hosed. And if have the capability of installing a one, then you have tons of possibility to hose the system. Including possibility that have nothing to do with AMD PSP).
Its just that, by the time the study gets designed approved financed and finally launched, the game technology has progressed.
They should be studying modern, violent & hyper competitive games.
Which again, by the time the study gets designed approved financed and finally launched, will have been forgotten.
It's almost a case of "{new technology that I haven't grown up with} will cause the end of civilisation as we know it !". See Douglas Adams's quote from Salmon of Doubt about "Rule of reaction to technology".
You know; the ones where abuse is rampant & swatting occurs at the extremes.
One should make a distinction between toxic culture of some assholes playing games, and the game themselves.
This study partially attempts to solve it by - on purpose - using non-gamers. I.e.: people how aren't part of the "twictch.tv-swearing-and-swatting" scene and see how they react.
IntelME was supposed to be exactly that: a separated isolated ARC core in the chipset, that was used to handle administrative tasks even if the main x86 CPU was shutdown (IntelAMT - Intel own NIH syndrom "lights out management" vaguely similar to IPMI). Got further repurposed for some trusted security tasks (TPM), got further repurposed for DRM related task, used also for critical steps to bring the hardware up.
And was the target of attacks and exploits last summer. Attacks that thus work EVEN when the main x86 CPU is turned off (remembre, before the overarching list of roles, it began as an IPMI-like solution). To the point that vendors like DELL started offering new BIOS/UEFI firmware, in which the Intel ME code was stripped to the bare strict minimum for just the "bring hardware up" part.
But I'm sure *this time around* the walled secure CPU core that Intel promise will be flawless and never exploited~~
I just googled agenda 21 and it looks like an actual UN action plan. Why is that lumped in with pizzagate? Are UN documents also conspiracies?
When researching this kind of stuff, remember to also double the search by running the exact same keywords, but this time adding "conspiracy" at the end (or any other similar keyword that is likely to show up in conspiracy theorists' title - 'plot', 'evil', 'truth' might also work too).
Basically :
Agenda 21, the normal outlook - Well a set of recommendation by the UN, in the hopes that maybe we won't completely fuck up our planet and it environment. Written at some ecological conference a couple of decades ago. If you're a corporate magnate, you might be mumbling about potential implementation being hindrance to your current business model.
Agenda 21, the conspiracy theorist's take - It' an evil plot on the leftists agenda to limit our sovereignty. It's an effort by the Deep Goverment to control the global subserviant sheeple population. UN Black Helicopters are going to invade the White House and tople the government ! The end game is to dismantle the western industry and eventually lead the population to extinction !!! Somehow, the reptilian Illuminati are Involved !!!!
One could also consider the opensource friendliness of the chipset :
- Broadcom's VideoCore is one of the few ARM chips where everything running on the ARM core can be opensource upstream code (Raspbian updates its kernel regularily). All the proprietary blobs are restricted to the DSPs handling video. You can even run without them (specially if you aren't interested in processing video, but use the pi as a micro server).
(The Freescale family of chips selected by Purism for their Librem 5 smartphone is another example that can be run 100% of opensource). (I suspect that the RISC-V will also bring interesting free-software friendliness)
- Lots of other chips limits you to kernel version "whatever happened to be popular on Android back then, now you're stuck with it". You're stuck with antique kernels full of blobs.
One could consider the community : Raspberry Pis are among the most popular SBC, have gathered a ginormous community of users. That means you can easily find tons of answers for common questions easily on forums and other web ressources, lots of add-on products will be specially be designed with raspberries in mind etc.
In the few case I've researched the subject: the cases of cheaper board with higher-clocked CPUs and more features touted on the bullet list provided by the marketeers, tend to also use much cheaper chips with crappier Linux support and although they tout lots of GPIO pins, those aren't 1:1 compatible with Pi (nor even follow any attempts of standard like HAT). They're great if you only plan to interface them with extremely generic hardware (basically if you mostly attach your stuff on the USB ports) or if you're making your own hardware (where the only requirement you have regarding the GPIO pins is that they exist).
Raspberry Pi basically has managed to become the IBM PC of the home computer : sure, better things exist elsewhere. But that's what everything is palying with. And if like me you're not the world's best expert in SBCs, better to stick with the most popular and most widely supported stuff.
I have a NAS with an Intel Atom CPU from a decade ago that will still run circles around any PI setup.
Good for you, but that's not my use case. Don't need the giant bandwidth. Only need the extreme low power to serve files at video-playing bandwidth. A glorified networked USB stick, if you want. Combined with printing service (can locally print a file that was updated to it, circumventing limitations of a locked-down windows laptop with no admin account to install printer drivers). Could also install rtorrent on it, for occasionnal download. Coupled with a couple of other similar extremely simple services.
Your Atom installation, while porbably awesome, is completely overkill to me.
If you're going to go with a PI setup for a NAS, you might as well just take the router you already have that likely already has a USB port and put something like DDWRT, Tomato, or LEDE on it and attach an external HD to the USB port, then enable Samba on the firmware distro.
That was *exactly* my target. Except that the router is locked, can't be installed with any opensource firmware. (It's the thing I got for free from the provider).
I could have thrown it away and spent decent money on a high quality router.
Or just re-use an old raspberry Pi that I have laying around, basically installing the same kind of software functionality that I would have installed on a router with OpenWRT.
(Also, the router happens to have decent Wifi, so it basically at least works as intended as a router. Though without IPv6).
Already solved... nearly two years ago. It hasn't been used yet because no mainstream headset has installed the eye tracking sensors needed.
According to the source you cite : the system works at 250Hz to avoid the fovea out-running the the rendering. That is way much higher thant the 90 FPS target of Occulus Rift (designed so the *head-motion* doesn't out run display. Intertia, etc.).
It will take some time until : - VR hardware catches up and makes screen that accept framerates beyond 250 FPS - The GPU rendering hardware is powerful enough so that, once factoring the foveated rendering speed gains, the over all system can stay above 250 FPS, as close to 100% of time as possible....while keeping in mind that the above (throwing GPU power at high FPS) is in competition with other targets (throwing GPU power at more scene detail and more pixels).
But could still be implemented half-way (not perfect foveated rendering, but slightly reducing resolution of parts of the image that are so much far away that there isn't much risk of over shooting even at lower FPS).
People wanting to do small tinkering projects, or file servers, or whatever are probably all happy with the Raspberry 1 (I certainly am).
People wanting to do video processing (which was the initial target of this class of chips by Broadcom anyway) are probably happier with more Mhz giving more power to offload h264 (and partial h265) to the hardware. People using it as a retro gaming machine are also happier with more Mhz giving faster / more precise emulation.
Starting from Raspberry Pi 3 (can't find any information about Raspberry Pi 2 version 1.2 which use the same CPU as Pi3, not as earlier Pi2s), the U-boot bootloader is UEFI compliant and several Linux distributions's (such as, for example, openSUSE Tumbleweed) AArch64 image can be run in 64bits mode.
So there should be a way to load Debian AArch64 on your Pi. (But of course it will be less optimized/geared toward Pi than a real Raspbian 64)
From what I've read in forums and interviews, there isn't a plan to do Raspbian64 in the immediate future, due to lots of 32bits (ARM6 or 7) Pis still in the wild, and the Rasberry Pi Foundation wanting not to dilute their resources over too many goals.
(Then I'm sure that the gentoo people have their own flavour completely optimized to the bone for 64bit Pi)
WTF? No they don't. My router doesn't download and run anything during normal operation and it doesn't need to and shouldn't need to.
Maybe your own doesn't.
But lots of equipment provided to client by telco (the router that you received for free when you signed up for DSL/cable/fibre internet) do.
In the name of user-friendliness, defined as "my grand-ma is unable to upgrade the firmware nor even configure the settings, so everybody is imposed auto-updates", nearly all of these device download and run a ton of shit. It might be just scripts (to set or update configuration) or it might be complete firmware upgrade (including telco's own "optimisation" - you tauch preloaded crapware waws limited to desktops?)
cue in rant by RMS about "autoupdate being a form of remote execution and thus security danger".
Anyone who installs a router that downloads stuff and runs it without their express command to do so is simply asking for it.
Sadly that's a situation that is enforced by telco on unsuspecting users. You got to get out of your way to buy your own personnal router, disable it's auto-update/auto-configuration capabilities, plug it in and manually configure it and upgrade it to a known good firmware (preferably something from OpenWrt/LEDE if you decide not to trust the original equipement manufacturer.
On top of that I don't understand why they call out DLLs. Mikrotiks run RouterOS based on Linux, most of which don't use DLLs for anything.
As pointed out by other, in this case it's the administration software that downloads Windows DLLs from the router and runs them on the admin's PC. But all the rants about auto-update and remote execution still apply in this context too.
And it's not new at all. Microsoft SMB/CIFS "shared printers" provide drivers on the servers. A client Windows system that wants to send documents on a server print queue will also automatically download and run printer drivers in the exact same fashion.
(But yeah, in this case, it's not the RouterOS itself loading.so and.ko and running them without any user approval).
on the other hand, stereo images is really one of the best situations for multi GPU rendering.
Once the geometry is processed (which can be somewhat balanced accross multi GPUs), the rest of the rendering is different between both eyes (that's the whole point of parallax) with little inter-dependency. You can simply subdivide the VR image into "two eyes, one eye per GPU"
(Though for objects far from eyes, the tesselation and rendering should be very similar / almost identical. Again that's due to the parallax).
This is not false, but it is not quite true either.
How often do you look as far left as possible? Rarely. We only actively look around directly within about 30-50% of our full view capability, except in the rare cases when we're trying to look at something without others knowing (ie, side-eye). So only the central visual field needs this level of pixel density to be nearly indistinguishable from real life's resolution. The visual fidelity could drop to 1/2 or even 1/4 outside this and you'd barely notice.
Which is exactly what ends up happening on modern VR headset (everything since the Occulus) which tend to use as simple as possible optics just to keep the image in focus (as opposed to older VR headset which used more complex optics to give perfect rectangular picture floating distorsion free in front) and use software compensation (shaders on the GPU to pre-distort the image in the opposite direction).
Due to this pillow-shape distortion, more pixels are used in the middle of the image (where the eye looks most of the time) than the side of the image (where the peripheral vision is looking most of the time).
In addition, we can render even fewer pixels with eye tracking. This has already been successfully tested on current equipment with eye tracking and foveated rendering... rendering the center at full resolution, but increasingly fewer pixels per inch as you go away from the center of vision. And it already workes very well, quartering the rendering power needed. With a massive full-vision FOV, it would reduce rendering by needs by 20-40 times.
As proven by all the research done in VR since Occulus : the main drawback would be rendering speed/feedback loop. Will this eyesight tracking work fast enough so the image rendering doesn't lag too much behind the eye motion ? (Other wise you'd be seeing blurred image when ever you're looking around fast, as the eye motion overshoots the region that was rendered at high resolution by the fovea tracking you're advocating).
Avoiding lags and blurs seems to be key to keeping the immersion realistic, and reducing risks of motion sickness.
Adding a eye-tracking/resolution feedback loops risks increasing these lags and blurs.
But the question and problem is, how many pixels CAN the human eye see? Just like 4K televisions you won't be able to see them all.
- Depends on how wide those pixels are spread. More precisely, which angle of your view they each occupy. The 4k television is just a rectangle in front of you. Ideal VR headset would cover nearly everything in front of your face, so no matter which direction you turn your eyes, there's still picture on the screen. So these 5.5k pixels are going to get spread across your whole field of vision, i.e.: at least 180, or ideally a tiny bit more (from when you're looking sideways). So overall, a VR pixels is going to look several times bigger than the pixels on the TV screen.
- Depends on which part of your field of view. They eye's retina and brain's visual cortex (and Convolution Neural Net which are inspired by it) works by comparing neighboring signal. So the distance between neighboring receptors will decide how fine the details you can see. Receptor density varies a lot across the region of the eye. Some region have very closely packed photoreceptor (fovea in the middle), so you can distinguish very fine pixels. Worst region have receptors very wide appart, such as the blind spot (a hole in the retina where the optical nerves exits the eyeball). There you can miss giant swaths of visual space if the details fall inside the blind spot, in between photo receptors.
- Depends on the geometry of the VR optics. Unlike older VR headset (say eMagine's 3D Visor. Or the old school VFX1 of old time), modern VR headset don't use over complicated optics to make perfect projection of the screen, but just the simplest possible stuff to keep the image in focus (and compensate in software - shader software on the GPU). The image end up distorted. But in a pillow shape that actually compensate the above. In the middle of the VR image (i.e.: where the high resolution eye's fovea will be looking most of the time), a lots of pixels are compressed into the image, you get a better resolution. In the side of the VR image, the image is heavily distorted and fewer pixels are stretched over a wider field. By luck, peripheral vision, with its lower spatial resolution, would be looking there most of the time. So whenever you're looking straight ahead, the optical properties of the VR headset compensate a bit for the variable resolution of the retina.
Basically, due to point 3, the way the pixels are stretched according to point 1 is partially compensating point 2.
Are non-Tesla entities allowed to make supercharger stations? {...} but when more electric vehicles come on the market it would be much better if they all shared a common charging interface. No one wants to wander around town looking for a compatible charge-station.
In Europe, there's a standard to which most manufacturer are gravitating toward : Mennekes (official name Type 2 (VDE-AR-E 2623-2-2)). It's mostly designed to carry tri-phase AC current.
Most of the cars sold in Europe tend to use Mennekes or have adapters for it. European Tesla, as far I've seen, come with Mennekes sockets instead of the weird proprietary shit that they use in the US.
Different Type 2 connectors will simply advertise different max current to the car. Your home charger will advertise current up to 15A (perhaps 25A) on 1 or 3 phases. High speed charger will advertise much higher currents.
The main difference setting appart Teslas is how they handle DC. The current standard is based around "Combined Charging System" (CCS) : two extra pins below the connector to carry the high voltage high current DC power. Tesla instead re-use the AC pins with some proprietary signaling to advertise DC instead of AC.
At least where I live, you can find AC Mennekes charger in lots of public places, and nearly every parking at least features normal house-plugs giving low current AC. On some big highways you can even find charging stations that features Mennekes, CCS and ChaDeMo.
Usually the house-plug style chargers are free (they are actual house plugs with only fancy box around them advertising them as vehicle chargers). AC Mennekes charge tend to be paying, but not much more expensive than base electricity costs. All the tri-standard high speed chargers I've seen are paying, but again, close to electricity costs. Most of the above are usually made available in partnership with the local utility city company.
You can charge Teslas at them but :
- due to differing standards, you can only charge them with the AC Mennekes. You can't charge them DC (they lack the CCS pins).
- they'll charge slower than on Tesla Super charger (or than if they had the DC pins).
I think I've read that Elon Musk isn't asking royalties for companies to implement the DC Tesla protocols. So maybe eventually the tri-standard high-speed chargers can be modified to allow DC Tesla charging on their Mennekes plug. (I've read about un-approved Tesla mode enabled on some multi-standard charger)
I'm sure there as some ChaDeMo or CSS to Tesla adapters on the market, too.
In short :
- Yes, in Europe, there are other brand of fast chargers than Tesla.
- Due to differing implementation for DC, Tesla can't user their higher super charging speed there, but they still can "normal charge" with AC.
- The charging interface is already common, except for the above exception (and except for some older cars that use older standards like Type 1).
You'd still need to find a way to persuade the victim to also enable cam access to that rogue malicious script, but yes, that would be a typical way to abuse such modern web API, to almost-litteraly get a finger print, which can be monetized by tracking by ad provider. A malicious chat app (like the scam clones of WhatsApp) would actually manage to have a valid reason to ask for proximity and camera.
The big pro, is that usually the selfie-cam is close to the ear speaker which in turn (for obvious reason) is close to the proximity sensors. So the ear will definitely be in-frame for the selfie cam. The big con, is that the selfie cam isn't optimized to focus on extreme close ups. (The attacker would need to correctly time the moment the ear leaves the vicinity of the proximity sensor, with the best moment to take a sharp-enough picture of the retreating ear. e.g.: after the sensors notice ear departure, wait 500ms and take the picutre then, it's should be in the best focus range).
I wasn't arguing wether the x86 or the ARM micro architecture is the "ultimate best one ever".
The parent was just point that intel never had a good CPU for smartphone.
I'm point that it's worse: they used to have one (an ARM based one) but managed to sell it out at the wrong time.
the micro-architecture is only relevant to make the "never had a good cpu for smartphone" sentence true. They never had a x86 one. They actually has a good CPU for smartphone (which happens to be an ARM, but that's completely orthogonal to my point. it could have been MIPS, it could even had been a motorola-compatible, etc.) but they managed to throw it away.
---
Though I partially agree with that the "RISC is always better no matter what" mantra is a bit overrated. (Mainly, the "cruft" often attributed to x86 doesn't really play a role on the scale of CPU currently made by Intel and AMD for workstations/servers/laptops)
On the other hand, the RISC is still relevant in some extremely small form factors (embed). And as the smartphones progressively grew out of the embed world (there are the precusors of IoT before IoT was a thing), ARM eventually ended up sticking.
Yes, Intel could have poured ressource to make a smartphone-grade lesser-atom-like embed cpu. Probably. But as you point out, it's definitely not worth the cost. The single main advantage selling point of x86 (running unmodified binary code) is moot in this form factor (again, 3D Studio on a 5 inch screen ?!)
What would make sense, instead of re-inventing a whole new wheel (a hypothetical smartphone-grade intel cpu) intel did the right thing and acquire a company and a core that is smartphone-ready (StrongArm. - it happens to be an ARM but that's orthogonal to the whole debate. The key point here isn't x86 vs ARM. The key point is "core designed to work in sub-notebooks and settop-box" (i.e.: relatively power hungry) vs. "core designed to work in smartphone, pda, etc." (i.e.: even less ressource consuming) But somehow Intel threw it away at the wrong time.
That's also why we aren't seeing that many practical real-world use of ARM in servers. Most of the existing ARM cores happens to be optimized for the ultra-low ressurce stuff such as smartphone. Not that many ARM cores happen to be good for servers (e.g.: not many do feature SATA bus).
And finally note that AMD is planning to eventually go the reverse route : acquire a 3rd party ARM core (Cortex core in Opteron A), and then progressively build a server-grade ARM CPU out of it (upcoming K12, eventually one day, when AMD has enough left-over ressource after the current focus on Zen).
Slashdot Mirror
But it was a bit of a sham. Their '40 megaray' camera had an actual still image equivalent resolution of 0.4 megapixels
That's inherent to the technology.
The whole idea behind this light field photography, is that the 40mega pixel sensors receives an array of ~1000 (a matrix of 16x16) sub images.
That gives you ~400k pixels per sub-image, but the final image that you get out isn't just on of the 400k pixel of the image, it's what you get by doing computations based on all the 40m pixels that the sensors captured.
That's why the 400k pixels aren't much relevant (they weren't kept "hidden in a conspiracy", they where mostly non relevant to the quality of the image).
That's also why they definitely cannot call the 40mege pixel of the sensors "40 mega pixels", because they won't directly translate into pixels of the final image (unlike a classical camera).
It's artificially generated picture which use an array of 40 million of data point to infer it.
Hence the funny "40 mega rays" name.
Now whether this is useful and can be actually leveraged for the en user ?
meh...
Probably not in the current form (big expensive camera, as huge and heavy as top DSLR, but producing less high quality pics, but with the added gimmick that you can do the focus *in-post* instead of before taking the picture) - it was basically a technological curiosity wrapped in a way to much expensive shell.
But it can *definitely* have some success in *smartphones*.
No matter how much high you pump the number of (theoretical) pixels in the sensor, there's only so much light that can cover a given surface.
Current smartphones are hitting physical len limitations hard (even more so because they have even thinner bodies).
Light field photography could be also away to get more image quality out of thin smartphone bodies (Instead of have 1 or 2 pinholes over corresponding tiny sensors, future smartphone could have a huge area at the back of the phone covered by a whole array of micro lens. Think the combined dual-camera tendency turned up to eleven) and doing the focusing in post-processing being as common as picking up instagram filters.
Billionaire wants you to use his new app.
Except that the app is not his (OpenWhisperSystems, by Moxie Malinspike),
and it is not exactly new either (4 years old).
In fact, given that Signal uses an open documented protocol,
you're free to use any other compatible software (e.g.: running on Jolla's Sailfish OS).
Unlike with WhatsApp which also have switched to the same encryption protocol, but actively tries to detect and kickban 3rd party apps.
(So you *have* to run a proprietary blob and hope that they have implemented encryption protocol properly and didn't leave a giant backdoor)
---
And Signal protocol is also usable on Facebook's Messenger and Google Allo when these are switched into private or incognito mode.
But those aren't open source so there's no way to test that they don't do things behind your back.
At least facebook isn't actively hunting 3rd party apps, giving rise to stuff as purple-facebook plugin that taps into the same proprietary JSON interface as the Android app - but currently, this plugin lacks the manpower to maintain signal protocol.
And even if purple-facebook starts supporting encryption, you would need *both end-points* to be secure (thus both of them running opensource auditable apps).
There isn't a 3rd party implementation of Google Allo, for now you need to stick with the official blob (and are dependent on their honest and correct implementation of encryption).
I'm trying to recall if there is anything I have to do after a dist-upgrade on Ubuntu once it reboots,..
And sometime you don't have even to reboot.
Have a look at 'needrestart' package. It's a plugin to dpkg that can automatically identify which services use files (such as libraries) that got overwritten during the upgrade, and give you the possibility to restart them.
So if it's not a big upgrade (like between two refreshes of the same LTS on Ubuntu, or a point release of Debian stable), you might postpone the reboot.
openSUSE has the ' zypper ps' command doing a similar detection (but you have to type the 'systemctl restart {blah}.service' yourself), which is pretty much useful on a rolling release distro like Tumbleweed which has extremely frequent but tiny updates (do these updates affect any executables that are currently running ?)
Unless you were saying it in 1990, not your joke.
And that an evolution from the IBM Joke.
...and you forgot to mention something about your lawn..
And Dianne needing to get away from it.
thinking that bitcoin was anonymous then they were fooling themselves.
...and also completely ignoring the specs.
By *design*, the whole "distributed trust" of bitcoin comes from the blockchain, a public ledger of which each (full) node on the bitcoin network has a full copy. What did you expect ?
The point of the bitcoin protocole was never anonymity, it was always the absence of a central authority (in theory - some big mining pool are close to it).
---
(yup, it uses cryptographic public key, instead of your actual real-world identity, so there some minimal level of pseudonymity.
That just means that your neighbor Joe Sixpack will have a hard day to guess your transactions.
A large actor with enough ressource (motivated police force) can unmask transaction by correlating with real world events (bitcoin payment leading to product shipped to real-world addresses).
For an even larger actor with even more ressources - like the NSA - unmasking bitcoin transaction is probably a walk in the park).
the only OS for gaming
beside PC compatible running Windows, there is this other small thing in a corner also used to play games.
It's called "consoles"
(Surprise: It's actually a sizeable market. You might want to gloat that consoles are dead and PC/Windows killed them. But in practice its still a market that bring a lot of cash in).
Except for a few studio that only produce exclusives, a technology that is only available on a single platform (e.g.: PC/Windows) is shutting away a lot of potential profits from other platforms.
You can expect that ray-tracing won't gain much traction until there are also similar technology on other platforms.
(i.e.: Microsoft port DXR to whatever clone of Windows/Direct X runs on XBox, Sony puts some local similar stuff for their playstation line, etc.
and Khronos announces some new "OpenTrace" API to be used cross platform, implemented atop of the former or atop of Vulkan low-level APIs)
But Firefox isn't using SHA-1 as a password hash; it's being used to generate deterministic noise for generating an encryption key, at which point the hash is thrown away. So if you generate billions of hashes that won't help you because you don't have the original hash to compare against.
Until you find a situation where you at least know 1 password stored in a database (stolen through other channels - e.g.: one of the webserver database leaks mentionned regularily on haveibeenpwnd.com) or rely on password reuse (there's bound to be at lest 2x the same entry over the whole password data base).
At that point, the idea is to brute force the master password, until either two entries decrypts to the same content or until at one entry in the data base matches the 1 clear password you know.
Of course it's much slower (every single entry in the database uses a different salt, so you need to iterate over the whole database every single time for every iteration of the brute force attack), so it's definitely not the situation of "brute force a 6 characters password for 2 dollars on EC2", but it's still within the realm of possibilities.
If someone leaves a major highway to try a back road, isn't that a hint that the major highway is full of traffic? So I'm interpreting this report as noticing that all the extra cars on the road are filling up the back roads, since the major highways are about as full as they can handle.
Yup, that was also my impression, specially regarding apps that try to be "smart" and guess where traffic is stuck.
Be it apps that leverage big data (Waze is supposed to autolearn traffic fluidity). Or plain old normal GPS apps that rely on the traffic announcement over FM RDS (and whatever its upcoming DAB+ successor is) to offer alternate course like almost any in-car built-in satnav.
Also : other very mundane reasons :
- not so smart apps.
not every single app has precise fluidity information for every last metet of road.
some of them fall back to plain old "speed (based on official limitation) x distance (on map)" heuristic to determin optimal path.
And thus end up advertising completely stupid routes, just because they happen to look shorter on the map, and are tagged with the same speed limit (e.g.: 50 km/h in residential area), but one is a large arterial road, the other is a tiny passage way.
Google Maps has been an offender in my experience (probably I live on the wrong side of the atlantic pond regarding to where has their cloud the most informations about), as from time to time even specialised satnav vendor such as Tomtom (Yes, I know that the pass through the montain seems much shorter on the map than taking the highway aroudn the whole mountain. But it's winter and the pass might not even be open)
---
Last, regarding the whole part autonomous cars :
Remember that the whole big advantage touted behind autonomous cars and any other shared form of transportation (shared cars as in lots of big cities including plain old non-autonomous shared cars, and even ride sharing systems as the mentioned Uber and Lyft), is that it *reduces* the number of cars on the road.
(Has been even studied, with some studies showing that 1 single shared (non-autonomous) car, replaces 4 cars).
So if autonomous cars rise in numbers, that will decrease the total flow of car and actually result in lest congestionned small streets. Not more.
(as is already the case with car sharing systems)
except that not until the 32bits (some) / 64bits (most) game console era did those start to have any FPU.
(with maybe some custom DSPs embed in some cartridge and the FM synthetisers being exceptions)
so building a SNES reimplementation in FPGA is about the only situation where you don't need floating points.
the editors should stop writing summaries one their phone (with autocomplete on).
If the changes are persistent, as at least some of the sources have indicated, then this *is* a serious problem,
It's a serious problem that require flashing the UEFI/BIOS firmware.
If you have the capacity to flash firmware, you *already at that point* have the capability to do a ton of awful and persisting damages.
The fact that these peculiar variants happen to attack the AMD PSP is just a small foot note detail.
To put it into perspective, this has nothing to do with the numerous bugs and exploit that have plagued IntelAMT and IPMI (those were more of the type "the lights-out remote management system is so buggy and fucked up, that you can basically use it as a backdoor"). Here, it's more "if you upgrade and put a buggy lights-out remote management tool, you'd be openning a backdoor" - Well no shit.
(Except that the AMD PSP isn't used for Light-out-management. But for handling stuff like DRM, TPM, boot firmware signing, etc.
But still, if you install a crappy one, yes, the system will be hosed.
And if have the capability of installing a one, then you have tons of possibility to hose the system. Including possibility that have nothing to do with AMD PSP).
It was GTA5 vs Sims 3. Not exactly violent games.
Sims 3 is non violent on purpose (Gives a point of comparison)
On the other hand, GAT5 back at its time has been controversial (as is the case with other games in the serie).
Its just that, by the time the study gets designed approved financed and finally launched, the game technology has progressed.
They should be studying modern, violent & hyper competitive games.
Which again, by the time the study gets designed approved financed and finally launched, will have been forgotten.
It's almost a case of "{new technology that I haven't grown up with} will cause the end of civilisation as we know it ! ".
See Douglas Adams's quote from Salmon of Doubt about "Rule of reaction to technology".
You know; the ones where abuse is rampant & swatting occurs at the extremes.
One should make a distinction between toxic culture of some assholes playing games, and the game themselves.
This study partially attempts to solve it by - on purpose - using non-gamers. I.e.: people how aren't part of the "twictch.tv-swearing-and-swatting" scene and see how they react.
Intel has already failed at exactly that before :
IntelME was supposed to be exactly that: a separated isolated ARC core in the chipset, that was used to handle administrative tasks even if the main x86 CPU was shutdown (IntelAMT - Intel own NIH syndrom "lights out management" vaguely similar to IPMI). Got further repurposed for some trusted security tasks (TPM), got further repurposed for DRM related task, used also for critical steps to bring the hardware up.
And was the target of attacks and exploits last summer. Attacks that thus work EVEN when the main x86 CPU is turned off (remembre, before the overarching list of roles, it began as an IPMI-like solution). To the point that vendors like DELL started offering new BIOS/UEFI firmware, in which the Intel ME code was stripped to the bare strict minimum for just the "bring hardware up" part.
But I'm sure *this time around* the walled secure CPU core that Intel promise will be flawless and never exploited~~
I just googled agenda 21 and it looks like an actual UN action plan. Why is that lumped in with pizzagate? Are UN documents also conspiracies?
When researching this kind of stuff, remember to also double the search by running the exact same keywords, but this time adding "conspiracy" at the end (or any other similar keyword that is likely to show up in conspiracy theorists' title - 'plot', 'evil', 'truth' might also work too).
Basically :
Agenda 21, the normal outlook - Well a set of recommendation by the UN, in the hopes that maybe we won't completely fuck up our planet and it environment. Written at some ecological conference a couple of decades ago. If you're a corporate magnate, you might be mumbling about potential implementation being hindrance to your current business model.
Agenda 21, the conspiracy theorist's take - It' an evil plot on the leftists agenda to limit our sovereignty. It's an effort by the Deep Goverment to control the global subserviant sheeple population. UN Black Helicopters are going to invade the White House and tople the government ! The end game is to dismantle the western industry and eventually lead the population to extinction !!! Somehow, the reptilian Illuminati are Involved !!!!
Depends on your criteria defining better.
One could also consider the opensource friendliness of the chipset :
- Broadcom's VideoCore is one of the few ARM chips where everything running on the ARM core can be opensource upstream code (Raspbian updates its kernel regularily). All the proprietary blobs are restricted to the DSPs handling video. You can even run without them (specially if you aren't interested in processing video, but use the pi as a micro server).
(The Freescale family of chips selected by Purism for their Librem 5 smartphone is another example that can be run 100% of opensource).
(I suspect that the RISC-V will also bring interesting free-software friendliness)
- Lots of other chips limits you to kernel version "whatever happened to be popular on Android back then, now you're stuck with it". You're stuck with antique kernels full of blobs.
One could consider the community :
Raspberry Pis are among the most popular SBC, have gathered a ginormous community of users.
That means you can easily find tons of answers for common questions easily on forums and other web ressources,
lots of add-on products will be specially be designed with raspberries in mind
etc.
In the few case I've researched the subject: the cases of cheaper board with higher-clocked CPUs and more features touted on the bullet list provided by the marketeers, tend to also use much cheaper chips with crappier Linux support and although they tout lots of GPIO pins, those aren't 1:1 compatible with Pi (nor even follow any attempts of standard like HAT).
They're great if you only plan to interface them with extremely generic hardware (basically if you mostly attach your stuff on the USB ports) or if you're making your own hardware (where the only requirement you have regarding the GPIO pins is that they exist).
Raspberry Pi basically has managed to become the IBM PC of the home computer : sure, better things exist elsewhere. But that's what everything is palying with.
And if like me you're not the world's best expert in SBCs, better to stick with the most popular and most widely supported stuff.
I have a NAS with an Intel Atom CPU from a decade ago that will still run circles around any PI setup.
Good for you, but that's not my use case. Don't need the giant bandwidth. Only need the extreme low power to serve files at video-playing bandwidth. A glorified networked USB stick, if you want.
Combined with printing service (can locally print a file that was updated to it, circumventing limitations of a locked-down windows laptop with no admin account to install printer drivers).
Could also install rtorrent on it, for occasionnal download.
Coupled with a couple of other similar extremely simple services.
Your Atom installation, while porbably awesome, is completely overkill to me.
If you're going to go with a PI setup for a NAS, you might as well just take the router you already have that likely already has a USB port and put something like DDWRT, Tomato, or LEDE on it and attach an external HD to the USB port, then enable Samba on the firmware distro.
That was *exactly* my target. Except that the router is locked, can't be installed with any opensource firmware. (It's the thing I got for free from the provider).
I could have thrown it away and spent decent money on a high quality router.
Or just re-use an old raspberry Pi that I have laying around, basically installing the same kind of software functionality that I would have installed on a router with OpenWRT.
(Also, the router happens to have decent Wifi, so it basically at least works as intended as a router. Though without IPv6).
Already solved... nearly two years ago. It hasn't been used yet because no mainstream headset has installed the eye tracking sensors needed.
According to the source you cite : the system works at 250Hz to avoid the fovea out-running the the rendering.
That is way much higher thant the 90 FPS target of Occulus Rift (designed so the *head-motion* doesn't out run display. Intertia, etc.).
It will take some time until : ...while keeping in mind that the above (throwing GPU power at high FPS) is in competition with other targets (throwing GPU power at more scene detail and more pixels).
- VR hardware catches up and makes screen that accept framerates beyond 250 FPS
- The GPU rendering hardware is powerful enough so that, once factoring the foveated rendering speed gains, the over all system can stay above 250 FPS, as close to 100% of time as possible.
But could still be implemented half-way (not perfect foveated rendering, but slightly reducing resolution of parts of the image that are so much far away that there isn't much risk of over shooting even at lower FPS).
People wanting to do small tinkering projects, or file servers, or whatever
are probably all happy with the Raspberry 1 (I certainly am).
People wanting to do video processing (which was the initial target of this class of chips by Broadcom anyway) are probably happier with more Mhz giving more power to offload h264 (and partial h265) to the hardware.
People using it as a retro gaming machine are also happier with more Mhz giving faster / more precise emulation.
Starting from Raspberry Pi 3 (can't find any information about Raspberry Pi 2 version 1.2 which use the same CPU as Pi3, not as earlier Pi2s), the U-boot bootloader is UEFI compliant and several Linux distributions's (such as, for example, openSUSE Tumbleweed) AArch64 image can be run in 64bits mode.
source: tumbleweed's wiki entry about Raspberry Pi 3.
So there should be a way to load Debian AArch64 on your Pi.
(But of course it will be less optimized/geared toward Pi than a real Raspbian 64)
From what I've read in forums and interviews, there isn't a plan to do Raspbian64 in the immediate future, due to lots of 32bits (ARM6 or 7) Pis still in the wild, and the Rasberry Pi Foundation wanting not to dilute their resources over too many goals.
(Then I'm sure that the gentoo people have their own flavour completely optimized to the bone for 64bit Pi)
WTF? No they don't. My router doesn't download and run anything during normal operation and it doesn't need to and shouldn't need to.
Maybe your own doesn't.
But lots of equipment provided to client by telco (the router that you received for free when you signed up for DSL/cable/fibre internet) do.
In the name of user-friendliness, defined as "my grand-ma is unable to upgrade the firmware nor even configure the settings, so everybody is imposed auto-updates", nearly all of these device download and run a ton of shit.
It might be just scripts (to set or update configuration) or it might be complete firmware upgrade (including telco's own "optimisation" - you tauch preloaded crapware waws limited to desktops?)
cue in rant by RMS about "autoupdate being a form of remote execution and thus security danger".
Anyone who installs a router that downloads stuff and runs it without their express command to do so is simply asking for it.
Sadly that's a situation that is enforced by telco on unsuspecting users.
You got to get out of your way to buy your own personnal router, disable it's auto-update/auto-configuration capabilities, plug it in and manually configure it and upgrade it to a known good firmware (preferably something from OpenWrt/LEDE if you decide not to trust the original equipement manufacturer.
On top of that I don't understand why they call out DLLs. Mikrotiks run RouterOS based on Linux, most of which don't use DLLs for anything.
As pointed out by other, in this case it's the administration software that downloads Windows DLLs from the router and runs them on the admin's PC.
But all the rants about auto-update and remote execution still apply in this context too.
And it's not new at all. Microsoft SMB/CIFS "shared printers" provide drivers on the servers. A client Windows system that wants to send documents on a server print queue will also automatically download and run printer drivers in the exact same fashion.
(But yeah, in this case, it's not the RouterOS itself loading .so and .ko and running them without any user approval).
on the other hand, stereo images is really one of the best situations for multi GPU rendering.
Once the geometry is processed (which can be somewhat balanced accross multi GPUs),
the rest of the rendering is different between both eyes (that's the whole point of parallax) with little inter-dependency.
You can simply subdivide the VR image into "two eyes, one eye per GPU"
(Though for objects far from eyes, the tesselation and rendering should be very similar / almost identical. Again that's due to the parallax).
This is not false, but it is not quite true either.
How often do you look as far left as possible? Rarely. We only actively look around directly within about 30-50% of our full view capability, except in the rare cases when we're trying to look at something without others knowing (ie, side-eye). So only the central visual field needs this level of pixel density to be nearly indistinguishable from real life's resolution. The visual fidelity could drop to 1/2 or even 1/4 outside this and you'd barely notice.
Which is exactly what ends up happening on modern VR headset (everything since the Occulus) which tend to use as simple as possible optics just to keep the image in focus (as opposed to older VR headset which used more complex optics to give perfect rectangular picture floating distorsion free in front) and use software compensation (shaders on the GPU to pre-distort the image in the opposite direction).
Due to this pillow-shape distortion, more pixels are used in the middle of the image (where the eye looks most of the time) than the side of the image (where the peripheral vision is looking most of the time).
In addition, we can render even fewer pixels with eye tracking. This has already been successfully tested on current equipment with eye tracking and foveated rendering... rendering the center at full resolution, but increasingly fewer pixels per inch as you go away from the center of vision. And it already workes very well, quartering the rendering power needed. With a massive full-vision FOV, it would reduce rendering by needs by 20-40 times.
As proven by all the research done in VR since Occulus : the main drawback would be rendering speed/feedback loop.
Will this eyesight tracking work fast enough so the image rendering doesn't lag too much behind the eye motion ? (Other wise you'd be seeing blurred image when ever you're looking around fast, as the eye motion overshoots the region that was rendered at high resolution by the fovea tracking you're advocating).
Avoiding lags and blurs seems to be key to keeping the immersion realistic, and reducing risks of motion sickness.
Adding a eye-tracking/resolution feedback loops risks increasing these lags and blurs.
But the question and problem is, how many pixels CAN the human eye see? Just like 4K televisions you won't be able to see them all.
- Depends on how wide those pixels are spread. More precisely, which angle of your view they each occupy.
The 4k television is just a rectangle in front of you.
Ideal VR headset would cover nearly everything in front of your face, so no matter which direction you turn your eyes, there's still picture on the screen.
So these 5.5k pixels are going to get spread across your whole field of vision, i.e.: at least 180, or ideally a tiny bit more (from when you're looking sideways).
So overall, a VR pixels is going to look several times bigger than the pixels on the TV screen.
- Depends on which part of your field of view.
They eye's retina and brain's visual cortex (and Convolution Neural Net which are inspired by it) works by comparing neighboring signal.
So the distance between neighboring receptors will decide how fine the details you can see.
Receptor density varies a lot across the region of the eye.
Some region have very closely packed photoreceptor (fovea in the middle), so you can distinguish very fine pixels.
Worst region have receptors very wide appart, such as the blind spot (a hole in the retina where the optical nerves exits the eyeball). There you can miss giant swaths of visual space if the details fall inside the blind spot, in between photo receptors.
- Depends on the geometry of the VR optics.
Unlike older VR headset (say eMagine's 3D Visor. Or the old school VFX1 of old time), modern VR headset don't use over complicated optics to make perfect projection of the screen, but just the simplest possible stuff to keep the image in focus (and compensate in software - shader software on the GPU).
The image end up distorted. But in a pillow shape that actually compensate the above.
In the middle of the VR image (i.e.: where the high resolution eye's fovea will be looking most of the time), a lots of pixels are compressed into the image, you get a better resolution.
In the side of the VR image, the image is heavily distorted and fewer pixels are stretched over a wider field. By luck, peripheral vision, with its lower spatial resolution, would be looking there most of the time.
So whenever you're looking straight ahead, the optical properties of the VR headset compensate a bit for the variable resolution of the retina.
Basically, due to point 3, the way the pixels are stretched according to point 1 is partially compensating point 2.
Are non-Tesla entities allowed to make supercharger stations? {...} but when more electric vehicles come on the market it would be much better if they all shared a common charging interface. No one wants to wander around town looking for a compatible charge-station.
In Europe, there's a standard to which most manufacturer are gravitating toward : Mennekes (official name Type 2 (VDE-AR-E 2623-2-2)).
It's mostly designed to carry tri-phase AC current.
Most of the cars sold in Europe tend to use Mennekes or have adapters for it. European Tesla, as far I've seen, come with Mennekes sockets instead of the weird proprietary shit that they use in the US.
Different Type 2 connectors will simply advertise different max current to the car. Your home charger will advertise current up to 15A (perhaps 25A) on 1 or 3 phases. High speed charger will advertise much higher currents.
The main difference setting appart Teslas is how they handle DC.
The current standard is based around "Combined Charging System" (CCS) : two extra pins below the connector to carry the high voltage high current DC power.
Tesla instead re-use the AC pins with some proprietary signaling to advertise DC instead of AC.
At least where I live, you can find AC Mennekes charger in lots of public places, and nearly every parking at least features normal house-plugs giving low current AC.
On some big highways you can even find charging stations that features Mennekes, CCS and ChaDeMo.
Usually the house-plug style chargers are free (they are actual house plugs with only fancy box around them advertising them as vehicle chargers).
AC Mennekes charge tend to be paying, but not much more expensive than base electricity costs.
All the tri-standard high speed chargers I've seen are paying, but again, close to electricity costs.
Most of the above are usually made available in partnership with the local utility city company.
You can charge Teslas at them but :
- due to differing standards, you can only charge them with the AC Mennekes. You can't charge them DC (they lack the CCS pins).
- they'll charge slower than on Tesla Super charger (or than if they had the DC pins).
I think I've read that Elon Musk isn't asking royalties for companies to implement the DC Tesla protocols.
So maybe eventually the tri-standard high-speed chargers can be modified to allow DC Tesla charging on their Mennekes plug.
(I've read about un-approved Tesla mode enabled on some multi-standard charger)
I'm sure there as some ChaDeMo or CSS to Tesla adapters on the market, too.
In short :
- Yes, in Europe, there are other brand of fast chargers than Tesla.
- Due to differing implementation for DC, Tesla can't user their higher super charging speed there, but they still can "normal charge" with AC.
- The charging interface is already common, except for the above exception (and except for some older cars that use older standards like Type 1).
You'd still need to find a way to persuade the victim to also enable cam access to that rogue malicious script, but yes,
that would be a typical way to abuse such modern web API, to almost-litteraly get a finger print, which can be monetized by tracking by ad provider.
A malicious chat app (like the scam clones of WhatsApp) would actually manage to have a valid reason to ask for proximity and camera.
The big pro, is that usually the selfie-cam is close to the ear speaker which in turn (for obvious reason) is close to the proximity sensors. So the ear will definitely be in-frame for the selfie cam.
The big con, is that the selfie cam isn't optimized to focus on extreme close ups. (The attacker would need to correctly time the moment the ear leaves the vicinity of the proximity sensor, with the best moment to take a sharp-enough picture of the retreating ear. e.g.: after the sensors notice ear departure, wait 500ms and take the picutre then, it's should be in the best focus range).
I wasn't arguing wether the x86 or the ARM micro architecture is the "ultimate best one ever".
The parent was just point that intel never had a good CPU for smartphone.
I'm point that it's worse: they used to have one (an ARM based one) but managed to sell it out at the wrong time.
the micro-architecture is only relevant to make the "never had a good cpu for smartphone" sentence true.
They never had a x86 one.
They actually has a good CPU for smartphone (which happens to be an ARM, but that's completely orthogonal to my point. it could have been MIPS, it could even had been a motorola-compatible, etc.) but they managed to throw it away.
---
Though I partially agree with that the "RISC is always better no matter what" mantra is a bit overrated.
(Mainly, the "cruft" often attributed to x86 doesn't really play a role on the scale of CPU currently made by Intel and AMD for workstations/servers/laptops)
On the other hand, the RISC is still relevant in some extremely small form factors (embed). And as the smartphones progressively grew out of the embed world (there are the precusors of IoT before IoT was a thing), ARM eventually ended up sticking.
Yes, Intel could have poured ressource to make a smartphone-grade lesser-atom-like embed cpu. Probably.
But as you point out, it's definitely not worth the cost.
The single main advantage selling point of x86 (running unmodified binary code) is moot in this form factor (again, 3D Studio on a 5 inch screen ?!)
What would make sense, instead of re-inventing a whole new wheel (a hypothetical smartphone-grade intel cpu) intel did the right thing and acquire a company and a core that is smartphone-ready (StrongArm. - it happens to be an ARM but that's orthogonal to the whole debate. The key point here isn't x86 vs ARM. The key point is "core designed to work in sub-notebooks and settop-box" (i.e.: relatively power hungry) vs. "core designed to work in smartphone, pda, etc." (i.e.: even less ressource consuming)
But somehow Intel threw it away at the wrong time.
That's also why we aren't seeing that many practical real-world use of ARM in servers.
Most of the existing ARM cores happens to be optimized for the ultra-low ressurce stuff such as smartphone. Not that many ARM cores happen to be good for servers (e.g.: not many do feature SATA bus).
And finally note that AMD is planning to eventually go the reverse route : acquire a 3rd party ARM core (Cortex core in Opteron A), and then progressively build a server-grade ARM CPU out of it (upcoming K12, eventually one day, when AMD has enough left-over ressource after the current focus on Zen).