Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

why not? 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • We really need an alternative to complement the directory structure. Something like a light database that indexes files on their type, date and other keywords (I am not even talking about indexing the content here), so you can just select the files you want to list. I am really tired of looking all over the system for files when I know what I want but not where it is.

    Of course the problem is to generate as many of the keywords automagically, with the user being able to add more in a simple way... quite a t

    • The problem is speed. Ever worked up to or past midnight (or whenever your slocate cron job runs)? The system slows to a crawl as it thrashes all over your filesystem. Now imagine that also doing full text indexing? Yikes.

      Plus I think there are a lot more questions with complex filesystems than there are answers, for instance the problem with sending a file from such a filesystem via email.

      Personally I'd rather keep filesystems simple, and work out funkier ways to actually work over the top of those. Mayb
      • As someone else has already mentioned, BeOS tried this originally and tossed it out due to speed problems. But then, hey, speed has never been an issue that's stopped Sun's Java. Why should it stop Microsoft? Maybe advances in hardware will hide any problems.

        Being able to add my own filesystem attributes was one of my favorite things about BeOS, though. With OpenBeos making progress, I might make it a goal to get back into Perl & Ruby on the BeOS platform. Perl 5.6 never was ported properly, thou

        • As someone else has already mentioned, BeOS tried this originally and tossed it out due to speed problems.
          Not in the demo's I've seen. Back when Be was releasing BeOS 3 or BeOS 4 (the first release for x86), they demoed BFS and Tracker together. First, they created a live query on the filesystem to find some kind of file. Next, they opened it up in Tracker. Next, they added some files to the filesystem and the new files magically appeared (and the old files magically disappeared).

          Next, they demonstrated processing 3 or 4 simultaneous Quicktime movies in realtime. Then they drop the box into single-CPU mode, and a few frames per second were being dropped (you had to have a really good eye to notice).

          At the end of these demos they claimed that BFS was offering 96% of the maximum theoretical throughput on these 9GB IDE drives.

          Perhaps the numbers are a lie. Perhaps they dropped BFS after 1998 or so. But what they did demonstrate was fast and impressive. From the few weeks I was running BeOS, I can say that it wasn't a faked demo, either. That OS and filesystem were damn fast.

          • Actually, I was referring to the *original* attempt by BeOS at an RDBMS turned filesystem. I'll have to look up the info in my BeOS Bible.

            By all accounts, BeOS is *still* one of the fastest and best filesystems to ever hit the market. I'll take it over Linux/Solaris any day. I'm actually planning on re-installing it, in lieu of the progress being made with OpenBeos.

            From what I've read, the folks working on OpenBeos have already made improvements by as much as 600% in some areas over the original BeOS

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.