And the embarassing ignorance shown by Declan McCullagh and Wired in trying to ridicule Gore for his pronounciation of "router"! Yes, the correct prounciation is "raut-er" if you're talking about a wood-working tool! But cisco makes machines which selects routes (a new meaning, not in standard dictionaries), so surely the pronounciation he used is completely valid. (I've heard many versions of the American classic "Route 66" and all pronounced it "root 66." Now where are the songs about routers?)
In many places in this country, "route" and "root" do not rhyme. In such places, "route" rhymes with "out", "root" rhymes with "foot" -- at least when it means the base of a tree. It tends to rhyme with "boot" only when you're rooting for the other team, and with "foot" when rooting in the ground. And to finish the series, "rut" rhymes with "hut", and "rout" (as in a disorderly retreat) with "out". Oh, and such places tend use the same vowel in "roof", "hoof", and "soot" as they do in "put" and "foot".
Let's not be ridiculingly prescriptivist here. It's not a matter of right or wrong. This is just the way it is. It may not be a prestige accent from Nyoo Yawk, but it's a legitimate American accent from the heartland, one that's been around a long, long time. And considering that it conserves more different pronunciations than do places in the country where these many r- words have merged together due to more frequent wear and tear there, it's probably an older one, too.
Re:The Queen's English - getting quite offtopic
on
FreeBSD 3.4 released
·
· Score: 2
I'm impressed that you still associate it with it's original dictionary meaning
"Original dictionary meaning"? I lament to report that I don't have Dr Johnson's dictionary handy.:-)
It's probably just a matter of having played enough tabletop games of Napoleonic miniatures as a youth for the word to have found that slot in my brain. You really wanted to have élite troops on hand. It made a tremendous difference in the outcome of the battle. If the other side had élites, and you didn't, you were probably doomed. Doubtless as a result of these childhood impressions, the word élite has for me always held a position of respect and honor.
My disgust with the commonplace use of the word is, however, completely unrelated to the presence of alternate definitions of that particular gloss, and likewise unrelated to the inexorable change that all language undergoes over the passage of the years. Rather, it's about bullying. As I believe I have previously explained, I take issue with the insultingly simplifying attitude with which the word has too often come to be used. This is the same problem as occurs when one stoops to calling someone a "hick", or, if you're in the American South, a "yankee". It's not an objective analysis: it's petty name-calling. The perpetrators should be ashamed of themselves.
The problem with all such name-calling is that it groups together a wildly diverse set of actual circumstances, each with its own individual issues, under an all-encompassing rubric that occludes what you're really saying by enflaming the passions of the listener. Name-calling blurs particulars by turning the specific into the generic, and, moreover, into a particular generic that evokes undisguised contempt, and in the current climate of polical correctness, risks no reproach. It's a bigotted way of bashing down a legitimate issue by diverting attention away from the actual concern by seeking a purely emotional reaction through stereotyping. Taking refuge behind a wholly derogatory ableit politically popular insult is nothing but an artless way to discourage reasoned discourse and true understanding. One should say whatever needs being said without pusillanimous posturing, without cowardly hiding behind belittling smokescreens.
In short, throwing "élitism" around is name-calling, and name-calling is bullying. Let's not encourage it.
I hope this isn't a direct response to the question of the Linux menuconfig being "bloat" or not. Recompiling a kernel takes a bit of learning no matter how you do it; I'm not sure why using a curses-based interface would mean that the admin in question eschews "professional knowledge".
No. It was not a direct response to any allegations of menuconfig some constituting bloat. For the record, I happen to use menuconfig and am happy with it. But that wasn't the issue. The issue was bigotry and name-calling.
My posting was a reaction to the disgustingly commonplace use of the term "élitist" as a pejorative. Just like branding someone or something with emotionally-charged terms like "hick" or "Luddite" or "fascist"--or, sadly, even "liberal", resorting to words like "élitism" obscures objective reality by drawing upon subliminal prejudices rather than upon technical accuracy and sound reasoning. It is, in effect, nothing more than obnoxious name-calling, fully deserving of utter condemnation.
If you have particular complaints about expectations, then I would see those explained. The trendy uses of "élite" and its derivatives are all nothing more than facile bigotry. It's an unjust branding that tries to pull at people's emotions rather than reason. Rather that rabble rousing, give precise details about what it bothering you. Don't hide the details under a pejorative. Say what you mean.
As for Perl, I strongly resent its mention in every article that addresses me. I would also appreciate it if you would avoid putting words into my mouth I never said.
There is undeniably an elitism amongst FreeBSD users that I neither liked nor could I understand. One of the regular complaints I heard was that Linux installation and configuration tools were uneccessary bloat. Well, I can hand edit a kernel config file on both Linux and FreeBSD as well as the next guru, but I'd much rather use 'make menuconfig'. This kind of carping was sheer elitism, and underlined that a sea change in FreeBSD users attitudes was required (if not in that of the developers).
Dare we ask for a bit of professional knowledge? Of course not, for that would be "élitist". Can we ask someone to actually spend some time learning something? Of course not--that's just more "élitism". Can we ask for honest work? Nope. Same problem. To acknowledge the existence of inherent complexity or inherent intelligence or any sort of learned skill or professional training is something only the "élite" can contemplate.
It's remarkable how much "technical competence" or "discerning professional judgment" gets branded as élitism. In fact, current usages of "élite", "élitist", and "élistism" are just part of the whole dumbing-down of America theme. Or, if you would, part of the supreme dominance of uninformed consumerism and the mass media's manipulations.
It is not "élitist" to prefer food that doesn't suck, or cars that don't break down, or software that doesn't crash. It is not "élitist" to want a clean, digital CD instead of a scratchy phonograph disc. It is not "élitist" to ask for a senior surgeon instead of an intern. It is not "élitist" to prefer BSD over CP/M.
In short, pay very careful every time you see someone using terms like "élite", "élitist", and "élistism". In almost every case, what you're seeing is a form of bigotry and prejudice that's bashing someone with a politically correct putdown that Joe Bubba can lend his cheerlead to. But it's still a disrespectful and facile insult.
This tred is subtly but seriously dangerous, and it's not just in our schools that it's happening. In recent years, the country as a whole as come to extoll the stupid, the dumb, the intellectually challenged if you would. There is no excellence, no pride, no "going the extra mile". To pretend that everyone is the same, that we are all no different in what we know or *can* know or what we do or *can* do, whether it be from training or education or intelligence or energy or motivation, is a damned lie.
So don't grab a nice little trendy buzzterm like "élitism" and bash down technical and professional competence, any individuality or drive or vision--any personal flare. By condesendingly scoffing at élitism, you're just furthering our current national hobby the Dumbing of America.
(And don't worry, you folks outside of America. Your time, too, is coming.)
Personally I can understand the idea of somebody not wanting to float code that Microsoft will end up with in their products. Like BSD did.
In ESR's writings on how hacker culture is really a gift culture, it works out that the more someone gives away, the more prestige, honor, and respect they accrue. By giving everything away to any and all--yes, even to Microsoft--the BSD team's honor (hacker karma?) has soared.
Linux is NOT UNIX. Linux is it's own kernel, OS, etc.
Look at the APIs spelt out in sections 1, 2, and 3 of the manual on a typical Linux system. Now look at the same on Solaris or some other commercial vendor's system. Now go over to your favorite BSD system.
Guess what? The similarities so far outweigh the differences as to render these latter wholly inconsequential. Quite obviously, here we are at most speaking variant dialects of the same common language called Unix, not completely different languages.
I like FreeBSD a lot, don't get me wrong, but some of the FreeBSD Bigots (especially in #freeBSD) turn off would-be users.
Such, I begin to suspect, may well be the nature of IRC. The same issues involved with IRC are probably present in other electronic forms of interaction, and perhaps in other ineractive situations as well.
Think about all the fascinating socal factors involved. Who is drawn to irc? Who becomes a regular there? How is pecking order determined? How is it preserved? How does a community age? How does an established power or prestige structure react to new members in that community? How does the lack of face-to-face contact change interactions? Does communication suffer, or is it smoothed? Are we quicker to show kindness if the other person is a person, not lines of type? Are we quicker to do casual harm if all there is on the other side is a line of type? How do we perceive the "us" and "them"? Are strangers always "them", and if not, which ones are "us"? Does the speed of feedback change any of this? What behaviours produce positive reinforcement, what behaviours negative ones? How does the overall friendliness of the group change with time? Do members come and go randomly, or are their entrenched figures? How well do these group dynamics scale as membership increases? Are there regular patterns of behavior that occur only in specific sorts of groups but not in others? Is it long-term helpful to give individual attention to each newcomer's duplicate questions rather than creating a FAQ? What differences and similaries in communications can be found between mailing lists, newsgroups, IRC, and Slashdot? Are these different than the group dynamics you find in a real-time live club devoted to a common interest that meets regularly, or from what you'd find in an informal bunch of pals hanging out at there favorite pub? Is Slashdot really something of a time-delayed webchat?
There's a very interesting paper or three waiting for some budding sociologist to write about interactions in the hacker community's electronic forums.
Some people would give life-saving medicine only to "the good guys" [read: their own team]. This is a selfish, destructive, and thus inherently EVIL way to live. Deny no man who thirsts the water he so earnestly desires, be he friend or be he foe. If we must pass judgment, then let us judge the goodness of a man, of a state, of any enterprise--not by how they treat their favorites, but by how they treat their downtrodden, their dissenters, their outcasts, the most despised segments of their communities.
That is why we should be happy that Microsoft had made good use from BSD code.
I am in the process of switching my freenix machines over to NetBSD (one Slackware box left out of the bunch.) Not because Linux has become too popular. Because the Linux code base is turning into a swamp I don't want to linger in.
I empathize with you. Good luck.
I would like to clarify one point, and then ask one question. The clarification is that "Freenix" isn't just an alternate spelling of "FreeBSD", but rather more of a contraction for "Free Unix". The term "Freenix" has come to comprise all free Unix-ish operating systems, including all the free BSDs, all the free Linuces, and anything else Unixy enough that's reasonably free that has in the past or shall in the future come along.
Now, the question is: what motivated you to select NetBSD over OpenBSD?
I'm completely agnostic here, and am just trying to learn. Any BSD makes me feel happy and comfortable and at home, probably because it was the first operating system I learned that was fun to play with. My priors of EXEC8, RT/11, MVS, and RSX didn't count, and the jury is still out on RSTS/E.:-) My own experiences are with just about any BSD except for NetBSD, starting from 2BSD on PDP-11s and then 4BSD on Vaxen, and working up through the various commercial BSDs like SunOS, Ultrix, and ConvexOS, as well as the more recent BSD/OS (marginal), MacOS X (marginal), OpenBSD (a fair bit), and FreeBSD (somewhat).
But not NetBSD. So I'm just curious: What made you make that choice?
Are you really serious? Have you truly looked? Linux documentation is abominable! Even the worst BSD distribution is at least an order of magnitude better at documentation than the best Linux distribution. I'm not kidding in the least. It abominable.
Take Redhat/Linux, for example (please:-). Most of what Redhat ships is undocumented, and that which exists is severely underpowered compared with BSD.
For example, let's suppose you'd like to learn about the interface to the system's terminal drivers. That's in tty(4).
That's a huge difference. As you can plainly see, the amount of info on just one device in BSD is much better than on Linux. And if you look at the overall device coverage, the same theme carries through.
And that's just part of it. Here's a bug list on Redhat docs that I've submitted, along with programs to automatically detect these problems. You should really read those over to start to get a feel for how bad it is.
I'd like to make clear that redhat has done a very great job at fielding these bugs and trying to do something about them. I am completely happy with their customer service. I'm not trying to knock that.
So not only is the documentation exceptionally scarce in Linux, it's very, very buggy. You wouldn't believe how nasty the situation truly is. Run those on your own systems and you'll see what I mean. And yes, I checked this on Debian/Linux and SuSE/Linux as well as Redhat/Linux. It was all nasty. I also checked on OpenBSD, FreeBSD, and Solaris. You'll see that there's a world of difference here. Find yourself a Redhat system and an OpenBSD system, for example, and start poking around. You'll see.
My point of view is that it isn't fair to the user of your system for you to ever include something that isn't documented. When I have been part of releases, either the old Unix releases from years ago or even the new Perl releases today, the rule was simple: if it isn't documented, it isn't shipped. No excuses.
I strongly believe that the Linuces should do the same. Let no program or library be shipped which is undocumented. It's the very least a systems integrator can do. That's just part of what we mean when we say that BSD distributions are more "solid" than Linux distributions. The commercial Unices and the free BSDs take this kind of thing seriously. The Linuces, so far, do not. I have hope that this will change, and Redhat has a truly positive attitude about all this, but right now, you just can't compare them.
How is it that *BSD demands more from an admin that *Linux does? I run both, and I really don't see that kind of dramatic distinction.
Re:Let's have more integration between *BSD and Li
on
Intel using FreeBSD
·
· Score: 2
Nice idea, but before we get "integration" across the Freenix world, shouldn't we please get a bit of integration across *Linux first? Right now, there's a whole long ways to go.
Re:Why is LISP superior?
on
RMS The Coder
·
· Score: 2
It's actually a big improvement. First of all , if you can decrease code size by an order of magnitude, you also cut bugs down by the same factor. Secondly, if you have a 1 program that writes 10 other programs, you've not only cut down your overall code size, you've significantly improved your abstraction level. This also helps for maintainability.
Syntax errors in program code are easily caught by the compiler and are therefore of scant consequence. Errors in the underlying logic are far more insidious, and therefore far more dangerous.
So, too, in prose. A simple typo is no big deal. But incorrect reasoning is something to be always wary of.
Here are some suggested improvements to your code posting which you may or may not wish to consider:
You're using global variables.
You forgot to use strict.
You used the evil cgi-lib.pl library instead of the standard CGI.pm module.
You assume that that library will be in whatever directory you're currently executing in rather than in the standard site_lib@INC path.
You used symbolic references and exposed your internal namespace to external mucking with.
You forgot to employ the -w flag or the use warnings compiler pragma.
You forgot to use the -T flag for taint checking.
You have either a bug in the template path handling, or else a horrible security hole just waiting to happen. What about someone specifying/etc/passwd as their file?
Your indentation is hosed. Run code you want to post to Slashdot through this program before posting. It is a work-around for the illegality of a <PRE> tag.
Finally, why is this a CGI script instead of a regular tool?
Hint: your import ordering is wrong. Please test your code next time.
You and yours have an incompatible change between library versions causing mysterious failures in a non-backward compatible fashion. Your toy language gives the most idiotic error message known to man, rendering it utterly indiscernible; this is what makes you want to punch python's lights out. I have never seen a programming language with such horrid error messages. Bug isolation and error recovery would be easier with your eyes closed than reading that embarrassment. A programmer doesn't need this kind of grief from a compiler. Your toy language also doesn't allow you to specify a version requirement the way Perl does with its modules or the way normal Unix shared library stuff does. This is just not something that a serious programmer in a real-world project should put up with. And we don't.
Your code is also inferior in that it does less than Perl's does. Apparenly you've confused the -n flag for some STDIN reading. Read the perlrun(1) manpage next time.
And your sorry script is slower, way slower--glacially slower--than my Perl version, just like so much in Python:
% time perl/tmp/code2html.pl < random_cgi_script >/dev/null 0.470u 0.010s 0:00.49
% time python/tmp/code2html.py < random_cgi_script >/dev/null 5.140u 0.070s 0:05.23
If I wanted to take an order of magnitude performance hit, I'd code in Javascript or something. No thanks, buddy. Get yourself a real programming language.
Actually it would be "I sure and *adverb* about *subject*" Since the first blank is describing how he IS and last time I check to be was a verb.
No, that's not correct; to be is a copulative verb, also known as a linking verb. Therefore, its predicate complement is not an adverb, but either a noun (or pronoun) or an adjective. Think of a copulative verb as though it were an equals sign. Another similar verb is to become. One cannot *become happily, although one can become happy, and one can become a new person.
I know both, and I can tell you that Python code is significantly easier to read than Perl code.
That's a silly thing to say. Please try to refrain from such subjective assessments. They're anecdotal at best, and serve mainly to perpetuate the leyenda negra; that is, FUD.
Python has its faults, and I'm surprised Tom hasn't come to point some of them out (or maybe he's masquerading as an AC, doing some astroturf for himself).
First off, I have a life, and yesterday was Sunday. I just got around to looking at this stuff this Monday morning.
Second off, why should I bother to jam on Python's faults? I see no profit from that.
I'd rather discuss the discrete advantages and disadvantages of your particular program--which, by the way, doesn't bloody work.
Even with Pythons' faults though, maintainability is king when it comes to writing real programs. Perl is notorious, even among Perl programmers, for being unmaintainable. Hence, Perl loses.
Nope, I'm sorry. That's not true. I don't know whether you're lying or simply wrong, but in any event, your fudding is unbecoming of any serious cyberlinguistic researcher and analyst.
Badly written code is notorious for being unmaintable irrespective of the implementation language. Fuzzy thinking and sloppy coding makes any program a nightmare. A software professional has been trained in ways that your common CGI hacker has not.
Perl is very accessible to these untrained but eager nonprofessionals just trying to get their jobs done. They shall forever come up lacking when held to the same standard as you would hold a softare design engineer. But they, too, have a place in the world. It's officialyy perfectly ok to speak "Perl baby talk". That's what they're doing. Do you criticize your nearest eight-year-old for his inability to construct and execute an intricate novel or a symphonic composition? Of course not.
Just look at the long code I originally reformatted. The bug is in the thinking of the coder, and inability to generalize approaches and work at high levels of abstraction. The fault of bad art lies here in the artist, not his paint.
Now, if you would, login to Slashdot and authenticate yourself. I need to have your mail address because your code is broken, and I'd like to discuss this privately in order to spare you public embarrassment.
If you insist upon maintaining your anonymity, then please do not bother to reply.
I would appreciate it if the author of this code would publish his mail address so I can contact him. His code aborts with fatal exceptions, and I'd like to know why.
Besides normal refcount GC, Perl also runs a complete GC pass on thread shutdown time to find the circularities. This makes it much more suitable in an embedded environment than most other languages that use a refcount GC, such as Python, which does no such lifesaving pass at the end of a thread.
And Perl is certainly strongly typed--providing you look at it the right way. You could say that Perl has strong typing but late binding, that is, dynamic typing.
Let me explain. If you store an object of type Foo in variable $ob, you are perfectly welcome to store an object of type Bar there later. This is very polymorphic. However, due to dynamic typing, if you call a method that only works for class Foo when the variable is holding a Bar--or vice versa--then you'll take a run-time exception.
The use fields pragma affords you static typing, however, so that you'll get caught early, back at compile time, for certain kinds of incorrect OO operations; viz., improper data attribute access. Perl has a lot more compile-time analysis than you might be used in other so-called "(byte-code) interpreted" languages.
Perl also has sane conformance rules between certain fundamental kinds of values that confuse people. That's not to say it's not strongly typed (again, given the right kind of squinting). For example, using an integer where a float is called for has a particular and completely well defined rule that gets applied. However, using a float where a Foo object is called for certainly does not, and you get zapped with an exception at that point.
There are certainly things you can do if you prefer a less forgiving system. For example, you can promote numeric warnings into fatals within a particular lexical scope via use warnings FATAL => 'numeric'. Or you could use the new lint tool to find dubious context coercions, such as perl -MO=Lint,-context,-undefined-subs myperlprogram.
Dynamic typing and certain common-place default conformance rules means you don't have to worry about a lot of busy-work if you won't want to. It also means you can detect whether an integer is odd using the peculiar $n =~/[13579]$/.:-)
Re:YART - Yet Another RMS Triumph
on
RMS The Coder
·
· Score: 1
The author was RTM Sr, not Robert the over-maligned author of the Internet Work.
Re:YART - Yet Another RMS Triumph
on
RMS The Coder
·
· Score: 2
[RMS] wrote the original bc manual
**BZZZT*. I'm sorry, but that's wrong. Thank you for playing anyway. The correct answer is that it was Lorinda Cherry and the famous Robert Morris who wrote the original bc manual. A copy can be found here in the original troff or here in poorly rendered HTML. You should also be able to find it on your BSD system in/usr/share/doc/usd/06.bc.
Slashdot Mirror
Let's not be ridiculingly prescriptivist here. It's not a matter of right or wrong. This is just the way it is. It may not be a prestige accent from Nyoo Yawk, but it's a legitimate American accent from the heartland, one that's been around a long, long time. And considering that it conserves more different pronunciations than do places in the country where these many r- words have merged together due to more frequent wear and tear there, it's probably an older one, too.
It's probably just a matter of having played enough tabletop games of Napoleonic miniatures as a youth for the word to have found that slot in my brain. You really wanted to have élite troops on hand. It made a tremendous difference in the outcome of the battle. If the other side had élites, and you didn't, you were probably doomed. Doubtless as a result of these childhood impressions, the word élite has for me always held a position of respect and honor.
My disgust with the commonplace use of the word is, however, completely unrelated to the presence of alternate definitions of that particular gloss, and likewise unrelated to the inexorable change that all language undergoes over the passage of the years. Rather, it's about bullying. As I believe I have previously explained, I take issue with the insultingly simplifying attitude with which the word has too often come to be used. This is the same problem as occurs when one stoops to calling someone a "hick", or, if you're in the American South, a "yankee". It's not an objective analysis: it's petty name-calling. The perpetrators should be ashamed of themselves.
The problem with all such name-calling is that it groups together a wildly diverse set of actual circumstances, each with its own individual issues, under an all-encompassing rubric that occludes what you're really saying by enflaming the passions of the listener. Name-calling blurs particulars by turning the specific into the generic, and, moreover, into a particular generic that evokes undisguised contempt, and in the current climate of polical correctness, risks no reproach. It's a bigotted way of bashing down a legitimate issue by diverting attention away from the actual concern by seeking a purely emotional reaction through stereotyping. Taking refuge behind a wholly derogatory ableit politically popular insult is nothing but an artless way to discourage reasoned discourse and true understanding. One should say whatever needs being said without pusillanimous posturing, without cowardly hiding behind belittling smokescreens.
In short, throwing "élitism" around is name-calling, and name-calling is bullying. Let's not encourage it.
My posting was a reaction to the disgustingly commonplace use of the term "élitist" as a pejorative. Just like branding someone or something with emotionally-charged terms like "hick" or "Luddite" or "fascist"--or, sadly, even "liberal", resorting to words like "élitism" obscures objective reality by drawing upon subliminal prejudices rather than upon technical accuracy and sound reasoning. It is, in effect, nothing more than obnoxious name-calling, fully deserving of utter condemnation.
As for Perl, I strongly resent its mention in every article that addresses me. I would also appreciate it if you would avoid putting words into my mouth I never said.
It's remarkable how much "technical competence" or "discerning professional judgment" gets branded as élitism. In fact, current usages of "élite", "élitist", and "élistism" are just part of the whole dumbing-down of America theme. Or, if you would, part of the supreme dominance of uninformed consumerism and the mass media's manipulations.
It is not "élitist" to prefer food that doesn't suck, or cars that don't break down, or software that doesn't crash. It is not "élitist" to want a clean, digital CD instead of a scratchy phonograph disc. It is not "élitist" to ask for a senior surgeon instead of an intern. It is not "élitist" to prefer BSD over CP/M.
In short, pay very careful every time you see someone using terms like "élite", "élitist", and "élistism". In almost every case, what you're seeing is a form of bigotry and prejudice that's bashing someone with a politically correct putdown that Joe Bubba can lend his cheerlead to. But it's still a disrespectful and facile insult.
This tred is subtly but seriously dangerous, and it's not just in our schools that it's happening. In recent years, the country as a whole as come to extoll the stupid, the dumb, the intellectually challenged if you would. There is no excellence, no pride, no "going the extra mile". To pretend that everyone is the same, that we are all no different in what we know or *can* know or what we do or *can* do, whether it be from training or education or intelligence or energy or motivation, is a damned lie.
So don't grab a nice little trendy buzzterm like "élitism" and bash down technical and professional competence, any individuality or drive or vision--any personal flare. By condesendingly scoffing at élitism, you're just furthering our current national hobby the Dumbing of America.
(And don't worry, you folks outside of America. Your time, too, is coming.)
Guess what? The similarities so far outweigh the differences as to render these latter wholly inconsequential. Quite obviously, here we are at most speaking variant dialects of the same common language called Unix, not completely different languages.
Think about all the fascinating socal factors involved. Who is drawn to irc? Who becomes a regular there? How is pecking order determined? How is it preserved? How does a community age? How does an established power or prestige structure react to new members in that community? How does the lack of face-to-face contact change interactions? Does communication suffer, or is it smoothed? Are we quicker to show kindness if the other person is a person, not lines of type? Are we quicker to do casual harm if all there is on the other side is a line of type? How do we perceive the "us" and "them"? Are strangers always "them", and if not, which ones are "us"? Does the speed of feedback change any of this? What behaviours produce positive reinforcement, what behaviours negative ones? How does the overall friendliness of the group change with time? Do members come and go randomly, or are their entrenched figures? How well do these group dynamics scale as membership increases? Are there regular patterns of behavior that occur only in specific sorts of groups but not in others? Is it long-term helpful to give individual attention to each newcomer's duplicate questions rather than creating a FAQ? What differences and similaries in communications can be found between mailing lists, newsgroups, IRC, and Slashdot? Are these different than the group dynamics you find in a real-time live club devoted to a common interest that meets regularly, or from what you'd find in an informal bunch of pals hanging out at there favorite pub? Is Slashdot really something of a time-delayed webchat?
There's a very interesting paper or three waiting for some budding sociologist to write about interactions in the hacker community's electronic forums.
That is why we should be happy that Microsoft had made good use from BSD code.
Merry Christmas.
Oh, and NO GROVELLING! :-)
I would like to clarify one point, and then ask one question. The clarification is that "Freenix" isn't just an alternate spelling of "FreeBSD", but rather more of a contraction for "Free Unix". The term "Freenix" has come to comprise all free Unix-ish operating systems, including all the free BSDs, all the free Linuces, and anything else Unixy enough that's reasonably free that has in the past or shall in the future come along.
Now, the question is: what motivated you to select NetBSD over OpenBSD?
I'm completely agnostic here, and am just trying to learn. Any BSD makes me feel happy and comfortable and at home, probably because it was the first operating system I learned that was fun to play with. My priors of EXEC8, RT/11, MVS, and RSX didn't count, and the jury is still out on RSTS/E. :-) My own experiences are with just about any BSD except for NetBSD, starting from 2BSD on PDP-11s and then 4BSD on Vaxen, and working up through the various commercial BSDs like SunOS, Ultrix, and ConvexOS, as well as the more recent BSD/OS (marginal), MacOS X (marginal), OpenBSD (a fair bit), and FreeBSD (somewhat).
But not NetBSD. So I'm just curious: What made you make that choice?
Take Redhat/Linux, for example (please :-). Most of what Redhat ships is undocumented, and that which exists is severely underpowered compared with BSD.
For example, let's suppose you'd like to learn about the interface to the system's terminal drivers. That's in tty(4).
That's a huge difference. As you can plainly see, the amount of info on just one device in BSD is much better than on Linux. And if you look at the overall device coverage, the same theme carries through.And that's just part of it. Here's a bug list on Redhat docs that I've submitted, along with programs to automatically detect these problems. You should really read those over to start to get a feel for how bad it is.
I'd like to make clear that redhat has done a very great job at fielding these bugs and trying to do something about them. I am completely happy with their customer service. I'm not trying to knock that.
Some of the tools I used for this are:
- cfman - make sure manpages have accurate SEE ALSOs
- no3man - identify which library calls aren't mannable
- noman - identify which commands are installed without manpages
- scatman - find turds in mantrees
So not only is the documentation exceptionally scarce in Linux, it's very, very buggy. You wouldn't believe how nasty the situation truly is. Run those on your own systems and you'll see what I mean. And yes, I checked this on Debian/Linux and SuSE/Linux as well as Redhat/Linux. It was all nasty. I also checked on OpenBSD, FreeBSD, and Solaris. You'll see that there's a world of difference here. Find yourself a Redhat system and an OpenBSD system, for example, and start poking around. You'll see.My point of view is that it isn't fair to the user of your system for you to ever include something that isn't documented. When I have been part of releases, either the old Unix releases from years ago or even the new Perl releases today, the rule was simple: if it isn't documented, it isn't shipped. No excuses.
I strongly believe that the Linuces should do the same. Let no program or library be shipped which is undocumented. It's the very least a systems integrator can do. That's just part of what we mean when we say that BSD distributions are more "solid" than Linux distributions. The commercial Unices and the free BSDs take this kind of thing seriously. The Linuces, so far, do not. I have hope that this will change, and Redhat has a truly positive attitude about all this, but right now, you just can't compare them.
How is it that *BSD demands more from an admin that *Linux does? I run both, and I really don't see that kind of dramatic distinction.
Nice idea, but before we get "integration" across the Freenix world, shouldn't we please get a bit of integration across *Linux first? Right now, there's a whole long ways to go.
It's actually a big improvement. First of all , if you can decrease code size by an order of magnitude, you also cut bugs down by the same factor. Secondly, if you have a 1 program that writes 10 other programs, you've not only cut down your overall code size, you've significantly improved your abstraction level. This also helps for maintainability.
So, too, in prose. A simple typo is no big deal. But incorrect reasoning is something to be always wary of.
You and yours have an incompatible change between library versions causing mysterious failures in a non-backward compatible fashion. Your toy language gives the most idiotic error message known to man, rendering it utterly indiscernible; this is what makes you want to punch python's lights out. I have never seen a programming language with such horrid error messages. Bug isolation and error recovery would be easier with your eyes closed than reading that embarrassment. A programmer doesn't need this kind of grief from a compiler. Your toy language also doesn't allow you to specify a version requirement the way Perl does with its modules or the way normal Unix shared library stuff does. This is just not something that a serious programmer in a real-world project should put up with. And we don't.
Your code is also inferior in that it does less than Perl's does. Apparenly you've confused the -n flag for some STDIN reading. Read the perlrun(1) manpage next time.
And your sorry script is slower, way slower--glacially slower--than my Perl version, just like so much in Python:
If I wanted to take an order of magnitude performance hit, I'd code in Javascript or something. No thanks, buddy. Get yourself a real programming language.If you expect to be treated professionally, then stop your lying and post your real name, you pathetic coward.
You can read more about this in the Elements of Language Manual.
Second off, why should I bother to jam on Python's faults? I see no profit from that.
I'd rather discuss the discrete advantages and disadvantages of your particular program--which, by the way, doesn't bloody work.
Nope, I'm sorry. That's not true. I don't know whether you're lying or simply wrong, but in any event, your fudding is unbecoming of any serious cyberlinguistic researcher and analyst.Badly written code is notorious for being unmaintable irrespective of the implementation language. Fuzzy thinking and sloppy coding makes any program a nightmare. A software professional has been trained in ways that your common CGI hacker has not.
Perl is very accessible to these untrained but eager nonprofessionals just trying to get their jobs done. They shall forever come up lacking when held to the same standard as you would hold a softare design engineer. But they, too, have a place in the world. It's officialyy perfectly ok to speak "Perl baby talk". That's what they're doing. Do you criticize your nearest eight-year-old for his inability to construct and execute an intricate novel or a symphonic composition? Of course not.
Just look at the long code I originally reformatted. The bug is in the thinking of the coder, and inability to generalize approaches and work at high levels of abstraction. The fault of bad art lies here in the artist, not his paint.
Now, if you would, login to Slashdot and authenticate yourself. I need to have your mail address because your code is broken, and I'd like to discuss this privately in order to spare you public embarrassment.
If you insist upon maintaining your anonymity, then please do not bother to reply.
I would appreciate it if the author of this code would publish his mail address so I can contact him. His code aborts with fatal exceptions, and I'd like to know why.
And Perl is certainly strongly typed--providing you look at it the right way. You could say that Perl has strong typing but late binding, that is, dynamic typing.
Let me explain. If you store an object of type Foo in variable $ob, you are perfectly welcome to store an object of type Bar there later. This is very polymorphic. However, due to dynamic typing, if you call a method that only works for class Foo when the variable is holding a Bar--or vice versa--then you'll take a run-time exception.
The use fields pragma affords you static typing, however, so that you'll get caught early, back at compile time, for certain kinds of incorrect OO operations; viz., improper data attribute access. Perl has a lot more compile-time analysis than you might be used in other so-called "(byte-code) interpreted" languages.
Perl also has sane conformance rules between certain fundamental kinds of values that confuse people. That's not to say it's not strongly typed (again, given the right kind of squinting). For example, using an integer where a float is called for has a particular and completely well defined rule that gets applied. However, using a float where a Foo object is called for certainly does not, and you get zapped with an exception at that point.
There are certainly things you can do if you prefer a less forgiving system. For example, you can promote numeric warnings into fatals within a particular lexical scope via use warnings FATAL => 'numeric'. Or you could use the new lint tool to find dubious context coercions, such as perl -MO=Lint,-context,-undefined-subs myperlprogram.
Dynamic typing and certain common-place default conformance rules means you don't have to worry about a lot of busy-work if you won't want to. It also means you can detect whether an integer is odd using the peculiar $n =~ /[13579]$/. :-)
The author was RTM Sr, not Robert the over-maligned author of the Internet Work.