...a stone may start the soup, but that is not the only ingredient. We have for too long been ladling software out and putting the odd bit of software or bug report into the Magic Cauldron that we forget that the Soup needs more than just that.
It needs wood for the fire. It needs flavour and zest.
The magic of software is that the old rule "You get what you pay for" doesn't apply to it.
However, it does still apply to people. (Although a lot less than the salary of global megacorp CEO's would suggest.)
If we need people to administer and run various Open Source projects, we need to pay them. They need to make a fair living.
Strange I thought it already had something like this in the text. I mean somewhere along the line somebody already added something like "Thou shalt not steal".
Perhaps instead of microdots they need to add a more specific admonishment. "Thou shalt not receive stolen goods, even if it is a Torah".
Nah. If they don't read the first, they won
't read the second, nor the microdots.
I think the Gideons have the right approach. Make'em cheap, make 'em available, and maybe, just maybe, somebody somewhere will actually _read_ them.
I suspect of all the people in the world, Uli has been one of those bitten hardest and deepest by this problem, mostly because of his vast contributions to so many of the core items in the GNU/Open Source software collection. So I can feel for his radical tone.
However, there is some good PR value in some of these ports.
He is right though, a bit of strategic thinking would be Good. eg. Think about when dropping a port would merely force some lazy PHB to take the final bold step into the wonderful world of GNU/Linux and when keeping a port is winning valuable support and new recruits. eg. Dropping support for SCO was Good in several ways.
IT SOUNDS a bit New Age, but there is a mysterious method of thought control you can learn that seems to boost brain power. No one quite knows how it works, and it is hard to describe exactly how to do it: it's not relaxation or concentration as such, more a state of mind. It's called neurofeedback. And it is slowly gaining scientific credibility.
That sounds interesting. Anyone tried it? Any reports? Anyone know of any good / cheap devices to do this?
The second that the RIAA felt threatened by the size and zeal of them, they came down hard.
The difference I guess is America trying damn hard to hound Norwegians and Russians and everybody else with DMCA. China is content just to make rumbling noises at North Korea and Taiwan.
They have the Grreat Firewall of China, you have the Grreat DMCA of America.
Speaking as a person living outside both those countries, it looks like you guys are pretty even.
Re:Learn Lisp Without Installing Anything on Your
on
Practical Common Lisp
·
· Score: 1
Well, Ruby doesn't warp your brain the way Lisp tends to, but "Why the Lucky Stiff's" Poignant Comic Book Guide to Ruby definitely will definitely umm, errr, it will, ahh, ahh shucks, see for yourself! Why's (Poignant) Guide to Ruby
You can do quite a lot of accelerating with that. Ye olde E=mc^2 converts electrons into 511kev.
ie. The mass of an electron undergoes total matter conversion into a packet of energy equal to the kinetic energy of an electron dropped through a potential difference of 511000 Volts.
Ok, so I assume that field is over quite a small distance, the potential difference is probably a lot less than 25E9 Volts ie a lot less than 49000 electrons. Given that a neutron has a mass of 940MeV/c^2 the neutrons they are measuring are being created out of the kinetic energy.
As the poster who started of this thread, can I point out I merely said "tests are more important than comments". ie. Given the choice of only tests xor only comments, I will have tests thank you.
However, my code always has unit tests, DbC assertions and comments.
I'm also always nagging folk on the subject of comments. Don't bother with comments that can be trivially deduced from just reading the code. Remember humans are input bandwidth limited. ie. We are limited in understanding reams of code by how fast we can read. Thus trivial comments slow us, rather than help us. Always comment at a higher semantic level. State eternals truths (always call this after that or Bad Things happen) about the code, not chat about the current weather. (Nice parameters we're having today...)
Tests are themselves a powerful commentary on the code. They explain graphically what the code does, and in what manner and what order.
However, tests are code too, and are as prone (if not more so) to being as badly written as code.
Which is why Refactoring and TDD go hand in hand. Refactoring improves the code, especially from the clarity and simplicity point of view. However, to refactor effectively and safely, you need a good framework of tests to preserve the functionality.
There is a very nice dualism between tests and code. Tests test (and comment) the code, Code tests (and comment) the tests.
Another good duality is Design by Contract. I use unit tests to constrain the public interface to my code. I use Design by Contract assertions to constrain the private workings of my code. DbC assertions are like coded comments. Think of a comment that asserts that something is true about this code. An assertion turns that comment from a warm fuzzy feeling into a hard fact.
Slashdot Mirror
There is something weird about that corner of Turkey...
Plasticine Park Already exists.
A firewall of course!
Having destroyed our base on Tempel 1, prepare to meet the wrath of the full Saturnian space fleet.
Hmm, and I note that although you slashdotters have welcomed every other overlord, you haven't welcomed us.
We will remember that.
...and the girls still won't date you.
Don't think there are any profitable non-evil companies in corporate America to absorb...
It needs wood for the fire. It needs flavour and zest.
The magic of software is that the old rule "You get what you pay for" doesn't apply to it.
However, it does still apply to people. (Although a lot less than the salary of global megacorp CEO's would suggest.)
If we need people to administer and run various Open Source projects, we need to pay them. They need to make a fair living.
Perhaps it's something you're doing....
We emacs users couldn't find a "masochistic" moderation, so we had to go with "funny".
Perhaps instead of microdots they need to add a more specific admonishment. "Thou shalt not receive stolen goods, even if it is a Torah".
Nah. If they don't read the first, they won 't read the second, nor the microdots.
I think the Gideons have the right approach. Make'em cheap, make 'em available, and maybe, just maybe, somebody somewhere will actually _read_ them.
However, there is some good PR value in some of these ports.
He is right though, a bit of strategic thinking would be Good. eg. Think about when dropping a port would merely force some lazy PHB to take the final bold step into the wonderful world of GNU/Linux and when keeping a port is winning valuable support and new recruits. eg. Dropping support for SCO was Good in several ways.
That sounds interesting. Anyone tried it? Any reports? Anyone know of any good / cheap devices to do this?
..these dang newfangled Cars are taking away our business. And when everyone drives cars, who will shoe your horses then?
The really interesting bit is who has been buying the information. This ball has in no way stopped rolling.
Well, the mechanism is in place....
The second that the RIAA felt threatened by the size and zeal of them, they came down hard.
The difference I guess is America trying damn hard to hound Norwegians and Russians and everybody else with DMCA. China is content just to make rumbling noises at North Korea and Taiwan.
I would like to see your response to him.
Speaking as a person living outside both those countries, it looks like you guys are pretty even.
Well, Ruby doesn't warp your brain the way Lisp tends to, but "Why the Lucky Stiff's" Poignant Comic Book Guide to Ruby definitely will definitely umm, errr, it will, ahh, ahh shucks, see for yourself! Why's (Poignant) Guide to Ruby
postscript forth joy or or think? about arse head
Bugger! Where did that "not" go to. I know I meant to type "not being created out of kinetic energy".
One of these days I actually use the preview button.
You can do quite a lot of accelerating with that. Ye olde E=mc^2 converts electrons into 511kev.
ie. The mass of an electron undergoes total matter conversion into a packet of energy equal to the kinetic energy of an electron dropped through a potential difference of 511000 Volts.
Ok, so I assume that field is over quite a small distance, the potential difference is probably a lot less than 25E9 Volts ie a lot less than 49000 electrons. Given that a neutron has a mass of 940MeV/c^2 the neutrons they are measuring are being created out of the kinetic energy.
However, my code always has unit tests, DbC assertions and comments.
I'm also always nagging folk on the subject of comments. Don't bother with comments that can be trivially deduced from just reading the code. Remember humans are input bandwidth limited. ie. We are limited in understanding reams of code by how fast we can read. Thus trivial comments slow us, rather than help us. Always comment at a higher semantic level. State eternals truths (always call this after that or Bad Things happen) about the code, not chat about the current weather. (Nice parameters we're having today...)
Tests are themselves a powerful commentary on the code. They explain graphically what the code does, and in what manner and what order.
However, tests are code too, and are as prone (if not more so) to being as badly written as code.
Which is why Refactoring and TDD go hand in hand. Refactoring improves the code, especially from the clarity and simplicity point of view. However, to refactor effectively and safely, you need a good framework of tests to preserve the functionality.
There is a very nice dualism between tests and code. Tests test (and comment) the code, Code tests (and comment) the tests.
Another good duality is Design by Contract. I use unit tests to constrain the public interface to my code. I use Design by Contract assertions to constrain the private workings of my code. DbC assertions are like coded comments. Think of a comment that asserts that something is true about this code. An assertion turns that comment from a warm fuzzy feeling into a hard fact.