As my boss is fond of saying, there's more than 100% of blame to go around. You can blame the user for running beta software, and still blame the developer for releasing a faulty product. Any time anything serious like deletion of a home directory happens, *all* parties should be asking themselves "What can I do to prevent this in the future?"
But it's hard to expect much from users. Developers are held to a higher standard -- they're expected to know what they're doing.
Beta does *not* mean "use at your own risk". Beta software might not do its job properly, but that doesn't mean it should randomly delete user data.
Anyone who releases software that can delete your home directory is irresponsible, whether they call it beta, alpha, whatever. (Cue joke about AT&T being irresponsible for releasing "rm".)
By the way, pkg_add in FreeBSD 2.1.5 once blew away my home directory. The author apologized to me and had a free set of 2.1.7 CDs sent to me. Now *that's* customer service.
The hole was that an attacker could theoretically cause locally-submitted mail to be deleted. I say "theoretically" because it was quite difficult. I am not aware of any reports that this vulnerability was ever exploited in the field.
Sendmail is definitely more usable with m4. But it's still pretty annoying to have to preprocess one's config file. If I ran the world, sendmail would optionally preprocess its config file itself. In other words, you'd be able to use the m4 file directly.
I'm a unix user since 1996, I don't mind using a one-button mouse.
Why journaling? It's not useful for most people.
The compiler should be gotten from Apple, not from lanl.gov. And developer.lanl.gov doesn't exist.
The window manager to use is OroborOSX, not oroboros. That's why it's different from the one in fink.
The "extra layers of file permissions" you speak of are not unique to Mac OS X. On any BSD system, look at the man page for chflags(1), and see the '-o' option to ls(1).
Starting with version 10.2, some of the files in/etc are checked before NetInfo. So some of those files you mention _can_ be used in the traditional way.
I don't think it's very cool to complain about misinformation and then post a ton of it. You posted some excellent advice as well, but I was only able to tell the wheat from the chaff because I'm already familiar with unix and Mac OS X.
If the new iPod owners were to set up MP3 sharing on company servers, then the company could be liable. But liable to the RIAA for giving away iPods? Forget it.
Well, they moved perl and games out of the base system, and they took i386 support out of the default kernel build. I don't know how it is over-all, but those are steps in the right direction.
4.4BSD was the last full release from the Computer Science Research Group at UC Berkeley. I think it was in 1994. FreeBSD and NetBSD were based in large part on this code. (This is an oversimplification but it's good enough.)
Mac OS X is based on NeXTStep, which includes BSD code from 4.3BSD, which came before 4.4BSD. Mac OS X was updated using FreeBSD 3.4 as a reference. There was no wholesale integration of FreeBSD 3.4. Mac OS X 10.2 was updated using FreeBSD 4.3 as a reference, I believe. Again, no wholesale integration. The same will be the case with FreeBSD 5.
Darwin and Mac OS X have a startup script system that is structurally similar to the one used by NetBSD and now FreeBSD. However, it is a different implementation. It is new with Mac OS X -- NeXTStep used a traditional BSD-style init.
It sounds to me like you're doing a poor job of managing expectations. When someone approaches me for side work, I explain to them that there are certain types of work I prefer to avoid, and I make it clear that I expect to be compensated for all work that I do.
Before I did things this way, I had the same kinds of problems you're having. It is tough.
I think we're in violent agreement here.
As my boss is fond of saying, there's more than 100% of
blame to go around. You can blame the user for running
beta software, and still blame the developer for releasing
a faulty product. Any time anything serious like deletion
of a home directory happens, *all* parties should be asking
themselves "What can I do to prevent this in the future?"
But it's hard to expect much from users. Developers are
held to a higher standard -- they're expected to know what
they're doing.
Beta does *not* mean "use at your own risk". Beta software
might not do its job properly, but that doesn't mean it
should randomly delete user data.
Anyone who releases software that can delete your home
directory is irresponsible, whether they call it beta, alpha,
whatever. (Cue joke about AT&T being irresponsible for
releasing "rm".)
By the way, pkg_add in FreeBSD 2.1.5 once blew away my
home directory. The author apologized to me and had a
free set of 2.1.7 CDs sent to me. Now *that's* customer
service.
I read about this years ago, and I've discussed it
with Wietse, and I stand by my assessment.
The hole was that an attacker could theoretically cause
locally-submitted mail to be deleted. I say "theoretically"
because it was quite difficult. I am not aware of any
reports that this vulnerability was ever exploited in the
field.
The hole -- which was very, very small to begin
with -- has been closed. Please stop spreading
misinformation.
And when was the last serious security problem in sendmail?
There are a lot of wannabes going around repeating old news
and thinking they're hip.
Sendmail is definitely more usable with m4. But it's still
pretty annoying to have to preprocess one's config file.
If I ran the world, sendmail would optionally preprocess
its config file itself. In other words, you'd be able to use
the m4 file directly.
Can you document your claim?
Now I have to endure another six months of
endless whining on Slashdot and the rumor sites.
Domine, libera me.
People's Front of Judea, anyone?
News flash: for most intents and purposes, the
similarities between Linux and BSD are far more
significant than the differences.
I'm a unix user since 1996, I don't mind using a
/etc are checked before NetInfo. So some of
one-button mouse.
Why journaling? It's not useful for most people.
The compiler should be gotten from Apple, not from
lanl.gov. And developer.lanl.gov doesn't exist.
The window manager to use is OroborOSX, not
oroboros. That's why it's different from the one
in fink.
The "extra layers of file permissions" you speak
of are not unique to Mac OS X. On any BSD
system, look at the man page for chflags(1), and
see the '-o' option to ls(1).
Starting with version 10.2, some of the files in
those files you mention _can_ be used in the
traditional way.
I don't think it's very cool to complain about
misinformation and then post a ton of it. You
posted some excellent advice as well, but I was
only able to tell the wheat from the chaff
because I'm already familiar with unix and Mac OS X.
The parent poster is living in a fantasy world.
If the new iPod owners were to set up MP3 sharing
on company servers, then the company could be liable.
But liable to the RIAA for giving away iPods?
Forget it.
Can you point me to an example?
Somebody told a biologist that "BSD is stable" and
they drew the wrong conclusion.
Well, they moved perl and games out of the base
system, and they took i386 support out of the
default kernel build. I don't know how it is
over-all, but those are steps in the right
direction.
You're quite confused, but I don't blame you.
4.4BSD was the last full release from the Computer
Science Research Group at UC Berkeley. I think it
was in 1994. FreeBSD and NetBSD were based in large
part on this code. (This is an oversimplification
but it's good enough.)
Mac OS X is based on NeXTStep, which includes BSD
code from 4.3BSD, which came before 4.4BSD. Mac OS
X was updated using FreeBSD 3.4 as a reference.
There was no wholesale integration of FreeBSD 3.4.
Mac OS X 10.2 was updated using FreeBSD 4.3 as a
reference, I believe. Again, no wholesale
integration. The same will be the case with
FreeBSD 5.
Darwin and Mac OS X have a startup script system
that is structurally similar to the one used by
NetBSD and now FreeBSD. However, it is a different
implementation. It is new with Mac OS X -- NeXTStep
used a traditional BSD-style init.
Error-correction happens mainly or entirely below
PPP, in the modem firmware.
Where do you live?
It sounds to me like you're doing a poor job of
managing expectations. When someone approaches
me for side work, I explain to them that there
are certain types of work I prefer to avoid, and
I make it clear that I expect to be compensated
for all work that I do.
Before I did things this way, I had the same kinds
of problems you're having. It is tough.
I know lots of people who use Mozilla or Netscape.
Mozilla is 100% open source, and Netscape is close.
The problem is accountability. With wireless
connectivity, it can be very difficult to trace
network abuse further than the owner of the
access point.
Fans do fail. Intel chips will slow down or shut
down if they get too hot, to keep from self-destructing.
It's just a collective crush, dude. No mystery here.