Obviously, in the use of legacy file formats, we would need filesystem hooks to do conversions at the time that the files arrive and/or leave the computer over a network.
Once we have become comfortable with a filesystem like the one described in the article, new file formats would be developed which would start putting the regular file data in with the meta-data in an organized fashion which makes all of the important parts easily accessible.
This would be quite elegant, as you would not have to open the file and seek around to get to some piece of data if that's all you need. Instead, you just crawl down the hierarchy to the part you want and open that file and you're pointed right at the beginning of the data you need.
The.info files for the Amiga, IIRC, were only for the workbench-related meta-data (including the icon).
You didn't have an.info file co-existing with all of the files in the filesystem, and the.info file did not contain read/write/archive/hidden/etc types of permission meta-data.
With the system that was proposed, you would probably need some kind of file packager system (with a rather extensive and flexible library) to assemble a file and it's meta-data into a standard "network" file type before you ship it off to a computer which does not have this kind of filesystem.
Probably something like:
$> mkfile ~/songs/OompaLoopmas
Would take the fs-organized file and meta-data: ~/songs/OompaLoopmas ~/songs/OompaLoo pmas/title ~/songs/OompaLoopmas/artist ~/songs/O ompaLoopmas/genre ~/songs/OompaLoopmas/year ~/so ngs/OompaLoopmas/album ~/songs/OompaLoopmas/track ~/songs/OompaLoopmas/..uid ~/songs/OompaLoopmas /..gid ~/songs/OompaLoopmas/..rwx ~/songs/OompaL oopmas/..type (contains "audio/mpeg")
and make the following basic "networkable" file, with no meta-data other than standard file-system meta-data:
Applications which use network sockets would be aware that before sending a file across the network, it should probably convert it into a network file first.
Perhaps there would be a way to fopen the file with a flag indicating it needs to be run through the library which converts the file into it's original "network form" and feed that stream on the file handle returned from fopen().
It would be much more taxing on the filesystem to change the original file to reflect the meta-data every time something in that meta-data is changed. If one byte of data needs to be added to the front of a long file, that could require the whole file to be re-written. These kinds of changes will probably occur a lot more frequently than the times where a file needs to be made "ready" to go out on the network.
For that reason, I think it would probably be more efficient if the conversion process is made at the time the data is copied to or from the network. A system of libraries to do this conversion would probably be more elegant, and would be much more well integrated with the pupropse of the file system described in the article.
As a bonus, the packager could perhaps also be intelligent enough to do file conversions through some additional modular libraries (if they are available).
$> mkfile -t ogg ~/songs/OompaLoopmas
Obviously you wouldn't be able to convert all files to all types.
$> mkfile -t jpg ~/songs/OompaLoopmas Error: ~/songs/OompaLoopas contains 'audio/mpeg' and cannot be converted to 'image/jpeg'.
I like most of the ideas proposed in the article, and I hope they get a chance to make it into the mainstream, though I'm sure it will take quite a bit of time before that can happen.
The only thing I'm not quite comfortable about is the mount layers idea, as that seems it could make room for a lot of confusion if it's use is not kept to a minimum.
More werid crap can be found by replacing the "000003" in the URL with any other padded number in that general vicinity.
I'll admit I like the approach. It's kind of a bit entertaining to see a marketing company which blatantly badmouths it's client in it's marketing material (even if it is part of the plan) =)
My Athlon 2000 ran at about 65C with the stock fan that came with it. I had to upgrade to one of those huge fan heat-sink things to get it down to the low 50's.
However, I seem to recall the 2100 was started on a smaller die size, which probably runs a lot cooler than the 2000.
Also cat-5 cable is $50 for 1000' retail. USB is $20 for 6'.
Wouldn't you say it's a bit unfair to compare bulk cable having no connectors at the ends with a retail-priced blister-packed consumer-ready cable?
The issue with length is valid, however. USB is not a standard intended for LAN use. =)
Personally, I look forward to getting our homes wired for DC. I'm getting tired of all of the transformer bricks that litter every corner of my apartment.
The last house I lived in was across a street from the Florida East Coast rail line. There were sign posts every few meters along the rail line warning about digging becuase of the fiber optic lines.
A half a km or so south of where I was living, there were two small air-conditioned barbed-fenced-in buildings, sitting next to sizeable propane tanks (presumably for backup generator). I assume they must be optical relay stations or something of the sort having to do with those fiber lines.
What sucked was that when I was living there, I couldn't get higher than a 21.6k internet connection (it was a rural area), but all the while there was likely gigabits/sec flying by my front yard =D
What I like about doing logic inside a.jsp is that I don't need to go configure the web.xml or other.conf files just to add more pages to the website. The server picks up the.jsp and figures it's mapping out on it's own.
Besides, is there really any disadvantage to using one.jsp for the controller which forwards to another.jsp for the view?
It's a lot less of a hassle than having to remember to configure the servlet and servlet-mapping directives in the web.xml for *all* the servlets, every time I set up a new server.
Slashdot Mirror
WTS: Spoon, slightly bent.
Obviously, in the use of legacy file formats, we would need filesystem hooks to do conversions at the time that the files arrive and/or leave the computer over a network.
Once we have become comfortable with a filesystem like the one described in the article, new file formats would be developed which would start putting the regular file data in with the meta-data in an organized fashion which makes all of the important parts easily accessible.
This would be quite elegant, as you would not have to open the file and seek around to get to some piece of data if that's all you need. Instead, you just crawl down the hierarchy to the part you want and open that file and you're pointed right at the beginning of the data you need.
The .info files for the Amiga, IIRC, were only for the workbench-related meta-data (including the icon).
.info file co-existing with all of the files in the filesystem, and the .info file did not contain read/write/archive/hidden/etc types of permission meta-data.
You didn't have an
With the system that was proposed, you would probably need some kind of file packager system (with a rather extensive and flexible library) to assemble a file and it's meta-data into a standard "network" file type before you ship it off to a computer which does not have this kind of filesystem.
o pmas/titleO ompaLoopmas/genreo ngs/OompaLoopmas/albumk s /..gidL oopmas/..type (contains "audio/mpeg")
m p3/..uid/ OompaLoopmas.mp3/..rwx. .type (contains "application/octet-stream")
Probably something like:
$> mkfile ~/songs/OompaLoopmas
Would take the fs-organized file and meta-data:
~/songs/OompaLoopmas
~/songs/OompaLo
~/songs/OompaLoopmas/artist
~/songs/
~/songs/OompaLoopmas/year
~/s
~/songs/OompaLoopmas/trac
~/songs/OompaLoopmas/..uid
~/songs/OompaLoopma
~/songs/OompaLoopmas/..rwx
~/songs/Oompa
and make the following basic "networkable" file, with no meta-data other than standard file-system meta-data:
~/songs/OompaLoopmas.mp3
~/songs/OompaLoopmas.
~/songs/OompaLoopmas.mp3/..gid
~/songs
~/songs/OompaLoopmas.mp3/
Applications which use network sockets would be aware that before sending a file across the network, it should probably convert it into a network file first.
Perhaps there would be a way to fopen the file with a flag indicating it needs to be run through the library which converts the file into it's original "network form" and feed that stream on the file handle returned from fopen().
It would be much more taxing on the filesystem to change the original file to reflect the meta-data every time something in that meta-data is changed. If one byte of data needs to be added to the front of a long file, that could require the whole file to be re-written. These kinds of changes will probably occur a lot more frequently than the times where a file needs to be made "ready" to go out on the network.
For that reason, I think it would probably be more efficient if the conversion process is made at the time the data is copied to or from the network. A system of libraries to do this conversion would probably be more elegant, and would be much more well integrated with the pupropse of the file system described in the article.
As a bonus, the packager could perhaps also be intelligent enough to do file conversions through some additional modular libraries (if they are available).
$> mkfile -t ogg ~/songs/OompaLoopmas
Obviously you wouldn't be able to convert all files to all types.
$> mkfile -t jpg ~/songs/OompaLoopmas
Error: ~/songs/OompaLoopas contains 'audio/mpeg' and cannot be converted to 'image/jpeg'.
I like most of the ideas proposed in the article, and I hope they get a chance to make it into the mainstream, though I'm sure it will take quite a bit of time before that can happen.
The only thing I'm not quite comfortable about is the mount layers idea, as that seems it could make room for a lot of confusion if it's use is not kept to a minimum.
The Florida Turnpike was named the Ronald Reagan Highway a few years ago...
Despite this, I don't know anyone who calls it by that name.
If that's what it is, and if it works effectively, they have one hell of an idea to sell more PS3's =)
It seems there's a sizeable group of hardcore gamers seem to have endless cash when it comes to maximizing their game performance.
I don't know where I learned this techique, but it seems to work well.
1. Type randomly on the keyboard
Example: asdiugbisdnmi;jqwefasdf
2. Crop out about 3-6 letters out of the middle, avoiding vowels.
Example: gbsdn
3. Insert random vowels whereever necessary to make the word pronounceable.
Example: Gobsidon
4. Make any minor adjustments.
Example: Gobsidion
5. If unhappy, return to step 1 and try again.
Heh. Gobsidion sounds kinda cool actually...
http://www.beta-7.com/blog/archives/000003.html which has a comment written by a "Jim" who's name links to GMD Studios, a "groundbreaking new media production firm based in Orlando, Florida".
More werid crap can be found by replacing the "000003" in the URL with any other padded number in that general vicinity.
I'll admit I like the approach. It's kind of a bit entertaining to see a marketing company which blatantly badmouths it's client in it's marketing material (even if it is part of the plan) =)
Ok, after reading up on this and re-reading the post I responded to, I am offically declaring my reply stupid. =)
I'll admit I don't know a whole lot about this, but can't you get more than 1 bit per baud by using something like QAM?
Heh. My 2.4GHz phone got interference whenever someone used a microwave oven nearby. =)
My Athlon 2000 ran at about 65C with the stock fan that came with it. I had to upgrade to one of those huge fan heat-sink things to get it down to the low 50's.
However, I seem to recall the 2100 was started on a smaller die size, which probably runs a lot cooler than the 2000.
Also cat-5 cable is $50 for 1000' retail. USB is $20 for 6'.
Wouldn't you say it's a bit unfair to compare bulk cable having no connectors at the ends with a retail-priced blister-packed consumer-ready cable?
The issue with length is valid, however. USB is not a standard intended for LAN use. =)
Personally, I look forward to getting our homes wired for DC. I'm getting tired of all of the transformer bricks that litter every corner of my apartment.
And then we'll have powered wireless ethernet! =D
distribute PDFs or host HTML files
If you can post it in PDF, please post an HTML copy as well. It is frustrating to come across content which is only available in PDF format.
With the screen down the Yopy is about the same depth as a paperback book
Like this?
Or Like this?
Anyone know of something like this?
Content-Type: audio/x-wav
Filename: insect_sounds/crickets.wav
Republicans aren't anti-science, they're justf uture- and-everybody-else-on-the-planet-except-ME.
pro-do-whatever-serves-me-NOW-and-damn-the-
Mabye when Ultima Online 2 comes out
Wasn't the team that was working on UO2 diverted into developing SWG?
it costs just about as much to turn all the lights off in labor as the added cost of just leaving them on all the time.
Hmm. Perhaps my roommates must think that they are buying energy in blocks.
Besides with much of human life 'spread out among the stars' the earth just might become interesting
Our decendents who 'spread out among the stars' would most likely not be classified as 'human' by one of us living today.
A million bucks is a feasible investment for a city that size, but what do you do with the 9.75 gigawatts left over?
Power eight DeLorean time machines?
The last house I lived in was across a street from the Florida East Coast rail line. There were sign posts every few meters along the rail line warning about digging becuase of the fiber optic lines.
A half a km or so south of where I was living, there were two small air-conditioned barbed-fenced-in buildings, sitting next to sizeable propane tanks (presumably for backup generator). I assume they must be optical relay stations or something of the sort having to do with those fiber lines.
What sucked was that when I was living there, I couldn't get higher than a 21.6k internet connection (it was a rural area), but all the while there was likely gigabits/sec flying by my front yard =D
Isn't it great to have so many standards to choose from?
I'm laying low until something prevails. Struts seems to be top on my list to invest some reading time in (whenever I finally get some time)...
What I like about doing logic inside a .jsp is that I don't need to go configure the web.xml or other .conf files just to add more pages to the website. The server picks up the .jsp and figures it's mapping out on it's own.
.jsp for the controller which forwards to another .jsp for the view?
Besides, is there really any disadvantage to using one
It's a lot less of a hassle than having to remember to configure the servlet and servlet-mapping directives in the web.xml for *all* the servlets, every time I set up a new server.