If you RTFA : yes, and actually they managed quite a few feat to make it both legal and easier on them.
e.g.: - the launch site is privately owned (no competition to use it by other branches government) - the launch site is quite remote (no need to wait and coordinate with air traffic) etc.
basically they managed to be legit, and they did in creative manner that actually enable them to operate better.
The story about it I read last week said that he did test it on another book and showed it to her to convince her it was safe.
Which overall speaks for the necessity of being very rigorous during testing.
Yes, paper armor is a thing. (And was a thing in historic China). Swords blows, and even some (not to high velocity) bullets can be stopped, while the overall armor is extremely light. (The explanation : the friction with each individual layer of paper slow the weapon a bit. After dozens and dozens of layer, a sword will get stopped. Some bullets might to. I think there might be a Mythbuster episode about this ?)
BUT it's extremely dependant on the exact parameters.
If he did the test with a massive book (some thick dictionary) and some not too powerful pea-shooter (sorry, we're not gun nuts enough on my side of the atlantic pond to have any vague idea what exact type of gun and bullets could get stopped) yeah sure, it might have worked.
If on the D day they decided to use a book with different characteristics (number of page, paper weight, types of cover, etc.) than during the test and if they switched to a different weapon (TFS mentions a Desert Eagle and I think I might remember that these have some power. Again, not gun nut enough to know) that will be enough for the bullet to simply flight through the book almost unencumbered.
Proper procedure would have been : - run tests with the exact same setup (distance, type of book, type of bullet, type of gun) than the final take - run SEVERAL tests to confirm that it is reliably reproducible. (- while you're at it : run the tests with the camera. help you find the correct setup, and gives footage for a decent "making of") - on the D day, try as much as possible to wear protection (ballistic plate dicretely hidden under the shirt, in case the trick fails ?) - also best if you have emergency responders ready to intervene if anything goes wrong.
(But that's the difference between a real stunt and a youtube trick by teenagers).
If human spoken language was as rigid and rule abiding as programming language, we will probably be still communicating by "Ug !"s and "Arg!"s. And hitting with club the head of anyone not following the same caveman conventions as anyone else.
Language evolve. New words and rules are constantly created, as people continue to speak. Some variation become widespread and eventually aren't considered as errors anymore as poeple get used to them and start using them too. And that's how you end-up speaking english, which doesn't look much like old-english, which in turn has evolved further from Germanic root, etc.
In fact even programming language aren't that much solid. Language evolve as new idea enters the standards (see the evolution of K&R C, ANSI C (C89/C90 and C95), C99, C11...) Even the different languages themselves are a sign of evolution, after all we aren't all still programming in Assembler, but we have moved to tons of languages like Fortran, C/C++, LISP, Perl, Python, Javascript, Rust,...
The only main difference being, as computer arent as good (yet) as humans to infer from context, one need presicion in programming as you mention, and language tend to have clear rules and systems of standards and extensions. (Okay, and then there is Perl).
I have NEVER seen a cheap piece of plastic last for more than a couple years out baking in the sunshine. It disintegrates on it's own. {...} but it all reverts back to good ole mother earth.
Yes, under the sun (and lots of other environmental factors, including mechanical action) a bottle will disintegrates. But THIS IS NOTreverting back to good old mother earth. It is just breaking a big plastic object into finer plastic dust.
Which brings its own bunch of problems: - this plastic dust disperse wide - this plastic dust has a higher risk of getting ingested by marine animal - this plastic dust also collects organic compounds more easily - once ingested by marine animal, due to higher amount of organic compound stuck on the plastic dust, these animal accumulate more pollution.
(There a movie called "A plastic ocean" currently touring festivals that explains this better).
And thus, TFS:
Should you ever travel to one of the many uninhibited islands that dot the most remote reaches of Earth's oceans, chances are you'll find plastic bottles littering the shore.
That's actually a myth. You're nearly NEVER going to find whole intact plastic bottles in remote places because the above phenomenon.
The reality is actually much grimmer : - with the naked eye you're not going to see much (again, artificial islands of collect plastic junks are a myth). - but if you make lab analysis of the environment, you'll see that :
-- most local marine animals have ingested an alarming amount of plastic dust in their bodies
-- and they'll have probably concentrated some polluant at higher dose.
Otherwise the Tennessee River which I grew up on would be totally lined with styrofoam.
It is a *river*. It wont never stay lined with anything for a long time : eventually everything will get carried away by the current and broken down in smaller particles (also some substance like steel *will* degrade (to rust, etc.) while other like glass and plastic are too chemically stable. At least glass will break-down into sand (basically : glass dust)).
Once carried away by the current they will eventually find their way into the seas, then into the ocean, when they'll finally get caught into some current that will keep them in some cycle forever.
Heck, there are some woods, cedar for example, that will last longer than a plastic bottle exposed to the elements.
Actually wood isn't such a bad exemple.
But not for the reasons you think. (No: it won't last longer than plastic bottle. It will *keep its shape* for a longer time than plastic [that's why life invented it in plants : because it's structurally sturdy]. But eventually, decomposers [bacteria, funghi, etc.] will manage to digest it. It will actually end up back into CO2) But some eons ago that wasn't the case. It took some time between life inventing wood (somewhere in the Devonian), and bacteria coming up with a way to degrade it. Of course all this juicy stored chemical energy was going to end-up being used as a food source for some microbes.
The same situation is happening again. We human produce tons of a nearly indestructible component (plastic) but that is still rich in stored chemical energy (the fact that you can actually burn it into CO2 is a sign). Eventually all this untapped chemical energy is going to attract some bacteria, and in the recent couple of year, scientist have discovered some types of bacteria who have evolved a way to digest and process plastics. Maybe in a couple of centuries (and maybe with a little bit of help by researchers) Nature will find a way to clean it self of this plastic pollution, by inventing a way to harness its stored chemical energy.
Your point on battery endurance is a bit ridiculous, use your iPhone like you would a dumb phone and its battery will last a lot longer.
I came from the other point of view. There was no way I could use an iPhone the way I've been (ab)using my Palm PDAs before.
I bought a Palm IIIc around 2000 and used it a my daily driver during a good part of my studies. I took all my notes during lectures on it. Typing on the foldable keyboard, or scribling with the stylus when on the move. Even under strong use, if I forgot to charge it during the night, it could still be holding the next day to the end.
The thing is, it was an *PDA*. It didn't have it's own connection, it relied on IrDA tethering if I wanted to check e-mail (with later PDAs like my Palm Tungsten T3 I could use bluetooth tethering or a Wifi SDIO card, though that last one similarily reduced battery life). So the pocket computer wasn't constantly connected. (Meanwhile, the phone I was using the most was a sturdy dumb phone, Ericsson T39 - good battery life, specially when using a fat replacement battery) Each device with its own adapted battery.
On the other hand, the smartphone trend started to pack all the above functionality in a single device, sharing a single meager battery. And with the race to make the device as thin as possible, the space constrain aren't getting any better.
So of course the first iPhone was going to have a not so great battery performance (doing all the work of a PDA and a feature phone, on a single battery). The non-replaceable battery didn't help.
In the context of your comment, marketing actually means; Making something usable, as opposed to being terrible.
No, I really meant "Try to bring it to market XYZ".
Every prior incarnation of touch-screen phones were uniformly unusably bad.
Microsoft's shitty god awful OS != "Every prior incarnation of touch-screen phones"
They where other contenders with better OSes. PalmOS was a very neat OS that successfully launched the whole concept of PDAs (from the ashes of Apple's own failed Netwon attempt, no less). BlackBerry largeley predates iPhone too.
"Pocket Internet Explorer"? A 'start' menu on a phone? Slow, clunky, ugly interfaces? Hard to configure? This is why they weren't popula
This is why I never went to a Microsoft's-Shit-Powered PDA. Started using PalmOS with a Palm IIIc and never looked back.
it's not because people weren't being told to use them. It's not because these things weren't marketed, they were. It's because they sucked.
The tremendous success of Palm and later BlackBerry in their own markets (business type, academics, doctors, etc.) begs to differ.
That was the whole core success of Palm : Making a sleak interface that even a non-nerd could use, and was very responsive and easy to get around. Just push a button and/or just start scribbling with the stylus and the PDA gets exactly what you need. You can google around and read articles about their story : after the flop of previous competitors (including - ironically - Apple's own Newton), a group of designers (that would eventually become Palm - though they initially sold hardware as 3com) spent lots of effort to make a PDA that would not suck, and that could be as handy and useful as possible.
No fuss with a stupid windows-95 styled "start" menu. That peculiar shit was Microsoft invention. They attempted to replay the same event as back with the Pen Computer craze: see a new potential market emerging (here: PDAs), and rush in some half-baked shit of their own with the intent to occupy the market. Almost more wanting that somebody else doesn't get successful rather than trying to actually conquer the market. (To the point that their shit tanks the emerging market and analysts take Microsoft suckiness as "there's no consumer interest in XYZ").
I was under the impression that this time Microsoft wasn't as successful at wiping the competition (thanks to Palm managing to establish themselves with a successful line of products). But the fact that some like you think that "PDA" == "Microsoft Pocket PC", makes me doubt it.
The iPhone came along, and sure, at the start it didn't even have apps. But it managed to achieve the not inconsiderable feat of not sucking.
As had Palm's PalmOS-powered PDA done in the past.
And unlike Palm and BlackBerry, they managed to persuade Joe Six Pack that having a networked computer in their pocked was worth it. (Whereas Palm and the like tried - successfully - to persuade business type that having their personal agenda in their pocket was worth it. to persuade college student that a small computer they can store schedule, take notes, organize and play a few games was worth it. to persuade doctors that rather than struggling which of the 20 different "pocket-size reference" they should take, a single pocketable and easy to use computer device is better. etc.)
While you might not think that constitutes innovation, you would be quite wrong.
I'm not saying that "not sucking" is not a significant caracteristic of the iPhone. I'm saying that pocket-sized computer that didn't suck were already available for around a decade back then and iPhone wasn't revolutionnary back then, no matter what shit Microsoft manader to make with their shitty OS.
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation. (And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
An attacker could use LE to setup a MITM attack, if they can hack the website.
As I've explained in the quote you're replying to, if the attacker has control of the website, they can do pretty much everything they want. At that point, getting a LE certificate is spending needless time on useless stuff that won't bring you much access beyond what you do.
1) Take control over the website.
At that point, the attacker has access to everything they could dream of. You can straigth jump to:
4) Phish a user into going to their MITM site, which has a LE signed certificate, that your browser trusts.
Why MITM site ? The attacker has access to the real deal. They could steal data straight from the actual site if they want.
Why LE signed certificate ? (Or for that matter CaCerts, Starcom or any non-EV option at one of the big name certificate authority). The attacker has access to the actual original private key on the site. If anything, a changed certificate or even a changed authority might look conspicuous (and some power users have tools to detect exactly that).
Why setup a separate LE certificate, when they can use the actual key and rely on whatever expensive signing the site went for ? (and then, for all intent and purpose, the interaction with the pish looks cryptographically exactly the same as if coming from the genuine site. There's no cryptographical way to distinguish them).
At the point where an attacker controls the website, you're pretty much hosed and the fact that they could get a certificate from Let's Encrypt (or from CaCerts.org) (or pay a non-EV certificate from any of the expensive trusted certificate providers) is a minor details compared to the potential of damage they now have access to.
There isn't much difference between Let's Encrypt, CaCerts.org, or a non-EV certificate that you can get from any of the classical providers. The only thing that Let's Encrypt has brought to the table is their "ACME" protocol, making things also easier to automate on the website owner's side of the business and providing a reasonable set of defaults. (With LE, even Joe Six Pack can have https on their own blog).
The big distinction is between EV and non-EV certficates. non-EV certs (including from classical sources, but also including Let's Encrypt and CaCerts) : only guarantee (through automated means) that the website is indeed the URL it claims to be - (padlock in URL bar) EV certs : actual human staff is paid to check extensive legal/official paper work to guarantee that the website belongs to a legal entity (a registered company) - (company name in URL bar).
Can you explain specifically what makes this better than self-signed certs?
Self signed certs don't certify much (beyond the cryptographic validity of the key pair). That means, on your first visit, that it's YOUR burden to check it that certification really belong to the domain, before trusting it and adding it. (It could be a Man-in-the-Middle with their own self-signed certificate).
On the other hand non-EV certificates and Let's encrypt, all require some proof that the certificate requestor has a control of the server (depending on the entity issuing the certification: requestor can answer "webmaster@[website.com]" e-mails (e.g.: CaCert), or that the requestor can publish and sign information on "https://[website.com]/nonce" (Let's Encrypt), etc.) It's always steps that : - can easily be automated (e.g.: no need to review official legal documents by staff. Unlike EV certificates) - are steps that can only be done if the requestor has actually control of the domain.
So when you go to [website.com], if the certificate is a non-EV certificate or by Let's Encrypt, you have the guaranty that this certificated was delivered to the people genuinely controlling [website.com]. It's very unlikely that an attacker is ini the middle.
Note that this type of certificate only confirms the address of the website. It provides no other information about the owner.
i.e.: a Let's Encrypt certificate gives you guaranty that "www.paipall.com" is indeed this website with no middle man attacker. (you get a padlock in browser URL bars. Like Slashdot.org). it's doesn't say anything if this website is actually owned by PayPal Inc or someone else. That would require an EV certificate (with a legal team reviewing the official papers to confirm or not) (taht gives a padlock and a company name in browser URL bars, like paypal.com)
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation. (And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
Most namely the Pocket PC and Windows CE, before the iPhone Windows Mobile and Pocket PC "apps" were sold by the millions through PocketGear and Handango, which were third party app stores that existed for many years.
Make a complex pocket-sized super-computer usable for normal people
done by PDAs for decade by this point. They weren't designed for highly technical people neither. The only details is that PDAs were usually marketed toward business, students, doctors, etc. Apple marketed their to Joe Random.
Put a proper webbrowser into a pocket sized device
...ever heard of Opera Mini ? Though yes theirs was a bit better than what was available elsewhere.
implement the concept of an online marketplace for software (henceforth called "Apps" - short and poignant so everyone can use the word)
Wut ? The well developped PalmOS apps ecosystem that existed before begs to differ. Apple's actual only success is managing to lock the users into a *single* walled garden. (Whereas there were various website where you could fetch PDA applications, none of which usually operated by the constructor).
Also, most people seem to forget, but when the iPhone was released, there wasn't much possibilities for 3rd party apps. 3rd parties were supposed to make mobile websites.
3rd party apps were only allowed at a later point in the device life cycle.
kill Flash and trailblaze it's replacement by an open standard web
My first all-touch device after my Blackberry was the HTC Desire. And while it was way better than the iPhone at the time in every aspect, you still have to hand it to Apple: They started an entirely new industry.
PDAs, including all the "firsts" attributed to the iPhone in this article, predate Apple's smartphone, sometime by a whole decade.
Even *Apple's own Newton* predates the iPhone.
My first tough when I saw the iPhone back then was : Oh, yeah. Now Apple wants to jump on the "PDA" bandwagon, as if Microsoft wasn't enough already.
The form factor (screen and touch interface) was already standard since the first Palm rose to success. (Apple's minor improvement was to be among the first with multi-touch, thank to their "capacitive touch interface" port-folio, licensed from Synaptics and used on iPod touch-wheels) The Palm Tungsten I had in my pocket that day already had this form factor and was already old by that time.
Network access ? Has always been the staple of PDAs. Starting from the venerable Psion (using compact-flash modules), through Palm both for wifi (Wifi SDIO modules, then later built-in) and for cell (IrDA tethering, Bluetooth Tethering, cell modules on Visor, and finally built-in cell capability with Palm Centro and such). By the time the iPhone was announced, every single PDA (either running PalmOS or WinCE) could go online, either wifi or cell.
The only thing that Apple brought is marketing the same old concept but to masses. Before, PDA tended to be market more toward business, academics and doctors. Random people tended to have durable dump phones (Nokia) or feature phone (exemple like RAZR). Apple's iPhone is the first that was marketed toward Joe Six-pack. (Tough before, other companies like Tapwave tried unsuccessfully to enter other market like the PDA/hanheld console hybrid Zodiac geared toward college students).
That, and managing to completely ruin the idea of battery endurance (iPhone 1 couldn't even get through the day on a single charge. Dumb phone could go between a week and a month depending on which (user-replaceable) battery was used. Most PDA could hold about a couple of days).
Apps ? PalmOS almost single-handedly invented the concept of apps. Apple's only "invention" (actually drawback) was to leverage their iTunes platform to impose 1 single walled garden with no way to get apps from anywhere else. And actually, You might not be remembering, but 3rd-party apps only arrived much later on. Initially Apple opinion was : either only our own apps, or 3rd mobile websites, no other choice.
Photography is the only actual field where Apple really helped things move forward. Before, it was either crappy webcam on feature phone with minimalist possibilities (save them on the bult-in memory, send them by MMS/eMail/Bluetooth/IrDA), or *very few* PDAs (as most PDAs where marketed toward business use, very few had built-in camera. Sony Clie was among the exceptions. A few add-ons did exist but with very limited real-world use). As Apples' smartphone was more geared toward the general public, it made sense to equip it with some photo capabilities. Of course that being Apple, they couldn't introduce it without yet another major step back : No. Fucking. External. Storage. Whereas most of the industry was standardizing on SD cards for PDAs (some even featuring dual slots) - (With Sony's memory stick being the only usual exception), iPhone didn't have any slot or extension ports. Oh and another step back : Bluetooth only used for wireless audio. No way to use bluetooth to send the photos. Basically, Apple tried to put a cam that didn't suck too much on the iPhone, but then locked in all the pictures.
So over all, Apple just re-heated an already existing concept PDA, managed to market it to wider masses (so iPhone is basically to PDAs and smartphone, what Wii is to home consoles), while still fucking up quite a few point (but never mind, the masses weren't using PDAs before and won't notice the missing stuff) and make people thing they actually started the whole concept.
Paper maps, compared to a SatNav have a couple of problems :
- A small one : One needs to know how to read them.
- And a *major one* : You're not supposed to read while driving, nor fussy around with books and papers. You're supposed to keep your eyes on the road. So you need that the person riding shotgun takes care of the maps (and hope is map-litterate enough to be actually able to do it). (As opposed to a SatNav that handles everything alone and that you can keep within your far aways field of view, like right above of the dashboard) (Just don't be an idiot, don't stick it in the middle of the front window as most idiots seem to be doing lately).
Emergency lines, navigation and texting are essential for people's safety and should be available all the time.
Da fuck happened with offline navigation ?
As in maps stored locally on an SD card (even on old SatNav from 15 years ago like Tomtom, or on modern car's infotainment, or by using the "save offline map" function of smartphone apps like Google, or even weird solution like Sailfish OS's OSM Scout Server where the map server *itself* runs on the phone). And getting the traffic information from any publicly broadcast source (TMC - Traffic Message Channel - over FM-RDS or over DAB, or over whatever you use a digital data transmission on your side of the Atlantic pond). Or listening to information over plain normal radio ? (Some in-car radio are even designed to automatically switch between radio traffic announcement and whatever you're listening to).
Why does everything has to be constantly online if it's that much critical ?!
Said as an European dweller, who's used to cross national border whenever driving more than a few dozens of Km, and thus used to take offline mapping capability to avoid absurd data roaming costs. To me it seems absolutely clear that if you need to rely on it, you must be able to make do with dropped signal.
Currently the XMPP server is still available (and can chat to Google Hangout users) For now. Let's hope that Google will at least maintain this access.
One thing that worked about 10 years ago but doesn't anymore is gapless playback. {...} I searched a lot only to find that pulse audio with amroK either uses gstreamer or vlc as engine, and neither can do gapless.
This has nothing to do with pulse audio, but with the way modern application are built.
Old school application were in charge of decompression their own audio using their library or nativ codecs. They filled their audio buffer, and sent it to play. When play list advances from song A to song B, it just change which source the data going into the audio buffer will come from. In the end, the audio buffer is filled anyway, and the audio from song A and song B are just next to each other in the output buffer and get sent to the output all the same.
Modern application don't handle the decompression themselves. They offload all the tiny details to frame works (like Gstreamer). Song are played by constructing a filter graph that handles the decompression and output of each song. Each different song is a different such filter graph. Once song A finishes to play, its graph is tear down, then song B begins to play and a new graph is built (and perhaps different graph depending on the file format demuxers, audio decompressors, etc.) The tiny gap you hear between 2 songs is this work of the virtual "plug board" being re-cabled for the new song. The modern app isn't in charge any more of building a continuous seamless audio output buffer. It's only job is giving instruction to the frame work (once song A finishes, move to song B). On the other hand, because it's not a single buffer but 2 files being player independently, cross fading from A to B is trivial and comes free.
the xine framework was the only exception to this rule (the framework itself was designed specially to allow several different file to be played as continuous uninterrupted stream (because that's how DVD used to work back then - a bunch of separate VOB files). And amarok used to be able to play gapless 10 year ago using libxine. (and a few other neat feat). But more recent versions of amarok have completely dropped the support for libxine.
Blame it on gstream to not being specially optimized for gapless, and for phonon (the high-level API used by most KDE and Qt application) being mostly a "play file A, play file B"-oriented API, instead of "keep the buffer full"-oriented Perhaps the future shift to PipeWire might change the trend.
(Switzerland is one of the few direct democracies, i.e.: where the general population has the final say on nearly anything - as mentioned by the above poster).
They are chineses. No matter what ebay and amazon try to do whil attempting to outcompete each other, alibaba will still manage to come up with something dramatically cheaper. Yes, the build quality will be horrendous, the time to failure will be counted in minutes, but still, it's going to be cheaper.
Last time I drove one of those, it was more annoying than it was worth... The damned little light kept coming on as I was driving a winding mountain road, telling me there was something in my blind spot. No shit; it's called a mountain.
That's typical with ultra-sound sonar based BLIS. The sonar in cars was developed initially for park-assistance (or later autonomous parking), so it was chosen because it can detect *any* object in the way (anything that exists will register on the sonar. Not only cars, but even mountains. Which makes sense for parking, because you don't want the car to hit the wall next to your parking place. But is completely unadapted for BLIS)
Camera BLIS are a bit better. The camera detect vehicle-shaped things. It will not blink in case of a mountain or a wall, it's not an incoming vehicle on the side lane (and detecting lane where you can drive into is already the job of the front-facing camera and lanes-departure-alerts. If you're driving into the mountain instead of another lane, that alert should be already sounding).
It's not perfect though, specially most manufacturers use the same off-the-shelf part from Mobileye which are based on a bit older and less performant machine learning algorithm than the current edge (Deep neural nets) and thus might miss identify object : - the oldest Mobileye platform couldn't recognize bicycles. - on my parent's older Volvo, under very weird lighint conditions, it sometime mis identifies its own reflection (or even its own shadow, according to the book), and has occasionnally blinked while I was driving next to a plexiglas "sound barrier".
Some cars (I've seen it with french manufacturer, but it exists elsewhere too) go the other way around : they supplement their parking assistance with a simulated "top view" around the car obtained by distorting the video feed of the cameras around the car).
During the day it was no big deal, but at night, that light blinking on and off in the peripheral vision was quite distracting.
For me, it looks mostly a UX / UI problem : - BLIS should be something that you notice when looking sideways before changing lanes, - BLIS should NOT be something that attracts too much attention when you look forward.
(And in my parent's Volvo, indeed, it's not distracting. At least that car got it right).
They should make the light dimmer (follow the setting of the dash-board light dimmer). Eventually only lighting up when really needed (when the turn signal/blinkers are on. And/or when the lane-derparture alert notice that the user is going to change lane without a turn signal)
Anyhow, I know how to set my mirrors properly to minimize blind spots, and I always shouldercheck.
Still better safe than sorry. You can garantee that the human driver will always be perfect forever in absolutely 100% of time. Mistakes could happen one day. Alerts in modern cars (forward collision avoidance, etc.) are a good way to supplement the human and an extra step to avoid accident. (Saddly, some humans treat them as "excuse to completely shut of the brain and try dozing as mush as possible").
It would be nice if things like that could be turned off when not needed.
Again a UX / UI problem : shutting it off should be an easy setting, at least in the menu on the infotainment center. (Or a small button on the dash board as most advanced feature).
But beware, I'm sure that some US insurance companies are going to jack up price if they detect shutting down security features)
- add a forward facing LIDAR and or 3d-pair of stereo camera (instead of 2d), to supplement the current radar and 2d camera. This would help the car disambiguate between a truck just in front, and a highway sign much further in the same direction - both could look similar to the current set of sensors)
- add backward facing cameras under the rear-view mirror : this would help the car change lane safely. Means that it could cover the scenario "user doesn't touch the wheel for the past 30min despite alarms" => "user has probably passed out / is unconscious / etc." => "telsa should automatically pull to the side" => "means must be able to change lanes until side is reached" (The car should also automatically call emergency services, and should blink and honk to attract attention)
* Why didn't the car slow down if you have your hands off the wheel for more then 5+ minutes?
slowing down brings a slight risk of getting rear-ended, specially in the middle of other wise fluid traffic. that's why I suspect that the engineers at Tesla erred on the side of not stopping.
* Why didn't the car's sensor detect the impending crash?
Tesla in particular lack LIDARs and/or 3D-pair of stereo video camera. They only have a forward facing 2D video camera and a radar. These might get slightly confused by distance and size and might confuse the truck with a street sign much further. (Highway signs are rather reflective and might seem closer on the radar that they actually are. A truck - i.e.: a big close signal - could thus be confused with artifacts caused by a highway sign - the car might think that it could be looking closer than it is, even if actually the radar was right and the truck is indeed closer) (A 2D camera would be poor at judging distances).
(On the other hand, because they have accurate Z coordinate, stereo cameras and LIDARs could more reliabily confirm that this is indeed a closer object (a truck right in front of the car) than expected).
* Why didn't the car pull over the side of the road after 15 minutes of hands free driving?
Sensors/safety again. Tesla only uses ultra-sound sonars (souped up equivalent of parking assistance) to check nearby lanes for free space to change lane into. Backward facing camera - as used in some other cars - would be better at spotting a car coming from far behind and avoid cutting it of. With its current set of sensors, a Tesla can reliably change lane safely.
If the car is not smart enough to see a truck by itself,
This may also not have been a problem of smart, but a problem of sensors not registering the truck in this peculiar situation. (e.g.: unlike other cars, Teslas only have forward facing radars and 2D video camera, no LIDARs, nor 3D-pair of stereo cameras.)
it may not be smart enough to find a safe space to pull over and shut itself off.
It's definitely not as much a problem of smart as it is of sensors : whereas some other cars feature read-facing video cameras under the side mirrors (that can see if there's a car in the next lane much further back), Teslas are among the car that exclusively rely on their ultra-sound sonars (basically souped up parking assistance with a bit improved range) which are much shorter-range. They can reliably tell you when a car is in the next lane or if there's space right next to the Tesla, they can't see if there's a car coming from behind in the lane.
With its current set of sensors, Tesla definitely can't change lane without risking to cut someone of. That's part of the reasons why the driver needs to signal his request by using the blinker (driver checks blind sport and behind on the lane, and only then pushes the blinker lever).
If that's a requirement, why didn't the car just pull over and shut off?
The main reason is that in this exact type of car (Tesla Model S) pulling over - specifically, the "change lane" part of it - can't be automated 100% yet. The car sense cars in neighboring lanes (BLIS - Blind Sport Information System) by using its ultra-sound sonars. Basically a type of souped up parking assistance with a little bit more range. This is good at detecting whether the space right next to the Tesla is free, this isn't that good at detecting incoming cars in the lane. (i.e.: if the Tesla only trusts its sonars as currently done, there's a risk that it cuts of someone)
That why currently the car will never initiate a lane change on its own, the driver is required to action the blinker to initiate a lane change.
(Compare with camera-based BLIS, like the past couple of year in Volvos. The camera has much longer range and can actually spot a car incoming from far behind. These Volvos don't change lanes by themeselves, but at least are able to bring to attention to the driver cars not only in the blind spot but even further back in the lane)
Also, I suspect that the machine learning / deep net in Tesla doesn't have a notion/concept that the shoulder lane is something different and special. (i.e.: I mean it can't even *target* the shoulder lane as a destination to change lane into, because it won't necessarily recognize it as such).
Note that none of the above is a hard obstacle : - as mentioned, camera based BLIS - that can look much further back and realise if there's incoming traffic - do exist and have been in circulation for a couple of year. And I know that at some point in time, Tesla was toying with the idea of camera at side mirrors (except that they wanted to completely drop the side mirror and only use cameras/virtual mirrors - This would have been much more difficult to get past regulations). - training the system to recognize shoulder lanes shouldn't be that much complicated. - it's probably an emergency situation (if the driver hasn't been able to touch the wheel for the past 30 minutes, he might not even be conscious). It would be acceptable for the car to blink and honk to notify that something is wrong so other driver can see and take evasive manoeuvre. - Bonus point if the car can automatically drop a triangle 100m before stopping on the shoulder lane for safety (or whatever is the required distance in your jurisdition). And Elon Musk is the kind of geek who'll pay special attention to these kind of small details (see the uncanny automatic charging snake).
Slashdot Mirror
You think adding bluetooth to a fidget spinner is a brillant idea ?!
You're *this* close to winning a Darwin Award.
If you RTFA : yes, and actually they managed quite a few feat to make it both legal and easier on them.
e.g.:
- the launch site is privately owned (no competition to use it by other branches government)
- the launch site is quite remote (no need to wait and coordinate with air traffic)
etc.
basically they managed to be legit, and they did in creative manner that actually enable them to operate better.
The story about it I read last week said that he did test it on another book and showed it to her to convince her it was safe.
Which overall speaks for the necessity of being very rigorous during testing.
Yes, paper armor is a thing. (And was a thing in historic China).
Swords blows, and even some (not to high velocity) bullets can be stopped, while the overall armor is extremely light.
(The explanation : the friction with each individual layer of paper slow the weapon a bit. After dozens and dozens of layer, a sword will get stopped. Some bullets might to. I think there might be a Mythbuster episode about this ?)
BUT it's extremely dependant on the exact parameters.
If he did the test with a massive book (some thick dictionary) and some not too powerful pea-shooter (sorry, we're not gun nuts enough on my side of the atlantic pond to have any vague idea what exact type of gun and bullets could get stopped) yeah sure, it might have worked.
If on the D day they decided to use a book with different characteristics (number of page, paper weight, types of cover, etc.) than during the test and if they switched to a different weapon (TFS mentions a Desert Eagle and I think I might remember that these have some power. Again, not gun nut enough to know) that will be enough for the bullet to simply flight through the book almost unencumbered.
Proper procedure would have been :
- run tests with the exact same setup (distance, type of book, type of bullet, type of gun) than the final take
- run SEVERAL tests to confirm that it is reliably reproducible.
(- while you're at it : run the tests with the camera. help you find the correct setup, and gives footage for a decent "making of")
- on the D day, try as much as possible to wear protection (ballistic plate dicretely hidden under the shirt, in case the trick fails ?)
- also best if you have emergency responders ready to intervene if anything goes wrong.
(But that's the difference between a real stunt and a youtube trick by teenagers).
If human spoken language was as rigid and rule abiding as programming language,
we will probably be still communicating by "Ug !"s and "Arg!"s.
And hitting with club the head of anyone not following the same caveman conventions as anyone else.
Language evolve. New words and rules are constantly created, as people continue to speak.
Some variation become widespread and eventually aren't considered as errors anymore as poeple get used to them and start using them too.
And that's how you end-up speaking english, which doesn't look much like old-english, which in turn has evolved further from Germanic root, etc.
In fact even programming language aren't that much solid. ...
Language evolve as new idea enters the standards (see the evolution of K&R C, ANSI C (C89/C90 and C95), C99, C11...)
Even the different languages themselves are a sign of evolution, after all we aren't all still programming in Assembler, but we have moved to tons of languages like Fortran, C/C++, LISP, Perl, Python, Javascript, Rust,
The only main difference being, as computer arent as good (yet) as humans to infer from context, one need presicion in programming as you mention, and language tend to have clear rules and systems of standards and extensions. (Okay, and then there is Perl).
I have NEVER seen a cheap piece of plastic last for more than a couple years out baking in the sunshine. It disintegrates on it's own. {...} but it all reverts back to good ole mother earth.
Yes, under the sun (and lots of other environmental factors, including mechanical action) a bottle will disintegrates.
But THIS IS NOT reverting back to good old mother earth.
It is just breaking a big plastic object into finer plastic dust.
Which brings its own bunch of problems:
- this plastic dust disperse wide
- this plastic dust has a higher risk of getting ingested by marine animal
- this plastic dust also collects organic compounds more easily
- once ingested by marine animal, due to higher amount of organic compound stuck on the plastic dust, these animal accumulate more pollution.
(There a movie called "A plastic ocean" currently touring festivals that explains this better).
And thus, TFS :
Should you ever travel to one of the many uninhibited islands that dot the most remote reaches of Earth's oceans, chances are you'll find plastic bottles littering the shore.
That's actually a myth. You're nearly NEVER going to find whole intact plastic bottles in remote places because the above phenomenon.
The reality is actually much grimmer :
- with the naked eye you're not going to see much (again, artificial islands of collect plastic junks are a myth).
- but if you make lab analysis of the environment, you'll see that :
-- most local marine animals have ingested an alarming amount of plastic dust in their bodies
-- and they'll have probably concentrated some polluant at higher dose.
Otherwise the Tennessee River which I grew up on would be totally lined with styrofoam.
It is a *river*. It wont never stay lined with anything for a long time : eventually everything will get carried away by the current and broken down in smaller particles (also some substance like steel *will* degrade (to rust, etc.) while other like glass and plastic are too chemically stable. At least glass will break-down into sand (basically : glass dust)).
Once carried away by the current they will eventually find their way into the seas, then into the ocean, when they'll finally get caught into some current that will keep them in some cycle forever.
Heck, there are some woods, cedar for example, that will last longer than a plastic bottle exposed to the elements.
Actually wood isn't such a bad exemple.
But not for the reasons you think.
(No: it won't last longer than plastic bottle. It will *keep its shape* for a longer time than plastic [that's why life invented it in plants : because it's structurally sturdy]. But eventually, decomposers [bacteria, funghi, etc.] will manage to digest it. It will actually end up back into CO2)
But some eons ago that wasn't the case. It took some time between life inventing wood (somewhere in the Devonian), and bacteria coming up with a way to degrade it.
Of course all this juicy stored chemical energy was going to end-up being used as a food source for some microbes.
The same situation is happening again. We human produce tons of a nearly indestructible component (plastic) but that is still rich in stored chemical energy (the fact that you can actually burn it into CO2 is a sign).
Eventually all this untapped chemical energy is going to attract some bacteria, and in the recent couple of year, scientist have discovered some types of bacteria who have evolved a way to digest and process plastics.
Maybe in a couple of centuries (and maybe with a little bit of help by researchers) Nature will find a way to clean it self of this plastic pollution, by inventing a way to harness its stored chemical energy.
Your point on battery endurance is a bit ridiculous, use your iPhone like you would a dumb phone and its battery will last a lot longer.
I came from the other point of view.
There was no way I could use an iPhone the way I've been (ab)using my Palm PDAs before.
I bought a Palm IIIc around 2000 and used it a my daily driver during a good part of my studies.
I took all my notes during lectures on it. Typing on the foldable keyboard, or scribling with the stylus when on the move.
Even under strong use, if I forgot to charge it during the night, it could still be holding the next day to the end.
The thing is, it was an *PDA*. It didn't have it's own connection, it relied on IrDA tethering if I wanted to check e-mail (with later PDAs like my Palm Tungsten T3 I could use bluetooth tethering or a Wifi SDIO card, though that last one similarily reduced battery life).
So the pocket computer wasn't constantly connected.
(Meanwhile, the phone I was using the most was a sturdy dumb phone, Ericsson T39 - good battery life, specially when using a fat replacement battery)
Each device with its own adapted battery.
On the other hand, the smartphone trend started to pack all the above functionality in a single device, sharing a single meager battery.
And with the race to make the device as thin as possible, the space constrain aren't getting any better.
So of course the first iPhone was going to have a not so great battery performance (doing all the work of a PDA and a feature phone, on a single battery).
The non-replaceable battery didn't help.
In the context of your comment, marketing actually means; Making something usable, as opposed to being terrible.
No, I really meant "Try to bring it to market XYZ".
Every prior incarnation of touch-screen phones were uniformly unusably bad.
Microsoft's shitty god awful OS != "Every prior incarnation of touch-screen phones"
They where other contenders with better OSes.
PalmOS was a very neat OS that successfully launched the whole concept of PDAs (from the ashes of Apple's own failed Netwon attempt, no less).
BlackBerry largeley predates iPhone too.
"Pocket Internet Explorer"? A 'start' menu on a phone? Slow, clunky, ugly interfaces? Hard to configure? This is why they weren't popula
This is why I never went to a Microsoft's-Shit-Powered PDA.
Started using PalmOS with a Palm IIIc and never looked back.
it's not because people weren't being told to use them. It's not because these things weren't marketed, they were. It's because they sucked.
The tremendous success of Palm and later BlackBerry in their own markets (business type, academics, doctors, etc.) begs to differ.
That was the whole core success of Palm : Making a sleak interface that even a non-nerd could use, and was very responsive and easy to get around.
Just push a button and/or just start scribbling with the stylus and the PDA gets exactly what you need.
You can google around and read articles about their story : after the flop of previous competitors (including - ironically - Apple's own Newton), a group of designers (that would eventually become Palm - though they initially sold hardware as 3com) spent lots of effort to make a PDA that would not suck, and that could be as handy and useful as possible.
No fuss with a stupid windows-95 styled "start" menu. That peculiar shit was Microsoft invention. :
They attempted to replay the same event as back with the Pen Computer craze
see a new potential market emerging (here: PDAs), and rush in some half-baked shit of their own with the intent to occupy the market.
Almost more wanting that somebody else doesn't get successful rather than trying to actually conquer the market.
(To the point that their shit tanks the emerging market and analysts take Microsoft suckiness as "there's no consumer interest in XYZ").
I was under the impression that this time Microsoft wasn't as successful at wiping the competition (thanks to Palm managing to establish themselves with a successful line of products).
But the fact that some like you think that "PDA" == "Microsoft Pocket PC", makes me doubt it.
The iPhone came along, and sure, at the start it didn't even have apps. But it managed to achieve the not inconsiderable feat of not sucking.
As had Palm's PalmOS-powered PDA done in the past.
And unlike Palm and BlackBerry, they managed to persuade Joe Six Pack that having a networked computer in their pocked was worth it.
(Whereas Palm and the like tried - successfully - to persuade business type that having their personal agenda in their pocket was worth it.
to persuade college student that a small computer they can store schedule, take notes, organize and play a few games was worth it.
to persuade doctors that rather than struggling which of the 20 different "pocket-size reference" they should take, a single pocketable and easy to use computer device is better.
etc.)
While you might not think that constitutes innovation, you would be quite wrong.
I'm not saying that "not sucking" is not a significant caracteristic of the iPhone.
I'm saying that pocket-sized computer that didn't suck were already available for around a decade back then and iPhone wasn't revolutionnary back then, no matter what shit Microsoft manader to make with their shitty OS.
Apple leveraged two thing :
- Their quasi-cu
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation.
(And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
An attacker could use LE to setup a MITM attack, if they can hack the website.
As I've explained in the quote you're replying to, if the attacker has control of the website, they can do pretty much everything they want.
At that point, getting a LE certificate is spending needless time on useless stuff that won't bring you much access beyond what you do.
1) Take control over the website.
At that point, the attacker has access to everything they could dream of. :
You can straigth jump to
4) Phish a user into going to their MITM site, which has a LE signed certificate, that your browser trusts.
Why MITM site ? The attacker has access to the real deal.
They could steal data straight from the actual site if they want.
Why LE signed certificate ? (Or for that matter CaCerts, Starcom or any non-EV option at one of the big name certificate authority). The attacker has access to the actual original private key on the site.
If anything, a changed certificate or even a changed authority might look conspicuous (and some power users have tools to detect exactly that).
Why setup a separate LE certificate, when they can use the actual key and rely on whatever expensive signing the site went for ? (and then, for all intent and purpose, the interaction with the pish looks cryptographically exactly the same as if coming from the genuine site. There's no cryptographical way to distinguish them).
At the point where an attacker controls the website, you're pretty much hosed and the fact that they could get a certificate from Let's Encrypt (or from CaCerts.org) (or pay a non-EV certificate from any of the expensive trusted certificate providers) is a minor details compared to the potential of damage they now have access to.
There isn't much difference between Let's Encrypt, CaCerts.org, or a non-EV certificate that you can get from any of the classical providers.
The only thing that Let's Encrypt has brought to the table is their "ACME" protocol, making things also easier to automate on the website owner's side of the business and providing a reasonable set of defaults. (With LE, even Joe Six Pack can have https on their own blog).
The big distinction is between EV and non-EV certficates.
non-EV certs (including from classical sources, but also including Let's Encrypt and CaCerts) : only guarantee (through automated means) that the website is indeed the URL it claims to be - (padlock in URL bar)
EV certs : actual human staff is paid to check extensive legal/official paper work to guarantee that the website belongs to a legal entity (a registered company) - (company name in URL bar).
Can you explain specifically what makes this better than self-signed certs?
Self signed certs don't certify much (beyond the cryptographic validity of the key pair).
That means, on your first visit, that it's YOUR burden to check it that certification really belong to the domain, before trusting it and adding it.
(It could be a Man-in-the-Middle with their own self-signed certificate).
On the other hand non-EV certificates and Let's encrypt, all require some proof that the certificate requestor has a control of the server
(depending on the entity issuing the certification: requestor can answer "webmaster@[website.com]" e-mails (e.g.: CaCert), or that the requestor can publish and sign information on "https://[website.com]/nonce" (Let's Encrypt), etc.)
It's always steps that :
- can easily be automated (e.g.: no need to review official legal documents by staff. Unlike EV certificates)
- are steps that can only be done if the requestor has actually control of the domain.
So when you go to [website.com], if the certificate is a non-EV certificate or by Let's Encrypt, you have the guaranty that this certificated was delivered to the people genuinely controlling [website.com].
It's very unlikely that an attacker is ini the middle.
Note that this type of certificate only confirms the address of the website.
It provides no other information about the owner.
i.e.: a Let's Encrypt certificate gives you guaranty that "www.paipall.com" is indeed this website with no middle man attacker.
(you get a padlock in browser URL bars. Like Slashdot.org).
it's doesn't say anything if this website is actually owned by PayPal Inc or someone else. That would require an EV certificate (with a legal team reviewing the official papers to confirm or not)
(taht gives a padlock and a company name in browser URL bars, like paypal.com)
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation.
(And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
Most namely the Pocket PC and Windows CE, before the iPhone Windows Mobile and Pocket PC "apps" were sold by the millions through PocketGear and Handango, which were third party app stores that existed for many years.
And before that PalmOS had a tremedous success.
PDAs were already doing this for quite some time.
Make a complex pocket-sized super-computer usable for normal people
done by PDAs for decade by this point. They weren't designed for highly technical people neither.
The only details is that PDAs were usually marketed toward business, students, doctors, etc.
Apple marketed their to Joe Random.
Put a proper webbrowser into a pocket sized device
...ever heard of Opera Mini ?
Though yes theirs was a bit better than what was available elsewhere.
implement the concept of an online marketplace for software (henceforth called "Apps" - short and poignant so everyone can use the word)
Wut ?
The well developped PalmOS apps ecosystem that existed before begs to differ.
Apple's actual only success is managing to lock the users into a *single* walled garden. (Whereas there were various website where you could fetch PDA applications, none of which usually operated by the constructor).
Also, most people seem to forget, but when the iPhone was released, there wasn't much possibilities for 3rd party apps.
3rd parties were supposed to make mobile websites.
3rd party apps were only allowed at a later point in the device life cycle.
kill Flash and trailblaze it's replacement by an open standard web
My first all-touch device after my Blackberry was the HTC Desire.
And while it was way better than the iPhone at the time in every aspect, you still have to hand it to Apple: They started an entirely new industry.
PDAs, including all the "firsts" attributed to the iPhone in this article, predate Apple's smartphone, sometime by a whole decade.
Even *Apple's own Newton* predates the iPhone.
My first tough when I saw the iPhone back then was : Oh, yeah. Now Apple wants to jump on the "PDA" bandwagon, as if Microsoft wasn't enough already.
The form factor (screen and touch interface) was already standard since the first Palm rose to success.
(Apple's minor improvement was to be among the first with multi-touch, thank to their "capacitive touch interface" port-folio, licensed from Synaptics and used on iPod touch-wheels)
The Palm Tungsten I had in my pocket that day already had this form factor and was already old by that time.
Network access ? Has always been the staple of PDAs. Starting from the venerable Psion (using compact-flash modules), through Palm both for wifi
(Wifi SDIO modules, then later built-in) and for cell (IrDA tethering, Bluetooth Tethering, cell modules on Visor, and finally built-in cell capability with Palm Centro and such).
By the time the iPhone was announced, every single PDA (either running PalmOS or WinCE) could go online, either wifi or cell.
The only thing that Apple brought is marketing the same old concept but to masses. Before, PDA tended to be market more toward business, academics and doctors. Random people tended to have durable dump phones (Nokia) or feature phone (exemple like RAZR).
Apple's iPhone is the first that was marketed toward Joe Six-pack. (Tough before, other companies like Tapwave tried unsuccessfully to enter other market like the PDA/hanheld console hybrid Zodiac geared toward college students).
That, and managing to completely ruin the idea of battery endurance (iPhone 1 couldn't even get through the day on a single charge. Dumb phone could go between a week and a month depending on which (user-replaceable) battery was used. Most PDA could hold about a couple of days).
Apps ? PalmOS almost single-handedly invented the concept of apps.
Apple's only "invention" (actually drawback) was to leverage their iTunes platform to impose 1 single walled garden with no way to get apps from anywhere else.
And actually, You might not be remembering, but 3rd-party apps only arrived much later on. Initially Apple opinion was : either only our own apps, or 3rd mobile websites, no other choice.
Photography is the only actual field where Apple really helped things move forward.
Before, it was either crappy webcam on feature phone with minimalist possibilities (save them on the bult-in memory, send them by MMS/eMail/Bluetooth/IrDA),
or *very few* PDAs (as most PDAs where marketed toward business use, very few had built-in camera. Sony Clie was among the exceptions. A few add-ons did exist but with very limited real-world use).
As Apples' smartphone was more geared toward the general public, it made sense to equip it with some photo capabilities.
Of course that being Apple, they couldn't introduce it without yet another major step back : No. Fucking. External. Storage.
Whereas most of the industry was standardizing on SD cards for PDAs (some even featuring dual slots) - (With Sony's memory stick being the only usual exception), iPhone didn't have any slot or extension ports.
Oh and another step back : Bluetooth only used for wireless audio. No way to use bluetooth to send the photos. Basically, Apple tried to put a cam that didn't suck too much on the iPhone, but then locked in all the pictures.
So over all, Apple just re-heated an already existing concept PDA, managed to market it to wider masses (so iPhone is basically to PDAs and smartphone, what Wii is to home consoles), while still fucking up quite a few point (but never mind, the masses weren't using PDAs before and won't notice the missing stuff) and make people thing they actually started the whole concept.
Since the traffic is predicted to be bad, I'd recommend car-pooling to the eclipse. Problem solved!
Or taking the public transportati....
Oh, wait. United States...
Nevermind.
Paper maps, compared to a SatNav have a couple of problems :
- A small one :
One needs to know how to read them.
- And a *major one* :
You're not supposed to read while driving, nor fussy around with books and papers.
You're supposed to keep your eyes on the road.
So you need that the person riding shotgun takes care of the maps (and hope is map-litterate enough to be actually able to do it).
(As opposed to a SatNav that handles everything alone and that you can keep within your far aways field of view, like right above of the dashboard)
(Just don't be an idiot, don't stick it in the middle of the front window as most idiots seem to be doing lately).
Emergency lines, navigation and texting are essential for people's safety and should be available all the time.
Da fuck happened with offline navigation ?
As in maps stored locally on an SD card (even on old SatNav from 15 years ago like Tomtom, or on modern car's infotainment, or by using the "save offline map" function of smartphone apps like Google, or even weird solution like Sailfish OS's OSM Scout Server where the map server *itself* runs on the phone).
And getting the traffic information from any publicly broadcast source (TMC - Traffic Message Channel - over FM-RDS or over DAB, or over whatever you use a digital data transmission on your side of the Atlantic pond).
Or listening to information over plain normal radio ? (Some in-car radio are even designed to automatically switch between radio traffic announcement and whatever you're listening to).
Why does everything has to be constantly online if it's that much critical ?!
Said as an European dweller, who's used to cross national border whenever driving more than a few dozens of Km, and thus used to take offline mapping capability to avoid absurd data roaming costs.
To me it seems absolutely clear that if you need to rely on it, you must be able to make do with dropped signal.
Currently the XMPP server is still available (and can chat to Google Hangout users)
For now.
Let's hope that Google will at least maintain this access.
One thing that worked about 10 years ago but doesn't anymore is gapless playback. {...}
I searched a lot only to find that pulse audio with amroK either uses gstreamer or vlc as engine, and neither can do gapless.
This has nothing to do with pulse audio, but with the way modern application are built.
Old school application were in charge of decompression their own audio using their library or nativ codecs. They filled their audio buffer, and sent it to play.
When play list advances from song A to song B, it just change which source the data going into the audio buffer will come from.
In the end, the audio buffer is filled anyway, and the audio from song A and song B are just next to each other in the output buffer and get sent to the output all the same.
Modern application don't handle the decompression themselves. They offload all the tiny details to frame works (like Gstreamer). Song are played by constructing a filter graph that handles the decompression and output of each song.
Each different song is a different such filter graph.
Once song A finishes to play, its graph is tear down, then song B begins to play and a new graph is built (and perhaps different graph depending on the file format demuxers, audio decompressors, etc.)
The tiny gap you hear between 2 songs is this work of the virtual "plug board" being re-cabled for the new song.
The modern app isn't in charge any more of building a continuous seamless audio output buffer. It's only job is giving instruction to the frame work (once song A finishes, move to song B).
On the other hand, because it's not a single buffer but 2 files being player independently, cross fading from A to B is trivial and comes free.
the xine framework was the only exception to this rule (the framework itself was designed specially to allow several different file to be played as continuous uninterrupted stream (because that's how DVD used to work back then - a bunch of separate VOB files). And amarok used to be able to play gapless 10 year ago using libxine. (and a few other neat feat). But more recent versions of amarok have completely dropped the support for libxine.
Blame it on gstream to not being specially optimized for gapless, and for phonon (the high-level API used by most KDE and Qt application) being mostly a "play file A, play file B"-oriented API, instead of "keep the buffer full"-oriented
Perhaps the future shift to PipeWire might change the trend.
Nobody tell him Santa doesn't exist!
Or that Santa is Swiss.
(Switzerland is one of the few direct democracies, i.e.: where the general population has the final say on nearly anything - as mentioned by the above poster).
You here that sound in the distance ?
That's the maniacal cackle of Alibaba.
They are chineses.
No matter what ebay and amazon try to do whil attempting to outcompete each other, alibaba will still manage to come up with something dramatically cheaper.
Yes, the build quality will be horrendous, the time to failure will be counted in minutes, but still, it's going to be cheaper.
Last time I drove one of those, it was more annoying than it was worth... The damned little light kept coming on as I was driving a winding mountain road, telling me there was something in my blind spot. No shit; it's called a mountain.
That's typical with ultra-sound sonar based BLIS.
The sonar in cars was developed initially for park-assistance (or later autonomous parking), so it was chosen because it can detect *any* object in the way (anything that exists will register on the sonar. Not only cars, but even mountains.
Which makes sense for parking, because you don't want the car to hit the wall next to your parking place.
But is completely unadapted for BLIS)
Camera BLIS are a bit better.
The camera detect vehicle-shaped things.
It will not blink in case of a mountain or a wall, it's not an incoming vehicle on the side lane (and detecting lane where you can drive into is already the job of the front-facing camera and lanes-departure-alerts. If you're driving into the mountain instead of another lane, that alert should be already sounding).
It's not perfect though, specially most manufacturers use the same off-the-shelf part from Mobileye which are based on a bit older and less performant machine learning algorithm than the current edge (Deep neural nets) and thus might miss identify object :
- the oldest Mobileye platform couldn't recognize bicycles.
- on my parent's older Volvo, under very weird lighint conditions, it sometime mis identifies its own reflection (or even its own shadow, according to the book), and has occasionnally blinked while I was driving next to a plexiglas "sound barrier".
Some cars (I've seen it with french manufacturer, but it exists elsewhere too) go the other way around :
they supplement their parking assistance with a simulated "top view" around the car obtained by distorting the video feed of the cameras around the car).
During the day it was no big deal, but at night, that light blinking on and off in the peripheral vision was quite distracting.
For me, it looks mostly a UX / UI problem :
- BLIS should be something that you notice when looking sideways before changing lanes,
- BLIS should NOT be something that attracts too much attention when you look forward.
(And in my parent's Volvo, indeed, it's not distracting. At least that car got it right).
They should make the light dimmer (follow the setting of the dash-board light dimmer).
Eventually only lighting up when really needed (when the turn signal/blinkers are on. And/or when the lane-derparture alert notice that the user is going to change lane without a turn signal)
Anyhow, I know how to set my mirrors properly to minimize blind spots, and I always shouldercheck.
Still better safe than sorry. You can garantee that the human driver will always be perfect forever in absolutely 100% of time. Mistakes could happen one day.
Alerts in modern cars (forward collision avoidance, etc.) are a good way to supplement the human and an extra step to avoid accident.
(Saddly, some humans treat them as "excuse to completely shut of the brain and try dozing as mush as possible").
It would be nice if things like that could be turned off when not needed.
Again a UX / UI problem : shutting it off should be an easy setting, at least in the menu on the infotainment center.
(Or a small button on the dash board as most advanced feature).
But beware, I'm sure that some US insurance companies are going to jack up price if they detect shutting down security features)
- add a forward facing LIDAR and or 3d-pair of stereo camera (instead of 2d), to supplement the current radar and 2d camera.
This would help the car disambiguate between a truck just in front, and a highway sign much further in the same direction - both could look similar to the current set of sensors)
- add backward facing cameras under the rear-view mirror :
this would help the car change lane safely.
Means that it could cover the scenario "user doesn't touch the wheel for the past 30min despite alarms" => "user has probably passed out / is unconscious / etc." => "telsa should automatically pull to the side" => "means must be able to change lanes until side is reached"
(The car should also automatically call emergency services, and should blink and honk to attract attention)
* Why didn't the car slow down if you have your hands off the wheel for more then 5+ minutes?
slowing down brings a slight risk of getting rear-ended, specially in the middle of other wise fluid traffic.
that's why I suspect that the engineers at Tesla erred on the side of not stopping.
* Why didn't the car's sensor detect the impending crash?
Tesla in particular lack LIDARs and/or 3D-pair of stereo video camera.
They only have a forward facing 2D video camera and a radar.
These might get slightly confused by distance and size and might confuse the truck with a street sign much further.
(Highway signs are rather reflective and might seem closer on the radar that they actually are.
A truck - i.e.: a big close signal - could thus be confused with artifacts caused by a highway sign - the car might think that it could be looking closer than it is, even if actually the radar was right and the truck is indeed closer)
(A 2D camera would be poor at judging distances).
(On the other hand, because they have accurate Z coordinate, stereo cameras and LIDARs could more reliabily confirm that this is indeed a closer object (a truck right in front of the car) than expected).
* Why didn't the car pull over the side of the road after 15 minutes of hands free driving?
Sensors/safety again.
Tesla only uses ultra-sound sonars (souped up equivalent of parking assistance) to check nearby lanes for free space to change lane into.
Backward facing camera - as used in some other cars - would be better at spotting a car coming from far behind and avoid cutting it of.
With its current set of sensors, a Tesla can reliably change lane safely.
If the car is not smart enough to see a truck by itself,
This may also not have been a problem of smart, but a problem of sensors not registering the truck in this peculiar situation.
(e.g.: unlike other cars, Teslas only have forward facing radars and 2D video camera, no LIDARs, nor 3D-pair of stereo cameras.)
it may not be smart enough to find a safe space to pull over and shut itself off.
It's definitely not as much a problem of smart as it is of sensors :
whereas some other cars feature read-facing video cameras under the side mirrors (that can see if there's a car in the next lane much further back),
Teslas are among the car that exclusively rely on their ultra-sound sonars (basically souped up parking assistance with a bit improved range) which are much shorter-range. They can reliably tell you when a car is in the next lane or if there's space right next to the Tesla, they can't see if there's a car coming from behind in the lane.
With its current set of sensors, Tesla definitely can't change lane without risking to cut someone of.
That's part of the reasons why the driver needs to signal his request by using the blinker (driver checks blind sport and behind on the lane, and only then pushes the blinker lever).
If that's a requirement, why didn't the car just pull over and shut off?
The main reason is that in this exact type of car (Tesla Model S) pulling over - specifically, the "change lane" part of it - can't be automated 100% yet.
The car sense cars in neighboring lanes (BLIS - Blind Sport Information System) by using its ultra-sound sonars. Basically a type of souped up parking assistance with a little bit more range.
This is good at detecting whether the space right next to the Tesla is free, this isn't that good at detecting incoming cars in the lane.
(i.e.: if the Tesla only trusts its sonars as currently done, there's a risk that it cuts of someone)
That why currently the car will never initiate a lane change on its own, the driver is required to action the blinker to initiate a lane change.
(Compare with camera-based BLIS, like the past couple of year in Volvos. The camera has much longer range and can actually spot a car incoming from far behind. These Volvos don't change lanes by themeselves, but at least are able to bring to attention to the driver cars not only in the blind spot but even further back in the lane)
Also, I suspect that the machine learning / deep net in Tesla doesn't have a notion/concept that the shoulder lane is something different and special.
(i.e.: I mean it can't even *target* the shoulder lane as a destination to change lane into, because it won't necessarily recognize it as such).
Note that none of the above is a hard obstacle :
- as mentioned, camera based BLIS - that can look much further back and realise if there's incoming traffic - do exist and have been in circulation for a couple of year. And I know that at some point in time, Tesla was toying with the idea of camera at side mirrors (except that they wanted to completely drop the side mirror and only use cameras/virtual mirrors - This would have been much more difficult to get past regulations).
- training the system to recognize shoulder lanes shouldn't be that much complicated.
- it's probably an emergency situation (if the driver hasn't been able to touch the wheel for the past 30 minutes, he might not even be conscious). It would be acceptable for the car to blink and honk to notify that something is wrong so other driver can see and take evasive manoeuvre.
- Bonus point if the car can automatically drop a triangle 100m before stopping on the shoulder lane for safety (or whatever is the required distance in your jurisdition). And Elon Musk is the kind of geek who'll pay special attention to these kind of small details (see the uncanny automatic charging snake).
sing my own DNS gave me also access to The Pirate Bay
An alternative would be to use TOR, and use PirateBay's .onion address : http://uj3wazyk5u4hnvtk.onion/