Now then, on to the "proper" use of comments.
1. Write out what you are planning to do in English... 2. Make a copy and label it "documentation."
3. Go back to the original, fill in all of the logic...label it "source file."
I'm reluctant to discourage people from writing both specs and comments, but I think that advice needs to be taken with a grain of salt. One of the most common causes of error in programming is having two copies of the same thing that get out of sync over time. This "thing" can be specs vs. comments in your example, variables in a program, or cached disk blocks in a system. Maybe I'm especially sensitive to this sort of problem because this last example is pretty much my specialty (or maybe it's the other way around) but alarm bells go off for me whenever someone suggests duplicating something without specifying how the copies will be kept in sync.
IMO comments should be complementary to what's in the spec, not a copy. Explanations of how the program is written, especially those that would apply regardless of module structure or implementation language, belong in the spec. Explanations of how the code is written, that might be hard to understand except when the explanation and the code are close together, belong in comments. Putting information of either type in the place designated for the other is IMO a mistake.
Functions are named consistantly, variables use Hungarian Notation or some other standard.
I'd add that functions should be not only named but also grouped consistently. Matched pairs of functions (initialize/terminate, hold/release, get/put) should be close together so that when one is changed it's easy to go and change the other in complementary ways.
As for Hungarian notation, I disagree. I've worked on lots of code that used it, and lots that didn't, and I haven't noticed any difference in readability. There's even a possibibility when using HN that the name will not match the actual type after someone changes the code, and that can be worse than having to find the declaration. Type information belongs in declarations; names should contain information that can't be expressed as a type - usually usage.
In the context of that last statement, I should also point out that typedefs and enums should always be used to maximize the amount of information in a declaration. Some of my code uses virtual block numbers, physical block numbers, and buffer numbers, for example. These all equate to integers of the same size, but they're visibly different types with different expectations. Opaque pointers ("typedef struct foo * bar") are also very useful to define usage.
Lots of comments, clearly written and explanatory...The best comment I heard was from a friend about a former coworkers code: "It's English with some C++ thrown inbetween the comments."
Yuk. Verbose comments are a waste of time. Yes, if you have to write a paragraph to describe why a tricky piece of code works the way it does or how a complex data structure is linked together, by all means do so. However, "English with some C++ thrown in" is likely to lead to information overload. IMO, comments are like warning flags; they alert the reader to something that they might miss otherwise. I'd say 80-90% of code is usually pretty self-explanatory as long as you have the proper context from design docs and module/function header comments, and further verbosity is undesirable.
As Joel points out, code embodies the experience of the people who wrote and debugged it. The most useful comments are those that share that experience in the form of pointing out things like why seemingly-extraneous code is really necessary. My personal favorite type of comment is one that anticipates my objections and says "we tried xxx, but it didn't work because..."; that kind of comment can save hours or days of frustration.
Documentation is good. Write it.
Absolutely. I'm sometimes dismayed by the apparent drop-off in my productivity as measured by lines of code compared to the days when code was all I wrote, but I know deep down that writing the spec first is worth it, which brings me to the single most important point that I think you forgot to mention:
Fix things sooner, not later
In a lot of ways, this is like the Zeroth Law of Thermodynamics; it really underlies all of the other suggestions. Anticipating a problem or future enhancement in the design phase is cheaper than having to go back and rewrite thousands of lines. Anticipating and avoiding type confusion, or code rewritten into an inferior form due to misunderstanding, is also better than suffering the effects after the fact. Finding problems with thorough asserts or unit tests is better than finding them in the field is good. Finding problems in the field with internal integrity checks that warn you when a data structure first gets corrupted rather than when the corrupted data structure gets used is good. Always, in everything you do as a programmer, plan ahead and try to think of ways you can save yourself grief later by acting now. These "defensive" skills are the ones that set the programming elite apart from green recruits, and it's unfortunate that most people don't start developing them until they've lost a few months of their lives under the gun desperately searching through post-mortem dumps to figure out bugs that should have been caught in unit tests.
Salamander - the symbol from Farenheit 451. Symbol for flames...
The origin of my name here actually goes back a lot further than Ray Bradbury. In ancient times salamanders were noted not so much for starting fires but for resisting their effects. I chose the name because - contrary to claims of karma whoring - even when I first registered I could tell that this was a place there are plenty of flames to go around and independent thinkers will get even more than their share.
BTW, I do admit that I was wrong about plenum cable in homes. No problem. I'll even apologize for the original AC wisecrack. Good luck getting any of the other participants on either side of this stupid "conversation" to show even that much contrition for their even more absurd claims or behavior - "hate Slashdot", "astroturf", "make me sick", etc.
My point about WNight jumping to conclusions or having undue faith in the moderation system still stand, however. I've had a couple of dozen posts modded up to five in the past and I metamoderate almost every weekday, so I know damn well how frivolously mod points are often awarded. I've also been hounded by ACs after my more controversial posts enough times to have an instinctive dislike of the breed. Stick around for a while, consistently speak your own mind instead of someone else's, and see if you don't get pretty annoyed yourself at ACs or the other ovine members of the Slashdot non-community.
It is the unreasonable explanation that requires proof. If it's not BS, prove it.
Do you believe there are viable business models for open source? Better set about proving that, because right now it's seeming like a pretty irrational belief. Everyone has their "religion" whether they call it that or not. This is not to say that all beliefs are equal - e.g. creationism has neither the evidence nor the explanatory power of evolution theory - but that one should not be too obnoxious about demanding rock-solid proof before you'll accept others' beliefs as valid (let alone true) lest you find yourself without a leg to stand on when your own pet beliefs are challenged.
Yeah, I'll probably get modded down for my choice of illustrative examples. That should put the last nail in the "mod points == reasonable" idea's coffin. Hey, maybe that canard would have made an even better example.
Re:My experiences in wiring a new house
on
Wiring A New House?
·
· Score: 1, Flamebait
Here's a little advice for you. Since you obviously hate Slashdot, don't use it. It's really easy. (See.sig)
Here's a little advice for you: don't jump to conclusions. If I hated Slashdot I wouldn't be here at all; ergo, since I am here, I do not hate Slashdot. I do, however, harbor a strong dislike for the herd members such as yourself who can't distinguish an informed opinion from utter BS, let alone form such an opinion for themselves, and who drown out reasoned debate with their bleating.
an AC who said something sensible enough to get modded up
What's the correlation between saying something sensible and getting modded up, Sparky? Herd mindset again: popular, therefore good.
Re:My experiences in wiring a new house
on
Wiring A New House?
·
· Score: 1, Troll
Do Not use plenum, braided, or shielded CAT5e cable
On the contrary, do use plenum cable. Fire-safety precautions are just as important in your home as in your office and, as another poster already pointed out, plenum might well be required by local codes.
Most importantly, do not take advice from people who've already been wrong on one important point and who are not even willing to stand behind their advice. I'd take everything in the parent article with a grain of salt if I were you.
Also, with respect to data loss, the only data Freenet loses is that which is unrequested. If the author wants to ensure that unpopular data is available in Freenet then all they have to do is reinsert it.
That's just not good enough, for reasons that have already been discussed in this article and elsewhere. Reinserting data is not only horribly inefficient but also unreliable. How often do you need to reinsert? You can't know that unless you know what else is going on that will cause old copies to drop off the end of everyone's cache, so you make a pessimistic assumption and spam the network with reinsertions...and it seems to work until someone else starts doing the same things and the caches start turning over faster and IT JUST REALLY SUCKS. Freenet is useful as a data transmission method but not as a data store, and some people want a data store. Get over it.
Perhaps you should educate yourself before you expose your ignorance.
I'm on freenet-tech, Ian. I see how people respond when someone asks when Freenet will be finished. I know about the near-total restart when a lot of the original grand plans were found to be fatally flawed. I can almost predict the next one. You're the one who's ignorant, Ian - about what constitutes a useful system and how to provide it.
Yeah, it sounds like a ripoff of Freenet, except that the transmission of data is direct instead of via intermediate nodes and the anonymity/encryption which is integral to Freenet is missing, and it doesn't just drop unpopular data like Freenet. Yeah, otherwise it's just like Freenet.
Freenet is very interesting in an abstract sort of way, but certain characteristics - e.g. anonymity and most especially data loss - severely limit its usefulness in the real world. Plus, it's not done and doesn't look like it ever will be. I don't think it can be considered "truly great" unless (a) the development team is functional and (b) the result is useful. There are better examples.
Yes, XFS on Linux is relatively immature. Filesystems and operating systems interrelate in very complicated ways involving the VFS, VM, and block-device layers, and this OS-specific code is usually the most difficult part of FS development. The situation is made even worse by Linux's "VFS Layer From Mars"; there's more similarity between VFS layers on AIX and FreeBSD, for example, than between either and Linux. Because of all this, XFS on Linux is really quite a different creature than XFS on IRIX so XFS's history on IRIX essentially becomes irrelevant. Ditto for JFS on AIX vs. Linux. There is simply no journaling filesystem for Linux that has been widely enough used with stable OS interfaces for a long enough time to have that kind of confidence in it. Give it another year or so; there's no shame in waiting for sufficient real-life evidence before making ambitious claims.
Linux is as ready for the enterprise as any other offering (including those already considered to be enterprise platforms).
Wrong. It's certainly making good progress, but it's still quite deficient in several important areas.:
Support for truly large block devices, or truly large numbers of devices, still lags behind most of the commercial UNIXes.
The SCSI stack is still a mess, lacking features, robust error handling, and overall coherency. FC drivers aren't in great shape either.
The journaling filesystems available for Linux are still relatively immature.
The VM system is effectively only a couple of months old. We don't really know how it will perform on many types of systems, except that it will be *horrible* on NUMA machines.
Linux's error logging and general RAS functionality is still nothing like what's provided by the commercial UNIXes.
High-availability clustering does exist for Linux, but at a level roughly equivalent to what AIX had in '95 and most others by '98 or so.
That's far from an exhaustive list, of course. As I said, it's making good progress, and if you're comparing it to any flavor of Windows then it looks pretty good. In the real world of the enterprise, though, it's just not there yet.
'Come, come, Mr Clarke,' said the people at the Patent Office. 'We're a serious outfit, we haven't got time to waste on fantastic ideas like this.'
I seriously doubt this would have been their reaction. IMO the real stumbling block would have been this, from the General Information Concerning Patents page at USPTO:
A patent cannot be obtained upon a mere idea or suggestion. The patent is granted upon the new machine, manufacture, etc., as has been said, and not upon the idea or suggestion of the new machine. A complete description of the actual machine or other subject matter for which a patent is sought is required.
In other words, the details of implementation must have been worked out in sufficient detail to allow implementation without requiring further innovation. Usually this means that a working prototype must exist, although that's not strictly required.
ACC's idea for geosynchronous satellites, however brilliant, did not meet this standard for patentability.
Inability to use screen resolutions greater than (or less than) 1024x768...
Video Mode=1792 / Video Mode=1600 / Video Mode=1280 / Video Mode=1152
Cool, thanks!
It would be nice to be able to mark units obsolete, like in SMAC.
In a similar vein, it would be nice if they'd document the unit-upgrade paths and costs. Maybe they're mentioned somewhere, but not where they should be.
There's supposed to be a patch before Christmas. Not that that's an excuse to ship a shoddy game.
I agree. It's good to hear there'll be a patch soon, though, because there are many aspects of the interface that are just too bogus for a shipping product.
I'll probaly get flamed here, but I prefer the freeciv interface. The civ3 GUI is "pretty", but civ style games are all about information.
The interface in Civ3 is notably bad, so I doubt you'll find many people disagreeing with you. Some of my favorite gripes:
Inability to use screen resolutions greater than (or less than) 1024x768, compounded by the availability of only two zoom levels.
General visual sloppiness, making it hard to distinguish units (e.g. workers/spearmen, riflemen/infantry) or determine where cultural-influence borders are on some terrain.
Lack of facilities to get information in the middle of a decision process, e.g. on an improvement/wonder/unit when choosing what to build from the city-management screen.
Production menus that include dozens of items in a single non-hierarchical list, which is bad enough but gets worse when obsolete units (e.g. archers in the modern age) are included.
Way too many poorly-documented command keys, especially for workers.
Generally, way too many holes in the documentation - formulae (e.g. corruption, resistance) not specified, unit capabilities (e.g. precision bombing) never mentioned, visual items (e.g. red/yellow/white for city growth) and preferences (e.g. "city governor is default") never mentioned.
A crappy AI, for which the game compensates by giving AI players huge production bonuses and you huge corruption.
I still love the game, I'm still hooked, there are some things - e.g. culture/trade/diplomacy - that have improved, but...but, overall, I think Civ2 might still be a better game. I haven't tried FreeCiv but, to the extent that it seems to resemble Civ2 quite closely, it seems like it might well be a better game than Civ3 too.
When are people going to learn that it's not art that makes the game?
Did anybody say that it was art that made the game? No. Hell, I've been playing Slime Volleyball recently. It has some of the lamest, most childish graphics I've ever seen, but it also has very engaging game play. Nonetheless, better graphics in both SV and FC would be nice, and their implementation needn't affect the game play one bit.
One of our contributors in JBoss landed a high profile job, not because he was wasting time in cubeland but because he used his sinking company time to work on JBoss while at work... ...a Open Source track record shows you LOVE coding, you do it for free
But the guy in your example didn't do it for free. He stole time and resources from a prior employer to "do his own thing" and for that reason I would never hire him. If people want to work on open source on their own time fine, in many ways I agree that work on open-source software is a better indication of someone's true capabilities than what they do in a constrained corporate environment, but that's not what we're talking about here. Once a thief, always a thief. If someone wants to have their voice heard in determining what work we do that's fine, but I can't afford to have people working for me who will get bored and start working on personal projects behind my back instead of working toward our supposedly-shared goals.
yes many of them are actually stealing time on their job but many are also professionals taking the jump
If so, then good for them and good luck to all of you. However, I'm sure you know that one anecdote doesn't prove much of anything. I've dealt with hundreds of open-source developers, and I can only think of one or two who don't fall into one of the three categories I mentioned. Even those few are questionable cases; they make enough money from consulting to have a lot of free time that they then spend on open-source development, but I'm not sure if that qualifies as "making a living from open-source software".
I seriously think that one of the problems here is that you all assume that you must be working for some stupid corporation to make a living.
I for one don't make that assumption. Several of my friends have done quite well over the years on the consulting/contracting circuit, and I know I could join them any time I wished. Yes, even now, with the high-tech economy sucking wind. However, consulting/contracting != open source. Maybe I could make it a term of my contracts that any code I produced be open source, and still make a living, but I don't think that would be the usual case. Freelancers don't usually have that kind of leverage; all but the creme de la creme usually take whatever they can get.
Actually you can make a living too in open source it is not difficult.
I could make a living as a consultant, on open or closed source, but it's not clear what that has to do with "making a living in open source". Let's wait a little while and see if JBoss's classic-dot-com business model really holds up over time or whether those T-shirts and mugs you sell on your website (pets.com anyone?) end up as dot-bomb souvenirs.
The item I'm most likely to buy personally would be the Steri-pen, or maybe the mashed-potato machine. I already own a natural-spectrum lamp, have done so for well over a year, as have thousands of other people, so I'm not sure how innovative I'd call it.
The gyroplane looks really cool too. Why isn't the military all over this concept, instead of pouring money into the black hole that is the Osprey project?
But the winner, for me, is the food cooling system. It's ultra-low-tech, but it's likely to make the biggest difference in parts of the world where food storage is a very real problem with very real human and economic effects.
Historically, I think open-source software has been written by two groups of people: college students, people working on their own time, and professional programmers stealing time and resources from their employers. The first two groups are pretty constant; good times or bad, the numbers will be almost the same. During the dot-com boom, a lot of people in the last group started fleecing investors instead of employers, but that's coming to an end now.
Nowadays you're going to see two dnamics at work. On the one hand a lot of those who once hoped to become dot-com millionaires are being laid off. They'll go back to what they did before, whatever that was, and they'll sneak in what time they can doing open-source projects. At the same time, employers are going to be a lot more focused on the bottom line, cutting deadwood and leaving schedules the same. This will create more schedule pressure, and an incentive not to be the one who appears "unproductive" when the next layoff hits. Between these two factors, I think we'll see a net decrease in the amount of time devoted to open source by people in this group. That shortfall will not be made up by the people who remain unemployed for long periods and figure they might as well use the "enforced downtime" to work on their open-source projects, because those people are likely to be the bottom of the barrel. If they were that good, they wouldn't be remaining unemployed for long even in tough economic times.
In short, lean times are bad for open source. We can expect a slow-down in the pace of open-source development for as long as the bad times last.
One of the issues here is the definition of 'battery life.
It would be nice if they'd give a "standby" time number like they do for celphones. Eight hours of continuous use might be adequate, but I wonder how well it compares to Palm devices in non-continuous use? How thoroughly does it sleep? Palm stuff is very carefully designed - both hardware and software - so that battery use is reduced by 99% when the device is not actually in use, which is why a single set of batteries can give you weeks of occasional use. How deeply does the StrongArm sleep in the Zaurus? How about all that RAM? How well does Linux take to being comatose like that? Even if the batteries are good enough for eight hours continuously, it's a pain if I'm losing significant capacity even when it's in my pocket so that I have to plug it in every day to keep it at that capacity.
I believe most people would have it plugged in the cradle in the office to connect to their PC (and recharging). They would then take take it to a meeting and afterwards put it back in the cradle.
I already have a device that I can leave plugged in at my desk and then take to meetings. It's called a laptop, and it's a hell of a lot better suited to that role than a PDA is. The whole point of a PDA is to go beyond where you'd take a laptop, which very often means into situations where you don't have an electrical outlet handy.
I can't think of a lot of cases where it would be used for 8 hours solid - can anyone else ?
That's an easy one. I'd like to take my PDA with me on a two- or three-day business trip, without having to pack my cradle as well. I have a Visor backup module for exactly that reason. While I'm on planes (six hours each way, across the country or across the Atlantic) I might very well use it more than two thirds of the time for a combination of jotting down notes and playing games to kill time. I'll certainly be using it when I'm at my destination to store directions and new contact information, take notes, etc. Some of that time I'll be using the backlight. Altogether I'd say 15-20 hours of continuous use between visits to the cradle is not out of the question.
According to the LinuxDevices link, the battery life is from 2 hours (backlight on) to eight hours (backlight off). Am I missing something? What good is a PDA that can't even go a full workday without suckling from the electrical teat? I'd gladly accept a smaller monochrome screen, a slower processor, and less memory if that meant a battery life that was at least a couple of days. As a point of reference, my Visor (which meets the above description) goes for several weeks on a pair of rechargeable NiMH AAA batteries. No matter how cool the technology in the Zaurus might be, it doesn't seem all that useful with such a short battery life.
Anyone who's thinking of buying something like this should stop to consider whether it's worth spending $400 for a few days of "gee whiz" before the new toy ends up in the bottom of the junk drawer with all of the other "seemed like a good idea at the time" gadgets. There are much more cost-effective forms of entertainment.
Slashdot Mirror
Reuel.
I'm reluctant to discourage people from writing both specs and comments, but I think that advice needs to be taken with a grain of salt. One of the most common causes of error in programming is having two copies of the same thing that get out of sync over time. This "thing" can be specs vs. comments in your example, variables in a program, or cached disk blocks in a system. Maybe I'm especially sensitive to this sort of problem because this last example is pretty much my specialty (or maybe it's the other way around) but alarm bells go off for me whenever someone suggests duplicating something without specifying how the copies will be kept in sync.
IMO comments should be complementary to what's in the spec, not a copy. Explanations of how the program is written, especially those that would apply regardless of module structure or implementation language, belong in the spec. Explanations of how the code is written, that might be hard to understand except when the explanation and the code are close together, belong in comments. Putting information of either type in the place designated for the other is IMO a mistake.
I'd add that functions should be not only named but also grouped consistently. Matched pairs of functions (initialize/terminate, hold/release, get/put) should be close together so that when one is changed it's easy to go and change the other in complementary ways.
As for Hungarian notation, I disagree. I've worked on lots of code that used it, and lots that didn't, and I haven't noticed any difference in readability. There's even a possibibility when using HN that the name will not match the actual type after someone changes the code, and that can be worse than having to find the declaration. Type information belongs in declarations; names should contain information that can't be expressed as a type - usually usage.
In the context of that last statement, I should also point out that typedefs and enums should always be used to maximize the amount of information in a declaration. Some of my code uses virtual block numbers, physical block numbers, and buffer numbers, for example. These all equate to integers of the same size, but they're visibly different types with different expectations. Opaque pointers ("typedef struct foo * bar") are also very useful to define usage.
Yuk. Verbose comments are a waste of time. Yes, if you have to write a paragraph to describe why a tricky piece of code works the way it does or how a complex data structure is linked together, by all means do so. However, "English with some C++ thrown in" is likely to lead to information overload. IMO, comments are like warning flags; they alert the reader to something that they might miss otherwise. I'd say 80-90% of code is usually pretty self-explanatory as long as you have the proper context from design docs and module/function header comments, and further verbosity is undesirable.
As Joel points out, code embodies the experience of the people who wrote and debugged it. The most useful comments are those that share that experience in the form of pointing out things like why seemingly-extraneous code is really necessary. My personal favorite type of comment is one that anticipates my objections and says "we tried xxx, but it didn't work because..."; that kind of comment can save hours or days of frustration.
Absolutely. I'm sometimes dismayed by the apparent drop-off in my productivity as measured by lines of code compared to the days when code was all I wrote, but I know deep down that writing the spec first is worth it, which brings me to the single most important point that I think you forgot to mention:
Fix things sooner, not later
In a lot of ways, this is like the Zeroth Law of Thermodynamics; it really underlies all of the other suggestions. Anticipating a problem or future enhancement in the design phase is cheaper than having to go back and rewrite thousands of lines. Anticipating and avoiding type confusion, or code rewritten into an inferior form due to misunderstanding, is also better than suffering the effects after the fact. Finding problems with thorough asserts or unit tests is better than finding them in the field is good. Finding problems in the field with internal integrity checks that warn you when a data structure first gets corrupted rather than when the corrupted data structure gets used is good. Always, in everything you do as a programmer, plan ahead and try to think of ways you can save yourself grief later by acting now. These "defensive" skills are the ones that set the programming elite apart from green recruits, and it's unfortunate that most people don't start developing them until they've lost a few months of their lives under the gun desperately searching through post-mortem dumps to figure out bugs that should have been caught in unit tests.
The origin of my name here actually goes back a lot further than Ray Bradbury. In ancient times salamanders were noted not so much for starting fires but for resisting their effects. I chose the name because - contrary to claims of karma whoring - even when I first registered I could tell that this was a place there are plenty of flames to go around and independent thinkers will get even more than their share.
BTW, I do admit that I was wrong about plenum cable in homes. No problem. I'll even apologize for the original AC wisecrack. Good luck getting any of the other participants on either side of this stupid "conversation" to show even that much contrition for their even more absurd claims or behavior - "hate Slashdot", "astroturf", "make me sick", etc.
My point about WNight jumping to conclusions or having undue faith in the moderation system still stand, however. I've had a couple of dozen posts modded up to five in the past and I metamoderate almost every weekday, so I know damn well how frivolously mod points are often awarded. I've also been hounded by ACs after my more controversial posts enough times to have an instinctive dislike of the breed. Stick around for a while, consistently speak your own mind instead of someone else's, and see if you don't get pretty annoyed yourself at ACs or the other ovine members of the Slashdot non-community.
Do you believe there are viable business models for open source? Better set about proving that, because right now it's seeming like a pretty irrational belief. Everyone has their "religion" whether they call it that or not. This is not to say that all beliefs are equal - e.g. creationism has neither the evidence nor the explanatory power of evolution theory - but that one should not be too obnoxious about demanding rock-solid proof before you'll accept others' beliefs as valid (let alone true) lest you find yourself without a leg to stand on when your own pet beliefs are challenged.
Yeah, I'll probably get modded down for my choice of illustrative examples. That should put the last nail in the "mod points == reasonable" idea's coffin. Hey, maybe that canard would have made an even better example.
Here's a little advice for you: don't jump to conclusions. If I hated Slashdot I wouldn't be here at all; ergo, since I am here, I do not hate Slashdot. I do, however, harbor a strong dislike for the herd members such as yourself who can't distinguish an informed opinion from utter BS, let alone form such an opinion for themselves, and who drown out reasoned debate with their bleating.
What's the correlation between saying something sensible and getting modded up, Sparky? Herd mindset again: popular, therefore good.
On the contrary, do use plenum cable. Fire-safety precautions are just as important in your home as in your office and, as another poster already pointed out, plenum might well be required by local codes.
Most importantly, do not take advice from people who've already been wrong on one important point and who are not even willing to stand behind their advice. I'd take everything in the parent article with a grain of salt if I were you.
That's just not good enough, for reasons that have already been discussed in this article and elsewhere. Reinserting data is not only horribly inefficient but also unreliable. How often do you need to reinsert? You can't know that unless you know what else is going on that will cause old copies to drop off the end of everyone's cache, so you make a pessimistic assumption and spam the network with reinsertions...and it seems to work until someone else starts doing the same things and the caches start turning over faster and IT JUST REALLY SUCKS. Freenet is useful as a data transmission method but not as a data store, and some people want a data store. Get over it.
I'm on freenet-tech, Ian. I see how people respond when someone asks when Freenet will be finished. I know about the near-total restart when a lot of the original grand plans were found to be fatally flawed. I can almost predict the next one. You're the one who's ignorant, Ian - about what constitutes a useful system and how to provide it.
Yeah, it sounds like a ripoff of Freenet, except that the transmission of data is direct instead of via intermediate nodes and the anonymity/encryption which is integral to Freenet is missing, and it doesn't just drop unpopular data like Freenet. Yeah, otherwise it's just like Freenet.
Freenet is very interesting in an abstract sort of way, but certain characteristics - e.g. anonymity and most especially data loss - severely limit its usefulness in the real world. Plus, it's not done and doesn't look like it ever will be. I don't think it can be considered "truly great" unless (a) the development team is functional and (b) the result is useful. There are better examples.
Yes, XFS on Linux is relatively immature. Filesystems and operating systems interrelate in very complicated ways involving the VFS, VM, and block-device layers, and this OS-specific code is usually the most difficult part of FS development. The situation is made even worse by Linux's "VFS Layer From Mars"; there's more similarity between VFS layers on AIX and FreeBSD, for example, than between either and Linux. Because of all this, XFS on Linux is really quite a different creature than XFS on IRIX so XFS's history on IRIX essentially becomes irrelevant. Ditto for JFS on AIX vs. Linux. There is simply no journaling filesystem for Linux that has been widely enough used with stable OS interfaces for a long enough time to have that kind of confidence in it. Give it another year or so; there's no shame in waiting for sufficient real-life evidence before making ambitious claims.
Wrong. It's certainly making good progress, but it's still quite deficient in several important areas.:
That's far from an exhaustive list, of course. As I said, it's making good progress, and if you're comparing it to any flavor of Windows then it looks pretty good. In the real world of the enterprise, though, it's just not there yet.
I seriously doubt this would have been their reaction. IMO the real stumbling block would have been this, from the General Information Concerning Patents page at USPTO:
In other words, the details of implementation must have been worked out in sufficient detail to allow implementation without requiring further innovation. Usually this means that a working prototype must exist, although that's not strictly required.
ACC's idea for geosynchronous satellites, however brilliant, did not meet this standard for patentability.
Cool, thanks!
In a similar vein, it would be nice if they'd document the unit-upgrade paths and costs. Maybe they're mentioned somewhere, but not where they should be.
I agree. It's good to hear there'll be a patch soon, though, because there are many aspects of the interface that are just too bogus for a shipping product.
The interface in Civ3 is notably bad, so I doubt you'll find many people disagreeing with you. Some of my favorite gripes:
I still love the game, I'm still hooked, there are some things - e.g. culture/trade/diplomacy - that have improved, but...but, overall, I think Civ2 might still be a better game. I haven't tried FreeCiv but, to the extent that it seems to resemble Civ2 quite closely, it seems like it might well be a better game than Civ3 too.
Did anybody say that it was art that made the game? No. Hell, I've been playing Slime Volleyball recently. It has some of the lamest, most childish graphics I've ever seen, but it also has very engaging game play. Nonetheless, better graphics in both SV and FC would be nice, and their implementation needn't affect the game play one bit.
...ask for a world map, two technologies, and half the treasury, then gone to war anyway.
Yeah, I guess I've been playing too much. ;-)
But the guy in your example didn't do it for free. He stole time and resources from a prior employer to "do his own thing" and for that reason I would never hire him. If people want to work on open source on their own time fine, in many ways I agree that work on open-source software is a better indication of someone's true capabilities than what they do in a constrained corporate environment, but that's not what we're talking about here. Once a thief, always a thief. If someone wants to have their voice heard in determining what work we do that's fine, but I can't afford to have people working for me who will get bored and start working on personal projects behind my back instead of working toward our supposedly-shared goals.
If so, then good for them and good luck to all of you. However, I'm sure you know that one anecdote doesn't prove much of anything. I've dealt with hundreds of open-source developers, and I can only think of one or two who don't fall into one of the three categories I mentioned. Even those few are questionable cases; they make enough money from consulting to have a lot of free time that they then spend on open-source development, but I'm not sure if that qualifies as "making a living from open-source software".
I for one don't make that assumption. Several of my friends have done quite well over the years on the consulting/contracting circuit, and I know I could join them any time I wished. Yes, even now, with the high-tech economy sucking wind. However, consulting/contracting != open source. Maybe I could make it a term of my contracts that any code I produced be open source, and still make a living, but I don't think that would be the usual case. Freelancers don't usually have that kind of leverage; all but the creme de la creme usually take whatever they can get.
I could make a living as a consultant, on open or closed source, but it's not clear what that has to do with "making a living in open source". Let's wait a little while and see if JBoss's classic-dot-com business model really holds up over time or whether those T-shirts and mugs you sell on your website (pets.com anyone?) end up as dot-bomb souvenirs.
The item I'm most likely to buy personally would be the Steri-pen, or maybe the mashed-potato machine. I already own a natural-spectrum lamp, have done so for well over a year, as have thousands of other people, so I'm not sure how innovative I'd call it.
The gyroplane looks really cool too. Why isn't the military all over this concept, instead of pouring money into the black hole that is the Osprey project?
But the winner, for me, is the food cooling system. It's ultra-low-tech, but it's likely to make the biggest difference in parts of the world where food storage is a very real problem with very real human and economic effects.
Oops, that's one of the dangers of overediting. Obviously there are three groups, but I forgot to change "two groups" from an earlier draft.
Historically, I think open-source software has been written by two groups of people: college students, people working on their own time, and professional programmers stealing time and resources from their employers. The first two groups are pretty constant; good times or bad, the numbers will be almost the same. During the dot-com boom, a lot of people in the last group started fleecing investors instead of employers, but that's coming to an end now.
Nowadays you're going to see two dnamics at work. On the one hand a lot of those who once hoped to become dot-com millionaires are being laid off. They'll go back to what they did before, whatever that was, and they'll sneak in what time they can doing open-source projects. At the same time, employers are going to be a lot more focused on the bottom line, cutting deadwood and leaving schedules the same. This will create more schedule pressure, and an incentive not to be the one who appears "unproductive" when the next layoff hits. Between these two factors, I think we'll see a net decrease in the amount of time devoted to open source by people in this group. That shortfall will not be made up by the people who remain unemployed for long periods and figure they might as well use the "enforced downtime" to work on their open-source projects, because those people are likely to be the bottom of the barrel. If they were that good, they wouldn't be remaining unemployed for long even in tough economic times.
In short, lean times are bad for open source. We can expect a slow-down in the pace of open-source development for as long as the bad times last.
Not likely. Implementing memory this way is not at all the same as implementing real logic.
It would be nice if they'd give a "standby" time number like they do for celphones. Eight hours of continuous use might be adequate, but I wonder how well it compares to Palm devices in non-continuous use? How thoroughly does it sleep? Palm stuff is very carefully designed - both hardware and software - so that battery use is reduced by 99% when the device is not actually in use, which is why a single set of batteries can give you weeks of occasional use. How deeply does the StrongArm sleep in the Zaurus? How about all that RAM? How well does Linux take to being comatose like that? Even if the batteries are good enough for eight hours continuously, it's a pain if I'm losing significant capacity even when it's in my pocket so that I have to plug it in every day to keep it at that capacity.
I already have a device that I can leave plugged in at my desk and then take to meetings. It's called a laptop, and it's a hell of a lot better suited to that role than a PDA is. The whole point of a PDA is to go beyond where you'd take a laptop, which very often means into situations where you don't have an electrical outlet handy.
That's an easy one. I'd like to take my PDA with me on a two- or three-day business trip, without having to pack my cradle as well. I have a Visor backup module for exactly that reason. While I'm on planes (six hours each way, across the country or across the Atlantic) I might very well use it more than two thirds of the time for a combination of jotting down notes and playing games to kill time. I'll certainly be using it when I'm at my destination to store directions and new contact information, take notes, etc. Some of that time I'll be using the backlight. Altogether I'd say 15-20 hours of continuous use between visits to the cradle is not out of the question.
According to the LinuxDevices link, the battery life is from 2 hours (backlight on) to eight hours (backlight off). Am I missing something? What good is a PDA that can't even go a full workday without suckling from the electrical teat? I'd gladly accept a smaller monochrome screen, a slower processor, and less memory if that meant a battery life that was at least a couple of days. As a point of reference, my Visor (which meets the above description) goes for several weeks on a pair of rechargeable NiMH AAA batteries. No matter how cool the technology in the Zaurus might be, it doesn't seem all that useful with such a short battery life.
Anyone who's thinking of buying something like this should stop to consider whether it's worth spending $400 for a few days of "gee whiz" before the new toy ends up in the bottom of the junk drawer with all of the other "seemed like a good idea at the time" gadgets. There are much more cost-effective forms of entertainment.