All these dumb kids got through high schools with endemic grade inflation
I only hear about that being a problem in the US.
I've TA'ed in a freshman course (introductory programming 2) here in Denmark, and my group of students seemed to be doing some real work when they showed up for lab exercises. Sure, some of them caught a WoW-break some or all of the time; their loss. But most were studious, and you can't keep all the slackers out.
When people are still using any algorithm you came up with 30 years from now, you will have the right to say something about Edsger Dijkstra.
Nah, I don't buy that. We have the right to criticize him and his ideas all we want, no matter our and his past accomplishments.
The only important requirement is that we critique his ideas based on their own merit.
Just because he eschewed the run-break-fix approach so beloved of the folks who are spewing billions of lines of error-laden code into the world today
I'd rather have billions of LOCs that let me read slashdot than thousands of lines of code that provably correctly lets me alternate between printing A's and B's.
Proving your code correct is notoriously hard. I'm doing TA work in "Contract-based Programming" right now. Project one was an implementation and correctness proof of divmod and merge. Only one group of students (out of ~eight) handed in something that I would consider good enough to bet money on. Project two was insertion sort. Half the proofs were shoddy, the proof rules were incorrectly applied, the loop invariants were too weak and contained unnecessary conditions at the same time. Even the one group I'd bet money on had some minor errors that would need correction. The reports run to about ten pages on average, for ten lines of code.
If you want to prove firefox-running-on-linux correct, you need prove the correctness of firefox, linux-gate, libpthread, libdl, libstdc++, libm, libgcc, libc and linux in combination (list courtesy of ldd, but I think there should be a lot more...). If you want to have support for images, javascript, java, flash, output to X11 and some GNOME-ish look and feel, you need to add libimagesomething, libx11, javavm, flashvm and libgtk to the list. And of course libgtk requires libgdk, and...
No, let's rather just run code that does something of value than prove our code to correctly do nothing of value.
Let's not forget that science is not only a philosophical construct, but also a social and economic one: the public pays tax money for science because they expect something useful out of it.
If you ask me, that means you have to bet against Dijkstra.
By the way, do you have a correctness proof for that Algol compiler? I'd like to read it...
Unfortunately the Internet doesn't have any easy mechanism to indicate which peers would be better.
Take the ones with reasonably consistent low round-trip times. That's probably a good heuristic indicator that they're close by, which probably also means cheap.
In any case, it's probably better than picking uniformly at random.
You really have a very strange over-estimation of the value of a PhD. [...] It simply means you've been willing to go through some schooling.
Not quite, it also means that you're capable of coming up with ideas and solutions to novel problems on your own.
Linus Torvalds only attained a mere masters degree in Computer Science, but yet his OS seems to have become a bit more successful than quite a few other OS's written by people with more education.
Is this surprising to anyone? Building an OS is an big feet in terms of craftsmanship and engineering, but not so much a feat of science. If you concentrate your $n years of masters studies on OSes, you'll learn more than enough to write your own.
You doing two years of research into whatever OS-related topic tickles your fancy might give you a new and faster/better/nicer solution to implement, but somehow the world seemed to be able to write OSes without your idea in the past.
A PhD means you're a scientist (or at least one in the making). It doesn't take a scientist to build an OS. It takes an engineer.
I suspect a lot of the "more educated" OS designers implement OSes for academic purposes. Nothing wrong with that, it's just that they don't serve as a product people want to use (i.e. Linux), but rather as a proving ground for new research ideas (i.e. Hurd:D).
And even if the proven new ideas don't get adopted into production OSes, remember that there's value to basic research: you come up with a solution, someone somewhere sometime comes up with a good problem to your solution later on.
It could also be because they want things done right. I've spent some time finding memory management bugs in a piece of open source C code; it was a good way of getting to know that piece of software, and I felt some kind of satisfaction knowing that I've made the program better.
[I also found some non-memory-management bugs in the process; they weren't expressed without my changes due to luck and the way malloc works].
I've also reported a fairly large amount of bugs against compiz in a short amount of time; they're not causing breakage or anything, it's just that little extra polish that makes software nice to work with.
Having your code reviewed by a mindless idiot comparing it to the official procedure is bad. Even worse when the idiot is replaced by a program.
That depends. A requirement that all committed code should build from a clean checkout and should pass all unit tests is perfect for automation. It's also a fairly reasonable requirement.
What's the cost? (See, I read the article, learned something new, and applied it straight away.) Developers have to wait for the build-and-test cycle to run between successive commits. If I have two distinct commits that I want to commit at the same time, I have to queue them up, and wait and see if they pass. If my commits get rejected due to a test bug, I have to file a bug against the test, get it disabled, and commit again.
Could the cost be cut down? (as an addendum to the article: ask how much you can cut the cost while still getting most of the benefit.) Possibly.
Accept all commits up front and pull them back out when tests fail; send me a mail letting me know this. Cache the test results, such that if the only change is the removal of a buggy test, the commit goes through straight away.
If you commit on top of my test-pending commit and mine gets pulled out, the tests should automatically run on your commit against the code with my changes backed out. If it goes through, commit it automatically. (This works well for linear progress; I'm not sure exactly how it would work for merges.)
They don't tell you why the code was written as it is, or why the code is good.
This can be remedied by good comments. A very interesting remark by one of my lecturers is that cache-oblivious algorithms are competitive against IO-algorithms. Submitting your cache-oblivious disk sorting program for review would require comments as to why you chose the cache-oblivious algorithm over the IO one (explanation below).
But there's more to being a good programmer than knowing how to write a piece of code well. There's also knowing which code to write, and which code not to write.
The decision to write the reviewed code may be obvious, say "this feature is on the checklist", but it may also not be. It may be a good to split your application into a server and client, and have a library for talking to the server used both by a command-line tool and a GUI tool, but none of the code that implements this decisions talks about why the decision is good.
Most importantly, there's knowing what code not to write.
In synergy2, there's a function that's given a list of rectangles in the plane and wants to find an intersection. The current implementation has two for-loops and "// XXX O(n^2)". For the fun of it, I implemented a line-sweeping algorithm that did the same thing in O(n log n) time. No matter how I tweaked the parameters (including adding lots of very small rectangles), I couldn't make the damn line-sweeper faster than the trivial algorithm. I would never submit that for review.
And that's a damn shame. The hypothetical reviewers would learn some important lessons: that theoretically better algorithms aren't always better in practice, and that you should always measure time when you optimize for it.
[You may say "yeah, but we all know this"; as a response, I would ask: do you? Do you always measure? Do you do the comparisons? Knowing something and putting your knowledge to use is two different things.]
Back to the line-sweeping example: I think it would be useful to have a practice of "submitting for rejection". That is, go through the review process, commit the code to your VCS in a branch of its own, and mark the branch as "rejected". That way, your knowledge of what doesn't work (well) is stored in the VCS, for you to refer to when people who don't read it suggest implementing old ideas. In the ideal world, people would also read the rejected commits and the comments stating why it's submitted for rejection;)
Of course, not everything should be submitted for rejection; a good rule of thumb, I guess, is that the code should work correctly, but not desirably.
I might be naive in my thinking, but why spend billions on listening to everyone's conversations when you could spend the same money to make their lives good.
Most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small, green pieces of paper, which is odd, because on the whole, it wasn't the small, green pieces of paper which were unhappy.
Right now I fail to see the pros outweighing the cons when it comes to govt-controlled health care.
Come to Denmark for a while. Get sick. Spend the summer in the hospital. You'll be happy that you didn't ruin yourself and your family. You'll be happy that your parents didn't have to drain your college fund. Not that they'd have one for you, seeing not only how is education free, but also how you get paid to take it.
Yeah, we pay taxes for it. So what? We live a happy life over here. There's data that's only a few years old putting us as the number one Happy Nation (with apologies to Ace of Base). I think we're still doing well on that measure.
Out on the road? Want to download the newest HD episode of your show? Ya, you're going to want to get a connection from a paid-for ISP.
Find the torrent on the FCC connection, ssh into your home server, and run rtorrent or some other command-line torrent client in your screen session to grab the file.
Besides, I hope you were not planning to watch HD on your 14" laptop screen;)
People will absorb ANY amount of bandwidth if it's free.
Right now, all I'm using is a little HTTP here and there to browse slashdot.
I have plenty of things to do before I'll just chill out and watch some video. When I do, I have plenty of video queued up. Once it looks like I run out, I'll probably download some more. While I download the newest open movie from the blender project, I'll happily entertain myself with work, Guitar Hero III or hacking on compiz/network-manager/synergy2.
When I'm out of the house, sure it'd be nice to stream music off my home server to my portable music player, but it's not a hard requirement. Besides, if I know I'll be out for long, I'll bring my laptop and play off of ~/cache.
I'd like to have semi-reasonable browsing and ssh speeds everywhere I go, though, but then I'll shut up and be happy.
If my ISP is selling me unlimited internet and they decide not to deliver, I want a rate cut.
I think you should argue that you should pay for the share you're getting. If you get bandwidth limited by a constant k, but paid for unlimited bandwidth, it would only be fair to pay a limited part of an unbound whole:
stop lying about what it is you have sold to her. Either charge more or advertise less. It's as simple as that.
I'm certain the ISP would be happy to sell the teen a 24/7-100%-for-her pipe. I'm also certain she doesn't want to pay.
I would like to go to www.${ISP}.com and see a bunch of numbers.
I'd like to know what the oversubscription rations for each of their services are.
I'd like to know what the measured *actual* rates are, in say four-hour intervals across a typical work week, and in half-hour intervals across the average workday and weekend day.
Never has so little rrdtool work for so much overview been done so rarely. Err...;)
When an ISP throttles UDP packets because somebody is using excessive bandwidth
I assume good nature on behalf of the ISPs, meaning that "excessive bandwidth" is understood to exactly mean "more than you paid for".
I would assume the ISPs to drop IP datagrams to matter what protocol is used inside them; TCP, UDP, RTP, whatever. You used more than you paid for; away goes the packet.
But BT can well work on UDP and even generate less overhead and thus actually less traffic than it does today.
Only if it adds its own layer of TCPness on top.
Here's the deal. You have one gigabyte of data to download. It's been split into one megabyte chunks, and you know the sha1 hash of every 1-meg chunk.
You go ask a peer for a 1-meg chunk. You get 1024 little 1k-chunks in return. There are 1024! permutations of them. Please put them in the right order.
You could, you know, number them. If you want men outside the middle to not be able to spoof a connection from you, you need to start numbering from a random place, and tell the other endpoint from where you start your numbering.
Presumably, you want to make outgoing connections to several peers at the same time. Hmm... I know, let's number each of the connections, and send the number to the receiving end.
Boy, this sounds a lot like port and sequence numbers...
If you do a 20-byte hash (say, sha1) of every 1k block, you end up with a 1-to-50 reduction. For a 1G torrent, the.torrent file is 20 meg. Presumably you could use a somewhat smaller hash function for each packet and then use a bigger hash for a chunk of packets...
I'm not saying it can't be done. But I don't see what compelling features UDP offers that you can't get almost as effectively with TCP. Care to enlighten me?
Slashdot Mirror
So, his Macintosh wasn't a computer?
It couldn't have been his, you know, personal computer ;)
All these dumb kids got through high schools with endemic grade inflation
I only hear about that being a problem in the US.
I've TA'ed in a freshman course (introductory programming 2) here in Denmark, and my group of students seemed to be doing some real work when they showed up for lab exercises. Sure, some of them caught a WoW-break some or all of the time; their loss. But most were studious, and you can't keep all the slackers out.
When people are still using any algorithm you came up with 30 years from now, you will have the right to say something about Edsger Dijkstra.
Nah, I don't buy that. We have the right to criticize him and his ideas all we want, no matter our and his past accomplishments.
The only important requirement is that we critique his ideas based on their own merit.
Just because he eschewed the run-break-fix approach so beloved of the folks who are spewing billions of lines of error-laden code into the world today
I'd rather have billions of LOCs that let me read slashdot than thousands of lines of code that provably correctly lets me alternate between printing A's and B's.
Proving your code correct is notoriously hard. I'm doing TA work in "Contract-based Programming" right now. Project one was an implementation and correctness proof of divmod and merge. Only one group of students (out of ~eight) handed in something that I would consider good enough to bet money on. Project two was insertion sort. Half the proofs were shoddy, the proof rules were incorrectly applied, the loop invariants were too weak and contained unnecessary conditions at the same time. Even the one group I'd bet money on had some minor errors that would need correction. The reports run to about ten pages on average, for ten lines of code.
If you want to prove firefox-running-on-linux correct, you need prove the correctness of firefox, linux-gate, libpthread, libdl, libstdc++, libm, libgcc, libc and linux in combination (list courtesy of ldd, but I think there should be a lot more...). If you want to have support for images, javascript, java, flash, output to X11 and some GNOME-ish look and feel, you need to add libimagesomething, libx11, javavm, flashvm and libgtk to the list. And of course libgtk requires libgdk, and ...
No, let's rather just run code that does something of value than prove our code to correctly do nothing of value.
Let's not forget that science is not only a philosophical construct, but also a social and economic one: the public pays tax money for science because they expect something useful out of it.
If you ask me, that means you have to bet against Dijkstra.
By the way, do you have a correctness proof for that Algol compiler? I'd like to read it...
To say that you only use your PC for gaming shows your age and naivete.
The slashdot filtler made me mangle the following quote. The last character is repeated a 'few' more times.
<h|tler> HOW THE FUCK CAN YOU TELL THAT I'M 13 BY LOOKING AT WHAT I'M WRITEING???????
Send Steve Ballmer to DC in his private gold jet
He can afford it ;)
Unfortunately the Internet doesn't have any easy mechanism to indicate which peers would be better.
Take the ones with reasonably consistent low round-trip times. That's probably a good heuristic indicator that they're close by, which probably also means cheap.
In any case, it's probably better than picking uniformly at random.
You really have a very strange over-estimation of the value of a PhD. [...] It simply means you've been willing to go through some schooling.
Not quite, it also means that you're capable of coming up with ideas and solutions to novel problems on your own.
Linus Torvalds only attained a mere masters degree in Computer Science, but yet his OS seems to have become a bit more successful than quite a few other OS's written by people with more education.
Is this surprising to anyone? Building an OS is an big feet in terms of craftsmanship and engineering, but not so much a feat of science. If you concentrate your $n years of masters studies on OSes, you'll learn more than enough to write your own.
You doing two years of research into whatever OS-related topic tickles your fancy might give you a new and faster/better/nicer solution to implement, but somehow the world seemed to be able to write OSes without your idea in the past.
A PhD means you're a scientist (or at least one in the making). It doesn't take a scientist to build an OS. It takes an engineer.
I suspect a lot of the "more educated" OS designers implement OSes for academic purposes. Nothing wrong with that, it's just that they don't serve as a product people want to use (i.e. Linux), but rather as a proving ground for new research ideas (i.e. Hurd :D).
And even if the proven new ideas don't get adopted into production OSes, remember that there's value to basic research: you come up with a solution, someone somewhere sometime comes up with a good problem to your solution later on.
Am I the only person who hates those ridiculous jokes that have a made-up story just to set up a pun?
Yep.
Also, your parent's story is funny in itself ;)
Testers love to find bugs, whether it be [...]
It could also be because they want things done right. I've spent some time finding memory management bugs in a piece of open source C code; it was a good way of getting to know that piece of software, and I felt some kind of satisfaction knowing that I've made the program better.
[I also found some non-memory-management bugs in the process; they weren't expressed without my changes due to luck and the way malloc works].
I've also reported a fairly large amount of bugs against compiz in a short amount of time; they're not causing breakage or anything, it's just that little extra polish that makes software nice to work with.
instructions on how to get a bigger pen15 2day
:(
Why are there no penis enlargement 0-days?
/riony
Having your code reviewed by a mindless idiot comparing it to the official procedure is bad. Even worse when the idiot is replaced by a program.
That depends. A requirement that all committed code should build from a clean checkout and should pass all unit tests is perfect for automation. It's also a fairly reasonable requirement.
What's the cost? (See, I read the article, learned something new, and applied it straight away.) Developers have to wait for the build-and-test cycle to run between successive commits. If I have two distinct commits that I want to commit at the same time, I have to queue them up, and wait and see if they pass. If my commits get rejected due to a test bug, I have to file a bug against the test, get it disabled, and commit again.
Could the cost be cut down? (as an addendum to the article: ask how much you can cut the cost while still getting most of the benefit.) Possibly.
Accept all commits up front and pull them back out when tests fail; send me a mail letting me know this. Cache the test results, such that if the only change is the removal of a buggy test, the commit goes through straight away.
If you commit on top of my test-pending commit and mine gets pulled out, the tests should automatically run on your commit against the code with my changes backed out. If it goes through, commit it automatically. (This works well for linear progress; I'm not sure exactly how it would work for merges.)
They can be docked karma that way[...] they can cover their asses
Is that why they call it Dock and Cover?
Code reviews for the win, absolutely.
They don't do everything, though.
They don't tell you why the code was written as it is, or why the code is good.
This can be remedied by good comments. A very interesting remark by one of my lecturers is that cache-oblivious algorithms are competitive against IO-algorithms. Submitting your cache-oblivious disk sorting program for review would require comments as to why you chose the cache-oblivious algorithm over the IO one (explanation below).
But there's more to being a good programmer than knowing how to write a piece of code well. There's also knowing which code to write, and which code not to write.
The decision to write the reviewed code may be obvious, say "this feature is on the checklist", but it may also not be. It may be a good to split your application into a server and client, and have a library for talking to the server used both by a command-line tool and a GUI tool, but none of the code that implements this decisions talks about why the decision is good.
Most importantly, there's knowing what code not to write.
In synergy2, there's a function that's given a list of rectangles in the plane and wants to find an intersection. The current implementation has two for-loops and "// XXX O(n^2)". For the fun of it, I implemented a line-sweeping algorithm that did the same thing in O(n log n) time. No matter how I tweaked the parameters (including adding lots of very small rectangles), I couldn't make the damn line-sweeper faster than the trivial algorithm. I would never submit that for review.
And that's a damn shame. The hypothetical reviewers would learn some important lessons: that theoretically better algorithms aren't always better in practice, and that you should always measure time when you optimize for it.
[You may say "yeah, but we all know this"; as a response, I would ask: do you? Do you always measure? Do you do the comparisons? Knowing something and putting your knowledge to use is two different things.]
Back to the line-sweeping example: I think it would be useful to have a practice of "submitting for rejection". That is, go through the review process, commit the code to your VCS in a branch of its own, and mark the branch as "rejected". That way, your knowledge of what doesn't work (well) is stored in the VCS, for you to refer to when people who don't read it suggest implementing old ideas. In the ideal world, people would also read the rejected commits and the comments stating why it's submitted for rejection ;)
Of course, not everything should be submitted for rejection; a good rule of thumb, I guess, is that the code should work correctly, but not desirably.
I might be naive in my thinking, but why spend billions on listening to everyone's conversations when you could spend the same money to make their lives good.
Most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small, green pieces of paper, which is odd, because on the whole, it wasn't the small, green pieces of paper which were unhappy.
;)
Right now I fail to see the pros outweighing the cons when it comes to govt-controlled health care.
Come to Denmark for a while. Get sick. Spend the summer in the hospital. You'll be happy that you didn't ruin yourself and your family. You'll be happy that your parents didn't have to drain your college fund. Not that they'd have one for you, seeing not only how is education free, but also how you get paid to take it.
Yeah, we pay taxes for it. So what? We live a happy life over here. There's data that's only a few years old putting us as the number one Happy Nation (with apologies to Ace of Base). I think we're still doing well on that measure.
Out on the road? Want to download the newest HD episode of your show? Ya, you're going to want to get a connection from a paid-for ISP.
Find the torrent on the FCC connection, ssh into your home server, and run rtorrent or some other command-line torrent client in your screen session to grab the file.
Besides, I hope you were not planning to watch HD on your 14" laptop screen ;)
People will absorb ANY amount of bandwidth if it's free.
Right now, all I'm using is a little HTTP here and there to browse slashdot.
I have plenty of things to do before I'll just chill out and watch some video. When I do, I have plenty of video queued up. Once it looks like I run out, I'll probably download some more. While I download the newest open movie from the blender project, I'll happily entertain myself with work, Guitar Hero III or hacking on compiz/network-manager/synergy2.
When I'm out of the house, sure it'd be nice to stream music off my home server to my portable music player, but it's not a hard requirement. Besides, if I know I'll be out for long, I'll bring my laptop and play off of ~/cache.
I'd like to have semi-reasonable browsing and ssh speeds everywhere I go, though, but then I'll shut up and be happy.
Express task dependencies in graphviz format; write a scheduling algorithm in C, python, or gvpr and have it output a Gantt chart in pic format.
Wait, you manager you not hacker? ;)
If my ISP is selling me unlimited internet and they decide not to deliver, I want a rate cut.
I think you should argue that you should pay for the share you're getting. If you get bandwidth limited by a constant k, but paid for unlimited bandwidth, it would only be fair to pay a limited part of an unbound whole:
lim_{n \rightarrow \infty} \frac{k}{n}
(i.e. 0)
stop lying about what it is you have sold to her. Either charge more or advertise less. It's as simple as that.
I'm certain the ISP would be happy to sell the teen a 24/7-100%-for-her pipe. I'm also certain she doesn't want to pay.
I would like to go to www.${ISP}.com and see a bunch of numbers.
I'd like to know what the oversubscription rations for each of their services are.
I'd like to know what the measured *actual* rates are, in say four-hour intervals across a typical work week, and in half-hour intervals across the average workday and weekend day.
Never has so little rrdtool work for so much overview been done so rarely. Err... ;)
When an ISP throttles UDP packets because somebody is using excessive bandwidth
I assume good nature on behalf of the ISPs, meaning that "excessive bandwidth" is understood to exactly mean "more than you paid for".
I would assume the ISPs to drop IP datagrams to matter what protocol is used inside them; TCP, UDP, RTP, whatever. You used more than you paid for; away goes the packet.
But BT can well work on UDP and even generate less overhead and thus actually less traffic than it does today.
Only if it adds its own layer of TCPness on top.
Here's the deal. You have one gigabyte of data to download. It's been split into one megabyte chunks, and you know the sha1 hash of every 1-meg chunk.
You go ask a peer for a 1-meg chunk. You get 1024 little 1k-chunks in return. There are 1024! permutations of them. Please put them in the right order.
You could, you know, number them. If you want men outside the middle to not be able to spoof a connection from you, you need to start numbering from a random place, and tell the other endpoint from where you start your numbering.
Presumably, you want to make outgoing connections to several peers at the same time. Hmm... I know, let's number each of the connections, and send the number to the receiving end.
Boy, this sounds a lot like port and sequence numbers...
If you do a 20-byte hash (say, sha1) of every 1k block, you end up with a 1-to-50 reduction. For a 1G torrent, the .torrent file is 20 meg. Presumably you could use a somewhat smaller hash function for each packet and then use a bigger hash for a chunk of packets...
I'm not saying it can't be done. But I don't see what compelling features UDP offers that you can't get almost as effectively with TCP. Care to enlighten me?
After you sold it to me, it's simply criminal to then say
No, that would be a civil lawsuit.
(ianal, tinla, sorry to nitpick)
Win98 - Plug and Play tweaked to be slightly more reliable.
And here's the video that demonstrates Plug and Play: http://video.google.com/videoplay?docid=-2542580036602389550