You or I wouldn't touch this with a ten-foot pole,
but there actually is a fair fraction of the
public which doesn't care who knows where they
browse, and which doesn't have any idea of the
other risks.
After all, many people don't mind their local
drug store tracking their purchases through
discount cards.
And if purchase data helps the drugstore
keep the things people buy in in stock and
makes the ad flyers they receive more likely
to have the stuff they want in them, why, that's
just making a happier (if violated) customer.
ISP's (and to a lesser extent, portals) can go
even farther, and anticipate interest in
particular products based on browsing behavior.
Yet another step toward happy consumerdom: if
they get good enough at their tracking, you'll
never have to see an ad you aren't interested in.
Joe consumer is supposed to enjoy that his
privacy is being pimped to the highest bidder.
And, sadly enough, there is evidence that this
may indeed be so.
(That doesn't mean that Juno will be able to
actually pull off this marketer's wet dream,
of course.)
That said, the distributed-computing angle of
this is actually pretty interesting as a way
of generating income for Juno.
It will be a lot easier for them, as an ISP, to
administer this sort of system than for a
stand-alone enterprise to do so.
Yes, the security issues are mind-boggling, and
the near-inevitable scandal that results will
probably kill them (if nothing else does first).
But it's an idea that will likely succeed at
some point, even if Juno fails.
Of course he brought up Columbine.
It's like anti-crypto arguments, where
terrorism is produced as a "reason."
As long as the sort of profiling that
victimized your son is justified as
"preventing Columbines" rather than
"promulgating repression," it will continue
to happen.
Thus one of my points is that
Katz is playing their game by bringing
up Columbine.
It's become a trigger word for those who would
turn schools into lockups (and there is big
money in this sort of fear-mongering both in
terms of security personnel and hardware
and a multitude of "training courses"
for everyone from school superintendents
on down).
All of this I'm sure you already know.
My hat's off to you for standing up for
your son and for what you feel is right,
and for speaking up here.
I've not the slightest issue with you;
my objection is to
people who exploit Columbine to push various
repressive programs.
Not only do they harm a community which is
still reeling years after the tragic event,
but they injure their own communities by
their fear-mongering and child-hating ideas.
Why this may be so (aside from the aforementioned
profit motive) could fill a book, so I'll stop
now.
It's old-style C code, but in terms of
overall structure and organization it's
hard to beat the original Bell Labs Unix.
Now that the Lions commentary on 6th Edition
Unix is generally available
(Lions' Commentary on UNIX 6th Edition, with
Source Code; ISBN 1-57398-013-7),
you can both read the code and Lions'
brilliant commentary on it.
It's amazing what a few thousand lines of
carefully-crafted code can do; most text
editors and mail readers are larger than
the original Unix kernel.
Don't read this to learn how to program in
C -- the language has grown enormously since
this time, often in ways that allow for
better style and consistency-checking.
But do read it to see how to program with a
clean, modular design and carefully thought-out
organization, and probably learn more about
operating systems per unit time spent than
you would reading anything else.
Agreed, Katz has surfaced a lot of issues, many
of them quite worthy of attention and
frightening in their implications.
This particular article focuses mainly on two
of them: profiling and anonymous
informant programs.
Neither of these originated with Columbine,
although people promoting them are quite
willing to exploit Columbine to their ends.
And Katz, by raising the "Hellmouth" banner,
is doing the same.
I don't think Katz helps his cause by conjuring
the ghosts of Columbine.
He sure as hell isn't helping those folks who
are still dealing with its aftermath.
Every year there are more breakdowns, more
suicides, of people who lost family or friends
or who witnessed the massacre or who have been
laboring long hours to help put
those shattered lives back together.
The issues Katz raises are potent enough on
their own, and there are ready examples with
far more power at his fingertips, should he
spend just a little time researching.
Look at
East Germany or the USSR, where informants and
profiling were taken to their evil extremes.
Leave Columbine alone.
The first couple of Hellmouth articles
had a powerful effect, not only by providing
an outlet for the ranks of schoolkids (and
former schoolkids) outside of the dominant
clique, but by sensitizing some of the more
thoughtful teachers and counselors to their
issues.
The articles actually circulated among some of the
professionals dealing with Columbine, something
that no doubt helped sensitize them to the
ways that reactions to Columbine would (and did)
come down on innocent groups.
I suspect that Katz was greatly surprised
at the power and scope of the emotions and
experiences that the articles tapped -- and the
amount of attention they received.
He's still riding the wave of outpourings from
that series.
He should stop.
There is a point where self-expression becomes
self-obsession.
There is a point where opening old wounds
becomes injurious, not cathartic.
And there is a point where he becomes just
another zealot milking Columbine to his own
ends (even though I might support those ends),
and to rapidly shrinking effect.
I generally support Katz (which I'm sure many
here feel puts me in a small minority).
Yes, his pieces are sometimes fluffy and he
often forgets to dot his intellectual I's and
cross his factual T's.
But he generally creates a good springboard for
discussion (if you can ignore the knee-jerk
Katz-haters that love to flock to his articles).
And discussion (not "news") is what Slashdot
is about, isn't it?
But it is far past time to stop dragging out
"Hellmouth" and start developing some fresh
perspectives and constructive ideas on this
subject, or drop it altogether.
He should have stopped the series some time ago.
That's their mark-up, the price difference
between what they sell a book for and what
they pay the publisher.
From that, they have to pay people, maintain
their stores, warehouses, offices, and
inventory, and pay for advertising and other
marketing efforts.
The actual profit is under 10%,
at least for the big chains, and usually even
less for smaller stores.
In contrast, that 24% profit for Microsoft is after
all salaries and expenses.
(Given the marginal
costs associated with their product, it's
damn near 100% using the reasoning you're
employing.)
It's no wonder that, until recently, they
were considered one of the seven wonders of
the economic world.
I'm setting up a B&W cam (from
Marlin P Jones &
Associates) for the same purpose (baby cam).
The nice thing is that CCD cameras are very
infra-red sensitive unless they incorporate
an IR filter.
(You can test yours by observing how well it
"sees" an IR remote's beam.)
I've wired up two banks of IR LEDs as a light
source (20 50-cent LED's in series/parallel).
Baby can sleep in complete darkness while
Big Brother (well, Big Mother and Big Father)
watch.
Good cameras (from MPJA,
SuperCircuits, and others) are cheap enough that there
really is no reason to fool with toys like
the camera mentioned in the base article.
The X10 stuff is as cheap and is at least
barely usable (with good lighting and short
distances).
But if you're half-way handy with electronics,
you can do a lot better assembling a system yourself for just a bit more money.
Actually, some larger providers do charge in
part on the basis of "sustained peak bandwidth,"
where the "sustained" part means over a
specified time period (five minutes in the cases
I'm familiar with).
This only makes sense with really big sites
that make of a significant fraction of a
provider's total capacity.
A customer with a high sustained peak bandwidth
would force the provider to build out to support
that bandwidth to avoid impact on other
customers.
Human and pre-human evolution has generally
taken place well outside of the Artic Circle.
Nonetheless, the length of daylight probably
isn't a factor for most people.
An exception
would be people with SAD, or Seasonal Affective
Disorder, who tend to get depressed when days
are shortest.
I've read that in at least some cases moving
closer to the equator has helped such folks.
So individuals differ, but our ability to
synchronize is generally pretty robust; most
people recover from trans-hemispheric jet-lag
in just a few days, for example.
All those experiments mean is that humans, in the
absense of cues, tend to have a slightly longer
biological cycle than they do when time cues
are present.
That doesn't mean that a longer cycle
is natural, any more than living in
an environment without exposure to outside
stimuli is natural.
I'll use an engineering example (skip to next
paragraph if your eyes glaze over):
if you are trying to synchronize a relaxation
oscilator to a particular frequency, you design
it to free-run at a slightly lower frequency
(i.e. longer period) and then apply a pulse
or some other excitation at the desired rate.
Biological systems (in particular the nervous
and endocrine systems) seem to exploit
relaxation processes quite frequently, so
a relaxation oscilator is likely to be a particularly strong analogy to what is
happening here.
Day/night cues have been very strong for human
life throughout its existence.
Even people living in caves probably spent a
good fraction of their time outside the cave
during the day.
Putting someone in an envronment without
time cues is a bit like putting them in a
sensory isolation tank -- normal people start
to hallucinate after an hour or two in the
later case.
Those experiments are looking at artifacts
of exposure to an unusual environment, and have
little bearing on what is "normal."
This might be a bit off-topic, but I think it's
important that we examine our reasons (and the
feelings that underpin them) for wanting software
to be free.
The following was written by a musician
(thus the reference to harmony) but it shows
that the idea of shared software was around
long before GNU:
Computers are bringing about a situation that's
like the invention of harmony.
Subroutines are like chords.
No one would think of keeping a chord to himself.
You'd give it to anyone who wanted it.
You'd welcome alterations of it.
-- John Cage (1969)
I think that many programmers instinctively feel
the way that Cage did,
and are distressed that others choose to hoard
software, whatever the reason.
Cage was an unusual artist ("Thank God!" some
folks would say), but I think he was of like
mind to many creative programmers.
He did not feel diminished when other people
borrowed from his work.
Other artists had problems with this, but it
was at the heart of the "how" and "why" of his
creations (and the reason why most of them
were, in one form or another, collaborations).
Likewise, programmers who feel that
sharing leads to increase and not to
diminishment meet the same sort of resistance
from those who feel that other considerations
predominate.
And I suspect that this difference is deeper
than mere opinion.
Small children understand quite well that
sharing must work both ways:
I'll share with you,
but only if you share with me.
The GPL casts this simple, bone-deep feeling in
the form of a software license.
I'll let you decide whether the feeling remains a
fundamental one in this context,
or a childish one --
and whether the difference in outlook between
those who espouse it and those who oppose it
is too broad a gap to
bridge.
Even with the giant lock you'll get more out of
that second CPU than you might think.
My 2x550MHz will do a "make -j 3 buildworld" in
60% of the time with the second CPU enabled
(58 minutes) compared to one CPU (97 minutes).
Yes, the GL sucks, and the SMPng stuff will
(eventually) be great.
But depending upon what your load mix is, you
can get full use out of your second CPU now.
BT is an ISP (among other things).
If they can take money (and business) from
other ISPs, it benefits them.
But they want the rest of the web and its
underpinnings to flourish so they can make
even more money.
It's not much use being an ISP if there are
no browsers, web sites, and so on.
But BT thinks it would be a lot of fun to
ding all the other ISPs.
Because BT is an ISP.
Hurting other ISPs' benefits them (or so they
probably figure).
Web browsers, authoring tools, and web sites
themselves help BT, make
money.
So why go after them?
The more content there is out there, the more
ISP services BT can sell.
This is embedded, stand-alone software.
How would you propose that someone hack
into it?
Stability is the issue, not security,
at least in this application.
With the exception of certain big-ticket
items that Congress likes to throw money
at (planes, tanks, weapon systems -- anything
that funnels sufficient money into a given
congressman's district) the military is
pretty cost-conscious.
Ever notice that the more
technical the original
article, the few people that post responses?
What you said!
When you filter out the trolls and the
dogmatists (you know, license lawyers and such
who spout the same canned opinions every chance
they get),
most technical articles have maybe 20-35
responses.
Even such solidly technical Linux-oriented
stuff like ReiserFS
vs. ext3 gets maybe 50 technically relevent
responses, with the rest being hearsay or worse.
I'm not complaining, really.
The chatter is often what makes
Slashdot interesting.
Even the trolling is useful to me; it helps
prepare me for when my son reaches age 15 or
so, and is trying to extend a childhood
interest in fart jokes to the ultimate level
of sophistication.;-)
"The number of posts on Usenet"???
I'd say that your chain of reasoning has a fatal
flaw right from the start.
Very little technical BSD discussion is conducted
via Usenet.
Frankly, OpenBSD gets discussed more
often on Usenet due to emotional, not technical reasons.
That's not to say that the issues discussed aren't
technical, just that things like security and
encryption tend to elicit vocal opinions.
Of course, you're probably the same FUD-meister
who shows up in any BSD discussion that appears
on the Slashdot front page.
Or perhaps there are several of you who make
posting the same drivel some sort of hobby.
In any case, your anonymous status suits your
overall lack of credibility.
Not sure why I bother...
There is a real advantage to a laptop that can
run on batteries during a transcontinental
flight (and not just for watching DVDs).
And although I agree that a 486 should
be just fine for word-processing, the folks
in Redmond (and Santa Clara) have had different
ideas; I'd hate to use Office 2000 on such a
unit.
Long battery life doesn't have much geek value,
but for many of the folks who buy new laptops
it may be the most important thing.
There is more truth to what she wrote than you
might think.
The ability to communicate and to lead
ends up being
equally important to technical knowledge in
the "real world."
I've known enough mediocre techies with
better-than-average people skills who wound
up becoming good technical managers to see
that a better-rounded background is more
important to success in high-tech business
than technical competence alone.
Of course, the outstanding engineer with
leadership skills will go even farther
(evidence the Andy Groves and David Hewletts
of the world -- and, I would venture, the
Linus Torvalds, too).
But such talents are too rare to fill middle
management.
You may feel that engineers don't receive
enough recognition for what they do, and
you may well be right.
But, with some notable exceptions, businesses
aren't run by engineers.
They are run by managers who are more likely to
have a liberal arts background than an
engineering background.
You may be so blinded by what you consider is
or isn't
"real work" that you can't see how
the world around you actually behaves.
Make fun all you want of what managers do, but
I'd rather bet on a team of twenty average
engineers and four good managers than twenty-four
superstar engineers working on their own
(or with poor managers, which is pretty much
the same).
Leadership -- the ability to articulate a
common goal and lead a group toward it --
is how real work typically gets done.
And leadership is more likely to spring from
a knowledge and understanding of human
thinking and culture than from technical
knowledge.
Thus it's interesting, but hardly surprising,
that the few engineering
programs which include liberal arts requirements
as well as engineering training (such as
Stanford's) produce so many of our technical
leaders.
"rwx" permissions existed in Unix from its
creation, so by definition they are Unix-like.
That doesn't mean they are the best way
(look at Plan 9's credential system for more
recent ideas from Unix's creators), but
they are what Thompson & Ritchie used
in place of the more more capable (and complex)
mechanisms of Multics.
-Ed
Don't expect all of OS X to be open-source
on
JKH on OS X
·
· Score: 4
Jordan writes that open-sourcing OS X would be
a "very bold and aggressively forward-thinking"
thing for Apple to do.
That may be an understatement; I'm sure there
are many at Apple who feel it would be suicide.
Apple makes a lot of their money from selling
hardware.
Say what you want about the price/performance
of that hardware, people buy it not just
because of its looks (perhaps in spite of them),
but because it is the only way to obtain the Mac
GUI and run Mac apps.
Open-source all of OS X, and in a matter of weeks
the Mac GUI will be running on non-Apple
hardware that costs
a third of Apple's prices, and in a matter of
months the Mac apps will start to follow.
At least this would be their fear, and it is
hardly a groundless one.
I agree with Jordan that
leveraging OS X's open-source-friendly Unix
base with the Mac GUI and apps would create
a major force to be reckoned with --
perhaps even the Microsoft-toppling force
he envisions.
But I don't
think Apple sees their share of that potential
market as offsetting the downside to their
hardware business.
Perhaps there is a way they can assure a
sufficient fraction of the resulting software
market to make up for that loss,
but I've yet to see
a convincing argument of how they could do so.
I've actually read the BSD kevent
stuff, and I think it's classic over-design.
It's not easy to see what it's all about,
and the whole <kq, ident, filter> tuple crap
is just silly.
Looks much too complicated.
All due respect to Mr Torvalds, but I'm not sure
he understands the intent behind the kqueue
interface.
It's not just intended to be a poll() on
steriods, though it serves that function.
A kevent does not need to be related to a file
descriptor--for example, signals and the status
of other processes can also be monitored with
the appropriate filter.
Other filters will be added as time goes on.
The tuples Linus objects to are actually the
simplest way to provide this level of generality
through a single interface.
Yahoo just wants to be a paid
middle man? We're getting rid of those from the
real world. Why do we want to create them on the
internet?
Yup, why go to a plumbing store when you can
go to a pipe store, a T-fitting store, a
faucet store, etc.?
Face it, aggregation, whether products or
information, can be extremely useful.
Aggregation is done by "middlemen," and
there are useful middlemen, and useless
middlemen.
As a matter of fact, in the "real world" the
more efficent middlemen (e.g. WalMart) are
getting increasingly powerful--they are hardly
being "gotten rid of"--by their
efficiencies in aggregating products and
services in a convenient and useful way.
Another example:
TV networks (cable or broadcast) aggregate
programs from a variety of producers; a
minority of programs are actually produced
in-house.
They run ads and use the
proceeds to buy those programs.
Some channels (e.g. HBO) charge instead; you can
choose not to pay, and still get what the other
channels provide.
Viacom, for instance, owns both
subscriber- and ad-supported channels.
I don't see them all of a sudden deciding
to make MTV a pay channel, do you?
Not to put too fine a point on it, but TNSTAAFL.
(There's No Such Thing As A Free Lunch.)
Aggregation has value, but it also has costs.
The latter are going to get passed to you one
way (advertising) or another (direct charges).
If you don't find that service worth the price,
go without or create your own.
I agree that the C++ ABI issue is a horrible
mess, but you really can't blaim AT&T for
that.
If the C++ ABI had been set back in early
days, it would have had to be revised several
times over the years as templates, namespaces,
and so forth were added to the language.
For this to have been any better than the
present situation, a much more extensible
object file format would have to have been
created than we use today.
The real issue is that C and C++ still use a flat
namespace for symbols in object files, just like
in the 1950's when assembler languages were all
that existed.
The minor additions made to ELF for static
constructors and the like were the absolute
minimum to get C++ to work--leaving no option
but kludge-of-the-day name mangling to flatten
C++'s multitude of hierarchies.
This is so inelegant that no one wanted
to define it into a standard -- surely a better
way will arise?
But it hasn't.
CFront's name mangling could have been taken
as the de facto standard and
extended as C++ was extended.
That didn't happen, and given that AT&T
didn't "own" C++ the way that Sun owns Java,
it probably wouldn't have happened even if
they pushed it.
But why perpetuate what is an ugly kludge,
anyway?
It's probably too late to fix the real problem.
Rejiggering the entire toolchain for a new
object file format just isn't going to happen.
(Some people are still smarting after the
change to ELF.)
So we'll have to live for the forseeable future
with fragile and incompatible attempts to
fit N-dimensional structures into flat
lists...
I use it daily.
And I've been stung by misoptimizations
enough that I no longer even bother
trying anything beyond -O1 on critical code.
And this is on i386.
RedHat releases on Alpha, which you admit
"wasn't great."
A lot of Alpha issues got solved post-2.95.2.
I have no inside knowledge of RedHat, but this
might have weighed fairly heavily in their
decision.
I've used GCC since 1.X days, and it used
to be that it was the equivalent or better
of almost any vendor's compiler.
That's no longer true.
Where I work, GCC 2.95.2 has such a bad rep
for miscompiling or crashing
that nearly all production code is compiled with
EGCS 1.1.2 -- or GCC 2.7.2.3.
We might just be unlucky, or perhaps GCC 2.95.2
has more problems when dealing with legacy C++.
But the latter would still be a major defect
in GCC.
As to whether 2.95.2 is the "buggiest":
I have experienced more grief from 2.95.2
than any earlier release.
I have seen more people have problems with
it than any earlier release.
I've managed to
avoided the 2.8 series, though, so I'll
have to take back my claim of 2.95.2 being
the "buggiest," since judging by its repulation
2.8 might well have been worse.
As for what Debian uses, 2.95.2 is also
the production compiler for FreeBSD 4.x
(which is most often where I use it, though I
do some development on Linux and Solaris
as well).
And unlike Debian, the FreeBSD folks are
not at all happy with it.
I agree that GCC testing has improved a lot; I've
scanned the GCC developer's list from time
to time, and I'm quite impressed at how much
rigor has been added to the testing process,
and how it has been made an integral part
of development.
This is probably why snapshots seem to be a lot
more solid than they did early in the EGCS
project.
This is why
2.95.2 was an enormous (negative) surprise to me.
I'd talked up EGCS and the EGCS development
process from EGCS 1.0 on, and converted a lot
of folks to using EGCS.
I had even greater hopes for it when it was
made the official GCC.
The testing regime seemed promising, a lot
of good developers (including yourself)
were slaving away at making GCC better and better,
so I fully expected something "better than EGCS."
Perhaps calling it "the buggiest" is a bit of an
overstatement, but I feel disappointed and a bit
betrayed.
Slashdot Mirror
You or I wouldn't touch this with a ten-foot pole, but there actually is a fair fraction of the public which doesn't care who knows where they browse, and which doesn't have any idea of the other risks. After all, many people don't mind their local drug store tracking their purchases through discount cards. And if purchase data helps the drugstore keep the things people buy in in stock and makes the ad flyers they receive more likely to have the stuff they want in them, why, that's just making a happier (if violated) customer.
ISP's (and to a lesser extent, portals) can go even farther, and anticipate interest in particular products based on browsing behavior. Yet another step toward happy consumerdom: if they get good enough at their tracking, you'll never have to see an ad you aren't interested in. Joe consumer is supposed to enjoy that his privacy is being pimped to the highest bidder. And, sadly enough, there is evidence that this may indeed be so. (That doesn't mean that Juno will be able to actually pull off this marketer's wet dream, of course.)
That said, the distributed-computing angle of this is actually pretty interesting as a way of generating income for Juno. It will be a lot easier for them, as an ISP, to administer this sort of system than for a stand-alone enterprise to do so. Yes, the security issues are mind-boggling, and the near-inevitable scandal that results will probably kill them (if nothing else does first). But it's an idea that will likely succeed at some point, even if Juno fails.
Of course he brought up Columbine. It's like anti-crypto arguments, where terrorism is produced as a "reason." As long as the sort of profiling that victimized your son is justified as "preventing Columbines" rather than "promulgating repression," it will continue to happen. Thus one of my points is that Katz is playing their game by bringing up Columbine. It's become a trigger word for those who would turn schools into lockups (and there is big money in this sort of fear-mongering both in terms of security personnel and hardware and a multitude of "training courses" for everyone from school superintendents on down).
All of this I'm sure you already know. My hat's off to you for standing up for your son and for what you feel is right, and for speaking up here. I've not the slightest issue with you; my objection is to people who exploit Columbine to push various repressive programs. Not only do they harm a community which is still reeling years after the tragic event, but they injure their own communities by their fear-mongering and child-hating ideas. Why this may be so (aside from the aforementioned profit motive) could fill a book, so I'll stop now.
It's old-style C code, but in terms of overall structure and organization it's hard to beat the original Bell Labs Unix. Now that the Lions commentary on 6th Edition Unix is generally available (Lions' Commentary on UNIX 6th Edition, with Source Code; ISBN 1-57398-013-7), you can both read the code and Lions' brilliant commentary on it. It's amazing what a few thousand lines of carefully-crafted code can do; most text editors and mail readers are larger than the original Unix kernel.
Don't read this to learn how to program in C -- the language has grown enormously since this time, often in ways that allow for better style and consistency-checking. But do read it to see how to program with a clean, modular design and carefully thought-out organization, and probably learn more about operating systems per unit time spent than you would reading anything else.
Agreed, Katz has surfaced a lot of issues, many of them quite worthy of attention and frightening in their implications. This particular article focuses mainly on two of them: profiling and anonymous informant programs. Neither of these originated with Columbine, although people promoting them are quite willing to exploit Columbine to their ends. And Katz, by raising the "Hellmouth" banner, is doing the same.
I don't think Katz helps his cause by conjuring the ghosts of Columbine. He sure as hell isn't helping those folks who are still dealing with its aftermath. Every year there are more breakdowns, more suicides, of people who lost family or friends or who witnessed the massacre or who have been laboring long hours to help put those shattered lives back together.
The issues Katz raises are potent enough on their own, and there are ready examples with far more power at his fingertips, should he spend just a little time researching. Look at East Germany or the USSR, where informants and profiling were taken to their evil extremes. Leave Columbine alone.
The first couple of Hellmouth articles had a powerful effect, not only by providing an outlet for the ranks of schoolkids (and former schoolkids) outside of the dominant clique, but by sensitizing some of the more thoughtful teachers and counselors to their issues. The articles actually circulated among some of the professionals dealing with Columbine, something that no doubt helped sensitize them to the ways that reactions to Columbine would (and did) come down on innocent groups. I suspect that Katz was greatly surprised at the power and scope of the emotions and experiences that the articles tapped -- and the amount of attention they received. He's still riding the wave of outpourings from that series.
He should stop. There is a point where self-expression becomes self-obsession. There is a point where opening old wounds becomes injurious, not cathartic. And there is a point where he becomes just another zealot milking Columbine to his own ends (even though I might support those ends), and to rapidly shrinking effect.
I generally support Katz (which I'm sure many here feel puts me in a small minority). Yes, his pieces are sometimes fluffy and he often forgets to dot his intellectual I's and cross his factual T's. But he generally creates a good springboard for discussion (if you can ignore the knee-jerk Katz-haters that love to flock to his articles). And discussion (not "news") is what Slashdot is about, isn't it?
But it is far past time to stop dragging out "Hellmouth" and start developing some fresh perspectives and constructive ideas on this subject, or drop it altogether. He should have stopped the series some time ago.
That's their mark-up, the price difference between what they sell a book for and what they pay the publisher. From that, they have to pay people, maintain their stores, warehouses, offices, and inventory, and pay for advertising and other marketing efforts. The actual profit is under 10%, at least for the big chains, and usually even less for smaller stores.
In contrast, that 24% profit for Microsoft is after all salaries and expenses. (Given the marginal costs associated with their product, it's damn near 100% using the reasoning you're employing.) It's no wonder that, until recently, they were considered one of the seven wonders of the economic world.
I'm setting up a B&W cam (from Marlin P Jones & Associates) for the same purpose (baby cam). The nice thing is that CCD cameras are very infra-red sensitive unless they incorporate an IR filter. (You can test yours by observing how well it "sees" an IR remote's beam.) I've wired up two banks of IR LEDs as a light source (20 50-cent LED's in series/parallel). Baby can sleep in complete darkness while Big Brother (well, Big Mother and Big Father) watch.
Good cameras (from MPJA, SuperCircuits, and others) are cheap enough that there really is no reason to fool with toys like the camera mentioned in the base article. The X10 stuff is as cheap and is at least barely usable (with good lighting and short distances). But if you're half-way handy with electronics, you can do a lot better assembling a system yourself for just a bit more money.
Actually, some larger providers do charge in part on the basis of "sustained peak bandwidth," where the "sustained" part means over a specified time period (five minutes in the cases I'm familiar with). This only makes sense with really big sites that make of a significant fraction of a provider's total capacity. A customer with a high sustained peak bandwidth would force the provider to build out to support that bandwidth to avoid impact on other customers.
Human and pre-human evolution has generally taken place well outside of the Artic Circle. Nonetheless, the length of daylight probably isn't a factor for most people. An exception would be people with SAD, or Seasonal Affective Disorder, who tend to get depressed when days are shortest. I've read that in at least some cases moving closer to the equator has helped such folks. So individuals differ, but our ability to synchronize is generally pretty robust; most people recover from trans-hemispheric jet-lag in just a few days, for example.
All those experiments mean is that humans, in the absense of cues, tend to have a slightly longer biological cycle than they do when time cues are present. That doesn't mean that a longer cycle is natural, any more than living in an environment without exposure to outside stimuli is natural.
I'll use an engineering example (skip to next paragraph if your eyes glaze over): if you are trying to synchronize a relaxation oscilator to a particular frequency, you design it to free-run at a slightly lower frequency (i.e. longer period) and then apply a pulse or some other excitation at the desired rate. Biological systems (in particular the nervous and endocrine systems) seem to exploit relaxation processes quite frequently, so a relaxation oscilator is likely to be a particularly strong analogy to what is happening here.
Day/night cues have been very strong for human life throughout its existence. Even people living in caves probably spent a good fraction of their time outside the cave during the day. Putting someone in an envronment without time cues is a bit like putting them in a sensory isolation tank -- normal people start to hallucinate after an hour or two in the later case. Those experiments are looking at artifacts of exposure to an unusual environment, and have little bearing on what is "normal."
This might be a bit off-topic, but I think it's important that we examine our reasons (and the feelings that underpin them) for wanting software to be free.
The following was written by a musician (thus the reference to harmony) but it shows that the idea of shared software was around long before GNU:
I think that many programmers instinctively feel the way that Cage did, and are distressed that others choose to hoard software, whatever the reason. Cage was an unusual artist ("Thank God!" some folks would say), but I think he was of like mind to many creative programmers. He did not feel diminished when other people borrowed from his work. Other artists had problems with this, but it was at the heart of the "how" and "why" of his creations (and the reason why most of them were, in one form or another, collaborations).
Likewise, programmers who feel that sharing leads to increase and not to diminishment meet the same sort of resistance from those who feel that other considerations predominate. And I suspect that this difference is deeper than mere opinion. Small children understand quite well that sharing must work both ways: I'll share with you, but only if you share with me. The GPL casts this simple, bone-deep feeling in the form of a software license. I'll let you decide whether the feeling remains a fundamental one in this context, or a childish one -- and whether the difference in outlook between those who espouse it and those who oppose it is too broad a gap to bridge.
Even with the giant lock you'll get more out of that second CPU than you might think. My 2x550MHz will do a "make -j 3 buildworld" in 60% of the time with the second CPU enabled (58 minutes) compared to one CPU (97 minutes).
Yes, the GL sucks, and the SMPng stuff will (eventually) be great. But depending upon what your load mix is, you can get full use out of your second CPU now.
BT is an ISP (among other things). If they can take money (and business) from other ISPs, it benefits them. But they want the rest of the web and its underpinnings to flourish so they can make even more money. It's not much use being an ISP if there are no browsers, web sites, and so on. But BT thinks it would be a lot of fun to ding all the other ISPs.
-EdThis is embedded, stand-alone software. How would you propose that someone hack into it? Stability is the issue, not security, at least in this application.
With the exception of certain big-ticket items that Congress likes to throw money at (planes, tanks, weapon systems -- anything that funnels sufficient money into a given congressman's district) the military is pretty cost-conscious.
What you said! When you filter out the trolls and the dogmatists (you know, license lawyers and such who spout the same canned opinions every chance they get), most technical articles have maybe 20-35 responses. Even such solidly technical Linux-oriented stuff like ReiserFS vs. ext3 gets maybe 50 technically relevent responses, with the rest being hearsay or worse.
I'm not complaining, really. The chatter is often what makes Slashdot interesting. Even the trolling is useful to me; it helps prepare me for when my son reaches age 15 or so, and is trying to extend a childhood interest in fart jokes to the ultimate level of sophistication. ;-)
"The number of posts on Usenet"??? I'd say that your chain of reasoning has a fatal flaw right from the start. Very little technical BSD discussion is conducted via Usenet.
Frankly, OpenBSD gets discussed more often on Usenet due to emotional, not technical reasons. That's not to say that the issues discussed aren't technical, just that things like security and encryption tend to elicit vocal opinions.
Of course, you're probably the same FUD-meister who shows up in any BSD discussion that appears on the Slashdot front page. Or perhaps there are several of you who make posting the same drivel some sort of hobby. In any case, your anonymous status suits your overall lack of credibility. Not sure why I bother...
There is a real advantage to a laptop that can run on batteries during a transcontinental flight (and not just for watching DVDs). And although I agree that a 486 should be just fine for word-processing, the folks in Redmond (and Santa Clara) have had different ideas; I'd hate to use Office 2000 on such a unit.
Long battery life doesn't have much geek value, but for many of the folks who buy new laptops it may be the most important thing.
There is more truth to what she wrote than you might think. The ability to communicate and to lead ends up being equally important to technical knowledge in the "real world." I've known enough mediocre techies with better-than-average people skills who wound up becoming good technical managers to see that a better-rounded background is more important to success in high-tech business than technical competence alone. Of course, the outstanding engineer with leadership skills will go even farther (evidence the Andy Groves and David Hewletts of the world -- and, I would venture, the Linus Torvalds, too). But such talents are too rare to fill middle management.
You may feel that engineers don't receive enough recognition for what they do, and you may well be right. But, with some notable exceptions, businesses aren't run by engineers. They are run by managers who are more likely to have a liberal arts background than an engineering background.
You may be so blinded by what you consider is or isn't "real work" that you can't see how the world around you actually behaves. Make fun all you want of what managers do, but I'd rather bet on a team of twenty average engineers and four good managers than twenty-four superstar engineers working on their own (or with poor managers, which is pretty much the same). Leadership -- the ability to articulate a common goal and lead a group toward it -- is how real work typically gets done. And leadership is more likely to spring from a knowledge and understanding of human thinking and culture than from technical knowledge. Thus it's interesting, but hardly surprising, that the few engineering programs which include liberal arts requirements as well as engineering training (such as Stanford's) produce so many of our technical leaders.
"rwx" permissions existed in Unix from its creation, so by definition they are Unix-like. That doesn't mean they are the best way (look at Plan 9's credential system for more recent ideas from Unix's creators), but they are what Thompson & Ritchie used in place of the more more capable (and complex) mechanisms of Multics.
Jordan writes that open-sourcing OS X would be a "very bold and aggressively forward-thinking" thing for Apple to do. That may be an understatement; I'm sure there are many at Apple who feel it would be suicide.
Apple makes a lot of their money from selling hardware. Say what you want about the price/performance of that hardware, people buy it not just because of its looks (perhaps in spite of them), but because it is the only way to obtain the Mac GUI and run Mac apps. Open-source all of OS X, and in a matter of weeks the Mac GUI will be running on non-Apple hardware that costs a third of Apple's prices, and in a matter of months the Mac apps will start to follow. At least this would be their fear, and it is hardly a groundless one.
I agree with Jordan that leveraging OS X's open-source-friendly Unix base with the Mac GUI and apps would create a major force to be reckoned with -- perhaps even the Microsoft-toppling force he envisions. But I don't think Apple sees their share of that potential market as offsetting the downside to their hardware business. Perhaps there is a way they can assure a sufficient fraction of the resulting software market to make up for that loss, but I've yet to see a convincing argument of how they could do so.
Linus' comment on this:
All due respect to Mr Torvalds, but I'm not sure he understands the intent behind the kqueue interface. It's not just intended to be a poll() on steriods, though it serves that function. A kevent does not need to be related to a file descriptor--for example, signals and the status of other processes can also be monitored with the appropriate filter. Other filters will be added as time goes on. The tuples Linus objects to are actually the simplest way to provide this level of generality through a single interface.
Yup, why go to a plumbing store when you can go to a pipe store, a T-fitting store, a faucet store, etc.? Face it, aggregation, whether products or information, can be extremely useful. Aggregation is done by "middlemen," and there are useful middlemen, and useless middlemen. As a matter of fact, in the "real world" the more efficent middlemen (e.g. WalMart) are getting increasingly powerful--they are hardly being "gotten rid of"--by their efficiencies in aggregating products and services in a convenient and useful way.
Another example: TV networks (cable or broadcast) aggregate programs from a variety of producers; a minority of programs are actually produced in-house. They run ads and use the proceeds to buy those programs. Some channels (e.g. HBO) charge instead; you can choose not to pay, and still get what the other channels provide. Viacom, for instance, owns both subscriber- and ad-supported channels. I don't see them all of a sudden deciding to make MTV a pay channel, do you?
Not to put too fine a point on it, but TNSTAAFL. (There's No Such Thing As A Free Lunch.) Aggregation has value, but it also has costs. The latter are going to get passed to you one way (advertising) or another (direct charges). If you don't find that service worth the price, go without or create your own.
I agree that the C++ ABI issue is a horrible mess, but you really can't blaim AT&T for that. If the C++ ABI had been set back in early days, it would have had to be revised several times over the years as templates, namespaces, and so forth were added to the language. For this to have been any better than the present situation, a much more extensible object file format would have to have been created than we use today.
The real issue is that C and C++ still use a flat namespace for symbols in object files, just like in the 1950's when assembler languages were all that existed. The minor additions made to ELF for static constructors and the like were the absolute minimum to get C++ to work--leaving no option but kludge-of-the-day name mangling to flatten C++'s multitude of hierarchies. This is so inelegant that no one wanted to define it into a standard -- surely a better way will arise? But it hasn't.
CFront's name mangling could have been taken as the de facto standard and extended as C++ was extended. That didn't happen, and given that AT&T didn't "own" C++ the way that Sun owns Java, it probably wouldn't have happened even if they pushed it. But why perpetuate what is an ugly kludge, anyway?
It's probably too late to fix the real problem. Rejiggering the entire toolchain for a new object file format just isn't going to happen. (Some people are still smarting after the change to ELF.) So we'll have to live for the forseeable future with fragile and incompatible attempts to fit N-dimensional structures into flat lists...
I use it daily. And I've been stung by misoptimizations enough that I no longer even bother trying anything beyond -O1 on critical code. And this is on i386. RedHat releases on Alpha, which you admit "wasn't great." A lot of Alpha issues got solved post-2.95.2. I have no inside knowledge of RedHat, but this might have weighed fairly heavily in their decision.
I've used GCC since 1.X days, and it used to be that it was the equivalent or better of almost any vendor's compiler. That's no longer true. Where I work, GCC 2.95.2 has such a bad rep for miscompiling or crashing that nearly all production code is compiled with EGCS 1.1.2 -- or GCC 2.7.2.3. We might just be unlucky, or perhaps GCC 2.95.2 has more problems when dealing with legacy C++. But the latter would still be a major defect in GCC.
As to whether 2.95.2 is the "buggiest": I have experienced more grief from 2.95.2 than any earlier release. I have seen more people have problems with it than any earlier release. I've managed to avoided the 2.8 series, though, so I'll have to take back my claim of 2.95.2 being the "buggiest," since judging by its repulation 2.8 might well have been worse.
As for what Debian uses, 2.95.2 is also the production compiler for FreeBSD 4.x (which is most often where I use it, though I do some development on Linux and Solaris as well). And unlike Debian, the FreeBSD folks are not at all happy with it.
I agree that GCC testing has improved a lot; I've scanned the GCC developer's list from time to time, and I'm quite impressed at how much rigor has been added to the testing process, and how it has been made an integral part of development. This is probably why snapshots seem to be a lot more solid than they did early in the EGCS project.
This is why 2.95.2 was an enormous (negative) surprise to me. I'd talked up EGCS and the EGCS development process from EGCS 1.0 on, and converted a lot of folks to using EGCS. I had even greater hopes for it when it was made the official GCC. The testing regime seemed promising, a lot of good developers (including yourself) were slaving away at making GCC better and better, so I fully expected something "better than EGCS." Perhaps calling it "the buggiest" is a bit of an overstatement, but I feel disappointed and a bit betrayed.