Management firmware is basically a minimalist OS running on a separate low-power core inside the chipset.
Let them make that firmware opensource, problem solved.
(I haven't checked, but I'm quite sure it's just come embed linux system (busybox, uclib, etc.) running on a low-power ARM core, with special driver to run the hardware connected on the GPIO pins)
For the opensource driver efforts, I would go for an AMD GPU.
Latest generation is supported out of the box by amdgpu opensource drivers all the way up to opengl 4.5 (thanks to mesa), already some opensource Vulkan (thanks to radv), and the kernel drm module is shared with the closed source amdgpu-pro, so it's basically just switching a few user-space libraries around to run the closed source driver if you need them that much (AMD only recommands them for some specific professional use cases) your kernel of whatever dristribution already has the drm module even if it's a beta pre-release.
AMD actively pays linux developers (and since recently, a lot of them, now that they're trying to rebuild a shared codebase between their windows and linux drivers with DAL/DC)
A far as I've understood, the complain of Uber is that the official level imposed to cab driver is much more strict than uber asks from its driver.
Because of this uber is going to lose lots of driver who know enough bits of english to be functional in communicating with the client (e.g understand where to drive them), but who don't have advanced written/oral comprehension.
I.e.: Uber needs and selects people with A1 levels of language proficiency, London imposes B2 levels on cab drivers.(*)
Or in other words, it's not london only requiring that people who handle services to english-speaking client to be able to communicate in English, but Uber complaining that their drivers don't need to be able to write an essay.(*)
---
(*) : According to Trinity College who handles such tests, cab drivers are in fact required to have B1 level of english language proficiency, which does include reading/writing comprehension.
the A levels are basic communication/survival (ask your way arround, go shopping, etc.) the B levels are more complex communication (be able to tell a story, describe your dream(**), etc.) The C levels are more or less academic (be able to do your studies in that language, among other, etc.)
(**) : I kid you not. "Dreams" are mentioned in the official criteria for language. Though I'm sure, depending on they are high on, some/.ers would require languages which have not be invented yet, just to describe what went through during their dreams.
It's funny that you mention France, because inside Europe, they are known to be notoriously worse at languages (specially regarding English).
And it's probably because of the same reasons: it's a (relatively) big country (on the scale of Europe), you can easily get around using french in lots of places (oversea territories in south america, former colonies all over africa including from north, qebec in canada, etc.), and they are really proud of their unified culture.
Also in the specific case of english, it doesn't help in that it's as different as you can get from french, (spanish, italian, etc. are much easier to learn for french because they are much closer. German still has closer sonority to french than english).
Rendering and video encoding is not an end-user application
No, indeed. Spending time online on Facebook/Whatsapp/instagram/etc. is the more typically end-user application. And that has been already solved for quite some time. Including by CPUs that run into your pocket.
Now please, can we go back to what modern CPUs have to offer ?
Intel clearly retains the crown for single thread and high-end performance. - And single-thread performance is king for games and end-user applications.
Was. Multithreading is slowly entering other fields. Games start to make better use of multiple cores. That was one of the main argument for Vulkan : better multithreading support.
It's a CPU running x86 instruction. It basically works.
The rest is just drivers for the various parts (for the northbridge that's inside the CPU package, or for the chipset on the motherboard). And drivers can be provided by the motherboard manufacturer.
So basically there's no reason why a Ryzen won't run on your Windows 8.1 or 7 (once you loaded the appropriate chipset drivers), nor why it won't run on older versions of Ubuntu (kernel 4.4, predates Ryzen, doesn't have any Ryzen specific code, will output a few oopses in code, but otherwise reported to run).
So you need to add something that creates an amorphous solid ice when mixed with water, or at least far smaller ice crystals.
Which is exactly the technique used by some fishes that can survive in the ice : they secrete some sort of anti-freeze in their bloodstream which prevent big ice crystals to form.
indeed, it's not technically cgi animation as we know it today. more computer post-pprocess.
eg.: the scene were the T-1000 flows trough the prison "bars" door, is actually filmed with robert patrick simply walking straigh through a door that had the bar hacked off. then, they digitally added the bars back in the scene, and had the original image of robert patrick wobble and distort to match the flow that a liquid-metal based robot would have.
The novelty is that these one use machine learning (SVM according to the source).
(As opposed to older psychoauditive models used in compression of MP3, Vorbis, etc. which were based on clear rule, such as "a loud beat from a drum will mask whatever was playing the main melody". This one learns automatically based on a crowd-sourced quality evaluation)
I could easily spot a Terminator in a war, it's the "Human" that looks like he eats 8000 calories a day and works out...
The in-world retro-fitted explanation is that technology only got that good with the T-800. The Arnold is the most compact humanoid outer flesh that they can manage to fit over the robotic chassis. Older models were even bulkier and looked even less human. OTOH, later model managed to camouflage better thanks to mimetic polyalloys and looked much more leaner.
The cinematographic reason : Cameron needed an actor that will look unstoppable and will inspire awe. The Arnold is the best he could manage to inspire this "mighty glacier" power. This stature has the on-screen effect that was in Cameron's vision for the movie, and to the hell if he doesn't remotely look like Michael Biehn (who's supposed to be the future's everyman).
the whole point of recaptcha is crowd sourcing ai training.
some of the audio captcha aren't purposely distorted synthetic bits, but actual snips of real-world data with which google voice is.having problems. (just like visual captcha can also help training the OCR or imagr recognition ).
the suggestion you're making would be training data for a different AI task (tagging/recognition of sounds, and common knowledge/logic databases).
the funniest thing, i find, is that reCaptcha was initially designed to crowd-source difficult AI problems. (OCR, image recognition).
So after a while, it seems normal that with enough such recaptcha crowdsourced feedback, google's voice recognition will get better, and thus could also be used to understand audio captchas ?
the problem will be: what will happen is this get massive deployment ? google won't be able to learn new stuff, teach it AI new tricks. Whenever there is a new difficult piece of voicd, when submitted to recaptcha for crowdsourcing, the swarm of google-voice powered bots will answer with the default (broken?) answer. and given the massive number of answers, recaptcha will reach the wrong conclusion that the default is good. the actual few humans will be first useless for AI training in the middle of the bot noise, and then will get problems once recaptcha decide that the bad automatic interpretation is the correct one.
Touch interfaces are crap even for people with perfect eye sight.
Touch interfaces are crap, usually because they try to replicate button interfaces, poorly.
Worst offender : visual keyboards. - physical keyboards work more or less, because your finger tips are equipped with a sense of touch. you can feel the buttons under your finger, and know when you're about to hit what you want, the you feel the button getting pressed by your finger movement. (See regular computer keyboards. See also older physical keyboard on phones (flip-out, slide-out, etc.) specially those with gum-drops style keys) - on a visual keyboard, you have tons of small buttons densely packed. your fingers need to jump allover the place, each time aiming for a small surface, all this "blindly" without any tactical feed-back to feel the keys passing by as the fingers seek, or the button being pressed. And according to Fitt's law, this configuration (lots of movement all over the place aiming for very precise target areas) is absolutely dreadful. You end up putting your finger in the general area where you think is the key you want to type, and hope that the autocorrect will manage to make some sense out of it. Swype isn't much better from that regard. Even if you're not "pecking" with your finger, you still need to swipe in theory over the desired key, and there's still an autocorrect that needs to make sens out of it.
Gesture interfaces try to follow the logic behind Fitt's law and remove the worst offender : - they try to eschew small targets that you need to aim at. - Instead they either use a large "gesture area" (like HP/Palm webOS used to, or like is introduced to Android) - or follow an adaptation of Fitt's 5 best optimal point, adapted for touch screens (the place your finger happens to already be is easy to reach, so gesture where you grab the whole app screen ; 4 edges are also easy to tactile-find) and use whole screen gestures (like Jolla's Sailfish OS )
No more pecking and hunting for small buttons. Only larger smooth motions that are easy to do even on a touch screen. e.g.: Just swipe more-or-less horizontally, in the general left direction.
(Note that currently as of today, there aren't many gesture-based text inputs deployed in the wild. "Graffiti" used to be a thing back in the Palm OS era. Dasher is a PPM-based type of text input wiht word prediction that can target people with reduced mobility).
I'm sure people with visual handicaps are going to really HATE this.
Now, I don't know how TFS' companies are going to specifically implement it.
But based on my experience with other gesture based smartphone (Palm/HP webOS, Jolla Sailfish), this actually *improves* visibility.
With classical button interfaces, you need to hunt down a button to do an action. That's not that much complicated, but gives you a baseline. And it's possible to do some without looking.
After the move to virtual buttons (as tons of modern android device have been doing), it becomes much *more* complicated, because you can't even count on tactile feed back to feel the shape of the button to be sure where/when to press. You need to visually check that your finger is hovering above the correct button. (Small target area: bad according to Fitt's law).
On the other hand, gesture are much *simpler*. You move your finger in the general area (= large target area: better according to fitt's law), and just move it in a general direction (left, right, etc.), no small targets (= no bad, thank Fitt's). Most of the gesture can be done without looking (and were on purpose designed so).
So a person with visual disabilities would be moving from a current tiresome virtual button interface (constantly checking visual feedback to be sure to click the intended button), to something which won't require any visual control at all (just slide the finger on the correct side of the device, and in the correct direction).
HP/Palm webOS and Jolla's Sailfish OS were asked for comments about Android's new gesture interface. Their answer : yawn.
Moto's implementation sounds better to me.
...and used to be the standard mode of operation since Palm's Pre (webOS powered).
Jolla Phone (Sailfish OS) has a similar general approach to gesture, except that in order to save on screen estate, they abandon the idea of a dedicated gesture area, and instead use the screen (e.g.: you swipe the *whole app's* main area or title bar to do a "back", instead of swiping under it) and screen edges (e.g.: you swipe from the right edge to go or peek at multitasking, instead of in a gesture area).
Due to fitt's law such gesture-based approaches are much better than "hunt the button" presses.
(Much older than that, PalmOS used to have a gesture area. Most of the time it was used to draw glyphs (replacement for a keyboard), but a lot of simple shortcuts where possible ( "\" + "C" : copy, etc. and also other shortcut to jump to apps) )
Obviously the vast majority of phone users do not do this, so I understand why the onscreen keyboard has won-out, but it would be nice if a single manufacturer made a ruggedized phone with a good physical keyboard.
Or at least leave enough access (pogo pin contacts, etc.) so 3rd party can easily manufacture after-market keyboards. e.g.: TOHKBD (the other half - keyboard) back cover with magnetically sliding keyboard for the Jolla phone.
Same should also be possible for Fairphone 2 (has USB pogo pins available under the back cover for the exact purpose of this kind of extensions).
When you eat too much sugar, the body produces more insulin to force the sugar into the cells, cells get too much sugar, and reduce their insulin sensitivity. After a while, you see blood sugar rise, but the damage has already been going on for years, usually.
For added precision:
bad eating habits: - high calorie intake (too much sugar and fat) : drives obesity up. - too much *glucose*, i.e. *processed* sugar (In everyday's terms: pure sugar. Like the sugar-cubes equivalent in a soda can. As opposed to complex glucose polymers fibers, as found in nuts) and/or *very small low complexity oligomers* (starch. Like white bread. It doesn't taste sweet at all (there's very little actual pure sugar inside) but the starch gets broken up *extemely fast into glucose* during digestion. As opposed to whole grain bread which takes a bit more time. And as opposed to nuts, as mentionned above : their fibers takes a long time to digest).
When the glucose absoption is too fast (because the sugar is alredy processed as glucose, or because the starch gets digested too quickly), the body keeps the blood glucose concentration low by quickly releasing peaks of insulin. (Compare with eating nuts : they get digested into glucose extremely slowly and thus the glucose only enters the body drip by drip. Insulin only needs to be raised very slightly above basal level) (As a consequence, a type 1 diabetic doesn't usually give a fuck about nuts and doesn't need to take them into account when computing insulin injection dose)
This *very sudden* and *very high* rise of insulin causes: - nearly all cells in the body will down-regulate their insulin receptors. They become more insulin resisting (eventually devolving into type 2 diabetes). And eventually glucose rises as a consequence. The lone exception is the brain which use an entire different pathway (does not depend on insulin at all) and still keeps getting its sugar. (And this is part of the reasons why diabetes is much more destructive than fasting / any other protein-high diets) - the high level of insulin also work as hormone and signal to the body. It encourages creating even more fat tissue storage (as opposed to use the sugar to build muscle mass). This worsens the obesity, which in turn works as a positive feedback, and is also a cause of heart diseases.
Once insulin resistance sets in: - glucose remain in excess in the blood - due to high concerntration you pee a lot (hence the name diabetis) - as it doesn't enter in the cells (except the brain) the rest of the body thinks that it doesn't have any, and thus bruns fat and proteins instead, tries to synthetise glucose out of these, and asks the liver (through glucagon) to release some of the glucose from the reserves in the liver. - but non of this extra glucose (synthetised or release) is of any help : the insulin still won't bring it in.
Damage comes from: - High concentration of glucose. (Body has problems keeping the osmolarity of the blood). This eventually leads to blood vessels walls being damaged. (Diabetes is mainly a blood vessel disease, mediated by the glucose concentration). - Ketonic bodies toxicity. Because glucose can't enter most of the body, it's as if there was none and the body was fasting. In absence of (available) glucose, the body cells start to burn fat as an energy source (this requires to burn proteins as a by product of a missing reaction) (this also produces ketonic bodies. These are toxic. Under normal circumstance (someone on a high protein, low carb diet), the brain cell would eat it and burn it as fuel source. But here the brain has access to plenty of glucose (remember : brain uses a different pathway to get its glucose and isn't affected by glucose) and thus will keep burning glucose, instead of burning ketonic bodies. These therefore accumulate and they end up being toxic)
Note: - The above only concerns *glucose*. - This doesn't concern al
Ingested carbs need to go somewhere. Brain consumes a bit, and the remaining part is the problem. If one has enough physical activity, carbs get burned in muscles. Otherwise, they are converted into fat,
not quite. carbs don't just stay here waiting (like gaz in a car's tank) body will process them, depending on tons of hormonal messages. carbs will get used and making fat is only one of the possibility the body will choose.
e.g.: if you do sports, not only will you burn carbs for energy during the sport, but you will raise the level of some growth hormone, encouraging your body to use the available resources to build more mudcles instead of storing them in long term.
remain in bloodstream (this is diabetes) until cleared by kidneys.
huh.. Nope. not at all. diabetis is absolutely not "the excess sugar in the blood". diabetes is mainly the signaling pathway that normally orders the uptake of the sugar being broken. the two types of diabetis are due to which step of the pathway is broken . (either the production of insulin, or the receptors that should.detect it)
the fact that people who overeat have an increased risk of diabetis isnt due to extra sugar staying in the blood, it's due to the body getting desensitized tobthe insuline (mainly because to avoid having extra sugar in the blood the body will secrete extra insulin, but over time that extra insulin will down regulate the receptors, leading to the oathway not working that well anymore) (also fat tissue also secrete it's own signaling hormones. obese patients have so much of fat, that they produce excessive amiunt of some hormone and their signaling disturbs other pathway) so excess sugar isn't the cause of diabetes (and is actually correctly compensated at the beginning) it's the result of an insulin pathway that got fucked up, e.g. by the bad eating habits.
Does the Git usage of SHA-1 *really* cause silent problems? I'm not sure how Git works internally but I was under the impression that it hashes whole objects, like individual source files at least.
The individual objects inside git aren't file. The individual objects are commits (i.e..: the content of a patchfile, and a few information like pointer to other past commits to which this patch applies). To make things easier, a handy number designates this commit - this is currently generated by SHA-1.
(Git is a content-addressable platform. You don't access object by name, you access them depending on their content. But instead of using the whole content to access them, you use addresses generated by SHA-1 to access the various blocks. So to say which are the parent commits to which the patch in a commit applies, you just mention them by using the SHA-1 sum of the content of these commits).
A theoretical attack would be: - try to generate 2 commits. one adds a clean piece of code. the other adds a backdoored piece of code. but both commits hash to the same SHA-1 so they would be considered as "the same content" by git. Then try to force your target to re-download the whole repo from scratch from your backdoored history (otherwise git will simply ignore the commits with sha-1 sum that it already has - it thinks that it has the same content already).
In practice it's currently not doable. The only thing that google managed to generate is a pair of block series. Each series contain completely random junk. Both series end-up generating the exact same shasum even if the random junk is different. - That is exploitable in a PDF (or any other binary format that supports scripting. You could even do it in an EXE) : using the embed scripting present 2 different contents depending on which random junk is present. - That is not exploitable in a sourcecode commit : you would need a believable explanation for why the random junk is present in the patched source code. AND you would need a piece of code which reacts differently (normal vs. backdoor) depending on which random junk is present - to be able to pull that unnoticed would require "Underhanded C Contest"-level of ingenuity.
That's it, you only have blocks of random garbage. Google currently can't produce hashes colliding from arbitrary pieces of data ("Hey google: here's is legit script A, and that's malicious script B. Add a small nonce at the end so they both end-up having the same sha-1sum") ("Actually don't add a nonce, that would be too conspicuous, try to tweak the punctuation in the comments instead")
Also as you mention, further edits will be problematic : if I edit script A and submit a patch, this patch will be valid, but will completely fail on top of script B.
A cryptographic hash function has the properties you mention, plus the fact that it must not be easily reversible and uniformly distribute results over its entire output space.
The later is a property which is not guaranteed by most common checksums. Thus, when you need a hash function to give a number to use as a handy "nickname" for a collection of data (e.g.: for a hash look-up table. Or for a content-addressable like git to create said addresses for a given content - and thus to give a serial number to a commit. Or apparently also used in SVN to give a simple number to designate commits), it might be a good choice to pick-up a cryptographic hash like SHA-1 because it guarantees you this additional property, which a vanilla checksum could lack.
If you only care about random bit flips CRC32 will work very well and be much faster than MD5 or SHA-1.
Well, not exactly. - MD5 and SHA-1 have fast hardware implementation on some CPUs. CRC32 won't necessarily be a huge performance gain.
SHA-1 is used a bit more than a simple glorified checksum in GIT. It is also used to give a handy number by which you designates commits, etc. (i.e.: to compute a hash - e.g.: as would also be used in a hash look-up table). That requires good output uniformity. In other words you'd need a hashing function that "spreads" its output accross the whole output domain. (to give an over-simplified examples: if due to a poor design, all patches ended-up having hashes that begins with the hex number "9", that would be a poor hashing function for these needs. If you used it in a hash lookup table, one part of the table would be over filled, while other would be still empty)
Cryptographic hashing functions offer these guarantees among lots of others. CRC32 doesn't, and several of the other checksums that were quickly designed for speed have also been detected not to offer these.
At this situation, a programmer can choose two paths : - Some coder would try design their own new hashing which offers both good speed and the important properties (e.g.: That's exactly what LZ4's Yann Collet did, and created xxHash64. It's not a cryptographic hash, but at least offers all the properties that cyann needed) - Other would instead jump to a quick'n'dirty solution, and go for the major overkill: take a cryptographic hash (e.g.: And that's what Linus Torvalds did. He's a lazy git. He knows that a cryptographic hash would provide all the properties he needs. SHA-1 is one that was popular back then, had even some hardware implementation. So he picked it and didn't think much about it. It offers all the properties Linus needed for git. It also offered much more but Linus didn't give a fuck about that. Though it doesn't offer security (anymore. specially since the google proof of concept) but that's something that Linus doesn't care and didn't even bother to check (as mentioned SHA-1 was already suspected backthen, and serious cryptographic usage relied on SHA-2 instead), relying instead on signed repositories if security is needed).
And on exactly what basis do you make this assumption?
It's NOT an assumption. It's the personal anecdotal experience of what is running on my phone. I'm not from India, I'm from Europe. I have a Microsoft account and it's configured to use a time-based OTP as a second factor in the 2 factor authentication. I don't have biometrics configured as a way to log-in. I don't even have my biometrics data stored in the Aadhaar database.
I installed Skype Lite (note: like with Facebook's "Lite" applications, you need to side-load it manually, because inside the Google Playstore the app is geo-restricted and the store will refuse to install it on smartphone outside the target market). App asks me my credential, app asks me my 2nd factor. That's it, it works.
At no point in time did it ask me to upload my biometrics into the Aadhaar database, nor did it even consider using biometrics as an authentication factor. So even if Aadhaar is apparently a leaky mess of privacy violations, I'm not concerned by it. My fingerprints are not going to get pwnd and leaked to the net by Aadhaar as they don't have them.
So okay, I'm a single data point. Maybe there are other factors that I'm overlooking. But still, my personnal anecdotal experience is a good sign that people outside of India could be using Skype without beeing affected by Aadhaar's "peculiar" relationship with personal information and privacy. The only limitation that I've seen is the Playstore's own geo-locking, preventing non-Idan google accounts to deploy the app. (This can easily be circumvented by manually installing). No practical limitation would prevent a US user, like the top poster, to use it in the USA (just like I did) and enjoy a skype client that only uses a fractions of the resources that the current mainstream android app uses.
The same is similarily valid with Facebook Lite and Facebook Messenger Lite.
The big question I was trying to raise in my above post is : - are young associate lawyers being made redundant by OCR and AI, to the point that they are fired and we see even less lawyers nowadays than before ? or : - are OCR and AI enabling the young associate lawyers to do much more work for the law firm (e.g.: now they can use google to search online through a large corpus of archive, instead of painstakingly going through microfiche in the basement of some government archive), so that the law firm can process even more lawsuits. To the point that we see even more and more lawsuits and other legal cases everywhere than there used to be in the past ?
My current impression of all the information I find online is that law suits and other legal proceedings are actually on the rise. (e.g.: the several million of DMCA take-downs issued by the brazillian equivalent of **AA against an obscure "mp3toys" downloading website). We're not seeing *less* laywers, we are seeing lawyers being more busy thanks to the modern computing tools.
Or in another field : Watson isn't putting medical doctors jobless on the street. Watson is helping process more of the simple stupid cases that could otherwise swamp a doctor's office. It helps doctors process even more patients cheaper than before thus bringing more affordable healthcare to the population.
Also, the survey taker will be more concerned about others' jobs (i.e.: jobs in general), because they see the over-all advances in AI (e.g.: speech recognition in Siri, automatic image tagging in Facebook, automatic face recognition nearly everywhere) and think that in general term, AI is progressing and one day might replace them...
But when they think about they own job (i.e.: they think about a specific area where they have expertise) they have much more insights on the details (they know all the intricacies of their crafts. They might even have seen and/or tested some automation solution) and have noticed that we aren't quite there yet. (e.g.: though speech recognition has made advances, automatic transcription isn't perfect for anything but the most easy cases. Youtube automatic captions still need to be corrected by a human. etc.). Might even notice that robots are going to augment rather than replace them - as mentioned by others in this thread (AI is currently helping with the research work in law. It's not replacing attorney. Instead it's enabling a law firm to do much more without needing to hire more interns and assistants).
So hence the "my job" vs. "others' jobs" fears.
In addition of "not being frightened 'once a week by a robot' " as mentionned, they might know that due to the specifics they know about their job, it won't exactly mean overnight take over by bots within the coming month.
Slashdot Mirror
Management firmware is basically a minimalist OS running on a separate low-power core inside the chipset.
Let them make that firmware opensource, problem solved.
(I haven't checked, but I'm quite sure it's just come embed linux system (busybox, uclib, etc.) running on a low-power ARM core, with special driver to run the hardware connected on the GPIO pins)
For the opensource driver efforts, I would go for an AMD GPU.
Latest generation is supported out of the box by amdgpu opensource drivers all the way up to opengl 4.5 (thanks to mesa), already some opensource Vulkan (thanks to radv), and the kernel drm module is shared with the closed source amdgpu-pro, so it's basically just switching a few user-space libraries around to run the closed source driver if you need them that much (AMD only recommands them for some specific professional use cases) your kernel of whatever dristribution already has the drm module even if it's a beta pre-release.
AMD actively pays linux developers
(and since recently, a lot of them, now that they're trying to rebuild a shared codebase between their windows and linux drivers with DAL/DC)
A far as I've understood, the complain of Uber is that the official level imposed to cab driver is much more strict than uber asks from its driver.
Because of this uber is going to lose lots of driver who know enough bits of english to be functional in communicating with the client (e.g understand where to drive them), but who don't have advanced written/oral comprehension.
I.e.: Uber needs and selects people with A1 levels of language proficiency,
London imposes B2 levels on cab drivers.(*)
Or in other words, it's not london only requiring that people who handle services to english-speaking client to be able to communicate in English, but Uber complaining that their drivers don't need to be able to write an essay.(*)
---
(*) : According to Trinity College who handles such tests, cab drivers are in fact required to have B1 level of english language proficiency, which does include reading/writing comprehension.
the A levels are basic communication/survival (ask your way arround, go shopping, etc.)
the B levels are more complex communication (be able to tell a story, describe your dream(**), etc.)
The C levels are more or less academic (be able to do your studies in that language, among other, etc.)
(**) : I kid you not. "Dreams" are mentioned in the official criteria for language. /.ers would require languages which have not be invented yet, just to describe what went through during their dreams.
Though I'm sure, depending on they are high on, some
It's funny that you mention France, because inside Europe, they are known to be notoriously worse at languages (specially regarding English).
And it's probably because of the same reasons: it's a (relatively) big country (on the scale of Europe), you can easily get around using french in lots of places (oversea territories in south america, former colonies all over africa including from north, qebec in canada, etc.), and they are really proud of their unified culture.
Also in the specific case of english, it doesn't help in that it's as different as you can get from french, (spanish, italian, etc. are much easier to learn for french because they are much closer. German still has closer sonority to french than english).
Rendering and video encoding is not an end-user application
No, indeed. Spending time online on Facebook/Whatsapp/instagram/etc. is the more typically end-user application.
And that has been already solved for quite some time.
Including by CPUs that run into your pocket.
Now please, can we go back to what modern CPUs have to offer ?
Intel clearly retains the crown for single thread and high-end performance. - And single-thread performance is king for games and end-user applications.
Was.
Multithreading is slowly entering other fields.
Games start to make better use of multiple cores.
That was one of the main argument for Vulkan : better multithreading support.
Regardless of gaming, which really is all about the GPU especially with Vulkan games coming down the pipe, ...
Vulkan has even another reason: it supports better multithreading, and Ryzen seems to shine under those circumstances.
(That's also why older, more single-thread-oriented games don't work better)
It's a CPU running x86 instruction.
It basically works.
The rest is just drivers for the various parts (for the northbridge that's inside the CPU package, or for the chipset on the motherboard).
And drivers can be provided by the motherboard manufacturer.
So basically there's no reason why a Ryzen won't run on your Windows 8.1 or 7 (once you loaded the appropriate chipset drivers), nor why it won't run on older versions of Ubuntu (kernel 4.4, predates Ryzen, doesn't have any Ryzen specific code, will output a few oopses in code, but otherwise reported to run).
So you need to add something that creates an amorphous solid ice when mixed with water, or at least far smaller ice crystals.
Which is exactly the technique used by some fishes that can survive in the ice :
they secrete some sort of anti-freeze in their bloodstream which prevent big ice crystals to form.
indeed, it's not technically cgi animation as we know it today.
more computer post-pprocess.
eg.: the scene were the T-1000 flows trough the prison "bars" door, is actually filmed with robert patrick simply walking straigh through a door that had the bar hacked off.
then, they digitally added the bars back in the scene, and had the original image of robert patrick wobble and distort to match the flow that a liquid-metal based robot would have.
Yup, it's a psychovisual model.
Like there has been used in video compression for quite some time.
There is a primary source link mentionned elsewhere in this thread.
The novelty is that these one use machine learning (SVM according to the source).
(As opposed to older psychoauditive models used in compression of MP3, Vorbis, etc. which were based on clear rule, such as "a loud beat from a drum will mask whatever was playing the main melody".
This one learns automatically based on a crowd-sourced quality evaluation)
I could easily spot a Terminator in a war, it's the "Human" that looks like he eats 8000 calories a day and works out...
The in-world retro-fitted explanation is that technology only got that good with the T-800. The Arnold is the most compact humanoid outer flesh that they can manage to fit over the robotic chassis. Older models were even bulkier and looked even less human. OTOH, later model managed to camouflage better thanks to mimetic polyalloys and looked much more leaner.
The cinematographic reason : Cameron needed an actor that will look unstoppable and will inspire awe. The Arnold is the best he could manage to inspire this "mighty glacier" power. This stature has the on-screen effect that was in Cameron's vision for the movie, and to the hell if he doesn't remotely look like Michael Biehn (who's supposed to be the future's everyman).
the whole point of recaptcha is crowd sourcing ai training.
some of the audio captcha aren't purposely distorted synthetic bits, but actual snips of real-world data with which google voice is.having problems. (just like visual captcha can also help training the OCR or imagr recognition ).
the suggestion you're making would be training data for a different AI task
(tagging/recognition of sounds, and common knowledge/logic databases).
the funniest thing, i find, is that reCaptcha was initially designed to crowd-source difficult AI problems.
(OCR, image recognition).
So after a while, it seems normal that with enough such recaptcha crowdsourced feedback, google's voice recognition will get better, and thus could also be used to understand audio captchas ?
the problem will be:
what will happen is this get massive deployment ? google won't be able to learn new stuff, teach it AI new tricks.
Whenever there is a new difficult piece of voicd, when submitted to recaptcha for crowdsourcing, the swarm of google-voice powered bots will answer with the default (broken?) answer.
and given the massive number of answers, recaptcha will reach the wrong conclusion that the default is good.
the actual few humans will be first useless for AI training in the middle of the bot noise, and then will get problems once recaptcha decide that the bad automatic interpretation is the correct one.
Touch interfaces are crap even for people with perfect eye sight.
Touch interfaces are crap, usually because they try to replicate button interfaces, poorly.
Worst offender : visual keyboards.
- physical keyboards work more or less, because your finger tips are equipped with a sense of touch.
you can feel the buttons under your finger, and know when you're about to hit what you want, the you feel the button getting pressed by your finger movement.
(See regular computer keyboards. See also older physical keyboard on phones (flip-out, slide-out, etc.) specially those with gum-drops style keys)
- on a visual keyboard, you have tons of small buttons densely packed.
your fingers need to jump allover the place, each time aiming for a small surface, all this "blindly" without any tactical feed-back to feel the keys passing by as the fingers seek, or the button being pressed.
And according to Fitt's law, this configuration (lots of movement all over the place aiming for very precise target areas) is absolutely dreadful.
You end up putting your finger in the general area where you think is the key you want to type, and hope that the autocorrect will manage to make some sense out of it.
Swype isn't much better from that regard. Even if you're not "pecking" with your finger, you still need to swipe in theory over the desired key, and there's still an autocorrect that needs to make sens out of it.
Gesture interfaces try to follow the logic behind Fitt's law and remove the worst offender :
- they try to eschew small targets that you need to aim at.
- Instead they either use a large "gesture area" (like HP/Palm webOS used to, or like is introduced to Android)
- or follow an adaptation of Fitt's 5 best optimal point, adapted for touch screens (the place your finger happens to already be is easy to reach, so gesture where you grab the whole app screen ; 4 edges are also easy to tactile-find) and use whole screen gestures (like Jolla's Sailfish OS )
No more pecking and hunting for small buttons. Only larger smooth motions that are easy to do even on a touch screen.
e.g.: Just swipe more-or-less horizontally, in the general left direction.
(Note that currently as of today, there aren't many gesture-based text inputs deployed in the wild.
"Graffiti" used to be a thing back in the Palm OS era.
Dasher is a PPM-based type of text input wiht word prediction that can target people with reduced mobility).
I'm sure people with visual handicaps are going to really HATE this.
Now, I don't know how TFS' companies are going to specifically implement it.
But based on my experience with other gesture based smartphone (Palm/HP webOS, Jolla Sailfish), this actually *improves* visibility.
With classical button interfaces, you need to hunt down a button to do an action. That's not that much complicated, but gives you a baseline.
And it's possible to do some without looking.
After the move to virtual buttons (as tons of modern android device have been doing), it becomes much *more* complicated, because you can't even count on tactile feed back to feel the shape of the button to be sure where/when to press. You need to visually check that your finger is hovering above the correct button.
(Small target area: bad according to Fitt's law).
On the other hand, gesture are much *simpler*. You move your finger in the general area (= large target area: better according to fitt's law), and just move it in a general direction (left, right, etc.), no small targets (= no bad, thank Fitt's).
Most of the gesture can be done without looking (and were on purpose designed so).
So a person with visual disabilities would be moving from a current tiresome virtual button interface (constantly checking visual feedback to be sure to click the intended button), to something which won't require any visual control at all (just slide the finger on the correct side of the device, and in the correct direction).
HP/Palm webOS and Jolla's Sailfish OS were asked for comments about Android's new gesture interface.
Their answer : yawn.
Moto's implementation sounds better to me.
...and used to be the standard mode of operation since Palm's Pre (webOS powered).
Jolla Phone (Sailfish OS) has a similar general approach to gesture, except that in order to save on screen estate, they abandon the idea of a dedicated gesture area, and instead use the screen (e.g.: you swipe the *whole app's* main area or title bar to do a "back", instead of swiping under it) and screen edges (e.g.: you swipe from the right edge to go or peek at multitasking, instead of in a gesture area).
Due to fitt's law such gesture-based approaches are much better than "hunt the button" presses.
(Much older than that, PalmOS used to have a gesture area. Most of the time it was used to draw glyphs (replacement for a keyboard), but a lot of simple shortcuts where possible ( "\" + "C" : copy, etc. and also other shortcut to jump to apps) )
Obviously the vast majority of phone users do not do this, so I understand why the onscreen keyboard has won-out, but it would be nice if a single manufacturer made a ruggedized phone with a good physical keyboard.
Or at least leave enough access (pogo pin contacts, etc.) so 3rd party can easily manufacture after-market keyboards.
e.g.: TOHKBD (the other half - keyboard) back cover with magnetically sliding keyboard for the Jolla phone.
Same should also be possible for Fairphone 2 (has USB pogo pins available under the back cover for the exact purpose of this kind of extensions).
bad eating habits = too much sugar,
When you eat too much sugar, the body produces more insulin to force the sugar into the cells, cells get too much sugar, and reduce their insulin sensitivity. After a while, you see blood sugar rise, but the damage has already been going on for years, usually.
For added precision :
bad eating habits :
- high calorie intake (too much sugar and fat) : drives obesity up.
- too much *glucose*, i.e. *processed* sugar (In everyday's terms: pure sugar. Like the sugar-cubes equivalent in a soda can. As opposed to complex glucose polymers fibers, as found in nuts) and/or *very small low complexity oligomers* (starch. Like white bread. It doesn't taste sweet at all (there's very little actual pure sugar inside) but the starch gets broken up *extemely fast into glucose* during digestion. As opposed to whole grain bread which takes a bit more time. And as opposed to nuts, as mentionned above : their fibers takes a long time to digest).
When the glucose absoption is too fast (because the sugar is alredy processed as glucose, or because the starch gets digested too quickly),
the body keeps the blood glucose concentration low by quickly releasing peaks of insulin.
(Compare with eating nuts : they get digested into glucose extremely slowly and thus the glucose only enters the body drip by drip. Insulin only needs to be raised very slightly above basal level) (As a consequence, a type 1 diabetic doesn't usually give a fuck about nuts and doesn't need to take them into account when computing insulin injection dose)
This *very sudden* and *very high* rise of insulin causes :
- nearly all cells in the body will down-regulate their insulin receptors. They become more insulin resisting (eventually devolving into type 2 diabetes). And eventually glucose rises as a consequence.
The lone exception is the brain which use an entire different pathway (does not depend on insulin at all) and still keeps getting its sugar. (And this is part of the reasons why diabetes is much more destructive than fasting / any other protein-high diets)
- the high level of insulin also work as hormone and signal to the body. It encourages creating even more fat tissue storage (as opposed to use the sugar to build muscle mass). This worsens the obesity, which in turn works as a positive feedback, and is also a cause of heart diseases.
Once insulin resistance sets in :
- glucose remain in excess in the blood
- due to high concerntration you pee a lot (hence the name diabetis)
- as it doesn't enter in the cells (except the brain) the rest of the body thinks that it doesn't have any, and thus bruns fat and proteins instead, tries to synthetise glucose out of these, and asks the liver (through glucagon) to release some of the glucose from the reserves in the liver.
- but non of this extra glucose (synthetised or release) is of any help : the insulin still won't bring it in.
Damage comes from :
- High concentration of glucose. (Body has problems keeping the osmolarity of the blood). This eventually leads to blood vessels walls being damaged.
(Diabetes is mainly a blood vessel disease, mediated by the glucose concentration).
- Ketonic bodies toxicity. Because glucose can't enter most of the body, it's as if there was none and the body was fasting. In absence of (available) glucose, the body cells start to burn fat as an energy source (this requires to burn proteins as a by product of a missing reaction)
(this also produces ketonic bodies. These are toxic. Under normal circumstance (someone on a high protein, low carb diet), the brain cell would eat it and burn it as fuel source. But here the brain has access to plenty of glucose (remember : brain uses a different pathway to get its glucose and isn't affected by glucose) and thus will keep burning glucose, instead of burning ketonic bodies. These therefore accumulate and they end up being toxic)
Note:
- The above only concerns *glucose*.
- This doesn't concern al
Ingested carbs need to go somewhere. Brain consumes a bit, and the remaining part is the problem. If one has enough physical activity, carbs get burned in muscles. Otherwise, they are converted into fat,
not quite.
carbs don't just stay here waiting (like gaz in a car's tank)
body will process them, depending on tons of hormonal messages.
carbs will get used and making fat is only one of the possibility the body will choose.
e.g.: if you do sports, not only will you burn carbs for energy during the sport, but you will raise the level of some growth hormone, encouraging your body to use the available resources to build more mudcles instead of storing them in long term.
remain in bloodstream (this is diabetes) until cleared by kidneys.
huh.. Nope. not at all.
diabetis is absolutely not "the excess sugar in the blood".
diabetes is mainly the signaling pathway that normally orders the uptake of the sugar being broken.
the two types of diabetis are due to which step of the pathway is broken .
(either the production of insulin, or the receptors that should.detect it)
the fact that people who overeat have an increased risk of diabetis isnt due to extra sugar staying in the blood, it's due to the body getting desensitized tobthe insuline (mainly because to avoid having extra sugar in the blood the body will secrete extra insulin, but over time that extra insulin will down regulate the receptors, leading to the oathway not working that well anymore) (also fat tissue also secrete it's own signaling hormones. obese patients have so much of fat, that they produce excessive amiunt of some hormone and their signaling disturbs other pathway)
so excess sugar isn't the cause of diabetes (and is actually correctly compensated at the beginning) it's the result of an insulin pathway that got fucked up, e.g. by the bad eating habits.
Does the Git usage of SHA-1 *really* cause silent problems? I'm not sure how Git works internally but I was under the impression that it hashes whole objects, like individual source files at least.
The individual objects inside git aren't file.
The individual objects are commits (i.e..: the content of a patchfile, and a few information like pointer to other past commits to which this patch applies).
To make things easier, a handy number designates this commit - this is currently generated by SHA-1.
(Git is a content-addressable platform. You don't access object by name, you access them depending on their content. But instead of using the whole content to access them, you use addresses generated by SHA-1 to access the various blocks.
So to say which are the parent commits to which the patch in a commit applies, you just mention them by using the SHA-1 sum of the content of these commits).
A theoretical attack would be:
- try to generate 2 commits.
one adds a clean piece of code. the other adds a backdoored piece of code.
but both commits hash to the same SHA-1 so they would be considered as "the same content" by git.
Then try to force your target to re-download the whole repo from scratch from your backdoored history (otherwise git will simply ignore the commits with sha-1 sum that it already has - it thinks that it has the same content already).
In practice it's currently not doable.
The only thing that google managed to generate is a pair of block series. Each series contain completely random junk. Both series end-up generating the exact same shasum even if the random junk is different.
- That is exploitable in a PDF (or any other binary format that supports scripting. You could even do it in an EXE) : using the embed scripting present 2 different contents depending on which random junk is present.
- That is not exploitable in a sourcecode commit : you would need a believable explanation for why the random junk is present in the patched source code.
AND you would need a piece of code which reacts differently (normal vs. backdoor) depending on which random junk is present - to be able to pull that unnoticed would require "Underhanded C Contest"-level of ingenuity.
That's it, you only have blocks of random garbage.
Google currently can't produce hashes colliding from arbitrary pieces of data ("Hey google: here's is legit script A, and that's malicious script B. Add a small nonce at the end so they both end-up having the same sha-1sum") ("Actually don't add a nonce, that would be too conspicuous, try to tweak the punctuation in the comments instead")
Also as you mention, further edits will be problematic :
if I edit script A and submit a patch, this patch will be valid, but will completely fail on top of script B.
A cryptographic hash function has the properties you mention, plus the fact that it must not be easily reversible and uniformly distribute results over its entire output space.
The later is a property which is not guaranteed by most common checksums.
Thus, when you need a hash function to give a number to use as a handy "nickname" for a collection of data (e.g.: for a hash look-up table. Or for a content-addressable like git to create said addresses for a given content - and thus to give a serial number to a commit. Or apparently also used in SVN to give a simple number to designate commits), it might be a good choice to pick-up a cryptographic hash like SHA-1 because it guarantees you this additional property, which a vanilla checksum could lack.
If you only care about random bit flips CRC32 will work very well and be much faster than MD5 or SHA-1.
Well, not exactly.
- MD5 and SHA-1 have fast hardware implementation on some CPUs. CRC32 won't necessarily be a huge performance gain.
SHA-1 is used a bit more than a simple glorified checksum in GIT.
It is also used to give a handy number by which you designates commits, etc.
(i.e.: to compute a hash - e.g.: as would also be used in a hash look-up table).
That requires good output uniformity.
In other words you'd need a hashing function that "spreads" its output accross the whole output domain.
(to give an over-simplified examples: if due to a poor design, all patches ended-up having hashes that begins with the hex number "9", that would be a poor hashing function for these needs. If you used it in a hash lookup table, one part of the table would be over filled, while other would be still empty)
Cryptographic hashing functions offer these guarantees among lots of others. CRC32 doesn't, and several of the other checksums that were quickly designed for speed have also been detected not to offer these.
At this situation, a programmer can choose two paths :
- Some coder would try design their own new hashing which offers both good speed and the important properties (e.g.: That's exactly what LZ4's Yann Collet did, and created xxHash64. It's not a cryptographic hash, but at least offers all the properties that cyann needed)
- Other would instead jump to a quick'n'dirty solution, and go for the major overkill: take a cryptographic hash (e.g.: And that's what Linus Torvalds did. He's a lazy git. He knows that a cryptographic hash would provide all the properties he needs. SHA-1 is one that was popular back then, had even some hardware implementation. So he picked it and didn't think much about it. It offers all the properties Linus needed for git. It also offered much more but Linus didn't give a fuck about that. Though it doesn't offer security (anymore. specially since the google proof of concept) but that's something that Linus doesn't care and didn't even bother to check (as mentioned SHA-1 was already suspected backthen, and serious cryptographic usage relied on SHA-2 instead), relying instead on signed repositories if security is needed).
And on exactly what basis do you make this assumption?
It's NOT an assumption. It's the personal anecdotal experience of what is running on my phone.
I'm not from India, I'm from Europe.
I have a Microsoft account and it's configured to use a time-based OTP as a second factor in the 2 factor authentication.
I don't have biometrics configured as a way to log-in.
I don't even have my biometrics data stored in the Aadhaar database.
I installed Skype Lite (note: like with Facebook's "Lite" applications, you need to side-load it manually, because inside the Google Playstore the app is geo-restricted and the store will refuse to install it on smartphone outside the target market).
App asks me my credential, app asks me my 2nd factor.
That's it, it works.
At no point in time did it ask me to upload my biometrics into the Aadhaar database, nor did it even consider using biometrics as an authentication factor.
So even if Aadhaar is apparently a leaky mess of privacy violations, I'm not concerned by it.
My fingerprints are not going to get pwnd and leaked to the net by Aadhaar as they don't have them.
So okay, I'm a single data point. Maybe there are other factors that I'm overlooking.
But still, my personnal anecdotal experience is a good sign that people outside of India could be using Skype without beeing affected by Aadhaar's "peculiar" relationship with personal information and privacy.
The only limitation that I've seen is the Playstore's own geo-locking, preventing non-Idan google accounts to deploy the app. (This can easily be circumvented by manually installing).
No practical limitation would prevent a US user, like the top poster, to use it in the USA (just like I did) and enjoy a skype client that only uses a fractions of the resources that the current mainstream android app uses.
The same is similarily valid with Facebook Lite and Facebook Messenger Lite.
The big question I was trying to raise in my above post is :
- are young associate lawyers being made redundant by OCR and AI, to the point that they are fired and we see even less lawyers nowadays than before ?
or :
- are OCR and AI enabling the young associate lawyers to do much more work for the law firm (e.g.: now they can use google to search online through a large corpus of archive, instead of painstakingly going through microfiche in the basement of some government archive), so that the law firm can process even more lawsuits. To the point that we see even more and more lawsuits and other legal cases everywhere than there used to be in the past ?
My current impression of all the information I find online is that law suits and other legal proceedings are actually on the rise.
(e.g.: the several million of DMCA take-downs issued by the brazillian equivalent of **AA against an obscure "mp3toys" downloading website).
We're not seeing *less* laywers, we are seeing lawyers being more busy thanks to the modern computing tools.
Or in another field : Watson isn't putting medical doctors jobless on the street. Watson is helping process more of the simple stupid cases that could otherwise swamp a doctor's office. It helps doctors process even more patients cheaper than before thus bringing more affordable healthcare to the population.
Also, the survey taker will be more concerned about others' jobs (i.e.: jobs in general), because they see the over-all advances in AI (e.g.: speech recognition in Siri, automatic image tagging in Facebook, automatic face recognition nearly everywhere) and think that in general term, AI is progressing and one day might replace them...
But when they think about they own job (i.e.: they think about a specific area where they have expertise) they have much more insights on the details (they know all the intricacies of their crafts.
They might even have seen and/or tested some automation solution) and have noticed that we aren't quite there yet.
(e.g.: though speech recognition has made advances, automatic transcription isn't perfect for anything but the most easy cases. Youtube automatic captions still need to be corrected by a human. etc.).
Might even notice that robots are going to augment rather than replace them - as mentioned by others in this thread (AI is currently helping with the research work in law. It's not replacing attorney. Instead it's enabling a law firm to do much more without needing to hire more interns and assistants).
So hence the "my job" vs. "others' jobs" fears.
In addition of "not being frightened 'once a week by a robot' " as mentionned,
they might know that due to the specifics they know about their job, it won't exactly mean overnight take over by bots within the coming month.