The number is very illustrative of what
a very tiny portion of the Linux community can accomplish cooperatively, through Bazaar style work.
On the other hand, you have supplied absolutely no evidence or reason to believe the metric or this use is "bullshit"
Instead, you are irrationally arguing a point that you apparently cannot logically support, by calling it names, or attempting to attach deceptive labels such as "bullshit".
Two studies came up with the same result, so it's not BS at all.
And includes only the time it took to develop the Linux kernel itself, not all the OSS development efforts by third parties such as GNU, of critical components, and of documentation.
Software development requires expertise, and still all those hundreds of thousands of man-years worth of work have been done.
Imagine how much work the community can do, inclusive of people not having specialized software development skills?
Billions of people who couldn't/wouldn't want to do kernel hacking are readily available for assisting with the reviewing / packaging / adding software to the repository.
Doing basic checks/testing on software to make sure it's proper and get it into a repository is much easier, quicker, less expensive work than actually writing it or even than writing its documentation.
What part of "Windows default registry permissions are open widely enough for Power Users to elevate themselves to Administrators" don't you understand?
Also, don't you think Windows XP's Compatibility mode is inherently risky?
Programs will be run based on their name, in a mode where they can make low-level calls...
The worm's main code wasn't BSD-specific. It could infect 4BSD systems on DEC VAX machines, and Sun 3 systems. These systems bear no similarity to todays OSes
The worm's infection vector was a portable C stub though "11.c", and was OS-agnostic. It could "hurt" systems running other OSes, even though the main code would not run.
It exploited vulnerabilities in rsh, fingerd, sendmail, and attempted to crack weak passwords.
Facilitated by the fact that "encrypted" passwords were publicly visible in/etc/passwd
and valid usernames on one machine are likely valid usernames on other machines.
It was not a trojan.
Link:
Although sendmail was the Worm's least favored attack method (it was only tried after all other attempts had failed), it too was a powerful method of intrusion. At one site in Utah, nearly 150 sendmail attacks were logged on November 2 alone.
The Worm takes advantage of a flaw in the TCP networks for Berkeley UNIX systems (used in sending e-mail). When the program was being designed, a DEBUG flag was included with it in order to facilitate testing of the program. One of the capabilities of this flag was that it allowed someone to send mail to a process, rather than a user account. Unfortunately, when the program was finished and compiled for distribution, this feature was never removed....
On a Linux system it's almost unheard of for individual programs to check for updates.. that's extremely wasteful, and you probably don't want it.
Programs are to be updated by the system package manager, which handles all that.
You presumably know what your IM, streaming, P2P, and IP apps are, and what ports they should be using.
Or perhaps your distribution vendor could publish a ruleset for you, based on each app, and the connections it's "expected" to make.
You best hope the malware doesn't gain root though: the very first thing it would do is "hack" the reporting app's ruleset to ignore itself.
Conficker is proof that such worms are not pretty much history.
Stating your own counterexample doesn't invalidate it.
Windows 2003's successors such as Windows 2008 are all very young, and not (yet) widely deployed. They have not been "proven" secure; therefore, they should be assumed to be insecure like Windows 2003, until proven otherwise.
Your remark's like saying this type of malware is history in 2 weeks, because there's going to be a new point release of Ubuntu! So the new version of Ubuntu is automatically invincible to all malware until proven otherwise!!!
Also, most malware nowadays does not come as trojans that the user downloads and runs from disk.
Most malware infections nowadays (on Workstations) are caused by "drive-by downloaders" that exploit bugs in Internet Explorer.
It's fascinating this is still true, given the very high market penetration of Firefox...
one would expect there to be more malware infections due to drive-by-downloaders targetting Firefox.
I wonder why that might be...
Firefox is a great example proving that Open source development results in more secure software.
So, there are at least two pieces of evidence against anyone who wants to claim Open source software isn't any more secure than Windows against malware.
You're making a leap in logic here. The existence of a malicious Linux program does not indicate that the Linux platform is less secure than Windows against malware threats.
On the contrary, there is strong evidence otherwise, given:
(A) Windows users commonly run with 'Administrator' rights, because many software programs require it. The Administrator user has rights that are useful to malware, such as the ability to change system configurations, including the DNS resolver config: the ability to modify/add system files, including the "hosts" file.
(B) In the Linux world, it is common that users run as "non-root"; this non-administrative user cannot change global system configurations.
Among things non-root cannot do:
Cannot access arbitrary process memory and manipulate/read things out of browser processes. Common default security configs prohibit even attaching a debugger.
Cannot: discover the user's login password as they login. (Since non-root-installed malware cannot be running while the system is at login prompt)
Cannot Modify global system files (such as/etc/hosts)
Cannot Delete or modify system utilities and software used to detect/kill unwanted programs such as "/bin/ps", "/bin/kill"
Cannot capture passwords being transmitted across the network, spoof IP addresses, arp spoof other hosts on LAN, etc (only root can try that junk)
Cannot modify the web browser (such as Epiphany or Konqueror), to intercept web traffic or credentials, since the system files are not writable to non-root user.
Cannot create additional users, to allow an attacker access.
Cannot change firewall rules to allow attacker traffic, or to allow outbound traffic in violation of configured egress policy.
Since standard firewall settings for most distros block inbound connections; cannot run a web server ti serve a phishing site.
Since common Linux firewall settings block most outbound ports, including port 25 (except to ISP mailserver and hosts on the LAN), malware cannot send spam.
Ability to "log" keystrokes is very limited, due to the X security model. Malware cannot log keystrokes for other users' X sessions. Secure X applications can also "lock" the keyboard into secure mode, assuring that no other applications running as even the same user can log anything.
Cannot destroy or manipulate other users' files.
Whereas on Windows cannot is not true. Because malware running on Windows can accomplish all those things.
Some of them require Administrator, but most users run Administrator.
For the few that don't... Windows has more unpatched, "secret" Administrator privilege escalation security bugs, than common Linux distros' bugs of all types, over their entire lifetime.
But the notion of Trojan applies here; you download a seemingly innocent program, but it contains a hidden nefarious payload.
AV software makers love it, because it means that once software gets classified as Malware instead of an actual virus, they don't have to worry about detection and safe removal anymore, that's another program's job...
It's a paradoxical situation where we have two true concepts that appear to be contradictory but are not, in actual fact.
The redacted material has already been made "public", it's just well hidden, such that much of the public doesn't immediately observe it.
The people who thought they redacted the material successfully, won't have cause to learn they didn't (as evidenced by lack of material appearing online).
Another real-world example would be professor who re-uses old tests, but nevertheless passes out and lets students keep their completed test/exam sheet after they had been graded.
That is: every single test is identical every semester, the answers are always the same, and every student receives the same test.
Let's also say the tests are extremely hard and basically impossible for the average person to pass; the difficulty in formulating the answer is presumed to make it obscure (just like blacking out text is meant to make text obscure).
Some students may seek out past students and quietly share/obtain past test information (e.g. a research unmasking redacted information to satisfy their own curiosity).
The professor is blissfully unaware of such practices/quiet past-test-sharing that occur outside the classroom between new students and past-year students.
Let's say there's no explicit rules against it, the teacher never ordered students not to share their tests with past students, and encouraged students to compare their graded answers with others' anyways.
It's a senior class, and prof. never imagined people might share such things as scans of past tests, on Facebook, and other social networks.
Until one day, some babboon from a previous year
sneaks into a classroom on the first day of the next semester, and 10 minutes before class starts, posts the answers to all the previous tests (all questions and complete key), on the blackboard, in plain sight.
The professor walks in... of course now everyone's screwed, because the professor will draw up new tests this go around:)
NTFS gets badly fragmented, as in 80% file fragmentation frequently under many types of load, and the fragmentation of NTFS effects performance substantially.
And NTFS doesn't provide self-defragmentation.
40% fragmentation is "normal" for a NTFS filesystem.
It can only be fixed by running a manual tool 'defrag', which is a dangerous procedure (although it _has_ become a bit safer over the years), it's still potentially troubling, degrades performance, and requires lots of free disk space to work properly.
Linux ext3 or BSD FFS is considered severely fragmented if you get 15% of fragmentation. It can happen, but it's exceedingly rare, under almost all common load scenarios, fragmentation never becomes a real performance issue with FFS or ext3, even at such high levels.
But that's a side-issue, really:
Well, the main problem is with NTFS on Windows, due to Windows' security issues, and bloat.
Windows includes complex libraries and software that are unnecessary for a NAS, and frequently present stability or security issues.
For example: the (very bloated) console GUI, DirectX, Internet Explorer, Windows RPC services.
Some services that may be useful for some types of NAS apps however: mainly file sharing with Windows desktop PCs, e.g. LOW-END NAS uses.
However, Eg.: I don't think Windows Storage server is a good choice for a NAS that needs to be highly available (for example, to run virtual machines), and needs to serve NFS and iSCSI.
Stable NTFS-3G is fairly young (~2 years), however, and, i'm not sure that it's as stable as the Windows implementation.
Frankly, I wish attention-whores wouldn't undo the blackout for them and post online, they're doing security work for the TSA, in helping them to better hide/censor pieces of documents from the public that are generally not worth censoring.
Whatever was struck out was done so for a reason, and this recovery of censored text is very poor form (read: unethical, possibly illegal) behavior.
The blacking out may be generally not bulletproof, however, it's sufficient for the casual viewer.
Yeah. If they didn't post the un-blacked out version, some people still see it.
Expert computer users who are unlikely to be abusing whatever info might be there.
But apparently not the case, as at least one person who can see through their artificial text blackout -- was so abusive as to post it to the public; a highly abusive act.
When TSA sees this, it means they won't make the same mistake again, which ultimtely results in less useful information released to the public.
You think blacking it out with a marker and then photocopying it hides the original text from detailed forensic document analysis techniques?
Maybe... it depends on how dark the marker is, and how similar the shade of the pen ink is to the marker ink.
Branches such as the TSA aren't privvy to truly classified info.
Surely the military, FBI, or NSA, would never manage a mistake like this.
Just find a netbook that is equal or better than a "laptop", and you'll have proven that Netbooks aren't low-end laptops, since you have a laptop with even worse specs than a Netbook:)
IRC/Jabber servers running inside the country are easily traced and killed, as in, soldier goes to the person's house, puts a bullet through the server, and takes the owner away in cuffs to be subject to criminal charges.
Well, Linux does have problems dropping or corrupting bits, and can't detect corrupted bits like ZFS can, which means that silent data corruption is possible.
It's not necessary that Linux causes the corruption. The problem is corruption occurs that Linux can't fix / deal with reasonably, or the way Linux filesystems work is high-risk, and ext3 fsck is horrible, in that data loss or inconsistency of I/Os results and cannot be corrected, despite the fact the filesystem is "journaled": in fact, ext3 journaling is not true journaling, by default, ext3 operates in the less-reliable journal_data_ordered, and not journal_ordered; thus, only metadata is journaled, and data corruption is likely if power or access to storage is disrupted.
The ext3 / ext4 filesystems do not live up to the "journalling" promise.
It's happened too many times to count, that I have lost important data, database, or even entire systems due to Ext3 shenanigans, on Debian Etch, Ubuntu, Redhat Enterprise Linux 4, and Redhat Enterprise Linux 5.
Usually how it happens is a kernel panic, power outage, reset (due to system lock-up), or something of that nature occured, and upon boot, the journal is aborted -- however, there is still data corruption after abort of the journal, or even, the abort of the journal fails, and it becomes necessary to manually run fsck, which "tinkers around with the filesystem" trying to make the metadata consistent again.
I have yet to ever have any issues with ZFS-based or NTFS-based systems; they handle it seamlessly.
Windows 2003 or 2008 may show a blue screen once every 2 or 3 years, but the system doesn't require an expert to travel out and manually run chkdsk (Windows equivalent of fsck).
And ZFS handles this quite elegantly....
By the way, even NTFS is ahead of ext3 in some ways, in this regard, as far as self-healing is concerned.
Just because it runs Linux doesn't mean the physical disks are magically immune to common issues that effect all storage.
Linux isn't the worst choice for a NAS.
(In fact, I would be really scared of the idea of using NTFS for a NAS).
However, it's just as dishonest to suggest Linux Debian is rock-solid for a NAS as it is to suggest Windows 2000 is.
FreeBSD or Solaris is a really good choice for a NAS.
Systems that utilize certain versions of the Linux kernel can be a good choice, with the right configuration, and right supporting programs installed.
For example, a dedicated NAS appliance, can easily provision its ext3 filesystems using SAFE journalling options, instead of the defaults.
And can also pick just the right kernel version and library versions to be as stable as possible under the supported hardware list...
It's not necessarily good for a NAS to support as much hardware as possible: The Number 1 cause of system crashes is faulty hardware or faulty hardware drivers.
It's best to stick with old hardware and driver code that has been around for 5+ years, without major bugs detected.
And to have kernels with isolation features such as IOMMU and NX bit.
It doesn't matter how long you wait between releases, if the quality of your userland is poor.
Junk in, junk out.
Holding releases or releasing slowly does not improve code quality or eliminate bugs. Although it can give you more time to find certain issues before releasing, certain issues will only be found by your users --- and then, your slow release process hurts you (means it takes longer to fix bugs, since releases are so far apart).
Today Olivier Cochard-Labbé has made a great announcement, FreeNAS will live on and production ready ZFS support will be added with the upgrade to FreeBSD 8.0. At the same time a new Linux version of FreeNAS will be created called OpenMediaVault!
...
Olivier explained it like this: FreeNAS needs some big modification to remove its present limitations (with one of the biggest being the lack of support for add-ons/plugins). We think that a full-rewrite of the FreeNAS base is needed. Therefore, we will take 2 different paths:
1. Volker will create a new project called “‘OpenMediaVault” based on a
GNU/Linux and use all his experience acquired with all those nights and week-ends spent improving FreeNAS during the last 2 years. He will still
continue to work on FreeNAS
2. And, a great surprise: iXsystems (http://www.ixsystems.com/), a company specialising in professional FreeBSD systems has offered to take FreeNAS under its wing as an open source community driven project. This means that they will use their professionals FreeBSD developers to better FreeNAS! Their manpower will permit a full-rewriting of FreeNAS.
Olivier also added that he will personally come back to actively working on FreeNAS and begin to upgrade it to FreeBSD 8.0 (which is “production ready” for ZFS).
The device you plug into is a single point of failure anyways (potentially).
If the same device exposes a DHCP equivalent to its direct ports, and handles inter-plugin-device addressing properly (when multiple plugin-devices interconnect), then the DHCP equivalent's not an additional point of failure.
Also, DHCP doesn't have to be a single point of failure even on a LAN -- multiple DHCP servers can be used, with a supernet split according to the 80/20 rule.
Also, unless the static IP addresses are of the IPv6 sort, or EUI-64/48 (64-bit or 48-bit MAC addresses), there is a point of failure introduced -- as in the equivalent of an IP conflict.
Slashdot Mirror
The number is very illustrative of what a very tiny portion of the Linux community can accomplish cooperatively, through Bazaar style work.
On the other hand, you have supplied absolutely no evidence or reason to believe the metric or this use is "bullshit"
Instead, you are irrationally arguing a point that you apparently cannot logically support, by calling it names, or attempting to attach deceptive labels such as "bullshit".
It's not. It is based on two real studies, based on: number of man hours.
Two studies came up with the same result, so it's not BS at all.
And includes only the time it took to develop the Linux kernel itself, not all the OSS development efforts by third parties such as GNU, of critical components, and of documentation.
Software development requires expertise, and still all those hundreds of thousands of man-years worth of work have been done.
Imagine how much work the community can do, inclusive of people not having specialized software development skills?
Billions of people who couldn't/wouldn't want to do kernel hacking are readily available for assisting with the reviewing / packaging / adding software to the repository.
Doing basic checks/testing on software to make sure it's proper and get it into a repository is much easier, quicker, less expensive work than actually writing it or even than writing its documentation.
You're suggesting there are enough human resources to develop a $2 Billion dollar operating system (the Linux kernel)...
But not enough resources to take submissions, and include all the reputable software people actually want in the repository?
This is something like using a computer virus to develop software.
Linux software. By having it infect Windows programs and cause them to self-destruct.
Leaving behind their rich amounts of data...
What part of "Windows default registry permissions are open widely enough for Power Users to elevate themselves to Administrators" don't you understand?
Also, don't you think Windows XP's Compatibility mode is inherently risky?
Programs will be run based on their name, in a mode where they can make low-level calls...
The worm's main code wasn't BSD-specific. It could infect 4BSD systems on DEC VAX machines, and Sun 3 systems. These systems bear no similarity to todays OSes
The worm's infection vector was a portable C stub though "11.c", and was OS-agnostic. It could "hurt" systems running other OSes, even though the main code would not run.
It exploited vulnerabilities in rsh, fingerd, sendmail, and attempted to crack weak passwords. Facilitated by the fact that "encrypted" passwords were publicly visible in /etc/passwd
and valid usernames on one machine are likely valid usernames on other machines.
It was not a trojan.
On a Linux system it's almost unheard of for individual programs to check for updates.. that's extremely wasteful, and you probably don't want it. Programs are to be updated by the system package manager, which handles all that.
You presumably know what your IM, streaming, P2P, and IP apps are, and what ports they should be using.
Or perhaps your distribution vendor could publish a ruleset for you, based on each app, and the connections it's "expected" to make.
You best hope the malware doesn't gain root though: the very first thing it would do is "hack" the reporting app's ruleset to ignore itself.
Conficker is proof that such worms are not pretty much history.
Stating your own counterexample doesn't invalidate it.
Windows 2003's successors such as Windows 2008 are all very young, and not (yet) widely deployed. They have not been "proven" secure; therefore, they should be assumed to be insecure like Windows 2003, until proven otherwise.
Your remark's like saying this type of malware is history in 2 weeks, because there's going to be a new point release of Ubuntu! So the new version of Ubuntu is automatically invincible to all malware until proven otherwise!!!
Also, most malware nowadays does not come as trojans that the user downloads and runs from disk.
Most malware infections nowadays (on Workstations) are caused by "drive-by downloaders" that exploit bugs in Internet Explorer.
It's fascinating this is still true, given the very high market penetration of Firefox... one would expect there to be more malware infections due to drive-by-downloaders targetting Firefox.
I wonder why that might be...
Firefox is a great example proving that Open source development results in more secure software.
So, there are at least two pieces of evidence against anyone who wants to claim Open source software isn't any more secure than Windows against malware.
Both. You are imagining a false dichotomy where there is none.
Getting as much of the 3rd party software as possible into the repository does not preclude raising the threshold of entry.
Some software you want to fall below the threshold is no-name drive-by malware.
You're making a leap in logic here. The existence of a malicious Linux program does not indicate that the Linux platform is less secure than Windows against malware threats.
On the contrary, there is strong evidence otherwise, given:
(A) Windows users commonly run with 'Administrator' rights, because many software programs require it. The Administrator user has rights that are useful to malware, such as the ability to change system configurations, including the DNS resolver config: the ability to modify/add system files, including the "hosts" file.
(B) In the Linux world, it is common that users run as "non-root"; this non-administrative user cannot change global system configurations. Among things non-root cannot do:
Whereas on Windows cannot is not true. Because malware running on Windows can accomplish all those things.
Some of them require Administrator, but most users run Administrator. For the few that don't... Windows has more unpatched, "secret" Administrator privilege escalation security bugs, than common Linux distros' bugs of all types, over their entire lifetime.
It's a Trojan Horse
Malware is a generic term for malicious software.
But the notion of Trojan applies here; you download a seemingly innocent program, but it contains a hidden nefarious payload.
AV software makers love it, because it means that once software gets classified as Malware instead of an actual virus, they don't have to worry about detection and safe removal anymore, that's another program's job...
And that's why it needs a recent bugfix to stop it from crashing and corrupting filesystems on fragmented files?
That's not an exception to the rule. NTFS-3G doesn't have a comparable track record to Linux ext3 and Windows native NTFS implementations.
It's a paradoxical situation where we have two true concepts that appear to be contradictory but are not, in actual fact.
The redacted material has already been made "public", it's just well hidden, such that much of the public doesn't immediately observe it.
The people who thought they redacted the material successfully, won't have cause to learn they didn't (as evidenced by lack of material appearing online).
Another real-world example would be professor who re-uses old tests, but nevertheless passes out and lets students keep their completed test/exam sheet after they had been graded.
That is: every single test is identical every semester, the answers are always the same, and every student receives the same test.
Let's also say the tests are extremely hard and basically impossible for the average person to pass; the difficulty in formulating the answer is presumed to make it obscure (just like blacking out text is meant to make text obscure).
Some students may seek out past students and quietly share/obtain past test information (e.g. a research unmasking redacted information to satisfy their own curiosity).
The professor is blissfully unaware of such practices/quiet past-test-sharing that occur outside the classroom between new students and past-year students.
Let's say there's no explicit rules against it, the teacher never ordered students not to share their tests with past students, and encouraged students to compare their graded answers with others' anyways.
It's a senior class, and prof. never imagined people might share such things as scans of past tests, on Facebook, and other social networks.
Until one day, some babboon from a previous year sneaks into a classroom on the first day of the next semester, and 10 minutes before class starts, posts the answers to all the previous tests (all questions and complete key), on the blackboard, in plain sight.
The professor walks in... of course now everyone's screwed, because the professor will draw up new tests this go around :)
NTFS gets badly fragmented, as in 80% file fragmentation frequently under many types of load, and the fragmentation of NTFS effects performance substantially. And NTFS doesn't provide self-defragmentation. 40% fragmentation is "normal" for a NTFS filesystem.
It can only be fixed by running a manual tool 'defrag', which is a dangerous procedure (although it _has_ become a bit safer over the years), it's still potentially troubling, degrades performance, and requires lots of free disk space to work properly.
Linux ext3 or BSD FFS is considered severely fragmented if you get 15% of fragmentation. It can happen, but it's exceedingly rare, under almost all common load scenarios, fragmentation never becomes a real performance issue with FFS or ext3, even at such high levels. But that's a side-issue, really:
Well, the main problem is with NTFS on Windows, due to Windows' security issues, and bloat. Windows includes complex libraries and software that are unnecessary for a NAS, and frequently present stability or security issues.
For example: the (very bloated) console GUI, DirectX, Internet Explorer, Windows RPC services.
Some services that may be useful for some types of NAS apps however: mainly file sharing with Windows desktop PCs, e.g. LOW-END NAS uses. However, Eg.: I don't think Windows Storage server is a good choice for a NAS that needs to be highly available (for example, to run virtual machines), and needs to serve NFS and iSCSI.
Stable NTFS-3G is fairly young (~2 years), however, and, i'm not sure that it's as stable as the Windows implementation.
Frankly, I wish attention-whores wouldn't undo the blackout for them and post online, they're doing security work for the TSA, in helping them to better hide/censor pieces of documents from the public that are generally not worth censoring.
Whatever was struck out was done so for a reason, and this recovery of censored text is very poor form (read: unethical, possibly illegal) behavior.
The blacking out may be generally not bulletproof, however, it's sufficient for the casual viewer.
Yeah. If they didn't post the un-blacked out version, some people still see it. Expert computer users who are unlikely to be abusing whatever info might be there.
But apparently not the case, as at least one person who can see through their artificial text blackout -- was so abusive as to post it to the public; a highly abusive act.
When TSA sees this, it means they won't make the same mistake again, which ultimtely results in less useful information released to the public.
You think blacking it out with a marker and then photocopying it hides the original text from detailed forensic document analysis techniques?
Maybe... it depends on how dark the marker is, and how similar the shade of the pen ink is to the marker ink.
Branches such as the TSA aren't privvy to truly classified info.
Surely the military, FBI, or NSA, would never manage a mistake like this.
Just find a netbook that is equal or better than a "laptop", and you'll have proven that Netbooks aren't low-end laptops, since you have a laptop with even worse specs than a Netbook :)
Plane tickets cost money... a $100 conference within driving distance of a major city where a majority of the atendees are could be a better thing.
If it's for your employer's benefit, you should be able to convince them to allow you to go without burning vacation time.
Even if you do have to pay for the trip yourself.
But you gotta be prepared to make a really convincing argument that your employer needs you to go there.
No.. well, I think the app will never be approved.
The Apple team will develop it, sure.. but right before the new OS is about to ship, the app approval team will reject the app.
Try on the new version of the Android :)
The price-point seems like highway robbery for what it does.
Pure greed, as further evidenced by ownership drama mentioned in article.
I have no doubt someone started seeing dollar signs, got drunk with greed and started making some really crappy decisions.
IRC/Jabber servers running inside the country are easily traced and killed, as in, soldier goes to the person's house, puts a bullet through the server, and takes the owner away in cuffs to be subject to criminal charges.
Well, Linux does have problems dropping or corrupting bits, and can't detect corrupted bits like ZFS can, which means that silent data corruption is possible.
It's not necessary that Linux causes the corruption. The problem is corruption occurs that Linux can't fix / deal with reasonably, or the way Linux filesystems work is high-risk, and ext3 fsck is horrible, in that data loss or inconsistency of I/Os results and cannot be corrected, despite the fact the filesystem is "journaled": in fact, ext3 journaling is not true journaling, by default, ext3 operates in the less-reliable journal_data_ordered, and not journal_ordered; thus, only metadata is journaled, and data corruption is likely if power or access to storage is disrupted.
The ext3 / ext4 filesystems do not live up to the "journalling" promise.
It's happened too many times to count, that I have lost important data, database, or even entire systems due to Ext3 shenanigans, on Debian Etch, Ubuntu, Redhat Enterprise Linux 4, and Redhat Enterprise Linux 5.
Usually how it happens is a kernel panic, power outage, reset (due to system lock-up), or something of that nature occured, and upon boot, the journal is aborted -- however, there is still data corruption after abort of the journal, or even, the abort of the journal fails, and it becomes necessary to manually run fsck, which "tinkers around with the filesystem" trying to make the metadata consistent again.
I have yet to ever have any issues with ZFS-based or NTFS-based systems; they handle it seamlessly. Windows 2003 or 2008 may show a blue screen once every 2 or 3 years, but the system doesn't require an expert to travel out and manually run chkdsk (Windows equivalent of fsck). And ZFS handles this quite elegantly....
By the way, even NTFS is ahead of ext3 in some ways, in this regard, as far as self-healing is concerned.
Just because it runs Linux doesn't mean the physical disks are magically immune to common issues that effect all storage.
Linux isn't the worst choice for a NAS. (In fact, I would be really scared of the idea of using NTFS for a NAS).
However, it's just as dishonest to suggest Linux Debian is rock-solid for a NAS as it is to suggest Windows 2000 is.
FreeBSD or Solaris is a really good choice for a NAS.
Systems that utilize certain versions of the Linux kernel can be a good choice, with the right configuration, and right supporting programs installed.
For example, a dedicated NAS appliance, can easily provision its ext3 filesystems using SAFE journalling options, instead of the defaults.
And can also pick just the right kernel version and library versions to be as stable as possible under the supported hardware list...
It's not necessarily good for a NAS to support as much hardware as possible: The Number 1 cause of system crashes is faulty hardware or faulty hardware drivers.
It's best to stick with old hardware and driver code that has been around for 5+ years, without major bugs detected.
And to have kernels with isolation features such as IOMMU and NX bit.
It doesn't matter how long you wait between releases, if the quality of your userland is poor.
Junk in, junk out.
Holding releases or releasing slowly does not improve code quality or eliminate bugs. Although it can give you more time to find certain issues before releasing, certain issues will only be found by your users --- and then, your slow release process hurts you (means it takes longer to fix bugs, since releases are so far apart).
The move to Linux IS a fork. It's explained in this artcle about Rumors of FreeNAS' death greatly exagerated
The device you plug into is a single point of failure anyways (potentially). If the same device exposes a DHCP equivalent to its direct ports, and handles inter-plugin-device addressing properly (when multiple plugin-devices interconnect), then the DHCP equivalent's not an additional point of failure.
Also, DHCP doesn't have to be a single point of failure even on a LAN -- multiple DHCP servers can be used, with a supernet split according to the 80/20 rule.
Also, unless the static IP addresses are of the IPv6 sort, or EUI-64/48 (64-bit or 48-bit MAC addresses), there is a point of failure introduced -- as in the equivalent of an IP conflict.