You're right in the technical aspects, but I believe the big problem isn't technical.
I agree with Dan in these two:
The big mistake was not to extend IPv4 to make it easier for normal users to adopt the New Way.
The problem that the previous mistake caused is that most normal users are deadlocked, all of them waiting for the others to adopt the New Way first.
That's why I think this discussion is quite relevant, especially if you expect IPv6 to finally enter the mainstream. It seems the mainstream is deadlocked. That won't be solved by pitching the technology, they don't care. They are sensitive to economic arguments and to marketing, and both are stacked against IPv6.
I post from Europe, and we've been enticed and encouraged to adopt IPv6 for years. However, it remains exotic for most techies and almost completely unknown to normal users. Why? Because IPv4 already won. Even if I decide to embrace IPv6 myself, I can't recommend it to paying clients who hire me to help them avoid dumb mistakes. The adoption of a new technology to do the job of an existing and deployed old technology that seems to work OK, and a real expense to get some unknown benefit with no timeframe will look like a dumb mistake to many of them. And I can't change their short-term way of thinking.
Some people think incremental steps like this will somehow help IPv6 rollout worldwide. I think that is a completely different problem, and very hard to solve. Any volunteers to solve the hard and difficult problem?
The best description I know about The Problem comes from Dan Bernstein, The IPv6 mess.
The IPv6 designers don't have a transition plan. They've taken some helpful steps, but they typically declare success (``IPv6 support'') when the real problem---making public IPv6 addresses work just as well as public IPv4 addresses---still hasn't been solved.
McVoy said what the problem with Tridgell's work was. It's up to each of us to believe him or not:
Concurrently we were working with OSDL's management. In this area I pulled in calmer heads than mine and our VP of sales got involved. He negotiates all of our enterprise level agreements, (his strength is finding common ground) so you can imagine he's a pretty reasonable guy. He was unsuccessful in getting anywhere with OSDL's CEO. Stuart's position was that this was not their problem and this is the sort of activity you expect in the open source world. We did get a verbal promise from OSDL that Tridge had discontinued his work and would not begin again as long as we were trying to work things out. We believed we had an uneasy truce, but it ends up Tridge was still working.
We ended up in a no-win situation. OSDL didn't appear to care and we couldn't trust what we were being told. With that we were fairly confident that Tridge was going to release his code. That was a problem for us for two reasons:
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
If Tridge's tool is out there we are now supporting our code and his code. We couldn't do that.
b) IP loss. If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering.
Internally, we were looking at ways to best handle this. One option was to have two versions of BK, one that we gave away and another that was commercial only. This had been our course for some time and it wasn't working out. The difficulty with that solution is we couldn't just stop all work on the free version because of future compatibility issues. Trying to maintain compatibility between a free product and commercial version was grinding our development to a halt. Everyone was losing. In order for this to work we had to continuing throwing resources at the problem. We're already up to about $500K/year for the free version and continuing to ratchet that up wouldn't be prudent.
At that point we started looking at what it would be like to discontinue the free BK. Linus strongly encouraged us to do this once he came to the conclusion that the costs of the free version to BitMover outweighed the benefits to BitMover.
OSDL's management was kept informed of what we were thinking and again they seemed rather apathetic about it. Their position was that it was BitMover's problem and we needed to figure out how to fix it. That is until we set the wheels in motion to discontinue the free product. They did make motions very recently that we should work together on this, but it was too little too late. http://os.newsforge.com/os/05/04/11/118211.shtml?t id=152&tid=2&tid=25&tid=3
Nevertheless, most of those angry with Linus like to refer again and again to the unbelievably bad decision he made in 2002 when he chose closed-source BK, and to the pain that all of us could avoid if he wouldn't have chosen BK in the first place. The point of my previous post is that Linus was a good engineer back then, and did the right thing to get results, because BK was a unique tool. Many people feel the current pain, but seem to be unaware of the great results BK made possible, and Linus himself reminds us:
I think everybody saw the split as inevitable _eventually_. I don't think anybody believes that the open-source SCMs wouldn't grow up, and when they would, there would have been obvious reasons to switch over eventually.
But I think it could have been a lot less painful if it happened a year or two down the road, and that's my only real regret. That said, we did get three very productive years out of it, and we not only learnt how S
Linus is right in what he said. He may look like an idiot right now, but he isn't. Please read his posts (cited below), and don't believe hearsay.
He said this episode is damaging to the Linux kernel *project*, because he took advantage of, and depended on, BK's *functionality*, not BK per se. He said there isn't any other app (open or closed) that offers that functionality, and that he would rather write a new one himself.
[...] It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea.
[...]
Now, I'm dealing with the fall-out, and I'll write my own kernel source tracking tool because I can't use the best any more. That's ok - I deal with my own problems, thank you very much. But what I find sad is how some people are so _gleeful_ about a commercial program becoming less useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee. But in this case it was the commercial people who did the impressive technology and pushed technology forward. And I'm just honest enough to be able to say that. http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11
So: true support for totally distributed development (replication doesn't count), performance, and trust. Nothing else matters. And BK does those better than anything else I've seen.
(Well, at least I hope those are the only three things that matter. The quick-hack framework I'm putting together bases its entire design on just those three things, and maybe I'll find out that I'm wrong, and that there are three other things that I just took for granted;) http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=5&entryID=49321&room ID=11
He said he doesn't believe in the open-or-nothing 'solution'.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned. http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11
He did NOT say Tridgell didn't have a right to do what he did. He said Tridgell's goal was not to develop an alternative to BK right now (and therefore his current work wasn't a solution to his dependence 'problem'), and now the *project* is going to suffer.
But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
I understand that is true in many situations. In fact, Holub himself agrees with you.
... I do believe that data flow should be minimized in a system, and that methods generally should not return basic types (with the exception of boolean), but there's certainly nothing at all wrong with a method that returns an object that implements a known public interface....
Besides that, he tries to emphasize design process, to invite us to keep in mind OO principles while looking for an ideal design first, and to settle for something less than ideal afterwards, as late as possible. In a nutshell, if getters or setters are to be used, they ought to be included at the end of the design process, only if a better solution isn't found, but not at the beginning (that's what he regards as evil).
I've tried his approach and the designs are much better than whatever I am able to conceive any other way (I'm not surprised). But it takes more effort and commitment, of course. And it takes longer.
Well, Holub explains this at length in his article. Let me rephrase and summarize what I understand of what he says.
I think his chain of reasoning (and mine:) is somewhat like this (anyone can personally agree or disagree with any of these, of course):
- Software design is a separate activity, different from coding. - Good software designs must stick to their underlying paradigm (OO in this case) as much as possible, to reap as much of its benefits as possible. - Encapsulation is a quality that provides most of the benefits of OO. - Encapsulation is a quality that good OO designs must pursue with a passion, or else they are very bad OO designs, measured in OO benefits reaped. - Encapsulation means knowing as little as possible about the inner implementation of an object, ideally nothing. - Knowing nothing about the inner implementation of an object, and still be able to work with it, is almost always possible. - Getter and setter methods reveal part of the inner implementation of an object, so using them means running away from encapsulation and embracing the opposite. - Getter and setter methods are very bad for the quality of the design that includes them.
I don't think Holub believes getter and setter are *always* bad. I do think he believes getter and setter methods are overused. I also think he believes the availability of getter and setter methods discourages long and hard thinking about the best possible design in a given circumstance, so he naturally prefers to approach OO design as if getters and setters would not exist.
My personal opinion (and experience) is that he is spectacularly right.
These phrases from his article include the above, in his words:
A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
One basic principle of OO systems is data abstraction. You should completely hide the way in which an object implements a message handler from the rest of the program. That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
This implementation hiding principle leads to a good acid test of an OO system's quality: Can you make massive changes to a class definition--even throw out the whole thing and replace it with a completely different implementation--without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other OO features.
Since accessors violate the encapsulation principle, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented. If you go through a design process, as opposed to just coding, you'll find hardly any accessors in your program. The process is important.
Dihydrogen Monoxide (DHMO) is a colorless and odorless chemical compound, also referred to by some as Dihydrogen Oxide, Hydrogen Hydroxide, Hydronium Hydroxide, or simply Hydric acid.
I am not a chemist, so I searched all those names in the best source I know (which is here), and found that Dihydrogen Oxide is a fancy name of water (H2O).
LCRZO is a network library to do exactly what you need. You can find it here.
Quoting from Laurent's website:
Lcrzo is a network library, for network administrators and network hackers. Its objective is to easily create network programs. This library provides network functionnalities for Ethernet, IP, UDP, TCP, ICMP, ARP and RARP protocols. It supports spoofing, sniffing, client and server creation. Furthermore, lcrzo contains high level functions dealing with data storage and handling. Using all these functions, you can quickly create a network test program.
The library lcrzo provides:
+ network functionnalities:
- address conversion
- packet encoding/decoding/printing
- spoofing
- real/virtual UDP/TCP clients/servers
- sniffing
- device(network board) dealing
- etc.
+ and general functionnalities:
- data conversion
- chained list
- IPC
- etc.
In fact, I don't care. It seems not many people realize how right Joel is in most of what he says. That's because it's difficult to understand some grim realities of software development, particularly about project management, without real experience in a similar setting. I run my own software company, so I fight daily the problems Joel talks about. My clients are corporations, and my software is custom, so my context is not the same as his. Nevertheless, I've failed less often thanks to his advice. I want to give credit when credit is due.
I see that many posts try to point out what Joel does not get right. I know that he is spectacularly right about at least one thing. Why not read about it in his own words?
I could rant a bit about how wrong (or right) Joel is about lots of topics, but that would be a little redundant.
Instead, I would like to say thank you. Thanks, Joel, for writing about your opinions and experiences, the lessons you learned, what you did wrong. Thanks for taking the time to tell us. It doesn't matter if we agree with you or not. Thanks for trying to help, you centainly help me a lot.
During the months of September, October, November, and December, I will not be reading any mail about purported errors in my books, because all the master files are at Stanford in a standalone computer that will be turned off. After Y2K I'll get back to the routine of bug-fixing as usual. (Any rewards for bugs reported during my downtime will be increased by adding interest compounded from the time they were received.)
I emailed my first bug on Sept. 22, 1999. The letter from Knuth was postmarked Jan. 10, 2000. Inside the envelope, I found the following note:
24 December 1999
Dear helper,
While I was away from Stanford during the last four months of 1999, my home computer - on which I keep all the master files for my books - was shut off. Thus I had to wait to process all errata until returning home this week.
Thanks for your patience awaiting my reply. I have computed the amount of your reward by adding interest at 5%, compounded continuously from the day of your letter until 1 January 2000.
I'm writing the checks today, but Stanford will be closed next week; so my secretary will not be able to mail this letter until Y2K is with us. With luck, however, the US Postal Service will survive and will deliver your check before your patience wears too thin.
My books owe a great deal to careful readers like you. Therefore I hope you'll continue to let me know whenever you find anything wrong.
In the future, just after contacting with alien civilizations, we humans will be able to chat with the aliens about all the funny physics experiments we came up with, and ask them if they also carried them out. Imagine the conversations:
Human:By the way, did you try to beam neutrinos across your planet and gain some insights into the charge-parity violation? We based all our theories on the results of that revolutionary experiment.
Alien (translated):Yes, being there, done that, half an eon ago. And you got it wrong, see, this "y = i++;" is really "y = ++i". You should have abandoned C long ago.
It turned out that all self-publishing required was a really good book designer, some money, and a large garage. For capital, I took out another mortgage on my house. This also concentrated my mind, in part because interest rates were 18% at the time. The bank officer said this was the second most unusual loan that she had ever made; first place belonged to a loan to a circus to buy an elephant!
My view on self-publishing was to go all out, to make the best and most elegant and wonderful book possible, without compromise. Otherwise, why do it? If I wanted to mess it up, I could have gone to a real publisher. And I also wanted a reasonable price so that the book would be widely accessible. It all worked out, dreamlike
And the reason that there are so many bugs in the first place is because that is the nature of software. Any piece of code, even slightly complex, will probably be buggy until you take the time to debug it.
Sorry, but you are wrong. Bugs are not the nature of software, but a symptom of the nature of human beings.
Our software is faulty because we are fallible. And that's because our software development processes mostly suck. Is your software buggy? Your process was lousy, and your own fallibility got you.
I would like to ask every coder around here to read this great article, only to learn a little about what perfect software development takes, and how difficult it is to tame our own tendency to screw things up.
Of course it is possible to write perfect software, just eliminate the coders' ability to fail. Perfect software development is very non-human.
I don't say that VA Linux people aren't honest, I am sure they are very nice. I just asked because I'm still confused about what's acceptable or not when using (or abusing) the Linux trademark, and Linus didn't mention this particular issue.
I think that the 4-character limitation in NASDAQ ticker symbols actually makes this worse than domain name squatting, because there aren't many ticker symbols that rhyme with Linux. Now, one of them is used by a company that sells hardware, congratulations to them.
The problem with 'LNUX' is that some investors will think VA Linux is the only Linux company listed on NASDAQ, others will think that Linux is a piece of hardware, others will think that Linux needs special hardware to run on, and others, who knows what they will think!
In contrast (to give some tangible examples), something like "VA Linux" or "Red Hat Linux" oviously isn't a generic term: it's a very _targeted_ term for something very specific. Those kinds of names do not detract from other peoples ability to call _their_ Linux company something else.
I'm confused. If Linus believes this, I don't know why he let VA Linux choose 'LNUX' as their NASDAQ ticker symbol. They should have chosen perhaps 'VALX', and not be too general. After all, aren't NASDAQ symbols just like domain names?
In my opinion, Red Hat did the right thing with 'RHAT'
It's a pretty thought, but it doesn't work out that way in practice. We will probably win, but it won't be just because we played fair.
I acknowledge that not many people believe in fair-play right now, but I don't care, because races can't be won by everybody. Most races allow only one winner, and I believe that fair-play is a real help in many races that really matter.
Slashdot Mirror
I agree with Dan in these two:
- The big mistake was not to extend IPv4 to make it easier for normal users to adopt the New Way.
- The problem that the previous mistake caused is that most normal users are deadlocked, all of them waiting for the others to adopt the New Way first.
That's why I think this discussion is quite relevant, especially if you expect IPv6 to finally enter the mainstream. It seems the mainstream is deadlocked. That won't be solved by pitching the technology, they don't care. They are sensitive to economic arguments and to marketing, and both are stacked against IPv6.I post from Europe, and we've been enticed and encouraged to adopt IPv6 for years. However, it remains exotic for most techies and almost completely unknown to normal users. Why? Because IPv4 already won. Even if I decide to embrace IPv6 myself, I can't recommend it to paying clients who hire me to help them avoid dumb mistakes. The adoption of a new technology to do the job of an existing and deployed old technology that seems to work OK, and a real expense to get some unknown benefit with no timeframe will look like a dumb mistake to many of them. And I can't change their short-term way of thinking.
Some people think incremental steps like this will somehow help IPv6 rollout worldwide. I think that is a completely different problem, and very hard to solve. Any volunteers to solve the hard and difficult problem?
The best description I know about The Problem comes from Dan Bernstein, The IPv6 mess.
The IPv6 designers don't have a transition plan. They've taken some helpful steps, but they typically declare success (``IPv6 support'') when the real problem---making public IPv6 addresses work just as well as public IPv4 addresses---still hasn't been solved.
McVoy said what the problem with Tridgell's work was. It's up to each of us to believe him or not:
Concurrently we were working with OSDL's management. In this area I pulled in calmer heads than mine and our VP of sales got involved. He negotiates all of our enterprise level agreements, (his strength is finding common ground) so you can imagine he's a pretty reasonable guy. He was unsuccessful in getting anywhere with OSDL's CEO. Stuart's position was that this was not their problem and this is the sort of activity you expect in the open source world. We did get a verbal promise from OSDL that Tridge had discontinued his work and would not begin again as long as we were trying to work things out. We believed we had an uneasy truce, but it ends up Tridge was still working.
We ended up in a no-win situation. OSDL didn't appear to care and we couldn't trust what we were being told. With that we were fairly confident that Tridge was going to release his code. That was a problem for us for two reasons:
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
If Tridge's tool is out there we are now supporting our code and his code. We couldn't do that.
b) IP loss. If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering.
Internally, we were looking at ways to best handle this. One option was to have two versions of BK, one that we gave away and another that was commercial only. This had been our course for some time and it wasn't working out. The difficulty with that solution is we couldn't just stop all work on the free version because of future compatibility issues. Trying to maintain compatibility between a free product and commercial version was grinding our development to a halt. Everyone was losing. In order for this to work we had to continuing throwing resources at the problem. We're already up to about $500K/year for the free version and continuing to ratchet that up wouldn't be prudent.
At that point we started looking at what it would be like to discontinue the free BK. Linus strongly encouraged us to do this once he came to the conclusion that the costs of the free version to BitMover outweighed the benefits to BitMover.
OSDL's management was kept informed of what we were thinking and again they seemed rather apathetic about it. Their position was that it was BitMover's problem and we needed to figure out how to fix it. That is until we set the wheels in motion to discontinue the free product. They did make motions very recently that we should work together on this, but it was too little too late.
http://os.newsforge.com/os/05/04/11/118211.shtml?t id=152&tid=2&tid=25&tid=3
Nevertheless, most of those angry with Linus like to refer again and again to the unbelievably bad decision he made in 2002 when he chose closed-source BK, and to the pain that all of us could avoid if he wouldn't have chosen BK in the first place. The point of my previous post is that Linus was a good engineer back then, and did the right thing to get results, because BK was a unique tool. Many people feel the current pain, but seem to be unaware of the great results BK made possible, and Linus himself reminds us:
I think everybody saw the split as inevitable _eventually_. I don't think anybody believes that the open-source SCMs wouldn't grow up, and when they would, there would have been obvious reasons to switch over eventually.
But I think it could have been a lot less painful if it happened a year or two down the road, and that's my only real regret. That said, we did get three very productive years out of it, and we not only learnt how S
Linus is right in what he said. He may look like an idiot right now, but he isn't. Please read his posts (cited below), and don't believe hearsay.
He said this episode is damaging to the Linux kernel *project*, because he took advantage of, and depended on, BK's *functionality*, not BK per se. He said there isn't any other app (open or closed) that offers that functionality, and that he would rather write a new one himself.
[...] It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea.
[...]
Now, I'm dealing with the fall-out, and I'll write my own kernel source tracking tool because I can't use the best any more. That's ok - I deal with my own problems, thank you very much. But what I find sad is how some people are so _gleeful_ about a commercial program becoming less useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee. But in this case it was the commercial people who did the impressive technology and pushed technology forward. And I'm just honest enough to be able to say that.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11
So: true support for totally distributed development (replication doesn't count), performance, and trust. Nothing else matters. And BK does those better than anything else I've seen. ;)
(Well, at least I hope those are the only three things that matter. The quick-hack framework I'm putting together bases its entire design on just those three things, and maybe I'll find out that I'm wrong, and that there are three other things that I just took for granted
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=5&entryID=49321&room ID=11
He said he doesn't believe in the open-or-nothing 'solution'.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11
He did NOT say Tridgell didn't have a right to do what he did. He said Tridgell's goal was not to develop an alternative to BK right now (and therefore his current work wasn't a solution to his dependence 'problem'), and now the *project* is going to suffer.
But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
I understand that is true in many situations. In fact, Holub himself agrees with you.
... I do believe that data flow should be minimized in a system, and that methods generally should not return basic types (with the exception of boolean), but there's certainly nothing at all wrong with a method that returns an object that implements a known public interface. ...
Besides that, he tries to emphasize design process, to invite us to keep in mind OO principles while looking for an ideal design first, and to settle for something less than ideal afterwards, as late as possible. In a nutshell, if getters or setters are to be used, they ought to be included at the end of the design process, only if a better solution isn't found, but not at the beginning (that's what he regards as evil).
I've tried his approach and the designs are much better than whatever I am able to conceive any other way (I'm not surprised). But it takes more effort and commitment, of course. And it takes longer.
Well, Holub explains this at length in his article. Let me rephrase and summarize what I understand of what he says.
:) is somewhat like this (anyone can personally agree or disagree with any of these, of course):
I think his chain of reasoning (and mine
- Software design is a separate activity, different from coding.
- Good software designs must stick to their underlying paradigm (OO in this case) as much as possible, to reap as much of its benefits as possible.
- Encapsulation is a quality that provides most of the benefits of OO.
- Encapsulation is a quality that good OO designs must pursue with a passion, or else they are very bad OO designs, measured in OO benefits reaped.
- Encapsulation means knowing as little as possible about the inner implementation of an object, ideally nothing.
- Knowing nothing about the inner implementation of an object, and still be able to work with it, is almost always possible.
- Getter and setter methods reveal part of the inner implementation of an object, so using them means running away from encapsulation and embracing the opposite.
- Getter and setter methods are very bad for the quality of the design that includes them.
I don't think Holub believes getter and setter are *always* bad. I do think he believes getter and setter methods are overused. I also think he believes the availability of getter and setter methods discourages long and hard thinking about the best possible design in a given circumstance, so he naturally prefers to approach OO design as if getters and setters would not exist.
My personal opinion (and experience) is that he is spectacularly right.
These phrases from his article include the above, in his words:
A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
One basic principle of OO systems is data abstraction. You should completely hide the way in which an object implements a message handler from the rest of the program. That's one reason why all of your instance variables (a class's nonconstant fields) should be private.
This implementation hiding principle leads to a good acid test of an OO system's quality: Can you make massive changes to a class definition--even throw out the whole thing and replace it with a completely different implementation--without impacting any of the code that uses that class's objects? This sort of modularization is the central premise of object orientation and makes maintenance much easier. Without implementation hiding, there's little point in using other OO features.
Since accessors violate the encapsulation principle, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented. If you go through a design process, as opposed to just coding, you'll find hardly any accessors in your program. The process is important.
From the DHMO FAQ, in the website you mention:
Dihydrogen Monoxide (DHMO) is a colorless and odorless chemical compound, also referred to by some as Dihydrogen Oxide, Hydrogen Hydroxide, Hydronium Hydroxide, or simply Hydric acid.
I am not a chemist, so I searched all those names in the best source I know (which is here), and found that Dihydrogen Oxide is a fancy name of water (H2O).
scorecard.org (founded by Philip Greenspun, by the way) contains a whole lot of information about pollutants. They maintain a list of suspected neurotoxicants (the section about mercury compounds is a little scary).
However, there is no shortage of theories to explain the surge in autism. There are two of them that seem to deserve some research:
- Autism is caused by mercury (thimerosal) in vaccines.
- Autism is caused by methylmercury in fish, when eaten during pregnancy.
The FDA already discourages eating some types of fish during pregnancy (they even publish mercury levels in seafood).I remember to have read about this topic in a fascinating book by Peter Huber, engineer, lawyer and insightful writer.
The book is titled "Orwell's Revenge, The 1984 Palimpsest", and, amazingly, its text is freely available here.
Go ahead and read it (240 pages). Much better than the article.
LCRZO is a network library to do exactly what you need. You can find it here.
: : :
Quoting from Laurent's website:
Lcrzo is a network library, for network administrators and network hackers.
Its objective is to easily create network programs. This library provides network functionnalities for Ethernet, IP, UDP, TCP, ICMP, ARP and RARP protocols. It supports spoofing, sniffing, client and server creation. Furthermore, lcrzo contains high level functions dealing with data storage and handling. Using all these functions, you can quickly create a network test program.
The library lcrzo provides
+ network functionnalities
- address conversion
- packet encoding/decoding/printing
- spoofing
- real/virtual UDP/TCP clients/servers
- sniffing
- device(network board) dealing
- etc.
+ and general functionnalities
- data conversion
- chained list
- IPC
- etc.
Yes, you just did it.
In fact, I don't care. It seems not many people realize how right Joel is in most of what he says. That's because it's difficult to understand some grim realities of software development, particularly about project management, without real experience in a similar setting. I run my own software company, so I fight daily the problems Joel talks about. My clients are corporations, and my software is custom, so my context is not the same as his. Nevertheless, I've failed less often thanks to his advice. I want to give credit when credit is due.
I see that many posts try to point out what Joel does not get right. I know that he is spectacularly right about at least one thing. Why not read about it in his own words?
He mistook the judge for a server, and was trying to find his security holes, to sneak in and become root. It seems he didn't find any.
I could rant a bit about how wrong (or right) Joel is about lots of topics, but that would be a little redundant.
Instead, I would like to say thank you. Thanks, Joel, for writing about your opinions and experiences, the lessons you learned, what you did wrong. Thanks for taking the time to tell us. It doesn't matter if we agree with you or not. Thanks for trying to help, you centainly help me a lot.
How did you come by a check for $2.94? I thought all his bounty checks were powers of two.
Please see the following quote, from this page:
During the months of September, October, November, and December, I will not be reading any mail about purported errors in my books, because all the master files are at Stanford in a standalone computer that will be turned off. After Y2K I'll get back to the routine of bug-fixing as usual. (Any rewards for bugs reported during my downtime will be increased by adding interest compounded from the time they were received.)
I emailed my first bug on Sept. 22, 1999. The letter from Knuth was postmarked Jan. 10, 2000. Inside the envelope, I found the following note:
24 December 1999
Dear helper,
While I was away from Stanford during the last four months of 1999, my home computer - on which I keep all the master files for my books - was shut off. Thus I had to wait to process all errata until returning home this week.
Thanks for your patience awaiting my reply. I have computed the amount of your reward by adding interest at 5%, compounded continuously from the day of your letter until 1 January 2000.
I'm writing the checks today, but Stanford will be closed next week; so my secretary will not be able to mail this letter until Y2K is with us. With luck, however, the US Postal Service will survive and will deliver your check before your patience wears too thin.
My books owe a great deal to careful readers like you. Therefore I hope you'll continue to let me know whenever you find anything wrong.
Best wishes for the year 2000 and beyond!
Cordially, Don Knuth
Of course, I was spellbound!
In the future, just after contacting with alien civilizations, we humans will be able to chat with the aliens about all the funny physics experiments we came up with, and ask them if they also carried them out. Imagine the conversations:
Human: By the way, did you try to beam neutrinos across your planet and gain some insights into the charge-parity violation? We based all our theories on the results of that revolutionary experiment.
Alien (translated): Yes, being there, done that, half an eon ago. And you got it wrong, see, this "y = i++;" is really "y = ++i". You should have abandoned C long ago.
Human: Ohhh... I see (damn!)
If the future book lends itself to self-publishing, why not?
The most successful self-publisher I know about is Edward Tufte. He has sold hundreds of thousands of copies of his three books. There is an interview in which he tells why and how he self-published.
An excerpt from that interview follows:
It turned out that all self-publishing required was a really good book designer, some money, and a large garage. For capital, I took out another mortgage on my house. This also concentrated my mind, in part because interest rates were 18% at the time. The bank officer said this was the second most unusual loan that she had ever made; first place belonged to a loan to a circus to buy an elephant!
My view on self-publishing was to go all out, to make the best and most elegant and wonderful book possible, without compromise. Otherwise, why do it? If I wanted to mess it up, I could have gone to a real publisher. And I also wanted a reasonable price so that the book would be widely accessible. It all worked out, dreamlike
Please read the paper before dismissing the theory.
In a word: physics
If physics can't compete, let's see how many people will want to generate their own energy anywhere by winding up their electronics!
And the reason that there are so many bugs in the first place is because that is the nature of software. Any piece of code, even slightly complex, will probably be buggy until you take the time to debug it.
Sorry, but you are wrong. Bugs are not the nature of software, but a symptom of the nature of human beings.
Our software is faulty because we are fallible. And that's because our software development processes mostly suck. Is your software buggy? Your process was lousy, and your own fallibility got you.
I would like to ask every coder around here to read this great article, only to learn a little about what perfect software development takes, and how difficult it is to tame our own tendency to screw things up.
Of course it is possible to write perfect software, just eliminate the coders' ability to fail. Perfect software development is very non-human.
Yes, and LI website tells me Larry M. Augustine is in the Board of Directors, from a company called 'VA Research'
Gasp! 'Nuff said, indeed.
I don't say that VA Linux people aren't honest, I am sure they are very nice. I just asked because I'm still confused about what's acceptable or not when using (or abusing) the Linux trademark, and Linus didn't mention this particular issue.
I think that the 4-character limitation in NASDAQ ticker symbols actually makes this worse than domain name squatting, because there aren't many ticker symbols that rhyme with Linux. Now, one of them is used by a company that sells hardware, congratulations to them.
The problem with 'LNUX' is that some investors will think VA Linux is the only Linux company listed on NASDAQ, others will think that Linux is a piece of hardware, others will think that Linux needs special hardware to run on, and others, who knows what they will think!
In contrast (to give some tangible examples), something like "VA Linux" or "Red Hat Linux" oviously isn't a generic term: it's a very _targeted_ term for something very specific. Those kinds of names do not detract from other peoples ability to call _their_ Linux company something else.
I'm confused. If Linus believes this, I don't know why he let VA Linux choose 'LNUX' as their NASDAQ ticker symbol. They should have chosen perhaps 'VALX', and not be too general. After all, aren't NASDAQ symbols just like domain names?
In my opinion, Red Hat did the right thing with 'RHAT'
AOL bought what remained of the battle-worn company for a pittance.
A pittance, yeah. As reported, about $4,000,000,000 (in stock, of course).
It's a pretty thought, but it doesn't work out that way in practice. We will probably win, but it won't be just because we played fair.
I acknowledge that not many people believe in fair-play right now, but I don't care, because races can't be won by everybody. Most races allow only one winner, and I believe that fair-play is a real help in many races that really matter.