Our of curiosity, is there some reason why you'd want PostgreSQL specifically for this task?
There are a wide variety of embedded database toolkits that implement RDBMS functionality without the requirement of running a server product.
The eldest example would likely be the classic DBM file, with is descendents NDBM and GDBM, though these are fairly simplictic.
Your next step up would likely be BDB, which, like DBM, uses its own API, but provides a much more richer set of functionality. The concurrent access, transaction, and recovery options are exceptional.
And finally, if you're looking specifically for a SQL interface, the SQLite package provides a fairly complete SQL92 implementation in its toolkit, including automic commit and rollback.
It also has a command-line "monitor" much like the pgsql or mysql commands for administration.
I'm not necessarily dismissing the concept of in-process access to PostgreSQL tables, but given the choices available already available for embedded databases, and the unique requirements in writing one (e.g. locking without a controlling process), I don't quite what the motivation would be.
>So the option is, wait a few more years for
>Xrender to be completed, or check out stuff like
>directfb and berlin which claim to do what
>Xrender will do years from now.
Well, Berlin is at 0.2.2, and requires some sort of underlying graphic system - directfb, ggi, sdl or glut.
Both sdl and glut require an underlying graphics system as well, usually X. So those two are out if you want to do away with X.
Now on to GGI - at least the library (libGGI) is release quality. This is actually just a userspace graphics library that sits on top of an underlying system - X, svgalib, fbcon or glide.
We'll assume you want acceleration, freedom from X, and reasonable hardware support. So out go X, svgalib, and glibe. FBcon can be accelerated, as long as it used kggi, which is currently only available from CVS.
DirectFB also depends on FBcon, but it is does at least have what looks like a near final release.
So, our choices are:
Berlin on DirectFB on FBcon
Berlin on GGI on FBcon
DirectFB on FBcon
We may want to nix Berlin on GGI on FBcon, if only for the sake of having something which is SOMEWHAT near completion.
I'm not sure where you're getting this figure of "a few years" for Xrender to be completed, as Keith doesn't have timeline information on his website at all, but alpha compositing, anti-aliasing, and sub-pixel positioning are all written and included in the current XFree86 distribution. As the primary author states, the big pieces left are polygons and image transformation. Given that the initial discussions were at the 2000 USENIX Technical Conference, I'd say their progress is remarkable.
>Whats the best option? People want alpha
>channeling, scaling and OSX like effects,
>alternatives claim to be able to do it now, they
>port GTK and QT, and they claim to be compatible
>with X.
Xrender is already able to do alpha channeling and anti-aliased text, which are a major part of the deficiencies. Image transformation for things like scaling are forthcoming.
The alternatives, as discussed above, are not at a final release stage, rely on a linux only graphics layer (FBcon), have a narrower range of hardware supported (or supported well), and have a signifigantly different paradigm, thus complicating porting existing toolkits.
So is moving to a completely different toolkit, possibly with an unsolidified API, with the added headache of bringing all the drivers up to the same level of stability and performance as XFree86 already enjoys the "best option"? Or is the best option really updating toolkits to take advantage of the features available in XRender now, and planning on supporting the upcoming portions of the extension as they become available?
>If it's SCSI-1 that the tape drive requires, you
>might have a challenge getting a host adaptor
>capable of talking to it:-).
Actually, one of the beauties of SCSI is that it is fully forwards and backwoards compatible; i.e. to SCSI-1 devices should work on an Ultra320 bus, and vice versa.
Mind you, plugging an SCSI-1 device into the bus will limit it to single-ended narrow speeds, so you wouldn't ever want to mix it with new devices, but it will in fact work.
In fact the only external CD-ROM I had for years was an old 1x SCSI, and I've run on machines up to Ultra160.
>If my math is correct, that would take about 94 >HOURS to back up 100GB of data. And that's not
>including the time it takes for you to notice the
>tape is full, swap it, go to work/school, and
>sleep once in awhile. You're talking a week and a >half easy I'd say.
This has been my choice for low-cost backup solutions for a couple of years now.
The drives support three different flavours of media - 12GB, 20GB and 33GB, and come with IDE, SCSI, or Firewire interfaces. The IDE is cheapest, at $699, with the media costs being $80, $45, or $35 depending on the capacity.
Is it the absoulte top of the line as far as tapes go? No. But the cost can't be beat. And you get a reasonably fast (3MB/sec) drive with very nice reliability (take a look at the independent testing on their site; e.g. soaking a tape in hot coffee for a minute, rinsing it, drying it and reading the data off.)
They also recently merged with Exabyte, who will be positioning it as their new value solution. Hopefully the Exabyte name will expand the market enough to drive the prices down on these even further.
>Heck, as far as a I know (And I could be really
>wrong here) it's not even like it loads modules
>or something like that. It's just one massive
>700,000 line program.
You're really wrong. Aside from being a mail and groupware client, Evolution has also been one of the primary testbeds for Bonobo.
The actual program itself is just a shell that loads components to do all the dirty work:
>Putting everything in one file (binary or not)
>is a pretty stupid idea.
>I just upgraded my distro and was very happy
>that I could copy single per-app configfiles
>instead of the whole "registry" (that may not
>work). This happyness is about both the/etc
>files and the KDE config files.
Whew... Good thing Gconf has nothing to do with storing everying in a single file, and allows you to copy single per-app configuration instead of the whole "registry".
>I do find MySQL to be very limited and I find it
>frustrating that it just can't do what I want it to
>do (without a huge amount of ugly workarounds). But
>hey I have to use Access so I'm used to it. I will
>use PostGreSQL If there was a ODBC driver that
>would work on windows.
The *only* ODBC driver that is officially provided by the PostgreSQL team is for Windows. It's been available since at least 1998.
http://odbc.postgresql.org
They even provide an FAQ on using it with Access:
http://odbc.postgresql.org/faq.html
Hope this helps.
Let me preface my reply by saying I do in fact admin a fairly large MySQL installation, and it performs better than one would expect with its limitations. However, that is no reason to gloss over its deficiencies.
>>no proper transactions
>Yes it does! If you use certain table types
All of which are fairly new and account for only a small portion of the installations, meaning that they are no where near as well tested as the default table type (MyISAM).
Not to mention that none of them seem to have reliable benchmarks available. And to make matters worse, InnoDB has a big banner on their front page comparing themselves to a "leading database" but if you click on the link and read through the text, they state:
"Note that the tests were not run in exactly
the same way for the other database: the
comparison does not satisfy strict standards."
Publicizing the results of an admittedly flawed benchmark is unprofessional and, in my opinion, highly unethical.
>>no subselects
>This is a nice feature, but *not* necessary.
>Many times a proper JOIN can be used instead.
>Alternately you just use multiple SQLs.
>However, this is the one missing feature of
>MySQL that I want the most.
Agreed - it is possible to work around this issue. Though it does increase client code complexity.
>>no foreign keys
>You don't need foreign keys to maintain
>referential integrity. A proper GUI, among many
>other things, can enforce this anyway. It is a
>nice feature, but definitely not needed in a
>well designed system. Further they slow down
>performance and I have seen projects where they
>are not used because of this.
Yes it is possible to do integrity checks programmatically. However, this does nothing for manual administration, and requires implementation for every piece of code that might modify the database.
In most intstances I would consider not using foreign keys to be a poor decision, particularly after dealing with the mess created by a database where they decided to use programmatic checks for integrity.
As a side note, there is partial implementation of foreign keys in the InnoDB table handler, though it has some fundamental flaws to it. It drops constraints on an ALTER table, it allows you to drop referenced tables, and it lacks features such as CASCADE ON DELETE.
>>views
>These can be nice too, but I personally never
>use them. They are simply not required in any
>project I've ever seen. Actually I think views
>are confusing because they mask the real tables.
>I think this is a style issue more than anything
>else, YMMV.
Views make it possible for you to modify the schema of a database without having to touch your client code.
Views are also a wonderful way to present a simplified view to your programmers, rather than expecting them to know, e.g. how to do a full outer join on three or four tables with a sub-select thrown in just to make it a little more confusing.:)
>>How can this be a "mission critical" SQL
>>database?
>How about better performance [mysql.com].
As I have pointed out before, the benchmarks on mysql.com are for a single thread of access only. Which does not mimic the real world environment of the vast majority of database installations. Unless that is going to be your method, those benchmarks are essentially useless.
To their credit, representatives from MySQL AB have promised a more robust test in the future. But until that's out, I cannot put any stock in their published benchmarks.
>MyISAM tables are not good in an environment
>where you are doing a lot of long running
>updates and selects on the same tables.
Unfortunately MyISAM is still the best backend that has a widely deployed long-standing backend.
>The benchmarks on the www.mysql.com page are
>still single users, but we are working on an
>open source multi user tests that will show how
>the different table handlers MySQL provides
>works under heavy multi-user load.
I applaud the effort. That doesn't change the fact that the current benchmarks have major deficiencies.
>The single user benchmarks does however show the
>top speed for a database and the strength and
>weakness for each database, so they are still
>very useful on their own.
It shows the top speed for a database under conditions almost never found in production environments and hides the weaknesses of MySQL by doing so. They are very much NOT useful to most people.
>But the fact is, MySQL simply kills it in
>performance. Which is usually the number one
>issue with any kind of database. That isn't to
>say that PostgreSQL is bad. It just isn't as
>fast. That's all. Here's a benchmark [mysql.com]
>of MySQL versus other databases... including
>PostgreSQL.
Their posted benchmarks are for SINGLE threaded access. Unless you're using it for one of the very few niche applications that require this, the benchmarks are *useless*.
MySQL has a major problem with heavily concurrent access, particularly in instances where you are doing a lot of updates.
At work I'm migrating from MySQL to Postgres for precisely this reason. Performance has been going majorly downhill as the utilization has grown. And now its not uncommon to see as many as 50-60 threads stalled waiting for a table lock .
Yes, I'm aware that alternate table types exist for MySQL that implement finer grained locking. The problem is they are fairly new, and are in use on only a small portion of the MySQL installations out there; hence, they are nowhere near as well tested as Postgres.
Also, the benchmarks published on InnoDB are extremely poor. The comparison to Postgres suffers from the same single thread test only problem I mentioned and is far from comprehensive. The rest of it is even worse - the test for concurrency impact only shows results up to 50 threads for inserts, and shows a major dropoff in performance of selects between 50 and 100 rows. And he actually admits to poor methodology on the test against a commercial database.
>Actually this was largely due to the BSD-style >code which was in the kernel (Sys V was much
>easier to SMPize), but from the little I know
>about the FreeBSD kernel they didn't have nearly
>the same problems as HP-UX.
Why is it every source I've ever seen are under the impression that HP-UX is (and has been) based on the AT&T codebase (originally SVR2 iirc, currently SVR3.2 with SVR4 extentions)? I would think that the HP/UX instructors and engineers wouldn't lie to me about such things.
Take a look at gnome-db... It's still fairly immature, but it provides much of what you're asking for here.
The backend library (libgda) provides a nice abstraction layer for accessing disparate data sources, including LDAP, ODBC, and specific database drivers (Postgresql, Interbase, MySQL, Oracle, Primebase, Sybase, etc).
One really nice benefit is embedding libsqllite so that it can write out flatfiles that don't require the user to have an SQL server running.
The gnome-db package provides generic widgets for database access, as well as a front end program for managing data sources, building forms and reports, etc.
And finally, it is being bonoboized, so it can be used as a component in other applications. One example would be the gda support in Gnumeric, which allows you to import data into your spreadsheets.
Ooops, meant to qualify the lark comment with "in the near future".:)
However, much as I appreciate your optimism, I still feel its misguided, regardless of who you work for and what you do for them. Yes, HP has solved all these issues before, with about 15 years worth of development, complete control over the codebase, and licencing liberal amounts of code from third parties.
The difference in capability between Linux and HP/UX is gigantic, and many of the changes would require signifigant rearchitecture of low-level sections of the kernel (which would never make it into the current stable branch:) as well as a huge amount of rewriting to get around licenced parts of the code.
One major problem would be that people who have previously worked on the kernel might not be legally able to work on a lot of the reimplementation necessary due to NDAs, trade secrets, etc.
And given the scope of the changes that would be necessary, it would take years of incremental releases with huge bugtest/beta periods to get it working RIGHT.
So yes, a transition is possible, possibly even inevitable, but I seriously doubt you'll see Linux on hardware like the Superdome. Alphaserver SC, or Himilaya in less than 4-5 years. And even then, it will likely have to fork before it could happen, since all of the different operating systems are using highly variant clustering and scaling techniques.
Matt
Re:Comment applies only to identical hard drives.
on
USB 2.0 For Linux
·
· Score: 2
The basis for your claim being anecdotal, save for some unnamed report doesn't give me much faith in your claims. For that matter, the rest of your post doesn't give me much faith either.
I can't claim with authority that some drives don't have a SCSI layer over an IDE one. However, regardless of that, it does not mean that "in those cases, SCSI must be slower".
For example, one of the major advantages of SCSI over IDE is tagged command queueing. In an IDE bus, you can only ever have one command pending at any given time, whereas SCSI allows typically for at least 64 commands.
One advantage of this is that it allows for reads and writes to be reordered for more efficiency. And this speed benefit would be gained even if it was done in a layer above the drives native interface. If you want an analogy, look at the improvements in performance in different kernel versions - hardware is the same, but it is being accessed and utilized more intelligently.
And no, the transfer speed of ATA/100 is not a lie. The bus is perfectly capable of transfering data at that speed, regardless of the speed of the devices. And sustained speed is not the only factor here; there are performance gains to be had even if you are just bursting traffic at that speed.
That does, however, bring up yet another disadvantage of the IDE bus - multiple devices. Aside from only being able to handle two per bus, if you use even that many (!) you seriously degrade performance since only one device can "speak" at a given time. An example of where this could be bad is if you're copying from your hard drive to your CD-RW.
Your claims that single user systems don't claim benefit from the multi-tasking features of SCSI are at best naive and at worst stupid (and more likely is a combination of both). Modern operating systems (i.e. anything post DOS when talking about PCs) never have just one process active at a time under normal use, even when the user is only running a single application. (E.g. Windows is always running Explorer (no, not the browser, the desktop shell) in addition to the foreground application).
And increasingly, users are running multiple applications at once - an mp3 or cd player in the background, a copy of ICQ/AIM/whatever in their taskbar, etc, etc, etc).
If you'd actually run some performance testing instead of relying on a single article and your owen prejudices, you might learn that even under very mild concurency (i.e. not "multiple processes competing heavily for hard drive access") SCSI yeilds a signifigant performance increase (particularly since the cost of high speed CPUs and memory have dropped so drastically, thus making the hard drive all the more of a performance bottleneck.)
Yeah, but specififying speed with a pure MHz rating is misleading since it doesn't take into account how wide the bus is or how many bits are sent per clock.
They haven't a larks chance in hell of making that sort of transition. The PA-RISC port of Linux is best classified as immature, and is highly incomplete (i.e. it doesn't support the full gamut of bus types found in HP 9000s, such as GSC or HP-PB; there's absolutely no support for the high end machines like the V-class or Superdome, etc).
I can't even begin to imagine home much work they'd have to do in order to make Linux run at all, much less reliably and quick, on the Superdome (each node can be a 64-way PA-8600, 128GB memory, up to 192 PCI slots, all hot swappable, with hardware/software parititioning).
And HP/UX is only ONE of the operating systems in question here - you've also got OpenVMS, Tru64, Nonstop-UX, and MPE/IX. All of which have very large legacy installtions, run on hardware that Linux can't yet, and have capabilities that are well beyond what Linux can do.
I'm a huge fan of Linux, and have been using it since around '94, but have also used and supported HP/UX, Solaris, Openserver, Unixware, Nonstop Clusters, BSDI, OpenBSD and FreeBSD. (With some exposure to Tru64, MPE/IX, OpenVMS and Vax/VMS).
Unfortunately migration is a per customer, per application issue. Some might be simple (i.e. moving a webserver or a database), but there is a HUGE amount of custom code or niche applications running out there that aren't nearly that simple, particularly when talking about the non UX platforms (e.g. MPE/IX) where you don't even have the benefit of a mostly similar API to ease porting. And even porting to and from Unixes is no piece of cake, particularly when they're based on different branches of the great Unix tree (e.g. HP/UX is heavily modified SVR3, Tru64 is branched off OSF/1, etc).
So getting back to the original point - they couldn't really drop anything without screwing their customers. So its much more likely that they'd move what they could into maintainance (i.e. no updates save bugfixes.)
>Actually, SCSI is slower than the current IDE
>unless used in a multiuser system.
Care to substantiate this? SCSI is up to 320MB/sec compared to ATA at 100MB/sec (or 150MB/sec if you count the yet to appear on market SATA).
And beyond that, the available devices vary wildly - the fastest IDE drives I've seen are 7200rpm w/ 2mb cache, whereas I can get myself 15000rpm w/ 8mb cache in Ultra/160.
>Uh, no. PC800 transfers at 1600 MB/sec. Its
>clocked at 400MHz base * 2x DDR * 2 bytes per
>transfer = 1600 MB/sec. And yes, its honest to
>report DDR busses as being double the megahertz
>because they mostly behave that way. Thus,
>PC-2100 really is DDR-266.
Juse one note - 133MHz * 2x DDR * 8 bytes per transfer = 2128 MB/sec; Likewise 100MHz * 2x DDR * 8 bytes per transfer = 1600 MB/sec, hence the PC-1600 and PC-2100 nomenclature.
Which article were you reading? Look at the last two paragraphs:
"The Dvorak keyboard sounds very good. However, a keyboard need to do more than just "sound" good, and unfortunately, Dvorak has failed to prove itself superior to QWERTY... It's not surprising, then, that Dvorak has failed to take hold. No one wants to take the time and trouble to learn a new keyboard, especially if it isn't convincingly superior to the old."
>I am not a GNOME developer, and there is a great
>deal that I do not understand about what is going
>on. However, I still haven't seen any
>applications that use ORBIT, and I don't see
>CORBA or Java having a substantial impact on
>Linux or GNOME applications.
If you've used Gnome at all in the past couple years, you've seen programs that utilize ORBit running on your desktop (e.g. the control center or panel applets).
For a quick listing, you can just cd to/usr/bin and do something like:
Slashdot Mirror
>the mind boggles... do you really believe that
l es /sles_s390/
>Mandrake or RedHat will install on the s/390?
>
>Get your shit straight.
Before insulting other people, you might want to "get your shit straight" yourself.
Redhat Linux for the S/390 was released December 2001.
http://www.redhat.com/software/linux/s390/
SuSE for the S/390 was released October 2000.
http://www.suse.com/us/products/suse_business/s
TurboLinux for the S/390 was released January 2001.
http://www.turbolinux.com/products/s390/
Debian has a beta distribution for the S/390
http://www.debian.org/ports/s390/
Matt
Our of curiosity, is there some reason why you'd want PostgreSQL specifically for this task?
There are a wide variety of embedded database toolkits that implement RDBMS functionality without the requirement of running a server product.
The eldest example would likely be the classic DBM file, with is descendents NDBM and GDBM, though these are fairly simplictic.
Your next step up would likely be BDB, which, like DBM, uses its own API, but provides a much more richer set of functionality. The concurrent access, transaction, and recovery options are exceptional.
And finally, if you're looking specifically for a SQL interface, the SQLite package provides a fairly complete SQL92 implementation in its toolkit, including automic commit and rollback.
It also has a command-line "monitor" much like the pgsql or mysql commands for administration.
I'm not necessarily dismissing the concept of in-process access to PostgreSQL tables, but given the choices available already available for embedded databases, and the unique requirements in writing one (e.g. locking without a controlling process), I don't quite what the motivation would be.
>So the option is, wait a few more years for
>Xrender to be completed, or check out stuff like
>directfb and berlin which claim to do what
>Xrender will do years from now.
Well, Berlin is at 0.2.2, and requires some sort of underlying graphic system - directfb, ggi, sdl or glut.
Both sdl and glut require an underlying graphics system as well, usually X. So those two are out if you want to do away with X.
Now on to GGI - at least the library (libGGI) is release quality. This is actually just a userspace graphics library that sits on top of an underlying system - X, svgalib, fbcon or glide.
We'll assume you want acceleration, freedom from X, and reasonable hardware support. So out go X, svgalib, and glibe. FBcon can be accelerated, as long as it used kggi, which is currently only available from CVS.
DirectFB also depends on FBcon, but it is does at least have what looks like a near final release.
So, our choices are:
Berlin on DirectFB on FBcon
Berlin on GGI on FBcon
DirectFB on FBcon
We may want to nix Berlin on GGI on FBcon, if only for the sake of having something which is SOMEWHAT near completion.
I'm not sure where you're getting this figure of "a few years" for Xrender to be completed, as Keith doesn't have timeline information on his website at all, but alpha compositing, anti-aliasing, and sub-pixel positioning are all written and included in the current XFree86 distribution. As the primary author states, the big pieces left are polygons and image transformation. Given that the initial discussions were at the 2000 USENIX Technical Conference, I'd say their progress is remarkable.
>Whats the best option? People want alpha
>channeling, scaling and OSX like effects,
>alternatives claim to be able to do it now, they
>port GTK and QT, and they claim to be compatible
>with X.
Xrender is already able to do alpha channeling and anti-aliased text, which are a major part of the deficiencies. Image transformation for things like scaling are forthcoming.
The alternatives, as discussed above, are not at a final release stage, rely on a linux only graphics layer (FBcon), have a narrower range of hardware supported (or supported well), and have a signifigantly different paradigm, thus complicating porting existing toolkits.
So is moving to a completely different toolkit, possibly with an unsolidified API, with the added headache of bringing all the drivers up to the same level of stability and performance as XFree86 already enjoys the "best option"? Or is the best option really updating toolkits to take advantage of the features available in XRender now, and planning on supporting the upcoming portions of the extension as they become available?
Matt
>If it's SCSI-1 that the tape drive requires, you :-).
>might have a challenge getting a host adaptor
>capable of talking to it
Actually, one of the beauties of SCSI is that it is fully forwards and backwoards compatible; i.e. to SCSI-1 devices should work on an Ultra320 bus, and vice versa.
Mind you, plugging an SCSI-1 device into the bus will limit it to single-ended narrow speeds, so you wouldn't ever want to mix it with new devices, but it will in fact work.
In fact the only external CD-ROM I had for years was an old 1x SCSI, and I've run on machines up to Ultra160.
Matt
>If my math is correct, that would take about 94 >HOURS to back up 100GB of data. And that's not
:)
>including the time it takes for you to notice the
>tape is full, swap it, go to work/school, and
>sleep once in awhile. You're talking a week and a >half easy I'd say.
Not quite, 3MB/sec = 180MB/min = 18000MB/hour
100GB = 102400MB
102400 / 18000 = ~5h41m20s
Matt
This has been my choice for low-cost backup solutions for a couple of years now.
The drives support three different flavours of media - 12GB, 20GB and 33GB, and come with IDE, SCSI, or Firewire interfaces. The IDE is cheapest, at $699, with the media costs being $80, $45, or $35 depending on the capacity.
Is it the absoulte top of the line as far as tapes go? No. But the cost can't be beat. And you get a reasonably fast (3MB/sec) drive with very nice reliability (take a look at the independent testing on their site; e.g. soaking a tape in hot coffee for a minute, rinsing it, drying it and reading the data off.)
They also recently merged with Exabyte, who will be positioning it as their new value solution. Hopefully the Exabyte name will expand the market enough to drive the prices down on these even further.
Matt
>Heck, as far as a I know (And I could be really
>wrong here) it's not even like it loads modules
>or something like that. It's just one massive
>700,000 line program.
You're really wrong. Aside from being a mail and groupware client, Evolution has also been one of the primary testbeds for Bonobo.
The actual program itself is just a shell that loads components to do all the dirty work:
/usr/bin/evolution
/usr/bin/evolution-addressbook
/usr/bin/evolution-addressbook-clean
/usr/bin/evolution-addressbook-export
/usr/bin/evolution-addressbook-import
/usr/bin/evolution-alarm-notify
/usr/bin/evolution-calendar
/usr/bin/evolution-calendar-importer
/usr/bin/evolution-elm-importer
/usr/bin/evolution-executive-summary
/usr/bin/evolution-gnomecard-importer
/usr/bin/evolution-ldif-importer
/usr/bin/evolution-mail
/usr/bin/evolution-move-tasks
/usr/bin/evolution-netscape-importer
/usr/bin/evolution-pine-importer
/usr/bin/evolution-vcard-importer
>Putting everything in one file (binary or not) /etc
.gconf]$ find . -type d -maxdepth 2
.gconf]$ find . -type f | grep galeon
>is a pretty stupid idea.
>I just upgraded my distro and was very happy
>that I could copy single per-app configfiles
>instead of the whole "registry" (that may not
>work). This happyness is about both the
>files and the KDE config files.
Whew... Good thing Gconf has nothing to do with storing everying in a single file, and allows you to copy single per-app configuration instead of the whole "registry".
[galt@damballah
.
./%gconf-xml-backend.lock
./apps
./apps/nautilus
./apps/eazel-trilobite
./apps/eog
./apps/gda
./apps/galeon
[galt@damballah
./apps/galeon/%gconf.xml
./apps/galeon/State/%gconf.xml
./apps/galeon/State/prefs_dialog/%gconf.xml
./apps/galeon/Advanced/%gconf.xml
./apps/galeon/Advanced/Crash/%gconf.xml
./apps/galeon/Advanced/Filtering/%gconf.xml
./apps/galeon/Advanced/Network/%gconf.xml
./apps/galeon/Rendering/%gconf.xml
./apps/galeon/Rendering/FontsColors/%gconf.xml
./apps/galeon/Rendering/Language/%gconf.xml
./apps/galeon/Browsing/%gconf.xml
./apps/galeon/Browsing/Find/%gconf.xml
./apps/galeon/Browsing/General/%gconf.xml
./apps/galeon/Browsing/History/%gconf.xml
./apps/galeon/UI/%gconf.xml
./apps/galeon/UI/Tabs/%gconf.xml
./apps/galeon/UI/Windows/%gconf.xml
./apps/galeon/UI/Toolbar/%gconf.xml
>1.) You can't set what font to use in html email
>messages
If you go to the control center there is an applet for configuring gtkhtml. Set the font there.
(I'd really like for there to be an Evolution menu option for overriding the default here, or a shortcut to the control center at the very least.)
Matt
>I do find MySQL to be very limited and I find it
>frustrating that it just can't do what I want it to
>do (without a huge amount of ugly workarounds). But
>hey I have to use Access so I'm used to it. I will
>use PostGreSQL If there was a ODBC driver that
>would work on windows.
The *only* ODBC driver that is officially provided by the PostgreSQL team is for Windows. It's been available since at least 1998.
http://odbc.postgresql.org
They even provide an FAQ on using it with Access:
http://odbc.postgresql.org/faq.html
Hope this helps.
Matt
Let me preface my reply by saying I do in fact admin a fairly large MySQL installation, and it performs better than one would expect with its limitations. However, that is no reason to gloss over its deficiencies.
:)
>>no proper transactions
>Yes it does! If you use certain table types
All of which are fairly new and account for only a small portion of the installations, meaning that they are no where near as well tested as the default table type (MyISAM).
Not to mention that none of them seem to have reliable benchmarks available. And to make matters worse, InnoDB has a big banner on their front page comparing themselves to a "leading database" but if you click on the link and read through the text, they state:
"Note that the tests were not run in exactly
the same way for the other database: the
comparison does not satisfy strict standards."
Publicizing the results of an admittedly flawed benchmark is unprofessional and, in my opinion, highly unethical.
>>no subselects
>This is a nice feature, but *not* necessary.
>Many times a proper JOIN can be used instead.
>Alternately you just use multiple SQLs.
>However, this is the one missing feature of
>MySQL that I want the most.
Agreed - it is possible to work around this issue. Though it does increase client code complexity.
>>no foreign keys
>You don't need foreign keys to maintain
>referential integrity. A proper GUI, among many
>other things, can enforce this anyway. It is a
>nice feature, but definitely not needed in a
>well designed system. Further they slow down
>performance and I have seen projects where they
>are not used because of this.
Yes it is possible to do integrity checks programmatically. However, this does nothing for manual administration, and requires implementation for every piece of code that might modify the database.
In most intstances I would consider not using foreign keys to be a poor decision, particularly after dealing with the mess created by a database where they decided to use programmatic checks for integrity.
As a side note, there is partial implementation of foreign keys in the InnoDB table handler, though it has some fundamental flaws to it. It drops constraints on an ALTER table, it allows you to drop referenced tables, and it lacks features such as CASCADE ON DELETE.
>>views
>These can be nice too, but I personally never
>use them. They are simply not required in any
>project I've ever seen. Actually I think views
>are confusing because they mask the real tables.
>I think this is a style issue more than anything
>else, YMMV.
Views make it possible for you to modify the schema of a database without having to touch your client code.
Views are also a wonderful way to present a simplified view to your programmers, rather than expecting them to know, e.g. how to do a full outer join on three or four tables with a sub-select thrown in just to make it a little more confusing.
>>How can this be a "mission critical" SQL
>>database?
>How about better performance [mysql.com].
As I have pointed out before, the benchmarks on mysql.com are for a single thread of access only. Which does not mimic the real world environment of the vast majority of database installations. Unless that is going to be your method, those benchmarks are essentially useless.
To their credit, representatives from MySQL AB have promised a more robust test in the future. But until that's out, I cannot put any stock in their published benchmarks.
>MyISAM tables are not good in an environment
>where you are doing a lot of long running
>updates and selects on the same tables.
Unfortunately MyISAM is still the best backend that has a widely deployed long-standing backend.
>The benchmarks on the www.mysql.com page are
>still single users, but we are working on an
>open source multi user tests that will show how
>the different table handlers MySQL provides
>works under heavy multi-user load.
I applaud the effort. That doesn't change the fact that the current benchmarks have major deficiencies.
>The single user benchmarks does however show the
>top speed for a database and the strength and
>weakness for each database, so they are still
>very useful on their own.
It shows the top speed for a database under conditions almost never found in production environments and hides the weaknesses of MySQL by doing so. They are very much NOT useful to most people.
Matt
>But the fact is, MySQL simply kills it in
>performance. Which is usually the number one
>issue with any kind of database. That isn't to
>say that PostgreSQL is bad. It just isn't as
>fast. That's all. Here's a benchmark [mysql.com]
>of MySQL versus other databases... including
>PostgreSQL.
Their posted benchmarks are for SINGLE threaded access. Unless you're using it for one of the very few niche applications that require this, the benchmarks are *useless*.
MySQL has a major problem with heavily concurrent access, particularly in instances where you are doing a lot of updates.
At work I'm migrating from MySQL to Postgres for precisely this reason. Performance has been going majorly downhill as the utilization has grown. And now its not uncommon to see as many as 50-60 threads stalled waiting for a table lock .
Yes, I'm aware that alternate table types exist for MySQL that implement finer grained locking. The problem is they are fairly new, and are in use on only a small portion of the MySQL installations out there; hence, they are nowhere near as well tested as Postgres.
Also, the benchmarks published on InnoDB are extremely poor. The comparison to Postgres suffers from the same single thread test only problem I mentioned and is far from comprehensive. The rest of it is even worse - the test for concurrency impact only shows results up to 50 threads for inserts, and shows a major dropoff in performance of selects between 50 and 100 rows. And he actually admits to poor methodology on the test against a commercial database.
Matt
>Actually this was largely due to the BSD-style >code which was in the kernel (Sys V was much
>easier to SMPize), but from the little I know
>about the FreeBSD kernel they didn't have nearly
>the same problems as HP-UX.
Why is it every source I've ever seen are under the impression that HP-UX is (and has been) based on the AT&T codebase (originally SVR2 iirc, currently SVR3.2 with SVR4 extentions)? I would think that the HP/UX instructors and engineers wouldn't lie to me about such things.
Why not do a readable Intercal contest instead?
Take a look at gnome-db... It's still fairly immature, but it provides much of what you're asking for here.
The backend library (libgda) provides a nice abstraction layer for accessing disparate data sources, including LDAP, ODBC, and specific database drivers (Postgresql, Interbase, MySQL, Oracle, Primebase, Sybase, etc).
One really nice benefit is embedding libsqllite so that it can write out flatfiles that don't require the user to have an SQL server running.
The gnome-db package provides generic widgets for database access, as well as a front end program for managing data sources, building forms and reports, etc.
And finally, it is being bonoboized, so it can be used as a component in other applications. One example would be the gda support in Gnumeric, which allows you to import data into your spreadsheets.
Matt
Ooops, meant to qualify the lark comment with "in the near future". :)
:) as well as a huge amount of rewriting to get around licenced parts of the code.
However, much as I appreciate your optimism, I still feel its misguided, regardless of who you work for and what you do for them. Yes, HP has solved all these issues before, with about 15 years worth of development, complete control over the codebase, and licencing liberal amounts of code from third parties.
The difference in capability between Linux and HP/UX is gigantic, and many of the changes would require signifigant rearchitecture of low-level sections of the kernel (which would never make it into the current stable branch
One major problem would be that people who have previously worked on the kernel might not be legally able to work on a lot of the reimplementation necessary due to NDAs, trade secrets, etc.
And given the scope of the changes that would be necessary, it would take years of incremental releases with huge bugtest/beta periods to get it working RIGHT.
So yes, a transition is possible, possibly even inevitable, but I seriously doubt you'll see Linux on hardware like the Superdome. Alphaserver SC, or Himilaya in less than 4-5 years. And even then, it will likely have to fork before it could happen, since all of the different operating systems are using highly variant clustering and scaling techniques.
Matt
The basis for your claim being anecdotal, save for some unnamed report doesn't give me much faith in your claims. For that matter, the rest of your post doesn't give me much faith either.
I can't claim with authority that some drives don't have a SCSI layer over an IDE one. However, regardless of that, it does not mean that "in those cases, SCSI must be slower".
For example, one of the major advantages of SCSI over IDE is tagged command queueing. In an IDE bus, you can only ever have one command pending at any given time, whereas SCSI allows typically for at least 64 commands.
One advantage of this is that it allows for reads and writes to be reordered for more efficiency. And this speed benefit would be gained even if it was done in a layer above the drives native interface. If you want an analogy, look at the improvements in performance in different kernel versions - hardware is the same, but it is being accessed and utilized more intelligently.
And no, the transfer speed of ATA/100 is not a lie. The bus is perfectly capable of transfering data at that speed, regardless of the speed of the devices. And sustained speed is not the only factor here; there are performance gains to be had even if you are just bursting traffic at that speed.
That does, however, bring up yet another disadvantage of the IDE bus - multiple devices. Aside from only being able to handle two per bus, if you use even that many (!) you seriously degrade performance since only one device can "speak" at a given time. An example of where this could be bad is if you're copying from your hard drive to your CD-RW.
Your claims that single user systems don't claim benefit from the multi-tasking features of SCSI are at best naive and at worst stupid (and more likely is a combination of both). Modern operating systems (i.e. anything post DOS when talking about PCs) never have just one process active at a time under normal use, even when the user is only running a single application. (E.g. Windows is always running Explorer (no, not the browser, the desktop shell) in addition to the foreground application).
And increasingly, users are running multiple applications at once - an mp3 or cd player in the background, a copy of ICQ/AIM/whatever in their taskbar, etc, etc, etc).
If you'd actually run some performance testing instead of relying on a single article and your owen prejudices, you might learn that even under very mild concurency (i.e. not "multiple processes competing heavily for hard drive access") SCSI yeilds a signifigant performance increase (particularly since the cost of high speed CPUs and memory have dropped so drastically, thus making the hard drive all the more of a performance bottleneck.)
Matt
Yeah, but specififying speed with a pure MHz rating is misleading since it doesn't take into account how wide the bus is or how many bits are sent per clock.
They haven't a larks chance in hell of making that sort of transition. The PA-RISC port of Linux is best classified as immature, and is highly incomplete (i.e. it doesn't support the full gamut of bus types found in HP 9000s, such as GSC or HP-PB; there's absolutely no support for the high end machines like the V-class or Superdome, etc).
I can't even begin to imagine home much work they'd have to do in order to make Linux run at all, much less reliably and quick, on the Superdome (each node can be a 64-way PA-8600, 128GB memory, up to 192 PCI slots, all hot swappable, with hardware/software parititioning).
And HP/UX is only ONE of the operating systems in question here - you've also got OpenVMS, Tru64, Nonstop-UX, and MPE/IX. All of which have very large legacy installtions, run on hardware that Linux can't yet, and have capabilities that are well beyond what Linux can do.
I'm a huge fan of Linux, and have been using it since around '94, but have also used and supported HP/UX, Solaris, Openserver, Unixware, Nonstop Clusters, BSDI, OpenBSD and FreeBSD. (With some exposure to Tru64, MPE/IX, OpenVMS and Vax/VMS).
Unfortunately migration is a per customer, per application issue. Some might be simple (i.e. moving a webserver or a database), but there is a HUGE amount of custom code or niche applications running out there that aren't nearly that simple, particularly when talking about the non UX platforms (e.g. MPE/IX) where you don't even have the benefit of a mostly similar API to ease porting. And even porting to and from Unixes is no piece of cake, particularly when they're based on different branches of the great Unix tree (e.g. HP/UX is heavily modified SVR3, Tru64 is branched off OSF/1, etc).
So getting back to the original point - they couldn't really drop anything without screwing their customers. So its much more likely that they'd move what they could into maintainance (i.e. no updates save bugfixes.)
Matt
>Actually, SCSI is slower than the current IDE
>unless used in a multiuser system.
Care to substantiate this? SCSI is up to 320MB/sec compared to ATA at 100MB/sec (or 150MB/sec if you count the yet to appear on market SATA).
And beyond that, the available devices vary wildly - the fastest IDE drives I've seen are 7200rpm w/ 2mb cache, whereas I can get myself 15000rpm w/ 8mb cache in Ultra/160.
Matt
>Uh, no. PC800 transfers at 1600 MB/sec. Its
>clocked at 400MHz base * 2x DDR * 2 bytes per
>transfer = 1600 MB/sec. And yes, its honest to
>report DDR busses as being double the megahertz
>because they mostly behave that way. Thus,
>PC-2100 really is DDR-266.
Juse one note - 133MHz * 2x DDR * 8 bytes per transfer = 2128 MB/sec; Likewise 100MHz * 2x DDR * 8 bytes per transfer = 1600 MB/sec, hence the PC-1600 and PC-2100 nomenclature.
:)
Matt
Which article were you reading? Look at the last two paragraphs:
"The Dvorak keyboard sounds very good. However, a keyboard need to do more than just "sound" good, and unfortunately, Dvorak has failed to prove itself superior to QWERTY... It's not surprising, then, that Dvorak has failed to take hold. No one wants to take the time and trouble to learn a new keyboard, especially if it isn't convincingly superior to the old."
>I am not a GNOME developer, and there is a great
/usr/bin and do something like:
>deal that I do not understand about what is going
>on. However, I still haven't seen any
>applications that use ORBIT, and I don't see
>CORBA or Java having a substantial impact on
>Linux or GNOME applications.
If you've used Gnome at all in the past couple years, you've seen programs that utilize ORBit running on your desktop (e.g. the control center or panel applets).
For a quick listing, you can just cd to
$ for I in *; do if (ldd $I 2>/dev/null | grep -i orbit >/dev/null); then echo $I; fi; done
address-conduit-capplet
another_clock_applet
asclock_applet
background-properties-capplet
backup-conduit-control-applet
battery_applet
bonobo-application-ps
bonobo-application-x-mines
bonobo-audio-ulaw
bonobo-echo
bonobo-moniker-gunzip
bonobo-moniker-http
bonobo-sample-canvas-item
bonobo-sample-controls
bonobo-sample-hello
bonobo-sample-paintbonobo-selector
bonobo-text-plain
bug-buddy
calendar-conduit-control-applet
calendar-pilot-sync
cdplayer_applet
charpick_applet
clockmail_applet
cpumemusage_applet
default-application-properties-capplet
deskguide_applet
diskusage_applet
drivemount_applet
eazel-proxy
eazel-proxy-util
ebrowser
echo-client
email-conduit-control-applet
eog
eog-image-viewer
evolution
evolution-addressbook
evolution-alarm-notify
evolution-calendar
evolution-elm-importer
evolution-executive-summary
evolution-gnomecard-importer
evolution-mail
evolution-netscape-importer
evolution-pine-importer
evolution-vcard-importer
expense-conduit-control-applet
fifteen_applet
file-conduit-control-applet
file-types-capplet
gaim
gaim_applet
galeon-bin
gconfd-1
gconftool
gconftool-1
gda-default-srv
gda-mysql-srv
gda-postgres-srv
gda-run
gda-test
gdict
gedit
geyes_applet
gkb_applet
gmc
gmc-client
gnapster
gnomecal
gnomecard
gnomecc
gnome-gtkhtml-editor
gnome-help-browser
gnome-help-caller
gnome-hint-properties-capplet
gnome-iconedit
gnomeicu
gnomeicu-client
gnome-name-service
gnome-panel-add-launcher
gnome-panel-properties-capplet
gnome-terminal
gnome-vfs-slave
gnomexmms
gnotes_applet
goad-browser
gpilotdgpilotd-client
gpilotdcm-client
gpilotd-control-applet
gpilot-install-file
grdb-capplet
gshell
gtcd
gtik2_applet
gtkhtml-properties-capplet
gweather
hyperbola
ior-decode
jbc_applet
keyboard-properties
life_applet
load-gnomecard-addressbook
load-pine-addressbook
loadshlib
medusa-idled
medusa-indexd
medusa-searchd
memo_file_capplet
metatheme_selector_capplet
mini_commander_applet
mixer_applet
modemlights_applet
moniker-test
mouse-properties-capplet
msearch
multiload_applet
name-client
nautilus
nautilus-adapter
nautilus-content-loser
nautilus-hardware-view
nautilus-history-view
nautilus-image-view
nautilus-launcher-applet
nautilus-mime-type-capplet
nautilus-music-view
nautilus-news
nautilus-notes
nautilus-preferences-applet
nautilus-sample-content-view
nautilus-sidebar-loser
nautilus-text-view
nautilus-throbber
new-object
oaf-client
oafd
odometer_applet
old-name-server
orbit-event-server
orbit-name-server
panel
pilot-applet
quicklaunch_applet
rdf-summary
rp3
sample-container
sample-control-container
sawfish-capplet
screensaver-properties-capplet
screenshooter_applet
session-properties-capplet
slash_applet
sound-monitor_applet
sound-properties
stripchart-applet
tasklist_applet
test-conduit-control-applet
test-servicetheme-selector-capplet
tickastat_applet
ui-properties
You could always do ORDER BY and DISTINCT *on* a view, just not as part of one.
That limitation is removed in the 7.1 release.
Matt