In addition to my "online" storage pools, I keep a three-way ZFS mirror on encrypted hard drives of everything that is irreplacable. If you have more than fits on one disk, maybe use a 1+0 or 1+5, even, setup. This story does depend upon you being able to connect two complete copies of your backup to one machine at a time, so again, if it's really a lot of data, external RAID enclosures may be in your future. In any case, one of the full copies lives off-site and every month I grab one of the two at home, swap it with the off-site one, allow it to come up to date with the third, and then push that month's backups to both. Rinse, repeat, like clockwork.
They don't hash the whole shebang into one number. Rather, they take a (random) number and use that to generate a set of mutations and then probe for that set of mutations in the leaked document. So now, even if you alter the document further, you probably didn't undo the mutations in question. Even if you did, you probably didn't undo all of them and you almost certainly didn't produce a high-confidence result that it's somebody else's copy.
The correct design is neither this reactive monitoring nor the UNIX-standard "oh sure, go ahead!" approach. I contend that the correct approach is one of a capability system: an application which could not even name a remote network endpoint unless it was granted a handle to it is in no position to leak data.
The proprietary world has yet to invent a mechanism for that, and it's been a known problem for a long while (decades). Data "liberation" is challenging and, even if you don't think that is a problem, cross-realm authentication is all but nonexistent. They have little incentive to provide these things unless people demand them, and by and large people don't. (And before you bring up LiveJournal's OpenID protocol, I've two things to say: 1) it's not worthy of the trust placed in it because not all parties srongly authenticate each other, and 2) note that commercial OpenID providers do not, and fundamentally cannot by nature of the beast, make it easy to transition from an identity rooted at one to an identity rooted at another.)
The only truly distributed bring-your-identity-with-you schemes out there have come from the open, usually academic, world: PGP, SPKI/SDSI, E rights, the Petname system and protocol, and so on. Similarly, shared, secure-against-the-owner storage is not something social network companies have huge incentives to produce, but it exists in open research: TAHOE-LAFS exists and Diaspora has made vague promises to being similarly secure.
I'm not sure where the claim about "can't use each other's code" comes from. Perhaps a subtle misunderstanding. While Avida does keep each virtual machine fully isolated from the others, Avida _does_ have explicit support for parasitic behaviors, in the form of code injection into neighboring organisms.
The technology you're looking for is called the TLS SNI extension. It's even vaguely supported these days, though there isn't a huge push to deploy it, sadly.
"One of the main problems is that HTTPS is fundamentally incompatible with virtual hosts" is a common misconception. HTTPS uses TLS; there is a standard called Server Name Indication (RFC3546) which allows TLS to present the moral equivalent of the Host: header during the initial ClientHello message. The problem with SNI is that almost everybody is dragging their feet over this, despite it being a very commonly requested feature. GNUTLS has support for it, and mod_gnutls for Apache will use it, but last I checked OpenSSL has only made it available in "unstable" releases (0.9.9), which leaves most people out in the cold.
This is almost exactly the same thing, in spirit at least, as Inferno (http://www.vitanuova.com/inferno/), which started in 1995 and has been under continuous development since. Managed kernel, runs on real hardware, uses software isolation between managed threads... oh, and has code flying, for real, right now.:)
DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.
It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.
One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.
I was unaware of NSEC3, having only looked at DNSSEC before its publication as an RFC in March. Thank you for bringing it to my attention; I retract my assertions that zone enumaration is a viable objection to DNSSEC.
AFAIK I understand the issues, EDNS having an extended ID field would also have solved, or made dramatically less likley at least, the injection attacks of late with a lot less effort. Am I mistaken in this understanding?
Do you have a pointer towards a design of a getnodebyname() replacement that indicates how it arrived at its data? I haven't seen one, but I admit to being shamed by ignorance of NSEC3.
Yes, sorry, my brain had glitched. The ISC is a nonprofit but was (is?) closely associated (http://cr.yp.to/djbdns/blurb/bindmoney.html) with the company I should have named, namely Nominum, the for-profit branch of Paul Vixie's life. I apoligize for the confusion.
Unrelatedly, if you're still worried that your protocols need work, it seems premature to promise that you won't flag-day the protocol again. You might certainly hope that you won't have to, which I admit is an admirable wish. Or is that to say that you aren't going to rev it if problems show up? Or that you'll leave DNSSEC running but go for a DNSSEC V2?
Forgive me if I still don't believe that DNSSEC brings any major advantage to the table and is diverting resources from the more correct view of the namespace and lulling us into a false sense of security.
Please note that a lot of DNS exploits are still possible with DNSSEC, including Kaminsky's Suckets work -- it simply won't solve the DNS problems of the world. Moreover, the "problems" you're trying to solve with DNSSEC (e.g. yourbank.com getting redirected hostilly) can either still happen (oh, whoops, right, not all caches can mandate DNSSEC yet; applications can't tell whether getnodebyname() was done securely or not, and you should damn well be using TLS anyway). Further, DNSSEC has administrative problems (never _did_ solve that zone exposure problem, after 13 years, did they?) and dramatically increased server, cache, and resolver load. DNS aside, most phishing (which, be honest, is mostly why you're worried about DNS retargeting) is still served using compromised servers that don't claim to be the right one and don't present valid cryptographic tokens anyway! Clearly that problem is at a higher layer than DNS.
In addition to lack of political will, I view handing Verisign more money and ability to (*@#&*&@^#* up the network as something that should be an antigoal of the technical community.
And you're running around telling people to deploy this?
The point here is that you should be viewing hostnames as TOXIC WASTE that might be, occasionally, helpful, not as absolute truth given by Paul Vixie^W^Wgod himself. Failing to treat getnodebyname() and friends in this way is just setting yourself up for trouble.
"It will absolutely not help, and will hurt some" reflects admirably on the design and state of DNSSEC and, more largely, the IETF's ability to design transition plans of late.
Though I suppose it would have helped with that eroneously, mysteriously "still running" old GTLD root server. Clearly the people designing and running DNS know what they're doing.:)
You're going down the path of DNSSEC, and, while I can't claim to be an expert, evidence suggests that this is a bad plan. DNSSEC started out as "oh, we'll just have the server sign all answers it gives out" (the "SIG+KEY" protocol of old).
Also, Verisign has _never_ shown themselves terribly competent at avoiding impersonation attacks -- they issued another SSL key for microsoft.com, FFS. We're supposed to hand them _more_ keys to the Internet?
If I have to guess, it's because Vixie is associated with ISC, who makes BIND, and is hoping that ISC makes more money with the "ZOMG, run DNSSEC or you're all doomed!". Of course, Vixie has never shown any kind of restraint over DNSSEC, and has previously urged adoption of (prior) broken editions of the protocol that somehow passed muster at the IETF despite not living up to their claims.
DJB may be a meanie, but he seems much more technically competent than Vixie. (I offer as evidence, again, the security records of vixie-cron and bind against djb's utilities, djbdjs, and qmail.) Also DJB seems much more intellectually honest and aware of what's going on. Of course, that's just MHO.
(For more lulz invoving DNS, and proof that it isn't, even with DNSSEC, a trustworthy protocol, see Kaminsky's "suckets" work. Using an adversary-controlled DNS server, it's possible to use the "same origin policy" (which is based on DNS being trustworthy) to achieve arbitrary connections. The correct conclusion is that your naming scheme and authority (DNS) ought not try to say anything about the security properties of the entities it names.)
Unfortunately, as Vixie admits, DNSSEC has intractable problems and is... well, let's be generous and say "pushed too quickly through the standards process". (See http://cr.yp.to./djbdns/forgery.html; in particular, Vixie's observation 'We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?"...' [this was _after_ several DNSSEC RFCs were approved and intended to be implemented were shown to be utter crap.])
Encouraging people to use DNSSEC is just about as useful as encouraging people to use HOSTS.TXT. OK, I exaggerate a bit, but it's simply not going to solve the problem, is going to expose zones to arbitrary enumeration (remember, The Internet community discouraged answering AXFR requests from the Internet at large presumably for a reason), and is going to introduce much larger computational demands of DNS servers that implement it.
(Here's a thought: most of this forgery comes from my ability to guess your DNS cache / resolver's query port and request ID. Come IPv6, we could surely add 48+ bits of entropy to the process by having DNS servers listen on a prefix of addresses. Much simpler, if gross.)
Technically 100 SYN packets per second shouldn't cause your TCP stack any pain, because all TCP stacks worth their salt use SYN cookies to avoid acquiring resources server-side until the ACK comes back.
There are in fact several mechanisms, which is part of the problem. There's a TLS extension, Server Name Identification (http://www.ietf.org/rfc/rfc4366.txt), and an HTTP Upgrade: header approach (http://www.ietf.org/rfc/rfc2817.txt). I think consensus is moving towards SNI, and a reasonable chunk of the browsers seem to support it (though OpenSSL does not yet until 0.9.9 comes around). The Apache project is also dragging its feet, waiting for a clear consensus towards one or the other, AFAICT.
The UML program sits at ring-3 on X86 machines: it's just a normal user program using the ptrace() mechanism and extensions [except when the host has been patched with SKAS, but even here it's just a "normal user program". Rumor has it that SKAS might eventually make it into mainline, but it's time in 'real soon now' is starting to rival Duke Nukem Forever's.]. Rings 1 and 2 are odd, rarely used (IIRC there's the current virtualization craze and OS/2 as notable consumers) features of the x86, derived from MULTICS. For processors with only two (user & supervisor) modes, identify ring 0 with supervisor mode and the other rings with user mode.
It is a little odd to say that Linux "becomes" the Ring-0 kernel under KVM. It was already running in ring 0.
Is there any technical, legal, or other problem with moving the Cryptome server onto the EFF's Tor network as a hidden service? This would, AFAICT, make it difficult for the ISPs from finding out that they hosted the server (modulo traffic analysis attacks on Tor)... even given those, it would at least provide plausible deniability?
Are the DVDs still available? I'm perfectly happy to pay for it if they are.
Incidentally, there is an extension to TLS to embed the host name in the initial handshake, so that one need not use the Upgrade: extension of HTTP. I find this solution simpler, if also rarely implemented, but YMMV.
Generating bits takes a lot of time so you generally only generate a shared secret for use with another symmetric cipher scheme; this is often a lot shorter than your message.
You don't gain complete knowledge of which bits are compromised as you are forced to disclose bits over a potentially insecure channel (if you had a secure one, why are you doing this in the first place??) which renders them useless for shared secret usage even if they're not compromised. But disclosing lets you match up bits and say (with high probability) that nobody's snooping on your line, so the undisclosed bits are the same (they'd not be in the advent of somebody fooling on the line).
Er... well, so that's complicated. In Latin, viri is the nominative plural of vir,viri (m,2nd) ["man"], which should have "virus" as its nominative singular form but doesn't - it's an irregular. So if virus were to exist it would likely be an irregular to avoid conflation and so virii is a likely outcome.
Set the sticky bit and a+rwx on / and munge your file ownerships (or POSIX ACLs) to your heart's content. Bam! No more heirarchy. Add / to your path, add / to your lib dir, add / to your man dir. It'd work.
Oh, different users should have different views? Er, uh, ok, so then we have/home/foo and/home/bar. No more need to worry about namespace collision. Add that to your environment paths.
Things in multiple places? Sounds like hard (or symbolic) links to me. (man ln) Nothing revolutionary.
Can you see why lack of heirarchy is a bad idea? You get namespace collisions, a disorganized mess, and no clear idea of what's what. The moment you introduce anything vaguely clever, like different views per user, you've just added the old heirarchy under a new name.
Not saying that the file system is the best thing since sliced bread, but it really is good at what it does. Databases are good at what they do, which, curiously, isn't generally managing files.
Of course, some realize that distros are good at different things and don't (seriously) insult any of them.
I use Gentoo on my two main boxes, simply because I toyed with it and haven't found a good reason to switch away yet (two just so I have the same environment on my two main machines). That said, my router runs Debian-testing. I maintain Mandrake machines at work, know my way around a RedHat machine... etc. My 486 ran Slack 8 while it was up. My DECStation runs NetBSD (though that's a different issue entirely).
I catch flack for using Gentoo, RedHat, Mandrake... my point is, it doesn't matter at all. Use the right tool for the job - that's what open source, and moreso just diversity in the computing environment, is good for! As long as everything speaks TCP+UDP/IP, who cares? ^^
Slashdot Mirror
In addition to my "online" storage pools, I keep a three-way ZFS mirror on encrypted hard drives of everything that is irreplacable. If you have more than fits on one disk, maybe use a 1+0 or 1+5, even, setup. This story does depend upon you being able to connect two complete copies of your backup to one machine at a time, so again, if it's really a lot of data, external RAID enclosures may be in your future. In any case, one of the full copies lives off-site and every month I grab one of the two at home, swap it with the off-site one, allow it to come up to date with the third, and then push that month's backups to both. Rinse, repeat, like clockwork.
They don't hash the whole shebang into one number. Rather, they take a (random) number and use that to generate a set of mutations and then probe for that set of mutations in the leaked document. So now, even if you alter the document further, you probably didn't undo the mutations in question. Even if you did, you probably didn't undo all of them and you almost certainly didn't produce a high-confidence result that it's somebody else's copy.
The correct design is neither this reactive monitoring nor the UNIX-standard "oh sure, go ahead!" approach. I contend that the correct approach is one of a capability system: an application which could not even name a remote network endpoint unless it was granted a handle to it is in no position to leak data.
> and users can move freely between them.
The proprietary world has yet to invent a mechanism for that, and it's been a known problem for a long while (decades). Data "liberation" is challenging and, even if you don't think that is a problem, cross-realm authentication is all but nonexistent. They have little incentive to provide these things unless people demand them, and by and large people don't. (And before you bring up LiveJournal's OpenID protocol, I've two things to say: 1) it's not worthy of the trust placed in it because not all parties srongly authenticate each other, and 2) note that commercial OpenID providers do not, and fundamentally cannot by nature of the beast, make it easy to transition from an identity rooted at one to an identity rooted at another.)
The only truly distributed bring-your-identity-with-you schemes out there have come from the open, usually academic, world: PGP, SPKI/SDSI, E rights, the Petname system and protocol, and so on. Similarly, shared, secure-against-the-owner storage is not something social network companies have huge incentives to produce, but it exists in open research: TAHOE-LAFS exists and Diaspora has made vague promises to being similarly secure.
I'm not sure where the claim about "can't use each other's code" comes from. Perhaps a subtle misunderstanding. While Avida does keep each virtual machine fully isolated from the others, Avida _does_ have explicit support for parasitic behaviors, in the form of code injection into neighboring organisms.
The technology you're looking for is called the TLS SNI extension. It's even vaguely supported these days, though there isn't a huge push to deploy it, sadly.
"One of the main problems is that HTTPS is fundamentally incompatible with virtual hosts" is a common misconception. HTTPS uses TLS; there is a standard called Server Name Indication (RFC3546) which allows TLS to present the moral equivalent of the Host: header during the initial ClientHello message. The problem with SNI is that almost everybody is dragging their feet over this, despite it being a very commonly requested feature. GNUTLS has support for it, and mod_gnutls for Apache will use it, but last I checked OpenSSL has only made it available in "unstable" releases (0.9.9), which leaves most people out in the cold.
This is almost exactly the same thing, in spirit at least, as Inferno (http://www.vitanuova.com/inferno/), which started in 1995 and has been under continuous development since. Managed kernel, runs on real hardware, uses software isolation between managed threads... oh, and has code flying, for real, right now. :)
DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.
It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.
One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.
I was unaware of NSEC3, having only looked at DNSSEC before its publication as an RFC in March. Thank you for bringing it to my attention; I retract my assertions that zone enumaration is a viable objection to DNSSEC.
AFAIK I understand the issues, EDNS having an extended ID field would also have solved, or made dramatically less likley at least, the injection attacks of late with a lot less effort. Am I mistaken in this understanding?
Do you have a pointer towards a design of a getnodebyname() replacement that indicates how it arrived at its data? I haven't seen one, but I admit to being shamed by ignorance of NSEC3.
Yes, sorry, my brain had glitched. The ISC is a nonprofit but was (is?) closely associated (http://cr.yp.to/djbdns/blurb/bindmoney.html) with the company I should have named, namely Nominum, the for-profit branch of Paul Vixie's life. I apoligize for the confusion.
Unrelatedly, if you're still worried that your protocols need work, it seems premature to promise that you won't flag-day the protocol again. You might certainly hope that you won't have to, which I admit is an admirable wish. Or is that to say that you aren't going to rev it if problems show up? Or that you'll leave DNSSEC running but go for a DNSSEC V2?
Forgive me if I still don't believe that DNSSEC brings any major advantage to the table and is diverting resources from the more correct view of the namespace and lulling us into a false sense of security.
Please note that a lot of DNS exploits are still possible with DNSSEC, including Kaminsky's Suckets work -- it simply won't solve the DNS problems of the world. Moreover, the "problems" you're trying to solve with DNSSEC (e.g. yourbank.com getting redirected hostilly) can either still happen (oh, whoops, right, not all caches can mandate DNSSEC yet; applications can't tell whether getnodebyname() was done securely or not, and you should damn well be using TLS anyway). Further, DNSSEC has administrative problems (never _did_ solve that zone exposure problem, after 13 years, did they?) and dramatically increased server, cache, and resolver load. DNS aside, most phishing (which, be honest, is mostly why you're worried about DNS retargeting) is still served using compromised servers that don't claim to be the right one and don't present valid cryptographic tokens anyway! Clearly that problem is at a higher layer than DNS.
In addition to lack of political will, I view handing Verisign more money and ability to (*@#&*&@^#* up the network as something that should be an antigoal of the technical community.
And you're running around telling people to deploy this?
The point here is that you should be viewing hostnames as TOXIC WASTE that might be, occasionally, helpful, not as absolute truth given by Paul Vixie^W^Wgod himself. Failing to treat getnodebyname() and friends in this way is just setting yourself up for trouble.
"It will absolutely not help, and will hurt some" reflects admirably on the design and state of DNSSEC and, more largely, the IETF's ability to design transition plans of late.
Though I suppose it would have helped with that eroneously, mysteriously "still running" old GTLD root server. Clearly the people designing and running DNS know what they're doing. :)
You're going down the path of DNSSEC, and, while I can't claim to be an expert, evidence suggests that this is a bad plan. DNSSEC started out as "oh, we'll just have the server sign all answers it gives out" (the "SIG+KEY" protocol of old).
Also, Verisign has _never_ shown themselves terribly competent at avoiding impersonation attacks -- they issued another SSL key for microsoft.com, FFS. We're supposed to hand them _more_ keys to the Internet?
If I have to guess, it's because Vixie is associated with ISC, who makes BIND, and is hoping that ISC makes more money with the "ZOMG, run DNSSEC or you're all doomed!". Of course, Vixie has never shown any kind of restraint over DNSSEC, and has previously urged adoption of (prior) broken editions of the protocol that somehow passed muster at the IETF despite not living up to their claims.
DJB may be a meanie, but he seems much more technically competent than Vixie. (I offer as evidence, again, the security records of vixie-cron and bind against djb's utilities, djbdjs, and qmail.) Also DJB seems much more intellectually honest and aware of what's going on. Of course, that's just MHO.
(For more lulz invoving DNS, and proof that it isn't, even with DNSSEC, a trustworthy protocol, see Kaminsky's "suckets" work. Using an adversary-controlled DNS server, it's possible to use the "same origin policy" (which is based on DNS being trustworthy) to achieve arbitrary connections. The correct conclusion is that your naming scheme and authority (DNS) ought not try to say anything about the security properties of the entities it names.)
Unfortunately, as Vixie admits, DNSSEC has intractable problems and is... well, let's be generous and say "pushed too quickly through the standards process". (See http://cr.yp.to./djbdns/forgery.html; in particular, Vixie's observation 'We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ...' [this was _after_ several DNSSEC RFCs were approved and intended to be implemented were shown to be utter crap.])
Encouraging people to use DNSSEC is just about as useful as encouraging people to use HOSTS.TXT. OK, I exaggerate a bit, but it's simply not going to solve the problem, is going to expose zones to arbitrary enumeration (remember, The Internet community discouraged answering AXFR requests from the Internet at large presumably for a reason), and is going to introduce much larger computational demands of DNS servers that implement it.
(Here's a thought: most of this forgery comes from my ability to guess your DNS cache / resolver's query port and request ID. Come IPv6, we could surely add 48+ bits of entropy to the process by having DNS servers listen on a prefix of addresses. Much simpler, if gross.)
Technically 100 SYN packets per second shouldn't cause your TCP stack any pain, because all TCP stacks worth their salt use SYN cookies to avoid acquiring resources server-side until the ACK comes back.
There are in fact several mechanisms, which is part of the problem. There's a TLS extension, Server Name Identification (http://www.ietf.org/rfc/rfc4366.txt), and an HTTP Upgrade: header approach (http://www.ietf.org/rfc/rfc2817.txt). I think consensus is moving towards SNI, and a reasonable chunk of the browsers seem to support it (though OpenSSL does not yet until 0.9.9 comes around). The Apache project is also dragging its feet, waiting for a clear consensus towards one or the other, AFAICT.
Slight corrections:
The UML program sits at ring-3 on X86 machines: it's just a normal user program using the ptrace() mechanism and extensions [except when the host has been patched with SKAS, but even here it's just a "normal user program". Rumor has it that SKAS might eventually make it into mainline, but it's time in 'real soon now' is starting to rival Duke Nukem Forever's.]. Rings 1 and 2 are odd, rarely used (IIRC there's the current virtualization craze and OS/2 as notable consumers) features of the x86, derived from MULTICS. For processors with only two (user & supervisor) modes, identify ring 0 with supervisor mode and the other rings with user mode.
It is a little odd to say that Linux "becomes" the Ring-0 kernel under KVM. It was already running in ring 0.
You are free to reimplement ZFS for Linux, not in FUSE. You might even start from the GPL'd code in GRUB at http://src.opensolaris.org/source/xref/onnv/onnv-g ate/usr/src/grub/grub-0.95/stage2/ .
Is there any technical, legal, or other problem with moving the Cryptome server onto the EFF's Tor network as a hidden service? This would, AFAICT, make it difficult for the ISPs from finding out that they hosted the server (modulo traffic analysis attacks on Tor)... even given those, it would at least provide plausible deniability?
Are the DVDs still available? I'm perfectly happy to pay for it if they are.
Incidentally, there is an extension to TLS to embed the host name in the initial handshake, so that one need not use the Upgrade: extension of HTTP. I find this solution simpler, if also rarely implemented, but YMMV.
Close but not quite....
Generating bits takes a lot of time so you generally only generate a shared secret for use with another symmetric cipher scheme; this is often a lot shorter than your message.
You don't gain complete knowledge of which bits are compromised as you are forced to disclose bits over a potentially insecure channel (if you had a secure one, why are you doing this in the first place??) which renders them useless for shared secret usage even if they're not compromised. But disclosing lets you match up bits and say (with high probability) that nobody's snooping on your line, so the undisclosed bits are the same (they'd not be in the advent of somebody fooling on the line).
Er... well, so that's complicated. In Latin, viri is the nominative plural of vir,viri (m,2nd) ["man"], which should have "virus" as its nominative singular form but doesn't - it's an irregular. So if virus were to exist it would likely be an irregular to avoid conflation and so virii is a likely outcome.
That doesn't sound terribly spectacular...
/home/foo and /home/bar. No more need to worry about namespace collision. Add that to your environment paths.
Set the sticky bit and a+rwx on / and munge your file ownerships (or POSIX ACLs) to your heart's content. Bam! No more heirarchy. Add / to your path, add / to your lib dir, add / to your man dir. It'd work.
Oh, different users should have different views? Er, uh, ok, so then we have
Things in multiple places? Sounds like hard (or symbolic) links to me. (man ln) Nothing revolutionary.
Can you see why lack of heirarchy is a bad idea? You get namespace collisions, a disorganized mess, and no clear idea of what's what. The moment you introduce anything vaguely clever, like different views per user, you've just added the old heirarchy under a new name.
Not saying that the file system is the best thing since sliced bread, but it really is good at what it does. Databases are good at what they do, which, curiously, isn't generally managing files.
My $.02.
Of course, some realize that distros are good at different things and don't (seriously) insult any of them.
I use Gentoo on my two main boxes, simply because I toyed with it and haven't found a good reason to switch away yet (two just so I have the same environment on my two main machines). That said, my router runs Debian-testing. I maintain Mandrake machines at work, know my way around a RedHat machine... etc. My 486 ran Slack 8 while it was up. My DECStation runs NetBSD (though that's a different issue entirely).
I catch flack for using Gentoo, RedHat, Mandrake... my point is, it doesn't matter at all. Use the right tool for the job - that's what open source, and moreso just diversity in the computing environment, is good for! As long as everything speaks TCP+UDP/IP, who cares? ^^
--Knots;