except that, unlike your garden variety lead/copper/plastic pipe, here the pipes themselves are made of liquid(ish) walls: TFS mentions silicon oil.
depending on how this technology evolves, it might have very interesting ramifications for organs 3rd printing (eg.: would work for gel-in-water matrix structures).
If you pay attention to the article (yes, I know,/. , never RTFA), the mostly are interested in what is floating in the air. As in spores that at some point of time got air born (TFS mentions "flushing" as something that might launch spores in the air)
The whole idea of the article, is that specifically exposing plates to the air flow of the air dryer gives much more bacteria colonies than anything else (sample the nozzle of a turned off air dryer, leaving the plate in an currently unused toilet room, blowing air with a less powerful small fan, etc.) Their proposed explanation is that this contamination is due to the sheer amount of air that goes out of the dryer (there aren't that many microbes in the air, but when the whole atmosphere of the toilet room is cycled and blown to your plate in a few seconds, you're bound to catch a few microboes).
From that point of view :
- Dysons have always been louded for their extremely powerful air flow and insanely efficient fan motors. That doesn't help the "blowing the whole room's worth of air to your hand" problem.
- Dysons have a pool of water accumulating at the bottom, which will get blown at the exact moment when the dryer is used, helping the "getting microbe airborne" a tiny bit (would be as if someone did flush their toilet exactly in sync with a classical dryer, given TFS. Here the pool is smaller, but closer, but the effect should be tiny).
- Touching the wall isn't a problem (sampling the nozzles of turned off dryer didn't produce much. Again, it's not that dryers are dirty. It's the fact that almost any particule currently in the air will end up being blown on your hands at some point of time in the cycle of these air blowing monsters. Unless dysons have HEPA filters, there's no reason to suspect they are any different from other dryers)
- The direction where sheets of water flow isn't relevant to the perspective of this study.
Funnily though, even if TFS reports that paper towel were added to toilet rooms as a consquence of the study, at point during the study did they test the paper towel surface for microbes...
Tin foil hat ! Conspiracy theory time !! THEY WERE PAID BY THE "BIG SOFT TISSUE" !!!~~
In a certain nitpicky way, the above poster happens to be right, simply because in lots of circumstances (ex.: author competition), the difference betwen "short story" and "novel" is defined by the number of words. By this extremely strict definition, "graphic novel" is simply contradicting the definition of "novel". But on the other hand "graphic short story", in turn, is contradicting the definition of "short" anyway.
But once you throw in the common saying that "a picture is a thousand of words", then suddenly "graphic novel" reach the necessary threshold of words. (Which is what basically your good explanation about information being conveyed in the visual channel boils down to).
You can add hacker friendliness / large indy dev communities to the list.
Even at the time of Parlm Pre and webOS, although it didn't feature week-long battery life (since back the move to beefier ARMs PalmOS devices) and since it was heavily reliant on cloud instead of simple sync (since webOS) and not tightly integrated PIM apps (again since webOS), it was still a very open device that you could hack as much as you could want.
This thing will probably be the run-of-the-mill "No you're not allow to flash LineageOS on it" android smartphone crap. With only the "Palm" name slapped on it.
Self driving cars are neither run by AIs nor by Deep Learning Neural Networks.
Nvidia made a clear point that their platform was indeed pure DNN (aka "end-to-end deep learning self driving cars"). (Because it was more a demo of the application of their tensor acceleration rather than a practical implementation of driving).
But also has given rise to criticism about a technology that we can't completely understand (simply by not being based on a set of rules).
Recognizing a street sign might be so...
Yes, in most cars (except Nvidia), the final decision is rules based (as in "if there an object that's too near, hit the brakes")
The problem here, is what goes upstream. Neural nets use go way beyond recognizing signage. We have moved past using Hough-space to recognize lane in early LDAS a long time ago. Neural nets are used to make better sense out of the sensors input, like tagging all the various object in the scene seen by the cameras. (Comma.ai's blog gives a nice overview of what goes in a modern car system) It's these modern classifier that enable auto maker to start detecting new object like cyclists, etc. (e.g.: Volvo's various announcement of the improvment of their City-Safety) But it's this type of image recognition that is the weirdest to understand and might get fooled in weird ways (Volvo having problem with kangoroos crossing the road in Australia, because by jumping vertically they might seem to move forward and backward to the monoscopic camera's perspective) This makes the signals coming out the object dections/tagging of the sensors less reliable.
Thus a simple rule like the above "if there an object that's too near, hit the brakes" can become much less reliable in practice because the autonomous system will have trouble determining what's an object and were it is.
System are already reaching border condition where the standard input filtering gets in the way.
- Uber mentioned that their accident might be caused by the radar normally filtering out signals that don't move at a different speed (it tries to find incoming cars, but will miss a bike going perpendicular).
- Tesla mentioned that their car crash might be partially caused by the radar trying to filter out abnormal reflection that could be caused by metallic junk / metallic signage.
Now just try to imagine what happens when it's the neural net used to tag objects in the camera that goes miss prediciton. It will be even harder to understand *why* the rules kicked into action and the autonomous car took a specific decision.
it's targetting web. on the web, DRM is handled at another level (EME - encrypted media extensions). video codecs are orthogonal to it.
basically, content providers don't pay attention if AV1 supports DRM or not (it doesn't). What interests them is if the browser supports widevinecdm (it does if you browser can play netflix).
The plan of AOMedia was to shift the work to the GPU as soon as possible (think Vulkan/OpenCL compute shader)
And given the names on the list (several hardware manufacturers), you can bet that dedicated hardware AV1 cores are going to come next after that, much sooner speed than you would otherwise expect.
Which requires a powerful and power hungry CPU, probably complete with active cooling... Mobile devices won't be able to do it, or won't do it for long before the battery dies.
Which is *also* the case with h265, mostly due to the patent minefield and high licensing costs causing lots of hardware manufacturer to backtrack on their intentions to feature dedicated h265 cores in their latest hardware.
Which is the whole reason Daala, VP10 and the other pieces of what eventually combined into AV1 were started in the first place. Except for a few select phone (Apple's iPhone) lots of (cheaper) mobile devices haven't started getting real h265 decoding, neither.
And again, AV-1 was designed to be GPGPU friendly.
This is awesome, but it's useless until decoder hardware is prevalent.
The plan is that the initial quick deployment of it will rely on shader code, so decoding will be hardware accelerated, but GPGPU instead of dedicated hardware code.
On the other hand, you have a bunch of hardware manufacturer on the board too (dedicated hardware manufacturer like Broadcom, GPU manufacturer AMD, ARM, Intel, Nvidia) and they have been taking part in the process, guiding selection of some technology (the reason why ANS was dropped in favor of Daala_ec, as it's more hardware friendly, etc.) They have probably already started testing hardware implementation while the development process was going on. So maybe AV1 spetialized decoding cores might show up faster than expected.
Cygwin does its work at the user level. It's just another Win32 application that use the Win32 API provided by Windows NT kernel to try to do what a POSIX compliant program compiled against Cygwin wants to do. (Among other things, this causes "fork()" to be slow due to Win32 API sucking at it). (And as you mention it means that you need to recompile and relink against it).
WSL does its work at the kernel level. Just like Win32 is one of the API tha the NT Kernel provides (and just like the OS/2 API that it did happen to have a long time ago) it's another different API that it proposes and the provides a tiny subset of what a Linux kernel would provide. (Among other things, this cause "fork()" to be fast because it can rely on concepts that were recently introduced inside the NT kernel but aren't exposed to Win32 such as pico-threads). (And it makes possible to run the same ELF as under Linux. Well, as long as they only rely on those few APIs that the NT kernel exposes. Network is okay, but forget about any filesystem driver or anything more fancy).
This "runs unmodified elfs" is the main selling point for Microsoft : a shop witch is mainly Windows-on-the-desktop might be developing code for their Linux server. To test it, the dev might want to run it locally. Until now, that would have required either running a full blown virtual machine or even dual booting into Linux. Or switching to another platform like Mac OS X which is unixish enough to allow some (limited) local testing. (Which, in the perspective of devs would be a performance hit. And in the perspective of microsoft would be a giant risk of becoming a gateway drug toward the dark side of complete linux migration (or OS X))
Hence the idea of enabling more distros on WSL : so the dev can install whatever distro will be running on the server to better replicate the environment.
But in practice don't hope to use it for anything more than such testing : the functionnality offered under WSL is extremely limited. (i.e.: they haven't even successfully accomplished the first "E" of "EEE").
It is definitely NOT a replacement for an actual installation of Linux.
The situation is actually worse than with Therac-25.
Back then it was standard type of software, (a classical imperative program written in assembler, that is supposed to do a series of determined steps), where further analysis could find bugs (mostly due to bad practices that could help arise race conditions, overflows, etc.) you can clearly show that the software didn't work as planned.
Nowadays, with autonomous cars, its entirely different, mostly relying on modern-day AI with deep neural nets.
I'm exaggerating (though not necessarily that much, in the specific case of Nvidia's platform) : but basically you have on one side a bunch of sensor inputs (camera, radar, lidar, sonar) on the other side you have a bunch of controls (steering wheel, brakes, gaz pedal) and in the middle you have a giant AI black box with "here magic happens" written on it (but it could as well be hallucinating sheeps).
There's no clear software bug here. In fact the software run exactly as expected : it correctly ran the neural net. It's what the neural decided to do out of sensors data that is problematic. It's not as much a software bug as a general design oversight. With problematic black boxes whose logic is hard to model and understand in an exact logic fashion (DNN aren't a long list of logic rules like "if condition A and B are detected then apply decision C").
Of course in practice that's a big simplification (except, again, for Nvidia's platform). In practice a good design should include also hard logic that looks at some simpler safeguards (a big object in front detected by sensors should cause direct slowing down/braking not waiting to see what weird decision the neural net might come up with). So there is actual "classical imperative program" somewhere that needs fixing.
But you get the general gist of the direction things are going with AI : we're reaching the point where it's hard to understand what going under hood, because what goes under the hood is closer to "intuition" than "hard logic".
actually some companies have indeed exactly tried that, with products such as SplashTop:
some of the first Dell laptops to feature "Latitude On" where exactly that: a special custom SOC in a specially modified mini-PCIe card, that was able to run some restricted Linux (a web kiosk and a few built in apps. basically a distant ancestror of the chromebook concept), while accessing the nornal regular laptop screen and keyboard (but not much beyond that and certainly no access to any Sata mass storage).
it had a few minor advantage (mainly, instant power-on, and lower power usage of the SoC compared to the main CPU) but a lot of disadvantage (complexity and restrictions due to the switching concept) and cannot be used at the same time as the main CPU with Windows.
eventually, later version of "Latitude On" evolves into exaclty what you're suggesting: the mini-PCIe card evolved into an SSD with a Linux installation on it, and the main CPU simply dual booted into either the Linux installation on SSD or the Windows installation on SATA HDD.
can the code running on that emulated cpu achieve any of these out-of-order execution exploits against the host cpu running the emulator software?
It depends on the depth of the pipeline of the CPU.
If it long enough, the physical CPU might speculatively execute past the point where Qemu simulated the check in the emulated CPU, up to the point where Qemu simulate the payload that the attacker are wanting the emulated CPU to execute.
The thing is, for performance reason, if everybody switches to emulated CPUs (Java's /.NET's dreams), that's exactly the direction we will be heading onto : - CPU getting longer pipeline (yet again, just like old P4) to try to squeeze more performance - emulator getting more efficient at simulating the CPU.
Worse part ? On intel architecture, that's already the case sometimes : Google's project zero managed to exactly pull this situation off, by running eBPF bytecodes (bytecode used by the programmable packet filtering virtual machine) on a few select Intel hardware. (On AMD, the same only work when JITing is activated, otherwise the speculative execution doesn't reach far enough).
Trying to find extra value of the left over rubbish, a.k.a. "revaluating / recycling", has been standard practice since as long as people have been digging (or boring). Inventing ways to getting people to buy dirt is literally the norm in the field.
It's the marketing spin that's new: Usually the dirt is provided as a ultra cheap material to fill holes, mix with concrete, etc. Shaping it as the architect's supersized LEGO (as *litteral* bricks) is a new marketing ploy.
Probably for the free publicity that this novelty will generate. And maybe banking on Elon's charisma, they'll even manage to bump the price and make a quick buck compared to what the normal "landfill material" rates would have brought.
2) if you want to run some of their apps, those apps expect to run in an environment that passed the Android certification
The problem is that a lot of 3rd party apps end up calling API from the Google Services, so you end up needing Google's code even if you don't want to run Google's App.
it's not the france is banning netflix for not showing films in theaters. It's that cannes has always exclded films not released in france.
But, Netflix cannot release in theater even if they wanted, because some weird old protectionist law make it impossible to both release online and in theater at the same time.
(The law was designed in such a way so that back in the days, movie theaters would have a window of opportunity to try to profit from a movie, before the movie got unleashed on VHS tapes. Of course it was probably presented as some crap like "movie theater should be noble place used to display art, not to serve as vile commercial to advertise VHS sold in shops").
Similar restriction also (used to) exist regarding the timing of TV releases(*) in France (again to guarantee a "right to profit" to those who released before).
And modern EU-wide laws (that also exist in France) prevents Netflix from geo-locking (They cannot block streaming of some movie to French IP addresses for the sake of France's movie theater release priorities).
So yeah, it *is* France's law that a preventing Netflix to compete in Canne due to some indirect interactions that blocks Netflix from doing what they are required to do in order to compete.
---
(*) : Which wasn't very efficient at its intended "profit-securing" purpose, because these law couldn't obviously apply to nearby countries such as Switzerland and Belgium where french is also one of the spoken language and where the movie would be released sooner on over-the-air TV that could be received in France. Much to the dismay of VHS shops in France and/or TV channel in france who would have wanted to profit from advertisement sold during movie airing.
If you aren't making grades and progress towards your degree in Germany, you are bouncing down the stairs of the university.
There's a difference between :
"If you are among the 1% elite of outstanding results, you might get a change to get some help to pay for your tuition with four "zeroes" after the significand. (Or you could try the sport. If you make our team win the local skull smashing pet sport...)" (Or at least that's how the US sounds to us).
and :
"Try not to fail too many exam to the point of getting kicked out of the university(1), and as long as you keep paying your *semester* tuition which is just a tiny sum(2), smaller than you *monthly* booze budget, you can stay at the uni. If you're really low on cash, even that small sum can be helped. If you're working *at* the university (TA, admin work, etc.) tuition is nearly lifted".
Yes being a total doof will get you kicked out of Germany's (and other European countries' ) university. But there's a big difference with the privatized education they have on the other side of the atlantic pond.
--- (1): In Switzerland: Needing to repeat a year more than 3 times in a row, needing more than 2 years sabatical, taking more than 5 years to finish your *master's* thesis etc. These are not actually "ground for expulsion", only criteria that the uni administration will talk to you to see if it does really make sense for you to keep at the uni. (2): personal experience in Switzerland and Germany. And France isn't much more expensive than that.
Which combination of tablet and keyboard case that totals less than $300 is any good?
Bluetooth and USB keyboard can go all the way from crappy asian no-names that still work at ~10 EUR (see ebay, alibaba) all they way to decent quality from more reliable brands (logitech, their's at ~50 EUR) up to 100 EUR (there's definitely no point buying anything beyond that. 300 EUR keyboards are vanity items).
You can find 10 inch tablets with not so bad hardware going from 100-150EUR range with some "meh" brands (Acer) up to 150-200 EUR range with more known brands (Lenovo). Though you have to concede that at that price range, it's going to be powered by some cheap MediaTek chipset, so don't expect miracles in terms of performance nor miracles doable by LineageOS.
Still means that you can make your self a half decent installation somewhere between 120EUR and 300EUR depending on the hardware you picked up.
An iPad mini alone costs that much without a keyboard case.
I think I found where your problem comes from. *i*Pad <- it's there.
If the point of your device is to : - surf the web to get some information (Wikipedia and co) - surf the web to the school's web app quizzes etc. - watch video tutorials (online courses) - write documentations and presentation using the school's local deployment of commercial Google Docs or whatever is Microsoft's clone currently called (Office 365 Web ?)
An Apple iShiny is complete over-kill. (My 3 years old 10inch ACER tab bought for less than 150EUR can still do it today, despite being so crappy that there's no LineageOS available for it - there's no fastboot mode available at all).
That would require kernel-mode settings. But very likely you have still a user-mode-setting driver, because you're using Nvidia GPUs.
Stop using Nvidia hardware with their proprietary blob that doesn't play nicely with the rest of the usual Linux stack. (In a gross over simplification, Nvidia basically recompile their Windows driver for Linux. So if they need something that work differently, or if Linux some things being done differently, well too bad for you. Too bad for you if you have a laptop that goes into suspend or want to switch to a text console virtual terminal)
However that does not necessarily exclude the possibility of some other type of unknown mechanism, no matter how slight that possibility might be.
Such a not yet known mechanism could be :
- at microwavelenght, most of the absorbed energy is converted to heat (see micro-oven as an example where this phenomenon has been put to good use - though using a frequency band of 2.4Ghz. That one *also* lies whithin the range at which water will absorb micro-waves into heat. But that one is less heavily regulated than 1.8Ghz). - the varying train of pulses and jumps at 1.8Ghz, could cause small varying trains of heat pulse in the water medium of the body. - such train of heat pulse could cause very tiny shock wave. - these thermal shock waves could cause tiny bit of (non-lethal, non critical) damage. - the metabolism must keep repairing these tiny insignificant damages. - over a lifetime of such constant higher-level of repair, the additional chronic metabolic stress could eventually cause some serious damage, leading to degerative disease (see repetitive-micro-trauma induced parkinson) or slightly higher cancer rates (either due to oxydative stress of the inflamatory cells cleaning up the small damage, or the increase cell division rate to replenish afterward).
DISCLAIMER: don't take my post as an authority, but as random speculation of potential explaining hypothesis
A. I drive quite a lot when on vacations/week-end, including often on nights, including sometime in fog. - The human supervisor *should* have turned on the high beams. It seems to me that only the low beams were active, reducing the visibility range. (This might have affected the camera part of the sensors). The super visor is supposed to supervise the self-driving car and thus should be able to see in order to anticipate and compensate bugs, instead of relying the whole thing to work. - The human supervisor *should* have instructed the car to drive at a speed within the supervisor's visible range (with the low beam only, the visibility is extremely short, the speed should have been kept low). - The human supervisor *should* have kept eyes on the road (Uber is testing a new technology, bugs are bound to happen.
Definitely the supervisor was doing a couple of things wrong. But even if all the above were followed, that probably wouldn't have saved the bike rider.
B. I bike to work almost every single working day (welcome to europe), I'm used to bike at night, etc. - She was wearing dark clothes. It's not a problem per se but you have to keep in mind you're a bit less visible. (Some people here around even where reflective jackets when biking). - She didn't have any reflector on the bike. That makes the bikes drastically less visible. Usually most bike riders have a good quantity of retroflective reflectors on the bike (plastic on the wheel spokes, sticky bands on the bike body), etc. - She had absolutely no light. That's a very high danger of collision. Enough for cops here around to pull you if they catch you with an unlit bike. Nearly every one will use a good battery-powered headlight/taillight, often a blinking tail light (legally dubious but every one use them for visibility and police tolerate them). Some bike rider look for "always on" solution to be better visible (magnetic induction tiny lights that are at least visible, even if not very good at lighting. Or on-axis dynamo that powers good lights). Some almost turn their bikes into christmas-tree like light shows just for lulz. - No helmet (could help diminish the results of an impact, also most of them have reflectors, and some even feature built-in lights). - She should have seen the headlights from far away. If she counted on the car slowing down, standard practice (massively advertised at the beginning of each school year here around) require to establish eye contact (to make sure that the driver has seen you and will slown down) which is impossible to do by night. - In the absence of eye contact, she should have waited for obvious signs that the driver will slow down (e.g.: the driver already starting to slow down and blinking the high beams to ack). - Other wise she should have assumed to not having been seen (specially given the clothes she's wearing).
With my experience with bike I would never attempt to cross the way she did given all the above. That looks absolutely suicidal to me, there's now sane way to expect even a well behaving driver to have avoided the collision.
There must be some reason for her absolutely not paying attention : - being way too much absorbed into some phone conversation over earphones ? - emotionally distressed and not able to focus and pay attention ? - drunk ? (which here around could be a reason for the police to take away your *other* licenses : car driver, boat, etc.)
Jokes about stealthy bike aside, she *is* indeed very stealthy.
- Her jacket is very dark, it might be also dark in the IR spectrum and be as invisible on the LIDAR as on the camera. - She not only doesn't have any light turned on on her bike, she doesn't even have any reflector on her bike nor on her clothing (here around where I live that would be considered suicidal)
On the other hand, the radar should have picked-up her (unless the bike wheel's spokes are scattering the radio wave in a weird way), but maybe the radar saw her too much to the left side, i.e.: "in a different lane and thus not on a collision course". The radar analysis part of the system should be upgraded to take into acount object moving perpenducaly to the vehicle. (i.e.: Yes, if she stayed where she was, she would have been in a different lane. But she was moving side ways to the right. If the radar was able to pick her up, the computer should be able to calculate speed/trajectory and determine she'll be in the car's lane by the time the car reaches her).
It could have seen the person and taken its course of action anyway, {...} It could have decided that swerving out the way was more dangerous, for instance.
Unless Uber have been implementing their driving system in a completely weird way (e.g.: the whole thing is just a giant deep neural net black box, with sensors on one side and controls directly driven by the output of the NN on the other side, like the Nvidia demo platform - which is just a techdemo, not a real-world use case), there are low-level system in drive assistance systems. Even on current "Level 1" system currently on the street for quite some time, it the FCAS detects an obstacle in front of the car, the FCAS will hit the brakes and try to decelerate as much as possible (either stopping before hitting the object if distance permits, or in the current case if the obstacle jumps into view at the last moment, trying to shed as much kinetic energy before the impact as possible to reduce damage and potentially make the collision non-fatal). Even if the higher level path-finding doesn't react (and frankly what should it do ? swerving is rarely a good idea as it increases risk of skiding), the low-level system should hit the brake.
Here they didn't, meaning that they didn't register the bike to begin with. Somehow, not only the victim wasn't seen by the camera (obvious from the video : she was in dark until the last few seconds. Neither a human nor a camera would have noticed them in time), but it wasn't seen by either the lidar nor the radar. Either she was invisible to the sensors (e.g.: the dark jacket aborbing the IR light used by the lidar, the spokes of the bike's wheels shattering the radar wave in a weird way, etc.) or the sensors didn't register her (e.g.: the radar detects her as an object, but to the side (not in the same lane) and thus not a collision danger at that time. My experience with ACC is that sometime the radar has problem undestanding which object are in the same lane or not (problems fusing radar detections with the camera's lane detection and/or with the drivers wheel's heading) sometime missing (false negative) objects which are a bit on the side, or sometime getting confused (false positive) when the lane is curving a lot and the radar picks something in front of the car).
Slashdot Mirror
That package might be called "wine" or "VirtualBox" in yoir distro~~
except that, unlike your garden variety lead/copper/plastic pipe, here the pipes themselves are made of liquid(ish) walls: TFS mentions silicon oil.
depending on how this technology evolves, it might have very interesting ramifications for organs 3rd printing (eg.: would work for gel-in-water matrix structures).
If you pay attention to the article (yes, I know, /. , never RTFA), the mostly are interested in what is floating in the air.
As in spores that at some point of time got air born (TFS mentions "flushing" as something that might launch spores in the air)
The whole idea of the article, is that specifically exposing plates to the air flow of the air dryer gives much more bacteria colonies than anything else (sample the nozzle of a turned off air dryer, leaving the plate in an currently unused toilet room, blowing air with a less powerful small fan, etc.)
Their proposed explanation is that this contamination is due to the sheer amount of air that goes out of the dryer (there aren't that many microbes in the air, but when the whole atmosphere of the toilet room is cycled and blown to your plate in a few seconds, you're bound to catch a few microboes).
From that point of view :
- Dysons have always been louded for their extremely powerful air flow and insanely efficient fan motors. That doesn't help the "blowing the whole room's worth of air to your hand" problem.
- Dysons have a pool of water accumulating at the bottom, which will get blown at the exact moment when the dryer is used, helping the "getting microbe airborne" a tiny bit (would be as if someone did flush their toilet exactly in sync with a classical dryer, given TFS. Here the pool is smaller, but closer, but the effect should be tiny).
- Touching the wall isn't a problem (sampling the nozzles of turned off dryer didn't produce much. Again, it's not that dryers are dirty. It's the fact that almost any particule currently in the air will end up being blown on your hands at some point of time in the cycle of these air blowing monsters. Unless dysons have HEPA filters, there's no reason to suspect they are any different from other dryers)
- The direction where sheets of water flow isn't relevant to the perspective of this study.
Funnily though, even if TFS reports that paper towel were added to toilet rooms as a consquence of the study, at point during the study did they test the paper towel surface for microbes...
Tin foil hat ! Conspiracy theory time !! THEY WERE PAID BY THE "BIG SOFT TISSUE" !!!~~
In a certain nitpicky way, the above poster happens to be right, simply because in lots of circumstances (ex.: author competition), the difference betwen "short story" and "novel" is defined by the number of words.
By this extremely strict definition, "graphic novel" is simply contradicting the definition of "novel". But on the other hand "graphic short story", in turn, is contradicting the definition of "short" anyway.
But once you throw in the common saying that "a picture is a thousand of words", then suddenly "graphic novel" reach the necessary threshold of words.
(Which is what basically your good explanation about information being conveyed in the visual channel boils down to).
You can add hacker friendliness / large indy dev communities to the list.
Even at the time of Parlm Pre and webOS, although it didn't feature week-long battery life (since back the move to beefier ARMs PalmOS devices)
and since it was heavily reliant on cloud instead of simple sync (since webOS) and not tightly integrated PIM apps (again since webOS),
it was still a very open device that you could hack as much as you could want.
This thing will probably be the run-of-the-mill "No you're not allow to flash LineageOS on it" android smartphone crap.
With only the "Palm" name slapped on it.
Self driving cars are neither run by AIs nor by Deep Learning Neural Networks.
Nvidia made a clear point that their platform was indeed pure DNN (aka "end-to-end deep learning self driving cars").
(Because it was more a demo of the application of their tensor acceleration rather than a practical implementation of driving).
But also has given rise to criticism about a technology that we can't completely understand (simply by not being based on a set of rules).
Recognizing a street sign might be so ...
Yes, in most cars (except Nvidia), the final decision is rules based (as in "if there an object that's too near, hit the brakes")
The problem here, is what goes upstream.
Neural nets use go way beyond recognizing signage.
We have moved past using Hough-space to recognize lane in early LDAS a long time ago. Neural nets are used to make better sense out of the sensors input, like tagging all the various object in the scene seen by the cameras.
(Comma.ai's blog gives a nice overview of what goes in a modern car system)
It's these modern classifier that enable auto maker to start detecting new object like cyclists, etc.
(e.g.: Volvo's various announcement of the improvment of their City-Safety)
But it's this type of image recognition that is the weirdest to understand and might get fooled in weird ways (Volvo having problem with kangoroos crossing the road in Australia, because by jumping vertically they might seem to move forward and backward to the monoscopic camera's perspective)
This makes the signals coming out the object dections/tagging of the sensors less reliable.
Thus a simple rule like the above "if there an object that's too near, hit the brakes" can become much less reliable in practice because the autonomous system will have trouble determining what's an object and were it is.
System are already reaching border condition where the standard input filtering gets in the way.
- Uber mentioned that their accident might be caused by the radar normally filtering out signals that don't move at a different speed (it tries to find incoming cars, but will miss a bike going perpendicular).
- Tesla mentioned that their car crash might be partially caused by the radar trying to filter out abnormal reflection that could be caused by metallic junk / metallic signage.
Now just try to imagine what happens when it's the neural net used to tag objects in the camera that goes miss prediciton.
It will be even harder to understand *why* the rules kicked into action and the autonomous car took a specific decision.
it's targetting web.
on the web, DRM is handled at another level (EME - encrypted media extensions).
video codecs are orthogonal to it.
basically, content providers don't pay attention if AV1 supports DRM or not (it doesn't).
What interests them is if the browser supports widevinecdm (it does if you browser can play netflix).
The plan of AOMedia was to shift the work to the GPU as soon as possible (think Vulkan/OpenCL compute shader)
And given the names on the list (several hardware manufacturers), you can bet that dedicated hardware AV1 cores are going to come next after that, much sooner speed than you would otherwise expect.
VLC has also preliminary AV1 support (since 3.0).
G-Streamer has too (since 1.14)
Bitmovin has started offering experimental AV1 cloud compression for quite some time.
And given the long list of companies involved, more is going to come any moment soon.
Which requires a powerful and power hungry CPU, probably complete with active cooling...
Mobile devices won't be able to do it, or won't do it for long before the battery dies.
Which is *also* the case with h265, mostly due to the patent minefield and high licensing costs causing lots of hardware manufacturer to backtrack on their intentions to feature dedicated h265 cores in their latest hardware.
Which is the whole reason Daala, VP10 and the other pieces of what eventually combined into AV1 were started in the first place.
Except for a few select phone (Apple's iPhone) lots of (cheaper) mobile devices haven't started getting real h265 decoding, neither.
And again, AV-1 was designed to be GPGPU friendly.
This is awesome, but it's useless until decoder hardware is prevalent.
The plan is that the initial quick deployment of it will rely on shader code, so decoding will be hardware accelerated, but GPGPU instead of dedicated hardware code.
On the other hand, you have a bunch of hardware manufacturer on the board too (dedicated hardware manufacturer like Broadcom, GPU manufacturer AMD, ARM, Intel, Nvidia) and they have been taking part in the process, guiding selection of some technology (the reason why ANS was dropped in favor of Daala_ec, as it's more hardware friendly, etc.)
They have probably already started testing hardware implementation while the development process was going on. So maybe AV1 spetialized decoding cores might show up faster than expected.
Cygwin does its work at the user level. It's just another Win32 application that use the Win32 API provided by Windows NT kernel to try to do what a POSIX compliant program compiled against Cygwin wants to do.
(Among other things, this causes "fork()" to be slow due to Win32 API sucking at it).
(And as you mention it means that you need to recompile and relink against it).
WSL does its work at the kernel level. Just like Win32 is one of the API tha the NT Kernel provides (and just like the OS/2 API that it did happen to have a long time ago) it's another different API that it proposes and the provides a tiny subset of what a Linux kernel would provide.
(Among other things, this cause "fork()" to be fast because it can rely on concepts that were recently introduced inside the NT kernel but aren't exposed to Win32 such as pico-threads).
(And it makes possible to run the same ELF as under Linux. Well, as long as they only rely on those few APIs that the NT kernel exposes. Network is okay, but forget about any filesystem driver or anything more fancy).
This "runs unmodified elfs" is the main selling point for Microsoft :
a shop witch is mainly Windows-on-the-desktop might be developing code for their Linux server. To test it, the dev might want to run it locally.
Until now, that would have required either running a full blown virtual machine or even dual booting into Linux.
Or switching to another platform like Mac OS X which is unixish enough to allow some (limited) local testing.
(Which, in the perspective of devs would be a performance hit.
And in the perspective of microsoft would be a giant risk of becoming a gateway drug toward the dark side of complete linux migration (or OS X))
Hence the idea of enabling more distros on WSL : so the dev can install whatever distro will be running on the server to better replicate the environment.
But in practice don't hope to use it for anything more than such testing : the functionnality offered under WSL is extremely limited.
(i.e.: they haven't even successfully accomplished the first "E" of "EEE").
It is definitely NOT a replacement for an actual installation of Linux.
The situation is actually worse than with Therac-25.
Back then it was standard type of software, (a classical imperative program written in assembler, that is supposed to do a series of determined steps), where further analysis could find bugs (mostly due to bad practices that could help arise race conditions, overflows, etc.) you can clearly show that the software didn't work as planned.
Nowadays, with autonomous cars, its entirely different, mostly relying on modern-day AI with deep neural nets.
I'm exaggerating (though not necessarily that much, in the specific case of Nvidia's platform) :
but basically you have on one side a bunch of sensor inputs (camera, radar, lidar, sonar)
on the other side you have a bunch of controls (steering wheel, brakes, gaz pedal)
and in the middle you have a giant AI black box with "here magic happens" written on it (but it could as well be hallucinating sheeps).
There's no clear software bug here. In fact the software run exactly as expected : it correctly ran the neural net.
It's what the neural decided to do out of sensors data that is problematic.
It's not as much a software bug as a general design oversight.
With problematic black boxes whose logic is hard to model and understand in an exact logic fashion (DNN aren't a long list of logic rules like "if condition A and B are detected then apply decision C").
Of course in practice that's a big simplification (except, again, for Nvidia's platform). In practice a good design should include also hard logic that looks at some simpler safeguards (a big object in front detected by sensors should cause direct slowing down/braking not waiting to see what weird decision the neural net might come up with). So there is actual "classical imperative program" somewhere that needs fixing.
But you get the general gist of the direction things are going with AI : we're reaching the point where it's hard to understand what going under hood, because what goes under the hood is closer to "intuition" than "hard logic".
actually some companies have indeed exactly tried that, with products such as SplashTop:
some of the first Dell laptops to feature "Latitude On" where exactly that: a special custom SOC in a specially modified mini-PCIe card, that was able to run some restricted Linux (a web kiosk and a few built in apps. basically a distant ancestror of the chromebook concept), while accessing the nornal regular laptop screen and keyboard (but not much beyond that and certainly no access to any Sata mass storage).
it had a few minor advantage (mainly, instant power-on, and lower power usage of the SoC compared to the main CPU)
but a lot of disadvantage (complexity and restrictions due to the switching concept)
and cannot be used at the same time as the main CPU with Windows.
eventually, later version of "Latitude On" evolves into exaclty what you're suggesting: the mini-PCIe card evolved into an SSD with a Linux installation on it, and the main CPU simply dual booted into either the Linux installation on SSD or the Windows installation on SATA HDD.
can the code running on that emulated cpu achieve any of these out-of-order execution exploits against the host cpu running the emulator software?
It depends on the depth of the pipeline of the CPU.
If it long enough, the physical CPU might speculatively execute past the point where Qemu simulated the check in the emulated CPU, up to the point where Qemu simulate the payload that the attacker are wanting the emulated CPU to execute.
The thing is, for performance reason, if everybody switches to emulated CPUs (Java's / .NET's dreams), that's exactly the direction we will be heading onto :
- CPU getting longer pipeline (yet again, just like old P4) to try to squeeze more performance
- emulator getting more efficient at simulating the CPU.
Worse part ?
On intel architecture, that's already the case sometimes : Google's project zero managed to exactly pull this situation off, by running eBPF bytecodes (bytecode used by the programmable packet filtering virtual machine) on a few select Intel hardware.
(On AMD, the same only work when JITing is activated, otherwise the speculative execution doesn't reach far enough).
Trying to find extra value of the left over rubbish, a.k.a. "revaluating / recycling", has been standard practice since as long as people have been digging (or boring).
Inventing ways to getting people to buy dirt is literally the norm in the field.
It's the marketing spin that's new:
Usually the dirt is provided as a ultra cheap material to fill holes, mix with concrete, etc.
Shaping it as the architect's supersized LEGO (as *litteral* bricks) is a new marketing ploy.
Probably for the free publicity that this novelty will generate.
And maybe banking on Elon's charisma, they'll even manage to bump the price and make a quick buck compared to what the normal "landfill material" rates would have brought.
2) if you want to run some of their apps, those apps expect to run in an environment that passed the Android certification
The problem is that a lot of 3rd party apps end up calling API from the Google Services,
so you end up needing Google's code even if you don't want to run Google's App.
(i.e.: I don't want to run Youtube or Gmail apps, but an app I rely on needs the map displaying library from Google Services).
it's not the france is banning netflix for not showing films in theaters. It's that cannes has always exclded films not released in france.
But, Netflix cannot release in theater even if they wanted, because some weird old protectionist law make it impossible to both release online and in theater at the same time.
(The law was designed in such a way so that back in the days, movie theaters would have a window of opportunity to try to profit from a movie, before the movie got unleashed on VHS tapes. Of course it was probably presented as some crap like "movie theater should be noble place used to display art, not to serve as vile commercial to advertise VHS sold in shops").
Similar restriction also (used to) exist regarding the timing of TV releases(*) in France (again to guarantee a "right to profit" to those who released before).
And modern EU-wide laws (that also exist in France) prevents Netflix from geo-locking (They cannot block streaming of some movie to French IP addresses for the sake of France's movie theater release priorities).
So yeah, it *is* France's law that a preventing Netflix to compete in Canne due to some indirect interactions that blocks Netflix from doing what they are required to do in order to compete.
---
(*) : Which wasn't very efficient at its intended "profit-securing" purpose, because these law couldn't obviously apply to nearby countries such as Switzerland and Belgium where french is also one of the spoken language and where the movie would be released sooner on over-the-air TV that could be received in France. Much to the dismay of VHS shops in France and/or TV channel in france who would have wanted to profit from advertisement sold during movie airing.
If you aren't making grades and progress towards your degree in Germany, you are bouncing down the stairs of the university.
There's a difference between :
"If you are among the 1% elite of outstanding results, you might get a change to get some help to pay for your tuition with four "zeroes" after the significand.
(Or you could try the sport. If you make our team win the local skull smashing pet sport...)"
(Or at least that's how the US sounds to us).
and :
"Try not to fail too many exam to the point of getting kicked out of the university(1), and as long as you keep paying your *semester* tuition which is just a tiny sum(2), smaller than you *monthly* booze budget, you can stay at the uni.
If you're really low on cash, even that small sum can be helped.
If you're working *at* the university (TA, admin work, etc.) tuition is nearly lifted".
Yes being a total doof will get you kicked out of Germany's (and other European countries' ) university.
But there's a big difference with the privatized education they have on the other side of the atlantic pond.
---
(1): In Switzerland: Needing to repeat a year more than 3 times in a row, needing more than 2 years sabatical, taking more than 5 years to finish your *master's* thesis etc.
These are not actually "ground for expulsion", only criteria that the uni administration will talk to you to see if it does really make sense for you to keep at the uni.
(2): personal experience in Switzerland and Germany. And France isn't much more expensive than that.
Which combination of tablet and keyboard case that totals less than $300 is any good?
Bluetooth and USB keyboard can go all the way from crappy asian no-names that still work at ~10 EUR (see ebay, alibaba) all they way to decent quality from more reliable brands (logitech, their's at ~50 EUR) up to 100 EUR (there's definitely no point buying anything beyond that. 300 EUR keyboards are vanity items).
You can find 10 inch tablets with not so bad hardware going from 100-150EUR range with some "meh" brands (Acer) up to 150-200 EUR range with more known brands (Lenovo). Though you have to concede that at that price range, it's going to be powered by some cheap MediaTek chipset, so don't expect miracles in terms of performance nor miracles doable by LineageOS.
Still means that you can make your self a half decent installation somewhere between 120EUR and 300EUR depending on the hardware you picked up.
An iPad mini alone costs that much without a keyboard case.
I think I found where your problem comes from.
*i*Pad <- it's there.
If the point of your device is to :
- surf the web to get some information (Wikipedia and co)
- surf the web to the school's web app quizzes etc.
- watch video tutorials (online courses)
- write documentations and presentation using the school's local deployment of commercial Google Docs or whatever is Microsoft's clone currently called (Office 365 Web ?)
An Apple iShiny is complete over-kill.
(My 3 years old 10inch ACER tab bought for less than 150EUR can still do it today, despite being so crappy that there's no LineageOS available for it - there's no fastboot mode available at all).
Leave my text alone!
That would require kernel-mode settings.
But very likely you have still a user-mode-setting driver, because you're using Nvidia GPUs.
Stop using Nvidia hardware with their proprietary blob that doesn't play nicely with the rest of the usual Linux stack.
(In a gross over simplification, Nvidia basically recompile their Windows driver for Linux. So if they need something that work differently, or if Linux some things being done differently, well too bad for you. Too bad for you if you have a laptop that goes into suspend or want to switch to a text console virtual terminal)
However that does not necessarily exclude the possibility of some other type of unknown mechanism, no matter how slight that possibility might be.
Such a not yet known mechanism could be :
- at microwavelenght, most of the absorbed energy is converted to heat (see micro-oven as an example where this phenomenon has been put to good use - though using a frequency band of 2.4Ghz. That one *also* lies whithin the range at which water will absorb micro-waves into heat. But that one is less heavily regulated than 1.8Ghz).
- the varying train of pulses and jumps at 1.8Ghz, could cause small varying trains of heat pulse in the water medium of the body.
- such train of heat pulse could cause very tiny shock wave.
- these thermal shock waves could cause tiny bit of (non-lethal, non critical) damage.
- the metabolism must keep repairing these tiny insignificant damages.
- over a lifetime of such constant higher-level of repair, the additional chronic metabolic stress could eventually cause some serious damage, leading to degerative disease (see repetitive-micro-trauma induced parkinson) or slightly higher cancer rates (either due to oxydative stress of the inflamatory cells cleaning up the small damage, or the increase cell division rate to replenish afterward).
DISCLAIMER: don't take my post as an authority, but as random speculation of potential explaining hypothesis
Speaking from experience :
A.
I drive quite a lot when on vacations/week-end, including often on nights, including sometime in fog.
- The human supervisor *should* have turned on the high beams. It seems to me that only the low beams were active, reducing the visibility range. (This might have affected the camera part of the sensors). The super visor is supposed to supervise the self-driving car and thus should be able to see in order to anticipate and compensate bugs, instead of relying the whole thing to work.
- The human supervisor *should* have instructed the car to drive at a speed within the supervisor's visible range (with the low beam only, the visibility is extremely short, the speed should have been kept low).
- The human supervisor *should* have kept eyes on the road (Uber is testing a new technology, bugs are bound to happen.
Definitely the supervisor was doing a couple of things wrong. But even if all the above were followed, that probably wouldn't have saved the bike rider.
B.
I bike to work almost every single working day (welcome to europe), I'm used to bike at night, etc.
- She was wearing dark clothes. It's not a problem per se but you have to keep in mind you're a bit less visible. (Some people here around even where reflective jackets when biking).
- She didn't have any reflector on the bike. That makes the bikes drastically less visible. Usually most bike riders have a good quantity of retroflective reflectors on the bike (plastic on the wheel spokes, sticky bands on the bike body), etc.
- She had absolutely no light. That's a very high danger of collision. Enough for cops here around to pull you if they catch you with an unlit bike. Nearly every one will use a good battery-powered headlight/taillight, often a blinking tail light (legally dubious but every one use them for visibility and police tolerate them). Some bike rider look for "always on" solution to be better visible (magnetic induction tiny lights that are at least visible, even if not very good at lighting. Or on-axis dynamo that powers good lights). Some almost turn their bikes into christmas-tree like light shows just for lulz.
- No helmet (could help diminish the results of an impact, also most of them have reflectors, and some even feature built-in lights).
- She should have seen the headlights from far away. If she counted on the car slowing down, standard practice (massively advertised at the beginning of each school year here around) require to establish eye contact (to make sure that the driver has seen you and will slown down) which is impossible to do by night.
- In the absence of eye contact, she should have waited for obvious signs that the driver will slow down (e.g.: the driver already starting to slow down and blinking the high beams to ack).
- Other wise she should have assumed to not having been seen (specially given the clothes she's wearing).
With my experience with bike I would never attempt to cross the way she did given all the above. That looks absolutely suicidal to me, there's now sane way to expect even a well behaving driver to have avoided the collision.
There must be some reason for her absolutely not paying attention : - being way too much absorbed into some phone conversation over earphones ? - emotionally distressed and not able to focus and pay attention ? - drunk ? (which here around could be a reason for the police to take away your *other* licenses : car driver, boat, etc.)
Jokes about stealthy bike aside, she *is* indeed very stealthy.
- Her jacket is very dark, it might be also dark in the IR spectrum and be as invisible on the LIDAR as on the camera.
- She not only doesn't have any light turned on on her bike, she doesn't even have any reflector on her bike nor on her clothing (here around where I live that would be considered suicidal)
On the other hand, the radar should have picked-up her (unless the bike wheel's spokes are scattering the radio wave in a weird way), but maybe the radar saw her too much to the left side, i.e.: "in a different lane and thus not on a collision course". The radar analysis part of the system should be upgraded to take into acount object moving perpenducaly to the vehicle.
(i.e.: Yes, if she stayed where she was, she would have been in a different lane. But she was moving side ways to the right. If the radar was able to pick her up, the computer should be able to calculate speed/trajectory and determine she'll be in the car's lane by the time the car reaches her).
It could have seen the person and taken its course of action anyway, {...} It could have decided that swerving out the way was more dangerous, for instance.
Unless Uber have been implementing their driving system in a completely weird way (e.g.: the whole thing is just a giant deep neural net black box, with sensors on one side and controls directly driven by the output of the NN on the other side, like the Nvidia demo platform - which is just a techdemo, not a real-world use case), there are low-level system in drive assistance systems.
Even on current "Level 1" system currently on the street for quite some time, it the FCAS detects an obstacle in front of the car, the FCAS will hit the brakes and try to decelerate as much as possible (either stopping before hitting the object if distance permits, or in the current case if the obstacle jumps into view at the last moment, trying to shed as much kinetic energy before the impact as possible to reduce damage and potentially make the collision non-fatal).
Even if the higher level path-finding doesn't react (and frankly what should it do ? swerving is rarely a good idea as it increases risk of skiding), the low-level system should hit the brake.
Here they didn't, meaning that they didn't register the bike to begin with.
Somehow, not only the victim wasn't seen by the camera (obvious from the video : she was in dark until the last few seconds. Neither a human nor a camera would have noticed them in time), but it wasn't seen by either the lidar nor the radar.
Either she was invisible to the sensors (e.g.: the dark jacket aborbing the IR light used by the lidar, the spokes of the bike's wheels shattering the radar wave in a weird way, etc.)
or the sensors didn't register her (e.g.: the radar detects her as an object, but to the side (not in the same lane) and thus not a collision danger at that time. My experience with ACC is that sometime the radar has problem undestanding which object are in the same lane or not (problems fusing radar detections with the camera's lane detection and/or with the drivers wheel's heading) sometime missing (false negative) objects which are a bit on the side, or sometime getting confused (false positive) when the lane is curving a lot and the radar picks something in front of the car).