Airplane is one of the uggliest words in American English. It makes the speaker sound like a child who has just rammed two words together, because there's absolutely no way to make the r and p sounds flow together.
I'd be shocked if it's only 800. One of the odd things learning one English if you're French is that the more complex English word is often the same as the French word (with some potentially embarrassing exceptions), whereas the more common version is typically a corrupted Saxon word. This is also interesting when you're speaking to a French person, because the temptation when speaking to a non-native speaker is to select more common versions of words, whereas the more formal or obscure terms are likely to be easier to understand.
I tried playing Balderdash[1] with some Italians a few years ago. They thought that I'd have an unfair advantage as a native speaker when we started, but after a couple of rounds where they'd all correctly written down the definitions, we gave up: all of the obscure English words from the cards were identical or very similar to much more common Italian words.
English has a very long tail. I believe it's estimated to have around 250,000 words. Most educated people know about 25,000 in total, and most people use 2,500 in normal conversation.
[1] A board game where you pick a card with an obscure word on it and everyone has to write down either the correct definition or a plausible definition that other people will guess when they're all read out.
Why do you assume that it's visible? Open source just means that you have the rights to make changes. This should be the requirement for all government procurement, because if the vendor goes out or business or EOLs the product then you're screwed if it isn't.
That's not how it worked, for two reasons. First, the Debian vulnerability meant that SSH private keys were generated with only about 16 bits of entropy, so became trivially guessable by brute force attacks. There was a long tail of people finding that they had vulnerable keys and replacing them for months after it was discovered. Some were in embedded devices where replacing the keys was very painful. Second, the people noticing a bug to exploit the vulnerability and the people noticing a bug to fix it are not the same. It was trivial to just use a different SSH on your own machines and leave everyone else vulnerable, if you found it in that time.
The fact of the matter is that every month dozens of new vulnerabilities in Windows come out. We're now at Microsoft KBnumber 4052231, and a significant fraction of those four million KBs address security issues.
Windows is pretty big. How does that number compare to Linux, plus glibc, plus glib, plus GTK, plus the core GNOME libraries, plus systemd, dbusd, and so on (i.e. the 2,000 or so open source packages that, combined, provide roughly equivalent functionality to the base Windows install)?
Someone says "but but but three years ago Heartbleed was in open source software", and I point to the 40 or so vulnerabilities published for Windows THIS MONTH, and EVERY MONTH.
And I can point to 40 in the Linux kernel's USB stack alone from this month (and we're only half way through the month). How many Windows kernel CVEs have there been?
I wonder... you seem to know your stuff pretty well. Have you ever designed something like that? Perhaps for fun? For your own usage? Because I would like to see that, and try it out. I'd support you.:)
I did, but before I knew most of the useful things that I know now and it made far more terrible mistakes than WebAssembly (which, for all it faults, is something that is probably easier to make fast than JavaScript). I don't think I ever put it online, so I'm probably safe from anyone finding it and pointing and laughing too hard.
My research area is cross-language interoperability, so this is the kind of thing I look at quite a lot. I'm interested in what the core building blocks are for different kinds of language and which ones should be provided as hardware functionality, OS features, or libraries. Most recently, I've been working on a set of architectural extensions for fine-grained memory safety, which lets you have languages like C and Java in the same address space without the C code being able to trample over the invariants that the Java code depends on.
Crashes might be covered by your insurance, but if the crash has a known-preventable cause then the insurance might not cover it, and if they do then your premiums are going to shoot up once they discover that you're not fixing known issues.
The guidance system for the F-35 is open source: the DoD receives from their contractors complete rights to modify and distribute the code. Open source doesn't mean publicly distributed or community developed.
You make it sound like that's hard for them to do with proprietary software. It's not like it's hard to get someone into a multinational company that hires developers all across the world or brings them into the US / EU on work visas. The difference with open source is that you can audit the code and if you find a vulnerability then you can fix it (or have a choice of companies to hire to fix it), you're not dependent on the original vendor.
Why? Open source means that they have the rights to modify the code. They can distribute an internal patch with a classified notice on it and keep the exploit for attacking others.
The main drive away from spooks doing this is that people keep pointing out to the people that control their funding how much critical infrastructure runs on the code that they're keeping vulnerable.
I like the idea of a smartwatch, but the technology is not there yet. They're at the same stage that the Nokia Communicator was in the smartphone market: they show you that something is possible, but it's not really something you want to carry around. My watch is 5mm thick (close to the upper limit for a thing I can completely forget is on my wrist) and has a battery that lasts 3-5 years. A watch that's more than double that thickness, and doesn't even last a week between charges (sure, I can charge it most nights, but I forget to plug my phone in some days and I'm sure I'd do the same on the watch - I also like my watch working on flights where I'm away from sensible charging facilities for more than 24 hours).
Hmm well when you support the left wing candidate for POTUS and support most all of the left wing ideology it kinda makes you left
Note for Americans wondering why they're confusing an international audience: A candidate that is bought and paid for by industry groups is not 'left' just because they are supported by different industry groups to the candidate who self identifies as 'right'.
And it's pretty clear that no one wants to target people with devices that are old enough to be unsupported on iOS; because they are usually the "poor" ones, anyway, LOL!
That's not how it works. Someone finds an exploit in iOS. Eventually someone else finds it and reports it (very often Google's Project Zero these days). The first people produce a tool to exploit it and sell it for a lot of money to somewhat unscrupulous people. Some of them then sell it for less money to other unscrupulous people. Eventually the tool is leaked and becomes public and any script kiddie can get hold of it. At this point, it's incorporated into exploit toolkits and lives there forever. If a script kiddie decides to attack an iOS device, then the tools that they have access to will have a load of exploits for vulnerabilities that are fixed in newer versions of iOS but still present in unsupported devices.
Oh, and you're assuming that the goal for exploiting the vulnerability is to steal money from the user. For mobile devices, it's more often used to gain entry to a corporate network. Lots of companies allow personal devices on the corporate network and only do perimeter security, so if you can compromise an old iPhone then you can use it to bypass the firewall and get in. For script kiddies, it's often just to cause some disruption. They may not be able to get anything out of the fact that they've used an iOS vulnerability to get into a random person's home network and either copy / release private data or just delete random stuff, but that doesn't make it any less disruptive.
Same reason there probably aren't a whole lot of new exploits being written for Windows 2000 or XP these days.
You'd be surprised - Win2K is still running on some high-value targets, especially industrial control systems, but new exploits aren't the only ones to worry about, just because a system is old doesn't mean that people delete the old exploits.
How were you installing it? The Firefox web page tells me to enter an email address, and it's no longer in F-Droid. I wish Mozilla would just provide an official F-Droid repo that I can add and get automatic updates.
I suspect that it's largely a requirement to be easy to implement in JavaScript (their incremental deployment model involves providing an inefficient but working JavaScript implementation). JavaScript doesn't allow non-reduceable control flow, so you need to expand it (you can do so, but by copying all of the possible control flow paths into things enabled with flags, which can end up with lots of code duplication).
For BT within the UK, at least, it's over separate fibre or separate circuit-switched partitions within fibres that may also carry Internet traffic, but the majority of the phone network, in spite of running IP, is not addressable from the Internet. This is done to guarantee QoS for the voice traffic.
If you send a lot of random shit at something, of course it's going to crash.
If your thread model for something that is expected to accept random crap from the Internet is 'it's fine as long as input is well formed', then you are going to have a lot of fun dealing with security vulnerabilities. Contrary to your assertion, well-written code does not crash when you send it a lot of random shit, it gracefully handles errors.
I was "into" Java, back then. I just didn't think anybody here would remember.
Jazelle was quite popular on mobile platforms (under 2MB of RAM). It ran the common Java bytecodes natively (arithmetic, local flow control), but called out to the VM for things like virtual dispatch. It provided a pretty good intermediate, but was largely overshadowed by JITs (if you're doing any optimisation, you're translating from Java bytecode into something else and generating native ARM code from that was usually easier than translating it back into Java bytecode).
. I would have no problem with WebAssembly, if it was independent of the browser/web world. Which I'm predicting it will move to.
It is an explicit goal of the wasm working group to have non-browser uses.
I'm wondering though, why they didn't just go with some low-level LLVM intermediary?
Because they included some people with PNaCl experience who had learned the hard way how bad an idea this is. LLVM IR is a target-specific compiler IR, it is explicitly not intended as a distribution format. Everyone (PNaCl, SPIR, and so on) who tries it eventually learns that it's a bad idea.
Or use another good existing bytecode. Hell, using the JVM would have been a fun idea.
Java bytecode is pretty closely coupled to the Java language and it's surprisingly painful to get it to work with other languages. CLR bytecode is better, but still not a great fit if you want to support languages with pointer arithmetic and no GC (I suppose you could do the asm.js thing and just allocate a huge buffer object and make pointers offsets into it, but that's pretty ugly. Mind you, it's not far off what wasm does).
But then I'm remembering this is the WhatTheFuckWG we're talking about.
Given the experience of the various people involved, it's pretty impressive how bad most of their design choices were. For example, pointers are integers (as an explicit choice in the IR, not as an implementation detail of a back end), so you can never use memory-safe hardware or later add GC, or to support function pointers without look-aside tables. The IR is stack-based (good for interpreters, bad for compilers, and supporting interpreters was an explicit non-goal). No non-reduceible control flow (so the verifier is marginally simpler, but life is harder for front ends and optimisers). Enforced stack discipline (so supporting non-C languages is quite challenging). Oh, and now they're thinking of adding vectors by picking a fixed-size vector, rather than the sane thing of letting front ends describe arbitrary sized vectors that match the exposed parallelism and letting optimisers roll them into loops for narrower targets.
WebAssembly is explicitly designed to be separate from a web browser. The working group is actively seeking non-web uses and has not provided DOM integration in the first versions (you must go via JavaScript to touch the DOM). Oh and the restriction on flow control in WebAssembly is brain dead: validating CFI for arbitrary graphs of basic blocks is a solved problem and was a decade ago, but trying to compile a C codebase using goto or some of the more interesting variations on a switch statement into WebAssembly requires O(n^2) algorithms and potentially an O(n^2) increase in bytecode size, which the WebAssembly JIT has to then undo to be able to generate something whose performance doesn't suck.
I'd be happy if they could pressure Intel into sticking an LPDDR4 controller on their existing cores if (as rumoured) the ones that were scheduled to have LPDDR4 controllers are delayed by another year. My work laptop is a late 2013 MBP and our budget assumes upgrades every three years. There's money in the budget for me to get a new one, but the main performance limit for me is RAM, so I'm not upgrading until I can get 32GB (and, no, a machine that uses 32GB DDR4 at 11-12W instead of LPDDR3 at 1-2W is not an acceptable alternative, unless it has hot-swap RAM support and can move between LPDDR3 and DDR4 based on whether it's on battery or mains).
A literal gun, no. But if you actually want to use your phone for anything important then having regular security updates is important and their lack is a virtual gun pointed at your personal (and corporate) data. Most Android phones get less than three years of security updates. If you're lucky, you can then wipe it and install LineageOS to get them until the community gets bored with your device. If you have an iOS device, you probably get 5 years and then the locked bootloader means that it will never be able to run an OS without known vulnerabilities.
I very much doubt that they do. Certainly none of the ones that I've worked with do, and if you can name one that does then I'll be very happy to avoid them like the plague. They sometimes have quite baroque back ends (I know of one financial services company that uses Smalltalk for their core back-end infrastructure and wraps it in Java for the middle layer, for example). I know some that use FreeBSD, quite a few that use VMS and more that use System/z. All of these are still supported and you'd find it hard to pass an audit if you didn't have a support story for your OS (even if it's 'we have the source code and an in-house support team' as was the case at one bank that's just finished the upgrade to FreeBSD 6).
I bought a Dell 1355 multifunction colour laser about 6-7 years ago (and had it for a whole two years before my mother borrowed and found it so useful she never gave it back). It had an Ethernet port and could talk SMB and FTP, so you can scan directly to a file server and emit PDFs (and you can print PDFs from there). It was about £100 new. I don't print much and found that I was spending a lot on my old inkjet because the ink would always have dried up and I'd end up buying a new cartridge for every 2-3 pages. The laser toner lasted the two years I had it and then the next three yeas that my mother had it before needing to be replaced.
For signing documents, I don't bother printing anymore - I just insert my signature into the PDF, run it through the print driver to generate a flattened PDF, and then email it back.
Slashdot Mirror
Airplane is one of the uggliest words in American English. It makes the speaker sound like a child who has just rammed two words together, because there's absolutely no way to make the r and p sounds flow together.
I'd be shocked if it's only 800. One of the odd things learning one English if you're French is that the more complex English word is often the same as the French word (with some potentially embarrassing exceptions), whereas the more common version is typically a corrupted Saxon word. This is also interesting when you're speaking to a French person, because the temptation when speaking to a non-native speaker is to select more common versions of words, whereas the more formal or obscure terms are likely to be easier to understand.
I tried playing Balderdash[1] with some Italians a few years ago. They thought that I'd have an unfair advantage as a native speaker when we started, but after a couple of rounds where they'd all correctly written down the definitions, we gave up: all of the obscure English words from the cards were identical or very similar to much more common Italian words.
English has a very long tail. I believe it's estimated to have around 250,000 words. Most educated people know about 25,000 in total, and most people use 2,500 in normal conversation.
[1] A board game where you pick a card with an obscure word on it and everyone has to write down either the correct definition or a plausible definition that other people will guess when they're all read out.
Why do you assume that it's visible? Open source just means that you have the rights to make changes. This should be the requirement for all government procurement, because if the vendor goes out or business or EOLs the product then you're screwed if it isn't.
That's not how it worked, for two reasons. First, the Debian vulnerability meant that SSH private keys were generated with only about 16 bits of entropy, so became trivially guessable by brute force attacks. There was a long tail of people finding that they had vulnerable keys and replacing them for months after it was discovered. Some were in embedded devices where replacing the keys was very painful. Second, the people noticing a bug to exploit the vulnerability and the people noticing a bug to fix it are not the same. It was trivial to just use a different SSH on your own machines and leave everyone else vulnerable, if you found it in that time.
The fact of the matter is that every month dozens of new vulnerabilities in Windows come out. We're now at Microsoft KBnumber 4052231, and a significant fraction of those four million KBs address security issues.
Windows is pretty big. How does that number compare to Linux, plus glibc, plus glib, plus GTK, plus the core GNOME libraries, plus systemd, dbusd, and so on (i.e. the 2,000 or so open source packages that, combined, provide roughly equivalent functionality to the base Windows install)?
Someone says "but but but three years ago Heartbleed was in open source software", and I point to the 40 or so vulnerabilities published for Windows THIS MONTH, and EVERY MONTH.
And I can point to 40 in the Linux kernel's USB stack alone from this month (and we're only half way through the month). How many Windows kernel CVEs have there been?
I wonder... you seem to know your stuff pretty well. Have you ever designed something like that? Perhaps for fun? For your own usage? Because I would like to see that, and try it out. I'd support you. :)
I did, but before I knew most of the useful things that I know now and it made far more terrible mistakes than WebAssembly (which, for all it faults, is something that is probably easier to make fast than JavaScript). I don't think I ever put it online, so I'm probably safe from anyone finding it and pointing and laughing too hard.
My research area is cross-language interoperability, so this is the kind of thing I look at quite a lot. I'm interested in what the core building blocks are for different kinds of language and which ones should be provided as hardware functionality, OS features, or libraries. Most recently, I've been working on a set of architectural extensions for fine-grained memory safety, which lets you have languages like C and Java in the same address space without the C code being able to trample over the invariants that the Java code depends on.
Crashes might be covered by your insurance, but if the crash has a known-preventable cause then the insurance might not cover it, and if they do then your premiums are going to shoot up once they discover that you're not fixing known issues.
The guidance system for the F-35 is open source: the DoD receives from their contractors complete rights to modify and distribute the code. Open source doesn't mean publicly distributed or community developed.
You make it sound like that's hard for them to do with proprietary software. It's not like it's hard to get someone into a multinational company that hires developers all across the world or brings them into the US / EU on work visas. The difference with open source is that you can audit the code and if you find a vulnerability then you can fix it (or have a choice of companies to hire to fix it), you're not dependent on the original vendor.
Why? Open source means that they have the rights to modify the code. They can distribute an internal patch with a classified notice on it and keep the exploit for attacking others.
The main drive away from spooks doing this is that people keep pointing out to the people that control their funding how much critical infrastructure runs on the code that they're keeping vulnerable.
I like the idea of a smartwatch, but the technology is not there yet. They're at the same stage that the Nokia Communicator was in the smartphone market: they show you that something is possible, but it's not really something you want to carry around. My watch is 5mm thick (close to the upper limit for a thing I can completely forget is on my wrist) and has a battery that lasts 3-5 years. A watch that's more than double that thickness, and doesn't even last a week between charges (sure, I can charge it most nights, but I forget to plug my phone in some days and I'm sure I'd do the same on the watch - I also like my watch working on flights where I'm away from sensible charging facilities for more than 24 hours).
Hmm well when you support the left wing candidate for POTUS and support most all of the left wing ideology it kinda makes you left
Note for Americans wondering why they're confusing an international audience: A candidate that is bought and paid for by industry groups is not 'left' just because they are supported by different industry groups to the candidate who self identifies as 'right'.
And it's pretty clear that no one wants to target people with devices that are old enough to be unsupported on iOS; because they are usually the "poor" ones, anyway, LOL!
That's not how it works. Someone finds an exploit in iOS. Eventually someone else finds it and reports it (very often Google's Project Zero these days). The first people produce a tool to exploit it and sell it for a lot of money to somewhat unscrupulous people. Some of them then sell it for less money to other unscrupulous people. Eventually the tool is leaked and becomes public and any script kiddie can get hold of it. At this point, it's incorporated into exploit toolkits and lives there forever. If a script kiddie decides to attack an iOS device, then the tools that they have access to will have a load of exploits for vulnerabilities that are fixed in newer versions of iOS but still present in unsupported devices.
Oh, and you're assuming that the goal for exploiting the vulnerability is to steal money from the user. For mobile devices, it's more often used to gain entry to a corporate network. Lots of companies allow personal devices on the corporate network and only do perimeter security, so if you can compromise an old iPhone then you can use it to bypass the firewall and get in. For script kiddies, it's often just to cause some disruption. They may not be able to get anything out of the fact that they've used an iOS vulnerability to get into a random person's home network and either copy / release private data or just delete random stuff, but that doesn't make it any less disruptive.
Same reason there probably aren't a whole lot of new exploits being written for Windows 2000 or XP these days.
You'd be surprised - Win2K is still running on some high-value targets, especially industrial control systems, but new exploits aren't the only ones to worry about, just because a system is old doesn't mean that people delete the old exploits.
How were you installing it? The Firefox web page tells me to enter an email address, and it's no longer in F-Droid. I wish Mozilla would just provide an official F-Droid repo that I can add and get automatic updates.
I don't think I can answer that question without violating an NDA.
I suspect that it's largely a requirement to be easy to implement in JavaScript (their incremental deployment model involves providing an inefficient but working JavaScript implementation). JavaScript doesn't allow non-reduceable control flow, so you need to expand it (you can do so, but by copying all of the possible control flow paths into things enabled with flags, which can end up with lots of code duplication).
For BT within the UK, at least, it's over separate fibre or separate circuit-switched partitions within fibres that may also carry Internet traffic, but the majority of the phone network, in spite of running IP, is not addressable from the Internet. This is done to guarantee QoS for the voice traffic.
If you send a lot of random shit at something, of course it's going to crash.
If your thread model for something that is expected to accept random crap from the Internet is 'it's fine as long as input is well formed', then you are going to have a lot of fun dealing with security vulnerabilities. Contrary to your assertion, well-written code does not crash when you send it a lot of random shit, it gracefully handles errors.
Why would you do cryptocurrency mining in JavaScript on the CPU, when JavaScript implies WebCL and WebGL and lets you offload to the GPU?
I was "into" Java, back then. I just didn't think anybody here would remember.
Jazelle was quite popular on mobile platforms (under 2MB of RAM). It ran the common Java bytecodes natively (arithmetic, local flow control), but called out to the VM for things like virtual dispatch. It provided a pretty good intermediate, but was largely overshadowed by JITs (if you're doing any optimisation, you're translating from Java bytecode into something else and generating native ARM code from that was usually easier than translating it back into Java bytecode).
. I would have no problem with WebAssembly, if it was independent of the browser/web world. Which I'm predicting it will move to.
It is an explicit goal of the wasm working group to have non-browser uses.
I'm wondering though, why they didn't just go with some low-level LLVM intermediary?
Because they included some people with PNaCl experience who had learned the hard way how bad an idea this is. LLVM IR is a target-specific compiler IR, it is explicitly not intended as a distribution format. Everyone (PNaCl, SPIR, and so on) who tries it eventually learns that it's a bad idea.
Or use another good existing bytecode. Hell, using the JVM would have been a fun idea.
Java bytecode is pretty closely coupled to the Java language and it's surprisingly painful to get it to work with other languages. CLR bytecode is better, but still not a great fit if you want to support languages with pointer arithmetic and no GC (I suppose you could do the asm.js thing and just allocate a huge buffer object and make pointers offsets into it, but that's pretty ugly. Mind you, it's not far off what wasm does).
But then I'm remembering this is the WhatTheFuckWG we're talking about.
Given the experience of the various people involved, it's pretty impressive how bad most of their design choices were. For example, pointers are integers (as an explicit choice in the IR, not as an implementation detail of a back end), so you can never use memory-safe hardware or later add GC, or to support function pointers without look-aside tables. The IR is stack-based (good for interpreters, bad for compilers, and supporting interpreters was an explicit non-goal). No non-reduceible control flow (so the verifier is marginally simpler, but life is harder for front ends and optimisers). Enforced stack discipline (so supporting non-C languages is quite challenging). Oh, and now they're thinking of adding vectors by picking a fixed-size vector, rather than the sane thing of letting front ends describe arbitrary sized vectors that match the exposed parallelism and letting optimisers roll them into loops for narrower targets.
WebAssembly is explicitly designed to be separate from a web browser. The working group is actively seeking non-web uses and has not provided DOM integration in the first versions (you must go via JavaScript to touch the DOM). Oh and the restriction on flow control in WebAssembly is brain dead: validating CFI for arbitrary graphs of basic blocks is a solved problem and was a decade ago, but trying to compile a C codebase using goto or some of the more interesting variations on a switch statement into WebAssembly requires O(n^2) algorithms and potentially an O(n^2) increase in bytecode size, which the WebAssembly JIT has to then undo to be able to generate something whose performance doesn't suck.
I'd be happy if they could pressure Intel into sticking an LPDDR4 controller on their existing cores if (as rumoured) the ones that were scheduled to have LPDDR4 controllers are delayed by another year. My work laptop is a late 2013 MBP and our budget assumes upgrades every three years. There's money in the budget for me to get a new one, but the main performance limit for me is RAM, so I'm not upgrading until I can get 32GB (and, no, a machine that uses 32GB DDR4 at 11-12W instead of LPDDR3 at 1-2W is not an acceptable alternative, unless it has hot-swap RAM support and can move between LPDDR3 and DDR4 based on whether it's on battery or mains).
A literal gun, no. But if you actually want to use your phone for anything important then having regular security updates is important and their lack is a virtual gun pointed at your personal (and corporate) data. Most Android phones get less than three years of security updates. If you're lucky, you can then wipe it and install LineageOS to get them until the community gets bored with your device. If you have an iOS device, you probably get 5 years and then the locked bootloader means that it will never be able to run an OS without known vulnerabilities.
I very much doubt that they do. Certainly none of the ones that I've worked with do, and if you can name one that does then I'll be very happy to avoid them like the plague. They sometimes have quite baroque back ends (I know of one financial services company that uses Smalltalk for their core back-end infrastructure and wraps it in Java for the middle layer, for example). I know some that use FreeBSD, quite a few that use VMS and more that use System/z. All of these are still supported and you'd find it hard to pass an audit if you didn't have a support story for your OS (even if it's 'we have the source code and an in-house support team' as was the case at one bank that's just finished the upgrade to FreeBSD 6).
I bought a Dell 1355 multifunction colour laser about 6-7 years ago (and had it for a whole two years before my mother borrowed and found it so useful she never gave it back). It had an Ethernet port and could talk SMB and FTP, so you can scan directly to a file server and emit PDFs (and you can print PDFs from there). It was about £100 new. I don't print much and found that I was spending a lot on my old inkjet because the ink would always have dried up and I'd end up buying a new cartridge for every 2-3 pages. The laser toner lasted the two years I had it and then the next three yeas that my mother had it before needing to be replaced.
For signing documents, I don't bother printing anymore - I just insert my signature into the PDF, run it through the print driver to generate a flattened PDF, and then email it back.