The question I keep hitting is how do you create these documents in the first place? The XML "editors" out there are badly inadequate for writing documentation. What you need is something that will let you write with no more effort than a text editor, and then go back and select a bunch of text and ctrl-c and voila, you have a comment, or voila, you have a section title. HTML editors such as Mozilla's have the right idea; unfortunately there's logically no way to write in HTML and convert it to XML.
Clearly having the document stored as XML is superior because you can convert it to whatever you want, and the tags represent the document's meaning rather than its appearance. But producing the document using raw tags is not friendly; it discourages documenters.
If enough people attack the elections, it won't matter if some of them are just trying to find exploits to keep secret and hoard. Any security defect that's reported by an honest person immediately neutralizes the fact that a dishonest person found the same thing and kept it a secret, because it will be fixed once it's reported. So as long as more people are reporting bugs than are hoarding, this has a net benefit.
The problem is, if the system is poorly designed and has enough defects, inevitably some will slip through the cracks and get caught only by blackhats. So, while this please-hack-me strategy has benefits, it is not, by itself, enough to prove the system.
Cringely goes on to suggest that all connections be traceable - well, that's fine, except that it doesn't solve the problem of people launching viruses from public terminals, or obtaining free trial dialup accounts using fictitious information.
This somewhat misses the point of traceable TCP. It doesn't matter whether we catch the bad guy, what matters is that we can stop the flow of traffic to our overloaded site. Untraceable traffic cannot be effectively firewalled against.
Question: Some older programmers do quite well in the field. So if an older programmer is having trouble finding programming work, isn't it his/her own fault for not keeping up with changes in the technology?
No. Employers are not willing to hire a veteran programmer who has taken a course in a new software skill. Employers insist on actual work experience in that skill.
If an older programmer is lucky enough that the present employer will allow him/her to work on a project which uses a new skill, then he/she can then stay alive in the field. Or, in some instances, if there is a very new programming language X which very few programmers know, a programmer who knows another language Y can try to find another employer who needs Y and is willing to let him/her learn X on the job. But there is only a narrow window of time in which this is possible.
The authors brush over the fact that experienced "older" programmers can and often do suggest projects to their employers that need doing. Someone who actually has design skills and has written code for a project should know what needs to be done better than their management, and therefore, they are in a perfect position to say, "Hey, look at my project, we can add feature X with XML, and we can improve our processes by writing a build system in python..."
You can use this to your advantage. If you're one of those "older" programmers, actively look for projects where you could effectively apply a new technology skillset, then learn the skills yourself and lay out a design to your manager. They love that proactive shit, and you get to put the skill on your resume and say you have experience in it to boot.
Consider the two things that increase (for example) a web site's bandwidth requirements:
The amount of data the site itself pushes out to its users. This is directly under control of the site administrator. Keep your site light, and you don't have to worry about pushing huge amounts of data out.
The number of requests that come in. This is indirectly under your control (if your site sucks, there won't be many requests, no matter how many people out there have ethernet). But more importantly, this increases as function of the number of people on the net, and not as a function of how much capacity those users have. It takes the same amount of bandwidth to send an HTTP request on ethernet as it does on 28.8.
All of which points to the conclusion that ethernet for your average user isn't going to hammer the infrastructure too badly. Some upgrades will obviously be required, but demand isn't going to just explode to eat up the new supply.
A lot of people are posting comments to the effect of "micropayments are broken because it takes more too much work/requires you to give out too much information to work."
His first strip agrees with you. He's asking someone to set up a system where you enter information once in a secure form and reuse that information anywhere you want to send a payment. Then you click a button on the website to pay him, no matter where that website is, and ten cents comes out. (I would add the condition that you can cancel the bill within a certain amount of time to protect against being tricked into paying money.)
LAME used to be "Lame Ain't an MP3 Encoder" for precisely the reason you mentioned.
It's been more than half a year since that was true. LAME included a completely open, patent-free, license-free codec. While we're at it, it's content-protection free too, because you can rip/encode your own CDs.
mozilla -turbo loads FASTER than IE5. If you have anything in your "links" toolbar it is SIGNIFICANTLY faster. They're calling it "near-instaneous" -- and they mean it.
Forgot to mention: Where to get the rubber. For some reason, windshield wiper vacuum tubes work very well for this purpose. They're fairly rigid so they're easy to work with, and you can get a lifetime supply (if all you're using it for is to cut up and wedge against electronic stuff) for about $5. Any auto parts store should have it. Wash it off and carefully dry it before you start cutting it.
Quiet fans of all types are nice (quietpc.com makes the only useful ones I've found so far), but here's something most people don't think of:
Wedge rubber against everything that can move. Adapter cards, hard drives, CD drives, mounted fans (not the CPU fan though). Not only will this eliminate vibration and the resultant noise, but it will probably prolong the life of most of these components. Hardware doesn't like to vibrate.:-)
The Dec Athlon (Ubergeeks should think "mmm Dec Alpha" and buy these by the dozen)
The Bi Athlon (in addition to being a familiar, if stupid, Olympic event, this name has sexual connotations and should slightly benefit from men who want a faster proc for pr0n)
The Athlone Ranger (OK, this one's a bit of a stretch)
Athlon as You're Happy, That's All that Matters (may appeal to moms)
--
Don't spend your time putting in place a version control system an idiot can use. First of all:
1) An idiot won't be able to use it properly
2) Having the technology available will only make them seem (and probably feel) stupider
First of all Word and Excel aren't that easy to learn. You can type up and save a document no problem, but learning how to do precise formatting tasks is something that takes good doc people a long time to learn how to do properly. Furthermore, doc people have to understand the thing they're documenting, which is not that much easier than writing the code in the first place, for lots of projects. Thus it's a fallacy that doc people aren't technical enough to learn good version control.
Secondly, CVS is pretty easy to learn. 99% of working with CVS is two commands: cvs update and cvs commit. Even assuming you don't go with one of the many adequate-to-kickass gui clients for CVS (my fave: TkCVS, maybe even in Windows), your learning curve for what most of the doc people have to know is pretty low. You can send 5% of the team to a class or buy them a book, there are ALWAYS people who want to know just a little bit more about the system they work with, and those people can be the gurus for the rest, who really just want to write doc.
Finally, if you try to implement version control without SOME education about what's going on behind the scenes, you will have lots of minor tragedies. Version control isn't perfect, and you do not want people to think that it is, or they will lose even more of their work when it's not. You want them to know things like: If it's not checked in, it doesn't really exist. Always do diffs see you can see what changes are actually going in when you merge a new version. Let your teammate know when you have to work on a document they already have checked out, or you'll clobber each others' changes.
These kinds of things are obviously harder to learn than the mechanics of actually using the version control system. They have to be, or the coders I work with wouldn't make these mistakes so frequently. Since you have to spend some resources giving your doc department this kind of education anyway, you might as well spend some time teaching them how to use a good doc system as well. CVS is truly one of the best. --
Slashdot Mirror
Clearly having the document stored as XML is superior because you can convert it to whatever you want, and the tags represent the document's meaning rather than its appearance. But producing the document using raw tags is not friendly; it discourages documenters.
What editor do you use?
If enough people attack the elections, it won't matter if some of them are just trying to find exploits to keep secret and hoard. Any security defect that's reported by an honest person immediately neutralizes the fact that a dishonest person found the same thing and kept it a secret, because it will be fixed once it's reported. So as long as more people are reporting bugs than are hoarding, this has a net benefit. The problem is, if the system is poorly designed and has enough defects, inevitably some will slip through the cracks and get caught only by blackhats. So, while this please-hack-me strategy has benefits, it is not, by itself, enough to prove the system.
are still alive. I saw a 10-pack for sale at Radio Shack the other day. Seriously considered buying some as a novelty gift.
actually, 276 counting the parent, this one, and one I posted yesterday which wasn't in the mirror site's database yet.
I've posted 273 comments on slashdot. That's humbling. So why can I only see the last 24?
banjo.slsahdot.org
I need a typosquatter keeping track of my typos! Please don't post this until banjo.slsahdot.org is up.
This somewhat misses the point of traceable TCP. It doesn't matter whether we catch the bad guy, what matters is that we can stop the flow of traffic to our overloaded site. Untraceable traffic cannot be effectively firewalled against.
Every copy of Windows I've ever installed was pirated, so they don't have my address. Phew!
____________________
You can use this to your advantage. If you're one of those "older" programmers, actively look for projects where you could effectively apply a new technology skillset, then learn the skills yourself and lay out a design to your manager. They love that proactive shit, and you get to put the skill on your resume and say you have experience in it to boot.
____________________
____________________
____________________
This rally brought to you by Pepsi, official caffeinated beverage of righteous coders everywhere.
____________________
Wish I had pts for ya :-)
____________________
Kind of like the fabled dodo.
____________________
All of which points to the conclusion that ethernet for your average user isn't going to hammer the infrastructure too badly. Some upgrades will obviously be required, but demand isn't going to just explode to eat up the new supply.
____________________
Tickle, oh yes, tickle me in my private place. *hehehehe*
__
Mmm, I love the smell of a dead Democrat in the morning.
__
You went down like Princess Di.
__
Winners don't use drugs, scumbag, and caffeine is a drug, so stop drinking that coffee and you might play better, or something.
__
I'm sorry.
__
You're such a pussy I just might fuck you.
And BTW, no fair going to these guys for help on how to insult Duke Nukem...err, help Duke Nukem insult others..
____________________
A lot of people are posting comments to the effect of "micropayments are broken because it takes more too much work/requires you to give out too much information to work." His first strip agrees with you. He's asking someone to set up a system where you enter information once in a secure form and reuse that information anywhere you want to send a payment. Then you click a button on the website to pay him, no matter where that website is, and ten cents comes out. (I would add the condition that you can cancel the bill within a certain amount of time to protect against being tricked into paying money.)
____________________
LAME used to be "Lame Ain't an MP3 Encoder" for precisely the reason you mentioned. It's been more than half a year since that was true. LAME included a completely open, patent-free, license-free codec. While we're at it, it's content-protection free too, because you can rip/encode your own CDs.
____________________
Worldwide programmer shortage? Woooohooooooooooooo!
____________________
mozilla -turbo loads FASTER than IE5. If you have anything in your "links" toolbar it is SIGNIFICANTLY faster. They're calling it "near-instaneous" -- and they mean it.
____________________
Forgot to mention: Where to get the rubber. For some reason, windshield wiper vacuum tubes work very well for this purpose. They're fairly rigid so they're easy to work with, and you can get a lifetime supply (if all you're using it for is to cut up and wedge against electronic stuff) for about $5. Any auto parts store should have it. Wash it off and carefully dry it before you start cutting it.
____________________
Wedge rubber against everything that can move. Adapter cards, hard drives, CD drives, mounted fans (not the CPU fan though). Not only will this eliminate vibration and the resultant noise, but it will probably prolong the life of most of these components. Hardware doesn't like to vibrate. :-)
____________________
(From ChangeLog:) 560. Resync with DRI CVS trunk (VA Linux Systems).
____________________
The Bi Athlon (in addition to being a familiar, if stupid, Olympic event, this name has sexual connotations and should slightly benefit from men who want a faster proc for pr0n)
The Athlone Ranger (OK, this one's a bit of a stretch)
Athlon as You're Happy, That's All that Matters (may appeal to moms)
--
1) An idiot won't be able to use it properly
2) Having the technology available will only make them seem (and probably feel) stupider
First of all Word and Excel aren't that easy to learn. You can type up and save a document no problem, but learning how to do precise formatting tasks is something that takes good doc people a long time to learn how to do properly. Furthermore, doc people have to understand the thing they're documenting, which is not that much easier than writing the code in the first place, for lots of projects. Thus it's a fallacy that doc people aren't technical enough to learn good version control.
Secondly, CVS is pretty easy to learn. 99% of working with CVS is two commands: cvs update and cvs commit. Even assuming you don't go with one of the many adequate-to-kickass gui clients for CVS (my fave: TkCVS, maybe even in Windows), your learning curve for what most of the doc people have to know is pretty low. You can send 5% of the team to a class or buy them a book, there are ALWAYS people who want to know just a little bit more about the system they work with, and those people can be the gurus for the rest, who really just want to write doc.
Finally, if you try to implement version control without SOME education about what's going on behind the scenes, you will have lots of minor tragedies. Version control isn't perfect, and you do not want people to think that it is, or they will lose even more of their work when it's not. You want them to know things like: If it's not checked in, it doesn't really exist. Always do diffs see you can see what changes are actually going in when you merge a new version. Let your teammate know when you have to work on a document they already have checked out, or you'll clobber each others' changes.
These kinds of things are obviously harder to learn than the mechanics of actually using the version control system. They have to be, or the coders I work with wouldn't make these mistakes so frequently. Since you have to spend some resources giving your doc department this kind of education anyway, you might as well spend some time teaching them how to use a good doc system as well. CVS is truly one of the best.
--