The thing is, on the platform usually targetted by malware written in Bash script - like GNU/Linux systems - "Administrative access" isn't something trivial. It's rare that regular users run everyday tasks as "root".
You needed Microsoft to bring the GNU userspace and "linux ABI" to their NT kernel for suddenly things to run sour.
----
And joke aside about NT user running as "administrators" 24/24 hours and 7/7 days, this was bound to happen : In order to not have ridiculous performance (as opposed to solution like Cygwin which is a user-land translation layer that must leverage whatever meagre functions the Win32 API offers to provide its POSIX compatibility) "WSL" takes a lot of shortcuts when providing "linux API" ("picothreads" was a widely advertised capability introduced inside the NT kernel and leveraged by WSL so it could provide posix-threads to linux ELFs that doesn't suck as much at multi-threading/multi-processing as the rest of Windows). Some of these "not that much secure" performance shortcuts was bound to blow back on WSL users' face.
Again, remember : WSL is only exclusively to be used in testing/development environment (so that devs can directly test linux binary ELFs without needing, e.g., a full blown Ubuntu VirtaulBOX VM image). WSL is currently NOT to be used in production (keep it away from production servers - obviously those will be running some GNU/Linux flavor), otherwise such blow-in-your-face accident could happen on critical machines with critical data.
If anything remotely like the way it is handled in RPM repositories, at least the identity of the author is different. urlib and urllib would be submitted by 2 different authors. menaning that pypi would either "installing urllib, signed by 0xb00b1e5 'original@author.com' ? [Y/N]" or "installing urllib, signed by 0xdeadbeef 'evil@hacker.com' ? [Y/N] " (in a way, that is something that already is happening with GitHub repository as the author's nickname or the company's/project names are part of the URL)
it's not much, but if the user has missed a single letter in the name (has happened to me, pip refusing to install 'thony' as that one didn't exist, unlike 'thonny'), maybe they are better at spotting a whole different author identity (or maybe not. Maybe most python users are that much careless) (with their mind so busy paying attention to blank spaces and tabs)
Also, I don't have a clear idea of the python community publishing modules on pypi (I'm more of a Perl guy than Python guy, I mostly dabbled into pypi while helping software deployment on my university's HPC) but if the most common non-core modules are developed by a few known authors (e.g.: key 0xb00b1e5 'original@author.com' has been trusted multiple time already and the user has added it to his whitelist because he needs a lot modules) then pip suddenly pausing to ask confirmation for a new unkown, non-whitelisted key (e.g.: key 0xdeadbeef 'evil@hacker.com' seen for the first time) is sure to suddenly stand out as a sore thumb.
(as currently happens with 3rd party RPM repositories, e.g.: SUSE's Open Build System).
Yet another way to use cryptography, would be to take notice from GPG's web of trust, or from PKI's root certificates : we could also imagine authorities that sign several uploader's keys as trusted.
i.e.: one could imagine a group, called "Python Booster" who don't release modules themselves, but sign the keys of module that they consider trusted to be in a "Python Booster Module Collection". (and optionnally "pip install pbmc" launching a setup.py that installs the whole distribution). (So if you need a module that is trusted by one of these "module collections" you subscribe to, you'd be a bit better covered).
In practice, that is already the end result of not installing random module with "pip" but to use the RPMs provided by your trusted distro, or by a trusted 3rd party repository.
The only marginal finger-pointing possible here is at PyPl for allowing typo squating, however even that is marginal.
In addition of the cryptographic solution, it could also be useful that pypi.org refuse to automatically open new modules repositories for modules whose name isn't beyond a certain levenstein distance of other name present, without a human reviewing the reason behind close names.
That won't prevent you from making a "LibreBla" fork of an "OpenBlah" project, but that would reduce the easy to confuse clones (you'd need to explain to a human operator that "bla2" is a maintained legacy fork of an older pre-API-change version of "bla". Unlike the current mess on pypi (and on CPAN for that matter).
As soon as it feels it has enough power to do so, it will pervert the open source community around Linux.
But the peculiarity around "Linux", is that it is Copyleft. Not just any random thing where the source happen to be visible (as often the corporate friendly "open-source" buzzword is slapped around), but it on purpose follows the copyleft notions of the GPL.
Basically, this license gives you the right to do whatever you want with it BUT if you decide to give to someone else YOU MUST ABSOLUTELY provide with it the same freedom "to do whatever" that you receive it in the first.
And this not only concerns the Linux kernel itself, but a huge chunk of the GNU userspace that is usually found coupled with it on the server space that microsoft is targetting.
Meaning it nearly impossible to make your "very own private variant" of it, every modification of the Linux kernel, is still Linux. They cannot "extend" it in the way the standard Microsoft EEE strategy works. Microsoft managed to make their very own flavor of MS Java, Visual J++ and J# to Sun's Java. Microsoft managed to make IE - a browser bringing wonderful "extensions" to HTML such as "ActiveX" binary/i386/Windows-only OLE/COM objects But Microsoft cannot achieve the same with the Linux kernel or most of the GPLed userland. By virtue of how GPL works, any fork of the linux kernel (e.g.: as currently happens in the embed world, specially with Android by chipset manufacturers) MUST also follow the GPL. Meaning if you give/sell away this forked kernel YOU MUST publish your modifications too. (Ask any of the few manufacturer who forgot to publish their modifications - most end-up being forced to comply, a couple got into legal trouble in court for refusing to do so). That's one of the reason that drove Google to use a completely different userspace for Android (they needed their own Bionic C-lib if they wanted to switch away grom glibc's GPL).
So in the end: - either the "microsoft Linux" implements a few useful features that people actually want, and kernel developers would be legally allowed to re-integrate them into the main upstream linux (that's exactly what is happening with Hyper-V and the various other microsoft virtualisation extensions that are useful to get VMs running on Microsoft's Azure cloud). - or nobody gives a damn about these extensions and Microsoft fails to gain any traction with their variant. There is simply no way to accomplish the "Extend, Estinguish" sequence on copyleft software. That's actually part of the core reasons behind RMS' reasoning, and why he's still battling against various loopholes that some manufacturer try to find ("tivoization" - actually publishing the code, but managing to prevent you from using it on the device due to code-signing shenningans) "UEFI Secure Boot" on ARM hardware (where, unlike PC Intel/AMD hardware, there's nothing in the UEFI standard mandating that the end-user could put their own keys) is the latest such failed attempt (the Linux echo-system managed to get shims signed by the official Microsoft key).
There won't be incompatible "Microsoft Visual Linux.NET" that kills the ecosystem. Either vanilla Linux eventually re-uptakes the modifications, or nobody gives a shit. GPL prevents it legally.
There's a reason why Ballmer called copyleft a "cancer".
All the development described here is for the benefit and enhancement of their own products, mainly because in the server space their lunch is being eaten by Linux.
And the problem is that, by now for Microsoft, trying to retake the server-space (specially on the cloud, in high-performance computing, etc.) is an already lost battle. Unlike their former turf (corporate servers, desktops, gaming machines) Microsoft is completely irrelevant in that field.
The same in the embed market (you keep hearing here and there a few chipset that get Windows 10 support. But nearly every single project you hear from runs
He's intentionally misinterpreting the "In January 2018" part of the title to mean "only during January 2018, and not outside of that month"
Is he ? really ?
Or maybe he's starting to get really distrustful of Google and ready that in February 2018, we'll get huge announcement that "google has decided to back-pedal on their 'no-autoplay' feature following important back-lash" (trans.: the advertisers were unhappy, and that might have jeopardized our shareholders plan to buy yet another Porsche).
Given that apart from a few android license (for the "full official google experience" beyond AOSP), and the recently introduced You Tube Red, and micro drop in the bucket of selling apps/movies/music/e-books on Google Play, they are mostly running on advertisers' money, that not entirely impossible~
The USB-C charging protocol allows the sink and source to negotiate a higher voltage.
Thank you for trying to correct me with what I've litteraly written, after the next line:
Various QuickCharge standards (including USB's Official Power Delivery) work by giving the possibility to the device to ask for a higher voltage (9V or 12V or even higher - thus lower current for a given wattage)
The protocol is USB Power Delivery (USB-PD) (which supersedes previous protocols like USB Battery Charging Specification) - this is the one that introduces higher voltage negociations, like we've both written.
Also note that USB-PD is only ONE such protocol - it's merely the latest official USB standardization. Various other vendors protocols such as Qualcom's QuickCharge 2.0 and up also feature the same feat (only QuickCharge 4.0 is officially compatible with USB-PD, though I've read about smartphones (by HTC) running on chipsets (like 625) that are normally designed for QuickCharge 3.0 that can operate with USB-PD - maybe a redesign from the manufacturer, of maybe simple some firmware modifications).
All this isn't linked to any specific type of connector. Both Qualcom's QuickCharge 2.0 and USB-PD can be implemented with any type of USB A and B connector. (e.g.: Logitech' UE MegaBoom does it over a plain USB-A to micro-USB connection)
This is one of the things that makes USB-C charging better.
Again, this is one of the things that make USB-PD charging better. It might be implemented in a micro-USB device. And your USB-C device might only implement strictly USB 2.0
P=V*V/R so the losses in the wire are reduced by 16X, without changing the wire.
Okay, yeah I used another representation of the same law, P = RI^2 (You can convert one from the other simply by using V=RI):
thermal loss is only proportional to square of current.
Than standard USB wall-wart's max 5V 2A ? (Meaning that indeed the smartphone manages to ask for 12V 2A using USB Power Delivery protocole - or any other QuickCharge variant)
Or faster than the standard 5V 1A that was packaged with it ? (Meaning that the smartphone was simply using the standard max 5V 2A that the packaged wall wart couldn't achieve and that the 29W power supply could deliver by default if the device didn't engage in any USB-PD negociations).
There is another reason why Apple isn't including a charger with the iPhone 8 and X : Watts. And number of different parts.
Usually, the charging limits of a lithium battery are 1C : e.g.: you can charge a 3'000 mAh battery (like that in iPhone 7 plus) at 3A max. (that's why usually you can at most charge 50% of capacity in 30min)
Standard tablet charger only go up to 2A, and I think apples "thin as an euro-plug" phone charger are 1A only. (One of the limiting factor is the way too thin copper wires in the USB cable. Too much resistance for such moderately high current.) (reminder: thermal loss is only proportional to square of current. It doesn't give a shit about voltage. Standard home appliances cables are usually rated at 10A max).
Various QuickCharge standards (including USB's Official Power Delivery) work by giving the possibility to the device to ask for a higher voltage (9V or 12V or even higher - thus lower current for a given wattage) That means that the only way to achieve quick charging with iPhone 8 and X is a newer different USB charger that does support USB-PD's higher voltage and wattage.
And now you see where the thing is going : - that in theory would require Apple to introduce yet another specific "iphone quick-charger", in addition to the 29W to 87W ones (e.g.: something still in the same "europlug" form factor, but with 15W). - that's yet another different part to take care of (Apple is a company that tries to keep the number of parts low) - that's openning problem of clueless users who try to charge their high-range USB-C equipped Apple laptop, "because the iPhone charger is USB-C too !" and not understanding why a meagre 15W micro wall-wart can't charge a >85W consuming laptop - (or worse, the 15W wall wart blows under the load due to sub-optimal protection circuitry) - alternatively they need to pack at least the 29W variant together with the phone. But! -...but such giant chargers aren't popular with smartphone anymore. (it's not first gen iPod and iPhone era anymore). -...but the fact that it is bundled "free" with an iPhone suddenly decrease the perceived "premium" value of the device that enabled Apple for over-charge at >30$
In short, it's a nightmare. And not that many user need to push 1500mAh worth of battery within first 30 minutes anyway. So...
Let's just neglect to mention the thing altogether. Continue to pack the phone with a wall wart that is useful for most consumer. Let power the users (who are in the know) to play with their USB-PD chargers on their own if they want to.
(Best part: now if some iPhone battery blows up, Apple can blame the user of playing with charger which weren't the official packaged-in)
except when he scratched Kylo Ren's side with the glancing shot.
I interpreted the scene differently : - Chewie was not aiming to kill (couldn't bring himself to kill his "bestfriend's son almost godson") - Kylo is so badass he withstood the (non-letalla aimed) explosive ammo without even flintching (but still left him wounded enough to be at disadvantage against the young untrained wannabe Jedi)
But yeah, I see your point : - Chewie chose an ammo not to kill (couldn't bring himself to exploding his... blabla) - Kylo got a minor scratch from a glancing regular ammo (and somehow, even if he's not finished his own training, managed to get his ass whooped by an opponent even less well-trained than him)
the designer describes the whole thing to the engineers at Google without an NDA in place. I'm pretty sure Google ends up with the patent in the end.
Sorry, I don't bother to follow TV/web series enough to get the exact reference (I stop at recognizing the "middle-out compression" part). I suspect it's about an episode show the typical IP blunder of revealing some not-yet-protected company secret.
In the real world though, the NDA is completely superfluous in this situation. The designer (Duda) here is describing something for which he has published articles nearly a decade before. NDA - Non Disclosure Agreement - are exactly what it says on the tin : pacts asking the other party not to reveal any of the secret information. That would be hard to do when there are no secrets because the whole thing has been in public knowledge for a long time.
That would be like asking for an NDA before discussion the wheel or fire. And then pointing fingers at the guy who forgot the NDA, instead of point fingers to Google for trying to patent an already known thing.
Which is exactly what Duda is currently doing : pointing fingers at Google for trying to patent "as new" something which in fact has been published 10 years ago. And Duda won : according to the summary the patent WAS NOT granted due to not being original.
UTF-8 is an encoding scheme. As in "how should I represent Unicode codepoints in a bitstream" (in UTF-8's case : ASCII is coded as is, codepoints > 128 are encoded with sequences of multiple bytes with their high bit on). (Windows's UCS-2 is a different one, in that case it's : write everything as 16bit integers, and fuck everything above codepoint 65535/0xFFFF)
Unicode is a unified collection of codepoints. - some codepoint represent glyph on the screen (more or less letters and similar symbols) - some codepoint represent emojis (color icons) then there are other codepoint that represent inscruction about how to draw the above two : - there are instruction to change the colors of emojis (there's a special "skin color" code to use natural-looking skin color on smileys instead of the cartoonish yellow) - there are instruction about which direction the text should flow - there are instruction about how to combine other glyphs together... - a pair of code points (FFFE and FEFF - BOM "Byte Order Mark") control the encoding itself and how you should decode the subsequent bit stream.
I was referring to these last categories of codepoints when I was saying that if you squint in a way at it, it starts to look like a some sort of formatting language.
By using these categories, you can really screw and destroy the layout of a HTML page.
Some near-infrared bad could travel through the plastic used by cheap sunglasses, and the eyes could be a little bit more visible to the camera than the typical RGB visible domain.
Also, even if you don't see the eyes, you have a general estimate of the driver attention by looking at which direction the driver's face is facing. (i.e.: chance are low that the driver will spent watching a hour-long Harry Potter movie while glancing sideways. - for comfort the driver will eventually turn the head toward the DVD player, at which moment the car can determine that the driver isn't paying attention to the road anymore)
Rey not only duels Darth Teenage Angst, she beats him, in a single movie.
(First, small disclamer : I actually like the Darth Teenage Angst in this movie. I find that Adam driver's Kylo Ren would have been a much better Episode III teenage Anakin that what we ended up with)
The duel outcome isn't what disturbed me the most. When you look at the details : - Chewbacca has upgraded his weapon at some point of time between the 2 trilogies. - This new version is so much better that even Han Solo is impressed when we borrows it, even if he's used to shoot at things (first). - (I think we might see a few storm trooper recoil from the energy blast a some point in the movie. Though I am not sure about this). - THIS is the weapon with which Kylo Ren is shot (moments after dispatching Han Solo).
So at the moment they are duelling, Kylo Ren is badly shot with an extremely powerful weapon, is probably a little bit disturbed by the fact he went dark to the point of killing his own father, in addition to being a general mentally unbalanced ball of nerves. (And in his mental weirdness, he keeps punching his own wound).
The duel was actually heavily one sided-stacked in favor of Rey. But still even in this state, despite the above handicap, Kylo manages to wound Finn, and even if defeated manages to escape alive and with no much additional harm (beyond what he suffered from Chewbacca).
Also Rey, being more or less a street urchin surviving on her own should have some decent self-defense capabilities (with any random weapon she manages to grab) if she's survived successfully to her age.
(In the same way, her knowledge about ship should also not be a surprise given her day occupation - her being an ACE pilot is what I found stretching it too much.)
(Similarly - I can understand that the writers want to have her as a powerful natural force users who start to discover her latent power - it is her being able to *control* the force so fast without any formal training that prevents my suspension of disbelief - I would have expected a more haphazard random stream of accidental force uses, a bit reminiscent of X-Men mutants discovering their powers).
On the other hand Luke is a farm boy with a hobby of flying ship. - One would expect him to be good at flying and shooting thing with a gun. - One would not expect him to be able to successfully use other weapons that aren't found on a farm.
There was no reason to use the "Turing Complete" qualifier. You could have just said it isn't a language.
Modern Unicode is becoming so insanely complex, that it actually starts to border on a formatting language (like HTML and other markup language). Just not a turing-complete one (i.e.: if you squint at it, it's closer to become HTML soon. Not Javascript).
- prefere plain text when available - strip "advanced" formating (i.e.: remote bullshit and scripted crap) unless I whist list the correspondent.
The totally blank e-mail still happens (because, e.g. - the e-mail is entirely a remotely hosted picture - like a flyer). But these e-mail never come from my usual correspondant any way.(*) I don't even need to white-list them.
Nearly always they are some spam or other form of unsolicited mailing. So I don't bother even paying attention.
If you're not even putting enough effort to make your mail decently readable, you won't be spending any attention to you.
If that was some "important bill" and you subsequently try to sue me for not paying : - you're a shitty company I won't deal any business with anymore, and won't even blink about it, there are tons of decent companies with whom to do business. - be prepared to have your practice contested through consumer organisation. Welcome to Europe mother fucker.
----
even the HTML rich-editors used by my clueless friends : - can output an alternative plain text form - is simple enough that it can be displayed in "safe mode".
Yes, Postscript is a turing complete language (you can even write a ray tracer in it).
BUT
postscript can only output to the document (or screen), and can't read input from the internet.
Thus, as long as there isn't a critical bug in the displaying software... - (Adobe Acrobat reader, I'm looking at you right now !), ...and as long as there isn't some asinine extra feature implemented... - (you can bet that someone at microsoft on the outlook team would dream of a document viewer that can automatically extract attachments embed inside PDF files and execute them) ...there isn't an actual risk in opening random PDF files, except that some might take a few hours to render.
(And other can generate 1000 - worth of pages on the printer with only a few lines of code, if you're so stupid to send a raw post-script to the printer without even looking at it).
Unicode is extremely complex, and although it's not a turing-complete language, it can already be abused a lot to pretty much fuck up any layout.
(e.g.: When Slashdot didn't block them in the subject line, it was possible to abuse "text direction" marker to actually put arbitrary text on the right side of the subject. I.e.: write a troll flamepost with a title that could add "(Score: 5, Insightful)" right on the place where the actual scoring would normally go)
(e.g.: Zalgo text, where diactirics (extra accents on characters) and other such decoration is progressively used on text to make a complete unreadable mess of it)
etc.
Lots of potential abuse, so that's why/. which is primarily a english speaking site will severly limit unicode use (and English itself is a language that can possibly be written by using exclusively ASCII - e.g.: by ignoring the rare word where characters could be optionally accented).
The whole premise when smart watches where successfully brought back to the spotlight by Pebble, was to have electronics as power-economic as possible. Pebble had eInk among the considered technologies to make it cheaper. Tethering to a phone was actually a *selling point* - leave as much works as possible to the phone, and use the smartwatch only as an interface in order to make the most out of its tiny power budget. You ended-up with watches which could go a week or more between charges. (and currently you find smart watches which try to have even lower power requirement, such small fraction of watts that thermoelectric effect from the wearer is a valid method to boost battery life).
Then the big companies noticed the popularity and the tremendous success of pebble in crowd-funding, and panicked that they might miss a slice of the pie. So they rushed in with what they have : ultra-brilliant marketing department able to sell anything by making it seem desirable, and boring soulless engineering department trained to cram bullet points on a list. And you end up with products which are basically not smartwatches - i.e.: extensions giving a few useful extra functionnality on an otherwise nice watch - but instead are diminutive crippled phones. Things that try to be phones but with catastrophic performance.
It's "iPhone 1" and it's horrendous battery life all over again. Apple Watch 3 will end up being a crappy iPhone strapped to you wrist, not a brillant device revolution that Apple is desperately in need to stay relevant.
The sad part is that Pebble started an interesting trend of low-power device that can hold a week, but the whole concept of smartwatches seem to be dying due to over flooding the market with crappy power-hungry stuff.
I would think they would have had better impact and a better impression of credibility if they committed to making 2-3 models successfully. Do the others once you have proven yourself.
The already have, both... : - ultra small and low cost VW UP! - the iconic VW Golf are available as electric variant as VW-eUP! and VW e-Golf.
But you probably haven't heard much about them because VW only taugh about putting marketing money and massively advertising them in the wake of the diesel scandal.
Another problem -- at least for alert observing engineers -- is that both Musk and Nissan have shown that in order to make a successful EV one of the best practices is to design it as an EV from scratch. VW's announcement makes it sound like they are going to squeeze batteries and electric motors into their existing ICE designs.
(And you can add Renault to the list, they share their EV R&D with Nissan - they developped the "Zéro émission" platform together).
Yup, the current 2 above mentionned vehicles seem to me a little bit like "EV motor slapped on classical ICE cars" experiment quickly done to probe the market to see if there's interest. (Which then were subsequently re-advertised as serious EV business goals after the scandal) But I have to admit that I haven't much experience driving these.
Citroën C-zero also seems in my own driving experience like this - with a battery bank stuck in the trunk of an otherwise re-purposed ICE car. (Which is weird, given that Citroën has nearly 4 decades of successful electric utility vehicle used among other by the french post on their delivery routes).
This as opposed to Renault Zoé which are modern Twingo design bolted onto the specially designed "Zéro émission" platform that they designed together with Nissan for this special purpose.
Smart is another European brand that reuses part of Tesla's battery platform for their electric variant. (Haven't driven one though - only seen them around).
(Both these last have batteries under the car like other "from the ground up" EV designs. Not batteries occupying whatever space happened to be free in the converted ICE such as the trunk as in the former).
Yeah you can make it work somewhat but it doesn't sound like you will get a superior product that way. In effect they have announced that they are going to strive for mediocrity.
...or that they want to be the quickest to market.
See how long it took Nissan and Renault for their "Zéro émission" platform.
See how long it is still taking as of today for Tesla who are still in the process of extending their platforms range to cover Model 3.
Designing from the gound up take time. A lot. And costs. Again a lot. During which time you'll still have to sell the old cars.
VW's old cars got a horrid reputation after the scandal (in practice they're not the worst. There are other offenders cheating even more. VW just happen to be the one who didn't pay enough brib... huh.. sorry "who happened to get caugh by chance").
They need to move fast and cheap. (They've always have been about producing cheap cars fast, all the way back to the first beetles and minivan) Repurposing ICE cars is a quick cheap solution that can work RIGHT NOW.
Then they can take time to specially built new platforms at a later time (as the upcoming 2018 electric rebirth of the VW minivan - which seem to be built on a newer platform)
That also explains clearly the Citroën C-zero : cheap, fast to produce entry-level car now.
Not with this hotels' Wifi, apparently. I have the latest version of the big three browsers.
that's strange : I actually had the "there is apparently a log-in screen" pop-bar just the day before....
but not being able to disable the security measures just to click through a login screen is bad design on the web browsers' part.
On the "bad certificate" page in firefox, you can still click to get the details, then add an exception and make it temporary (just until you've logged in).
Disabling the security is another possible route instead of the pop-bar (one which was available long before the pop-bar itself).
Which you now have to fight Google in court to prove if they got the patent that you should have applied for.
*if* they get the patent... Which exactly why Jarek Duda is writing to the patent office to inform them of the prior art. Which is exactly what happened afterward.
Citing TFS on/.:
The researcher already filed a complaint, to which WIPO ISA responded by calling out Google for not coming up with "an inventive contribution over the prior art, because it is no more than a straightforward application of known coding algorithms.
Prior Art won. Thanks to publications of Jarek Duda (see: arxiv), and provable discussion with Google (i.e.: disclosure) that predate the patent filing.
Just to nitpick: tANS (table Assymetric Numeral Systems) such as the FSE (Finite State Entropy) implementation by Yann Collet, at the hearth of Zstd compressor (now Facebook's) are NOT 3-30x better than other modern post-Huffman entropy encoder, such as binary-arithmetic encoding or range-encoding. They are much *FASTER*. By lots.
They all boil down to the same logic: do not use a fixed code-word book like Huffman (which is thus limited to integer number of bits).
but try to get as close as Shanon's theory predict the necessary bits, by subdividing number space.
range encoding works by dividing an arbitrary big number (usually an extremely long binary number). For each symbol, you split this range in sub-ranges. More frequent symbol get a wider sub-range, more rarer symbol get a narrower one. You pick the sub-range corresponding to the next symbol in the text you need to encode. Then you keep the same work by subdividing *THAT* sub-range by the probabilities of symbol occuring in the position after that. - Encoding relies a lot on multiplications (there isn't such a thing as a direct multiplication in transistors. Instead you implement it in microcode by combining shifting and adding. modern CPU have big shift-adders units, so they can manage in chunks of 64bits - on modern Intel it's a few cycles delay, 1 more if you want the upper 64bits of a 128bits product). - Decoding relies on division (rules of three to "zoom" into the subranges), and division are fucking slow (again no such things as "division" with transistors. Instead you implement it in microcode, and most modern CPU tend to do it bit-by-bit meaning it's fucking slow. - on modern Intel it's dozens of cycles delay). This thing was published in 1979. (And thus isn't patentable) It's provable that it approaches arbitrarily close the Shanon limit. (all the symbols in the stream occupy a total of bits that is close the invert log2 of their respective frequencies).
Arithmetic Coding is a cousin technique patented more or less in the same era. In can be seen as a special sub-case of range-encoding where the range is [0;1] and you subdivide it in fraction. It's most often implemented as binary arithmetic encoding. Input symbol are converted into a bit stream. Then for each bit, the fraction is divided in two half. e.g.: if each bit has a 50:50 chance, the [0;1] is subdivided at 0.5 You chose the range under or above this mid-point depending if the bit is 0 or 1 and move forward to the next bit and sudivide the fraction based on the next probability (e.g.: mid point at 0.25). Given that there are only 2 symbols, and therefore only a mid-point fraction to keep track of, its implementation is a little bit simpler to follow. But because this works on *every single bit* of the input stream, you can guess it's either slow (on CPU - hence CABAC versus CAVLC in H264 videos) or require high-frequency on hardware implementation. As it is basically a variation of Range Encoding it can achieve similar arbitrarily close to optimum encoding.
Then come Mr. Duda with his ANS. They are basically range encoding turned on its head - to understand you must basically look at range encoding's bit the other way around. - Range encoding works by subdividing an arbitrarily big number. ANS work by build a progressively bigger number. - Range encoder usually works by writing out the most significant (high bits) away and then shift the working values. - ANS works by considering the least significant bit (the low part).
And here comes the real magic: - With range-entropy: if you have 2 symbols with 50:50 chances, you subdivide the range in 2 halfs. With a different probability you still end up with 2 adjacent sub-ranges of different lenght. - With ANS, because you figuratively "reverse the bits" : if you have 2 symbols with 50:50 chance, you'll find them alternating in
Slashdot Mirror
The thing is, on the platform usually targetted by malware written in Bash script - like GNU/Linux systems - "Administrative access" isn't something trivial.
It's rare that regular users run everyday tasks as "root".
You needed Microsoft to bring the GNU userspace and "linux ABI" to their NT kernel for suddenly things to run sour.
----
And joke aside about NT user running as "administrators" 24/24 hours and 7/7 days, this was bound to happen :
In order to not have ridiculous performance (as opposed to solution like Cygwin which is a user-land translation layer that must leverage whatever meagre functions the Win32 API offers to provide its POSIX compatibility) "WSL" takes a lot of shortcuts when providing "linux API" ("picothreads" was a widely advertised capability introduced inside the NT kernel and leveraged by WSL so it could provide posix-threads to linux ELFs that doesn't suck as much at multi-threading/multi-processing as the rest of Windows).
Some of these "not that much secure" performance shortcuts was bound to blow back on WSL users' face.
Again, remember : WSL is only exclusively to be used in testing/development environment (so that devs can directly test linux binary ELFs without needing, e.g., a full blown Ubuntu VirtaulBOX VM image).
WSL is currently NOT to be used in production (keep it away from production servers - obviously those will be running some GNU/Linux flavor), otherwise such blow-in-your-face accident could happen on critical machines with critical data.
What the hell would that change?
If anything remotely like the way it is handled in RPM repositories, at least the identity of the author is different.
urlib and urllib would be submitted by 2 different authors.
menaning that pypi would either "installing urllib, signed by 0xb00b1e5 'original@author.com' ? [Y/N]" or
"installing urllib, signed by 0xdeadbeef 'evil@hacker.com' ? [Y/N] "
(in a way, that is something that already is happening with GitHub repository as the author's nickname or the company's/project names are part of the URL)
it's not much, but if the user has missed a single letter in the name (has happened to me, pip refusing to install 'thony' as that one didn't exist, unlike 'thonny'),
maybe they are better at spotting a whole different author identity
(or maybe not. Maybe most python users are that much careless)
(with their mind so busy paying attention to blank spaces and tabs)
Also, I don't have a clear idea of the python community publishing modules on pypi (I'm more of a Perl guy than Python guy, I mostly dabbled into pypi while helping software deployment on my university's HPC) but if the most common non-core modules are developed by a few known authors (e.g.: key 0xb00b1e5 'original@author.com' has been trusted multiple time already and the user has added it to his whitelist because he needs a lot modules) then pip suddenly pausing to ask confirmation for a new unkown, non-whitelisted key (e.g.: key 0xdeadbeef 'evil@hacker.com' seen for the first time) is sure to suddenly stand out as a sore thumb.
(as currently happens with 3rd party RPM repositories, e.g.: SUSE's Open Build System).
Yet another way to use cryptography, would be to take notice from GPG's web of trust, or from PKI's root certificates :
we could also imagine authorities that sign several uploader's keys as trusted.
i.e.: one could imagine a group, called "Python Booster" who don't release modules themselves, but sign the keys of module that they consider trusted to be in a "Python Booster Module Collection". (and optionnally "pip install pbmc" launching a setup.py that installs the whole distribution).
(So if you need a module that is trusted by one of these "module collections" you subscribe to, you'd be a bit better covered).
In practice, that is already the end result of not installing random module with "pip" but to use the RPMs provided by your trusted distro, or by a trusted 3rd party repository.
The only marginal finger-pointing possible here is at PyPl for allowing typo squating, however even that is marginal.
In addition of the cryptographic solution,
it could also be useful that pypi.org refuse to automatically open new modules repositories for modules whose name isn't beyond a certain levenstein distance of other name present, without a human reviewing the reason behind close names.
That won't prevent you from making a "LibreBla" fork of an "OpenBlah" project, but that would reduce the easy to confuse clones (you'd need to explain to a human operator that "bla2" is a maintained legacy fork of an older pre-API-change version of "bla".
Unlike the current mess on pypi (and on CPAN for that matter).
As soon as it feels it has enough power to do so, it will pervert the open source community around Linux.
But the peculiarity around "Linux", is that it is Copyleft. Not just any random thing where the source happen to be visible (as often the corporate friendly "open-source" buzzword is slapped around), but it on purpose follows the copyleft notions of the GPL.
Basically, this license gives you the right to do whatever you want with it BUT if you decide to give to someone else YOU MUST ABSOLUTELY provide with it the same freedom "to do whatever" that you receive it in the first.
And this not only concerns the Linux kernel itself, but a huge chunk of the GNU userspace that is usually found coupled with it on the server space that microsoft is targetting.
Meaning it nearly impossible to make your "very own private variant" of it, every modification of the Linux kernel, is still Linux.
They cannot "extend" it in the way the standard Microsoft EEE strategy works.
Microsoft managed to make their very own flavor of MS Java, Visual J++ and J# to Sun's Java.
Microsoft managed to make IE - a browser bringing wonderful "extensions" to HTML such as "ActiveX" binary/i386/Windows-only OLE/COM objects
But Microsoft cannot achieve the same with the Linux kernel or most of the GPLed userland.
By virtue of how GPL works, any fork of the linux kernel (e.g.: as currently happens in the embed world, specially with Android by chipset manufacturers) MUST also follow the GPL. Meaning if you give/sell away this forked kernel YOU MUST publish your modifications too. (Ask any of the few manufacturer who forgot to publish their modifications - most end-up being forced to comply, a couple got into legal trouble in court for refusing to do so).
That's one of the reason that drove Google to use a completely different userspace for Android (they needed their own Bionic C-lib if they wanted to switch away grom glibc's GPL).
So in the end :
- either the "microsoft Linux" implements a few useful features that people actually want, and kernel developers would be legally allowed to re-integrate them into the main upstream linux (that's exactly what is happening with Hyper-V and the various other microsoft virtualisation extensions that are useful to get VMs running on Microsoft's Azure cloud).
- or nobody gives a damn about these extensions and Microsoft fails to gain any traction with their variant.
There is simply no way to accomplish the "Extend, Estinguish" sequence on copyleft software.
That's actually part of the core reasons behind RMS' reasoning, and why he's still battling against various loopholes that some manufacturer try to find ("tivoization" - actually publishing the code, but managing to prevent you from using it on the device due to code-signing shenningans)
"UEFI Secure Boot" on ARM hardware (where, unlike PC Intel/AMD hardware, there's nothing in the UEFI standard mandating that the end-user could put their own keys) is the latest such failed attempt (the Linux echo-system managed to get shims signed by the official Microsoft key).
There won't be incompatible "Microsoft Visual Linux.NET" that kills the ecosystem. Either vanilla Linux eventually re-uptakes the modifications, or nobody gives a shit. GPL prevents it legally.
There's a reason why Ballmer called copyleft a "cancer".
All the development described here is for the benefit and enhancement of their own products, mainly because in the server space their lunch is being eaten by Linux.
And the problem is that, by now for Microsoft, trying to retake the server-space (specially on the cloud, in high-performance computing, etc.) is an already lost battle. Unlike their former turf (corporate servers, desktops, gaming machines) Microsoft is completely irrelevant in that field.
The same in the embed market (you keep hearing here and there a few chipset that get Windows 10 support. But nearly every single project you hear from runs
He's intentionally misinterpreting the "In January 2018" part of the title to mean "only during January 2018, and not outside of that month"
Is he ? really ?
Or maybe he's starting to get really distrustful of Google and ready that in February 2018, we'll get huge announcement that "google has decided to back-pedal on their 'no-autoplay' feature following important back-lash" (trans.: the advertisers were unhappy, and that might have jeopardized our shareholders plan to buy yet another Porsche).
Given that apart from a few android license (for the "full official google experience" beyond AOSP), and the recently introduced You Tube Red, and micro drop in the bucket of selling apps/movies/music/e-books on Google Play, they are mostly running on advertisers' money, that not entirely impossible~
Ok, sold. How do we infect the hot chicks of the planet?
So now, you finally understand how the internet can both at the same time be
- only for porn
- only for kitten
You're witnessing our Machiavellian ploy unfold.
The USB-C charging protocol allows the sink and source to negotiate a higher voltage.
Thank you for trying to correct me with what I've litteraly written, after the next line :
Also note that this is not "USB-C charging protocol". USB-C is merely a connector, used most often for USB 3.1+ but can even be used for USB 2.0.
The protocol is USB Power Delivery (USB-PD) (which supersedes previous protocols like USB Battery Charging Specification) - this is the one that introduces higher voltage negociations, like we've both written.
Also note that USB-PD is only ONE such protocol - it's merely the latest official USB standardization.
Various other vendors protocols such as Qualcom's QuickCharge 2.0 and up also feature the same feat (only QuickCharge 4.0 is officially compatible with USB-PD, though I've read about smartphones (by HTC) running on chipsets (like 625) that are normally designed for QuickCharge 3.0 that can operate with USB-PD - maybe a redesign from the manufacturer, of maybe simple some firmware modifications).
All this isn't linked to any specific type of connector. Both Qualcom's QuickCharge 2.0 and USB-PD can be implemented with any type of USB A and B connector.
(e.g.: Logitech' UE MegaBoom does it over a plain USB-A to micro-USB connection)
This is one of the things that makes USB-C charging better.
Again, this is one of the things that make USB-PD charging better.
It might be implemented in a micro-USB device.
And your USB-C device might only implement strictly USB 2.0
P=V*V/R so the losses in the wire are reduced by 16X, without changing the wire.
Okay, yeah I used another representation of the same law, P = RI^2
(You can convert one from the other simply by using V=RI):
Faster than what ?
Than standard USB wall-wart's max 5V 2A ?
(Meaning that indeed the smartphone manages to ask for 12V 2A using USB Power Delivery protocole - or any other QuickCharge variant)
Or faster than the standard 5V 1A that was packaged with it ?
(Meaning that the smartphone was simply using the standard max 5V 2A that the packaged wall wart couldn't achieve and that the 29W power supply could deliver by default if the device didn't engage in any USB-PD negociations).
There is another reason why Apple isn't including a charger with the iPhone 8 and X : Watts. And number of different parts.
Usually, the charging limits of a lithium battery are 1C :
e.g.: you can charge a 3'000 mAh battery (like that in iPhone 7 plus) at 3A max.
(that's why usually you can at most charge 50% of capacity in 30min)
Standard tablet charger only go up to 2A, and I think apples "thin as an euro-plug" phone charger are 1A only.
(One of the limiting factor is the way too thin copper wires in the USB cable. Too much resistance for such moderately high current.)
(reminder: thermal loss is only proportional to square of current. It doesn't give a shit about voltage. Standard home appliances cables are usually rated at 10A max).
Various QuickCharge standards (including USB's Official Power Delivery) work by giving the possibility to the device to ask for a higher voltage (9V or 12V or even higher - thus lower current for a given wattage)
That means that the only way to achieve quick charging with iPhone 8 and X is a newer different USB charger that does support USB-PD's higher voltage and wattage.
And now you see where the thing is going : ...but such giant chargers aren't popular with smartphone anymore. (it's not first gen iPod and iPhone era anymore). ...but the fact that it is bundled "free" with an iPhone suddenly decrease the perceived "premium" value of the device that enabled Apple for over-charge at >30$
- that in theory would require Apple to introduce yet another specific "iphone quick-charger", in addition to the 29W to 87W ones (e.g.: something still in the same "europlug" form factor, but with 15W).
- that's yet another different part to take care of (Apple is a company that tries to keep the number of parts low)
- that's openning problem of clueless users who try to charge their high-range USB-C equipped Apple laptop, "because the iPhone charger is USB-C too !" and not understanding why a meagre 15W micro wall-wart can't charge a >85W consuming laptop
- (or worse, the 15W wall wart blows under the load due to sub-optimal protection circuitry)
- alternatively they need to pack at least the 29W variant together with the phone. But!
-
-
In short, it's a nightmare.
And not that many user need to push 1500mAh worth of battery within first 30 minutes anyway.
So...
Let's just neglect to mention the thing altogether.
Continue to pack the phone with a wall wart that is useful for most consumer.
Let power the users (who are in the know) to play with their USB-PD chargers on their own if they want to.
(Best part: now if some iPhone battery blows up, Apple can blame the user of playing with charger which weren't the official packaged-in)
except when he scratched Kylo Ren's side with the glancing shot.
I interpreted the scene differently :
- Chewie was not aiming to kill (couldn't bring himself to kill his "bestfriend's son almost godson")
- Kylo is so badass he withstood the (non-letalla aimed) explosive ammo without even flintching (but still left him wounded enough to be at disadvantage against the young untrained wannabe Jedi)
But yeah, I see your point : ... blabla)
- Chewie chose an ammo not to kill (couldn't bring himself to exploding his
- Kylo got a minor scratch from a glancing regular ammo (and somehow, even if he's not finished his own training, managed to get his ass whooped by an opponent even less well-trained than him)
the designer describes the whole thing to the engineers at Google without an NDA in place. I'm pretty sure Google ends up with the patent in the end.
Sorry, I don't bother to follow TV/web series enough to get the exact reference (I stop at recognizing the "middle-out compression" part).
I suspect it's about an episode show the typical IP blunder of revealing some not-yet-protected company secret.
In the real world though, the NDA is completely superfluous in this situation.
The designer (Duda) here is describing something for which he has published articles nearly a decade before.
NDA - Non Disclosure Agreement - are exactly what it says on the tin : pacts asking the other party not to reveal any of the secret information.
That would be hard to do when there are no secrets because the whole thing has been in public knowledge for a long time.
That would be like asking for an NDA before discussion the wheel or fire.
And then pointing fingers at the guy who forgot the NDA, instead of point fingers to Google for trying to patent an already known thing.
Which is exactly what Duda is currently doing : pointing fingers at Google for trying to patent "as new" something which in fact has been published 10 years ago.
And Duda won : according to the summary the patent WAS NOT granted due to not being original.
Unicode is an encoding scheme.
Not quite exactly.
UTF-8 is an encoding scheme. As in "how should I represent Unicode codepoints in a bitstream"
(in UTF-8's case : ASCII is coded as is, codepoints > 128 are encoded with sequences of multiple bytes with their high bit on).
(Windows's UCS-2 is a different one, in that case it's : write everything as 16bit integers, and fuck everything above codepoint 65535/0xFFFF)
Unicode is a unified collection of codepoints.
- some codepoint represent glyph on the screen (more or less letters and similar symbols)
- some codepoint represent emojis (color icons)
then there are other codepoint that represent inscruction about how to draw the above two :
- there are instruction to change the colors of emojis (there's a special "skin color" code to use natural-looking skin color on smileys instead of the cartoonish yellow)
- there are instruction about which direction the text should flow
- there are instruction about how to combine other glyphs together...
- a pair of code points (FFFE and FEFF - BOM "Byte Order Mark") control the encoding itself and how you should decode the subsequent bit stream.
I was referring to these last categories of codepoints when I was saying that if you squint in a way at it, it starts to look like a some sort of formatting language.
By using these categories, you can really screw and destroy the layout of a HTML page.
Meanwhile I've had a European Apple drone try to convince me that my device wasn't covered, because the sales-slip said "Apple Ireland"
If they persist, threaten them to contact your local consumer rights association.
Or directly do so, specially if you're in country with strong such groups (Germany and Switzerland come as an example).
Apple has no legal standing on these claims.
Consumer right groups have lawyers who can sue them for such violations of law.
Some near-infrared bad could travel through the plastic used by cheap sunglasses, and the eyes could be a little bit more visible to the camera than the typical RGB visible domain.
Also, even if you don't see the eyes, you have a general estimate of the driver attention by looking at which direction the driver's face is facing.
(i.e.: chance are low that the driver will spent watching a hour-long Harry Potter movie while glancing sideways. - for comfort the driver will eventually turn the head toward the DVD player, at which moment the car can determine that the driver isn't paying attention to the road anymore)
Rey not only duels Darth Teenage Angst, she beats him, in a single movie.
(First, small disclamer : I actually like the Darth Teenage Angst in this movie. I find that Adam driver's Kylo Ren would have been a much better Episode III teenage Anakin that what we ended up with)
The duel outcome isn't what disturbed me the most.
When you look at the details :
- Chewbacca has upgraded his weapon at some point of time between the 2 trilogies.
- This new version is so much better that even Han Solo is impressed when we borrows it, even if he's used to shoot at things (first).
- (I think we might see a few storm trooper recoil from the energy blast a some point in the movie. Though I am not sure about this).
- THIS is the weapon with which Kylo Ren is shot (moments after dispatching Han Solo).
So at the moment they are duelling, Kylo Ren is badly shot with an extremely powerful weapon, is probably a little bit disturbed by the fact he went dark to the point of killing his own father, in addition to being a general mentally unbalanced ball of nerves.
(And in his mental weirdness, he keeps punching his own wound).
The duel was actually heavily one sided-stacked in favor of Rey.
But still even in this state, despite the above handicap, Kylo manages to wound Finn, and even if defeated manages to escape alive and with no much additional harm (beyond what he suffered from Chewbacca).
Also Rey, being more or less a street urchin surviving on her own should have some decent self-defense capabilities (with any random weapon she manages to grab) if she's survived successfully to her age.
(In the same way, her knowledge about ship should also not be a surprise given her day occupation - her being an ACE pilot is what I found stretching it too much.)
(Similarly - I can understand that the writers want to have her as a powerful natural force users who start to discover her latent power - it is her being able to *control* the force so fast without any formal training that prevents my suspension of disbelief - I would have expected a more haphazard random stream of accidental force uses, a bit reminiscent of X-Men mutants discovering their powers).
On the other hand Luke is a farm boy with a hobby of flying ship.
- One would expect him to be good at flying and shooting thing with a gun.
- One would not expect him to be able to successfully use other weapons that aren't found on a farm.
There was no reason to use the "Turing Complete" qualifier. You could have just said it isn't a language.
Modern Unicode is becoming so insanely complex, that it actually starts to border on a formatting language (like HTML and other markup language).
Just not a turing-complete one (i.e.: if you squint at it, it's closer to become HTML soon. Not Javascript).
Thunderbird has similar options :
- prefere plain text when available
- strip "advanced" formating (i.e.: remote bullshit and scripted crap) unless I whist list the correspondent.
The totally blank e-mail still happens (because, e.g. - the e-mail is entirely a remotely hosted picture - like a flyer).
But these e-mail never come from my usual correspondant any way.(*)
I don't even need to white-list them.
Nearly always they are some spam or other form of unsolicited mailing.
So I don't bother even paying attention.
If you're not even putting enough effort to make your mail decently readable,
you won't be spending any attention to you.
If that was some "important bill" and you subsequently try to sue me for not paying :
- you're a shitty company I won't deal any business with anymore, and won't even blink about it, there are tons of decent companies with whom to do business.
- be prepared to have your practice contested through consumer organisation. Welcome to Europe mother fucker.
----
even the HTML rich-editors used by my clueless friends :
- can output an alternative plain text form
- is simple enough that it can be displayed in "safe mode".
a coal power plant when build as compactly as electrically possible?
This is France they don't count on coal for their main power plant source.
They mostly count on nuclear.
in this totally safe PDF?
Yes, Postscript is a turing complete language
(you can even write a ray tracer in it).
BUT
postscript can only output to the document (or screen), and can't read input from the internet.
Thus, as long as there isn't a critical bug in the displaying software...
- (Adobe Acrobat reader, I'm looking at you right now !),
...and as long as there isn't some asinine extra feature implemented...
- (you can bet that someone at microsoft on the outlook team would dream of a document viewer that can automatically extract attachments embed inside PDF files and execute them)
...there isn't an actual risk in opening random PDF files, except that some might take a few hours to render.
(And other can generate 1000 - worth of pages on the printer with only a few lines of code, if you're so stupid to send a raw post-script to the printer without even looking at it).
Though I personnally agree with you (unicode, specially UTF-8, is way too useful for users of language that don't fit inside ASCII)...
Why not Unicode?
Google Zalgo
Unicode is extremely complex, and although it's not a turing-complete language, it can already be abused a lot to pretty much fuck up any layout.
(e.g.: When Slashdot didn't block them in the subject line, it was possible to abuse "text direction" marker to actually put arbitrary text on the right side of the subject. I.e.: write a troll flamepost with a title that could add "(Score: 5, Insightful)" right on the place where the actual scoring would normally go)
(e.g.: Zalgo text, where diactirics (extra accents on characters) and other such decoration is progressively used on text to make a complete unreadable mess of it)
etc.
Lots of potential abuse, so that's why /. which is primarily a english speaking site will severly limit unicode use (and English itself is a language that can possibly be written by using exclusively ASCII - e.g.: by ignoring the rare word where characters could be optionally accented).
Yup indeed.
The whole premise when smart watches where successfully brought back to the spotlight by Pebble, was to have electronics as power-economic as possible.
Pebble had eInk among the considered technologies to make it cheaper.
Tethering to a phone was actually a *selling point* - leave as much works as possible to the phone, and use the smartwatch only as an interface in order to make the most out of its tiny power budget.
You ended-up with watches which could go a week or more between charges. (and currently you find smart watches which try to have even lower power requirement, such small fraction of watts that thermoelectric effect from the wearer is a valid method to boost battery life).
Then the big companies noticed the popularity and the tremendous success of pebble in crowd-funding, and panicked that they might miss a slice of the pie.
So they rushed in with what they have : ultra-brilliant marketing department able to sell anything by making it seem desirable, and boring soulless engineering department trained to cram bullet points on a list.
And you end up with products which are basically not smartwatches - i.e.: extensions giving a few useful extra functionnality on an otherwise nice watch - but instead are diminutive crippled phones. Things that try to be phones but with catastrophic performance.
It's "iPhone 1" and it's horrendous battery life all over again.
Apple Watch 3 will end up being a crappy iPhone strapped to you wrist, not a brillant device revolution that Apple is desperately in need to stay relevant.
The sad part is that Pebble started an interesting trend of low-power device that can hold a week,
but the whole concept of smartwatches seem to be dying due to over flooding the market with crappy power-hungry stuff.
I would think they would have had better impact and a better impression of credibility if they committed to making 2-3 models successfully. Do the others once you have proven yourself.
The already have, both... :
- ultra small and low cost VW UP!
- the iconic VW Golf
are available as electric variant as VW-eUP! and VW e-Golf.
But you probably haven't heard much about them because VW only taugh about putting marketing money and massively advertising them in the wake of the diesel scandal.
Another problem -- at least for alert observing engineers -- is that both Musk and Nissan have shown that in order to make a successful EV one of the best practices is to design it as an EV from scratch. VW's announcement makes it sound like they are going to squeeze batteries and electric motors into their existing ICE designs.
(And you can add Renault to the list, they share their EV R&D with Nissan - they developped the "Zéro émission" platform together).
Yup, the current 2 above mentionned vehicles seem to me a little bit like "EV motor slapped on classical ICE cars" experiment quickly done to probe the market to see if there's interest.
(Which then were subsequently re-advertised as serious EV business goals after the scandal)
But I have to admit that I haven't much experience driving these.
Citroën C-zero also seems in my own driving experience like this - with a battery bank stuck in the trunk of an otherwise re-purposed ICE car.
(Which is weird, given that Citroën has nearly 4 decades of successful electric utility vehicle used among other by the french post on their delivery routes).
This as opposed to Renault Zoé which are modern Twingo design bolted onto the specially designed "Zéro émission" platform that they designed together with Nissan for this special purpose.
Smart is another European brand that reuses part of Tesla's battery platform for their electric variant. (Haven't driven one though - only seen them around).
(Both these last have batteries under the car like other "from the ground up" EV designs. Not batteries occupying whatever space happened to be free in the converted ICE such as the trunk as in the former).
Yeah you can make it work somewhat but it doesn't sound like you will get a superior product that way. In effect they have announced that they are going to strive for mediocrity.
...or that they want to be the quickest to market.
See how long it took Nissan and Renault for their "Zéro émission" platform.
See how long it is still taking as of today for Tesla who are still in the process of extending their platforms range to cover Model 3.
Designing from the gound up take time. A lot. And costs. Again a lot. During which time you'll still have to sell the old cars.
VW's old cars got a horrid reputation after the scandal (in practice they're not the worst. There are other offenders cheating even more. VW just happen to be the one who didn't pay enough brib... huh.. sorry "who happened to get caugh by chance").
They need to move fast and cheap.
(They've always have been about producing cheap cars fast, all the way back to the first beetles and minivan)
Repurposing ICE cars is a quick cheap solution that can work RIGHT NOW.
Then they can take time to specially built new platforms at a later time (as the upcoming 2018 electric rebirth of the VW minivan - which seem to be built on a newer platform)
That also explains clearly the Citroën C-zero : cheap, fast to produce entry-level car now.
Not with this hotels' Wifi, apparently. I have the latest version of the big three browsers.
that's strange : I actually had the "there is apparently a log-in screen" pop-bar just the day before....
but not being able to disable the security measures just to click through a login screen is bad design on the web browsers' part.
On the "bad certificate" page in firefox, you can still click to get the details, then add an exception and make it temporary (just until you've logged in).
Disabling the security is another possible route instead of the pop-bar (one which was available long before the pop-bar itself).
Which you now have to fight Google in court to prove if they got the patent that you should have applied for.
*if* they get the patent...
Which exactly why Jarek Duda is writing to the patent office to inform them of the prior art.
Which is exactly what happened afterward.
Citing TFS on /. :
The researcher already filed a complaint, to which WIPO ISA responded by calling out Google for not coming up with "an inventive contribution over the prior art, because it is no more than a straightforward application of known coding algorithms.
Prior Art won.
Thanks to publications of Jarek Duda (see: arxiv), and provable discussion with Google (i.e.: disclosure) that predate the patent filing.
Just to nitpick :
tANS (table Assymetric Numeral Systems) such as the FSE (Finite State Entropy) implementation by Yann Collet, at the hearth of Zstd compressor (now Facebook's) are NOT 3-30x better than other modern post-Huffman entropy encoder, such as binary-arithmetic encoding or range-encoding.
They are much *FASTER*. By lots.
They all boil down to the same logic:
do not use a fixed code-word book like Huffman (which is thus limited to integer number of bits).
but try to get as close as Shanon's theory predict the necessary bits, by subdividing number space.
range encoding works by dividing an arbitrary big number (usually an extremely long binary number).
For each symbol, you split this range in sub-ranges. More frequent symbol get a wider sub-range, more rarer symbol get a narrower one.
You pick the sub-range corresponding to the next symbol in the text you need to encode.
Then you keep the same work by subdividing *THAT* sub-range by the probabilities of symbol occuring in the position after that.
- Encoding relies a lot on multiplications (there isn't such a thing as a direct multiplication in transistors. Instead you implement it in microcode by combining shifting and adding. modern CPU have big shift-adders units, so they can manage in chunks of 64bits - on modern Intel it's a few cycles delay, 1 more if you want the upper 64bits of a 128bits product).
- Decoding relies on division (rules of three to "zoom" into the subranges), and division are fucking slow (again no such things as "division" with transistors. Instead you implement it in microcode, and most modern CPU tend to do it bit-by-bit meaning it's fucking slow. - on modern Intel it's dozens of cycles delay).
This thing was published in 1979. (And thus isn't patentable)
It's provable that it approaches arbitrarily close the Shanon limit. (all the symbols in the stream occupy a total of bits that is close the invert log2 of their respective frequencies).
Arithmetic Coding is a cousin technique patented more or less in the same era.
In can be seen as a special sub-case of range-encoding where the range is [0;1] and you subdivide it in fraction.
It's most often implemented as binary arithmetic encoding.
Input symbol are converted into a bit stream.
Then for each bit, the fraction is divided in two half. e.g.: if each bit has a 50:50 chance, the [0;1] is subdivided at 0.5
You chose the range under or above this mid-point depending if the bit is 0 or 1 and move forward to the next bit and sudivide the fraction based on the next probability (e.g.: mid point at 0.25).
Given that there are only 2 symbols, and therefore only a mid-point fraction to keep track of, its implementation is a little bit simpler to follow.
But because this works on *every single bit* of the input stream, you can guess it's either slow (on CPU - hence CABAC versus CAVLC in H264 videos) or require high-frequency on hardware implementation.
As it is basically a variation of Range Encoding it can achieve similar arbitrarily close to optimum encoding.
Then come Mr. Duda with his ANS.
They are basically range encoding turned on its head - to understand you must basically look at range encoding's bit the other way around.
- Range encoding works by subdividing an arbitrarily big number. ANS work by build a progressively bigger number.
- Range encoder usually works by writing out the most significant (high bits) away and then shift the working values. - ANS works by considering the least significant bit (the low part).
And here comes the real magic :
- With range-entropy: if you have 2 symbols with 50:50 chances, you subdivide the range in 2 halfs. With a different probability you still end up with 2 adjacent sub-ranges of different lenght.
- With ANS, because you figuratively "reverse the bits" : if you have 2 symbols with 50:50 chance, you'll find them alternating in
Even if you want to just give it away, you better apply for that patent
Or you know.
Just publish it formally.
Like he did.
That constitutes prior art and make Google's patent invalid.