Slashdot Mirror

Sanbukid, your company already has programmers on staff, right? Then put this home-built package into OpenSource ASAP!

Your in-house guys are already going to be spending time debugging, so it's not like your company has anything to loose. If it's good, you get free testers every time someone decides to implement the system, providing feedback and making your own product better.

Eric S. Raymond mentions in his Homesteading the Noosphere, there is no value lost to your company, only benefit to be gained.

Bob-

there is no relationship between the symbolic glyphs C, A and T and the sound one physically makes when saying 'cat'

That's because the Latin alphabet, frankly, sucks. The Hangul alphabet, used to write the Korean language, and the Tengwar alphabet, used to write the Quenya and Sindarin languages, were designed to have much more correlation between the phonetics of a sound (voiced/voiceless, stop/fricative/nasal, front/back, etc.) and the shape of the associated glyph.

You can bet that with the marketing behind the LotR movie, there will be a movement to change English over to Tengwar letters. It's already happening with the Lojban language.

As far as i know, the first documented Easter Egg type occurrence was in the text adventure ADVENT, with the magic word xyzzy.

This magic word easter egg has been mimicked faithfully ever since.

I recall the first game i ever wrote. i was twelve years old and programmed it with a friend in GW-BASIC. It was a text adventure and at one point you had to use a payphone and dial a telephone number which you had discovered earlier in the game. My friend and I made it so that if you instead entered either of our telephone numbers you would suddenly have all of the items in the game. The easter egg is a tradition which may have been born independently from many minds... it's part of the desire to always know more than everyone else, particularily about thing that YOU made.

The sort of person who routinely uses phrases like `incompletely socialized' usually thinks hackers are. Hackers regard such people with contempt when they notice them at all.

Oh damn... this thread is now officially over!

That said, there are many excellent books about specific area's of computing and computation science in general. They would probably bore your father, or most people who arn't interested, to tears. Most of the good works on general computing arn't books, there articles and such. Acm classics probably has the best articles on the subject, but thats just my opinon, and you can't forget the jargon file. And not forget BOFH if he's had to do any support work. Anything much more specific than that, and you get into extreamly specific realms.

It's the "greater than equal less than" comparison operator, like from the Schwartzian Transform or some such:

sort { $a->[1] <=> $b->[1] } map { [$_, -s] } @array;

The Jargon File has a good definition. I've also seen people use the term for something like this:

while (<>) { print };

That looks more like the goatse operator to me, though.

-B

BIFF was the invention of Joe Talmadge in 1988, soon taken over by Richard Sexton and then imitated by many. Here are some links to the history:

http://www.tuxedo.org/~esr/jargon/html/entry/B1FF. html

http://www.vrx.net/richard/biff.html

"Never underestimate the bandwidth of a station wagon filled with magtape, or a 747 filled with CD-ROMs"

You know, that's starting to sound like a really good analogy, even if it runs the risk of invoking a modified Godwin's Law (i.e., by making such an outrageous accusation, you officially lower the discussion to the level of flaming, so you lose).

I think it was here on slashdot that someone posted what I believe is a quote from "Alpha Centauri" (I never played the game, so I only know what I saw here). Ahem:

As the Americans learned so painfully in Earth's final century, free access to information is the only safeguard against tyranny.

The once-chained people whose leaders at last lose their grip on information will soon burst with freedom and vitality, while the free nation gradually constricting its grip on free discourse has begun its rapid slide into despotism.

Beware he who would deny you access to information, for in his heart he dreams himself your master.

One of the named inventors on the patent, Butler Lampson, is a famed CS person who is noted in the Jargon File. Microsoft Research has all kinds of famous computer folk working there, including the inventor of Qsort, the author of VMS, the author of Turbo Pascal (now C#), and others.

Of course, this rights-management is all useless (as any informed antivirus software user can tell you) as long as users have the right to execute whatever code they want on their PCs. No software is safe from attack from an emulator. They'd have to make VMWare and Virtual PC illegal, and make flashing your computer's BIOS to a different BIOS illegal to actually have this work and stop any but the most casual practitioners.

Of course the way the legal system is acting as of late, that may not be too unrealistic a scenario :-(

The best site I have found for dual proc machines is Los Alamos Computers.
The prices seem reasonable and they occaisonally put systems on e-Bay.

They were also the ones who built the Utimate Linux Box for Linux Journal and Eric Raymond that was featured earlier.

Too bad they are not accepting any new orders till 2002.

See this page [tuxedo.org].

sorry. that's what i get for not previewing. the link is to the Jargon File and the sentence should read "...direction of the jargon file yet"

Assuming(as was stated) that these boys are planning to eventually get into the tech field. I wonder if anyone has pointed them in the direction of the yet.

I mean besides being a good read, there is some pretty useful information in there from a linguistic point of view.

Well the original kremvax (in the post you refer to) was an April Fool's joke... although when the USSR did get on the Internet years later, someone named a machine kremvax in tribute :)

1. Hackers who write open source software seem to do so where there is no mature market for that software (i.e., they do it for free because no one will pay them to do it, not because they are motivated more by ego gratification than by money, as ESR suggests).

2. Funding by government and academic bodies has significantly contributed to the development of open source software, and to that extent government intervention in the software market (i.e., by directly or indirectly subsidizing the writing of open source software) may be desirable. (Contra ESR?)

3. To the extent that software companies try to co-opt open source developers by hiring them, they undermine themselves by encouraging more people to become open source developers (i.e., so they can get hired).

4. Programmers in countries such as Canada and Scandinavia contribute more per capita to free software than programmers in the USA, perhaps because there isn't a ready market for their skills in their home countries, which suggests that wealthier countries won't necessarily move toward developing more open source software. The breakdown of labor market barriers in a united Europe may therefore affect the rate of development of open source software (i.e., by encouraging those programmers to go where there are jobs rather than stay in grad school hacking kernels or whatever).

5. It might be a useful strategy for some software companies to permit some level of piracy rather than crack down on all piracy and thereby encourage development of open source alternatives.

P.S. Most of this is econ terminology, not poli sci.

Anyway, the author is making the following points (see the last part of the essay):

1. Hackers who write open source software seem to do so where there is no mature market for that software (i.e., they do it for free because no one will pay them to do it, not because they are motivated more by ego gratification than by money, as ESR suggests).

2. Funding by government and academic bodies has significantly contributed to the development of open source software, and to that extent government intervention in the software market (i.e., by directly or indirectly subsidizing the writing of open source software) may be desirable. (Contra ESR?)

3. To the extent that software companies try to co-opt open source developers by hiring them, they undermine themselves by encouraging more people to become open source developers (i.e., so they can get hired).

4. Programmers in countries such as Canada and Scandinavia contribute more per capita to free software than programmers in the USA, perhaps because there isn't a ready market for their skills in their home countries, which suggests that wealthier countries won't necessarily move toward developing more open source software. The breakdown of labor market barriers in a united Europe may therefore affect the rate of development of open source software (i.e., by encouraging those programmers to go where there are jobs rather than stay in grad school hacking kernels or whatever).

5. It might be a useful strategy for some software companies to permit some level of piracy rather than crack down on all piracy and thereby encourage development of open source alternatives.

Well, here's the history of that sign from the Jargon File

You might want to read up on your jargon, then. Here's a relevant entry. This is also linked to, btw, by the CCC page in the main article.

SecureIIS application firewall security alert
HTTP Request caused a security alert, please contact our web master if you are getting this alert in error.
What is SecureIIS
SecureIIS offers websites running Microsoft Internet Information Server a broad range of protection from common vulnerabilities, both known and unknown. Because SecureIIS does not protect against specific vulnerabilities, but classes of vulnerabilities, it allows for a much more far reaching layer of security.
For more information on SecureIIS, please visit http://www.eeye.com/SecureIIS/
eEye Digital Security - Vulnerability Is Over...

Wow... good to know that eEye is protecting innocent IIS users from the horrors of the Slashdot Effect!! ;-)

Reprint this. I imagine it's under the GPL or something, so it shouldn't cost you anything in royalties.

RTFB

I think it's a sad state of affairs when people don't know the basic history of computers (or at least what I grew up with). I have been made to feel old now for the second time in a day because earlier today someone didn't know what telix was, and now people don't know what war dialing is (to know the etymology of war driving).

More people should comprehensively read the Jargon File.

Did you intentionally mispell HILTER in order to avoid Godwin's Law?

Yes folks, this method is absolutely tried and true. It has worked for the venerable software industry for years! There really is no other way to develop your software!

1.) A good piece of software starts by scratching where's there's no itch. But that doesn't matter, because with the right marketing, you can create an itch where one previously did not exist. Your software should be covered by as many US patents as possible to prevent other software developers from trying to scratch the same itch.

2.) Write everything yourself. Never reuse your own code or that of others. Modular code is your enemy. Avoid it like the plague.

3.) If your first implementation doesn't work, kludge it until it does.

4.) Interesting problems should be handed off to somebody else, or better yet, developed by a third party as an undocumented module with highly restrictive licensing. Your users will never know the difference.

5.) If you lose interest in a program, your last duty is to make it disappear from the face of the earth as quickly and quietly as possible. (this includes discontinuing all tech support and preferably changing your 800 number) Turning the software over to public domain or releasing the source code might somehow help a competitor.

6.) Treat your users as scum. You know far better than them how to develop the software and what features they need. If the complexity of the code base becomes overwhelming, you clearly need more middle managers to increase your programmers' productivity. Now is also a good time to double the price of the software to meet increased development costs.

7.) Never, ever release source code to any of your software. Your customers don't have any use for it anyhow and you might somehow help your competitors. If customers complain about a bug, wait 6 months before fixing it and charge a nominal fee plus shipping for the update. Requests for features should be written on small slips of paper, placed in a hat, and drawn at random no less than one year after a major version release.

8.) Your customers should have no part in the debugging effort. Beta-testers, if allowed, should be registered and be given time-expiring binaries only.

9.) Choice of data structures is of lower priority than rapid code development. Your users can always buy faster hardware.

10.) Do not attempt to foster an online community of your users. They'll just complain, flood your support resources, and worst, they might even band together and develop free software to replace their need for yours!

11.) The next best thing to having good ideas is stealing them from others and then claiming them as yours. (preferably with broad patents) The latter is always better as it saves you R&D costs.

12.) Often, the most striking and innovating solutions come from realizing that it's your users' needs that are wrong, not your software.

13.) Perfection (in design) is achieved when your software has enough features to run untolerably slow on anything but the fastest currently available hardware. Some hardware vendors may offer kickbacks for this service.

14.) As a tool, truly great software should have only one use. Your software should have safeguards to prevent customers from using it in ways you did not intend. Anyone who successfully finds new uses for your software should be sued immediately under the Digital Millenium Copyright Act.

15.) Don't be afraid to mangle data in any way you see fit. After all, yours is the only software that needs to access it anyhow. Leaving it intact may allow competing software to operate on the same data or encourage users to request new ways for your software to process the data.

16.) If your software requires its own language or command set, it should be as convoluted as possible to discourage users from using anything but the GUI you've designed. Syntax of the language should be based on an innovative combination of Old English, Arabic, Hiragana, and Swahili.

17.) Any secret encoding schemes or passwords critical to your software's security should be stored in a file called 'no_secrets_here.dat' to confuse would-be hackers. The contents should be ascii-armored and successively encrypted an even number of times using ROT-13. Anyone who dares break your security scheme can be sued under the Digital Millenium Copyright Act.

18.) Give your programmers the problems they are least interrested in. Otherwise, they might get excited and try to change the program specifications without first consulting middle management.

19.) Provided your lead software development manager has a medium at least as good as an overhead slide projector and knows how to increase productivity with threats of downsizing, you can always let go of a programmer or two.

This satire made possible by Eric Raymond, author of The Cathedral and the Bazaar. Read his works if you want your software to succeed instead. (-:

...will continue to be right for a while. ;) (See Moore's Law if you're unfamiliar. :)

your portrayal of a solder with keen survival instincts

"Two gates up!" - System & Flux

"Solder my heart!" - Leonard Motherboard

Ahem. From The Jargon File:

spelling flame n. //

[Usenet] A posting ostentatiously correcting a previous article's spelling as a way of casting scorn on the point the article was trying to make, instead of actually responding to that point (compare dictionary flame ). Of course, people who are more than usually slovenly spellers are prone to think any correction is a spelling flame. It's an amusing comment on human nature that spelling flames themselves often contain spelling errors.

And from: http://www.advicemeant.com/flame/04psych.shtml

#475 Ullman Exception:

The Ullman Exception is when someone makes spelling mistakes or typos whilst complaining about someone else's spelling. Then, according to Ullman, it is a moral imperative to flame the SOB.

Of course, it's likely that I'll make a spelling/grammar mistake here, then you'll flame me and so on. Spelling checker in the 'post comment' box, anyone?

your portrayal of a solder with keen survival instincts

"Two gates up!" - System & Flux

"Solder my heart!" - Leonard Motherboard

Ahem. From The Jargon File:

spelling flame n. //

[Usenet] A posting ostentatiously correcting a previous article's spelling as a way of casting scorn on the point the article was trying to make, instead of actually responding to that point (compare dictionary flame ). Of course, people who are more than usually slovenly spellers are prone to think any correction is a spelling flame. It's an amusing comment on human nature that spelling flames themselves often contain spelling errors.

And from: http://www.advicemeant.com/flame/04psych.shtml

#475 Ullman Exception:

The Ullman Exception is when someone makes spelling mistakes or typos whilst complaining about someone else's spelling. Then, according to Ullman, it is a moral imperative to flame the SOB.

Of course, it's likely that I'll make a spelling/grammar mistake here, then you'll flame me and so on. Spelling checker in the 'post comment' box, anyone?

BTW, most of us (the rest of the world) prefer nanometre. Personally I prefer the attoparsec.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

"If you put an infinite number of monkeys at typewriters, eventually one will bash out the script for Hamlet." (One may also hypothesize a small number of monkeys and a very long period of time.) This theorem asserts nothing about the intelligence of the one random monkey that eventually comes up with the script (and note that the mob will also type out all the possible incorrect versions of Hamlet). It may be referred to semi-seriously when justifying a brute force method; the implication is that, with enough resources thrown at it, any technical challenge becomes a one-banana problem . This argument gets more respect since Linux justified the bazaar mode of development.

I know, I know. Mod me down. I had to say it.

When I think of security, I think of pants. How can you be secure wearing a kilt. I mean sure sensitive areas are somewhat hidden, but not secured.

If using a product exposes holes as big as a kilt will then I want to know. Then I can change clothes or avoid windy sidewalks.

Definition of security thru obscurity: http://www.tuxedo.org/~esr/jargon/html/entry/secur ity-through-obscurity.html

Spam spam spam!

term comes from Monty Python's Flying Circus skit.

the jargon file has other notes of etymological interest.

http://www.tuxedo.org/~esr/jargon/html/index.html

If you're consistently biting off more than you can chew, that's bound to have an effect on your morale. This is made worse by the relatively unintrospective nature of many geeks. Luckily, geek skills of analysis and frobbing can be applied; try treating yourself an optimization problem.

The other thing that occurs to me is that disrupted sleep patterns and depression go hand in hand. If I'm feeling unreasonably melancholy, the first thing I'll do is get my sleep cycle back in sync, either via staying up all night or melatonin.

They actually hit a deadline by adding more developers onto a project? I don't know much about game programming, but in business systems development that would be a miracle to say the least.

At a company like KCEJ, it seems many programming tasks are handled in a very bureaucratic, top-down way. A significant amount of designers and planners manage and schedule tasks. Since whoever is added to a team will have little knowledge of how the project works, it's more important to hire motivated programmers than skillful ones -- the article mentioned about half were college students. They don't communicate much; they just keep at it until they complete their well-defined tasks, therefore Brooks's Law doesn't really apply. Brutal, though. I suspect most Americans would tend to flake out under such circumstances.

One does not normally append a period to a URL or command. Someone might type it.

Jargon 4.3.1

You'll find RH here, but you'll probably want to use a mirror. When I checked the URL I was user 349 out of only 350 anonymous users allowed. The path should be the same or similar on the mirrors.

ftp://ftp.kde.org/pub/kde/stable/2.2.2/RedHat/7.2/

Jesus christ you're a fucking nerd! I really suggest you read this, and may God help you in life.

Um... I'm trying to figure out just what you're saying...

Here we've got a CVS client for windows integrated with the windows explorer that somebody created because they thought WinCvs "wasn't good enough". Now, I don't know about you, but that sounds darned useful to me since I use CVS every day at work and get sick of using both explorer and WinCvs to do everything. Perhaps you know of some better projects which make this thing redundant? I sure don't.

Next, you seem to be implying that there are particular "more worthy" projects people should be working on. You supply a link to freenet and to mind.sourceforge.net whatever that is. Two pie in the sky projects that already have more developers then they'd ever warrant and likely will never amount to a hill of beans.

If you think Open Source is "public service" then you have fun with your "worthy" projects. Me, I'll be spending my time working on the tools that make my life easier. (and yes Margaret that includes whole operating systems for my extended family to use that I can actually get to work for them) Why will I give these tools away? So the next guy can work on something *more* useful, and maybe, just maybe, make my life easier in return.

hacker ethic n.

1. The belief that information-sharing is a powerful positive good, and that it is an ethical duty of hackers to share their expertise by writing open-source code and facilitating access to information and to computing resources wherever possible. (taken from the Jargon File)

I just finished reading the Cathedral and the Bazaar. It talks about Popclient becoming Fetchmail. The way this happened was ESR sent patches to the author and found out that the project was almost dead. This led to the original author handing over the reins to ESR.

You didn't notice the Skycar has eight engines and two parachutes?

airplane rule . n.

"Complexity increases the possibility of failure; a twin-engine airplane has twice as many engine problems as a single-engine airplane." By analogy, in both software and electronics, the rule that simplicity increases robustness. It is correspondingly argued that the right way to build reliable systems is to put all your eggs in one basket, after making sure that you've built a really good basket.

Do we need a socializing HOWTO?

There already is one.

:)

For those interested in old languages...
"The Retrocomputing Museum is dedicated to programs that induce sensations that hover somewhere between nostalgia and nausea -- the freaks, jokes, and fossils of computing history. Our exhibits include many languages, some machine emulators, and a few games.

Most are living history -- environments that were once important, but are now merely antiques. A few never previously existed except as thought experiments or pranks. Most, we hope, convey the hacker spirit -- and if not that, then at least a hint of what life was like back when programmers were real men and sheep were nervous."

http://www.tuxedo.org/~esr/retro/