>BUT: Eazel, HelixCode and Sun have put themselves
>into keypositions by developing the
>standard-gnome-filemanager, the
>standard-gnome-office and the
>standard-gnome-pim.
Yes, Eazel gave us a new filemanager.
Does this prevent us from using other ones? Of course not, its method of integration is through the standard drag-and-drop and embedding mechanisms.
Does this prevent us from forking the code in the future if need be? Of course not, its GPL.
Yes, Sun is giving us a free office suite.
Does this prevent us from using other ones? Of course not.
Does this prevent us from forking the code in the future if need be? Of course not.
Does this prevent us from using portions of their office suite with other components? Of course not, as they are publshing the details of their file formats and using the standard methods for integration under Gnome.
Yes, HelixCode is giving us a groupware product.
But they were doing that before they even formed the company, and the people who were working on it still are. They're just being paid.
Does this prevent us from using other products? No, of course.
Does this prevent us from forking the code if necessary? No, of course not, it's GPL.
Does this prevent us from using portions of their groupware with other products? No, of course not. They are using standard libraries, drag-and-drop, embedding, protocals, etc.
And regardless of all that, the FRAMEWORK of Gnome is in the hands of developers from all of these companies, as well as independent developers and those working at Redhat.
We are not in danger of vendor lock-in, we are not in danger of vendor control, we are not in danger period.
>Anyone looked at the mailinglists of gnumeric and
>abiword? -- These projects are obviously dying
>already;(
I count 24 new entries in the ChangeLog for gnumeric this month, and 92 new commits to Abiword. How is this dying?
Oh, and BTW, Gnumeric was one of the first projects Helix backed. I don't see how their rise to a key position can endanger one of their own products.
And beyond even that, the details of the Gnome office release are not out yet. For all we know, StarCalc may not even be part of the upcoming OpenOffice release.
>By occupying the core-positions these companies
>are obviously destroying the developer
>infrastructure that made sure that even
>independent developers can influence the
>development of such projects significantly.
Hint, the bulk of the independent developers are still there. A lot of them are just being paid for it now.
Hint, look at the membership of the Gnome Foundation. It's still largely independent developers.
>MySQL, starting with 3.23.15, has transaction
>support. Given, 3.23 is a beta series, but it's
>been in beta for quite a while, it should be
>fairly stable. Transaction support has been in
>the 3.23 series since this May.
Yes, 3.23 has been in alpha/beta for a while, but as you point out, transaction support has only been there since 3.23.15, or a mere 8 experimental releases.
Yes, its been in there since May, but do you think that three months is nearly enough time to integrate an entire new table type, add support for transactions, and properly test it? And this while other experimental features are being added?
And finally, I would have issue with the scalability and reliability of a table type (BDB) in a multi-user environment when it was designed primarily for embedded single-user databases.
>As they haven't released any information about
>the test or even the results one can just assume
>that they have done a test that doesn't have
>anything to do with the real world:(
"In the AS3AP tests... Postgres peaked at 1127.8 transactions per second with five users, and still processed at a steady rate of 1070.4 with 100 users... MySQL reached a peak of 803.48 with two users, but its performance fell precipitously under the stress of additional users to a rate of 117.87 transactions per second with 100 users."
The test is standard, so the definition of what it entails is easy to come by and they provided what the results were. So your above complaint really has no substance to it.
However, I do agree there should have been more information - namely the software configuration.
>PostgreSQL has of course also a lot of weak
>areas, like slow connection, slow insert, slow
>create/drop tables, running long multiple
>transactions where you get a conflict
>at the end (in this page/row locking is better)
Yes, Postgres is slower to connect, though not grotesqely so.
Yes, Postgres is slower to do inserts, but updates and inserts don't block. So though MySQL may be impressive if you bench insert speed without considering its impact on overall performance, in real world applications you'll see very different behaviour.
I'm not sure exactly what you're refering to when you mention "conflicts" at the end of transaction blocks. This is one area where I find MySQL falls short, since a) it has no transactions and b) it doesn't have the framework for transactions (e.g. multi-version concurency control, etc).
>We here at MySQL has always tried to design very
>fair test that no one can misinterpret or lie
>about.
Unfortunately the benchmarks MySQL uses are all single client load, which is completely meaningless in a production environment and covers up the weakest parts of MySQL (e.g. all selects stalling while an insert or update is happening).
>It's a shame that Great Bridge funds a test that
>is solely done to confuse users instead of
>telling the truth; PostgreSQL is good in some
>areas, and bad in others, just like all other
>databases.
I fail to see where they state what you are claiming they did. They merely point that a) on the AS3AP test, using the current production release of MySQL with its ODBC implementation, the performance was lackluster, and that MySQL currently lacks the feature set to run TPC-C.
>The article doesn't mention anything about this >or even with which ODBC driver they used the
>different databases.
As opposed to the benchmark on the MySQL website, where they make no mention of how the databases were compiled, what limits were set, what version of Perl was used, what version of DBI was used, what version of the DBD drivers were used, what hardware platform it was run on, what operating system it was run on, etc, etc.
And futhermore they are benchtesting an alpha product against a faily old stable release (6.5 being current over a year before these benchmarks were posted, with a half dozen released in the meantime).
>I also don't agree with the argument that they
>are not testing MySQL 3.23 as this is still
>marked 'beta'. We have here at MySQL a completely
>different release schedule on our versions...
>Compared to our release schedule, PostgreSQL 7.0 >would be called alpha.
Nice way to imply that the Postgres team doesn't properly beta test. Fact of the matter is that the 7.0 release spend many many months in its alpha/beta/gamma cycle.
There were a couple bugs that slipped through the cracks, but the subsequent releases resolved all known issues, and came very promptly (15 days between 7.0 and 7.0.1, and then 3 days between 7.0.1 and 7.0.2).
As for the development cycles being different, I agree. Though I would go the other direction. The goals of the 7.0 development series were much less ambitious than those of the 3.23 series of MySQL has; e.g. replication, two new backends, transaction support, a real locking mechanism, etc. Not to mention that they stopped adding new features to 7.0 about 6 months ago, whereas MySQL is continuing to add features (and change existing features) of 3.23.
>The net result is that the posted test is about
>as wrong as you can do a test, the important
>thing is just to get the people that reads that
>page to understand that.
Funny, I would say the epitomy of both misleading and incorrect testing would be the sql-bench suite run by MySQL.
>I had heard that Postgres was slow as hell and a
>serious resource hog, but I'll have to do some
>testing of my own. Is there a Postgres admin here
>who'd like to tell us what kind of resources
>Postgres demands?
Best tests are always your own. But the memory footprint is actually quite small.
The first process is an active connection to the datbase. Only uses about 524k of non-shared memory.
The second is the process that listens for incoming connections, and the third is the control program. You'll only have one of each of these.
E.g, when serving 100 simultaneous connections, the postmaster processes should use around 52MB, including the shared libraries.
Of course, you'd probably also want enough memory to keep your indexes cached. That'll depend on the size of your tables.
As for CPU utilization, I haven't really hit any walls there, since I only support a handful of clients, but I rarely see utilization by one postmaster process even break 2%, and thats on a complex five table join doing regular expression matching on two fields.
>Anyway, if there was a standard benchmark to run
>against both DB's from a vanilla install (and by
>that I mean running './configure' with no flags)
>then I think that would go a long way towards
>giving a more balanced view.
The tests they used ARE standard database benchmarking tests - AS3AP and TPC-C.
As for configuration, I can't rightly say what they did with it, as I wasn't there.
However, running them without any options does not necessarily put them on equal footing. For example, Postgres by default does an fsync after every single write, whereas MySQL does not. This SERIOUSLY impacts performance.
>They don't whine about their competition not
>being "SQL compatible" (a debatable term in any
>event). They don't lie about how the competition
>"isn't relational." They don't sneer about how
>the competition is "just a front end to the file
>system."
Have you read the MySQL docs?
Their section on why not to use foreign keys at best makes me laugh, at worst makes me cringe. This sentiment is even shared by most of the MySQL fans I know.
They gloss over their lack of sub-selects with an example that doesn't require the feature.
They gloss over the lack of transactions and commit/rollback syntax by suggesting table locking, which simply is not practical in high volume environments. Moreover, their examples neatly omit the idea that you may need to lock a *LOT* of tables, stalling updates to most of the database in order to circumvent the lack of MVCC.
Whether you want to admit it or not, the drawbacks in MySQL are *VERY* real, and the MySQL documentation trys to play them off as minimal annoyances.
I find their lack of responsibility in this more offensive than a few causally posted insults.
>It was added a while back. And still, mysql (when
>using MyISAM) is a lot faster than competing
>databases. Sorry I've done my independant
>benchmarks in the "real-world".
MySQL doesn't support transactions when using MyISAM tables, so your statement is either ignorant or deliberately misleading. How about testing MySQL running SleepyCat vs. a transactional database instead.
One other thing to note is that by default MySQL does not sync to disk after an insert or update. If you want a fair test, you should also disable this on the other database.
(Not that I personally would ever do this, since I *like* my data.)
>I used Postgres (back before the SQL was bolted
>on to it), and it worked but sorta sucked. Having
>a working database was all I asked for so I was
>happy.
If you're talking when it was just plain Postgres that was back in 1994. Even if you worked with Postgres95, it was back in 1995. (Big suprise.)
So your experience is mostly with an incarnation of Postgres thats 5 or more years old.
>I then tried one of the earlier releases of
>PostgreSql, and gave up on it.
Early releases of the SQL version were in the hands of a brand new set of developers. Of course they sucked.
>The reason (and I mean the single reason) I'm
>still running MySQL is its speed and operational
>ease. It never crashes.
I will give it that much.
We currently use MySQL heavily at the company I work for, and it does run reasonably fast and very reliabely.
However, in testing for future growth, the performance is less than phenominal with large tables supporting a large number of queries. Especially when you through inserts and updates into the mix. MySQL seems to break down and cry like a little girl.
Aside from that, the lack of a lot of SQL features in the production releases (and even development releases) represent a HUGE loss to project development time, requiring coding kludges in the front-end to circumvent MySQLs shortcomings.
>More power to you, but unless PostgreSql gets the
>upper hand in the operational arena, you'll have
>to pry MySQL from my cold dead fingers.
Where do you think Postgres CURRENTLY lacks in the "operational arena"? Given the timeframe you used Postgres in, any comparison is akin to benchmarking the 1.0 or 1.2 Linux kernel against modern operating systems.
>Issue two. They compared the bleeding edge
>postgres (7.0) with the old-as-heck mysql (3.22)
Again, they benched the current STABLE releases of the product in question.
Postgresql 7.0 has been released for months now, and was in beta for months previous to that.
The latest development branch of MySQL, on the other hand, is still undergoing some heavy changes, such as support for additional back-ends for storage (sleepycat, myisam), replication, etc.
This shows in the stability of the product. Last time I tried to run it (around.17 or so) I had it crash once, lock up once, and had the client segfault on me twice.
The occasional (!) crash might be fine and dandy for a home datbase, or static data for a non-crucial website. But a company that has to depend on the database being available 365/24/7 simply CANNOT tolerate this. Especially considering the speed of isam checking extremely large tables.
He obviously looked at the criteria, because he did quote from them. However, he did not seem to understand them very well.
Take the following snippet:
"Were we display aggregate number ovulnerabilities (Linux and BSD) the number is the size of the set that results from the union of all vulnerabilities for the components without duplication. Vulnerabilities are not counted twice."
This union includes all packages that ship with any version of Linux; e.g. it likely includes both xinetd and inetd, both proftp and wu-ftp, both pump and dhcpcd, both lpr and lprng, etc, etc.
So adding the Redhat and aggregate numbers does not indicate the number of bugs in Redhat. The Redhat number does, since that counts the bugs found in the packages Redhat ships.
The next issue is how many applications a Linux distribution includes, note:
"Similarly, a vulnerability in one of the RPMs distributed with RedHat Linux 6.2 is considered a vulnerability in that distribution. On the flip side, just because a random piece of software has a vulnerability it does not mean that the operating systems or applications it can run under are considered vulnerable."
So, we're counting bugs in literally thousands of applications in addition to the operating systems, most of which won't be in use. Some of the included packages were gnumeric, kde, enlightenment, etc.
And there is also the factor that some of the bugs were platform specific (e.g. ping and traceroute issues on alphas).
And finally he also didn't mention that this did not refer to any specific version of the operating system. At least seven of those updates were for version previous to 6.1.
Correcting for his inability to read and ignoring bugs for previous versions of the operating system, Redhat had 30 bugs. Nearly one-quarter that of WinNT. Remove the packages not typically run on a server, and you're down to 20, nearly one-fifth.
>One thing I have heard about Bonobo is that, >well, it is not known for being lightweight ( to >put it nicely.) Combining that with existing >bloat of SO what can we expect from this kind of >"marriage" ?
The idea that bonobo is a huge bloated monstrosity is an assertion oft repeated by KDE proponents, but rarely backed up. A large part of this may be due to KDE dropping use of CORBA as a part of their component model in favour of a pure shared library solution.
However Gnome is not KDE; and more importantly ORBit is not Mico.
A large problem with KDE implementation of CORBA is that it was built around Mico (which had already been attempted by the Gnome team and scrapped for performance reasons.) A simple test where a dummy function was executed 10,000 times was completed in a mere 2.93 seconds by ORBit, as opposed to 22.48 seconds by Mico.
A large portion of the performance benefit of ORBit is that, although it provides the ability for components to communicated through internet or unix domain sockets, it provides the ability to short circuit this method and load as a shared library if envoked on the same host as the calling application.
The benefit of this is that you have a single unified API allowing for both network transparent operation and high perfomance local operation.
Theory aside, I am currently running a Bonobo application on my desktop (Evolution) and see precious little evidence of any bloat. Yanking the memory usage statistics from top, the application itself is taking up 5640k, which might seem high if it weren't for the fact that 4432k of that represents shared libraries, including glib, gtk, gnome, X itself, and a variety of image libraries. The mailer component is also fairly lean, utilizing 7676k, with 5376k shared.
>well, Some month ago, our HPuX server's one scsi >drive failed. So out to buy a replacment. >Unfortunetly, The serrver had Fast-Wide disk's >and they are incompatible with the LVD disks they >sell all around.
Actually, your problem here isn't that fast-wide is incompatible with lvd; it's that fast-wide DIFFERENTIAL is incompatible with lvd.
It's an easy thing to miss, since HP simply labeled the ports on the machines as fast-wide in most instances, but until a couple years ago all wide connectors on the 9000 series were differential scsi rather than single-ended.
>The myriad of scsi variants makes The life of >using them a utter pain in the ass. The thumb >rule is that nothing works with nothing but the >same variant.
This is patently untrue. The following scsi protocals are backwards and forwards compatible:
SCSI-1 SCSI-2 (fast scsi or fast wide scsi) SCSI-3 (ultra scsi or ultra wide scsi) Ultra2 (lvd) Ultra/160 Ultra3 (not finalized yet)
In otherwords, ALL varities of scsi back to the original implementation.
The only thing you have to watch out for is the issue with traditional differential scsi (high-voltage differential) with single-ended or low-voltage differential. Everything else will negotiate.
Of all the issues SCSI has, compatibility is NOT one of them.
(If you want to complain about something, why not complain about the myriad of connectors used due to the scsi spec not specifying one, or the restrictions on cable-length with single-ended scsi?)
>SCO and HP own the rights to 30 years of UNIX >development. If SCO tanks, then HP will own the >sole rights to UNIX System V and it's >development.
What are you smoking? HP/UX is built on top of a SVR3 codebase, though it has been extended to support a lot of the SVR4 features in order to maintain compliance to the various Unix standards (POSIX, X/Open, etc).
SCO bought the rights to the SVR4 codebase from Novell. They own it exclusively. Whoever buys them will own it exclusively.
In any case, I disagree with your assertion that the codebase is the future of Unix. Standards are the future of Unix, whether they are implemented on Linux, BSD, SVR3, SVR4, or SVR5.
>That having been said, whoever owns SCO can port >SCO Merge to Linux, and there will be much >rejoicing!
SCO licenced the Merge codebase from a company called TreLOS. So its not theirs to port.
However, TreLOS has released a version for Linux called Win4Lin, which has the advantage of installing the Windows files inside your current filesystem (avoiding the need for a disk image or a seperate partition).
The only disadvantage I see to it is that it does not at this point support NT or Win2000. Buy any version of 95 or 98 should work just fine.
If you're interested, pop over to www.win4lin.com. They have an eval version up, and the entire product only costs $49.95.
>that i'm not too happy with the state of XFree86 >4.0. Primarily because there's a lot of support >that was left out.
The alternative being not releasing it so that people who DO have supported chipsets can use it?
>Particularly on most 3dfx chipsets. Sure, it says >all 3dfx chips are supported, but that's >laughable.
The DRI drivers are being done by 3DFX, so they're the ones that you have an issue with, not the XFree86 team.
It is also worth noting that the drivers are specifically mentioned in the FAQ to be beta quality at this time.
>Perhaps 4.0 was build up quite a bit more than >it should have been - but it comes down to the >fact that this wasn't really a next-gen release.
Ummm, a new codebase (X11R6.4), more protocol extensions (can we say Xinerama?), a re-enginnered direct rendering interface, integration of a font server and OpenGL software renderer, a binary loader that can load drivers on any operating system under the same architechture...
This smells of major next generation release to me.
>For some people it was worth while to upgrade, >while for others it was not.
And for almost all people it *will* be worthwhile to upgrade, once the driver base is brought up to snuff and the distributions start packaging it.
>I would have been much happier to see the folks >at XFree86 wait a little longer to release a much >better product.
What objections do you have to the current implementation, aside from whining that it the driver for your video card isn't finished?
Unfortunately its difficult for an unreleased product to gain a wide base of drivers, a signifigant amount of polish, and full bug testing.
>Something that everyone could upgrade to. I >know at least 3dfx and some ATI chips got >screwed.
Ummm, screwed? You can continue using 3.3.6 as you did before. The only people who need be affected are those that BENEFIT from the release.
And again, I must reiterate - waiting for all drivers to mature before release buys nothing. The only effect is to keep it out of the hands of the people who CAN upgrade and CAN benefit immediately.
>I think that the next UNIX to fall will be either >HP-UX, or TRU64. HP-UX still exists (last I >checked), but I never hear anything about it.
Well, HP-UX 11i was just release last week.
And HP operated in a completely different market than Linux.
For example, their V-Class configurations can provide up to 128 processors, 128GB of memory (32-way interleaved), 66.6GB of system throughput and 112 PCI slots.
The only real competitor in this space is IBM. Sun doesn't even have a product offering to compare.
>I do know that HP has set a time table for >killing off their PA-RISC chip, it will be a >while, but still.
Well, they've actually extended that roadmap recently due to delays with Merced as well as developments in their microprocessor group.
However, regardless of the future of PA-RISC as a platform, they have always made it clear that both HP/UX and MPE/IX were to be transitioned to Merced as their primary platform.
>Also, SCO has a working, clean desktop system >that's been tested extensively and used for >buisness applications. GNOME is definitely >getting there, but it's a little cutesy for my >taste. Then again, I wouldn't use open deathtrap, >either.
Are you talking about Panorama (the default on Openserver) or CDE (the default on Unixware).
Panorama, in my opinion, looks a lot more cartoonish than Gnome ever did. And is a hell of a lot less functional than even FVWM.
CDE is another issue. I personally dislike it because its nigh impossible to configure. But even if you do like it, they use a version licenced from TriTeal, who already does an independant version for Linux.
So IMHO, they have nothing to offer there.
>SCO also has MMDF, the mutant mail destruction >facility (Well, that's what those who know call >it anyway) which is fast, clean, secure, >and powerful; And they support it. It's nice to >have the power and flexibility of sendmail (more >or less) and be able to call someone for >support and have them be able to tell you just >what to do.
Oddly enough, in three years of supporting SCO, I came across one person who ran MMDF, and they only did because it was a legacy system they didn't want to mess with. The only other place I saw MMDF was in SCOs internal mail system.
In any case, why would you want something that has the power and flexibility of sendmail "more or less" as you put it, when you can get sendmail itself, with commercial support if you choose to pay for it.
>However, SCO UNIX isn't actually all that bad >and has a half-decent, tried and true support >infrastructure behind it. SCO also have quite >a lot of money.
I was part of that support infrastructure once, doing pre and post sales support on SCO products at a major distrubtor. As such, I dealt a lot with their premier support group.
Not only was their support group not that great to start with, but it has declined over the past two years. Mind you, most of my issues are with the front-line support, but even some of their back-end engineers are questionable.
Furthermore, their products are exceptionally buggy and don't get fixed even when you report them. I can cite at least a half-dozen major bugs that have been there through multiple releases.
Likewise, there are bugs in the current releases that I had been flat out told that they had no plans on fixing ni the current release.
>Solaris and IRIX are pretty attached to their >windowing systems. I wouldn't count this one as a >meaningful criterion.
Odd, there is a headless Sparcstation 10 sitting next to me running Solaris 2.7 without a graphical environment.
In fact, I would say Solaris on Sparc hardware is even more friendly to running sans graphical environmnet because its prom will set the console to the serial port if there is no keyboard attached.
Come to think of it, that is the default for Irix as well.
Odd behaviour for operating systems that are "attached" to their windowing environments isn't it?
Re:Clue impaired mac-people
on
Rack An iMac
·
· Score: 1
> Say what? This guy means to tell us that a > MIPS-based Linux rack-mount solution is a "PC"?
Actually, the RAQ3 *is* a PC, based on an AMD proccessor. It's the older, less featureful RAQ2 that is MIPS based.
Next time, before you insult someone, learn to make sure that you are justified in doing so.
>It just goes to show that people who post replies >here don't know dick about operating systems.
Agreed.:)
> Yet, people keep buying it. You know why?
Because of a large number of vertial market applications which haven't been ported to other platforms, such as Medical Manager, MAS/90, etc.
>Because SCO OpenServer 5.x is one of the most >stable and reliable Intel OS platforms you can >buy. It just works, and it works forever.
*ahem* SCO does not "just work" by any means of the imagination. I have spent the last two years supporting the platform and there are an ungodly number of bugs to it.
For example, since 5.0.0 I have seen the mkdev tape script completely fubar the link kit if you try to remove a tape drive that was misconfigured. You'd think that *thinks* 6 or 7 years would be long enough to fix that, wouldn't you?
Or network printing being completely broken out of the box on Openserver 5.0.5.
Or virtual domains showing up multiple times in the Internet Manager. Another bug that they have officially said they will never fix in the current release.
Or the problems with the new parallelized init scripts used in Openserver 5.0.4 and 5.0.5? (Mostly I have seen some of the scripts launched into the background ignoring the SIGALRM, thus hanging init.)
Granted, if you get it set up, and then don't poke at it much, it will run for a good long time.
> When you need stability, SCO can deliver.
I take exception to this as well. Look at Unixware 7.0. Look at Unixware 7.1. Look at Webtop 1.0. Look at Webtop 1.1. Look at NSC 7.1.0.
The NSC (Non-Stop Clustering) being the worst example, as it is supposed to be a high availability solution. Yet we have had two total failures of the entire cluster without a hardware fault.
> Finally, let me note that you can run all the > Open Source goodies on SCO platforms.
Unfortunately last time I checked they had cripled the version of GCC on skunkware to only use the SCO linker by changing the -B flag to be binary time (e.g. COFF or ELF) instead of what the GNU binutils package accepts.
And ignoring the fact that if it isn't on Skunkware getting ANY package to compile against SCO is akin to flaying off skin and rubbing salt into the wound because of the variety of quirks in many of the SCO APIs and the gaping holes in others.
Not to say that SCO doesn't have its advantages. But the cost of implementing SCO far outweighs any benefits. And in many ways it is inferior to the free variants of Unix.
Slashdot Mirror
>BUT: Eazel, HelixCode and Sun have put themselves
;(
>into keypositions by developing the
>standard-gnome-filemanager, the
>standard-gnome-office and the
>standard-gnome-pim.
Yes, Eazel gave us a new filemanager.
Does this prevent us from using other ones? Of course not, its method of integration is through the standard drag-and-drop and embedding mechanisms.
Does this prevent us from forking the code in the future if need be? Of course not, its GPL.
Yes, Sun is giving us a free office suite.
Does this prevent us from using other ones? Of course not.
Does this prevent us from forking the code in the future if need be? Of course not.
Does this prevent us from using portions of their office suite with other components? Of course not, as they are publshing the details of their file formats and using the standard methods for integration under Gnome.
Yes, HelixCode is giving us a groupware product.
But they were doing that before they even formed the company, and the people who were working on it still are. They're just being paid.
Does this prevent us from using other products? No, of course.
Does this prevent us from forking the code if necessary? No, of course not, it's GPL.
Does this prevent us from using portions of their groupware with other products? No, of course not. They are using standard libraries, drag-and-drop, embedding, protocals, etc.
And regardless of all that, the FRAMEWORK of Gnome is in the hands of developers from all of these companies, as well as independent developers and those working at Redhat.
We are not in danger of vendor lock-in, we are not in danger of vendor control, we are not in danger period.
>Anyone looked at the mailinglists of gnumeric and
>abiword? -- These projects are obviously dying
>already
I count 24 new entries in the ChangeLog for gnumeric this month, and 92 new commits to Abiword. How is this dying?
Oh, and BTW, Gnumeric was one of the first projects Helix backed. I don't see how their rise to a key position can endanger one of their own products.
And beyond even that, the details of the Gnome office release are not out yet. For all we know, StarCalc may not even be part of the upcoming OpenOffice release.
>By occupying the core-positions these companies
>are obviously destroying the developer
>infrastructure that made sure that even
>independent developers can influence the
>development of such projects significantly.
Hint, the bulk of the independent developers are still there. A lot of them are just being paid for it now.
Hint, look at the membership of the Gnome Foundation. It's still largely independent developers.
>And of course, in the real world, nobody ever
>actually inserts and selects at the same time.
>
>Try to find legitimate things to complain about.
Really? I do. The applications my company runs do. Any sort of e-commerce site does. Slashdot does.
>MySQL, starting with 3.23.15, has transaction
>support. Given, 3.23 is a beta series, but it's
>been in beta for quite a while, it should be
>fairly stable. Transaction support has been in
>the 3.23 series since this May.
Yes, 3.23 has been in alpha/beta for a while, but as you point out, transaction support has only been there since 3.23.15, or a mere 8 experimental releases.
Yes, its been in there since May, but do you think that three months is nearly enough time to integrate an entire new table type, add support for transactions, and properly test it? And this while other experimental features are being added?
And finally, I would have issue with the scalability and reliability of a table type (BDB) in a multi-user environment when it was designed primarily for embedded single-user databases.
>As they haven't released any information about :(
>the test or even the results one can just assume
>that they have done a test that doesn't have
>anything to do with the real world
"In the AS3AP tests... Postgres peaked at 1127.8 transactions per second with five users, and still processed at a steady rate of 1070.4 with 100 users... MySQL reached a peak of 803.48 with two users, but its performance fell precipitously under the stress of additional users to a rate of 117.87 transactions per second with 100 users."
The test is standard, so the definition of what it entails is easy to come by and they provided what the results were. So your above complaint really has no substance to it.
However, I do agree there should have been more information - namely the software configuration.
>PostgreSQL has of course also a lot of weak
>areas, like slow connection, slow insert, slow
>create/drop tables, running long multiple
>transactions where you get a conflict
>at the end (in this page/row locking is better)
Yes, Postgres is slower to connect, though not grotesqely so.
Yes, Postgres is slower to do inserts, but updates and inserts don't block. So though MySQL may be impressive if you bench insert speed without considering its impact on overall performance, in real world applications you'll see very different behaviour.
I'm not sure exactly what you're refering to when you mention "conflicts" at the end of transaction blocks. This is one area where I find MySQL falls short, since a) it has no transactions and b) it doesn't have the framework for transactions (e.g. multi-version concurency control, etc).
>We here at MySQL has always tried to design very
>fair test that no one can misinterpret or lie
>about.
Unfortunately the benchmarks MySQL uses are all single client load, which is completely meaningless in a production environment and covers up the weakest parts of MySQL (e.g. all selects stalling while an insert or update is happening).
>It's a shame that Great Bridge funds a test that
>is solely done to confuse users instead of
>telling the truth; PostgreSQL is good in some
>areas, and bad in others, just like all other
>databases.
I fail to see where they state what you are claiming they did. They merely point that a) on the AS3AP test, using the current production release of MySQL with its ODBC implementation, the performance was lackluster, and that MySQL currently lacks the feature set to run TPC-C.
>The article doesn't mention anything about this >or even with which ODBC driver they used the
>different databases.
As opposed to the benchmark on the MySQL website, where they make no mention of how the databases were compiled, what limits were set, what version of Perl was used, what version of DBI was used, what version of the DBD drivers were used, what hardware platform it was run on, what operating system it was run on, etc, etc.
And futhermore they are benchtesting an alpha product against a faily old stable release (6.5 being current over a year before these benchmarks were posted, with a half dozen released in the meantime).
>I also don't agree with the argument that they
>are not testing MySQL 3.23 as this is still
>marked 'beta'. We have here at MySQL a completely
>different release schedule on our versions...
>Compared to our release schedule, PostgreSQL 7.0 >would be called alpha.
Nice way to imply that the Postgres team doesn't properly beta test. Fact of the matter is that the 7.0 release spend many many months in its alpha/beta/gamma cycle.
There were a couple bugs that slipped through the cracks, but the subsequent releases resolved all known issues, and came very promptly (15 days between 7.0 and 7.0.1, and then 3 days between 7.0.1 and 7.0.2).
As for the development cycles being different, I agree. Though I would go the other direction. The goals of the 7.0 development series were much less ambitious than those of the 3.23 series of MySQL has; e.g. replication, two new backends, transaction support, a real locking mechanism, etc. Not to mention that they stopped adding new features to 7.0 about 6 months ago, whereas MySQL is continuing to add features (and change existing features) of 3.23.
>The net result is that the posted test is about
>as wrong as you can do a test, the important
>thing is just to get the people that reads that
>page to understand that.
Funny, I would say the epitomy of both misleading and incorrect testing would be the sql-bench suite run by MySQL.
>I had heard that Postgres was slow as hell and a
>serious resource hog, but I'll have to do some
>testing of my own. Is there a Postgres admin here
>who'd like to tell us what kind of resources
>Postgres demands?
Best tests are always your own. But the memory footprint is actually quite small.
SIZE RSS SHARE
2196 2132 1672 postmaster
444 300 252 postmaster
156 4 4 pg_ctl
The first process is an active connection to the datbase. Only uses about 524k of non-shared memory.
The second is the process that listens for incoming connections, and the third is the control program. You'll only have one of each of these.
E.g, when serving 100 simultaneous connections, the postmaster processes should use around 52MB, including the shared libraries.
Of course, you'd probably also want enough memory to keep your indexes cached. That'll depend on the size of your tables.
As for CPU utilization, I haven't really hit any walls there, since I only support a handful of clients, but I rarely see utilization by one postmaster process even break 2%, and thats on a complex five table join doing regular expression matching on two fields.
>Anyway, if there was a standard benchmark to run
>against both DB's from a vanilla install (and by
>that I mean running './configure' with no flags)
>then I think that would go a long way towards
>giving a more balanced view.
The tests they used ARE standard database benchmarking tests - AS3AP and TPC-C.
As for configuration, I can't rightly say what they did with it, as I wasn't there.
However, running them without any options does not necessarily put them on equal footing. For example, Postgres by default does an fsync after every single write, whereas MySQL does not. This SERIOUSLY impacts performance.
>They don't whine about their competition not
>being "SQL compatible" (a debatable term in any
>event). They don't lie about how the competition
>"isn't relational." They don't sneer about how
>the competition is "just a front end to the file
>system."
Have you read the MySQL docs?
Their section on why not to use foreign keys at best makes me laugh, at worst makes me cringe. This sentiment is even shared by most of the MySQL fans I know.
They gloss over their lack of sub-selects with an example that doesn't require the feature.
They gloss over the lack of transactions and commit/rollback syntax by suggesting table locking, which simply is not practical in high volume environments. Moreover, their examples neatly omit the idea that you may need to lock a *LOT* of tables, stalling updates to most of the database in order to circumvent the lack of MVCC.
Whether you want to admit it or not, the drawbacks in MySQL are *VERY* real, and the MySQL documentation trys to play them off as minimal annoyances.
I find their lack of responsibility in this more offensive than a few causally posted insults.
>It was added a while back. And still, mysql (when
>using MyISAM) is a lot faster than competing
>databases. Sorry I've done my independant
>benchmarks in the "real-world".
MySQL doesn't support transactions when using MyISAM tables, so your statement is either ignorant or deliberately misleading. How about testing MySQL running SleepyCat vs. a transactional database instead.
One other thing to note is that by default MySQL does not sync to disk after an insert or update. If you want a fair test, you should also disable this on the other database.
(Not that I personally would ever do this, since I *like* my data.)
>I used Postgres (back before the SQL was bolted
>on to it), and it worked but sorta sucked. Having
>a working database was all I asked for so I was
>happy.
If you're talking when it was just plain Postgres that was back in 1994. Even if you worked with Postgres95, it was back in 1995. (Big suprise.)
So your experience is mostly with an incarnation of Postgres thats 5 or more years old.
>I then tried one of the earlier releases of
>PostgreSql, and gave up on it.
Early releases of the SQL version were in the hands of a brand new set of developers. Of course they sucked.
>The reason (and I mean the single reason) I'm
>still running MySQL is its speed and operational
>ease. It never crashes.
I will give it that much.
We currently use MySQL heavily at the company I work for, and it does run reasonably fast and very reliabely.
However, in testing for future growth, the performance is less than phenominal with large tables supporting a large number of queries. Especially when you through inserts and updates into the mix. MySQL seems to break down and cry like a little girl.
Aside from that, the lack of a lot of SQL features in the production releases (and even development releases) represent a HUGE loss to project development time, requiring coding kludges in the front-end to circumvent MySQLs shortcomings.
>More power to you, but unless PostgreSql gets the
>upper hand in the operational arena, you'll have
>to pry MySQL from my cold dead fingers.
Where do you think Postgres CURRENTLY lacks in the "operational arena"? Given the timeframe you used Postgres in, any comparison is akin to benchmarking the 1.0 or 1.2 Linux kernel against modern operating systems.
>Issue two. They compared the bleeding edge
.17 or so) I had it crash once, lock up once, and had the client segfault on me twice.
>postgres (7.0) with the old-as-heck mysql (3.22)
Again, they benched the current STABLE releases of the product in question.
Postgresql 7.0 has been released for months now, and was in beta for months previous to that.
The latest development branch of MySQL, on the other hand, is still undergoing some heavy changes, such as support for additional back-ends for storage (sleepycat, myisam), replication, etc.
This shows in the stability of the product. Last time I tried to run it (around
The occasional (!) crash might be fine and dandy for a home datbase, or static data for a non-crucial website. But a company that has to depend on the database being available 365/24/7 simply CANNOT tolerate this. Especially considering the speed of isam checking extremely large tables.
>Its just not a really fair representaiton since
>they used OLD MySQL
How is it not fair that they used the STABLE version instead of an ALPHA for testing?
He obviously looked at the criteria, because he did quote from them. However, he did not seem to understand them very well.
Take the following snippet:
"Were we display aggregate number ovulnerabilities (Linux and BSD) the number is the size of the set that results from the union of all vulnerabilities for the components without duplication. Vulnerabilities are not counted twice."
This union includes all packages that ship with any version of Linux; e.g. it likely includes both xinetd and inetd, both proftp and wu-ftp, both pump and dhcpcd, both lpr and lprng, etc, etc.
So adding the Redhat and aggregate numbers does not indicate the number of bugs in Redhat. The Redhat number does, since that counts the bugs found in the packages Redhat ships.
The next issue is how many applications a Linux distribution includes, note:
"Similarly, a vulnerability in one of the RPMs distributed with RedHat Linux 6.2 is considered a vulnerability in that distribution. On the flip side, just because a random piece of software has a vulnerability it does not mean that the operating systems or applications it can run under are considered vulnerable."
So, we're counting bugs in literally thousands of applications in addition to the operating systems, most of which won't be in use. Some of the included packages were gnumeric, kde, enlightenment, etc.
And there is also the factor that some of the bugs were platform specific (e.g. ping and traceroute issues on alphas).
And finally he also didn't mention that this did not refer to any specific version of the operating system. At least seven of those updates were for version previous to 6.1.
Correcting for his inability to read and ignoring bugs for previous versions of the operating system, Redhat had 30 bugs. Nearly one-quarter that of WinNT. Remove the packages not typically run on a server, and you're down to 20, nearly one-fifth.
>Hmmm, I seem to remember that SCO is the owner
>of the UNIX trademark.
Nope, they transfered the trademark to the Open Group back in like 1995.
What they do own is the System V codebase.
>One thing I have heard about Bonobo is that,
>well, it is not known for being lightweight ( to
>put it nicely.) Combining that with existing
>bloat of SO what can we expect from this kind of
>"marriage" ?
The idea that bonobo is a huge bloated monstrosity is an assertion oft repeated by KDE proponents, but rarely backed up. A large part of this may be due to KDE dropping use of CORBA as a part of their component model in favour of a pure shared library solution.
However Gnome is not KDE; and more importantly ORBit is not Mico.
A large problem with KDE implementation of CORBA is that it was built around Mico (which had already been attempted by the Gnome team and scrapped for performance reasons.) A simple test where a dummy function was executed 10,000 times was completed in a mere 2.93 seconds by ORBit, as opposed to 22.48 seconds by Mico.
A large portion of the performance benefit of ORBit is that, although it provides the ability for components to communicated through internet or unix domain sockets, it provides the ability to short circuit this method and load as a shared library if envoked on the same host as the calling application.
The benefit of this is that you have a single unified API allowing for both network transparent operation and high perfomance local operation.
Theory aside, I am currently running a Bonobo application on my desktop (Evolution) and see precious little evidence of any bloat. Yanking the memory usage statistics from top, the application itself is taking up 5640k, which might seem high if it weren't for the fact that 4432k of that represents shared libraries, including glib, gtk, gnome, X itself, and a variety of image libraries. The mailer component is also fairly lean, utilizing 7676k, with 5376k shared.
>well, Some month ago, our HPuX server's one scsi
>drive failed. So out to buy a replacment.
>Unfortunetly, The serrver had Fast-Wide disk's
>and they are incompatible with the LVD disks they
>sell all around.
Actually, your problem here isn't that fast-wide is incompatible with lvd; it's that fast-wide DIFFERENTIAL is incompatible with lvd.
It's an easy thing to miss, since HP simply labeled the ports on the machines as fast-wide in most instances, but until a couple years ago all wide connectors on the 9000 series were differential scsi rather than single-ended.
>The myriad of scsi variants makes The life of
>using them a utter pain in the ass. The thumb
>rule is that nothing works with nothing but the
>same variant.
This is patently untrue. The following scsi protocals are backwards and forwards compatible:
SCSI-1
SCSI-2 (fast scsi or fast wide scsi)
SCSI-3 (ultra scsi or ultra wide scsi)
Ultra2 (lvd)
Ultra/160
Ultra3 (not finalized yet)
In otherwords, ALL varities of scsi back to the original implementation.
The only thing you have to watch out for is the issue with traditional differential scsi (high-voltage differential) with single-ended or low-voltage differential. Everything else will negotiate.
Of all the issues SCSI has, compatibility is NOT one of them.
(If you want to complain about something, why not complain about the myriad of connectors used due to the scsi spec not specifying one, or the restrictions on cable-length with single-ended scsi?)
First off, Gnumeric has been using Bonobo for a long while, as it is the testbed application.
Other applications that make use of it include Evolution, Gnome Ghostview, Gnome Xpdf, Gill, and Nautilus.
It may not be finished, but it is being finalized for inclusion in Gnome 2.0, due out this fall.
>SCO and HP own the rights to 30 years of UNIX
>development. If SCO tanks, then HP will own the
>sole rights to UNIX System V and it's
>development.
What are you smoking? HP/UX is built on top of a SVR3 codebase, though it has been extended to support a lot of the SVR4 features in order to maintain compliance to the various Unix standards (POSIX, X/Open, etc).
SCO bought the rights to the SVR4 codebase from Novell. They own it exclusively. Whoever buys them will own it exclusively.
In any case, I disagree with your assertion that the codebase is the future of Unix. Standards are the future of Unix, whether they are implemented on Linux, BSD, SVR3, SVR4, or SVR5.
>That having been said, whoever owns SCO can port
>SCO Merge to Linux, and there will be much
>rejoicing!
SCO licenced the Merge codebase from a company called TreLOS. So its not theirs to port.
However, TreLOS has released a version for Linux called Win4Lin, which has the advantage of installing the Windows files inside your current filesystem (avoiding the need for a disk image or a seperate partition).
The only disadvantage I see to it is that it does not at this point support NT or Win2000. Buy any version of 95 or 98 should work just fine.
If you're interested, pop over to www.win4lin.com. They have an eval version up, and the entire product only costs $49.95.
>that i'm not too happy with the state of XFree86
>4.0. Primarily because there's a lot of support
>that was left out.
The alternative being not releasing it so that people who DO have supported chipsets can use it?
>Particularly on most 3dfx chipsets. Sure, it says
>all 3dfx chips are supported, but that's
>laughable.
The DRI drivers are being done by 3DFX, so they're the ones that you have an issue with, not the XFree86 team.
It is also worth noting that the drivers are specifically mentioned in the FAQ to be beta quality at this time.
>Perhaps 4.0 was build up quite a bit more than
>it should have been - but it comes down to the
>fact that this wasn't really a next-gen release.
Ummm, a new codebase (X11R6.4), more protocol extensions (can we say Xinerama?), a re-enginnered direct rendering interface, integration of a font server and OpenGL software renderer, a binary loader that can load drivers on any operating system under the same architechture...
This smells of major next generation release to me.
>For some people it was worth while to upgrade,
>while for others it was not.
And for almost all people it *will* be worthwhile to upgrade, once the driver base is brought up to snuff and the distributions start packaging it.
>I would have been much happier to see the folks
>at XFree86 wait a little longer to release a much
>better product.
What objections do you have to the current implementation, aside from whining that it the driver for your video card isn't finished?
Unfortunately its difficult for an unreleased product to gain a wide base of drivers, a signifigant amount of polish, and full bug testing.
>Something that everyone could upgrade to. I
>know at least 3dfx and some ATI chips got
>screwed.
Ummm, screwed? You can continue using 3.3.6 as you did before. The only people who need be affected are those that BENEFIT from the release.
And again, I must reiterate - waiting for all drivers to mature before release buys nothing. The only effect is to keep it out of the hands of the people who CAN upgrade and CAN benefit immediately.
>I think that the next UNIX to fall will be either
>HP-UX, or TRU64. HP-UX still exists (last I
>checked), but I never hear anything about it.
Well, HP-UX 11i was just release last week.
And HP operated in a completely different market than Linux.
For example, their V-Class configurations can provide up to 128 processors, 128GB of memory (32-way interleaved), 66.6GB of system throughput and 112 PCI slots.
The only real competitor in this space is IBM. Sun doesn't even have a product offering to compare.
>I do know that HP has set a time table for
>killing off their PA-RISC chip, it will be a
>while, but still.
Well, they've actually extended that roadmap recently due to delays with Merced as well as developments in their microprocessor group.
However, regardless of the future of PA-RISC as a platform, they have always made it clear that both HP/UX and MPE/IX were to be transitioned to Merced as their primary platform.
>Also, SCO has a working, clean desktop system
>that's been tested extensively and used for
>buisness applications. GNOME is definitely
>getting there, but it's a little cutesy for my
>taste. Then again, I wouldn't use open deathtrap,
>either.
Are you talking about Panorama (the default on Openserver) or CDE (the default on Unixware).
Panorama, in my opinion, looks a lot more cartoonish than Gnome ever did. And is a hell of a lot less functional than even FVWM.
CDE is another issue. I personally dislike it because its nigh impossible to configure. But even if you do like it, they use a version licenced from TriTeal, who already does an independant version for Linux.
So IMHO, they have nothing to offer there.
>SCO also has MMDF, the mutant mail destruction
>facility (Well, that's what those who know call
>it anyway) which is fast, clean, secure,
>and powerful; And they support it. It's nice to
>have the power and flexibility of sendmail (more
>or less) and be able to call someone for
>support and have them be able to tell you just
>what to do.
Oddly enough, in three years of supporting SCO, I came across one person who ran MMDF, and they only did because it was a legacy system they didn't want to mess with. The only other place I saw MMDF was in SCOs internal mail system.
In any case, why would you want something that has the power and flexibility of sendmail "more or less" as you put it, when you can get sendmail itself, with commercial support if you choose to pay for it.
>However, SCO UNIX isn't actually all that bad
>and has a half-decent, tried and true support
>infrastructure behind it. SCO also have quite
>a lot of money.
I was part of that support infrastructure once, doing pre and post sales support on SCO products at a major distrubtor. As such, I dealt a lot with their premier support group.
Not only was their support group not that great to start with, but it has declined over the past two years. Mind you, most of my issues are with the front-line support, but even some of their back-end engineers are questionable.
Furthermore, their products are exceptionally buggy and don't get fixed even when you report them. I can cite at least a half-dozen major bugs that have been there through multiple releases.
Likewise, there are bugs in the current releases that I had been flat out told that they had no plans on fixing ni the current release.
>Solaris and IRIX are pretty attached to their
>windowing systems. I wouldn't count this one as a
>meaningful criterion.
Odd, there is a headless Sparcstation 10 sitting next to me running Solaris 2.7 without a graphical environment.
In fact, I would say Solaris on Sparc hardware is even more friendly to running sans graphical environmnet because its prom will set the console to the serial port if there is no keyboard attached.
Come to think of it, that is the default for Irix as well.
Odd behaviour for operating systems that are "attached" to their windowing environments isn't it?
> Say what? This guy means to tell us that a
> MIPS-based Linux rack-mount solution is a "PC"?
Actually, the RAQ3 *is* a PC, based on an AMD proccessor. It's the older, less featureful RAQ2 that is MIPS based.
Next time, before you insult someone, learn to make sure that you are justified in doing so.
>It just goes to show that people who post replies
:)
>here don't know dick about operating systems.
Agreed.
> Yet, people keep buying it. You know why?
Because of a large number of vertial market applications which haven't been ported to other platforms, such as Medical Manager, MAS/90, etc.
>Because SCO OpenServer 5.x is one of the most
>stable and reliable Intel OS platforms you can
>buy. It just works, and it works forever.
*ahem* SCO does not "just work" by any means of the imagination. I have spent the last two years supporting the platform and there are an ungodly number of bugs to it.
For example, since 5.0.0 I have seen the mkdev tape script completely fubar the link kit if you try to remove a tape drive that was misconfigured.
You'd think that *thinks* 6 or 7 years would be long enough to fix that, wouldn't you?
Or network printing being completely broken out of the box on Openserver 5.0.5.
Or virtual domains showing up multiple times in the Internet Manager. Another bug that they have officially said they will never fix in the current release.
Or the problems with the new parallelized init scripts used in Openserver 5.0.4 and 5.0.5? (Mostly I have seen some of the scripts launched into the background ignoring the SIGALRM, thus hanging init.)
Granted, if you get it set up, and then don't poke at it much, it will run for a good long time.
> When you need stability, SCO can deliver.
I take exception to this as well. Look at Unixware 7.0. Look at Unixware 7.1. Look at Webtop 1.0. Look at Webtop 1.1. Look at NSC 7.1.0.
The NSC (Non-Stop Clustering) being the worst example, as it is supposed to be a high availability solution. Yet we have had two total failures of the entire cluster without a hardware fault.
> Finally, let me note that you can run all the
> Open Source goodies on SCO platforms.
Unfortunately last time I checked they had cripled the version of GCC on skunkware to only use the SCO linker by changing the -B flag to be binary time (e.g. COFF or ELF) instead of what the GNU binutils package accepts.
And ignoring the fact that if it isn't on Skunkware getting ANY package to compile against SCO is akin to flaying off skin and rubbing salt into the wound because of the variety of quirks in many of the SCO APIs and the gaping holes in others.
Not to say that SCO doesn't have its advantages. But the cost of implementing SCO far outweighs any benefits. And in many ways it is inferior to the free variants of Unix.