I keep hearing people say, "don't take our file extentions away; they're ok!". Well, let me tell you, moving content type into meta data does not take away the functionality that file extentions provide.
There is only one problem with file extentions; file extentions are not reliable. There is no requirement for a file to have an extention. If there were, extentions would actually be meta-data seperate from file name; they'd just be stored right beside file name. Implementing meta-data based content type does not mean that content type must stop appearing as part of the name of a file. It does not mean that content type will stop being a delimiting factor between naming of files. When you create two files, one "document.txt" and one "document.xml" you are creating two files called document; one is a text file and the other is an xml file. The only difference between those two file names was extention. What would make it so impossible to have two files called document that are set appart from a user interface perspective by file type? Yes, I know that pretty much every program would need to use a different API for accessing files, and yes I know that your directory type inodes would need new formats (but who cares, it's a new file system any way).
Storing content type (extentions do not count as storing content type, they only do sometimes, if we're lucky as they are not reliable) does not mean that it'll be hard to interopt with non content-type systems. For instance, Linux and Windows both interact with HTTP just fine. HTTP uses content-type headers to define type, and totally ignores the extention; the servers and clients must translate between the content type header and extention if they want. There's no reason that other applications can't do the same for interoperability between systems.
People just don't want to do the work to change pretty much every application for Unix that exists. That's a very valid arguement. Adding a new file system that supports meta-data would change the UNIX API for files, and would probably break POSIX or something. We use old standards like FTP and EXT2 which don't have much of a concept of meta-data. It would be a major piece of work (and really a new OS - although it'd be very easy to port unix apps to it) to fully implement extended meta-data. But it's damned cool to do it! If we did it right, we'd listen to Hans Reiser's paper at http://www.namesys.com/whitepaper.html and make a damned cool awesome file system. And why not? (appart from all of the work)
The point of NetBIOS datagram service (and the rest of the suite) over TCP/IP (UDP) was sort of to make a LAN out of the internet.
Re:GNOME vs KDE for the newbie
on
GNOME 2.0 Beta
·
· Score: 2
As a developer and network admin, Windows pales in comparison to Linux, for me, as a desktop OS. I run Windows in VMWare so that I can use MMC consoles to admin some NT domain services, but past that, I can't stand Windows. Somehow, every time I use it, it manages to piss me off. I know that these are hardly objective observations, but for me, using Windows as a desktop OS would probably cause me to commit crimes.
Linux's flexability and it's tendency to force me to understand what I'm doing is what sells me on it. Oh, and it's free:) What's lacking, in my eyes? 3D graphics, advanced audio/video tools, easy and consistant printing, and good mime support (I do not consider Windows to have good mime support either). Groff/Lyx does a good job of typesetting, but it would be nice if Abiword improves. These issues are being worked on, so that's good:) Give it time, and it'll get better:)
If Linux doesn't do what you need in order to make it a viable desktop OS, that's cool. If you could lend a hand in improving things, that would be good:) If not, thanks for using Linux where you can:)
Maybe artists will realize that the record companies are preventing them from being heard. I personally tend to listen to net radio an hour a day at least... I listen to the on-air radio, well, when my alarm goes off.:) People who are into music, that make music, also tend to listen to music. If you alienate them, maybe they won't want to sign your contracts.
So, apart from pairing the retinal scan with some kind of changable secret (say a password, etc), what happens when someone compromises the 'electronic version' of your retina? You can't really change your retina. Same goes for other biometrics.
I wish that I could trust what you're posting. However, I don't really need to trust it. Historically, the United States Gov hasn't really promoted the 'compassion' that it likes to portray. I mean, how about Iraq and the sanctions against it? That action alone has killed many many more people than the World Trade Center attack. It's too bad that there's not more public outrage over these atrocities. I hope that soon the Ministry of Truth will slip, and the general public will notice.
Many people are going off on rants detailing why Mono is a bad idea.
Who says that Mono will try to chase Microsoft? Maybe a Wine like project will try to implement all of the new proprietary MS.NET classes for use with Mono, but will Mono do that? Why can't mono create new GNOME classes that run ontop of.NET? This would allow GNOME and its applications to run on Windows. This is a good thing. GNOME is trying to build a free software desktop - not only the environment, but also the applications. GNOME is not going to try to chase MS so that GNOME can give up and only use proprietary Windows apps.
Remember, using the.NET framework does not mean total compatability with MS, and it does not mean a new WINE.NET implementation of all of the MS classes (although someone could make such an effort). Think of the Mono.NET more as the basic C libraries as opposed to all of the proprietary libraries that vendors may come up with to do more advanced things.
While I agree that it may not be so much fun using the Windows style.net API, it must be noted that you probably won't have to. I'm sure that someone here in the Unix world will embrace and extend.net to include some Unix style API changes - new classes specific to Unix. Maybe if our APIs rock, people in the Windows world will add them too (provided that developers in Windows will be able to add those new classes to their.net compilier, etc).
I think that having developers on Unix learn an API that will be usable on Linux AND Windows will be EXTREMELY powerful. Not only does the free software world benifit from wider app support, but Linux programers, who love Linux, will also have an easier time programming in Windows at work when need be. Not only that, but programmers will be able to write applications in pretty much any language, on any platform, and expect them to work pretty much anywhere. As long as application developers don't build in platform specific code on purpose, this should be a realistic goal.
The only real risk, I think, is that our apps will run on Windows, but Windows apps won't run on Linux, thus making Windows stronger. However, that still is promoting free software - our free applications can still excell, on Windows or on Linux.
Well it's not too bad. Xwindows supports a generic interface for rendering things that are accelerated by hardware (falling back to software when need be). Now, please, if I'm wrong, someone correct me, but I believe that it works like this: XFT is an API for drawing fonts in XWindows - it replaces X's old font interface. XFT talks to freetype to turn a string into a vector image (font file) into a bitmap image. The bitmap image that freetype produces can either be a monochrome pixmap (what normal X font routines use) or a 256 colour pixmap with antialiasing). XFT takes the 256 colour (greyscale) image and gives it an alpha channel (through some kind of an operation like multiply or darken only in GIMP. It then passes this image to XRender to have it rendered on the screen. Right now, most QT or GTK apps use QT and GTK font rendering routines. These routines used to use the normal x font stuff... if you patch them to use XFT, they all get anti-aliasing. Mozilla has it's own widget set, so it needs it's own patch to use the better font rendering mechanisms.
The font support is in the right place, it's just that applications need to be changed to use the new, better interface, instead of the old interface that can't do hardware accelerated alpha channel stuff.
I imagine that there are already some well designed applications and protocols for streaming video, and audio over UDP with congestion control; if there is not, then we need them. What we do not need, is 'in band' transfer of blobs over IM networks. What IM networks should be doing, is using the solutions to these problems that are already available. For example, how about a standard interface and process for negotiating an audio or video session via an out of band system? (for example, set up a multicast group, bring up an audio/video encoder and stream UDP over mbone. Another example, if you want to transfer a blob, have the receiver open up a socket and dump the file to the socket, or open one up yourself and have them connect to you. If you need to send a file to someone who is offline, send it as an email attatchment or upload it to a web/ftp server and pass the other user a URL to it. Using in band transfer for blobs is not a good thing; it puts load on servers, re-invents congestion control and error correction mechanisms that we already have, increases protocol overhead, and isn't P2P neccessarily (as some IM networks transfer via IM server [jabber,ICQ]). All we need is an agreed upon method for negotating out of band transfers, and a set of best of breed applications for particular tasks.
Why does there have to be one prevailing 'metaphor'? Why can't we use metaphors specific to the task? I mean, I really like using the command line for a lot of things, but at the same time, I'd like to see thumbnails of images in my directory listings... XML-term is great for this - it merges command line and gui (although not very smoothly yet). Also, 3d works for some things, as does aural; but not for many other things. Use the right tool for the job, not the most cool.
Key strength doesn't matter really. Why? Because there's way less entropy in the user's password (likely) than there is in the encryption key, and having the user's password will get you the FEK.
I have a feeling that this is a hoax. Even if it is, there's some hope for the proposed features.
DBMS filesystem: A filesystem is a database... there are two major things that most filesystems today lack (so far as I can think of), that more modern database systems could provide. One, is that databases can be indexed fairly easily, providing for fast searching. Unfortunatly, indexing on many columns (in RDBMS) can actually take a lot of disk space... maybe more than many people would be willing to accept. I also wish that filesystems could hold much more meta-data. What I envision, is a filesystem which provides meta-data fields dynamically, based on mime-type (stored seperately - not in filename). Imagine meta-data for image/jpeg to include compression level, height, width, or even a thumbnail version of the image, or meta-data for audio/mpeg to include the info that's now stored in ID3. This shouldn't necessarily mean slowness, or excessive disk useage - especially if you can turn extended meta-data off for particular parts of the filesystem.
Visual interface: While 3D sounds cool, I'm not convinced. A monitor (currently) is a 2D object, and merging a 3D environment into a 2D display is going to cause as much - if not more - metaphore 'clash' as the 'desktop' metaphore. I think that some of the best/most interesting display technologies can be found in things like Aqua which uses display PDF and Berlin which uses 'fresco' to provide similar features like resolution independance, good printer output, vector based stuff, etc. Until we get holographic display, or maybe even good VR stuff, I'm not betting much on 3D interfaces except for very specific applications.
Security: They didn't really go into this much, unfortunately. Unix security is nice and simple (which is a mixed blessing); sometimes you need more control. It's also nice to have things NOT run with excess privilige (this is hard in some situations - like SSHD for example). Projects like RSBAC (rsbac.org) address some of these issues.
Current projects like Linux already have lots of hardware support, and people support; any new OS, no matter how revolutionary is not likely to take over too quickly. This Cesium project, should it exist, will have had to create all drivers internally without help; the Linux community hasn't even been able to support enough hardware to make everyone happy - I don't know how Cesium would. (not that wide hw support would have been a goal necessarily)
I was surprised to read that the bill expressly says that death may not be a penalty for conspiracy to commit terrorism. Guess no one gets to kill bin Laden huh?:)
Run Hogwash... its modification of snort that actualyl makes firewall decisions based on snort rules... so you can detect an attack and refuse to allow it into your network.
Depending on the language, the process of breaking into the computer systems of someone could include break and enter to property. Imagine breaking into MS and wiping/burning all Windows source because OSS developers suspect GPL violations?:) heh
First, let me say that it's disappointing to see so many people nitpick and try to come up with reasons that this won't work. I'll try to point out some reasonable goals that do not have to be dependant on one proprietary software vendor - but would benefit from open protocols.
The abstraction of data and computational location is cool. They're not saying that we should blindly start distributing our data across network devices without any attention to latency, reliability of links, security, etc. Ever heard of 'quality of service'? Or authentication? Or authorization? Or resource limits? In the case of computation, sometimes you can break a program up into blocks that take a long time to execute; if it takes much longer to execute the code than it does to move the code across the network to a faster/less loaded CPU, then it makes sense to do it. On the other hand, if the computation will take only a little time, or if the result is required ASAP, you wouldn't want to move it. If it's unknown, let the user pick a default or let the system make a good guess based on what the code looks like. And, they're not saying that we should send our data to MS to be worked on, or even someone down the block - maybe you have some of your own computers laying around that don't get used much. The goal here is to turn your private LAN into a cluster, that only acts as a cluster when it makes sense to do so. In the case of storage distribution, they're not saying that others on the net should be able to use your storage space without your permission or that you should have to store anything on anyone elses storage space. Let's first consider three cases; a swap file, a master thesis document, and an mp3 file. You would want to keep your swap file on your local drive; the swap manager would request this type of low latency storage from the file system. You'd want your thesis document copied to every available storage device that you could (maybe encrypted and signed to ensure that it's secure); you'd tell your word processor to save it with this quality of service. You wouldn't likely care to encrypt your mp3 files, but you don't need to keep them on your drive when there's lots of space available elsewhere on the network (think next generation storage area network). You wouldn't want to store the mp3 too far from your network, but as long as it came back at more than the bit rate that the song plays at, you likely wouldn't care too much (unless your friends often download mp3s from you). If some device on the network runs out of space, it could shuffle stuff around. It might make sense to elect a storage manager system on your network, replicate your file allocation table/inode table/whatever around to each box on the network, so that if the distributed file system server (really just something that keeps track of locations) goes down, something else could come up in it's place. I mean, I havn't really thought about this for too long - I'm sure that there'd be some problems but nothing that can't be fixed during the design stage.
Self tuning is also cool. It'd be great for all of those sites that get slashdotted. It makes sense to do expensive things on a website (server side) to provide more features when there's light load; when there's heavy load, it makes better sense to hold off on those expensive features and concentrate on the content instead. This might mean auto-tuning apache's caching and stuff, or automatically re-indexing a database to better serve the kind of requests that are popular. Some of this means lots of application programmer work - like what features to sacrifice under heavy load, but others like automatically indexing can be done with varying degrees of administration.
It's not all evil, and some of it is really cool. The idea is that we should be ABLE to make the most use of the resources available, and not be limited by things like physical location.
Umm, I think that in the real world you'd realize that you'd look pretty suspicious sneaking around to some guy's window, and trying to open it. I think that you'd just go talk to the homeowner. It's more like you came to knock on the person's door and when you knocked it drifted open, and you can't lock the door without a key.
Slashdot Mirror
I keep hearing people say, "don't take our file extentions away; they're ok!". Well, let me tell you, moving content type into meta data does not take away the functionality that file extentions provide.
There is only one problem with file extentions; file extentions are not reliable. There is no requirement for a file to have an extention. If there were, extentions would actually be meta-data seperate from file name; they'd just be stored right beside file name. Implementing meta-data based content type does not mean that content type must stop appearing as part of the name of a file. It does not mean that content type will stop being a delimiting factor between naming of files. When you create two files, one "document.txt" and one "document.xml" you are creating two files called document; one is a text file and the other is an xml file. The only difference between those two file names was extention. What would make it so impossible to have two files called document that are set appart from a user interface perspective by file type? Yes, I know that pretty much every program would need to use a different API for accessing files, and yes I know that your directory type inodes would need new formats (but who cares, it's a new file system any way).
Storing content type (extentions do not count as storing content type, they only do sometimes, if we're lucky as they are not reliable) does not mean that it'll be hard to interopt with non content-type systems. For instance, Linux and Windows both interact with HTTP just fine. HTTP uses content-type headers to define type, and totally ignores the extention; the servers and clients must translate between the content type header and extention if they want. There's no reason that other applications can't do the same for interoperability between systems.
People just don't want to do the work to change pretty much every application for Unix that exists. That's a very valid arguement. Adding a new file system that supports meta-data would change the UNIX API for files, and would probably break POSIX or something. We use old standards like FTP and EXT2 which don't have much of a concept of meta-data. It would be a major piece of work (and really a new OS - although it'd be very easy to port unix apps to it) to fully implement extended meta-data. But it's damned cool to do it! If we did it right, we'd listen to Hans Reiser's paper at http://www.namesys.com/whitepaper.html and make a damned cool awesome file system. And why not? (appart from all of the work)
The point of NetBIOS datagram service (and the rest of the suite) over TCP/IP (UDP) was sort of to make a LAN out of the internet.
As a developer and network admin, Windows pales in comparison to Linux, for me, as a desktop OS. I run Windows in VMWare so that I can use MMC consoles to admin some NT domain services, but past that, I can't stand Windows. Somehow, every time I use it, it manages to piss me off. I know that these are hardly objective observations, but for me, using Windows as a desktop OS would probably cause me to commit crimes.
:) What's lacking, in my eyes? 3D graphics, advanced audio/video tools, easy and consistant printing, and good mime support (I do not consider Windows to have good mime support either). Groff/Lyx does a good job of typesetting, but it would be nice if Abiword improves. These issues are being worked on, so that's good :) Give it time, and it'll get better :)
:) If not, thanks for using Linux where you can :)
Linux's flexability and it's tendency to force me to understand what I'm doing is what sells me on it. Oh, and it's free
If Linux doesn't do what you need in order to make it a viable desktop OS, that's cool. If you could lend a hand in improving things, that would be good
Do you mean that the default theme is ass-ugly? It's easy to switch themes.
Maybe artists will realize that the record companies are preventing them from being heard. I personally tend to listen to net radio an hour a day at least... I listen to the on-air radio, well, when my alarm goes off. :) People who are into music, that make music, also tend to listen to music. If you alienate them, maybe they won't want to sign your contracts.
So, apart from pairing the retinal scan with some kind of changable secret (say a password, etc), what happens when someone compromises the 'electronic version' of your retina? You can't really change your retina. Same goes for other biometrics.
I wish that I could trust what you're posting. However, I don't really need to trust it. Historically, the United States Gov hasn't really promoted the 'compassion' that it likes to portray. I mean, how about Iraq and the sanctions against it? That action alone has killed many many more people than the World Trade Center attack. It's too bad that there's not more public outrage over these atrocities. I hope that soon the Ministry of Truth will slip, and the general public will notice.
Many people are going off on rants detailing why Mono is a bad idea.
.NET classes for use with Mono, but will Mono do that? Why can't mono create new GNOME classes that run ontop of .NET? This would allow GNOME and its applications to run on Windows. This is a good thing. GNOME is trying to build a free software desktop - not only the environment, but also the applications. GNOME is not going to try to chase MS so that GNOME can give up and only use proprietary Windows apps.
.NET framework does not mean total compatability with MS, and it does not mean a new WINE .NET implementation of all of the MS classes (although someone could make such an effort). Think of the Mono .NET more as the basic C libraries as opposed to all of the proprietary libraries that vendors may come up with to do more advanced things.
Who says that Mono will try to chase Microsoft? Maybe a Wine like project will try to implement all of the new proprietary MS
Remember, using the
Or am I missing something?
While I agree that it may not be so much fun using the Windows style .net API, it must be noted that you probably won't have to. I'm sure that someone here in the Unix world will embrace and extend .net to include some Unix style API changes - new classes specific to Unix. Maybe if our APIs rock, people in the Windows world will add them too (provided that developers in Windows will be able to add those new classes to their .net compilier, etc).
I think that having developers on Unix learn an API that will be usable on Linux AND Windows will be EXTREMELY powerful. Not only does the free software world benifit from wider app support, but Linux programers, who love Linux, will also have an easier time programming in Windows at work when need be. Not only that, but programmers will be able to write applications in pretty much any language, on any platform, and expect them to work pretty much anywhere. As long as application developers don't build in platform specific code on purpose, this should be a realistic goal.
The only real risk, I think, is that our apps will run on Windows, but Windows apps won't run on Linux, thus making Windows stronger. However, that still is promoting free software - our free applications can still excell, on Windows or on Linux.
Well it's not too bad. Xwindows supports a generic interface for rendering things that are accelerated by hardware (falling back to software when need be). Now, please, if I'm wrong, someone correct me, but I believe that it works like this: XFT is an API for drawing fonts in XWindows - it replaces X's old font interface. XFT talks to freetype to turn a string into a vector image (font file) into a bitmap image. The bitmap image that freetype produces can either be a monochrome pixmap (what normal X font routines use) or a 256 colour pixmap with antialiasing). XFT takes the 256 colour (greyscale) image and gives it an alpha channel (through some kind of an operation like multiply or darken only in GIMP. It then passes this image to XRender to have it rendered on the screen. Right now, most QT or GTK apps use QT and GTK font rendering routines. These routines used to use the normal x font stuff... if you patch them to use XFT, they all get anti-aliasing. Mozilla has it's own widget set, so it needs it's own patch to use the better font rendering mechanisms.
The font support is in the right place, it's just that applications need to be changed to use the new, better interface, instead of the old interface that can't do hardware accelerated alpha channel stuff.
That's not entirely true given chroot jails and user mode Linux :)
I imagine that there are already some well designed applications and protocols for streaming video, and audio over UDP with congestion control; if there is not, then we need them. What we do not need, is 'in band' transfer of blobs over IM networks. What IM networks should be doing, is using the solutions to these problems that are already available. For example, how about a standard interface and process for negotiating an audio or video session via an out of band system? (for example, set up a multicast group, bring up an audio/video encoder and stream UDP over mbone. Another example, if you want to transfer a blob, have the receiver open up a socket and dump the file to the socket, or open one up yourself and have them connect to you. If you need to send a file to someone who is offline, send it as an email attatchment or upload it to a web/ftp server and pass the other user a URL to it. Using in band transfer for blobs is not a good thing; it puts load on servers, re-invents congestion control and error correction mechanisms that we already have, increases protocol overhead, and isn't P2P neccessarily (as some IM networks transfer via IM server [jabber,ICQ]). All we need is an agreed upon method for negotating out of band transfers, and a set of best of breed applications for particular tasks.
Why does there have to be one prevailing 'metaphor'? Why can't we use metaphors specific to the task? I mean, I really like using the command line for a lot of things, but at the same time, I'd like to see thumbnails of images in my directory listings... XML-term is great for this - it merges command line and gui (although not very smoothly yet). Also, 3d works for some things, as does aural; but not for many other things. Use the right tool for the job, not the most cool.
Key strength doesn't matter really. Why? Because there's way less entropy in the user's password (likely) than there is in the encryption key, and having the user's password will get you the FEK.
Huh? I've never had trouble admining Debian. I don't use ssh for X stuff, but Debian does put a cron daily entry in for updatedb - /etc/cron.daily/find
Well, please, excuse my ignorance :) Cool.
Oh, one other nice thing for filesystems would be transaction logging for consistency.
I have a feeling that this is a hoax. Even if it is, there's some hope for the proposed features.
DBMS filesystem: A filesystem is a database... there are two major things that most filesystems today lack (so far as I can think of), that more modern database systems could provide. One, is that databases can be indexed fairly easily, providing for fast searching. Unfortunatly, indexing on many columns (in RDBMS) can actually take a lot of disk space... maybe more than many people would be willing to accept. I also wish that filesystems could hold much more meta-data. What I envision, is a filesystem which provides meta-data fields dynamically, based on mime-type (stored seperately - not in filename). Imagine meta-data for image/jpeg to include compression level, height, width, or even a thumbnail version of the image, or meta-data for audio/mpeg to include the info that's now stored in ID3. This shouldn't necessarily mean slowness, or excessive disk useage - especially if you can turn extended meta-data off for particular parts of the filesystem.
Visual interface: While 3D sounds cool, I'm not convinced. A monitor (currently) is a 2D object, and merging a 3D environment into a 2D display is going to cause as much - if not more - metaphore 'clash' as the 'desktop' metaphore. I think that some of the best/most interesting display technologies can be found in things like Aqua which uses display PDF and Berlin which uses 'fresco' to provide similar features like resolution independance, good printer output, vector based stuff, etc. Until we get holographic display, or maybe even good VR stuff, I'm not betting much on 3D interfaces except for very specific applications.
Security: They didn't really go into this much, unfortunately. Unix security is nice and simple (which is a mixed blessing); sometimes you need more control. It's also nice to have things NOT run with excess privilige (this is hard in some situations - like SSHD for example). Projects like RSBAC (rsbac.org) address some of these issues.
Current projects like Linux already have lots of hardware support, and people support; any new OS, no matter how revolutionary is not likely to take over too quickly. This Cesium project, should it exist, will have had to create all drivers internally without help; the Linux community hasn't even been able to support enough hardware to make everyone happy - I don't know how Cesium would. (not that wide hw support would have been a goal necessarily)
I was surprised to read that the bill expressly says that death may not be a penalty for conspiracy to commit terrorism. Guess no one gets to kill bin Laden huh? :)
Run Hogwash... its modification of snort that actualyl makes firewall decisions based on snort rules... so you can detect an attack and refuse to allow it into your network.
hogwash.sourceforge.net
Because often the simple fact that communication is occuring at particular times with particular characteristics is revealing.
Depending on the language, the process of breaking into the computer systems of someone could include break and enter to property. Imagine breaking into MS and wiping/burning all Windows source because OSS developers suspect GPL violations? :) heh
First, let me say that it's disappointing to see so many people nitpick and try to come up with reasons that this won't work. I'll try to point out some reasonable goals that do not have to be dependant on one proprietary software vendor - but would benefit from open protocols.
The abstraction of data and computational location is cool. They're not saying that we should blindly start distributing our data across network devices without any attention to latency, reliability of links, security, etc. Ever heard of 'quality of service'? Or authentication? Or authorization? Or resource limits? In the case of computation, sometimes you can break a program up into blocks that take a long time to execute; if it takes much longer to execute the code than it does to move the code across the network to a faster/less loaded CPU, then it makes sense to do it. On the other hand, if the computation will take only a little time, or if the result is required ASAP, you wouldn't want to move it. If it's unknown, let the user pick a default or let the system make a good guess based on what the code looks like. And, they're not saying that we should send our data to MS to be worked on, or even someone down the block - maybe you have some of your own computers laying around that don't get used much. The goal here is to turn your private LAN into a cluster, that only acts as a cluster when it makes sense to do so. In the case of storage distribution, they're not saying that others on the net should be able to use your storage space without your permission or that you should have to store anything on anyone elses storage space. Let's first consider three cases; a swap file, a master thesis document, and an mp3 file. You would want to keep your swap file on your local drive; the swap manager would request this type of low latency storage from the file system. You'd want your thesis document copied to every available storage device that you could (maybe encrypted and signed to ensure that it's secure); you'd tell your word processor to save it with this quality of service. You wouldn't likely care to encrypt your mp3 files, but you don't need to keep them on your drive when there's lots of space available elsewhere on the network (think next generation storage area network). You wouldn't want to store the mp3 too far from your network, but as long as it came back at more than the bit rate that the song plays at, you likely wouldn't care too much (unless your friends often download mp3s from you). If some device on the network runs out of space, it could shuffle stuff around. It might make sense to elect a storage manager system on your network, replicate your file allocation table/inode table/whatever around to each box on the network, so that if the distributed file system server (really just something that keeps track of locations) goes down, something else could come up in it's place. I mean, I havn't really thought about this for too long - I'm sure that there'd be some problems but nothing that can't be fixed during the design stage.
Self tuning is also cool. It'd be great for all of those sites that get slashdotted. It makes sense to do expensive things on a website (server side) to provide more features when there's light load; when there's heavy load, it makes better sense to hold off on those expensive features and concentrate on the content instead. This might mean auto-tuning apache's caching and stuff, or automatically re-indexing a database to better serve the kind of requests that are popular. Some of this means lots of application programmer work - like what features to sacrifice under heavy load, but others like automatically indexing can be done with varying degrees of administration.
It's not all evil, and some of it is really cool. The idea is that we should be ABLE to make the most use of the resources available, and not be limited by things like physical location.
Hmm, how about I just install RSBAC, snort/hogwash and iptables for free? :)
Umm, I think that in the real world you'd realize that you'd look pretty suspicious sneaking around to some guy's window, and trying to open it. I think that you'd just go talk to the homeowner. It's more like you came to knock on the person's door and when you knocked it drifted open, and you can't lock the door without a key.