Slashdot Mirror
Interviews: ESR Answers Your Questions
Last week you had the chance to ask ESR about books, guns, and open source software. Below you'll find his answers to those questions.
What about protocols?
by Anonymous Coward
What are your feelings about protocols and file formats and keeping them open? Where do the efforts to keep protocols and file formats open and accessible to others fall on your list of priorities?
ESR: I don't think my answer will surprise you. When the function of software is defined by a requirement to be compatible with a protocol or file format, openness of the protocol or formats is even more important than the licensing status of any of the implementations around it.
The reason should be obvious. If the protocol is well documented and open, you can build open-source code to process it. On the other hand, if crucial parts are undocumented or (worse) require techniques that are under a non-royalty-free patent, *any* code touching it can have a serious problem.
There's a productive analogy with DNA and ribosomes here which I leave for the reader to fill in.
systemd
by Canek
As a long time "Unix philosophy" advocate, and in the light of the announced switch to it by Debian, Ubuntu, and basically every other major Linux distribution, what do you think of systemd, and the tight vertical integration it intends to bring as a standard plumbing for (most of) all Linux distributions?
ESR: I apologize; I haven't studied systemd in the detail that would be required for me to give a firm answer to this - it's been on my to-do list for a while, but I'm buried in other projects.
I want to study it carefully because I'm a bit troubled by what I hear about the feature set and the goals. From that, I fear it may be one of those projects that is teetering right at the edge of manageable complexity - OK as long as an architect with a strong sense of design discipline is running things, but very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.
But this may be me being too pessimistic. I don't actually think I know yet.
here's an obvious one..
by Connie_Lingus
it's been almost 20 years since your write tCatB...i gave it a quick read and thought, "well, it *is* dated now, isn't it?" altho i am old enough to remember when its' ideas were pretty cutting edge. Given the current state of software development (ie the ease of use of PHP and the fact that, without a doubt, the cathedral model has won), what would you either like to change or add to your original thesis?
ESR: Um. What color is the sky on your planet? The one where the cathedral model has won, I mean.
What's happening on Earth is just the opposite - even where bazaar-mode development hasn't taken over, many organizations that would previously have run their projects in a cathedral style are trying really hard to flatten out hierarchies, lighten up, and co-opt the many-eyeballs effect in any way they can. This is pretty clear just from what shows up in my mailbox - and see my later response to a question about Apple, too.
I think there have been some significant shifts in methodology that would affect the book if I were writing it today. A big one is that systematic use of version control is now pervasive in a way it was not then (when CaTB was written, Subversion wasn't out of early alpha stage yet; git and hg weren't even imagined). Development workflow is now correspondingly much more centered around shared public repositories.
The effects of always being able to revert to known codebase states rapidly are subtle but very large. One obvious one is that the risk factor of exploration drops significantly. That includes the risk in taking patches from strangers.
Less obvious but just as important is how sharp version-control tools raise the effectiveness and reduce the friction cost of testing techniques. In 2001 we couldn't routinely run bisections to pinpoint bad code changes; our tools were too slow and clumsy. Now we can, and the effect is to make building good unit and regression-test suites both easier and more rewarding in defects squashed per hours invested.
The reason I'm going on about this is that, like any technique that increases our visibility into the code's behavioral space, better test suites tremendously amplify the positive effects of code review. Of course that feeds through into a differential competitive advantage for open source, because our process naturally recruits more code reviewers than closed-source shops can usually afford to hire.
Here's an example of the effect. There's a project I've led since about 2005 called GPSD, a service daemon that handles GPSes and other geodetic sensors. It's *everywhere* in mobile embedded systems, including your Android phone - we must have well over over a billion deployments by now. Yet our defect rate is so low that months go by at a time between single bug reports.
Why? Because I wrote a test suite with good coverage - and use a test strategy that relies on fast rollback capabilities I plain didn't have before modern version control. Changes in tools change the rules. It's much easier to get to the this-never-breaks level of reliability than it was when I wrote CatB, if you know what you're doing.
(For much more on this case study see my paper on the architecture of GPSD; there's a major section on engineering for high reliability.)
Open-source development has quite a few advantages over closed in exploiting this possibility - better tools, healthier culture, and just plain more developers. I think a major theme of the next decade is going to be learning to systematically capture these gains.
How to ask questions
by houstonbofh
When you wrote "How to ask questions" did you have any idea how big it would be? Or how long it would be relevant? And how do you feel that your most referenced piece of work is a howto for the clueless? :)
ESR: I'm not sure it is my most referenced piece of work. Either "How To Become A Hacker" or the Jargon File could easily be getting more hits; I haven't bothered to track this.
But supposing it is, that's OK. I expect it to be relevant for a very long time, because the newbies and the clueless are always with us.
Halloween Documents
by frdmfghtr
I recall reading (and re-reading on occasion) the Halloween Documents. Have you written anything regarding any other opponents to OSS, or perhaps a look back on them and see what the end effect of Microsoft's attempts did long term?
ESR: I haven't written a retrospective, or anything else really similar.
I think those documents had a pretty significant effect in legitimizing not buying the Microsoft lock-in. The trade press certainly thought so at the time, and the intervening decade and a half hasn't given me any reason to suppose they were wrong.
How essential is software redistribution rights?
by unixisc
One of the issues w/ Open Source has been the freedom to redistribute software downstream - be it just binaries, just source or any combination of the 2. Do you think there are any good ways for software companies who make their software open source to prevent their customers from effectively becoming their competitors - by giving away or selling cheaper what they were sold? Or is the only alternative going for a shared-source approach, as opposed to open source, where redistribution can be explicitly prohibited?
ESR: If your customers are selling your open-source software for a lower price than you are, then you're doing it wrong! You need to face the question of why you've attached a sales price to the software itself at all. I think that's a doomed approach.
You need to be thinking about monetizing that investment in a different way. The most obvious is service and consulting contracts around the code. You have the advantage there; as the originators, you are in a better position to add value to the bundle than your competitors are.
There are a couple other potential business models here, but none I can recommend without knowing more details about your situation. My advice in The Magic Cauldron is still quite relevant.
What about the new wave of proprietary programs
by necro351
So it seems these days the most effective method of DRM is a network interface, like that used by Facebook, Google, Pinterest, etc... You cannot run your own instance of Gmail or Facebook, and you certainly cannot see or modify the code. At the same time all these companies are pressuring us to push our data into their servers by not supporting or coming up with solutions that let us continue to control/manage our data on our own machines and private networks. What can open source do to stem that tide? What about open source licensing? Could webkit or Mozilla have slowed down the encroachment of Chrom/ium and its pro-Google agenda if it had more defensive licensing terms like something similar to the GPL? How do we convince hackers to hack on open-source 'website programs', like an open Gmail or an open Facebook (e.g., Diaspora)?
ESR: You're pointing at a real problem. I don't know of any near-term solutions beyond being very careful what services you allow to draw you into their web. I run my own mailserver, rather than using GMail, for exactly this reason. I don't use Facebook or Pinterest. I use G+ for nonessential things only.
I don't think defensive or reciprocal licensing can solve the problem, because it is not one created by code secrecy. The service providers are trading on real advantages of scale that they would still collect if every line of source code in their app stack were public; the value they're offering actually comes from ubiquity and synergy.
In fact I'm a little surprised they even bother maintaining code secrecy, it has nothing whatsoever to do with their value proposition. I think we're seeing a result of instinctive territoriality rather than rational thought.
I'd love to believe that projects like Diaspora are a long-term solution to the problem, but I don't - basically because no matter how attractive and ingenious your software is, it tales gobs of capital expenditure on server farms to scale up to where you're any kind of functional competition to Facebook/Google/Pinterest etc.
In the long term I think the way we'll win is if the giants have to compete with each other for business by giving their customers exit and recovery options. Google's Data Liberation Front is a positive early sign.
Linus's Law (Many Eyes) Problems
by carp3_noct3m
Hi, there is currently some debate about the many eyes theory over on HNews about why it's a fallacious argument, but in my view they have it all wrong, in that a core component of Linus's Law is that the amount of code is directly inverse to the amount of eyes that can hit all of that code (or a significant percentage). Therefore, in my eyes it is the problem of code bloat that is undermining the open source movement more than anything. For example, the Linux kernel is now at, what, 10mil+ lines of code? That's insane. Minix 3, on the other hand, is at ~15k?
What are your thoughts on this problem?
ESR: I think you raise a valid point about code bloat being a problem. On the other hand, the code-coverage effectiveness of individual developers is also rising for reasons I wrote about in response to a previous question - better tools and better testing strategies feeding back on each other in virtuous ways.
A lot of criticisms of Linus's Law (including the Hacker News thread, as far down as I read it) miss the point that "many eyeballs" isn't just about sheer volume of people reviewing code, it's about diversity of assumptions. You want people reviewing the code that don't all work for the same company and report to the same boss - people who speak different languages, different toolkits, different expertise areas.
A handful of people who think very differently may be more effective auditors than an army with identical blind-spots. By recruiting more people you're maximizing the odds of good diversity in the subgroup that actually reviews any given section of code.
I actually chuckled when I read the Hacker News thread, because I've seen this movie before after every serious security flap in an open-source tool. The script, which includes a bunch of people indignantly exclaiming that many-eyeballs is useless because bug X lurked in a dusty corner for Y months, is so predictable that I can anticipate a lot of the lines.
The mistake being made here is a classic example of Frederic Bastiat's things seen versus things unseen. Critics of Linus's Law overweight the bug they can *see* and underweight the high probability that equivalently positioned closed-source security flaws they *can't* see are actually far worse, just so far undiscovered.
That's how it seems to go whenever we get a hint of the defect rate inside closed-source blobs, anyway. As a very pertinent example, in the last couple months I've learned some things about the security-defect density in proprietary firmware on residential and small business Internet routers that would absolutely curl your hair. It's far, far worse than most people understand out there.
Friends don't let friends run factory firmware. You really do *not* want to be relying on anything less audited than OpenWRT or one of its kindred (DDWRT, or CeroWRT for the bleeding edge). And yet the next time any security flaw turns up in one of those open-source projects, we'll see a replay of the movie with yet another round of squawking about open source not working.
Ironically enough this will happen precisely because the open-source process *is* working ... while, elsewhere, bugs that are *far* worse lurk in closed-source router firmware. Things seen vs. things unseen...
Apple today
by wordtech
Your comments in The Art of Unix Programming about Apple/Mac developers being diametrically opposed to Unix developers in development style and emphases (designing simple, user-friendly interfaces from the outside in) were quite interesting. I am wondering about your perspective on Apple now. My interest is specifically in Apple's contributions to open-source (WebKit and LLVM, chiefly) and your take on those. It seems to me that Apple has done quite a bit to foster an alternative ecosystem to the GNU environment, for instance in FreeBSD's adoption of clang as their default compiler; and also it seems to to me that WebKit has supplanted Gecko as the most widely used browser framework. Curious about your viewpoint here.
ESR: In answering an earlier question I spoke of organizations that would previously have developed in a secretive cathedral mode adopting the bazaar model and open-source practices. Projects like LLVM and Webkit exemplify this trend.
The interesting thing about these projects is that they're not just facades. They really seem to welcome, not just as outside contributors but sometimes as full-time employees, people who are from the Unix-descended open-source culture (with its inside-to-out priorities) rather than interface-centric Mac guys.
That - and of course, OS X - tells us Apple's technical culture in't what it used to be. It's more Unix-influenced now, more open, has more hacker in it. Obviously that doesn't fix every problem with Apple - I'm with RMS in judging the locked-down, walled-garden design of their phones and tablets to be a very bad thing for users in the longer term - but it's movement in a good direction.
AK or AR
by gmhowell
Which is the better battle rifle, an AK-47/74 type or an AR-15/M-16/M-4 type? Please give your criteria as well as your answer. Bonus: favorite handgun platform/caliber that isn't a .45 1911.
ESR: "Better battle rifle" depends on who you're equipping, and for what. I lean towards the AR-15 because I'm from a culture that readily produces people with good marksmanship, fire discipline, and steadiness onder combat pressure. The AR-15 is the better weapon to match those traits - it rewards skill in the shooter and you can actually use it at distance.
On the other hand, if your troops are savages or bandits who can barely clean a weapon and for whom the natural mode is short-range spray'n'pray, the AK-47 is probably a better choice. It hardly rewards shooter skill at all, but handles egregious abuse under field conditions better.
As for what I like when I don't have .45ACP handy, my answer is easy and boring: .40S&W. Medium-caliber semis suit me very well. I don't mind shooting my wife's Glock .40 at all, and it's likely what I'd carry if not for John Moses Browning (peace be unto him)
by Anonymous Coward
What are your feelings about protocols and file formats and keeping them open? Where do the efforts to keep protocols and file formats open and accessible to others fall on your list of priorities?
ESR: I don't think my answer will surprise you. When the function of software is defined by a requirement to be compatible with a protocol or file format, openness of the protocol or formats is even more important than the licensing status of any of the implementations around it.
The reason should be obvious. If the protocol is well documented and open, you can build open-source code to process it. On the other hand, if crucial parts are undocumented or (worse) require techniques that are under a non-royalty-free patent, *any* code touching it can have a serious problem.
There's a productive analogy with DNA and ribosomes here which I leave for the reader to fill in.
systemd
by Canek
As a long time "Unix philosophy" advocate, and in the light of the announced switch to it by Debian, Ubuntu, and basically every other major Linux distribution, what do you think of systemd, and the tight vertical integration it intends to bring as a standard plumbing for (most of) all Linux distributions?
ESR: I apologize; I haven't studied systemd in the detail that would be required for me to give a firm answer to this - it's been on my to-do list for a while, but I'm buried in other projects.
I want to study it carefully because I'm a bit troubled by what I hear about the feature set and the goals. From that, I fear it may be one of those projects that is teetering right at the edge of manageable complexity - OK as long as an architect with a strong sense of design discipline is running things, but very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.
But this may be me being too pessimistic. I don't actually think I know yet.
here's an obvious one..
by Connie_Lingus
it's been almost 20 years since your write tCatB...i gave it a quick read and thought, "well, it *is* dated now, isn't it?" altho i am old enough to remember when its' ideas were pretty cutting edge. Given the current state of software development (ie the ease of use of PHP and the fact that, without a doubt, the cathedral model has won), what would you either like to change or add to your original thesis?
ESR: Um. What color is the sky on your planet? The one where the cathedral model has won, I mean.
What's happening on Earth is just the opposite - even where bazaar-mode development hasn't taken over, many organizations that would previously have run their projects in a cathedral style are trying really hard to flatten out hierarchies, lighten up, and co-opt the many-eyeballs effect in any way they can. This is pretty clear just from what shows up in my mailbox - and see my later response to a question about Apple, too.
I think there have been some significant shifts in methodology that would affect the book if I were writing it today. A big one is that systematic use of version control is now pervasive in a way it was not then (when CaTB was written, Subversion wasn't out of early alpha stage yet; git and hg weren't even imagined). Development workflow is now correspondingly much more centered around shared public repositories.
The effects of always being able to revert to known codebase states rapidly are subtle but very large. One obvious one is that the risk factor of exploration drops significantly. That includes the risk in taking patches from strangers.
Less obvious but just as important is how sharp version-control tools raise the effectiveness and reduce the friction cost of testing techniques. In 2001 we couldn't routinely run bisections to pinpoint bad code changes; our tools were too slow and clumsy. Now we can, and the effect is to make building good unit and regression-test suites both easier and more rewarding in defects squashed per hours invested.
The reason I'm going on about this is that, like any technique that increases our visibility into the code's behavioral space, better test suites tremendously amplify the positive effects of code review. Of course that feeds through into a differential competitive advantage for open source, because our process naturally recruits more code reviewers than closed-source shops can usually afford to hire.
Here's an example of the effect. There's a project I've led since about 2005 called GPSD, a service daemon that handles GPSes and other geodetic sensors. It's *everywhere* in mobile embedded systems, including your Android phone - we must have well over over a billion deployments by now. Yet our defect rate is so low that months go by at a time between single bug reports.
Why? Because I wrote a test suite with good coverage - and use a test strategy that relies on fast rollback capabilities I plain didn't have before modern version control. Changes in tools change the rules. It's much easier to get to the this-never-breaks level of reliability than it was when I wrote CatB, if you know what you're doing.
(For much more on this case study see my paper on the architecture of GPSD; there's a major section on engineering for high reliability.)
Open-source development has quite a few advantages over closed in exploiting this possibility - better tools, healthier culture, and just plain more developers. I think a major theme of the next decade is going to be learning to systematically capture these gains.
How to ask questions
by houstonbofh
When you wrote "How to ask questions" did you have any idea how big it would be? Or how long it would be relevant? And how do you feel that your most referenced piece of work is a howto for the clueless? :)
ESR: I'm not sure it is my most referenced piece of work. Either "How To Become A Hacker" or the Jargon File could easily be getting more hits; I haven't bothered to track this.
But supposing it is, that's OK. I expect it to be relevant for a very long time, because the newbies and the clueless are always with us.
Halloween Documents
by frdmfghtr
I recall reading (and re-reading on occasion) the Halloween Documents. Have you written anything regarding any other opponents to OSS, or perhaps a look back on them and see what the end effect of Microsoft's attempts did long term?
ESR: I haven't written a retrospective, or anything else really similar.
I think those documents had a pretty significant effect in legitimizing not buying the Microsoft lock-in. The trade press certainly thought so at the time, and the intervening decade and a half hasn't given me any reason to suppose they were wrong.
How essential is software redistribution rights?
by unixisc
One of the issues w/ Open Source has been the freedom to redistribute software downstream - be it just binaries, just source or any combination of the 2. Do you think there are any good ways for software companies who make their software open source to prevent their customers from effectively becoming their competitors - by giving away or selling cheaper what they were sold? Or is the only alternative going for a shared-source approach, as opposed to open source, where redistribution can be explicitly prohibited?
ESR: If your customers are selling your open-source software for a lower price than you are, then you're doing it wrong! You need to face the question of why you've attached a sales price to the software itself at all. I think that's a doomed approach.
You need to be thinking about monetizing that investment in a different way. The most obvious is service and consulting contracts around the code. You have the advantage there; as the originators, you are in a better position to add value to the bundle than your competitors are.
There are a couple other potential business models here, but none I can recommend without knowing more details about your situation. My advice in The Magic Cauldron is still quite relevant.
What about the new wave of proprietary programs
by necro351
So it seems these days the most effective method of DRM is a network interface, like that used by Facebook, Google, Pinterest, etc... You cannot run your own instance of Gmail or Facebook, and you certainly cannot see or modify the code. At the same time all these companies are pressuring us to push our data into their servers by not supporting or coming up with solutions that let us continue to control/manage our data on our own machines and private networks. What can open source do to stem that tide? What about open source licensing? Could webkit or Mozilla have slowed down the encroachment of Chrom/ium and its pro-Google agenda if it had more defensive licensing terms like something similar to the GPL? How do we convince hackers to hack on open-source 'website programs', like an open Gmail or an open Facebook (e.g., Diaspora)?
ESR: You're pointing at a real problem. I don't know of any near-term solutions beyond being very careful what services you allow to draw you into their web. I run my own mailserver, rather than using GMail, for exactly this reason. I don't use Facebook or Pinterest. I use G+ for nonessential things only.
I don't think defensive or reciprocal licensing can solve the problem, because it is not one created by code secrecy. The service providers are trading on real advantages of scale that they would still collect if every line of source code in their app stack were public; the value they're offering actually comes from ubiquity and synergy.
In fact I'm a little surprised they even bother maintaining code secrecy, it has nothing whatsoever to do with their value proposition. I think we're seeing a result of instinctive territoriality rather than rational thought.
I'd love to believe that projects like Diaspora are a long-term solution to the problem, but I don't - basically because no matter how attractive and ingenious your software is, it tales gobs of capital expenditure on server farms to scale up to where you're any kind of functional competition to Facebook/Google/Pinterest etc.
In the long term I think the way we'll win is if the giants have to compete with each other for business by giving their customers exit and recovery options. Google's Data Liberation Front is a positive early sign.
Linus's Law (Many Eyes) Problems
by carp3_noct3m
Hi, there is currently some debate about the many eyes theory over on HNews about why it's a fallacious argument, but in my view they have it all wrong, in that a core component of Linus's Law is that the amount of code is directly inverse to the amount of eyes that can hit all of that code (or a significant percentage). Therefore, in my eyes it is the problem of code bloat that is undermining the open source movement more than anything. For example, the Linux kernel is now at, what, 10mil+ lines of code? That's insane. Minix 3, on the other hand, is at ~15k?
What are your thoughts on this problem?
ESR: I think you raise a valid point about code bloat being a problem. On the other hand, the code-coverage effectiveness of individual developers is also rising for reasons I wrote about in response to a previous question - better tools and better testing strategies feeding back on each other in virtuous ways.
A lot of criticisms of Linus's Law (including the Hacker News thread, as far down as I read it) miss the point that "many eyeballs" isn't just about sheer volume of people reviewing code, it's about diversity of assumptions. You want people reviewing the code that don't all work for the same company and report to the same boss - people who speak different languages, different toolkits, different expertise areas.
A handful of people who think very differently may be more effective auditors than an army with identical blind-spots. By recruiting more people you're maximizing the odds of good diversity in the subgroup that actually reviews any given section of code.
I actually chuckled when I read the Hacker News thread, because I've seen this movie before after every serious security flap in an open-source tool. The script, which includes a bunch of people indignantly exclaiming that many-eyeballs is useless because bug X lurked in a dusty corner for Y months, is so predictable that I can anticipate a lot of the lines.
The mistake being made here is a classic example of Frederic Bastiat's things seen versus things unseen. Critics of Linus's Law overweight the bug they can *see* and underweight the high probability that equivalently positioned closed-source security flaws they *can't* see are actually far worse, just so far undiscovered.
That's how it seems to go whenever we get a hint of the defect rate inside closed-source blobs, anyway. As a very pertinent example, in the last couple months I've learned some things about the security-defect density in proprietary firmware on residential and small business Internet routers that would absolutely curl your hair. It's far, far worse than most people understand out there.
Friends don't let friends run factory firmware. You really do *not* want to be relying on anything less audited than OpenWRT or one of its kindred (DDWRT, or CeroWRT for the bleeding edge). And yet the next time any security flaw turns up in one of those open-source projects, we'll see a replay of the movie with yet another round of squawking about open source not working.
Ironically enough this will happen precisely because the open-source process *is* working ... while, elsewhere, bugs that are *far* worse lurk in closed-source router firmware. Things seen vs. things unseen...
Apple today
by wordtech
Your comments in The Art of Unix Programming about Apple/Mac developers being diametrically opposed to Unix developers in development style and emphases (designing simple, user-friendly interfaces from the outside in) were quite interesting. I am wondering about your perspective on Apple now. My interest is specifically in Apple's contributions to open-source (WebKit and LLVM, chiefly) and your take on those. It seems to me that Apple has done quite a bit to foster an alternative ecosystem to the GNU environment, for instance in FreeBSD's adoption of clang as their default compiler; and also it seems to to me that WebKit has supplanted Gecko as the most widely used browser framework. Curious about your viewpoint here.
ESR: In answering an earlier question I spoke of organizations that would previously have developed in a secretive cathedral mode adopting the bazaar model and open-source practices. Projects like LLVM and Webkit exemplify this trend.
The interesting thing about these projects is that they're not just facades. They really seem to welcome, not just as outside contributors but sometimes as full-time employees, people who are from the Unix-descended open-source culture (with its inside-to-out priorities) rather than interface-centric Mac guys.
That - and of course, OS X - tells us Apple's technical culture in't what it used to be. It's more Unix-influenced now, more open, has more hacker in it. Obviously that doesn't fix every problem with Apple - I'm with RMS in judging the locked-down, walled-garden design of their phones and tablets to be a very bad thing for users in the longer term - but it's movement in a good direction.
AK or AR
by gmhowell
Which is the better battle rifle, an AK-47/74 type or an AR-15/M-16/M-4 type? Please give your criteria as well as your answer. Bonus: favorite handgun platform/caliber that isn't a .45 1911.
ESR: "Better battle rifle" depends on who you're equipping, and for what. I lean towards the AR-15 because I'm from a culture that readily produces people with good marksmanship, fire discipline, and steadiness onder combat pressure. The AR-15 is the better weapon to match those traits - it rewards skill in the shooter and you can actually use it at distance.
On the other hand, if your troops are savages or bandits who can barely clean a weapon and for whom the natural mode is short-range spray'n'pray, the AK-47 is probably a better choice. It hardly rewards shooter skill at all, but handles egregious abuse under field conditions better.
As for what I like when I don't have .45ACP handy, my answer is easy and boring: .40S&W. Medium-caliber semis suit me very well. I don't mind shooting my wife's Glock .40 at all, and it's likely what I'd carry if not for John Moses Browning (peace be unto him)
Hey, Eric, does this look like Fortran to you?
Fucking clown.
Watch this Heartland Institute video
Except he misses half the time because of his wonky eye, and he probably can't see past his gut anyways.
I expect it to be relevant for a very long time, because the newbies and the clueless are always with us.
sigh. This is why we will always have spam.
"First they came for the slanderers and i said nothing."
Sorry... it just ain't. Needs to be in a caliber that starts with a "3" (or "7" if you use metric measurements).
How about the FN-FAL or M1a instead?
Don't blame me, I voted for Kodos
Is ESR his rapper name?
SJW's don't eliminate discrimination. They just expropriate it for themselves.
European Space Research?
SJW's don't eliminate discrimination. They just expropriate it for themselves.
A lot of criticisms of Linus's Law (including the Hacker News thread, as far down as I read it) miss the point that "many eyeballs" isn't just about sheer volume of people reviewing code, it's about diversity of assumptions. You want people reviewing the code that don't all work for the same company and report to the same boss - people who speak different languages, different toolkits, different expertise areas.
The many-eyes attempt falters because OSS projects tend to self-select away the differences that would be meaningful. Most people who want to do OSS code want to code, not to debug other people's code (people who like to debug get plenty of that working in the big companies). A newcomer to a project is likely to read over the existing files for a while to try to figure out how to splice in whatever idea they want to work on, and the newcomer's code will be triple-checked by the old-hats, but it's far too easier for the established participants to just trust that their peers are doing enough self-testing.
In a sense, the camaraderie of an OSS project negates much of the many-eyes potential to find flaws. In contrast, the distrust between development groups and testing groups in 'cathedral style' development is often overridden by managerial insistence that a random deadline be met, so many bugs are known but left unsolved (whether they are reported depends on how the management reacts to known-buggy code being released).
He used to share an apartment with RMS and Linus.
So, Julian Assange?
*ducks*
== Jez ==
Do you miss Firefox? Try Pale Moon.
Extended Support Release.
No, it's his Raper Name.
Equivalent Series Resistance
Not all AR-15s are in 5.56 or .223, you know.
Finding God in a Dog
This comment thread really make me feel for the editors.
Stories get posted that aren't exactly "News for Nerds" and they get lambasted for it.
Now here's a story where any good Nerd should know exactly who ESR is and there's complaining about it not being mainstream (i.e. tell us his name) enough.
Damned if you do, damned if you don't.
If you don't know who ESR is you don't belong here. And if you can't Google it, then you really, really don't belong here. I assure you that you are what can only be called an insignificant minority and it is 100% valid for Slashdot to assume its readers either know who ESR is, or at least - if you are one of the few who doesn't know - that you are capable of using a search engine.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Effective Series Resistance
It's an important characteristic of capacitors in high-current situations such as switching power supplies.
http://en.wikipedia.org/wiki/E...
Brought to you by Carl's Junior.
ESR = Eric Steven Raymond the third. I'm kidding about the the third bit.
I thought the funniest thing about this story was how they didn't ask any of the modded-up questions about his racism, climate denial, paranoid conspiracy theories, etc. Then I got to this:
"ESR: "Better battle rifle" depends on who you're equipping, and for what. I lean towards the AR-15 because I'm from a culture that readily produces people with good marksmanship, fire discipline, and steadiness onder combat pressure. The AR-15 is the better weapon to match those traits - it rewards skill in the shooter and you can actually use it at distance."
This is just beyond hilarious; ESR is the ultimate internet tough guy. What exactly in your middle-class suburban "culture" made you steady under "combat pressure"? Do you think this posturing impresses anybody, or makes any of us believe that you wouldn't immediately fold if you faced any danger whatsoever? You know how you can tell if you have "fire discipline" or "steadininess [u]nder pressure"? Actually be in a situation that requires it. Until then you just look ridiculous.
ESR = Eric Steven Raymond the third. I'm kidding about the the third bit.
Damnit. I knew ternary logic was a lie!
It doesn't mean much now, it's built for the future.
Newbs...
I'm not sure about this, but I thought the interviewee just chose the questions they wanted to answer. Maybe not, though.
Assault rifle rounds:
NATO M-16/M-4: 5.56x45
Soviet AK-47: 7.62x39 & 5.45x39
Class-defining StG44: 7.92x33
Battle rifle rounds: .30-06 (7.62x63)
US:
NATO: 7.62x51
Soviet: 7.62x54
But there are a few older, obscure rounds that were under 7mm. So in general, the sign of a "full power" or battle rifle round is to be around 7mm, but the length should be over 50mm, which of course equates to the amount of powder that can be loaded. This produces the 1,000 meter shots that soldiers with battle rifles are expected to make.
This leaves me with one question: What's an ESR?
For a complete and immediate answer, click the first link in the first sentence of the article.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
AR15 is a semi automatic rifle. It is a scary (usually) black gun. Gun control folks like to call these assault weapons.
M16 is a select fire (fully automatic) rifle. These are classed as assault rifles. The key elements are full auto capability and an intermediate cartridge (compared to 308 30'06 and similar physically larger cartridges).
The distinction between fully automatic and semi automatic capabilities is key.
Assault Rifle = Fully automatic rifle firing an intermediate power rifle cartridge
Assault Weapon = PC term for a semi automatic rifle of any caliber which looks scary. The term is intended to be confused with assault rifle, so as to help promote gun control within the US. By blurring the distinction between semi-automatic and full auto weapons, the intention is to get the public to believe the proponents of gun control are trying to keep people from buying machine guns when the reality is that they are already very tightly regulated.
Equivalent Series Resistance. It's a measure of the resistance in a capacitor.
The above is an example of the hostility of tech culture to newcomers. As a tech worker myself, I apologize.
For those who Google "ESR" and wind up here, paradoxically both belonging and not belonging at the same time for having Googled but still not knowing specifically which ESR we're discussing, the original call for questions contains a suitable introduction to Eric S. Raymond. Yes, this link was provided at the top of the page, but better editing skills would have ended this thread before it started.
Very interesting description of how to find bugs. I think this is what OpenBSD said recently, that developing their software on many different - some ancient- architectures helped uncover bugs that didn't pop out on the dominant arch. Maybe there is a force multiplier there.
No True Scottsman, 'eh?
Nerds come in all shapes and flavors. If the article had said, ESR (Eric S. Raymond), author, open source software advocate and Nethack dev-team member answers your questions. , it might have told nerds not familiar with him if they should read the article or not.
judging from Eric's comments, it only validates what I have known since meeting him in person years ago - Eric is still a jerk.
Exactly! No True Scotsman.
On the internet, no one can see your tongue in your cheek.
I was talking about the platform and its derivations in the context of military usage. The original AR-15 was selective fire, and it was adopted by the US military as the M-16. What is marketed to civilians is the semi-automatic version of it.
The difference here is assault rifle (intermediate cartridge) vs. battle rifle (full power cartridge).
It's like those "The More You Know" commercials on NBC. Right?
If you entered ESR into the engine instead of ESR guns open source then you fall into the category of people unable to use a search engine, so no paradox. ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
He mentions his wife but I thought ESR was a corn-holer.
Is that some other Open Source guru I'm thinking of?
If you don't know who ESR is you don't belong here.
And if you don't introduce Three Letter Acronyms (TLAs) the first time you use them, you don't belong on the editing team of this site, nor any other.
If you don't know who ESR is you don't belong here.
3 PM ET Monday and there have been a bare 63 responses posted to "Ask ESR." Most of them content-free.
Either ESR said nothing worth repeating or no one gives a damn.
From skimming the wikipedia description, systemd logs are binary files rather than plain text. That's a huge warning sign that they don't grok the unix philosophy: how am I supposed to grep the logs? Am I supposed to use the search function in some systemd-specific log-viewer?
Skimmers steal card credentials from ATM's!
FBI investigates kidnapping allegations!
NASA sends space probe to the moon!
Open Source legend ESR speaks out!
On Slashdot, every single one of these headlines tells you everything you need to know. If you don't know who ESR is, then you can Google away your ignorance. Spouting the fact that you read Slashdot but have no idea who ESR is, and furthermore no ability to enter ESR guns open source into a search engine to find out, but instead wasting time complaining that the editor didn't know you were ignorant is just stupid.
"What the hell is Nethack? Damn editors..."
Yeah, buddy, Apple sure does seem to welcome outside contributions. They make the money, other people do the work. That's the #1 problem with open source right now - why would I work for free to improve the platforms which Apple is exploiting to make themselves rich? The walled garden model where the open source operating system platform and toolchain is being exploited to make money for big corporations which build their walled gardens on top of open source technology is not good. Chromebooks are the antithesis of what Linux should be as an open platform. Apple is exploiting open source to build their app walled garden. The funny thing is, no one seems to care. Has the technology world simply turned its back on its roots, and given up on openness?
I think it's something along the lines of that old saying about returning WW2 vets..."How do you get the boys back on the farm once they've seen Paris?", well, I was a GNU/Linux true believer for years, dutifully hating Apple and whatnot...until I used OSX in a design class and I realized I had wasted my young years on a shitty project. How do you get the boys to stick with GNU/Linux after they've used a Mac? OSX is the UNIX desktop we've all been waiting for...and it actually arrived more than 10 years ago, I was just to brainwashed to realize...
I think I just died a little. To think that there would come a day when this was asked in all seriousness on Slashdot!
ESR hasn't been relevant in years.
Connie_Lingus:
But you've apparently forgotten how to use apostrophes, you seeping cocksore.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
This is not the first time ESR has been used on this site.
Your point almost withstanding. given it was a call for interesting questions to a person a) you should have googled for a person's name, and b) if you didn't know it right off the bat, the chances you have an either interesting question or care about his answers to anyone else's question is next to none.
If you entered ESR into the engine instead of ESR guns open source then you fall into the category of people unable to use a search engine, so no paradox. ;-)
Hmm, So if you don't know what the acronym ESR is supposed to mean, you should have to parse through the article text just to find search terms to look it up?... Yeah, I'm going for crappy editing. It's pretty standard to state what an acronym (and especially initials for f's sake) means the first time it is used in an article/paper/whatever. At least the first time it is used, and especially on a news aggregator which is likely to a have a range of topics. Now, I've read slashdot long enough to expect horrible, horrible editing. It's not really shocking or a surprise. But defending the bad editing make me think you've been reading slashdot soooo long that your expectations have been badly warped like an abused spouse (e.g. "if you don't like being abused, there must be something wrong with you; It's normal, you should expect it!").
Let's take a second to celebrate the worst person in the world, Eric S. Raymond (ESR) ...the S stands for "stinks of cat piss 24/7"
He's a misogynist, racist, homophobic, tribal neopagan, gun-toting delusional redneck who considers himself an alpha male who felt a deep kinship with his viking ancestors the minute he picked up a sword and shield.
Let's see what this mental master thinks, http://i.imgur.com/s7BBG.png
"I think all teachers, day-care staff, and other adults in loco parentis for groups of children should be required to carry firearms on the job. Maintaining continued proficiency at rapid-reaction tactical shooting should be a condition of their continued employment. Their job is to protect children; if they are not physically, mentally, and morally competent to do that job, they don’t belong in it."
"I’m what [Pick Up Agents] PUAs call a “natural”, a man who figured out much of game on his own and consequently cuts a wide sexual swathe when he cares to. Not quite the same game they’re playing, however. For one thing, I’ve never tried to pick up a woman in a bar in my entire life. College parties when I was a student, yes; SF conventions, neopagan festivals, SCA events, yes; bars, no. Also, and partly as consequence of where I hang out, it has been quite unusual for me to hit on women with IQs below about 120 – and it may well be the case that I’ve never tried to interest a woman with below-average intelligence. (Er, which is not to say they don’t notice me; even in middle age I get lots of IOIs from waitresses and other female service personnel. Any PUA would tell you this is a predictable and unremarkable consequence of being an alpha male.)"
"Are gay men biologically or psychologically prone to rape boys at a level that makes a gay man even without a known history of abuse into a bad risk around boys? Does queer culture encourage a tendency to rape in gay men who are put in authority over boys? To the extent that pederasty, pedophilic impulses, and twink fantasies are normal among homosexual men, putting one in charge of adolescent boys may after all be just as bad an idea as waltzing a man with a known predisposition for alcoholism into a room full of booze."
"if you ever again behave like that kind of disruptive asshole in public, insult me, and jeopardize the interests of our entire tribe, I'll take it just as personally -- and I will find a way to make you regret it. Watch your step."
"I am male, 5'8", about 190lbs, muscular build. Blue eyes, hair of indeterminate brownish/reddish/blond color. I am in good physical shape due to martial-arts training."
ESR HAS A MUSCULAR BUILD
ESR IS IN GOOD PHYSICAL SHAPE
ESR IS DELUSIONAL
"And for any agents or proxy of the regime interested in asking me questions face to face, I’ve got some bullets slathered in pork fat to make you feel extra special welcome."
"No incidence of rape above zero is acceptable to me. I teach women pistol self-defense at no charge. You may correctly infer my motives from the fact that the first time a female student of mine shoots a good tight center-of-mass group, my normal mode of expressing approval is to say “That’s one dead rapist!”"
THAT'S HIS MODE OF EXPRESSING APPROVAL FOR EVERYTHING
HEY ESR WANT TO GET LUNCH?
THAT'S ONE DEAD RAPIST!
HOW ABOUT STEAKS?
THAT'S TWO DEAD RAPISTS!
BEERS LATER?
IT'S AN ORGY OF DEAD RAPISTS IN HERE!
"No; my position is that Polanski should be let go because that’s what Samantha Gailey says she wants — and, as the victim of his rape, hers is the only choice that I think should matter a damn.
If Gailey were calling for Polanski to be chemically castrated or executed, my position would be identical. In fact, if she were calling for him to be executed, I’d cheerfully shoot the bastard myself, and
not be too concerned about sparing any of the slimy Hollywood apologists fo
Yes, because in your eyes, minorities are too stupid and childlike to handle things as dangerous as guns.
Troll.
Here's a hint: You're just as , if not more, racist as the people you decry.
Open Source legend ESR speaks out!
That would have been great. Interviews: ESR Answers Your Questions on the other hand, is mostly useless unless you know what an ESR is.
Thee technology world is turning to appliances. You know, crap that people have to continually replace? That is where money is to be made. Change the package every year and hey its "NEW".
Unless you live in the Crimea.
This comment thread really make me feel for the editors.
Stories get posted that aren't exactly "News for Nerds" and they get lambasted for it.
Now here's a story where any good Nerd should know exactly who ESR is and there's complaining about it not being mainstream (i.e. tell us his name) enough.
Damned if you do, damned if you don't.
Actually, they are both examples of bad editing. The former being bad editorial filtering of stories, the latter is just bad English.
Dear Sanctimonious Douchbag,
If you are unable to have meaningful discourse without throwing in random, meaningless acronyms I suggest you but a shotgun in your mouth and pull the trigger.
Regards,
The rest of the human race
ESR is, among other things, the maintainer of the jargon file. A couple of weeks ago, the jargon file was entioned in a thread. One reader wasn't familiar with and asked for a link. I believe that reader who wanted to look at the jargon file very much belongs here.
> In a sense, the camaraderie of an OSS project negates much of the many-eyes potential to find flaws.
This is, I believe, a misunderstanding of the statement. I'm a little surprised ESR didn't clear this up, but the original statement is "with enough eyeballs bugs are shallow ... the fix will be obvious to someone."
Linus' law (written by ESR) does not say "there will be no bugs". It says that if enough people look at a bug "the solution will be obvious to someone".
Any programmer has had the experience of spending hours chasing a bug down, starting from the symptom and going through many functions in many files to eventually figure it out. That's a deep bug. This is a shallow bug:
if ($password_entered == $correct_password) {
deny_access();
} else {
allow_access();
}
You won't spend hours hunting down the bug in the code above, it's right there where you'd start looking. That's a shallow bug, the problem and solution is obvious.
With enough programmers examining the code, one of them will solve a bug quickly, it will seem shallow to them. That's an entirely different statement from "there will be no bugs".