When you say 'Europeanese' you mean 'English', though you're right that the word or close variants appear in many European languages. When you say 'wholesale' you mean 'retail'. When you say 'mall' you mean 'shop'. But aside from that, your sentence was correct.
Open source voting machines mean that anyone can inspect the hardware and software to find bugs
This is a nonsense argument, because open source does not mean freely available for anyone to download, it means that the customers of the voting machines have full access to the code and can inspect, modify, recompile and (if they wish) redistribute it.
That said, this policy from the Greens does show that they completely miss the point. You only have an open and fair election if the overwhelming majority of the electorate are able to audit the elections.
In a UK election, where we use paper ballots, auditors must watch the votes being cast and ensure that they go into the box. They must watch the boxes being carries to the counting stations and ensure that they make it and no votes are added or removed from the box on the way. They must then watch the votes being taken from the boxes and put into piles based on which square contains a cross. Anyone who is not blind can do this. If the sizes of the piles do not roughly correspond to the final tally, then they can request a recount and anyone who is basically numerate can manage this.
Now contrast this with a situation in which you have electronic voting machines. How many people are capable of looking at the entries in the Underhanded C Contest and spotting the malicious behaviour? In that controlled situation, you have small programs and you know that there is something underhanded going on. I'd be willing to bet that under 100 people in the USA are able to audit an electronic voting system and say, with a high level of confidence, that it doesn't contain any malicious code that can affect the results, even if the code is publicly available online. Do you really want to trust your election to the honesty of these people?
One of the down sides of global warming getting so much press is that people have started to conflate carbon dioxide with pollution. Releasing carbon dioxide into the atmosphere in large quantities is a bad idea, but it's far from the only thing that coal-fired plants pump out in large quantities. In particular, the effects of carbon dioxide are global, whereas most of the other pollutants have a more significant local effect.
Mostly it was the RAM. 64MB of RAM meant that the OOM killer ran a lot and always managed to pick the app with the most unsaved data to kill. It was great for running vim in an xterm, not so good for anything else.
No, and I'm not sure how you'd get that from what I said. In this case, from the evidence that I've seen, the majority are probably right, but that are right because of their application of the scientific method, not because they are the majority.
It's also worth remembering that the margin for error in calorie counts in chains is aroudn 1-2%, but the permitted margin of error by the FDA is a lot higher (I think 20%, but I'm not completely sure), so you can bet that the printed counts are all below by the maximum permitted amount.
You're redefining intelligence to mean pattern recognition. If this is artificial intelligence, then a moth possesses natural intelligence. Just because it uses a neural network doesn't mean that it comes close to any prior definition of intelligence.
It's not Tesla's fault that Android is insecure. It is Tesla's fault that they encourage customers to use an app on a known-to-be-horribly-insecure platform to lock and unlock their car.
The problem with this argument is that, until Eddington, the overwhelming scientific consensus was that Newton was right and Einstein was wrong. The argument shouldn't be that only 24 papers have been published on one side and 13,926 on the other side, it should be that every one of those 24 articles has subsequently been shown to have flawed data, flawed methodology, or both. And, given that it's only 24, that should have been really easy. Spending a long post arguing that the majority is on one side shows a rather disturbing lack of understanding of how science works.
I've tried the current offerings. There's almost no lag, which is not quite close enough to no lag to stop me from getting motion sick. There are about a dozen depth clues that a typical human uses and current VR systems are able to replicate around a quarter of them. Even getting rid of the lag, you're still going to make a sizeable proportion of the population motion sick.
Mac OS X's libc is so far behind what's in NetBSD or FreeBSD it's almost laughable. There are a so many missing function calls–– I write software that's portable to Linux, NetBSD, and FreeBSD; it won't build on MacOS without major extra effort to close the gaps.
What were you missing? There's been some slow movement inside Apple to start treating FreeBSD libc as an upstream vendor platform, to push their changes upstream, and do a new import. I'd be interested in what they're lacking, as it would probably help push this along a bit.
I'm not sure that it has all the features and applications that NeXTstep had
GNUstep aimed to implement the OpenStep APIs. Related projects have implemented various apps, but GNUstep itself is a developer platform.
GNUstep has been tracking Cocoa, rather than OpenStep, for over a decade now. Some things are mature, others are missing (CoreAnimation is the big omission, unfortunately).
You're right about Meego, but it's worth noting that Meego was a descendant of Maemo. I had a Maemo device in 2005. It was pretty crappy, but it did predate the iPhone by a couple of years.
Major corporate-sponsored permissive-licensed OSS didn't even take off until years after the GPL had established itself
Nonsense. Major BSD UNIX vendors were actively working with upstream sources for BSD-licensed programs back in the '80s. Sun developed and open sourced NFS under a permissive license in 1984. Version 1 of the GPL was released in 1989. Sendmail and Bind both predate the GPL and were developed with commercial backing, as were most of the pieces of software that made the Internet possible.
The anti-GPL / pro-permissive position is, for the most part, completely disconnected with reality.
Pot, meet kettle.
There are multiple real-life examples showing us of how this can go badly for permissive and multiple real-life examples of how GPL enforcement can lead to very worthy projects appearing
And then there's the one that the FSF spent a decade shouting about, where they forced NeXT to release the source for their Objective-C compiler code in GCC (but not the Objective-C runtime, without which it was useless), only to discover the code was absolute crap that they'd never have accepted upstream if they'd had it contributed, but which they then had to accept for political reasons. In contrast, the code in Clang for doing the same thing is far cleaner, more modular, and supports multiple runtime implementations.
No one forces you to use GPL code that other people have written.
And that's the core of the issue. If your choice is using a GPL'd library or program or writing something in-house, a lot of companies will pick the latter. Often you can persuade them to open source it (it's not usually anything that gives them a competitive advantage) and if it's permissively licensed then others will contribute upstream too. I've come across several companies that will hoard their changes to GPL'd projects that they use internally (which they're allowed to do, as they're not distributing it) because they're afraid of legal repercussions, but at the same time will push all of their changes to BSD-licensed projects upstream.
One new in 10.12 is they borked Qt's tooltips and menus, which have worked since 10.6.8 through 10.11
You have always been able to spot Qt apps on OS X: they're the ones that look ugly and where even basic things such as text fields don't respect the HIGs (for years, they managed to have different keyboard shortcuts for skipping words / lines in a text field to every other OS X app), so you'll forgive me if I suspect that this is more likely to be Qt's fault.
It's worth noting that robotic sheepdogs were effectively perfected well over a decade ago (John Billingsley worked on them), yet I've never seen one in use outside of a tech demo, because dogs are a lot cheaper, even factoring in the requirement for human supervision (the robotic ones can round up the cows, herd them through the milking machines, and back out into the field, without supervision).
Modern farms use so much automation already that the cost of the humans is really small, except in a few specialised cases (fruit picking, for example, is still very labour intensive and the machines that can do it are very complex and so far this means unreliable and expensive).
Farming will almost certainly be completely automated at some point, but it's unlikely to be a priority because all of the low-hanging fruit (if you'll pardon the pun) for automation has been picked.
Simple math, more people dislike Trump than Clinton as he got fewer votes.
That doesn't follow. Around 5 million people who voted Democrat last time and 10 million people who voted Democrat the time before didn't consider Clinton to be the lesser of two evils and so didn't bother to vote. The difference in unpopularity between the two is in the noise.
Checking is difficult. One of my colleagues has been involved in some of this auditing. There are some precincts that have counted more votes than were cast, but quite a large margin (I don't know which ones they were, so I can't tell how likely they were to affect the Electoral College outcome - that's something they're still checking). These precincts were all using pure electronic systems, so there's no paper trail and no way of doing a recount, the only thing that they can do is rerun the election there (and that's very unlikely).
But writing them portably was not - Unix's single greatest contribution was proving that you can write a portable operating system
Not really. The first 'port' of UNIX involved rewriting it in a completely different language. Subsequent ports involved massive rewrites of large portions. It wasn't until around 3BSD - long after Bell Labs had ceased to be the driving force behind it - that the pmap abstractions were introduced. The only reason that UNIX was portable was that it had such low hardware requirements: it didn't take advantage of any complex features and so you could implement something that provided the same interfaces on any hardware that met a very, very low bar. Remember, the original UNIX didn't support shared libraries, didn't support virtual memory, didn't support networks, and didn't support any I/O devices that weren't simple streams of bytes (e.g. raster displays).
nobody tried to write one in a compiled language until Kernighan and Ritchie
That's simply not true. MULTICS was written in PL/1, the B5000 (1961) had an OS written in ALGOL60. Writing operating systems in high-level languages was common by the time UNIX came along, it was only rare on the very cheapest computers (where UNIX ran), and UNIX was written in assembly until the PDP-11 port.
QA catches the low hanging fruit. Formal verification catches more (but even then, bugs in your specification can be a problem). seL4 currently has the record for the most efficient formal verification workflow and it cost around 30 times as much as doing best-of-breed QA. Oh, the spec didn't cover everything so it was about 6 hours between open sourcing the code and someone finding a security hole in the system call handler.
We can do this with civil engineering projects because they're fairly simple (physical systems are limited in the number of interacting parts by 3D physical space - software components are not and any given bit of code may have direct interactions with hundreds of others and second order interactions with vastly more) and because we've been doing them for a long time.
MIPS is a horrible ISA (and I say this as someone who works on a MIPS compiler). Branch delay slots haven't made much sense since pipelines grew to be longer than three stages (and the branch likely instructions with their delay slots that are only used sometimes are a pain to model). The lack of complex addressing modes makes low-power designs hard (putting an add and a shift into your load pipeline is cheap, adding an extra instruction or two for every load or store is not). The ABIs are all horrible; the lack of PC-relative addressing means that you have to use a jr / jalr $t9 for every function call so that the function knows that $t9 contains the PC on entry. The proliferation of incompatible extensions makes building portable binaries a pain if you want good performance.
MIPSr6 is a mediocre instruction set. It's not bad, but it's not particularly good either. It also loses the one thing of value that MIPS had: backwards compatibility. You can run MIPS I code on a MIPS64r2 core, but a MIPS32r6 core needs binary translation to be able to do the same, and if you're going to do binary translation then you might as well use ARM and benefit from an ecosystem that has a huge amount of investment.
The Alpha was not slow for then, but by modern standards the 400MHz Alphas that were common in Windows NT Alpha machines are slow: my low-end smartphone is faster. The speed of the Alpha was part of the reason FX32! worked so well: a typical Alpha was about twice the speed of the fastet processor Intel sold, so even paying a pretty high emulation penalty let you run things very fast.
This isn't the case with ARM, and especially the kinds of ARM cores that you're likely to find in mobile devices. They're not faster than desktop x86 processors, though they might be a lot faster than the processors that legacy applications were designed to run on.
Slashdot Mirror
When you say 'Europeanese' you mean 'English', though you're right that the word or close variants appear in many European languages. When you say 'wholesale' you mean 'retail'. When you say 'mall' you mean 'shop'. But aside from that, your sentence was correct.
Open source voting machines mean that anyone can inspect the hardware and software to find bugs
This is a nonsense argument, because open source does not mean freely available for anyone to download, it means that the customers of the voting machines have full access to the code and can inspect, modify, recompile and (if they wish) redistribute it. That said, this policy from the Greens does show that they completely miss the point. You only have an open and fair election if the overwhelming majority of the electorate are able to audit the elections.
In a UK election, where we use paper ballots, auditors must watch the votes being cast and ensure that they go into the box. They must watch the boxes being carries to the counting stations and ensure that they make it and no votes are added or removed from the box on the way. They must then watch the votes being taken from the boxes and put into piles based on which square contains a cross. Anyone who is not blind can do this. If the sizes of the piles do not roughly correspond to the final tally, then they can request a recount and anyone who is basically numerate can manage this.
Now contrast this with a situation in which you have electronic voting machines. How many people are capable of looking at the entries in the Underhanded C Contest and spotting the malicious behaviour? In that controlled situation, you have small programs and you know that there is something underhanded going on. I'd be willing to bet that under 100 people in the USA are able to audit an electronic voting system and say, with a high level of confidence, that it doesn't contain any malicious code that can affect the results, even if the code is publicly available online. Do you really want to trust your election to the honesty of these people?
One of the down sides of global warming getting so much press is that people have started to conflate carbon dioxide with pollution. Releasing carbon dioxide into the atmosphere in large quantities is a bad idea, but it's far from the only thing that coal-fired plants pump out in large quantities. In particular, the effects of carbon dioxide are global, whereas most of the other pollutants have a more significant local effect.
Mostly it was the RAM. 64MB of RAM meant that the OOM killer ran a lot and always managed to pick the app with the most unsaved data to kill. It was great for running vim in an xterm, not so good for anything else.
So, you're saying the minority is always right?
No, and I'm not sure how you'd get that from what I said. In this case, from the evidence that I've seen, the majority are probably right, but that are right because of their application of the scientific method, not because they are the majority.
It's also worth remembering that the margin for error in calorie counts in chains is aroudn 1-2%, but the permitted margin of error by the FDA is a lot higher (I think 20%, but I'm not completely sure), so you can bet that the printed counts are all below by the maximum permitted amount.
You're redefining intelligence to mean pattern recognition. If this is artificial intelligence, then a moth possesses natural intelligence. Just because it uses a neural network doesn't mean that it comes close to any prior definition of intelligence.
It's not Tesla's fault that Android is insecure. It is Tesla's fault that they encourage customers to use an app on a known-to-be-horribly-insecure platform to lock and unlock their car.
The problem with this argument is that, until Eddington, the overwhelming scientific consensus was that Newton was right and Einstein was wrong. The argument shouldn't be that only 24 papers have been published on one side and 13,926 on the other side, it should be that every one of those 24 articles has subsequently been shown to have flawed data, flawed methodology, or both. And, given that it's only 24, that should have been really easy. Spending a long post arguing that the majority is on one side shows a rather disturbing lack of understanding of how science works.
I've tried the current offerings. There's almost no lag, which is not quite close enough to no lag to stop me from getting motion sick. There are about a dozen depth clues that a typical human uses and current VR systems are able to replicate around a quarter of them. Even getting rid of the lag, you're still going to make a sizeable proportion of the population motion sick.
Mac OS X's libc is so far behind what's in NetBSD or FreeBSD it's almost laughable. There are a so many missing function calls–– I write software that's portable to Linux, NetBSD, and FreeBSD; it won't build on MacOS without major extra effort to close the gaps.
What were you missing? There's been some slow movement inside Apple to start treating FreeBSD libc as an upstream vendor platform, to push their changes upstream, and do a new import. I'd be interested in what they're lacking, as it would probably help push this along a bit.
I'm not sure that it has all the features and applications that NeXTstep had
GNUstep aimed to implement the OpenStep APIs. Related projects have implemented various apps, but GNUstep itself is a developer platform. GNUstep has been tracking Cocoa, rather than OpenStep, for over a decade now. Some things are mature, others are missing (CoreAnimation is the big omission, unfortunately).
You're right about Meego, but it's worth noting that Meego was a descendant of Maemo. I had a Maemo device in 2005. It was pretty crappy, but it did predate the iPhone by a couple of years.
Major corporate-sponsored permissive-licensed OSS didn't even take off until years after the GPL had established itself
Nonsense. Major BSD UNIX vendors were actively working with upstream sources for BSD-licensed programs back in the '80s. Sun developed and open sourced NFS under a permissive license in 1984. Version 1 of the GPL was released in 1989. Sendmail and Bind both predate the GPL and were developed with commercial backing, as were most of the pieces of software that made the Internet possible.
The anti-GPL / pro-permissive position is, for the most part, completely disconnected with reality.
Pot, meet kettle.
There are multiple real-life examples showing us of how this can go badly for permissive and multiple real-life examples of how GPL enforcement can lead to very worthy projects appearing
And then there's the one that the FSF spent a decade shouting about, where they forced NeXT to release the source for their Objective-C compiler code in GCC (but not the Objective-C runtime, without which it was useless), only to discover the code was absolute crap that they'd never have accepted upstream if they'd had it contributed, but which they then had to accept for political reasons. In contrast, the code in Clang for doing the same thing is far cleaner, more modular, and supports multiple runtime implementations.
No one forces you to use GPL code that other people have written.
And that's the core of the issue. If your choice is using a GPL'd library or program or writing something in-house, a lot of companies will pick the latter. Often you can persuade them to open source it (it's not usually anything that gives them a competitive advantage) and if it's permissively licensed then others will contribute upstream too. I've come across several companies that will hoard their changes to GPL'd projects that they use internally (which they're allowed to do, as they're not distributing it) because they're afraid of legal repercussions, but at the same time will push all of their changes to BSD-licensed projects upstream.
One new in 10.12 is they borked Qt's tooltips and menus, which have worked since 10.6.8 through 10.11
You have always been able to spot Qt apps on OS X: they're the ones that look ugly and where even basic things such as text fields don't respect the HIGs (for years, they managed to have different keyboard shortcuts for skipping words / lines in a text field to every other OS X app), so you'll forgive me if I suspect that this is more likely to be Qt's fault.
Modern farms use so much automation already that the cost of the humans is really small, except in a few specialised cases (fruit picking, for example, is still very labour intensive and the machines that can do it are very complex and so far this means unreliable and expensive).
Farming will almost certainly be completely automated at some point, but it's unlikely to be a priority because all of the low-hanging fruit (if you'll pardon the pun) for automation has been picked.
The solid password that you can remember is the one that you use to protect your password manager. All of the others are randomly generated.
Simple math, more people dislike Trump than Clinton as he got fewer votes.
That doesn't follow. Around 5 million people who voted Democrat last time and 10 million people who voted Democrat the time before didn't consider Clinton to be the lesser of two evils and so didn't bother to vote. The difference in unpopularity between the two is in the noise.
Checking is difficult. One of my colleagues has been involved in some of this auditing. There are some precincts that have counted more votes than were cast, but quite a large margin (I don't know which ones they were, so I can't tell how likely they were to affect the Electoral College outcome - that's something they're still checking). These precincts were all using pure electronic systems, so there's no paper trail and no way of doing a recount, the only thing that they can do is rerun the election there (and that's very unlikely).
But writing them portably was not - Unix's single greatest contribution was proving that you can write a portable operating system
Not really. The first 'port' of UNIX involved rewriting it in a completely different language. Subsequent ports involved massive rewrites of large portions. It wasn't until around 3BSD - long after Bell Labs had ceased to be the driving force behind it - that the pmap abstractions were introduced. The only reason that UNIX was portable was that it had such low hardware requirements: it didn't take advantage of any complex features and so you could implement something that provided the same interfaces on any hardware that met a very, very low bar. Remember, the original UNIX didn't support shared libraries, didn't support virtual memory, didn't support networks, and didn't support any I/O devices that weren't simple streams of bytes (e.g. raster displays).
nobody tried to write one in a compiled language until Kernighan and Ritchie
That's simply not true. MULTICS was written in PL/1, the B5000 (1961) had an OS written in ALGOL60. Writing operating systems in high-level languages was common by the time UNIX came along, it was only rare on the very cheapest computers (where UNIX ran), and UNIX was written in assembly until the PDP-11 port.
QA catches the low hanging fruit. Formal verification catches more (but even then, bugs in your specification can be a problem). seL4 currently has the record for the most efficient formal verification workflow and it cost around 30 times as much as doing best-of-breed QA. Oh, the spec didn't cover everything so it was about 6 hours between open sourcing the code and someone finding a security hole in the system call handler.
We can do this with civil engineering projects because they're fairly simple (physical systems are limited in the number of interacting parts by 3D physical space - software components are not and any given bit of code may have direct interactions with hundreds of others and second order interactions with vastly more) and because we've been doing them for a long time.
That's nothing. In recent polls in the Crimea, 106% of residents were in favour of Russia.
MIPS is a horrible ISA (and I say this as someone who works on a MIPS compiler). Branch delay slots haven't made much sense since pipelines grew to be longer than three stages (and the branch likely instructions with their delay slots that are only used sometimes are a pain to model). The lack of complex addressing modes makes low-power designs hard (putting an add and a shift into your load pipeline is cheap, adding an extra instruction or two for every load or store is not). The ABIs are all horrible; the lack of PC-relative addressing means that you have to use a jr / jalr $t9 for every function call so that the function knows that $t9 contains the PC on entry. The proliferation of incompatible extensions makes building portable binaries a pain if you want good performance.
MIPSr6 is a mediocre instruction set. It's not bad, but it's not particularly good either. It also loses the one thing of value that MIPS had: backwards compatibility. You can run MIPS I code on a MIPS64r2 core, but a MIPS32r6 core needs binary translation to be able to do the same, and if you're going to do binary translation then you might as well use ARM and benefit from an ecosystem that has a huge amount of investment.
The Alpha CPU wasn't slow, even for then,
The Alpha was not slow for then, but by modern standards the 400MHz Alphas that were common in Windows NT Alpha machines are slow: my low-end smartphone is faster. The speed of the Alpha was part of the reason FX32! worked so well: a typical Alpha was about twice the speed of the fastet processor Intel sold, so even paying a pretty high emulation penalty let you run things very fast.
This isn't the case with ARM, and especially the kinds of ARM cores that you're likely to find in mobile devices. They're not faster than desktop x86 processors, though they might be a lot faster than the processors that legacy applications were designed to run on.