Hmmm...
So, does this mean that a ham radio operator can force
people not to use microwave ovens, which also use the
2.4GHz band (and, last time I checked, weren't licensed
either)?
"Excuse me, ma'am, but I'm confiscating your microwave
as an illegal transmitter.
Your ham radio operator neighbors have been complaining."
A lot of them are trash -- probably most.
I (unitentionally) have some experience with that.
You may be next.
One of the SPAM generators out there seems to take the
mailing list in batches, using the first name of a batch
as the "From:" address and the rest as the "To:" addresses.
This has two rather evil effects: the first
address gets (1) bounce notices and (2) complaints.
I was the unlucky victim of this program a few days ago.
I got about ten bounce messages, some of them for a
half dozen or so bad addresses (the program was smart
enough to group messages by receiving domain), for about
30 bogus addresses in all.
But I only got one complaint...
Slashdot's "BSD is dying" troll is notorious -- there
are few people in the open-source community who haven't
seen or heard of those posts.
Mike's use of the troll in a rhetorical device is
natural; he's simply saying that even though he
and Jordan are "dying" parts of FreeBSD, FreeBSD
goes on.
(I suspect that his reference to the troll is also making
a dig at the people he blames for making his life on core
miserable by tying them to the "Slashdot crowd.")
FreeBSD is making steady progress on a variety of fronts.
Mike's complaint isn't that FreeBSD itself
is dying, or broken.
It's that the project's governance is broken,
and that
far too much time is spent arguing petty matters with
little effect beyond making the participants unhappy.
There is one way that Mike's leaving is a Good Thing,
in that it will trigger a core election.
That may go some ways toward solving the problem.
All you've made clear is your willingness to stretch
a point beyond all reasonableness.
Theo is merely exercising the right that all BSD folk
assume: that you can take the BSD code and make a
product out of it and sell it for whatever you like.
Of course, the code itself remains unencumbered, so
someone else can take it and make a product out
of it and give it away, or sell it for a different
price, perhaps after changes or additions.
They just can't exactly duplicate Theo's organization
("compilation" is the legal term, I believe) or packaging --
his "product."
BSD and GNU folks can argue all day over their
respective ideas of freedom, and over which model is
more "free."
I don't want to argue that issue here (I frankly don't
think it can ever be effectively settled), but merely
point out that you're making a distinction that BSD
doesn't consider valid.
And that's why your argument just doesn't have much
traction here, although in the GNU/Linux world it may.
Nothing prevents you from making your own ISO image and
giving it away or even selling it.
You just can't take the lazy way out and make bit-for-bit
copies of the distribution CD's.
So, install mkisofs and go at it.
You might even learn something.
Saying you "can't share it easily" is a confession of
laziness or incompetence, or both.
(Another word that comes to mind is "ingratitude.")
Actually, the video chip (which is identified by the server
as an ATI Radeon Mobility M6 LY rev 0) wasn't yet supported by XFree86 4.1,
so I built a snapshot of the XFree86 CVS; it's worked
well enough that I haven't even bothered to try 4.2
(which was released about a month later).
I did have to add some mode lines to XF86Config, but I
don't recall having much problem getting it going.
The server has only crashed twice (and FreeBSD has never
crashed) even though I use the laptop for several hours
a day.
Just FYI, I'm writing this on a Compaq 2700T laptop
with 1600x1200 resolution, on-screen.
(It's running XFree86 on FreeBSD.)
Yes, things do look a bit tiny at that resolution
on a 15" screen, but the sharpness of
the LCD partially makes up for that.
A UXGA was pretty much a requirement (so I could
duplicate my desktop's screen layout) as well
as the ability to run FreeBSD and Linux.
I got a Compaq because I could get a discount;
they're hardly the only ones with UXGA displays.
It mystifies me that laptops with 1600x1200 screens
are available, but no desktop LCD monitors smaller
that 19" seem to do that resolution (and those that
do cost more than my entire laptop).
CNET had an
article
on this yesterday.
In brief, Yahoo! split their
Marketing Preferences into a bunch of categories, and
defaulted the new categories to opted-in.
They are mailing out notices (a process that will take
a few weeks) telling people about the new preferences.
They then have 60 days to opt-out.
What makes more sense: learning a long list of facts
concerning each of a long list of algorithms, or
learning the much smaller number of principles
behind the algorithms themselves?
The latter sort of knowledge -- "deep" knowledge --
is harder to acquire, but it is a much more useful
form of learning than the rote memorization of facts.
With it, you'll have the insight to evaluate the
suitability of an algorithm without dredging up
a long list of memorized do's and don't's.
Understanding an algorithm lets you adapt it rather than
using it blindly.
For example, the same principle of partitioning that's
behind quicksort also yields fast algorithms for
finding the top N items in a large list without
having to sort the entire list.
It also allows you to adapt quicksort to work on
linked lists without first copying them into an array.
There are dozens of variations of the principles
behind quicksort that have potential uses --
variations you're not likely to find in a library.
(I only chose quicksort because some many posts here
mention it; most algorithms have similar mutability.)
If you don't understand the principles behind what
you do, you've no right to call yourself an "engineer."
-Ed
You're kidding yourself
on
Deep Algorithms?
·
· Score: 4, Insightful
That's a bit like saying that there is no need to
understand calculus because Newton and company
already figured it out for you.
To the professional programmer an
algorithm is a tool, and like any other kind
of tool it is important to know how it works even if
you didn't invent or produce it yourself.
This may suddenly dawn on you when you're coding an
algorithm out of a book, and find you don't know whether
it's
safe to take a particular shortcut or not because
you don't understand the algorithm well enough to
analyze the implications.
Or you're looking at some values in a debugger and
can't figure out if they're correct or have been
clobbered by a bug because you don't understand the
algorithm well enough.
And so on.
-Ed
Re:LOTR won Best Film & Best Director...
on
LoTR Takes 4 Oscars
·
· Score: 2
I think Howard deserved an Oscar for Apollo 13 -- which
was a much better film than ABM.
But he didn't get one that year.
The Acadamy
seems to carry an unofficial scorecard over who is "owed"
an Oscar, and sometimes awards them for inferior work to
correct for what is felt to be a past oversight.
I suspect this might have been a factor in nudging things
Ron's way (along with the fact that he is a pretty
popular guy in Hollywood, having literally grown up
in the "industry").
Actually, they were right, more or less, and you
were wrong.
Creative themselves claimed that the SoundBlaster was
Roland MPU-401 compatible.
You see, the MPU-401 isn't a synth, as you seem to
have thought.
It's a MIDI interface -- a device for transmitting
and receiving MIDI signals from a synth -- nothing more.
"General MIDI" is a standard (or rather a series of
standards) mapping a predefined list of synthesized
instruments onto MIDI, and standardizing how they are
selected and mapped to MIDI channels.
It has noting whatever to do with Roland MPU-401
compatibility.
I said they were "more or less" right since in fact
the SoundBlaster was only comparable to an MPU-401
running in "dumb UART" mode, and even then it had
a lot of glitches (lost interrupts and so forth) and
required a special cable (that was usually not part
of the package).
A real MPU-401 had a "smart" mode where it actually
queued and timed MIDI events for you, freeing the
computer from performing these tasks.
It had 3 DIN-5 MIDI connectors (in/out/thru) right
on the interface box (which was separate from the
card). I still own one (though I haven't used it
in years).
Of course, an honest saleman would have seen your
confusion between "General MIDI" and "Roland MPU-401"
and informed you of the difference, rather than
exploiting it to make a sale. Or perhaps the
salesman only knew the phrase "Roland MPU-401 compatible"
and was too ignorant to know that your desire for
"General MIDI" was an unrelated requirement.
In any case, a little knowledge, as the platitude
says, is a dangeous thing.
In those cases where you do have to have two people
work on the same code at the same time, seat them
elbow-by-elbow.
If a bunch of people need to work on the same code,
move their workstations into a conference room.
When the crunch is over, go back to your normal
work areas and vow to plan better on the next
project.
That's the 4.4BSD license, a license that predates
FreeBSD (and the other open-source BSDs).
It contains the dreaded "advertising clause,"
which is (IMHO) rightfully viewed as non-free.
That's why FreeBSD uses
this license
which drops the advertising clause and
is almost universally viewed as a free
license;
the other open-source BSDs did the same thing.
This might even help explain (aside from
GPL paranoia) why Microsoft chose FreeBSD.
Your sources and my sources agree 100%.
At the time, Yahoo! had less than half
the FreeBSD systems as HotMail, even though
it was handling a lot more traffic.
One reason HotMail had so many
FreeBSD boxes is that Microsoft wouldn't
allow them to do any new FreeBSD development,
so they were still running a horribly inefficient
CGI-based architecture.
So they added boxes instead of improving the
existing systems to handle the load.
Still, a number of their developers stuck around
and worked on the Windows 2000 rearchitecture.
Thus Microsoft has a number of developers who
know both FreeBSD and Windows 2000.
It would make sense if some of them went on
to work on "Rotor."
Actually, the CURRENT (5.0) branch of FreeBSD supports
ACPI just fine.
They aren't back-porting it to STABLE (4.x)
because there have been too many other changes
to the kernel that make it a major effort.
I might also add that this use of the term
"open source" for non-clandestine intelligence
info goes back at least as far as WW-II and
probably earlier than that. RMS wasn't even
a twinkle in his father's eye at that point...
So, if anything, it's the software community
that misused the term (not that it makes any
practical difference, though I wonder if this
article would even have been posted without a
misunderstanding of what "open source" meant --
it's not typical Slashdot fare).
A 128-bit address space would be huge! (I suspect
you meant "7-bit address" or "128 location.")
I think you're being over-pedantic.
True, you had to use two words to access an
arbitrary location in the 4K-word
address space, but
it still took only a single instruction.
It's not like you had to fool around with
segment registers or bank switching.
(Recall that it took two instructions just to
load from a memory location -- CLR and TAD -- so
a single instruction with indirection is
hardly heavyweight.)
I could also argue that the page-zero bit
was an address bit, but then I'd
be thw one who is over-pedantic.
That said, your memory of the PDP-8 agrees 100%
with mine.
It's utterly amazing what could be done with
such a tiny instruction set and a single
register plus one flag bit (the "link").
virii would definitely fall under the category of 'interactive digital devices'
That makes no sense whatsoever.
An "interactive digital device" is a piece of
hardware, as defined by the SSSCA.
Unless you know something about computer viruses
that I don't, they hardly qualify as such.
Even as software, they are highly unlikely to
contain the likely-to-be mandated digital
signature.
And that's the scary part: Microsoft
is promoting digital rights management as
an anti-virus solution (among other things).
Part of the.NET infrastructure is providing the
ability of each software component to be signed.
Thus the SSSCA dovetails quite nicely with
Microsoft's need for better security.
And it gives them the opportunity to get even
more leverage over non-Microsoft software
(not just virunses). Who do you think will
control the certification process necessary to
get a signature?
Just my opinion, as someone who's been here
a while: It isn't the frequent posters
that make Slashdot worth reading to me.
They're a bunch of fast-typing know-it-alls
who could be replaced by AI programs for all
I care.
It's the folks who wait until a particular
subject comes up that they actually have
something to say about, something that
their experience or education makes
especially relevent to them -- and, frequently,
to us.
The sad thing is that the hyper-posters usually
get there first, and are the ones who get all
the mod points before the moderators get tired
of scrolling or move on to the next topic.
So I'm happy that the hyper-posters will start
to "pay" for the privilege of publishing their
mildly-original but ultimately vacuous screeds.
A significant amount of the money that the
Defense Advanced Research Projects Agency
(the folks who paid for the ARPANET) spent
on Artificial Intelligence in the '70's and
'80's was to projects that purported to
model military decision-making.
Later in this period the Defense office of
Net Assessment got into the act, funding
some efforts to combine models of military
forces with command-and-control models and
rule-based decision systems.
At least one of these efforts endeavored to
create a system where humans and computer
agents interacted in a wargame involving
all these elements: the RAND Strategic
Assessment System, developed in the mid
1980's.
RAND was only one of many in using modeling and
simulation for military policy analysis; MITRE
and SAIC were among the others.
At the other end of the spectrum (and probably
of more interest to gamers) was the SIMNET
effort, a distributed battlefield simulation
system started in the early 1990's which employed
3-D graphics, multichannel sound, and a large
collection of (military) hardware models,
often involving several geographically
separated computational nodes and human players.
This is actually of far less interest from a
policy perspective (unless your idea of
"policy" involves low-level military tactics)
but is a lot closer to what most people think
of as computer gaming.
(Yes, I worked on projects like these back oh
so many years ago...
I left that world about the time it was
starting to focus on terrorism and
"light-intensity conflict."
Little did I know how prescient some of
those
scenarios were in light of recent events in
Afghanistan.)
That's the Linux NFS HOWTO.
Although it gives some good background on NFS
(and in more depth than the article
discussed here) it's pretty Linux-specific
when it comes down to the actual setup process.
It's not going to give you any FreeBSD-specific
information, and so is of limited usefulness in
setting up for that system.
I'm amazed that a comment that's arguably
off-topic gets modded up twice as "Informative,"
but this is, after all, Slashdot.
I don't think they're tracking Linux's feature set
any more deliberately than Linux is tracking
Solaris' feature set.
For example, FreeBSD's next-generation SMP may
put it roughly on the same level as Linux 2.4,
but the need to improve SMP exists independent
of Linux and the methods used (at least at the
detailed level) are quite a bit different than
Linux's.
That's not to say that FreeBSD developers are
ignorant of Linux; a few committers even are
on the Linux Kernel Mailing List.
But like any open source project, features get
added to "scratch an itch," and ideas can come
from anywhere.
So if something like kqueue or
jail seems like a good idea to someone,
whether it is in Linux or not makes no difference;
if code exists and core likes it, it gets added.
Just casually skimming the freebsd-arch
and freebsd-current mailing lists, I'd say
that features from the other BSD's, especially
NetBSD, get discussed more than Linux.
But the latter does get discussed, both as a
source of ideas and experiences.
(Unlike what some folks here claim, few FreeBSD
developerss are
knee-jerk Linux haters.
That's not to say such folk don't exist; FreeBSD
doesn't give personality tests to prospective
developers or committers.
As always, the code's the thing.)
The amazing thing about the first touch-tone
dial is that it used a single germanium
transistor to generate both tones. (Transistors
were pretty expensive at the time.) Let's see
some of today's EE's figure out how to do that!
But back to punch cards; one of the reasons
old farts can get misty-eyed over such obviously
inferior technologies is that, in some respects,
it's damned impressive that they worked so well.
A card reader that can read more than
a hundred cards a
second is a remarkable piece of machinery, and is
impressive to see (and hear -- they're
loud!) even today.
Sure, a CF card smaller than my thumb holds
670 times more data than the 5000-card trays
that they fed into these monsters.
But computing has lost the visceral element
it once had,
and from a mechanical engineering standpoint
is a lot less impressive.
Slashdot Mirror
Hmmm... So, does this mean that a ham radio operator can force people not to use microwave ovens, which also use the 2.4GHz band (and, last time I checked, weren't licensed either)? "Excuse me, ma'am, but I'm confiscating your microwave as an illegal transmitter. Your ham radio operator neighbors have been complaining."
A lot of them are trash -- probably most. I (unitentionally) have some experience with that. You may be next.
One of the SPAM generators out there seems to take the mailing list in batches, using the first name of a batch as the "From:" address and the rest as the "To:" addresses. This has two rather evil effects: the first address gets (1) bounce notices and (2) complaints.
I was the unlucky victim of this program a few days ago. I got about ten bounce messages, some of them for a half dozen or so bad addresses (the program was smart enough to group messages by receiving domain), for about 30 bogus addresses in all. But I only got one complaint...
Balderdash.
Slashdot's "BSD is dying" troll is notorious -- there are few people in the open-source community who haven't seen or heard of those posts. Mike's use of the troll in a rhetorical device is natural; he's simply saying that even though he and Jordan are "dying" parts of FreeBSD, FreeBSD goes on. (I suspect that his reference to the troll is also making a dig at the people he blames for making his life on core miserable by tying them to the "Slashdot crowd.")
FreeBSD is making steady progress on a variety of fronts. Mike's complaint isn't that FreeBSD itself is dying, or broken. It's that the project's governance is broken, and that far too much time is spent arguing petty matters with little effect beyond making the participants unhappy.
There is one way that Mike's leaving is a Good Thing, in that it will trigger a core election. That may go some ways toward solving the problem.
All you've made clear is your willingness to stretch a point beyond all reasonableness.
Theo is merely exercising the right that all BSD folk assume: that you can take the BSD code and make a product out of it and sell it for whatever you like. Of course, the code itself remains unencumbered, so someone else can take it and make a product out of it and give it away, or sell it for a different price, perhaps after changes or additions. They just can't exactly duplicate Theo's organization ("compilation" is the legal term, I believe) or packaging -- his "product."
BSD and GNU folks can argue all day over their respective ideas of freedom, and over which model is more "free." I don't want to argue that issue here (I frankly don't think it can ever be effectively settled), but merely point out that you're making a distinction that BSD doesn't consider valid. And that's why your argument just doesn't have much traction here, although in the GNU/Linux world it may.
Nothing prevents you from making your own ISO image and giving it away or even selling it. You just can't take the lazy way out and make bit-for-bit copies of the distribution CD's.
So, install mkisofs and go at it. You might even learn something. Saying you "can't share it easily" is a confession of laziness or incompetence, or both. (Another word that comes to mind is "ingratitude.")
Actually, the video chip (which is identified by the server as an ATI Radeon Mobility M6 LY rev 0) wasn't yet supported by XFree86 4.1, so I built a snapshot of the XFree86 CVS; it's worked well enough that I haven't even bothered to try 4.2 (which was released about a month later). I did have to add some mode lines to XF86Config, but I don't recall having much problem getting it going. The server has only crashed twice (and FreeBSD has never crashed) even though I use the laptop for several hours a day.
Just FYI, I'm writing this on a Compaq 2700T laptop with 1600x1200 resolution, on-screen. (It's running XFree86 on FreeBSD.) Yes, things do look a bit tiny at that resolution on a 15" screen, but the sharpness of the LCD partially makes up for that.
A UXGA was pretty much a requirement (so I could duplicate my desktop's screen layout) as well as the ability to run FreeBSD and Linux. I got a Compaq because I could get a discount; they're hardly the only ones with UXGA displays.
It mystifies me that laptops with 1600x1200 screens are available, but no desktop LCD monitors smaller that 19" seem to do that resolution (and those that do cost more than my entire laptop).
CNET had an article on this yesterday. In brief, Yahoo! split their Marketing Preferences into a bunch of categories, and defaulted the new categories to opted-in. They are mailing out notices (a process that will take a few weeks) telling people about the new preferences. They then have 60 days to opt-out.
Like I said, you're only kidding yourself.
What makes more sense: learning a long list of facts concerning each of a long list of algorithms, or learning the much smaller number of principles behind the algorithms themselves? The latter sort of knowledge -- "deep" knowledge -- is harder to acquire, but it is a much more useful form of learning than the rote memorization of facts. With it, you'll have the insight to evaluate the suitability of an algorithm without dredging up a long list of memorized do's and don't's.
Understanding an algorithm lets you adapt it rather than using it blindly. For example, the same principle of partitioning that's behind quicksort also yields fast algorithms for finding the top N items in a large list without having to sort the entire list. It also allows you to adapt quicksort to work on linked lists without first copying them into an array. There are dozens of variations of the principles behind quicksort that have potential uses -- variations you're not likely to find in a library. (I only chose quicksort because some many posts here mention it; most algorithms have similar mutability.)
If you don't understand the principles behind what you do, you've no right to call yourself an "engineer."
That's a bit like saying that there is no need to understand calculus because Newton and company already figured it out for you.
To the professional programmer an algorithm is a tool, and like any other kind of tool it is important to know how it works even if you didn't invent or produce it yourself.
This may suddenly dawn on you when you're coding an algorithm out of a book, and find you don't know whether it's safe to take a particular shortcut or not because you don't understand the algorithm well enough to analyze the implications. Or you're looking at some values in a debugger and can't figure out if they're correct or have been clobbered by a bug because you don't understand the algorithm well enough. And so on.
I think Howard deserved an Oscar for Apollo 13 -- which was a much better film than ABM. But he didn't get one that year.
The Acadamy seems to carry an unofficial scorecard over who is "owed" an Oscar, and sometimes awards them for inferior work to correct for what is felt to be a past oversight. I suspect this might have been a factor in nudging things Ron's way (along with the fact that he is a pretty popular guy in Hollywood, having literally grown up in the "industry").
Actually, they were right, more or less, and you were wrong. Creative themselves claimed that the SoundBlaster was Roland MPU-401 compatible. You see, the MPU-401 isn't a synth, as you seem to have thought. It's a MIDI interface -- a device for transmitting and receiving MIDI signals from a synth -- nothing more.
"General MIDI" is a standard (or rather a series of standards) mapping a predefined list of synthesized instruments onto MIDI, and standardizing how they are selected and mapped to MIDI channels. It has noting whatever to do with Roland MPU-401 compatibility.
I said they were "more or less" right since in fact the SoundBlaster was only comparable to an MPU-401 running in "dumb UART" mode, and even then it had a lot of glitches (lost interrupts and so forth) and required a special cable (that was usually not part of the package). A real MPU-401 had a "smart" mode where it actually queued and timed MIDI events for you, freeing the computer from performing these tasks. It had 3 DIN-5 MIDI connectors (in/out/thru) right on the interface box (which was separate from the card). I still own one (though I haven't used it in years).
Of course, an honest saleman would have seen your confusion between "General MIDI" and "Roland MPU-401" and informed you of the difference, rather than exploiting it to make a sale. Or perhaps the salesman only knew the phrase "Roland MPU-401 compatible" and was too ignorant to know that your desire for "General MIDI" was an unrelated requirement. In any case, a little knowledge, as the platitude says, is a dangeous thing.
Who needs acrobat? Xpdf renders the article Just Fine. In fact, it works well on most of the PDF I find around the web.
In those cases where you do have to have two people work on the same code at the same time, seat them elbow-by-elbow. If a bunch of people need to work on the same code, move their workstations into a conference room.
When the crunch is over, go back to your normal work areas and vow to plan better on the next project.
That's the 4.4BSD license, a license that predates FreeBSD (and the other open-source BSDs). It contains the dreaded "advertising clause," which is (IMHO) rightfully viewed as non-free. That's why FreeBSD uses this license which drops the advertising clause and is almost universally viewed as a free license; the other open-source BSDs did the same thing.
This might even help explain (aside from GPL paranoia) why Microsoft chose FreeBSD.
Your sources and my sources agree 100%. At the time, Yahoo! had less than half the FreeBSD systems as HotMail, even though it was handling a lot more traffic. One reason HotMail had so many FreeBSD boxes is that Microsoft wouldn't allow them to do any new FreeBSD development, so they were still running a horribly inefficient CGI-based architecture. So they added boxes instead of improving the existing systems to handle the load.
Still, a number of their developers stuck around and worked on the Windows 2000 rearchitecture. Thus Microsoft has a number of developers who know both FreeBSD and Windows 2000. It would make sense if some of them went on to work on "Rotor."
Actually, the CURRENT (5.0) branch of FreeBSD supports ACPI just fine. They aren't back-porting it to STABLE (4.x) because there have been too many other changes to the kernel that make it a major effort.
I might also add that this use of the term "open source" for non-clandestine intelligence info goes back at least as far as WW-II and probably earlier than that. RMS wasn't even a twinkle in his father's eye at that point... So, if anything, it's the software community that misused the term (not that it makes any practical difference, though I wonder if this article would even have been posted without a misunderstanding of what "open source" meant -- it's not typical Slashdot fare).
A 128-bit address space would be huge! (I suspect you meant "7-bit address" or "128 location.")
I think you're being over-pedantic. True, you had to use two words to access an arbitrary location in the 4K-word address space, but it still took only a single instruction. It's not like you had to fool around with segment registers or bank switching. (Recall that it took two instructions just to load from a memory location -- CLR and TAD -- so a single instruction with indirection is hardly heavyweight.) I could also argue that the page-zero bit was an address bit, but then I'd be thw one who is over-pedantic.
That said, your memory of the PDP-8 agrees 100% with mine. It's utterly amazing what could be done with such a tiny instruction set and a single register plus one flag bit (the "link").
That makes no sense whatsoever. An "interactive digital device" is a piece of hardware, as defined by the SSSCA. Unless you know something about computer viruses that I don't, they hardly qualify as such.
Even as software, they are highly unlikely to contain the likely-to-be mandated digital signature. And that's the scary part: Microsoft is promoting digital rights management as an anti-virus solution (among other things). Part of the .NET infrastructure is providing the
ability of each software component to be signed.
Thus the SSSCA dovetails quite nicely with
Microsoft's need for better security.
And it gives them the opportunity to get even
more leverage over non-Microsoft software
(not just virunses). Who do you think will
control the certification process necessary to
get a signature?
Just my opinion, as someone who's been here a while: It isn't the frequent posters that make Slashdot worth reading to me. They're a bunch of fast-typing know-it-alls who could be replaced by AI programs for all I care. It's the folks who wait until a particular subject comes up that they actually have something to say about, something that their experience or education makes especially relevent to them -- and, frequently, to us. The sad thing is that the hyper-posters usually get there first, and are the ones who get all the mod points before the moderators get tired of scrolling or move on to the next topic.
So I'm happy that the hyper-posters will start to "pay" for the privilege of publishing their mildly-original but ultimately vacuous screeds.
A significant amount of the money that the Defense Advanced Research Projects Agency (the folks who paid for the ARPANET) spent on Artificial Intelligence in the '70's and '80's was to projects that purported to model military decision-making. Later in this period the Defense office of Net Assessment got into the act, funding some efforts to combine models of military forces with command-and-control models and rule-based decision systems. At least one of these efforts endeavored to create a system where humans and computer agents interacted in a wargame involving all these elements: the RAND Strategic Assessment System, developed in the mid 1980's. RAND was only one of many in using modeling and simulation for military policy analysis; MITRE and SAIC were among the others.
At the other end of the spectrum (and probably of more interest to gamers) was the SIMNET effort, a distributed battlefield simulation system started in the early 1990's which employed 3-D graphics, multichannel sound, and a large collection of (military) hardware models, often involving several geographically separated computational nodes and human players. This is actually of far less interest from a policy perspective (unless your idea of "policy" involves low-level military tactics) but is a lot closer to what most people think of as computer gaming.
(Yes, I worked on projects like these back oh so many years ago... I left that world about the time it was starting to focus on terrorism and "light-intensity conflict." Little did I know how prescient some of those scenarios were in light of recent events in Afghanistan.)
That's the Linux NFS HOWTO. Although it gives some good background on NFS (and in more depth than the article discussed here) it's pretty Linux-specific when it comes down to the actual setup process. It's not going to give you any FreeBSD-specific information, and so is of limited usefulness in setting up for that system.
I'm amazed that a comment that's arguably off-topic gets modded up twice as "Informative," but this is, after all, Slashdot.
I don't think they're tracking Linux's feature set any more deliberately than Linux is tracking Solaris' feature set. For example, FreeBSD's next-generation SMP may put it roughly on the same level as Linux 2.4, but the need to improve SMP exists independent of Linux and the methods used (at least at the detailed level) are quite a bit different than Linux's. That's not to say that FreeBSD developers are ignorant of Linux; a few committers even are on the Linux Kernel Mailing List. But like any open source project, features get added to "scratch an itch," and ideas can come from anywhere. So if something like kqueue or jail seems like a good idea to someone, whether it is in Linux or not makes no difference; if code exists and core likes it, it gets added.
Just casually skimming the freebsd-arch and freebsd-current mailing lists, I'd say that features from the other BSD's, especially NetBSD, get discussed more than Linux. But the latter does get discussed, both as a source of ideas and experiences. (Unlike what some folks here claim, few FreeBSD developerss are knee-jerk Linux haters. That's not to say such folk don't exist; FreeBSD doesn't give personality tests to prospective developers or committers. As always, the code's the thing.)
The amazing thing about the first touch-tone dial is that it used a single germanium transistor to generate both tones. (Transistors were pretty expensive at the time.) Let's see some of today's EE's figure out how to do that!
But back to punch cards; one of the reasons old farts can get misty-eyed over such obviously inferior technologies is that, in some respects, it's damned impressive that they worked so well. A card reader that can read more than a hundred cards a second is a remarkable piece of machinery, and is impressive to see (and hear -- they're loud!) even today. Sure, a CF card smaller than my thumb holds 670 times more data than the 5000-card trays that they fed into these monsters. But computing has lost the visceral element it once had, and from a mechanical engineering standpoint is a lot less impressive.