Strictly speaking a constituency voting system where you can specify first choice, second choice and so on is not proportional representation. The number of seats allocated to each party still doesn't exactly reflect that party's share of the vote. True proportional representation means that if you got 10% of votes cast, you will get 10% of seats. Under single-transferrable-vote, Condorcet or other systems, a party could get 10% of first-choice votes and still not win a single seat.
True proportional representation requires a single nationwide count of votes and some kind of party list system - where you can't vote for a candidate, but only for a party which lists the candidates it will appoint to fill the seats it gets. Fairness is important in a voting system but it is not the only consideration - many people prefer a system which is 'unfair' (in that it doesn't reflect the exact proportion of votes cast) but gives more opportunity for local representation (constituencies) and doesn't concentrate power in the hands of party managers.
It's worth noting that if you do want a system of first choice, second choice and so on, the single transferrable vote system used in the ROI and other European countries may not be the best way to do it. See condorcet.org and related websites for some discussion of the flaws in STV, IRV and related systems, and a better way of deciding the winner. One interesting thing it points out (with examples) is that under STV, by voting for a candidate you can make them _less_ likely to win!
The Irish system uses multimember constituencies I believe, so it's not exactly the same as one-member STV, but I think the same flaws apply. And to reiterate, it's not accurate to call it proportional (though it does usually get closer to proportional than the plurality or first-past-the-post system used in some countries).
I think he is giving the world some warning that the security hole exists and that after the conference exploits for it may appear in the wild (if they don't exist already). Vulnerabilities are sometimes announced this way: for example the OpenSSH team issued a mysterious warning saying that everyone running sshd should turn on privilege separation. A little while later they disclosed an exploit in the current sshd and made a new release with a fix. It happened that if you had privsep turned on you weren't affected by the exploit. The warning gave most admins a chance to secure their systems, but didn't give any details of the exploit.
Now, you might not think this guy is credible and so wait for him to 'show you the code' before applying the suggested fix. That's up to you.
There's kind of a convention that setting cookies on the client side doesn't count as a side effect. You can follow a normal text link and receive a cookie, so it doesn't hurt too much to follow a 'Logout' link for a cookie to be deleted. If something happens to prefetch that page, it just won't apply the cookie changes. If 'Logout' ends up setting some state on the server, that's less appropriate and really should be a POST.
I know there isn't an exact line between what counts as a side effect and what doesn't, but most people have a general idea and I think one should try to follow the spirit of it. Personally I like to make clicky forms where intermediate changes are done with text links (eg toggling something on and off) but the final 'commit' happens by pressing a button and making a POST.
According to TFA, the microphones are to measure general noise levels following a complaint - not so that the sinister cabal known as Westminster Council can monitor conversations and feed them to Shirley Porter's underground monitoring centre in Israel or something. Come on, with microphones being so easy to conceal, if there is any bugging of London's streets by it will not be publicly announced.
I for one welcome our new microphone-wielding noise hotline overlords. The single biggest thing spoiling quality of life in London is scum living nearby blasting out music day and night. It doesn't work very well for noise enforcement teams to come round only after each complaint. If they can actively monitor noise levels and then instantly send round heavies with baseball bats, I'm all for it.
No language is magic and can prevent all errors, but in general moving from a lower-level to a higher-level language can help avoid some kinds of mistakes. You're less likely to get memory trampling bugs in Lisp than in assembler, though there are other tradeoffs. SQL is a higher-level way of manipulating data than most programming languages: what might take a hundred lines of Java can often be done in ten lines of SQL. That in itself reduces the chance of logic bugs. Then SQL also has strong type checking which also (in my experience) helps catch programming errors.
Most RDBMSes give you more than just SQL: they also offer ACID properties with transactions, which simplify a lot of programming work. If something goes wrong halfway through an operation, you can tell the database to roll back and everything is put cleanly back how it was at the beginning of the transaction. This is often a lot easier than writing your own undo mechanisms to start making changes to a data structure and then unpick them.
I'm getting rather tired of the fad that databases should be tacked on to everything, ranging from a shopping list to guidance systems.
If it is a fad, it is one that has been around for thirty years or more. If hardware in 1985 was powerful enough to run a relational database and offer full transaction safety, it's powerful enough now. I think the current fad is for people to ignore the past few decades of research and experience and try to do without a database system. Good luck to them, but they should make sure they don't need the useful things an RDBMS gives you.
Obviously, charging a small fee would get rid of all comment spam at a stroke, provided the fee was per view of the comment not a one-off posting charge. Perhaps you'd pay one cent and the comment would disappear after ten people had read it - then you have to keep on paying for people to keep reading it. It would be nice to think the same approach would deal with trolls and idiots on forums like Slashdot, but sadly there is no correlation between the value of what you have to say and the monetary value you'd place on getting others to read it. Otherwise, paid advertising would be the most highly prized form of literature.
Of course what the world needs is some bizarre web-of-trust karma money-go-round where points of karma can be bought or sold. (You probably wouldn't have a single global karma score in a web of trust, only a weighted score that's seen differently by every individual.) As CmdrTaco said, that would be hilarious.
Rather than simply show how to record a macro and reuse it, they start by talking about coding practices, naming conventions and application structure.
This is almost enough to put me off - I can't stand technical books where the author doesn't have the self-discipline to spare us an exposition of his personal system of naming conventions and brace placement. Or which harangue for pages about the importance of 'structured programming' and writing documentation. Keep to the point and tell the reader what he needs to know, and if you have something to say about style, let it show through your examples.
Perhaps for Excel there is a bit to say about naming conventions since the Microsoft ones may not be obvious. As long as it's information and not over-eager cluebie evangelism.
I should correct myself: there is another good reason to use a language feature and that is to help the compiler catch mistakes. A C++ program written using templates may be a little more complex than one using void* pointers everywhere and casting at run time, but it's less likely to have some kinds of bug. (At least, if you are a bad enough programmer to need all the help you can get from the machine - I know I am.)
One difference is that biotech already has relatively high overheads - you need to have a laboratory and expensive equipment already, so patent licensing is not a significant extra barrier to entry. But software development is often done by small firms or individuals to whom having to license hundreds of patents (or get shaken down by Lucent, etc) is a significant burden.
One way to tweak the patent system to promote progress is to grant patent monopolies only in areas where there's evidence it gives an economic benefit. There is no evidence of any benefit in the area of software, as studies have found, so it would be a good start to exclude software from patentability - whatever happens to the rest of the system.
I don't accept the premise of your question - you are offering a choice between 'simple' and 'elegant' but in reality they are the same thing. The only purpose of using object-oriented programming or any other technique is to make the program simpler and easier to understand. If it just obfuscates the code, then the feature has been misused.
Maybe you're being too hard on yourself and the 'comparable-complexity C++ program' you find hard to understand is just an overengineered mess. It can happen in any language but some languages make it easier than others, if the programmer lacks the self-discipline to keep it simple.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 1, Interesting
When I first came to Linux I couldn't figure out how applications displayed things on the X server. I was used to the idea that to draw a line on screen you save the return address on the stack, then jump to some operating system address. It draws the line for you and then returns.
So... how did this work on Linux? Was the X server process mapped into memory at a fixed logical address so other programs can know what routines to call?
It was rather a surprise to find that to draw something on the screen you had to format a message and send it down a TCP/IP link or at best a Unix socket, involving at least two context switches. No wonder computers are so slow nowadays...
Any exploitable program you run as another user will still need a local escilation exploit in order to do anything harmful.
What is 'harmful'? If something running as your ordinary user account is exploited - for example, a bug in your web browser lets it be taken over by some hostile web page - then your user account is cracked. Why is it necessary to escalate that to root to do any damage? All the files I care about are in my home directory; all the sensitive operations (like typing credit card numbers into a web page) happen when running as my user account. Root access is more or less irrelevant, unless there are other user accounts on the machine. But most PCs these days have only one real user.
rm -Rf / as nonroot will make you give a sigh of relief.
I don't know how often the typical Linspire user runs such a command, or its equivalent. But as nonroot 'rm -rf/' will still trash my home directory, which is all that matters. Honestly, I don't much care about the contents of/usr/ or/etc/ - those can easily be reinstalled.
The example you give for MySQL makes sense, however Linspire users aren't running MySQL. Having a separate user for accounting files might be a good idea if you are very security-conscious, but do you honestly believe grandma will or should set up her machine like this?
I think it would be a good idea for anyone responding to Robertson's arguments to give a practical *example* of where running as non-root makes a home user's system more secure. Remember this is a machine with only one user, it doesn't run MySQL or Apache or other server things, and the data that really matters is the user's personal files. I think Robertson is probably right: people tend to respond with a lot of bluster and 'of course non-root is more secure', seat belt analogies and moralizing, but find it hard to give a real scenario where Linspire's always-root policy worsens security.
Er... by the same argument any suid binary permits HUGE holes because it's easy to find a buffer overflow in the program.
Come on now, a Ruby script is much less likely to have buffer overflow vulnerabilities than some-random-bit-of-C and yet you say that the latter can safely be made suid and the former cannot?
I thought the real reason for disallowing suid scripts was not to protect people from themselves, but because of a race condition. The script interpreter is invoked with the _name_ of the program to run, but of course that filename could have been switched to link to a different file in between the kernel starting the interpreter and the interpreter calling open() on the script. Apparently some Unix variants fixed this by passing an open filehandle to the interpreter, but I don't know the details of how this worked.
Strictly speaking a constituency voting system where you can specify first choice, second choice and so on is not proportional representation. The number of seats allocated to each party still doesn't exactly reflect that party's share of the vote. True proportional representation means that if you got 10% of votes cast, you will get 10% of seats. Under single-transferrable-vote, Condorcet or other systems, a party could get 10% of first-choice votes and still not win a single seat.
True proportional representation requires a single nationwide count of votes and some kind of party list system - where you can't vote for a candidate, but only for a party which lists the candidates it will appoint to fill the seats it gets. Fairness is important in a voting system but it is not the only consideration - many people prefer a system which is 'unfair' (in that it doesn't reflect the exact proportion of votes cast) but gives more opportunity for local representation (constituencies) and doesn't concentrate power in the hands of party managers.
It's worth noting that if you do want a system of first choice, second choice and so on, the single transferrable vote system used in the ROI and other European countries may not be the best way to do it. See condorcet.org and related websites for some discussion of the flaws in STV, IRV and related systems, and a better way of deciding the winner. One interesting thing it points out (with examples) is that under STV, by voting for a candidate you can make them _less_ likely to win!
The Irish system uses multimember constituencies I believe, so it's not exactly the same as one-member STV, but I think the same flaws apply. And to reiterate, it's not accurate to call it proportional (though it does usually get closer to proportional than the plurality or first-past-the-post system used in some countries).
Not directly related, but this reminds me of RMS's story The Right To Read for some reason.
I think he is giving the world some warning that the security hole exists and that after the conference exploits for it may appear in the wild (if they don't exist already). Vulnerabilities are sometimes announced this way: for example the OpenSSH team issued a mysterious warning saying that everyone running sshd should turn on privilege separation. A little while later they disclosed an exploit in the current sshd and made a new release with a fix. It happened that if you had privsep turned on you weren't affected by the exploit. The warning gave most admins a chance to secure their systems, but didn't give any details of the exploit.
Now, you might not think this guy is credible and so wait for him to 'show you the code' before applying the suggested fix. That's up to you.
And this is different from proprietary software how?
It's been said before and needs to be said again:
'Free software is a matter of freedom, not price.'
For companies, freedom usually means freedom from dependence on a single supplier. The article is just stating the obvious.
Yes, Micro-Soft, but never MicroSoft AFAIK. That's just lame. Wikipedia has more details.
Has Microsoft ever been written with a capital S, even before 1987?
There's kind of a convention that setting cookies on the client side doesn't count as a side effect. You can follow a normal text link and receive a cookie, so it doesn't hurt too much to follow a 'Logout' link for a cookie to be deleted. If something happens to prefetch that page, it just won't apply the cookie changes. If 'Logout' ends up setting some state on the server, that's less appropriate and really should be a POST.
I know there isn't an exact line between what counts as a side effect and what doesn't, but most people have a general idea and I think one should try to follow the spirit of it. Personally I like to make clicky forms where intermediate changes are done with text links (eg toggling something on and off) but the final 'commit' happens by pressing a button and making a POST.
According to TFA, the microphones are to measure general noise levels following a complaint - not so that the sinister cabal known as Westminster Council can monitor conversations and feed them to Shirley Porter's underground monitoring centre in Israel or something. Come on, with microphones being so easy to conceal, if there is any bugging of London's streets by it will not be publicly announced.
I for one welcome our new microphone-wielding noise hotline overlords. The single biggest thing spoiling quality of life in London is scum living nearby blasting out music day and night. It doesn't work very well for noise enforcement teams to come round only after each complaint. If they can actively monitor noise levels and then instantly send round heavies with baseball bats, I'm all for it.
Most RDBMSes give you more than just SQL: they also offer ACID properties with transactions, which simplify a lot of programming work. If something goes wrong halfway through an operation, you can tell the database to roll back and everything is put cleanly back how it was at the beginning of the transaction. This is often a lot easier than writing your own undo mechanisms to start making changes to a data structure and then unpick them.If it is a fad, it is one that has been around for thirty years or more. If hardware in 1985 was powerful enough to run a relational database and offer full transaction safety, it's powerful enough now. I think the current fad is for people to ignore the past few decades of research and experience and try to do without a database system. Good luck to them, but they should make sure they don't need the useful things an RDBMS gives you.
Obviously, charging a small fee would get rid of all comment spam at a stroke, provided the fee was per view of the comment not a one-off posting charge. Perhaps you'd pay one cent and the comment would disappear after ten people had read it - then you have to keep on paying for people to keep reading it. It would be nice to think the same approach would deal with trolls and idiots on forums like Slashdot, but sadly there is no correlation between the value of what you have to say and the monetary value you'd place on getting others to read it. Otherwise, paid advertising would be the most highly prized form of literature.
Of course what the world needs is some bizarre web-of-trust karma money-go-round where points of karma can be bought or sold. (You probably wouldn't have a single global karma score in a web of trust, only a weighted score that's seen differently by every individual.) As CmdrTaco said, that would be hilarious.
Look at it this way, statistics can be used to back up a sensible argument. But the truth is, 99% of statistics are made up on the spot.
Perhaps for Excel there is a bit to say about naming conventions since the Microsoft ones may not be obvious. As long as it's information and not over-eager cluebie evangelism.
I should correct myself: there is another good reason to use a language feature and that is to help the compiler catch mistakes. A C++ program written using templates may be a little more complex than one using void* pointers everywhere and casting at run time, but it's less likely to have some kinds of bug. (At least, if you are a bad enough programmer to need all the help you can get from the machine - I know I am.)
One difference is that biotech already has relatively high overheads - you need to have a laboratory and expensive equipment already, so patent licensing is not a significant extra barrier to entry. But software development is often done by small firms or individuals to whom having to license hundreds of patents (or get shaken down by Lucent, etc) is a significant burden.
One way to tweak the patent system to promote progress is to grant patent monopolies only in areas where there's evidence it gives an economic benefit. There is no evidence of any benefit in the area of software, as studies have found, so it would be a good start to exclude software from patentability - whatever happens to the rest of the system.
See 'Gay Daleks': mini screenshot, article.
I stopped watching Firefly when they changed the name from Phoenix.
I don't accept the premise of your question - you are offering a choice between 'simple' and 'elegant' but in reality they are the same thing. The only purpose of using object-oriented programming or any other technique is to make the program simpler and easier to understand. If it just obfuscates the code, then the feature has been misused.
Maybe you're being too hard on yourself and the 'comparable-complexity C++ program' you find hard to understand is just an overengineered mess. It can happen in any language but some languages make it easier than others, if the programmer lacks the self-discipline to keep it simple.
Er... gcc -std=c99?
When I first came to Linux I couldn't figure out how applications displayed things on the X server. I was used to the idea that to draw a line on screen you save the return address on the stack, then jump to some operating system address. It draws the line for you and then returns.
So... how did this work on Linux? Was the X server process mapped into memory at a fixed logical address so other programs can know what routines to call?
It was rather a surprise to find that to draw something on the screen you had to format a message and send it down a TCP/IP link or at best a Unix socket, involving at least two context switches. No wonder computers are so slow nowadays...
That indicates how far the technology (PDFs in this case) has regressed.
I don't know how often the typical Linspire user runs such a command, or its equivalent. But as nonroot 'rm -rf
The example you give for MySQL makes sense, however Linspire users aren't running MySQL. Having a separate user for accounting files might be a good idea if you are very security-conscious, but do you honestly believe grandma will or should set up her machine like this?
I think it would be a good idea for anyone responding to Robertson's arguments to give a practical *example* of where running as non-root makes a home user's system more secure. Remember this is a machine with only one user, it doesn't run MySQL or Apache or other server things, and the data that really matters is the user's personal files. I think Robertson is probably right: people tend to respond with a lot of bluster and 'of course non-root is more secure', seat belt analogies and moralizing, but find it hard to give a real scenario where Linspire's always-root policy worsens security.
Er... by the same argument any suid binary permits HUGE holes because it's easy to find a buffer overflow in the program.
Come on now, a Ruby script is much less likely to have buffer overflow vulnerabilities than some-random-bit-of-C and yet you say that the latter can safely be made suid and the former cannot?
I thought the real reason for disallowing suid scripts was not to protect people from themselves, but because of a race condition. The script interpreter is invoked with the _name_ of the program to run, but of course that filename could have been switched to link to a different file in between the kernel starting the interpreter and the interpreter calling open() on the script. Apparently some Unix variants fixed this by passing an open filehandle to the interpreter, but I don't know the details of how this worked.
'Our patience is exhausted. We can no longer tolerate your vile provocations. Prepare for SLASHDOTTING!'