Laws should be written in such a way that the technology involved doesn't matter
Laws often apply to situations that didn't exist before some technology was invented. There was no little need to regulate traffic when a horse drawn cart on a rickety road was the fastest anyone went. There was no need to regulate wiretapping before the telephone was invented. There was no need to regulate the aggregation of large amount of personal data before large datacentres became cost effective to build, and so on. There may be some debate over whether hand-gun ownership should be regulated, but the invention of portable rocket launchers that could level buildings meant that at least some form of regulation was needed for private militias.
I believe that HURD is now GPLv3. GPLv3 is not GPLv2-compatible (it imposes conditions not present in GPLv2) and so you can not link GPLv2 code into a GPLv3 project. Most GPL'd projects include the 'or later versions' clause, but Linux is GPLv2 only, so none of its code can ever end up in GPLv3 projects.
I suspect that most people would happily work at a job that fit their interests, and that they found psychologically rewarding; the problem, of course, is that most jobs (and especially the kinds of jobs that are available to untrained/uneducated people) are of the tedious and mind-numbing variety.
A lot of what makes those jobs awful is the attitude of the employers. Compare working in a small shop to working in Walmart. Even if you're doing effectively the same thing, working in the small shop is likely to be a lot more rewarding because you're not being constantly treated as a replaceable and dispensable cog in a machine. If Walmart didn't have a ready supply of cheap labour then they'd have to improve worker conditions to make it a more attractive place to work.
Even a factor of 100 for truly exceptional people seems fine to me. I personally consider most sports personalities to be a colossal waste of space, but if what they're doing is enjoyed by a few million people and those people are willing to redistribute enough of their wealth in that direction that they can git the 100x-the-poorest line then I won't object. But when the difference is a factor of well over 1,000,000 that it's difficult to accept. When some people's annual income solely from owning property is greater than many people earn in total from working their entire life, it's hard to justify.
Yes you do have to just accept what the majority decides will be the law. That is how democracy (and all flavours of) work.
With minor variations, that's how all forms of society work. It is very difficult to rule without the consent of the governed. Even in a despotism, your army can't be everywhere enforcing your will and eventually people will stop doing the things necessary for your society to function and it will collapse. Or they'll come around with pitchforks and flaming torches one evening.
That said, slavery is never a stable situation. It produces economic imbalances when you have a lot more people producing goods than consuming them and it produces social imbalances. The Spartans had to live as if every free citizen was a soldier to prevent uprisings by their slaves, and even that proved not to be enough.
While I disagree with the grandparent, you should look at the turnout figures in recent elections. It's not uncommon for governments to be elected in western democracies with around 30% of total votes: turnout of around 60% and the winner getting a small majority. The winning party absolutely claims to have a strong mandate from the people and push through things that 30% of the population hated and 40% were apathetic about. If governments needed 51% of the population to agree, they'd never manage to do anything.
Probably for much the same reasons that things like Haiku, OpenIndiana, DragonflyBSD, and etc., exist
Haiku exists because people liked BeOS but BeOS was proprietary and largely abandoned. OpenIndiana exists because the phrase 'Oracle Solaris' just makes people sad. DragonflyBSD exists because Dillon wanted a playground where no one would disagree with him on project direction. But HURD? It had two reasons for existing: to build a microkernel-based OS and to provide a UNIX-like kernel with a license that made it a good fit for the rest of the GNU system. The former objective has been done better by things like Minix 3. The latter by Linux (at least, until GNU moved everything to GPLv3). HURD isn't that interesting as a research OS - the interesting project like L4 HURD died. It's not that interesting as a production OS. The only thing that it really has going for it at this point is the 'GNU' stamp on the top, and that doesn't matter unless you really want to build a complete GNU system (but are happy with X.org not being a GNU project and being more code than the kernel).
I've not tried it for ages, but it was able to run XFree86 back when that was a thing that people cared about. I'd presume that it can run X.org now. Debian/HURD made a release in April, so you can probably just download it and run it (though hardware support is likely to be worse than pretty much any other open source *NIX).
I don't have trouble reading code because of the font, so that is a non-issue for me
Define 'trouble'. Comprehension is not a binary thing. It's relatively easy to measure reading speed and retention. There's a lot of research showing that proportional fonts (and syntax highlighting) increase both, for all test subjects, including the ones that claim before the study that fixed-width single-coloured text is the best for them. Most of these apply equally to natural language, yet programmers insist that code is special and magical. This is even true of syntax highlighting - tagging different parts of speech in natural language has improves both reading speed and retention by 5-10%.
However, a proportional width font makes things extremely difficult to line up vertically
Nonsense. Tabulators exist for precisely this purpose. Oh, and read the rest of the post that you're replying to.
Re: Pure Internet Company?
on
IMDb Hits 25
·
· Score: 2
Most of the data is just facts. They aren't copyrightable. Database rights might apply to the aggregation, but they're most likely owned by the aggregator (IMDB).
I would actually be interested in this, if it comes along with smart tabs. I was initially sceptical of Stroustrup's claims in his book that code (like everything else) is more readable in a proportional font, but I checked the research and he is correct (in objectively measurable ways). I'd love to have an editor that:
Allowed my fingers to think that they were still using vim (the vim UI sucks by most objective measures, but motor memory is real and I'm too lazy to abandon it and retrain my fingers).
Had good syntax highlighting (not just lexical highlighting: I want variables declared in different scopes to be different colours)
Had context-aware autocomplete (of the kind that libclang can provide for [Objective-]C[++]).
Fully supported proportional fonts, with tabs correctly jumping to the next tabulator and allowing tabs in between non-whitespace characters to be saved as spaces that would preserve the tabulator alignment in fixed-width editors.
Had a client-server architecture, so I could easily use it to edit files on machines that I'm SSH'd into, without having to do X forwarding and getting an unresponsive UI.
Had a decent scripting interfaces with support for multiple languages.
Atom, Vim, and EMACS all support some overlapping subset of these. I've not yet found an editor that supports all of them.
And then you get issues with the composition. The Ariane problem is the classic example of this: the software for the gyroscope was fine and carried forward from the previous version. The gyroscope was changed to give more precision, and no one realised that they needed to modify the software that interacted with it.
A more topical example is the recent Xen bug. The shadow page table code was find when it was written. Then someone added support for superpages. Both of these components, in isolation, were correct. It was only the composition that caused issues.
TeX may be bug free, but that's only because it is a small VM that does very little. If you actually want to use it, you need to use a load of other packages, which do contain bugs.
If the vendor has not managed to produce a properly written, secure, bug free piece of software by the 10th attempt, what faith should one have in the 11th
Name one piece of software that is over 50,000 lines of code and is bug free after any number of attempts.
If vendors were required to ship working software, rather than anything they liked, we would have less software, but far less low quality software
We would have far less software. seL4 is the most complex piece of formally verified code and is around 10,000 lines of code. NICTA estimates that the cost of developing it is around 30 times the cost of developing the equivalent software with best-practice feature and regression testing and code review. The cost of making a nontrivial modification to seL4 is almost as great as the cost of writing it in the first place.
Oh, and when seL4 was open sourced, it took under 24 hours before someone found an exploitable security hole in it, because their formal verification hadn't verified the property that the attacker was looking for.
You probably want to link to PVH, not PVHVM for the real relevant approach. That said, HVM usually implies, at a minimum, hardware support for nested page tables. The bug in question is only present when using shadow page tables. Even if you're using PV devices in an HVM or PVH VM, you're using the hardware page tables.
ChoicePoint is obviously evil. The more subtle one is one of the services that Facebook offers. In most elections, a large percentage of voters either won't vote, or will vote for a particular party and won't have their minds changed by anything. This means that the election is usually decided by the swing voters - the 5-10% who are undecided. Facebook can, fairly accurately, identify who the swing voters are and, for each one what issues they find most important. More than that, it is willing to sell this information and to sell targeted advertising space. You can buy ads to target swing voters in constituency X, who think that issue Y is important. They'll only see the ad showing that your candidate has strong views that align with theirs on that issue. Someone else will see ads showing that the most important issue for your candidate is the thing that they care about. This is far harder to detect than something as blunt as ChoicePoint. The people seeing the ads have no idea that they're targeted, they only know that a particular candidate looks as if he or she really understands the issue of importance to them.
Full reverse engineering is difficult. But a hacker doesn't need to do that. He is just looking for potential stack overflows, buffer overruns, weak user authentication code, etc. If they exist, those are easy to find, using a disassembler and a VM.
Some of what you say is true. Stack buffer overflows are trivial to spot in both source and binary if they're local. If they're non-local, then you need to do some interprocedural analysis, but it's slightly easier to spot the root cause (someone passes a pointer to something that's on the stack) in source analysis. Heap buffer overflows are really hard to automatically detect with anything short of symbolic execution, though some heuristics can find likely places to look (are you doing pointer arithmetic without a bounds check?) and these are relatively easy in both compiled and binary, though going back and understanding what the invariants about the size are, which can elide the need for bounds checks is usually easier in source form.
Higher-level vulnerabilities in use of crypto, failure to correctly handle errors, and so on are all much easier to find in source form.
Yes and no. Yes, longer than the C99 standard int32_t typedef. No, not longer than the MS-specific int32 typedef, which was around at least in Windows 3.0 and inherited from Microsoft's DOS C toolchain.
So instead they fought 'proxy' wars, leaving lasting damage on all of the countries that were involved (Vietnam, Korea, Afghanistan, and so on). Much easier to keep fighting, because it's not your civilians / voters who are dying most of the time.
You see, when you have ARM32 vs ARM64 you have to remember that 64 is at least twice as much as 32. So you're going to need to use larger instructions in your program
You're joking, but that's actually true. Most AArch32 code these days uses Thumb-2, where most common instructions are 16 bits, a few are 32 bits. There's no Thumb-3 (yet) for AArch64, so all instructions are 32 bits. There almost certainly will be Thumb-3 at some point, though it is likely to be a little while coming and involve profiling a lot of code to determine what the most common instructions are (and there's no point in doing that until the compiler back ends have stabilised a bit).
We have a few ARMv8 boxes. One from AMD has a fairly standard layout motherboard and will fit in most PC cases. One from Cavium is in a standard rack-mount case (and, with two sockets and 48 cores per socket, is serving as a very useful test bed for lock contention in a variety of parts of the kernel).
They did break a lot of code, because a lot of code assumes that you can use long instead of intptr_t and store a pointer in a long then recover it later. The things that didn't break were doing really stupid things like putting long (instead of int32_t) in packed structs representing on-disk file headers (and Microsoft was responsible for shipping quite a few of those headers).
Slashdot Mirror
Laws should be written in such a way that the technology involved doesn't matter
Laws often apply to situations that didn't exist before some technology was invented. There was no little need to regulate traffic when a horse drawn cart on a rickety road was the fastest anyone went. There was no need to regulate wiretapping before the telephone was invented. There was no need to regulate the aggregation of large amount of personal data before large datacentres became cost effective to build, and so on. There may be some debate over whether hand-gun ownership should be regulated, but the invention of portable rocket launchers that could level buildings meant that at least some form of regulation was needed for private militias.
I believe that HURD is now GPLv3. GPLv3 is not GPLv2-compatible (it imposes conditions not present in GPLv2) and so you can not link GPLv2 code into a GPLv3 project. Most GPL'd projects include the 'or later versions' clause, but Linux is GPLv2 only, so none of its code can ever end up in GPLv3 projects.
Instead what will happen is that the rich will realize that it is not worth the effort to work really hard
Huh? If you could become rich by working really hard, then we'd have a lot more rich people.
I suspect that most people would happily work at a job that fit their interests, and that they found psychologically rewarding; the problem, of course, is that most jobs (and especially the kinds of jobs that are available to untrained/uneducated people) are of the tedious and mind-numbing variety.
A lot of what makes those jobs awful is the attitude of the employers. Compare working in a small shop to working in Walmart. Even if you're doing effectively the same thing, working in the small shop is likely to be a lot more rewarding because you're not being constantly treated as a replaceable and dispensable cog in a machine. If Walmart didn't have a ready supply of cheap labour then they'd have to improve worker conditions to make it a more attractive place to work.
Even a factor of 100 for truly exceptional people seems fine to me. I personally consider most sports personalities to be a colossal waste of space, but if what they're doing is enjoyed by a few million people and those people are willing to redistribute enough of their wealth in that direction that they can git the 100x-the-poorest line then I won't object. But when the difference is a factor of well over 1,000,000 that it's difficult to accept. When some people's annual income solely from owning property is greater than many people earn in total from working their entire life, it's hard to justify.
Yes you do have to just accept what the majority decides will be the law. That is how democracy (and all flavours of) work.
With minor variations, that's how all forms of society work. It is very difficult to rule without the consent of the governed. Even in a despotism, your army can't be everywhere enforcing your will and eventually people will stop doing the things necessary for your society to function and it will collapse. Or they'll come around with pitchforks and flaming torches one evening.
That said, slavery is never a stable situation. It produces economic imbalances when you have a lot more people producing goods than consuming them and it produces social imbalances. The Spartans had to live as if every free citizen was a soldier to prevent uprisings by their slaves, and even that proved not to be enough.
While I disagree with the grandparent, you should look at the turnout figures in recent elections. It's not uncommon for governments to be elected in western democracies with around 30% of total votes: turnout of around 60% and the winner getting a small majority. The winning party absolutely claims to have a strong mandate from the people and push through things that 30% of the population hated and 40% were apathetic about. If governments needed 51% of the population to agree, they'd never manage to do anything.
Probably for much the same reasons that things like Haiku, OpenIndiana, DragonflyBSD, and etc., exist
Haiku exists because people liked BeOS but BeOS was proprietary and largely abandoned. OpenIndiana exists because the phrase 'Oracle Solaris' just makes people sad. DragonflyBSD exists because Dillon wanted a playground where no one would disagree with him on project direction. But HURD? It had two reasons for existing: to build a microkernel-based OS and to provide a UNIX-like kernel with a license that made it a good fit for the rest of the GNU system. The former objective has been done better by things like Minix 3. The latter by Linux (at least, until GNU moved everything to GPLv3). HURD isn't that interesting as a research OS - the interesting project like L4 HURD died. It's not that interesting as a production OS. The only thing that it really has going for it at this point is the 'GNU' stamp on the top, and that doesn't matter unless you really want to build a complete GNU system (but are happy with X.org not being a GNU project and being more code than the kernel).
I've not tried it for ages, but it was able to run XFree86 back when that was a thing that people cared about. I'd presume that it can run X.org now. Debian/HURD made a release in April, so you can probably just download it and run it (though hardware support is likely to be worse than pretty much any other open source *NIX).
I don't have trouble reading code because of the font, so that is a non-issue for me
Define 'trouble'. Comprehension is not a binary thing. It's relatively easy to measure reading speed and retention. There's a lot of research showing that proportional fonts (and syntax highlighting) increase both, for all test subjects, including the ones that claim before the study that fixed-width single-coloured text is the best for them. Most of these apply equally to natural language, yet programmers insist that code is special and magical. This is even true of syntax highlighting - tagging different parts of speech in natural language has improves both reading speed and retention by 5-10%.
However, a proportional width font makes things extremely difficult to line up vertically
Nonsense. Tabulators exist for precisely this purpose. Oh, and read the rest of the post that you're replying to.
Most of the data is just facts. They aren't copyrightable. Database rights might apply to the aggregation, but they're most likely owned by the aggregator (IMDB).
* Using Variable Width Fonts
I would actually be interested in this, if it comes along with smart tabs. I was initially sceptical of Stroustrup's claims in his book that code (like everything else) is more readable in a proportional font, but I checked the research and he is correct (in objectively measurable ways). I'd love to have an editor that:
Atom, Vim, and EMACS all support some overlapping subset of these. I've not yet found an editor that supports all of them.
A more topical example is the recent Xen bug. The shadow page table code was find when it was written. Then someone added support for superpages. Both of these components, in isolation, were correct. It was only the composition that caused issues.
TeX may be bug free, but that's only because it is a small VM that does very little. If you actually want to use it, you need to use a load of other packages, which do contain bugs.
If the vendor has not managed to produce a properly written, secure, bug free piece of software by the 10th attempt, what faith should one have in the 11th
Name one piece of software that is over 50,000 lines of code and is bug free after any number of attempts.
If vendors were required to ship working software, rather than anything they liked, we would have less software, but far less low quality software
We would have far less software. seL4 is the most complex piece of formally verified code and is around 10,000 lines of code. NICTA estimates that the cost of developing it is around 30 times the cost of developing the equivalent software with best-practice feature and regression testing and code review. The cost of making a nontrivial modification to seL4 is almost as great as the cost of writing it in the first place.
Oh, and when seL4 was open sourced, it took under 24 hours before someone found an exploitable security hole in it, because their formal verification hadn't verified the property that the attacker was looking for.
You probably want to link to PVH, not PVHVM for the real relevant approach. That said, HVM usually implies, at a minimum, hardware support for nested page tables. The bug in question is only present when using shadow page tables. Even if you're using PV devices in an HVM or PVH VM, you're using the hardware page tables.
I'll just leave this here.
Lincoln had also abolished slavery in fact everywhere in the Confederacy where Union troops had set foot (most of it),
For a certain value of 'abolished'. It was another 30 years before all of the legally free former slaves were actually freed.
ChoicePoint is obviously evil. The more subtle one is one of the services that Facebook offers. In most elections, a large percentage of voters either won't vote, or will vote for a particular party and won't have their minds changed by anything. This means that the election is usually decided by the swing voters - the 5-10% who are undecided. Facebook can, fairly accurately, identify who the swing voters are and, for each one what issues they find most important. More than that, it is willing to sell this information and to sell targeted advertising space. You can buy ads to target swing voters in constituency X, who think that issue Y is important. They'll only see the ad showing that your candidate has strong views that align with theirs on that issue. Someone else will see ads showing that the most important issue for your candidate is the thing that they care about. This is far harder to detect than something as blunt as ChoicePoint. The people seeing the ads have no idea that they're targeted, they only know that a particular candidate looks as if he or she really understands the issue of importance to them.
Full reverse engineering is difficult. But a hacker doesn't need to do that. He is just looking for potential stack overflows, buffer overruns, weak user authentication code, etc. If they exist, those are easy to find, using a disassembler and a VM.
Some of what you say is true. Stack buffer overflows are trivial to spot in both source and binary if they're local. If they're non-local, then you need to do some interprocedural analysis, but it's slightly easier to spot the root cause (someone passes a pointer to something that's on the stack) in source analysis. Heap buffer overflows are really hard to automatically detect with anything short of symbolic execution, though some heuristics can find likely places to look (are you doing pointer arithmetic without a bounds check?) and these are relatively easy in both compiled and binary, though going back and understanding what the invariants about the size are, which can elide the need for bounds checks is usually easier in source form.
Higher-level vulnerabilities in use of crypto, failure to correctly handle errors, and so on are all much easier to find in source form.
Yes and no. Yes, longer than the C99 standard int32_t typedef. No, not longer than the MS-specific int32 typedef, which was around at least in Windows 3.0 and inherited from Microsoft's DOS C toolchain.
So instead they fought 'proxy' wars, leaving lasting damage on all of the countries that were involved (Vietnam, Korea, Afghanistan, and so on). Much easier to keep fighting, because it's not your civilians / voters who are dying most of the time.
You see, when you have ARM32 vs ARM64 you have to remember that 64 is at least twice as much as 32. So you're going to need to use larger instructions in your program
You're joking, but that's actually true. Most AArch32 code these days uses Thumb-2, where most common instructions are 16 bits, a few are 32 bits. There's no Thumb-3 (yet) for AArch64, so all instructions are 32 bits. There almost certainly will be Thumb-3 at some point, though it is likely to be a little while coming and involve profiling a lot of code to determine what the most common instructions are (and there's no point in doing that until the compiler back ends have stabilised a bit).
We have a few ARMv8 boxes. One from AMD has a fairly standard layout motherboard and will fit in most PC cases. One from Cavium is in a standard rack-mount case (and, with two sockets and 48 cores per socket, is serving as a very useful test bed for lock contention in a variety of parts of the kernel).
They did break a lot of code, because a lot of code assumes that you can use long instead of intptr_t and store a pointer in a long then recover it later. The things that didn't break were doing really stupid things like putting long (instead of int32_t) in packed structs representing on-disk file headers (and Microsoft was responsible for shipping quite a few of those headers).