When I write an e-mail I save it, wait 10 minutes, re-read it, edit it,
then send it.
If only everyone did...
A similar check: imagine you've sent your mail, and receive a personal, conciliatory reply that apologizes for whatever gripe you had and explains what's being done to prevent it in the future. Throw in a word of thanks for alerting them to the issue. Now ask yourself if you'll feel like an ass if you get that reply. If you can't definitively say "no", keep editing.
renumeration? Isn't that what we used to do to our BASIC programs? Is this a subtle reference to Bill Gates's flame that asked, "Why won't you pay for BASIC?".
They had to invest large amounts of money in custom typesetting machines
that were outfitted with extra $ and @ characters.
This is more true than the average Perl acolyte knows. The devout Perl monk has as many nuances on the
$ as the eskimo has words
for snow. To the uninitiated, they all look the same, but let me open
your eyes.
$i is a faithful servant, to whom you entrust the results of
your most elaborate calculation.
$i is an ignoramus who can do little more than count to 10.
$i is steadfast and will never change value.
$i is liable to disappear, and can only be counted on when
you're nearby.
$i is a conniving back-stabber, who will change values in
defiance of all laws of logic and program flow.
TPJ, to its credit, has commissioned fonts for dozens of variants and pays a
premium to the printer. They are pressing for inclusion into Unicode; but
if they don't make it, Perl 6 will specify them in the Unicode private-use
range, so everyone can use them in programs.
Adobe used
to have very restructive technological measures in place to prevent the piracy of their fonts (many of which
resemble Microsoft's current tactics).
I've used Adobe's fonts for years, and I can say none of them look anything like Microsoft's current tactics. Well, maybe Warning Pi, but that's hardly "many".
A post with Score: 6 has appeared on slashdot before (anyone remember it?). This suggests that there was a race in slashcode; and since slashdot still uses a non-transactional data store, I bet the it's still there. I think everyone gets where I'm going with this.
So, here's the plan: First, someone moderates this back down to 4. Second, everyone with mod points synchronizes their clocks to UTC (apt-get install ntp). Third, everyone picks an appropriate (positive, smartass) moderation for this article and moves their pointer over the "Moderate" button. Fourth, at exactly midnight (00:00:00 UTC, June 29), everyone clicks "Moderate".
Everyone without mod points places bets on how high we can get this sucker.
It is reprehensible that Microsoft would "force someone to work on something they don't want to work on."
Dammit, Microsoft! This whole work full time and get paid weekly thing has got to stop! What's next? Demanding
that people meet deadlines and check their work?
Ok, Mr. I won't read the article before posting, even if I don't have to follow a link. The quoted passage actually says that this doesn't happen at Microsoft. It says that nobody is cracking the whip to get the dirty jobs done. In a healthy team environment, people naturally balance what they're interested in, with what has to be done for the project to be successful. No coersion necessary.
This is great news for free software. Actually, it shouldn't be news, because we've already seen it. People have always said that "free software can't produce X, because it's no fun for programmers". And in fact it has always been true that you could find things that free software didn't produce--at a given moment. But time and again, we have seen that when the a need grows strong enough in the community, or when the right leader arrives, people become motivated to produce X, and it gets done. Consider beginner-friently graphical interfaces, business software, quality control. All are receiving increasing attention, and getting done.
Yes, the free software community is often slow to catch on to the importance of a new area. But this is not an inherent property of that area or of our community. It's not because it's dirty work that volunteers won't do. It just means that it's not important to us yet--but when it is, look out!
(Yes, I wish there were some way to made the free software community catch on to new ideas faster. But I'm not optimistic. In many ways we are a very conservative bunch--being highly technical, it's easy for us to meet out needs with fairly basic software, and complacency follows.)
My god did you butcher that poem! This is the slashdot--haven't you learned to cut and paste?? Take away this guy's poetic license and his karma whoring license both!
Reader, you are much more likely to enjoy an unaltered transcription of Updike's Cosmic Gall. (Actually, I'm not sure it is unaltered, but it's at least as good as my memory, and it has the indentation. Depressingly, most versions I found on the web are wrongly formatted and have at least one obvious textual mistake.)
I admit I don't have a response for this (because I don't know much about Be). The only explanation that comes to mind would be that most thread interaction is done in the framework code (ie, the server model or the GUI model), and that was carefully designed and written by the best programmers. If the apps themselves have to think about threads, I find it incredibly hard to believe that they get it right, no matter how clean the design is and how clear the documentation. I distincly recall apps getting flaky when Microsoft started pushing threads. Maybe Be just has better programmers:-)
PS. If be-fan reads this: do you happen to know a Carlin Wiegner, of the Be world some years ago?
Imagine you are writing a server, like say, Apache. So, this server has to handle, oh, about a thousand requests at the
same time. Please tell me what other way to solve this than with threads.
This is a gimme! It's been shown time and again that state-based web servers blow threaded servers out of the water. Find any treatment of web server performance for a demonstration.
Another example is a GUI. Imagine you have an image processing application. This application has a particular
filter which takes ten minutes to execute.
If your filter is long-running, there is no problem having it communicate via a pipe, with the main program using non-blocking read (so the GUI never stalls). I think that GIMP plug-ins do or can work in this way.
What sprung to my mind when I started thinking about this is that Linus
is a very fine Product Manager.... So, the question that springs to mind is
- what place (if any) is there for Product Manager-type role within OSS
projects?
I think your example of Linus reveals two things: One, yes, there is a
place. Two, there is an incredible synergy to having the technical lead and
the product manager be the same person. In fact, I think that number two is
the most important "development model" lesson of Linux.
Simply put, Linux refutes the suggestion that putting the geeks in charge
leads to feature creep, half-finished features, neglect of users, and
ultimately unproductive chaos (I'm sure someone can point out examples of
all of these in Linux, but when you look at the big picture, I don't think
they are critical). If the dev lead takes these issues seriously, he is
capable of controlling them.
The benefits of this arrangement are considerable: The technical focus of
the project is uncompromised, which results in better quality and higher
developer morale. Communication overhead--especially in explaining
technical considerations to a non-technical product manager--is greatly
reduced. And decisions are made by the person who probably cares most
passionately about the product. These factors are the heart of why Linux is
so good (ESR notwithstanding).
Granted, Linus is an unusual talent, but I think many people are capable of
filling the technical lead/product manager role if they really are
conscientious about both. I'm convinced that the product management skills
are much easier to learn than technical--the only obstacle is that most
geeks don't make an honest effort to learn them.
So I think your suggestion of using people who don't want to code as product
managers is misguided. Even with good intentions, a non-technical product
manager is not in the best position to make long-term decisions. In a
volunteer development effort, it's questionable whether anyone would listen
to him anyway. I think the best way for such a person to help is to offer
advice to maintainers, and generally raise awareness of the importance of
things that developers sometimes forget about: testing, documentation,
usability, user responsiveness, etc.
The first rule of multithreaded programming is the same as the first rule of optimization: Don't do it.
Threads are popular (hype aside) because they are a simple abstraction. Simple is usually good--but it's not when it introduces as many pitfalls as threads do. If you don't believe me, I'm probably not going to convince you--but reading a balanced treatment (eg, a systems textbook, not pro-Pthreads, -Win32, -Java hype) might. Most programmers shouldn't write threaded production code, period. Almost every experienced programmer I've talked to agrees.
There are demonstrably better abstractions for almost all problems that threads can solve. Co-routines, continuations, event models, message queues, sockets, shared memory. "Demonstrably" means they get the job done, but clearly introduce fewer possibilities for error and are easier to debug. They have higher conceptual overhead than threads, but they usually pay off. If you think you absolutely need threads for performance--prove it, with hard numbers.
If you use threads, be sure to understand exactly why you're using them and spec your model precisely. Review threaded code and perform load tests early and often.
Everyone who mailed Roblimo asking for this interview, up against the wall. We're very forgiving people here at slashdot, but this cannot go unpunished.
Every application developer has to
incorporate SSL (or whatever), and whenever identities need to be established there's a different way to do it.
The famous end to end argument is simply that every application has different needs. For example, even if you have connection-level encryption, how are you going to verify the authenticity of the message? For that, you will need something like GPG anyway.
"You have zero privacy" is true in a precise sense (which is I think what McNealy meant), and it has nothing to do with the Internet. It means that if someone really wants to find out something (anything) about you, he can. This has always been true for everyone except the most deliberate recluses.
The situation is analogous to computer security: there are a zillion non-obvious paths of attack, so unless you've designed the system with scrupulous attention to security, one of them will find a crack. Have you controlled every channel of information about yourself since before you were born? If not, "you have zero privacy" in that anyone determined can find an "exploit". I don't know how to find out information about people, but I bet once you know, it's child's play (like writing buffer overrun exploits).
I'm not saying that there is no cause for concern about the loss of privacy; I'm saying there's not much you can do about it, so "get over it". Think about how much effort it takes to make a single purchase at Amazon without compromising your privacy. Now, think about how relatively benign Amazon's abuse of privacy is, compared to what someone really nasty could do. I just think this battle isn't worth fighting.
For-profit companies have accepted donations in the form of tips for ages. The parallels to Mandrake's donation request are actually very close once you get past the obvious differences.
Re:What can we do to stop this from happening agai
on
Mandrake Shakeup
·
· Score: 5
Perhaps the answer is to finally admit that the GPL is designed to hurt businesses and programmers -- and is doing it.
Why tools and solutions companies like Cygnus (and Ars Digita, and Ada Core Technologies, and CodeSourcery) have had more success with free software than retail and support companies is an interesting question. Perhaps you should look into it instead of making wild and inflammatory claims.
make network round-trip latency ("ping") harder
to hide.
You mean like the position projection tricks used in Quake clients? That's a good point. I guess the only "secure" solution for that is faster networks:-)
I don't know how extreme he is on this point, but my sense is he takes it too far. Modes in some form are integral to our interactions with machines, people, and the world.
If we forbid modes, a TV remote control must have an on button and an off button. Nobody wants this, because it's much harder to remember which button is which, than it is to observe that the TV is off and deduce that the button will thus turn it on.
The system should always react in the same way to a command.
Very few things in the real world always react the same way to the same command. You don't behave the same way in the library as you would at a friend's home. Your car responds much better to the gas pedal when it's in drive than in neutral. You read people's moods before deciding how to communicate with them.
People can observe and remember a certain amount of context, and tune their behaviors accordingly. It's frequently convenient to enter a mode, because you can forget about everything not appropriate to that mode. This is just as applicable to computers as to the real world--when we perform different activities, we enter different mindsets and adopt different expectations. Computer interfaces should take advantage of this human capability (with appropriate restraint, of course).
Regardless, id software and Valve are both in the same boat: by using an open standard to render their games, they are relying on security through obscurity.
Disregarding the obvious fact (already pointed out) that using an open standard makes games less obscure, you bring up an interesting topic. One of the interesting aspects is that there is in fact no need, in principle, to rely upon obscurity at all.
All the games need to do is perform more computation on the server, to avoid sending "forbidden knowledge" to the clients. If the other guy is hiding behind the wall, figure that out on the server instead of relying on the client (game software, drivers, hardware) to keep the secret. This is expensive, but given the gains in CPU speed and 3D hardware (no reason the server couldn't offload this to a 3D card), I think it may be feasible. And it will only get more feasible in the future, because the cost of figuring out what's visible is increasing much more slowly than the cost of detailed rendering.
Take a look at what Bugtraq's owner had to say at the time
The message you quoted is in fact from the NTBugtraq moderator (who IMO deserves considerably less credibility). The two lists are entirely independent.
Slashdot Mirror
I think the important thing to take away from all this is that Professor Moglen writes his legal documents in LaTeX.
If only everyone did...
A similar check: imagine you've sent your mail, and receive a personal, conciliatory reply that apologizes for whatever gripe you had and explains what's being done to prevent it in the future. Throw in a word of thanks for alerting them to the issue. Now ask yourself if you'll feel like an ass if you get that reply. If you can't definitively say "no", keep editing.
renumeration? Isn't that what we used to do to our BASIC programs? Is this a subtle reference to Bill Gates's flame that asked, "Why won't you pay for BASIC?".
This is more true than the average Perl acolyte knows. The devout Perl monk has as many nuances on the $ as the eskimo has words for snow. To the uninitiated, they all look the same, but let me open your eyes.
TPJ, to its credit, has commissioned fonts for dozens of variants and pays a premium to the printer. They are pressing for inclusion into Unicode; but if they don't make it, Perl 6 will specify them in the Unicode private-use range, so everyone can use them in programs.
%m %n %30<..<%~%#
left-truncates the path to 30 characters, with a leading ...
I've used Adobe's fonts for years, and I can say none of them look anything like Microsoft's current tactics. Well, maybe Warning Pi, but that's hardly "many".
(A best-memory reconstruction of a post by Ken Miller, Harvard undergrad '96-or-so.)
Uh, I'm talking about the "wakka wakka" article, not mine. You know, the gut-bustingly funny one.
A post with Score: 6 has appeared on slashdot before (anyone remember it?). This suggests that there was a race in slashcode; and since slashdot still uses a non-transactional data store, I bet the it's still there. I think everyone gets where I'm going with this.
So, here's the plan: First, someone moderates this back down to 4. Second, everyone with mod points synchronizes their clocks to UTC (apt-get install ntp). Third, everyone picks an appropriate (positive, smartass) moderation for this article and moves their pointer over the "Moderate" button. Fourth, at exactly midnight (00:00:00 UTC, June 29), everyone clicks "Moderate".
Everyone without mod points places bets on how high we can get this sucker.
Ok, Mr. I won't read the article before posting, even if I don't have to follow a link. The quoted passage actually says that this doesn't happen at Microsoft. It says that nobody is cracking the whip to get the dirty jobs done. In a healthy team environment, people naturally balance what they're interested in, with what has to be done for the project to be successful. No coersion necessary.
This is great news for free software. Actually, it shouldn't be news, because we've already seen it. People have always said that "free software can't produce X, because it's no fun for programmers". And in fact it has always been true that you could find things that free software didn't produce--at a given moment. But time and again, we have seen that when the a need grows strong enough in the community, or when the right leader arrives, people become motivated to produce X, and it gets done. Consider beginner-friently graphical interfaces, business software, quality control. All are receiving increasing attention, and getting done.
Yes, the free software community is often slow to catch on to the importance of a new area. But this is not an inherent property of that area or of our community. It's not because it's dirty work that volunteers won't do. It just means that it's not important to us yet--but when it is, look out!
(Yes, I wish there were some way to made the free software community catch on to new ideas faster. But I'm not optimistic. In many ways we are a very conservative bunch--being highly technical, it's easy for us to meet out needs with fairly basic software, and complacency follows.)
Reader, you are much more likely to enjoy an unaltered transcription of Updike's Cosmic Gall . (Actually, I'm not sure it is unaltered, but it's at least as good as my memory, and it has the indentation. Depressingly, most versions I found on the web are wrongly formatted and have at least one obvious textual mistake.)
PS. If be-fan reads this: do you happen to know a Carlin Wiegner, of the Be world some years ago?
This is a gimme! It's been shown time and again that state-based web servers blow threaded servers out of the water. Find any treatment of web server performance for a demonstration.
Another example is a GUI. Imagine you have an image processing application. This application has a particular filter which takes ten minutes to execute.
If your filter is long-running, there is no problem having it communicate via a pipe, with the main program using non-blocking read (so the GUI never stalls). I think that GIMP plug-ins do or can work in this way.
I think your example of Linus reveals two things: One, yes, there is a place. Two, there is an incredible synergy to having the technical lead and the product manager be the same person. In fact, I think that number two is the most important "development model" lesson of Linux.
Simply put, Linux refutes the suggestion that putting the geeks in charge leads to feature creep, half-finished features, neglect of users, and ultimately unproductive chaos (I'm sure someone can point out examples of all of these in Linux, but when you look at the big picture, I don't think they are critical). If the dev lead takes these issues seriously, he is capable of controlling them.
The benefits of this arrangement are considerable: The technical focus of the project is uncompromised, which results in better quality and higher developer morale. Communication overhead--especially in explaining technical considerations to a non-technical product manager--is greatly reduced. And decisions are made by the person who probably cares most passionately about the product. These factors are the heart of why Linux is so good (ESR notwithstanding).
Granted, Linus is an unusual talent, but I think many people are capable of filling the technical lead/product manager role if they really are conscientious about both. I'm convinced that the product management skills are much easier to learn than technical--the only obstacle is that most geeks don't make an honest effort to learn them.
So I think your suggestion of using people who don't want to code as product managers is misguided. Even with good intentions, a non-technical product manager is not in the best position to make long-term decisions. In a volunteer development effort, it's questionable whether anyone would listen to him anyway. I think the best way for such a person to help is to offer advice to maintainers, and generally raise awareness of the importance of things that developers sometimes forget about: testing, documentation, usability, user responsiveness, etc.
Threads are popular (hype aside) because they are a simple abstraction. Simple is usually good--but it's not when it introduces as many pitfalls as threads do. If you don't believe me, I'm probably not going to convince you--but reading a balanced treatment (eg, a systems textbook, not pro-Pthreads, -Win32, -Java hype) might. Most programmers shouldn't write threaded production code, period. Almost every experienced programmer I've talked to agrees.
There are demonstrably better abstractions for almost all problems that threads can solve. Co-routines, continuations, event models, message queues, sockets, shared memory. "Demonstrably" means they get the job done, but clearly introduce fewer possibilities for error and are easier to debug. They have higher conceptual overhead than threads, but they usually pay off. If you think you absolutely need threads for performance--prove it, with hard numbers.
If you use threads, be sure to understand exactly why you're using them and spec your model precisely. Review threaded code and perform load tests early and often.
Everyone who mailed Roblimo asking for this interview, up against the wall. We're very forgiving people here at slashdot, but this cannot go unpunished.
The famous end to end argument is simply that every application has different needs. For example, even if you have connection-level encryption, how are you going to verify the authenticity of the message? For that, you will need something like GPG anyway.
Go read it. It's good.
The situation is analogous to computer security: there are a zillion non-obvious paths of attack, so unless you've designed the system with scrupulous attention to security, one of them will find a crack. Have you controlled every channel of information about yourself since before you were born? If not, "you have zero privacy" in that anyone determined can find an "exploit". I don't know how to find out information about people, but I bet once you know, it's child's play (like writing buffer overrun exploits).
I'm not saying that there is no cause for concern about the loss of privacy; I'm saying there's not much you can do about it, so "get over it". Think about how much effort it takes to make a single purchase at Amazon without compromising your privacy. Now, think about how relatively benign Amazon's abuse of privacy is, compared to what someone really nasty could do. I just think this battle isn't worth fighting.
For-profit companies have accepted donations in the form of tips for ages. The parallels to Mandrake's donation request are actually very close once you get past the obvious differences.
Oddly, the founder of a wildly successful free company doesn't agree. "I saw [in the GNU Manifesto] a business plan in disguise." Michael Tiemann, Future of Cygnus Solutions: An Entrepreneur's Account.
Why tools and solutions companies like Cygnus (and Ars Digita, and Ada Core Technologies, and CodeSourcery) have had more success with free software than retail and support companies is an interesting question. Perhaps you should look into it instead of making wild and inflammatory claims.
You mean like the position projection tricks used in Quake clients? That's a good point. I guess the only "secure" solution for that is faster networks :-)
I don't know how extreme he is on this point, but my sense is he takes it too far. Modes in some form are integral to our interactions with machines, people, and the world.
If we forbid modes, a TV remote control must have an on button and an off button. Nobody wants this, because it's much harder to remember which button is which, than it is to observe that the TV is off and deduce that the button will thus turn it on.
The system should always react in the same way to a command.
Very few things in the real world always react the same way to the same command. You don't behave the same way in the library as you would at a friend's home. Your car responds much better to the gas pedal when it's in drive than in neutral. You read people's moods before deciding how to communicate with them.
People can observe and remember a certain amount of context, and tune their behaviors accordingly. It's frequently convenient to enter a mode, because you can forget about everything not appropriate to that mode. This is just as applicable to computers as to the real world--when we perform different activities, we enter different mindsets and adopt different expectations. Computer interfaces should take advantage of this human capability (with appropriate restraint, of course).
Disregarding the obvious fact (already pointed out) that using an open standard makes games less obscure, you bring up an interesting topic. One of the interesting aspects is that there is in fact no need, in principle, to rely upon obscurity at all.
All the games need to do is perform more computation on the server, to avoid sending "forbidden knowledge" to the clients. If the other guy is hiding behind the wall, figure that out on the server instead of relying on the client (game software, drivers, hardware) to keep the secret. This is expensive, but given the gains in CPU speed and 3D hardware (no reason the server couldn't offload this to a 3D card), I think it may be feasible. And it will only get more feasible in the future, because the cost of figuring out what's visible is increasing much more slowly than the cost of detailed rendering.
There are times when the truth spoken plainly sounds louder than all of Madison Avenue. Just watch--this message will get through.
The message you quoted is in fact from the NTBugtraq moderator (who IMO deserves considerably less credibility). The two lists are entirely independent.