Re:That's the dumbest thing I've heard all day!
on
MySQL FS
·
· Score: 1
Absolutely!
And, I'm sure somebody out there probably thinks the whole directory structure is too relational, or db-like, already. Give me a break!
Yes, a file system puts flat files inside a flat file; drives are more logically mapped anymore than they are physically mapped; RAID, LVM, and partitioning in general divvy that up into pieces; databases put relational data into a bunch of indexed flat files; BLOBs are nothing more than flat files stored in databases.
So, what is a drive or a partition or a file or a database? The lines are already so blurry you can't tell the difference, anymore, and you wouldn't want to, unless you want to go backward!
Re:People are missing the point.
on
MySQL FS
·
· Score: 1
Absolutely! Thanks for doing a great job at making my point.
All one has to do is program for a dynamic, RDBMS-driven website, storing (and retrieving) images on-the-fly to see what I mean, adding your point, above. Of course, websites aren't the only place this is an issue.
The "ultimate portability" and "Even shell scripts" points are really good.
AS/400, Palm-OS, Be-OS, Reiser-FS, etc., all do something like this now, as has been pointed out.
Of course, this now has to be implemented.
I think they said they'd never land a man on the moon, or something like that. Then, there was this group at NASA.
People are missing the point.
on
MySQL FS
·
· Score: 4
Did you ever hear about BLOBs? Imagine being able to load and unload BLOBs (Binary Large OBjects) in a database in an easier fashion, or, at least, in two different ways.
Imagine a dynamic web site that uses this! You could simply copy files (especially graphics files) to/from a table easily and look them up via SQL queries! My goodness, the usefulness is extreme, people.
Have any of you (fs!=db) nay-sayers ever tried to store/retrieve GIFs and JPEGs in a relational database for a web site -- an often daunting, but often necessary task? There are whole article on my to store/retrieve pics as BLOBs via MySQL/PHP on PHPBuilder.com: http://www.phpbuilder.com/columns/florian19991014. php3 and (sorta) http://www.phpbuilder.com/columns/bealers20000904. php3
So, for those of you who can't get over this idea, try doing sites that store images in databases sometime. An idea like this (one being done by the big RDBMs -- and I work for one of those) is a BOON for websites. It also has many other applications.
A layer of abstraction is often a good thing for filesystems, and it's where things are headed. IMHO, I think db's could provide BETTER security and make things more distributed, rather than current filesystems. Imagine whole new networked filesystems that are distributed databases. Open your mind. Think about it hard before brushing it aside.
Besides a db is an fs is a db. It depends on how you look at it, your definition, etc. Is a filesystem relational? Does a db use local storage, often RAW storage. The true computer definition of the two is not all that different. And, SQL is not the only query language out there. Haven't you heard of CLI, which uses commands like cat, ls, echo, rm, mv to handle data? What about those relationships called directories?
I say, what's the real issue? Raw speed? Oh, wah! Grow up and join the enterprise! Oops, I guess the AS/400 must not be a viable platform; they've been doing this HOW LONG?!?!?
Q: When are we Linux/Open Source people going to get enterprise-level file and storage management?A: When we get to the point that we implement at least a JFS (if not a full-fledged logged filesystem, good logical volume management, real uninterruptible power, truly fault-tolerant hardware/software clustering, better security, and fully distributed storage management that backups and versions data automagically.
On a lighter note, MySQL now implements a filesystem.:-)
Yes, PHPLIB does have support for this, and it works for PHP 3 and 4 out-of-the-box.
PHPLIB has a semi-steep learning curve, but, IMHO, it's definitely worth the extra initial effort. See http://phplib.netuse.de
Also, for a good PHP 4 book that includes a section on PHPLIB, try Web Application Development with PHP 4.0. See http://www.phpwizard.net/book/ (More info below)
Book info: Paperback - 384 pages Bk&Cd-Rom edition (July 15, 2000)
New Riders Publishing; ISBN: 0735709971 ; Dimensions (in inches): 0.91 x 8.93 x 6.96
Well, until you can get X-Open, their contributers (like Sun - Solaris, IBM - AIX, HP - HP/UX, SCO, SGI - IRIX, and others), and all the "big guys" doing Linux distros (at least RedHat, Caldera, TurboLinux, and SuSE -- and Mandrake, Storm, Debian, and possibly Slackware), it's all completely moot. The BSD camp would likely follow, too, of course, but this particular discussion is about the reason Linux doesn't use XML.conf file(s).
The reason it's moot? Ummm. Backward compatibility, maybe? What if RedHat, Mandrake, and Caldera, say, adopted this tomorrow? It would not only break many apps, many of which would silently fail, as another poster pointed out, but it would also cause code forks all over the place, require a cut-over period, no longer be Unix compliant, etc. Code forks and broken software are worse than the retraining of people, in my opinion. (Unix/Linux/BSD people are typically smart, by default.)
I agree it would be GREAT to have a standard, unified SAX (preferred) or DOM XML parser for our.conf files. It *would* eliminate so many problems and it would make admin programs such as Webmin, Comanche, Linuxconf, Yast, DrakConfig, etc. far easier to code, making the user-friendliness of Linux far easier to achieve.
But it would break so much and leave us non-Unix compliant. We simply CANNOT cut-over to XML tomorrow. This MUST be phased in, little by little.
A better approach:
Create a standard XML.conf parser/config tool/lib
Write all *NEW* software to *require* this, esp. for GNOME and KDE apps, but also text-mode apps and daemons
Get all your major software that is not "Unix standard" ported first to XML, such as Apache, Perl, etc.
Get your other apps and daemons converted, but allow them to run in either mode -- old.conf style or new XML.conf style.
Meanwhile you will need to write convertors. HEAVY testing, here!
The cut-overs (plural, very plural) would have to be done on a project-by-project basis.
This HAS to be planned to be done piece-meal and it's far more difficult than it looks at first, but it's worth it! We don't want to break things.
I'd totally agree that a single.conf parser is better than this mess of multiple.conf readers with multiple "standards" using SAX is a no-brainer. However, the old system works, so let's not just rush in. Let's plan it out and be careful to work with all the inidividual GNU (or whatever) projects are out there. There also needs to be one GNU project (not a million projects) out there to standardize and coordinate this for Linux, BSD, X-Open, etc.
Heck, invite X-Open, Sun, IBM, HP, SGI, RedHat/Cygnus, Caldera/SCO, TurboLinux, SuSE, Debian, Slackware, Mandrake, Storm, Torvalds, et al, BSDi, FreeBSD, GNOME, KDE, Apache, Perl, Python, Zend, Sendmail, BIND, Netscape/Mozilla, etc., to the same party and cooperate. It ought to be a POSIX standard!!!
If we don't do this, it will never succeed. We'll just have noble intentions, argue about it, and then fragment.
The CODA file system, if I'm not mistaken, can do some of these things.
I think we're wanting to see a combo of CODA/Intermezzo, GnuTella~Napster, Push Technology, OSPF routing, Data Compression using bzip2, Rsync and CVS, Squid, Multicast/Broadcast/MBONE, and Usenet news, sort of!
Big servers get pushed a highly compressed copy. A routing protocol looks at hops, bandwidth, etc. and distributes based on a closest partner, similar to GnuTella/Napster. Rsync and CVS version and re-sync data, especially when connections go down. CODA/Intermezzo (and Squid) caching algorithms would be both on clients and servers, to keep copies semi local, on an as-needed basis. Multicast/MBONE/IGMP/Broadcast would be used to send to multiple machines at once, while reducing bandwidth. The Usenet news like delivery method could assist in the push vs. routing vs. caching stuff.
EGAD! That's a tall order. However, this is the only way we're gonna get past the current bandwidth vs. distro situation on the 'net.
Slashdot Mirror
And, I'm sure somebody out there probably thinks the whole directory structure is too relational, or db-like, already. Give me a break!
Yes, a file system puts flat files inside a flat file; drives are more logically mapped anymore than they are physically mapped; RAID, LVM, and partitioning in general divvy that up into pieces; databases put relational data into a bunch of indexed flat files; BLOBs are nothing more than flat files stored in databases.
So, what is a drive or a partition or a file or a database? The lines are already so blurry you can't tell the difference, anymore, and you wouldn't want to, unless you want to go backward!
All one has to do is program for a dynamic, RDBMS-driven website, storing (and retrieving) images on-the-fly to see what I mean, adding your point, above. Of course, websites aren't the only place this is an issue.
The "ultimate portability" and "Even shell scripts" points are really good.
AS/400, Palm-OS, Be-OS, Reiser-FS, etc., all do something like this now, as has been pointed out.
Of course, this now has to be implemented.
I think they said they'd never land a man on the moon, or something like that. Then, there was this group at NASA.
Imagine a dynamic web site that uses this! You could simply copy files (especially graphics files) to/from a table easily and look them up via SQL queries! My goodness, the usefulness is extreme, people.
Have any of you (fs!=db) nay-sayers ever tried to store/retrieve GIFs and JPEGs in a relational database for a web site -- an often daunting, but often necessary task? There are whole article on my to store/retrieve pics as BLOBs via MySQL/PHP on PHPBuilder.com: http://www.phpbuilder.com/columns/florian19991014. php3 and (sorta) http://www.phpbuilder.com/columns/bealers20000904. php3
So, for those of you who can't get over this idea, try doing sites that store images in databases sometime. An idea like this (one being done by the big RDBMs -- and I work for one of those) is a BOON for websites. It also has many other applications.
A layer of abstraction is often a good thing for filesystems, and it's where things are headed. IMHO, I think db's could provide BETTER security and make things more distributed, rather than current filesystems. Imagine whole new networked filesystems that are distributed databases. Open your mind. Think about it hard before brushing it aside.
Besides a db is an fs is a db. It depends on how you look at it, your definition, etc. Is a filesystem relational? Does a db use local storage, often RAW storage. The true computer definition of the two is not all that different. And, SQL is not the only query language out there. Haven't you heard of CLI, which uses commands like cat, ls, echo, rm, mv to handle data? What about those relationships called directories?
I say, what's the real issue? Raw speed? Oh, wah! Grow up and join the enterprise! Oops, I guess the AS/400 must not be a viable platform; they've been doing this HOW LONG?!?!?
Q: When are we Linux/Open Source people going to get enterprise-level file and storage management?A: When we get to the point that we implement at least a JFS (if not a full-fledged logged filesystem, good logical volume management, real uninterruptible power, truly fault-tolerant hardware/software clustering, better security, and fully distributed storage management that backups and versions data automagically.
On a lighter note, MySQL now implements a filesystem. :-)
Yes, PHPLIB does have support for this, and it works for PHP 3 and 4 out-of-the-box. PHPLIB has a semi-steep learning curve, but, IMHO, it's definitely worth the extra initial effort. See http://phplib.netuse.de Also, for a good PHP 4 book that includes a section on PHPLIB, try Web Application Development with PHP 4.0. See http://www.phpwizard.net/book/ (More info below) Book info: Paperback - 384 pages Bk&Cd-Rom edition (July 15, 2000) New Riders Publishing; ISBN: 0735709971 ; Dimensions (in inches): 0.91 x 8.93 x 6.96
My wife and I are also at that stage. Version 0.99RC3, waiting for the full productional version to ship.
The reason it's moot? Ummm. Backward compatibility, maybe? What if RedHat, Mandrake, and Caldera, say, adopted this tomorrow? It would not only break many apps, many of which would silently fail, as another poster pointed out, but it would also cause code forks all over the place, require a cut-over period, no longer be Unix compliant, etc. Code forks and broken software are worse than the retraining of people, in my opinion. (Unix/Linux/BSD people are typically smart, by default.)
I agree it would be GREAT to have a standard, unified SAX (preferred) or DOM XML parser for our .conf files. It *would* eliminate so many problems and it would make admin programs such as Webmin, Comanche, Linuxconf, Yast, DrakConfig, etc. far easier to code, making the user-friendliness of Linux far easier to achieve.
But it would break so much and leave us non-Unix compliant. We simply CANNOT cut-over to XML tomorrow. This MUST be phased in, little by little.
A better approach:
Create a standard XML .conf parser/config tool/lib
Write all *NEW* software to *require* this, esp. for GNOME and KDE apps, but also text-mode apps and daemons
Get all your major software that is not "Unix standard" ported first to XML, such as Apache, Perl, etc.
Get your other apps and daemons converted, but allow them to run in either mode -- old .conf style or new XML .conf style.
Meanwhile you will need to write convertors. HEAVY testing, here!
The cut-overs (plural, very plural) would have to be done on a project-by-project basis.
This HAS to be planned to be done piece-meal and it's far more difficult than it looks at first, but it's worth it! We don't want to break things.
I'd totally agree that a single .conf parser is better than this mess of multiple .conf readers with multiple "standards" using SAX is a no-brainer. However, the old system works, so let's not just rush in. Let's plan it out and be careful to work with all the inidividual GNU (or whatever) projects are out there. There also needs to be one GNU project (not a million projects) out there to standardize and coordinate this for Linux, BSD, X-Open, etc.
Heck, invite X-Open, Sun, IBM, HP, SGI, RedHat/Cygnus, Caldera/SCO, TurboLinux, SuSE, Debian, Slackware, Mandrake, Storm, Torvalds, et al, BSDi, FreeBSD, GNOME, KDE, Apache, Perl, Python, Zend, Sendmail, BIND, Netscape/Mozilla, etc., to the same party and cooperate. It ought to be a POSIX standard!!!
If we don't do this, it will never succeed. We'll just have noble intentions, argue about it, and then fragment.
The CODA file system, if I'm not mistaken, can do some of these things. I think we're wanting to see a combo of CODA/Intermezzo, GnuTella~Napster, Push Technology, OSPF routing, Data Compression using bzip2, Rsync and CVS, Squid, Multicast/Broadcast/MBONE, and Usenet news, sort of! Big servers get pushed a highly compressed copy. A routing protocol looks at hops, bandwidth, etc. and distributes based on a closest partner, similar to GnuTella/Napster. Rsync and CVS version and re-sync data, especially when connections go down. CODA/Intermezzo (and Squid) caching algorithms would be both on clients and servers, to keep copies semi local, on an as-needed basis. Multicast/MBONE/IGMP/Broadcast would be used to send to multiple machines at once, while reducing bandwidth. The Usenet news like delivery method could assist in the push vs. routing vs. caching stuff. EGAD! That's a tall order. However, this is the only way we're gonna get past the current bandwidth vs. distro situation on the 'net.