Small object support is good. Robustness against crashes is good if it doesn't cost performance.
A generic "database layer" in the file system, meaning something that allows extensible attributes or something that provides file indexing, is at best superfluous and probably harmful to performance.
If you merely want real-time file indexing, Linux already has the necessary kernel API, and it is independent of file system; all you need for that is change notification (changedfiles, FAM, dnotify) and some user code. The fact that almost nobody bothers running it tells you something.
File systems don't need to get a lot more complicated. Databases are useful, but in addition to file systems, not as a replacement for them.
Linux may well beat Microsoft on this feature, but it's a race that's not worth winning as far as I'm concerned. Please leave the file system alone.
Current-generation file systems were designed to handle the drive capacity and file sizes of modern computing, but not the number of files.
It's a hierarchical organization; it doesn't matter how big the drive gets.
A simple name search for a file across an entire drive can take ages,
Why would I want to do "a simple name search for a file across an entire drive"? The file name is meaningless outside the context of its hierarchy.
thus the continued need for 'locate', which builds a search database on a daily basis.
Yes, and it's fine for what it is. I certainly wouldn't want the overhead of updating the "locate" database every time a file changes somewhere.
MS are taking out the middle man.
Well, welcome to the club. For years, Linux has had several implementations, among them FAM, dnotify, and changedfiles, with hooks into indexing systems, and Linux is hardly the first.
But, you know what, few people are using it because it really isn't all that useful. For casual queries ("find all the documents in my home directory that..."), databases are too inflexible and direct searching is fast enough. And for genuine document databases (documentation, PDF repositories, etc.), you are far better off with a real document database.
Microsoft should focus on creating a robust file system with decent performance, not get side-tracked with gimmicks. NTFS could still stand a lot of improvement.
Most filesystems today weren't designed with 200 Gb drives and millions of files in mind.
I have no idea what "most" is supposed to mean in this context, but systems like NTFS, ext3, ReiserFS, XFS, and JFS were definitely designed for those kinds of applications.
A relational database setup should do wonders for file search and access.
Relational databases aren't designed for millions of records with potentially huge BLOBs in them. In fact, the way Oracle and DB2 handle that kind of data is by putting it into the file system; the database just refers to it and tries to keep it consistent.
Of course, Linux didn't do it first; Linux hardly ever does anything first. Doing things "first" is not the point of Linux.
However, BeOS also isn't the first to implement an attributed file system or to implement automatic indexing, not by a couple of decades.
Is it "GREAT"? Possibly for a desktop operating system, but you hardly need it there because with a fast file system, searches are fast anyway. Searching through all attributes of the 80000 files in my home directory takes about 2 seconds on my Linux box with no indexing whatsoever; I mean, how much faster do you want this stuff? And if you really want indexing, there are user daemons (plus a small kernel module for change detection) to do that, but nobody ever seems to bother.
For many other uses of an operating system, adding this sort of complexity and overhead to the file system is a serious problem. And I think these kinds of features are kind of symptomatic for the deeper reasons why BeOS didn't make it.
This will be better than FAT32 and NTFS, but it is hardly "breaking new ground". A number of operating systems have used more-or-less relational databases as their file systems; it's a special purpose technology and has no place in a general purpose OS. I think ReiserFS makes the right kind of compromise here: it uses a little bit of database technology, but it mostly remains a traditional file system.
Convert the Word stuff to HTML, PDF, or RTF, put it all into a directory tree, and index it with one of the open source intranet web search engines (htdig works OK for me).
The six penguins from Ohio started it all, Tollini said, apparently convincing the others to join them for the watery daily circuit.
Great! Six workout nuts convinced the nerd penguins to get in shape. Next thing you know, they'll all start dating. This means the next release will be months late.
The idea that you can be "infected" by simply looking at GPLd code is nonsense.
The reason why people worry about it is because many commercial vendors make such claims. Sun, for example, has claimed that people are "contaminated" by looking at Sun's Java source code. SCO is effectively making similar claims. Whether they hold up or not is another question, but companies are taking them seriously. And if they take them seriously for closed source code, it seems rational to take them seriously for open source as well.
Yeah: Plan 9 is an operating system, and a small and well-designed one at that. J2EE is a bloated, poorly designed class library well-removed from the hardware or operating system; the fact that J2EE provides a hierarchical namespace is almost incidental.
If you are looking for Plan 9 like name spaces as libraries, there are plenty of better choices than J2EE or Java. In fact, something like the Plastic file system for Linux can make it available as a library for almost any program (by changing the C library during loading).
I'm assuming you're talking either about additional Palm applications or you come from an environment that doesn't mandate the use of Outlook?
Yes, both, in fact. Palm has good applications built-in, and Clies come with really excellent additional ones.
If you are stuck with Outlook, of course the answer is to use another Microsoft product to talk to it; what do you expect? The converse is also true: PocketPC doesn't talk well to anything other than Microsoft products. That is another reason to avoid it.
if the current bill was advising to try proprietary software before open source you'd think it was ridiculous so why isn't the reverse true?
Because we generally prefer our governments not to pay money for something they can get for free. Putting free and non-free stuff on equal footing invites corruption.
Spending money should require special justification, while not spending money shouldn't. And in the case of, say, Microsoft licenses, we aren't talking a little money, we are talking a huge amount of money.
I have. Sorry, it's not an alternative as far as I'm concerned. Ultimately, no matter how badly PalmOS sucks as an operating system, its applications are much better than PocketPC, and that's what counts in a PDA.
If I wanted something that was technically well-designed, then a Zaurus would be a better choice than either Palm/Clie or PocketPC.
If you want a lightweight, solid-state video recorder, you have much better options than the Panasonic or Clie. Several of the Sony digital cameras offer real-time 640x480 MPEG recording up to the capacity of the memory stick (40 minutes on a 1G memory stick). A few other digital cameras have similar capabilities.
I have owned some Sony handhelds. Sony hardware is great, and PalmOS has going for it that there is a lot of software for it. But there are some real problems with the use of PalmOS on these devices.
For example, the Sony uses a different audio API from the Palm handhelds (because Palm didn't use to have an audio API) and Sony doesn't document it, so Palm audio players won't work on the Sony devices.
Also, many of the applications for Palm are specifically written for 160x160 pixels and will look absolutely horrible on a 320x320 screen. TopGun SSH is one of many examples.
Memory and memory management on these devices is also a problem. It is an enormous amount of work porting UNIX or Windows-based libraries to these devices, so a lot of software has to be written from scratch. And, in fact, a lot of pretty basic networking software just does not exist.
Applications also tend to crash with some frequency, which ends up rebooting the handheld (just like DOS).
PalmOS is designed with an "everything is a database" philosophy. Unfortunately, that runs into a brick wall when you stick in an SD or MS card, which, in fact, has a file system on it, and PalmOS doesn't deal well with it. Applications expect their data in particular subdirectories or ignore it. I have yet to figure out how to get the Sony movie player to play an MPEG file--I simply don't know where to put it on the memory stick and what to call it so that it will see it. And the lack of a file system inside the handheld means that installing and uninstalling applications is a complete mess: everything is just dumped into what amounts to a single top-level directory.
Sony does the right thing with these devices: they treat them as consumer gadgets. That is, they preload them with all the software you might ever want (including an MP3 player). The fact that they run PalmOS is almost incidental.
I think I can guardedly recommend the Sony handhelds since the hardware is nifty and the built-in applications are good (when they work). Just be aware of what you are getting and the limitations you have to live with.
This kowtowing to the god of standards is, I believe, doing great damage to our industry,
Let's cut to the chase. Sun has renegged on their promise to standardize Java and Sun's employees are trying to make excuses for that reprehensible behavior.
Yes, standards may, sometimes, inhibit innovation. That's why standardization takes a long time as people hash things out and figure things out. You stick with a standardization process until the core parts are not innovative anymore. That may take a few years, or a couple of decades (as in the case of C++). What counts is the commitment, the process, and the eventual outcome.
The long-standing standards are those that were first de facto standards, and were described (no invented) by the standards bodies.
Yes, like Windows. That's, however, the kind of standard we want to avoid. That's why the industry accepted Java with open arms when Sun promised to standardize it quickly. Then Sun did a 180 degree turn and said "actually, we would much prefer to make Java a proprietary, de-facto standard, like Microsoft does with Windows; screw our customers and screw the standards process".
In different words, the cost of subjecting Java to a standardization process was taken into account when the industry adopted Java. Sun's behavior is unacceptable and shows that the company is not to be trusted, and the software industry should drop Java.
Something that is not a standard is closed, proprietary, and to be avoided at all costs.
No, not at all. Open source software may not conform to a standard, but it's not "closed" or "proprietary".
Something that is "closed and proprietary", is rightfully viewed with suspicion, because customers place themselves into a position of paying an arm and a leg (the vendor can keep charging a bit extra because of the cost of switching to something else)--just like Microsoft does.
Something that was initially distributed with the promise of becoming both open and standard conforming and then later was changed into something closed and proprietary should be rejected by any rational user because it has all the risks and costs of another proprietary standard and because the company has already clearly demonstrated that it is not to be trusted. Like Sun and Java.
US measures are already based on the metric system--they just use weird multipliers.
So, whatever chicken scratches or lumps of stuff the metric system uses for its definitions affect US measures equally. (Of course, if you had bothered to read the article, you would have noted that weight is the only SI unit left that is defined in terms of a physical reference object.)
Imperial units are the units used in the Commonwealth, not the US. Many imperial units differ significantly from US units: US units generally refer to smaller amounts than their Imperial counterparts (gee I wonder how that happened). For practical purposes, Imperial units are not in use anymore since all (?) the countries that were using them have switched to metric.
Perhaps we don't have the coercive state apparatus necessary to 'make' the metric system the primary system that we use.
We do. It's just so much more convenient to use our coercive state apparatus to keep in place units that create trade barriers and protect domestic manufacturers.
A lot of these Microsoft "donations" are not pure software donations. Rather, Microsoft donates money but imposes obligations that effectively require the recipient to buy a lot of Microsoft products in the market. That kind of "donation" may end up being tax deductible.
Hey, there is a long tradition of that. The US does something similar with foreign aid, "giving away" billions of dollars but requiring purchases of US goods and services.
But to be honest if Microsoft didn't give away the money, people would be crying and moaning about that.
Companies aren't supposed to give away money, they are supposed to operate efficiently. If they have lots of money left over to give away, that's only an indication that some company isn't operating efficiently.
Of course, Microsoft isn't giving away money anyway, they are giving away temporary licenses for products.
Traditional UNIX style also uses "little languages", interactive exploration, and bottom-up programming. Matlab and Perl programmers take a similar approach. And any good OO developer will go through the same exercise when thinking about what operations to put into the interfaces to each class.
Graham's stuff on Lisp seems just like his stuff on spam filtering: either he doesn't know what other people have been doing for decades or he chooses to ignore it deliberately.
Slashdot Mirror
Small object support is good. Robustness against crashes is good if it doesn't cost performance.
A generic "database layer" in the file system, meaning something that allows extensible attributes or something that provides file indexing, is at best superfluous and probably harmful to performance.
If you merely want real-time file indexing, Linux already has the necessary kernel API, and it is independent of file system; all you need for that is change notification (changedfiles, FAM, dnotify) and some user code. The fact that almost nobody bothers running it tells you something.
File systems don't need to get a lot more complicated. Databases are useful, but in addition to file systems, not as a replacement for them.
Linux may well beat Microsoft on this feature, but it's a race that's not worth winning as far as I'm concerned. Please leave the file system alone.
Current-generation file systems were designed to handle the drive capacity and file sizes of modern computing, but not the number of files.
It's a hierarchical organization; it doesn't matter how big the drive gets.
A simple name search for a file across an entire drive can take ages,
Why would I want to do "a simple name search for a file across an entire drive"? The file name is meaningless outside the context of its hierarchy.
thus the continued need for 'locate', which builds a search database on a daily basis.
Yes, and it's fine for what it is. I certainly wouldn't want the overhead of updating the "locate" database every time a file changes somewhere.
MS are taking out the middle man.
Well, welcome to the club. For years, Linux has had several implementations, among them FAM, dnotify, and changedfiles, with hooks into indexing systems, and Linux is hardly the first.
But, you know what, few people are using it because it really isn't all that useful. For casual queries ("find all the documents in my home directory that..."), databases are too inflexible and direct searching is fast enough. And for genuine document databases (documentation, PDF repositories, etc.), you are far better off with a real document database.
Microsoft should focus on creating a robust file system with decent performance, not get side-tracked with gimmicks. NTFS could still stand a lot of improvement.
Most filesystems today weren't designed with 200 Gb drives and millions of files in mind.
I have no idea what "most" is supposed to mean in this context, but systems like NTFS, ext3, ReiserFS, XFS, and JFS were definitely designed for those kinds of applications.
A relational database setup should do wonders for file search and access.
Relational databases aren't designed for millions of records with potentially huge BLOBs in them. In fact, the way Oracle and DB2 handle that kind of data is by putting it into the file system; the database just refers to it and tries to keep it consistent.
Of course, Linux didn't do it first; Linux hardly ever does anything first. Doing things "first" is not the point of Linux.
However, BeOS also isn't the first to implement an attributed file system or to implement automatic indexing, not by a couple of decades.
Is it "GREAT"? Possibly for a desktop operating system, but you hardly need it there because with a fast file system, searches are fast anyway. Searching through all attributes of the 80000 files in my home directory takes about 2 seconds on my Linux box with no indexing whatsoever; I mean, how much faster do you want this stuff? And if you really want indexing, there are user daemons (plus a small kernel module for change detection) to do that, but nobody ever seems to bother.
For many other uses of an operating system, adding this sort of complexity and overhead to the file system is a serious problem. And I think these kinds of features are kind of symptomatic for the deeper reasons why BeOS didn't make it.
This will be better than FAT32 and NTFS, but it is hardly "breaking new ground". A number of operating systems have used more-or-less relational databases as their file systems; it's a special purpose technology and has no place in a general purpose OS. I think ReiserFS makes the right kind of compromise here: it uses a little bit of database technology, but it mostly remains a traditional file system.
Convert the Word stuff to HTML, PDF, or RTF, put it all into a directory tree, and index it with one of the open source intranet web search engines (htdig works OK for me).
The six penguins from Ohio started it all, Tollini said, apparently convincing the others to join them for the watery daily circuit.
Great! Six workout nuts convinced the nerd penguins to get in shape. Next thing you know, they'll all start dating. This means the next release will be months late.
The idea that you can be "infected" by simply looking at GPLd code is nonsense.
The reason why people worry about it is because many commercial vendors make such claims. Sun, for example, has claimed that people are "contaminated" by looking at Sun's Java source code. SCO is effectively making similar claims. Whether they hold up or not is another question, but companies are taking them seriously. And if they take them seriously for closed source code, it seems rational to take them seriously for open source as well.
Yeah: Plan 9 is an operating system, and a small and well-designed one at that. J2EE is a bloated, poorly designed class library well-removed from the hardware or operating system; the fact that J2EE provides a hierarchical namespace is almost incidental.
If you are looking for Plan 9 like name spaces as libraries, there are plenty of better choices than J2EE or Java. In fact, something like the Plastic file system for Linux can make it available as a library for almost any program (by changing the C library during loading).
I'm assuming you're talking either about additional Palm applications or you come from an environment that doesn't mandate the use of Outlook?
Yes, both, in fact. Palm has good applications built-in, and Clies come with really excellent additional ones.
If you are stuck with Outlook, of course the answer is to use another Microsoft product to talk to it; what do you expect? The converse is also true: PocketPC doesn't talk well to anything other than Microsoft products. That is another reason to avoid it.
if the current bill was advising to try proprietary software before open source you'd think it was ridiculous so why isn't the reverse true?
Because we generally prefer our governments not to pay money for something they can get for free. Putting free and non-free stuff on equal footing invites corruption.
Spending money should require special justification, while not spending money shouldn't. And in the case of, say, Microsoft licenses, we aren't talking a little money, we are talking a huge amount of money.
You need to try a Pocket PC.
I have. Sorry, it's not an alternative as far as I'm concerned. Ultimately, no matter how badly PalmOS sucks as an operating system, its applications are much better than PocketPC, and that's what counts in a PDA.
If I wanted something that was technically well-designed, then a Zaurus would be a better choice than either Palm/Clie or PocketPC.
Um... PalmOS 5? I think you're thinking of 3.5 or 4.0,
I am exactly talking about Palm OS 5. In fact, the only Sony Clie's I have used are Palm OS 5.
Actually--you're kinda off on the whole file system thing, but we'll let that pass...
I'm just reporting my experiences as a user.
Japanese youngster can adopt and dumb new things pretty quickly, Americans might be different.
:-)
American youngsters are no different in that they adopt dumb new things, they are simply different in the kind of dumb new things they adopt
If you want a lightweight, solid-state video recorder, you have much better options than the Panasonic or Clie. Several of the Sony digital cameras offer real-time 640x480 MPEG recording up to the capacity of the memory stick (40 minutes on a 1G memory stick). A few other digital cameras have similar capabilities.
I have owned some Sony handhelds. Sony hardware is great, and PalmOS has going for it that there is a lot of software for it. But there are some real problems with the use of PalmOS on these devices.
For example, the Sony uses a different audio API from the Palm handhelds (because Palm didn't use to have an audio API) and Sony doesn't document it, so Palm audio players won't work on the Sony devices.
Also, many of the applications for Palm are specifically written for 160x160 pixels and will look absolutely horrible on a 320x320 screen. TopGun SSH is one of many examples.
Memory and memory management on these devices is also a problem. It is an enormous amount of work porting UNIX or Windows-based libraries to these devices, so a lot of software has to be written from scratch. And, in fact, a lot of pretty basic networking software just does not exist.
Applications also tend to crash with some frequency, which ends up rebooting the handheld (just like DOS).
PalmOS is designed with an "everything is a database" philosophy. Unfortunately, that runs into a brick wall when you stick in an SD or MS card, which, in fact, has a file system on it, and PalmOS doesn't deal well with it. Applications expect their data in particular subdirectories or ignore it. I have yet to figure out how to get the Sony movie player to play an MPEG file--I simply don't know where to put it on the memory stick and what to call it so that it will see it. And the lack of a file system inside the handheld means that installing and uninstalling applications is a complete mess: everything is just dumped into what amounts to a single top-level directory.
Sony does the right thing with these devices: they treat them as consumer gadgets. That is, they preload them with all the software you might ever want (including an MP3 player). The fact that they run PalmOS is almost incidental.
I think I can guardedly recommend the Sony handhelds since the hardware is nifty and the built-in applications are good (when they work). Just be aware of what you are getting and the limitations you have to live with.
approved by [...] a little company named Microsoft.
Microsoft has picked lots of losers in the past, so I don't think that matters much.
This kowtowing to the god of standards is, I believe, doing great damage to our industry,
Let's cut to the chase. Sun has renegged on their promise to standardize Java and Sun's employees are trying to make excuses for that reprehensible behavior.
Yes, standards may, sometimes, inhibit innovation. That's why standardization takes a long time as people hash things out and figure things out. You stick with a standardization process until the core parts are not innovative anymore. That may take a few years, or a couple of decades (as in the case of C++). What counts is the commitment, the process, and the eventual outcome.
The long-standing standards are those that were first de facto standards, and were described (no invented) by the standards bodies.
Yes, like Windows. That's, however, the kind of standard we want to avoid. That's why the industry accepted Java with open arms when Sun promised to standardize it quickly. Then Sun did a 180 degree turn and said "actually, we would much prefer to make Java a proprietary, de-facto standard, like Microsoft does with Windows; screw our customers and screw the standards process".
In different words, the cost of subjecting Java to a standardization process was taken into account when the industry adopted Java. Sun's behavior is unacceptable and shows that the company is not to be trusted, and the software industry should drop Java.
Something that is not a standard is closed, proprietary, and to be avoided at all costs.
No, not at all. Open source software may not conform to a standard, but it's not "closed" or "proprietary".
Something that is "closed and proprietary", is rightfully viewed with suspicion, because customers place themselves into a position of paying an arm and a leg (the vendor can keep charging a bit extra because of the cost of switching to something else)--just like Microsoft does.
Something that was initially distributed with the promise of becoming both open and standard conforming and then later was changed into something closed and proprietary should be rejected by any rational user because it has all the risks and costs of another proprietary standard and because the company has already clearly demonstrated that it is not to be trusted. Like Sun and Java.
Gravity decreases exponentially with an exponent of 2 as the distance between the two objects increases;
Stop using big words if you don't understand what they mean.
US measures are already based on the metric system--they just use weird multipliers.
So, whatever chicken scratches or lumps of stuff the metric system uses for its definitions affect US measures equally. (Of course, if you had bothered to read the article, you would have noted that weight is the only SI unit left that is defined in terms of a physical reference object.)
Imperial units are the units used in the Commonwealth, not the US. Many imperial units differ significantly from US units: US units generally refer to smaller amounts than their Imperial counterparts (gee I wonder how that happened). For practical purposes, Imperial units are not in use anymore since all (?) the countries that were using them have switched to metric.
Perhaps we don't have the coercive state apparatus necessary to 'make' the metric system the primary system that we use.
We do. It's just so much more convenient to use our coercive state apparatus to keep in place units that create trade barriers and protect domestic manufacturers.
A lot of these Microsoft "donations" are not pure software donations. Rather, Microsoft donates money but imposes obligations that effectively require the recipient to buy a lot of Microsoft products in the market. That kind of "donation" may end up being tax deductible.
Hey, there is a long tradition of that. The US does something similar with foreign aid, "giving away" billions of dollars but requiring purchases of US goods and services.
But to be honest if Microsoft didn't give away the money, people would be crying and moaning about that.
Companies aren't supposed to give away money, they are supposed to operate efficiently. If they have lots of money left over to give away, that's only an indication that some company isn't operating efficiently.
Of course, Microsoft isn't giving away money anyway, they are giving away temporary licenses for products.
Traditional UNIX style also uses "little languages", interactive exploration, and bottom-up programming. Matlab and Perl programmers take a similar approach. And any good OO developer will go through the same exercise when thinking about what operations to put into the interfaces to each class.
Graham's stuff on Lisp seems just like his stuff on spam filtering: either he doesn't know what other people have been doing for decades or he chooses to ignore it deliberately.