Re:Linus calls Linux "idiotic", "broken" and "unst
on
BSDCon Europe 2001
·
· Score: 1
If you check the
current
Netcraft survey, you'll find a breakdown by
OS that puts the BSD's a bit behind Solaris
at about 6.3% (vs. 7.6%), with Linux at 28.5%.
More relevant to the topic, I'd be very
interested if Netcraft did a breakdown by country
or region both for OS and Server.
It would give an idea of just how popular BSD
(for example) is in Europe as a server platform.
Of course, attendance at conferences like these
is another measure, but independent verification
of the interest level helps to show whether
the conference is getting its message out or not.
What you ask for already exists.
They're called "ports," and there is also
talk of unified ports.
(OK, well here are a few ports that are partly
or wholy binaries, but for the most part the
port mechanism is for fetching and building
sources; you can take days perusing the
source between a "make" and a "make install"
if you like.)
I've built many a program from plain tarballs
and even separately fetched source files.
I see no reason for people to get "used"
to such things again when there are mechanisms
that make it much less likely to compromise
security by misunderstanding a configuration
option or to waste lots of time puzzling over
include file dependencies and so on.
I think that in most cases, source browsing is
among the least efficient uses of time in
securing a system.
If you assume from the start that the software
will have bugs, and configure and compartmentalize
it accordingly, you'll be miles ahead.
Tens of thousands of people built sendmail and
bind from source tarballs but serious security
bugs still lurked unfound in both for years.
What makes you think you'd be so much better
at finding them?
I know I'm not.
That's why I employ wrappers, packet filters,
chroot() and jail(), router ACLs, physical
access controls, and so forth and so on.
In any case, pre-built tools aren't the answer
for security, either; they're just another
option, with its own tradeoffs.
In the struggle to make the best use of my time,
they can be most welcome.
I suspect they know a hell of a lot more
about nonlinear dynamics (including "chaos
theory") than you do.
For instance, turbulent flows are generally
chaotic, making it impossible to predict the
path of a given particle for more than a brief
amount of time.
On the other hand, the resultant mixing can be
easy to study statistically on a larger scale,
and it is entirely
possible that the longer the model runs the more
accurate the aggregate results.
Stated differently, it is entirely possible
(even likely) that a system that is divergent
when modeled on a small scale is convergent
when modeled on a large scale.
Climatological modelers were among the first
to realize the implications of Lorentz's
results.
They, and most other scientists in fields
involving nonlinear dynamics, have spent the
last three decades digesting and incorporating
both the results spawned by his discovery,
and earlier "forgotten" results like those
of Poincaré.
That's not to say all climatologists
have sufficient understanding of chaos, but
the community as a whole has long been aware
of it.
As to the politics of the situation: just
follow the money -- as usual.
No, the highway patrol generally uses lines
perpendicular to the direction of travel; these
are frequently drawn to the side of the pavement
and occur in pairs.
They are usually found on well-traveled roads in
relatively rural areas, and are on straight
sections of road.
Aerial survey markers have lines at right angles
to each other and often as not
are in the middle
of the pavement and aren't necessarily aligned
in any way with the direction of travel.
They are generally not found in pairs,
and can appear on curves.
You're absolutely right.
Their "benchmark" is perfectly valid,
for their product running on
a naively tuned
operating system.
But only a neophyte would put an out-of-the-box
OS -- whether Linux, Solaris, Windows, or BSD --
into production as a high-performance network
server.
All the complaining boils down to two things:
The article asserts that performance
of a single bulk-email program is a valid way
to rank the four OSes, and
Ignores the system tuning that a competent
system administrator would have performed.
The FreeBSD folks are especially upset because
the article states that the OS was logging resource
failures but the testers still didn't
perform any tuning.
That's an amazing level of incompetence to
display in a magazine which is supposed to inform
system administrators.
'Tis true, bulk emailers don't
necessarily
need to be used for SPAM,
so perhaps someone felt that was "flamebait."
Ordinarily, I'd have cut Lyris some slack, but it
seemed pretty dishonest that their CEO and
Technical Manager would write an article
comparing the performance of their product
on several OSes and claim it was a useful
measure of OS performance.
That's a clear conflict of interest, and
pushes the benchmark fallacy one step
further; benchmarks at least can claim to
be somewhat application-neutral (which is why they
should be taken with a large grain of salt
in predicting the performance of any
particular application).
This "benchmark" measures just one thing, and
that's the performance of a particular product
on four (nearly) untuned OSes.
That's all.
The stuff on multithreading/multitasking/async
was pretty much fluff, generated via undocumented
microbenchmarks plus variants of their application
and reported using a few vague percentages.
Agreed -- it's been a long time since I've
seen a "benchmark" as poor as this one.
But I don't think Windows was treated any
more poorly than the other OSes.
It wasn't a fair test of any of them.
The "tuning" for the Unix systems consisted in
bumping up the maximum number of file descriptors.
That's it.
The FreeBSD system in particular was left
completely mistuned and clearly running out of
socket resources -- they report that it was
logging errors but seem entirely ignorant of
what those errors were (beyond their being
load-related) and how to correct them.
Polling is hardly the best system interface
for multiplexing TCP connections on either
Windows or FreeBSD.
As you mention, completion ports are best for
Windows.
Kqueue is best for FreeBSD.
It just happens that polling is used in
the crappy commercial
SPAM program they "benchmarked".
(All the OSes support scatter/gather, BTW, so you
can't claim Windows was treated unfairly by its
omission.)
None of the systems were testing in a way that
shows their actual capabilities.
The article is just a thinly disguised
commercial for a (barely-)cross-platform
"bulk email" product.
Don't bother reading that article
unless you are interested in using Lyris'
close-sourced SPAM-generating software.
The sum total of their "benchmark" consists
of SPAMming 200,000 copies of the same message
to a list of email addresses.
They didn't know the first thing about
configuring their Unix systems (bumping up the
maximum number of file descriptors--the only
tuning they did--does NOT increase the maximum
number of simultaneous connections, and it was
clear that FreeBSD especially suffered from
resource starvation as a result of
misconfiguration).
They didn't actually compare the various
paradigms (single/multiple thread,
single/multiple process, async/sync I/O).
No, they just tell you which O/S, naively
configured, pumps out SPAM the fastest.
This is not the place to go to see how
threaded/non-threaded solutions compare.
It's a thinly-disguised commercial for a
"bulk email" product.
Something you might find interesting:
at one time the worlds largest repository of
free and open-source software was at the
(then) Army
Ballistic Research Laboratory, open to
anyone who could FTP there.
It was an important resource during the 1980's
when the free software community, a community
that included the late
Mike Muuss of the BRL,
was taking shape.
This is only one example of many from that era.
(I hope it's not too trivial to point out that
the Internet itself originated with the
"War Pigs.")
Had the GPL included an anti-military clause,
there is a good chance that much of GNU would
not exist -- if the movement had happened at all.
Don't forget, the "War Pigs" paid for Stallman's
ARPANET connection (via MIT, which was on the
ARPANET by virtue of being a major military
contractor).
I'm not attempting to justify the military,
here, just pointing out that blindly excluding
them may not be the best of ideas...
Curious though why it only offers Windows CE and Linux, and not
the full blown version of Windows.
Probably because Windows only runs on the i386
architecture and not StrongARM.
WinCE, like Linux, does run on that chip
(as does NetBSD, though probably not on this
specific box).
Maybe it's slow enough that loading something other than CE might turn it into a
real paperweight
Actually, I'd expect it to be pretty snappy,
probably about as fast as a 200MHz Pentium.
Of course, 32MB RAM and only a 16MB Flash as
a storage device keeps it from being generally
useful, but the StrongARM is a pretty powerful
chip, especially
considering its low power requirements.
Sure, wanting to see your efforts find wide
use is a worthy goal, but what the other posters
were saying implied that other goals -- such as
a satisfying technical challenge -- weren't
significant.
I never said that usefulness and marketability
were to be avoided.
But unlike Microsoft (and most other commercial
software companies), the BSD and Linux efforts
have other goals which are often as important or
more important than shear commercial heft.
One of the primary goals of
NetBSD is a generally portable architecture
-- an emphasis
that distinguishes it from the other BSD's.
Even a port to an otherwise "useless"
achitecture can enhance that generality.
So it can be argued that an effort like this
contributes to NetBSD's usefulness.
But this (as well as your post) misses my
point: the hacker asthetic can be orthogonal to
utility.
Almost anyone who loves to program as an
activity (and not just a way to make money)
will understand this.
What shocked me was that none of the Slashdotters
responding tho this article seemed to have such
an understanding.
This is one of the best "how to do it"
articles I've read in a long time.
It's not just a technical description of
NetBSD's Linux emulation system.
It's a developer's-eye view of how it was
created, a detailed description of the
process and not just a laundry list
of steps.
The article would be useful reading to anyone
doing systems-level development even if they
never intend to touch NetBSD, both as an
example of how to approach the extension of an
existing system and as an excellent example
of how to write about it.
I don't use NetBSD or PPC, and I still found the
article absorbing and useful.
Check it out and see if you don't agree.
Sometimes the highest mountains are also the
oldest.
A hacker doesn't need to ask "why?"
and doesn't worry about "what use is it?"
Hackers know:
it's the sheer pleasure of
creating, of exploring uncharted territory,
of building up clever solutions and finally
emerging victorious over the challenge.
If wide usefulness ane marketability are your
goals, go join Microsoft -- they're their goals,
too.
I think the responses to this post make it
pretty damn clear that few Slashdot
posters are hackers anymore.
If you want to be picky, Patrick utterly
failed the challenge
by not supplying compressed files.
They were simply unaltered
pieces of the original file.
Sure, there were missing bits of the files
that had been moved to the file names, but
the fact that this slight of hand failed
to compress the data can be proved simply
by renaming the files.
Even if the order of files supplid to the
"decompressor" is preserved, renaming them
renders the original data unrecoverable.
Sure, moving data into the filename is
a cute trick, but it isn't compression.
The goal of the challenge is to produce
compression, not to win via some semantic
shell game.
It's Patrick who shed his honor by resorting
to a semantic smoke screen and attempting to
win by wordplay with no intention of actually
producing any real compression.
Don't you know porting NetBSD to
video game consoles and scientific calculators
and other crap will help it make many inroads
with major corporations and increase it's
legitimacy as a enterprise ready operating
system...
Actually, it does help make such inroads, but
it's as an embedded OS, not an "enterprise"
OS.
Even the NetBSD folks will admit they aren't
really shooting for the latter.
But porting to "video game consoles and
scientific calculators" proves how versatile
NetBSD is as an embedded platform.
Alphas are used in high-end embedded systems
such as those used for industrial and medical
imaging, since they still beat Pentiums
two-to-one or better in the computations
involved in such tasks.
And to reach the useful memory and I/O
bandwidth of
recent Alpha systems, you have to use exotic
chipsets with Pentiums, which can offset
some or all of their price advantage.
Wind River's purchase of BSDi suggests an
important trend for the BSD's into the embedded
market, a market that is expected to exceed
the enterprise market in value in the years to
come.
Given Linux's problems in this area (lack of
an integrated userland and what is often perceived
as a corporation-unfriendly license)
the BSD's have a pretty good shot at becoming open-source solutions for embedded systems.
You missed my point.
Not everyone who writes scripts is aware of the
difference between "<" and -lt.
Does your sysadmin know the difference?
I've met some who don't.
There is another 999999999 rollover problem.
Some admin scripts (in BASH, PERL, etc.)
assume that the decimal timestamp
can be compared as an ASCII string.
Unfortunately, 999999999 > 1000000000 in
this case, which can cause such scripts to
break in subtle or overt ways.
For example, if TS1=999999999 and TS2=1000000000,
the BASH statement:
Just a wild-ass guess, but I'd assume Yahoo!
pays at least $0.10-$0.20 for the average call
to this service.
There is no way to support that with ad revenue,
even in the best of times, even at rates
several times that of similar media (such as
radio).
On the other hand,
you can serve hundreds or thousands
of customers via the web for the same money.
You could probably pay for it with ad revenue
even in the current depressed ad market.
Don't read too much into this.
Free 800 number service wouldn't have lasted
that long even if the dot-com phenomenon hadn't
imploded.
One other reason why Linus and others might
have been staying away from BSD was the whole
legal morass it was involved in at the time.
Who would want to spend time on a project which
might well be declared contraband if AT&T's
lawsuit against Berkeley succeeded?
Well, it's much better organized, for starters.
And if the author continues to take interest
in it, it will be more up-to-date than any
search engine as well.
Google sucks somewhat less than other search
engines, but it still has problems with dead
links or live links to stale pages.
The pages it returns are organized by past
popularity and not necessarily relevence to
a particular issue.
Someone involved in the OpenBSD community
can update a page such as this immediately
when new information appears, and prune out
old links as needed.
He can provide nested table-of-contents
and succinct descriptions of the listed pages.
Google can take weeks to spot a new resource,
and even longer to forget about a once-popular
resource that has been superceded or removed.
The text excerpts provided by Google often are
of little help in deciding whether a link
is relevent.
Humans, especially humans with knowledge and
interest in a particular area, create much
more useful lists.
This page looks like a good start for someone
wanting to learn about OpenBSD,
complementing the openbsd.org site.
I predict that it won't be too long before it's
one of the first results returned from your
Google query.
There are other causes as well.
For example, people who have set up a web site
on GeoCities, Xoom, or wherever frequently make
copies of their site by saving pages with
their browser.
This includes any code that was inserted by
that service, whether for advertising or for
site features such as counters and statistics,
or even clip art.
When they decide to move their site to another
service they upload these copies -- including
all the stuff the old service inserted into
the pages.
As long as nothing overtly breaks, this sort
of stuff just accumulates as pages get moved
or updated.
If you're asking youself why anyone would be
so stupid, recall that all these page hosting
services provide tools for building web pages;
the average person with a web page knows little
or nothing about HTML, and so doesn't have the
slightest idea that some JavaScript appended
to their page isn't necessary, and in fact
wasn't actually part of the stored page in the
first place.
For example, GeoCities inserts a web bug to give
each user statistics concerning their web pages
and to provide an optional counter.
The bug is useless outside of GeoCities, yet I
see it fairly frequently on other services.
The same with Xoom's counter code, and so on.
I suspect in most cases the "foreign"
appearances of these bugs just represent noise
to the site of origin.
I have a much better chance of finding quality
code on SourceForge than quality music on
mp3.com.
But that's not the point.
Unlike mp3.com, which could do better without the
dreck, SourceForge needs those pre-alpha-going-nowhere
projects, because even failures can fuel ideas.
And unlike bad music, bad code can at least form
a starting point for good code.
Years ago I was a Minix fan, and ran it on my
10MHz 286.
I read comp.os.minix avidly and was pretty
sceptical when this student in
Finland announced that, because Minix's
creator didn't want to extend it to work on 386's
and support more of Unix, that he would do so,
and was anyone interested in helping.
It wasn't the first time someone had proposed
this, and if someone had asked me I'd have
said that he had little chance of success.
After all, the GNU folks had already been working
on such a project and had yet to
succeed.
I knew how hard it would be, and figured that
the most this fellow would do would be to waste
a lot of his time, and that of anyone else
who decided to help.
Of course, you know who that Finnish student
was, and what happened to his project.
But I doubt you would have given him any
better odds than I did, and would have put
him squarely in the "forever alpha"
column.
This is why SourceForge can't afford to
be too choosy as to the projects they host.
The bad ones don't take much space or bandwidth,
anyway.
Their challenge is to provide mechanisms for
the better projects to achieve visibility,
such that they don't get lost in the "noise."
But it is from that "noise" that wonderful things
may appear.
This has been done before, but not with light.
With sound!
That's right, back in the 1950's they actually
made memories from long mercury-filled tubes
conducting sound impulses.
The impulses would be amplified and "squared-up"
each time around.
They could only store a few thousand
bits that way, but you could always
have several of them running in parallel.
Slashdot Mirror
If you check the current Netcraft survey, you'll find a breakdown by OS that puts the BSD's a bit behind Solaris at about 6.3% (vs. 7.6%), with Linux at 28.5%.
More relevant to the topic, I'd be very interested if Netcraft did a breakdown by country or region both for OS and Server. It would give an idea of just how popular BSD (for example) is in Europe as a server platform. Of course, attendance at conferences like these is another measure, but independent verification of the interest level helps to show whether the conference is getting its message out or not.
What you ask for already exists. They're called "ports," and there is also talk of unified ports. (OK, well here are a few ports that are partly or wholy binaries, but for the most part the port mechanism is for fetching and building sources; you can take days perusing the source between a "make" and a "make install" if you like.)
I've built many a program from plain tarballs and even separately fetched source files. I see no reason for people to get "used" to such things again when there are mechanisms that make it much less likely to compromise security by misunderstanding a configuration option or to waste lots of time puzzling over include file dependencies and so on.
I think that in most cases, source browsing is among the least efficient uses of time in securing a system. If you assume from the start that the software will have bugs, and configure and compartmentalize it accordingly, you'll be miles ahead. Tens of thousands of people built sendmail and bind from source tarballs but serious security bugs still lurked unfound in both for years. What makes you think you'd be so much better at finding them? I know I'm not. That's why I employ wrappers, packet filters, chroot() and jail(), router ACLs, physical access controls, and so forth and so on.
In any case, pre-built tools aren't the answer for security, either; they're just another option, with its own tradeoffs. In the struggle to make the best use of my time, they can be most welcome.
I suspect they know a hell of a lot more about nonlinear dynamics (including "chaos theory") than you do. For instance, turbulent flows are generally chaotic, making it impossible to predict the path of a given particle for more than a brief amount of time. On the other hand, the resultant mixing can be easy to study statistically on a larger scale, and it is entirely possible that the longer the model runs the more accurate the aggregate results. Stated differently, it is entirely possible (even likely) that a system that is divergent when modeled on a small scale is convergent when modeled on a large scale.
Climatological modelers were among the first to realize the implications of Lorentz's results. They, and most other scientists in fields involving nonlinear dynamics, have spent the last three decades digesting and incorporating both the results spawned by his discovery, and earlier "forgotten" results like those of Poincaré. That's not to say all climatologists have sufficient understanding of chaos, but the community as a whole has long been aware of it.
As to the politics of the situation: just follow the money -- as usual.
No, the highway patrol generally uses lines perpendicular to the direction of travel; these are frequently drawn to the side of the pavement and occur in pairs. They are usually found on well-traveled roads in relatively rural areas, and are on straight sections of road. Aerial survey markers have lines at right angles to each other and often as not are in the middle of the pavement and aren't necessarily aligned in any way with the direction of travel. They are generally not found in pairs, and can appear on curves.
You're absolutely right. Their "benchmark" is perfectly valid, for their product running on a naively tuned operating system. But only a neophyte would put an out-of-the-box OS -- whether Linux, Solaris, Windows, or BSD -- into production as a high-performance network server. All the complaining boils down to two things:
The FreeBSD folks are especially upset because the article states that the OS was logging resource failures but the testers still didn't perform any tuning. That's an amazing level of incompetence to display in a magazine which is supposed to inform system administrators.
Now do you see what all the noise is about?
'Tis true, bulk emailers don't necessarily need to be used for SPAM, so perhaps someone felt that was "flamebait." Ordinarily, I'd have cut Lyris some slack, but it seemed pretty dishonest that their CEO and Technical Manager would write an article comparing the performance of their product on several OSes and claim it was a useful measure of OS performance. That's a clear conflict of interest, and pushes the benchmark fallacy one step further; benchmarks at least can claim to be somewhat application-neutral (which is why they should be taken with a large grain of salt in predicting the performance of any particular application). This "benchmark" measures just one thing, and that's the performance of a particular product on four (nearly) untuned OSes.
That's all. The stuff on multithreading/multitasking/async was pretty much fluff, generated via undocumented microbenchmarks plus variants of their application and reported using a few vague percentages.
Agreed -- it's been a long time since I've seen a "benchmark" as poor as this one. But I don't think Windows was treated any more poorly than the other OSes. It wasn't a fair test of any of them.
The "tuning" for the Unix systems consisted in bumping up the maximum number of file descriptors. That's it. The FreeBSD system in particular was left completely mistuned and clearly running out of socket resources -- they report that it was logging errors but seem entirely ignorant of what those errors were (beyond their being load-related) and how to correct them.
Polling is hardly the best system interface for multiplexing TCP connections on either Windows or FreeBSD. As you mention, completion ports are best for Windows. Kqueue is best for FreeBSD. It just happens that polling is used in the crappy commercial SPAM program they "benchmarked". (All the OSes support scatter/gather, BTW, so you can't claim Windows was treated unfairly by its omission.)
None of the systems were testing in a way that shows their actual capabilities. The article is just a thinly disguised commercial for a (barely-)cross-platform "bulk email" product.
Don't bother reading that article unless you are interested in using Lyris' close-sourced SPAM-generating software. The sum total of their "benchmark" consists of SPAMming 200,000 copies of the same message to a list of email addresses. They didn't know the first thing about configuring their Unix systems (bumping up the maximum number of file descriptors--the only tuning they did--does NOT increase the maximum number of simultaneous connections, and it was clear that FreeBSD especially suffered from resource starvation as a result of misconfiguration). They didn't actually compare the various paradigms (single/multiple thread, single/multiple process, async/sync I/O). No, they just tell you which O/S, naively configured, pumps out SPAM the fastest.
This is not the place to go to see how threaded/non-threaded solutions compare. It's a thinly-disguised commercial for a "bulk email" product.
Something you might find interesting: at one time the worlds largest repository of free and open-source software was at the (then) Army Ballistic Research Laboratory, open to anyone who could FTP there. It was an important resource during the 1980's when the free software community, a community that included the late Mike Muuss of the BRL, was taking shape.
This is only one example of many from that era. (I hope it's not too trivial to point out that the Internet itself originated with the "War Pigs.") Had the GPL included an anti-military clause, there is a good chance that much of GNU would not exist -- if the movement had happened at all. Don't forget, the "War Pigs" paid for Stallman's ARPANET connection (via MIT, which was on the ARPANET by virtue of being a major military contractor).
I'm not attempting to justify the military, here, just pointing out that blindly excluding them may not be the best of ideas...
Probably because Windows only runs on the i386 architecture and not StrongARM. WinCE, like Linux, does run on that chip (as does NetBSD, though probably not on this specific box).
Actually, I'd expect it to be pretty snappy, probably about as fast as a 200MHz Pentium. Of course, 32MB RAM and only a 16MB Flash as a storage device keeps it from being generally useful, but the StrongARM is a pretty powerful chip, especially considering its low power requirements.
Sure, wanting to see your efforts find wide use is a worthy goal, but what the other posters were saying implied that other goals -- such as a satisfying technical challenge -- weren't significant. I never said that usefulness and marketability were to be avoided. But unlike Microsoft (and most other commercial software companies), the BSD and Linux efforts have other goals which are often as important or more important than shear commercial heft.
One of the primary goals of NetBSD is a generally portable architecture -- an emphasis that distinguishes it from the other BSD's. Even a port to an otherwise "useless" achitecture can enhance that generality. So it can be argued that an effort like this contributes to NetBSD's usefulness.
But this (as well as your post) misses my point: the hacker asthetic can be orthogonal to utility. Almost anyone who loves to program as an activity (and not just a way to make money) will understand this. What shocked me was that none of the Slashdotters responding tho this article seemed to have such an understanding.
That's sad.
This is one of the best "how to do it" articles I've read in a long time. It's not just a technical description of NetBSD's Linux emulation system. It's a developer's-eye view of how it was created, a detailed description of the process and not just a laundry list of steps. The article would be useful reading to anyone doing systems-level development even if they never intend to touch NetBSD, both as an example of how to approach the extension of an existing system and as an excellent example of how to write about it.
I don't use NetBSD or PPC, and I still found the article absorbing and useful. Check it out and see if you don't agree.
-EdSometimes the highest mountains are also the oldest. A hacker doesn't need to ask "why?" and doesn't worry about "what use is it?" Hackers know: it's the sheer pleasure of creating, of exploring uncharted territory, of building up clever solutions and finally emerging victorious over the challenge. If wide usefulness ane marketability are your goals, go join Microsoft -- they're their goals, too.
I think the responses to this post make it pretty damn clear that few Slashdot posters are hackers anymore.
If you want to be picky, Patrick utterly failed the challenge by not supplying compressed files. They were simply unaltered pieces of the original file. Sure, there were missing bits of the files that had been moved to the file names, but the fact that this slight of hand failed to compress the data can be proved simply by renaming the files. Even if the order of files supplid to the "decompressor" is preserved, renaming them renders the original data unrecoverable. Sure, moving data into the filename is a cute trick, but it isn't compression.
The goal of the challenge is to produce compression, not to win via some semantic shell game. It's Patrick who shed his honor by resorting to a semantic smoke screen and attempting to win by wordplay with no intention of actually producing any real compression.
Actually, it does help make such inroads, but it's as an embedded OS, not an "enterprise" OS. Even the NetBSD folks will admit they aren't really shooting for the latter. But porting to "video game consoles and scientific calculators" proves how versatile NetBSD is as an embedded platform.
Alphas are used in high-end embedded systems such as those used for industrial and medical imaging, since they still beat Pentiums two-to-one or better in the computations involved in such tasks. And to reach the useful memory and I/O bandwidth of recent Alpha systems, you have to use exotic chipsets with Pentiums, which can offset some or all of their price advantage.
Wind River's purchase of BSDi suggests an important trend for the BSD's into the embedded market, a market that is expected to exceed the enterprise market in value in the years to come. Given Linux's problems in this area (lack of an integrated userland and what is often perceived as a corporation-unfriendly license) the BSD's have a pretty good shot at becoming open-source solutions for embedded systems.
You missed my point. Not everyone who writes scripts is aware of the difference between "<" and -lt. Does your sysadmin know the difference? I've met some who don't.
There is a difference between ">" and -gt in BASH as well. But that doesn't keep people from doing it wrong.
There is another 999999999 rollover problem. Some admin scripts (in BASH, PERL, etc.) assume that the decimal timestamp can be compared as an ASCII string. Unfortunately, 999999999 > 1000000000 in this case, which can cause such scripts to break in subtle or overt ways. For example, if TS1=999999999 and TS2=1000000000, the BASH statement:
if [ $TS1 ">" $TS2 ]; then
will evaluate as true.
Just a wild-ass guess, but I'd assume Yahoo! pays at least $0.10-$0.20 for the average call to this service. There is no way to support that with ad revenue, even in the best of times, even at rates several times that of similar media (such as radio). On the other hand, you can serve hundreds or thousands of customers via the web for the same money. You could probably pay for it with ad revenue even in the current depressed ad market.
Don't read too much into this. Free 800 number service wouldn't have lasted that long even if the dot-com phenomenon hadn't imploded.
One other reason why Linus and others might have been staying away from BSD was the whole legal morass it was involved in at the time. Who would want to spend time on a project which might well be declared contraband if AT&T's lawsuit against Berkeley succeeded?
Well, it's much better organized, for starters. And if the author continues to take interest in it, it will be more up-to-date than any search engine as well.
Google sucks somewhat less than other search engines, but it still has problems with dead links or live links to stale pages. The pages it returns are organized by past popularity and not necessarily relevence to a particular issue. Someone involved in the OpenBSD community can update a page such as this immediately when new information appears, and prune out old links as needed. He can provide nested table-of-contents and succinct descriptions of the listed pages.
Google can take weeks to spot a new resource, and even longer to forget about a once-popular resource that has been superceded or removed. The text excerpts provided by Google often are of little help in deciding whether a link is relevent. Humans, especially humans with knowledge and interest in a particular area, create much more useful lists.
This page looks like a good start for someone wanting to learn about OpenBSD, complementing the openbsd.org site. I predict that it won't be too long before it's one of the first results returned from your Google query.
There are other causes as well. For example, people who have set up a web site on GeoCities, Xoom, or wherever frequently make copies of their site by saving pages with their browser. This includes any code that was inserted by that service, whether for advertising or for site features such as counters and statistics, or even clip art. When they decide to move their site to another service they upload these copies -- including all the stuff the old service inserted into the pages. As long as nothing overtly breaks, this sort of stuff just accumulates as pages get moved or updated.
If you're asking youself why anyone would be so stupid, recall that all these page hosting services provide tools for building web pages; the average person with a web page knows little or nothing about HTML, and so doesn't have the slightest idea that some JavaScript appended to their page isn't necessary, and in fact wasn't actually part of the stored page in the first place.
For example, GeoCities inserts a web bug to give each user statistics concerning their web pages and to provide an optional counter. The bug is useless outside of GeoCities, yet I see it fairly frequently on other services. The same with Xoom's counter code, and so on. I suspect in most cases the "foreign" appearances of these bugs just represent noise to the site of origin.
Hey, let's look at WinNT 5 (i.e. Win-2000) for a real '70's OS. It is demonstrably closer to VMS than Linux is to Unix (in everything but name).
I have a much better chance of finding quality code on SourceForge than quality music on mp3.com. But that's not the point. Unlike mp3.com, which could do better without the dreck, SourceForge needs those pre-alpha-going-nowhere projects, because even failures can fuel ideas. And unlike bad music, bad code can at least form a starting point for good code.
Years ago I was a Minix fan, and ran it on my 10MHz 286. I read comp.os.minix avidly and was pretty sceptical when this student in Finland announced that, because Minix's creator didn't want to extend it to work on 386's and support more of Unix, that he would do so, and was anyone interested in helping. It wasn't the first time someone had proposed this, and if someone had asked me I'd have said that he had little chance of success. After all, the GNU folks had already been working on such a project and had yet to succeed. I knew how hard it would be, and figured that the most this fellow would do would be to waste a lot of his time, and that of anyone else who decided to help.
Of course, you know who that Finnish student was, and what happened to his project. But I doubt you would have given him any better odds than I did, and would have put him squarely in the "forever alpha" column.
This is why SourceForge can't afford to be too choosy as to the projects they host. The bad ones don't take much space or bandwidth, anyway. Their challenge is to provide mechanisms for the better projects to achieve visibility, such that they don't get lost in the "noise." But it is from that "noise" that wonderful things may appear.
This has been done before, but not with light. With sound! That's right, back in the 1950's they actually made memories from long mercury-filled tubes conducting sound impulses. The impulses would be amplified and "squared-up" each time around. They could only store a few thousand bits that way, but you could always have several of them running in parallel.