* The threading vs. processes was indeed my bad.
Since I have no idea why I said one when I
meant the other.:)
* No, those numbers are meaningless unless more
background is given. What backend are they
using? What proportion of selects to inserts?
Are they simple or complex queries? How big
are the tables? What operating system and
hardware platform are they running on?
The "numbers speak for themselves" arguments
rank only below the "we lack all these features,
but you shouldn't use them anyways, and besides,
we're planning them in the next few major
release" arguments in sullying the reputation
of MySQL in a lot of people's eyes.
* Unless your website is publishing false
information, you're wrong about locking on
MyISAM tables. I quote, "Currently MySQL only
supports table locking for ISAM/MyISAM and HEAP
tables and page level locking for BDB tables."
* MVCC has been part of Postgresql since June
1999; InnoDB was originally interfaced with
MySQL September 2000 and made part of the
mainstream distribution March 2001.
Likewise, MVCC is the locking backend for EVERY
Postgres installation, whereas InnoDB likely
constitutes a small portion of MySQL installs.
Guess which one has proven itself in production
environments?
* Again with the "usually". Your statement is
meaningless and only serves to discredit your
repute if you don't give at least some context.
Yes, MySQL *can* be up to 100 times faster; it
can also curl up in a little ball and cry like
a little girl under loads that Postgres and
other more featureful databases would handle
gracefully.
No, not every database is suited for every
application, but as I pointed out in my
original comment, there are very few instances
I can see where MySQL makes a better choice.
The lack of a robust implementation of ANSI
SQL make anything but trivial database schema
painful to implement and typically requires
reimplementing the missing features in each and
every piece of client code. Though the latest
release of MySQL adds many missing features,
most of them are in table backends that are
not widely adopted and thus lack rigorous
testing (and I'm not talking about a simple
regression test).
The main complain is the lack of fine-grained
locking, which makes most common usage patterns
(save data warehousing, which someone was kind
enough to reminds me of) perform worse as
access grows. This very real limit on practical
scalability makes theoretical performance edge
nigh meaningless in many situations.
* If you'll re-read my comments on the benchmark
on the InnoDB site, the complaint about the
Postgres test was not that it was missing
instructions for recreating the results, but
that the ONLY comparison was on select speed,
single client.
However, my issue with the test against a
"market-leading database" was in fact a matter
of them using different methedology for testing
each database, and only publishing the perl
code for the InnoDB test:
"Source code of tests for InnoDB is included
at the end of this email. Note that the tests
were not run in exactly the same way for the
other database."
* Regardless of whether its hard to write
benchmarks that cover concurrent access or not,
it doesn't change the fact that what is
currently published on the MySQL website is
nothing more than marketing material. To recap
a previous analogy, its like choosing a sports
car over a pick-up truck for hauling on the
basis that the sports car goes REALLY fast
when carrying a single two by four.
* I've read innumerable comparisons between
Postgres and MySQL. Not to mention having a
fair amount of experience with both in a
production environment.
It was, in fact, my research and the limitations
and poor performance I have experienced with
MySQL in a large-scale deployment that have
formed my opinions on the matter.
Given that one of my "simple faults" was a slip
of the tongue and another is backed up by
published material on your own website,
coupled with your failure to adequately
address my "opinions", you might want to
reconsider the condescending tone you chose
to take in the first paragraph of your
response.
>I played with Postgres again recently, and
>realized that because it (proudly) supports
>transactions and integrity constraints, I expect
>it to support a reasonable subset of SQL92. And
>yet, no subselects. And other annoying omissions
>I've forgotten.
Maybe what you forgot to do is actually look at the feature list and/or try using the features you think are missing. Postgresql supported sub-selects even in the 6.X series.
If you take a close look at the benchmarking on the InnoDB site, you'll notice their comparison against Postgresql is only measuring speeds with a since query running against the database. Likewise for their MyISAM vs. InnoDB test, and their MySQL vs "market-leading database test".
So all of these suffer from the same thing that the default MySQL benchmarks do - they're meaningless save for marketing. There are very few real world applications that are going to have serialized queries, and those that do are likely not going to require a lot of raw speed.
If you'll notice, the only test that they use multiple connections with is their scalability test, in which they make no comparison to other databases, and that showed performance dropping sharply on selects after 50 clients, and didn't even bother giving performance on more than 20 for inserts (I'd be interested in knowing whether they were just embarassing or if the server actually crashed).
And none of the tests include a mixed load of selects and inserts. And they flat out admit their methodology was different for MySQL and the contender in one test. And they ran all of it on a single server. And none of the tests include large tables, joins, transactions, sub-selects, etc, etc. The number of faults with their benchmarks are innumerable.
Part of the beauty of the newer releases of Postgresql (aside from the improvements to the query optimizer) is their new "no-locking" MVCC (Multi Version Concurrency Control) system. Selects NEVER block inserts and vice versa.
This is a _huge_ win in terms of performance in real world situations; coupled with the row (or even cell level) locking pretty much guarante better scalability than MySQL, even if running a table type that supports finer grain locking (I believe the best they do right now is page level).
I like to think of MySQL as a sports car. It'll get to zero to sixty faster than an 18-wheel truck. But if you try to put any load on it, it won't even more.
(Note - the company I work for uses MySQL for a large production database. And it has worked even for a fairly large database under a somewhat heavy load. However, it is performing adequately, not well. And there are a lot of things we simply CANNOT do (e.g. a large query against the database for statistics purposes, since the select would lock all inserts and deadlock the database. Even under normal load its not uncommon for us to see 20-30 selects locked waiting for an insert to complete).
And to be honest, even if MySQL performed half as well as their documentation implied, I find the lack of features like sub selects, select into table, transactions (under the heavily tested table types), stored procedures, triggers, foreign keys and views make it a waste of my time and a waste of the programmers time.
We have dozens of programs and scripts that all have to access the database and they all have to work around the deficiencies in MySQLs capabilities. And, to be honest, not every attempt to do so is ultimately successful, resulting in hours wasted doing cleanup work (when it actually CAN be done without killing the database.).
I don't begrudge other people their preferences, but it would take a LOT of improvement and real benchmarks to convince me MySQL is a better database.
Well, once and for all it is indisputable that bare lfs in a message body are forbidden.
In particular, LSMTP until recently allowed them. In fact me and several employees of L-Soft got into a pissing match over the matter when a large mailing list started flooding our servers with something on the order of 4 million SMTP connections a day using their software. Their argument was that, since it was only an Internet Draft and the RFCs only RECOMMENDED bare LFs be filtered, they were perfectly justified in not fixing the issue.
Main Entry: pedant
obsolete : a male schoolteacher
2 a : one who makes a show of knowledge b : one
who is unimaginative or who unduly emphasizes
minutiae in the presentation or use of knowledge
c: a formalist or precisionist in teaching
Which one of these applies exactly? Because your post is incorrect.
>Your commandline does not solve the problem that
>the original invocation of xargs was intended to
>solve - passing a *huge* number of files to grep
>on the commandline (grep * in a directory with a
>ton of files) causes it to break.
Actually, it *does* solve the issue that xargs was intended to solve - shells have finite (often 100 or 255 character) commandline buffers.
For example:
bash-2.04$ find . -type f | wc -l
35416
bash-2.04$ grep -il "is there anybody out \
there" `find -type f`
bash:/bin/grep: Argument list too long
bash-2.04$ find . -type f -print0 | xargs -0 \
grep -il "is there anybody out there"
I've done this on Linux, Solaris, OpenBSD, HP/UX, Openserver and Unixware without any problems.
> $/bin/ls | xargs grep "foo"
> is the equivilant to
> $ grep "foo" `/bin/ls`
This is almost, but not quite true.
First difference is that `/bin/ls` will be executed and substituted into the commandline buffer of the shell you're using, thus giving the possibility of an overrun.
The second difference is that you don't have to worry about escaping out special characters when using the backtick operators, but you do when using xargs.
For example, I have a directory containing a file with a single quote in its name. So this happens:
bash-2.04$ ls | xargs file
xargs: unmatched single quote
To work around this, its usually much better to use find.
10 watts may not make not make or break your air conditioner, but how many server rooms have a single machine? The company I work for currently has 112 dual processor servers.
The "10 watt difference" suddenly is 537.6kwh/day, or 193536kwh/year.
Even if you look at that in terms of just how much the electricity itself costs, we'd be paying $27,095.04 more a year if we were using (the currently non-existent) dual athlon boxen.
>I think this whole "they project each frame
>multiple times" thing is some weird urban
>legend...
Sorry, but speculation does not make fact. If you bother to go to the rec.arts.movie.tech FAQ, they refer to how the use of a double-bladed shutter does in fact cause each frame to be shown twice.
The issue of the matter is how the human eye percieves light. By cutting the display time in half, even if it is the same image, the eye percieves change, thereby creating an optical illusion that cuts down on the perception of the actual jerkiness of the changing images.
As I am not disciplined in this field, I did not retain the information on this particularly well. However I have come across a large number of sites backing this up. (Mostly stumbled across when looking into HDTV and progressive scan video technology).
>Instead I get a bunch of CDs that are now
>useless.
By that definition of useless, EVERY data CD is useless. There is no such thing as a bug-free release of any piece of software.
>Oh I guess I could install RH 7.0 and then
>download a million patches.
Oh you poor thing. You have to type 'up2date' at the console.
>Service packs are a great idea because you can
>consolidate all of the fixes into a comprehensive
>unit and thus you can tell people, my software
>will work on Redhat 7.0 service pack 3
I have to agree with you on this one. The concept of a service pack or a patch bundle is usefull at times.
However, patches SHOULD be made available as soon as there is one, and should continue to be available individually.
I don't know how many times during my stint as a support person I ran into a service pack or patch bundle that broke other things that were working fine.
>"Speaking of USB scanners, what the hell was that
>on the SuSE website about XFree86 4.0 supporting
>scanners on parallel ports???"
This is an easy one. Scanners with parallel port interfaces. Before USB became prevelant in 98-99, the two major interface types for scanners were either SCSI or parallel.
>I honestly don't know; this seems to defy logic.
>I would assume that this works out for a DB-25
>connector, but aren't the pinouts for the SCSI
>DB-25 and the Parallel DB-25 totally different?
Yes, they are. In fact, they're different signalling types, so they can't even be compared on a pin for pin basis.
>Maybe not, because Iomega's Zip Plus actually
>autodetected whether the connection was parallel
>or SCSI. But an LPT controller used as a SCSI
>device? This is making my head spin!
The Zip Plus actually had a built in parallel to SCSI converter built in. If you pluged into a real SCSI bus, it would connect directly to the ZIP drive, otherwise it would use the converter.
(Basically worked by having a driver that encapsulates SCSI commands over parallel.)
I'm not aware of one that is cross-platform, though there is one for Linux called the "Linux Software Map."
The format includes the following fields:
Title
Version
Entered-date
Description
Keywords
Author
Maintained-by
Primary-site
Alternate-site
Original-site
Platforms
Copying-policy
Given that there is a platform field, despite it being refered to as the *Linux* Software Map, this does qualify on most of the criteria that you mentioned.
Freshmeat, though not a format, is also a fairly comprehensive database of software which provides much the same information as you mentioned, including:
Title
Description
Author
Licence
Category
Download
Packages
Homepage
Changelog
Freshmeat, aside from providing updates on their site, also provide them via text files, which are suitable for simple automated parsing.
Though neither solution is entirely perfect, both are definitely close to what you're looking for.
What I would like to see is an SQL backend, with a simplified query engine on top of it that returns an XML formated document back. This would take care of the extensibility portion of it, as fields could be added to the backend and XML format, without breaking compatibility with the client.
Likewise, I would like the database to be available as a download so that mirrors could be created and/or alternative front-ends.
(E.g. The search functions of Freshmeat aren't always flexible enough for me to easily pinpoint what I am looking for. I would definitely prefer being able to download a snapshot of the database and run custom SQL queries locally.)
In any case, freshmeat and lsm are likely your best choices for the time being.
>But more often than not since the reality is that
>Winodws owns >80% of the market, a windows person
>will attempt to setup the mac and there ignorance
>will lead to an unstable Platform.
And more often that not, Apple claims that you the only setup their machine needs is to plug it in and turn it on. (There is no step three!:P)
Given that they market their platform as ideal to ignorant users, and most Mac zealots tout the fact that you don't need to be skilled to set one up, this claim seems VERY suspect.
Not to mention that my support days were spent supporting VARs, many of whom had only ever sold Macintosh.
>The error reported is IRQ Conflicts. I have
>personally worked on this for a long time. I have
>consulted "experts" with windows. The problems
>have never been solved, so I have to hack around
>the problems.
Congratulations. You're a rare case. I spent a year and a half on the general PC support line and got only ONE call with an IRQ conflict, out of around 80-100 a day.
Given the list of hardware, I'd guess its either an OS issue, a BIOS issue or broken hardware, rather than a dearth of interrupts.
>Then, on top of that I tried to hook up my new
>digital Camera through USB. What a joke. After
>calling the cameras tech support, they stated
>that I need to isolate the IRQ for the USB
>device. Well that is all well and good, but
>I seem to be out of IRQ positions. So basically I
>am trying to cram 10 pounds of crap into a 5
>pound bag. Nice...
Tech support being stupid is not a fault of PC hardware. One of the advantages of USB is that only the controller needs an interupt, not the device.
>And yes, some of us want the computer on our desk
>to be "cool" looking. We do not want to feel that
>the thing we just spent a pile of hard earned
>money is relegated to _under_ the desk. We want
>to show it off. Let people look at it.
Yes, but a supercomputer is hardly a desktop.
>Depends on what you are testing it against. If
>you are doing Photoshop/DV for a living, then the
>G4 is BETTER than an Athlon. Tests have shown
>this to be true. If you are doing other things,
>then the Athlon would be faster.
And those tests are of a piece of software which lacks optimization for the Athlon.
Given that we're dealing with a platform being used to run custom scientific applications though, it can be tuned for either processor.
Tests which bench optimized code vs optimized code show the Athlon to provide MUCH better performance at each processors current clock speeds.
>Again, I am paying a bit more for two things,
>both of which I prioritize over raw speed. I am
>paying for a Nice looking Box and an User
>Interface that is both pleasing to my eye and
>logical for _me_ to use.
When building a cluster, you'd be a fool to pay for a 'Nice Looking Box' over raw speed. The point of a Beowulf cluster is performance.
Likewise, the interface is a non point, as you will not be using these machines directly. If you want, build the control software on MacOS and have a ball.
>Considering My PC does not seem to want to work
>well at all, then I would have to disagree with
>the second part of your Sentence.
Your broken PC does not invalidate my experience with thousands of users and hundreds of PCs.
>Remember, other peoples Milage may vary from
>yours. Feel free to debate. Point out problems
>with the post. State your case, but when you make
>wide sweeping statements be able to back them up
>with Facts not religous war type hype crap.
Funny, thats what I thought I was responding to.:)
>Yes, standard PC hardware is cheaper- but with
>all of the options come support nightmares and
>driver conflicts that would drive the most stable
>person into the loony bin [what in the HELL is an
>IRQ, ANYWAY?!]- yes,
1. I've supported Macs, PCs, HP/9000s and Sparcs. Mac hardware is not any less a support nightmare than PCs.
2. Driver conflicts are going to be an OS issue.
3. The whole trying hand-setting IRQs issue was taken care of with PCI.
>not only is it aesthetically pleasing
Supercomputers are typically not build to be furniture.
>[arranged in a circle, they'd look quite
>eye-catching compared to the average beige boxen]
Which would be a waste of space and complicate administration for no good reason.
The more likely configuration is a bunch of 1U machines with a KVM switch.
>yon iMac currently goes for about 800$ at the
>minimum end.
And yon $800 iMac has a 350MHz G3. Considering even the brand new shiny G4s can't match an Athlon (or god forbit an Alpha) for performance, this is just *such* a great choice. Really.
>runs on a PPC chip [WAY cooler, far more stable,
>need I go on?]
Cooler? In terms of the chip running cooler, yes. This is one thing Motorolla got right.
Stable? You're full of shit. I'm an admin at a place with over fifty PC servers. Their uptimes don't make them seem unstable at all.
>It's the cheapest reliable computer package out
>there,
Macintoshes are FAR from cheap from a price/performance ratio persepective. Not to mention that PCs are *JUST AS RELIABLE*.
Not to mention that, in order to make the things reasonably compact (yes, floor space costs money) you have to rip them apart and likely void their warranties.
>and you're never going to have to worry about
>hardware driver conflicts or a thousand other
>setup nightmares common to the PC end of things.
Kindly stop talking out of your ass. It doesn't make for a pleasant debate.
>KDE is written in C++ and therefore KDE is more
>object oriented, more robust, more maintainable,
>more extensible and a better choice for a
>desktop.
Wow, you win the award for the most contrived non-sequiter of the year.
I'm getting sick of saying it, but GTK+ and GNOME are OBJECT ORIENTED. Every itsy bitsy widget in it.
As for robustness and maintainability, that is a function of the programmer, not the programming language. I've seen snippets of C++ that would make a Perl hacker blush.
Better choice for the desktop? I appreciate your offer to think for the rest of us, but its unecessary.
But why would 1384B (800 megaBITS) be sufficient when compared with AGP 8x (2 gigaBYTES)? Not to mention a future serial bus which will undoubtably be even faster?
"Gee, this technology only provides 2621 times the throughput. No need for that!"
>Do you realize that GNOME itself is the 1st
>successful software project based on Corba ?
No more than I realize that up is down and black is white. No offence, but that comment is asinine. Do you seriously believe that there would be over 50 available ORBs for a technology that had never been used successfully?
If you'd like to see some examples of where it IS used successfully, just go to the OMG homepage and follow the links.
>Why should a technology not produce any good
>results for over 10 years and then suddenly
>become worthwhile when an open source project
>starts to use it ?
See above, CORBA is a widely deployed, industry standard technology.
The only way you would be even remotely right is if you had said that GNOME was the first successful implementation of a DESKTOP ENVIRONMENT based on CORBA, which is true. But on the other hand, to my knowledge the only effort towards that end that has failed is KDE.
>Not just any Open Source project either but one
>with lots of backing and funding from everywhere.
And this is relevant how?
>You see Corba is broken. but only a little. In
>order to use it you must build something else on
>top that actually talks to your apps. Gnome usees
>Bonobo. KDE used Kom. Despite being built on the
>same technology they couldn't communicate with
>each other. Not even when Gnome used the same ORB
>as KDE ( Mico ).
You see TCP/IP is broken, but only a little. In order to use it you must build something else on top that actually talks to your apps....
See how stupid that sounds?
>This is the power of the Hacker mentality at
>work. They took a broken twisted pile of junk and
>built a wonderful interface on top of that.
Okay, why exactly is CORBA a "broken twisted pile of junk"? Real arguments please, not complaints from KDE hackers that they couldn't make it work.
>Best of all being Corba makes it 100% buzzword
>compliant.
Well look here, we got us another completely non-techinical argument.
If you want to see a discussion about the advantages of CORBA over a proprietary solution, such as COM or Kparts, look on the KDE list around September, when the decision to drop CORBA as the embedding technology was first made. Hint - it was not universally accepted as "the right decision".
>Read this post to asses how much of a "buzzword"
>it is.
Well, nice of you to provide some arguments, even if they weren't yours. Let's take a look
>Whenever a performant and lightweight
>communication is required, shared library
>components, languange dependend and toolkit
>dependend, are chosen (in KDE).
Whenever performance and lightweight communication is required in Gnome, language and toolkit independence are still maintained by use of an ORB that allows for using a shared library approach for local objects.
>Noone is going to embed a remote spreadsheet
>document into a word document, running on a
>machine on the other side of the ocean. This is a
>nice dream and it is certainly technically
>interesting (no doubt about that), but it is not
>what the average desktop user really wants.
Maybe not across the ocean, but what about across the office, or from ASP to consumer.
Also, what do you mean by the "average desktop user"? Someone on a PC in a home or business?
What about the benefits of a network transparent component model when dealing with internet appliances or thin clients?
And note that after saying that the mythical average user doesn't want this, he immediately gives an example of where it does make sense
>Here language independence and network
>transparency have priority, no doubt. And that's
>why KDE uses DCOP (based on the standard ICE
>library)
Standard here needs to be defined as standard only on X11 implementations on MOST Unixes.
So you can forget about using this standard for interoperability with Windows, Mac, BeOS, etc. You can forget about it for handhelds. You can forget about it for alternate Unix windowing systems.
But wait, they have a solution for that as well! XML-RPC layered on top of DCOP layered on top of libICE.
Now mind you, the base XML-RPC spec is an XML description of an interface sent via HTTP. On top of that there are consideration of nameservices, authentication, encryption, interoperability (only four xml-rpc implementations have been validated as interoperable), etc, etc.
>In the Windows world Microsoft defined COM as
>standard. Who/Which/What defined CORBA as
>"standard" in the Unix world?
The 800+ membergs of OMG and all the companies that built their infrastructure on it? Like many of the standards in the Unix world, it is through industry adoption that CORBA has arisen.
Also, it is a misnomer to say that CORBA is a "Unix" standard, as it is a cross-platform, cross-language standard. It is used in a number of enterprises to tie together heterogenous environments.
In closing, get a clue. Though KDE official documentation and some of the developers like to bad mouth CORBA as a technology, it is proven, mature and widely available. And GNOME shows that it can be used as an effective foundation for a desktop.
>>You seem to be falling into the trap, though, of
>>thinking that gtk+ isn't object oriented just
>>because it's written in C. In fact, it is.
>I am not falling into a trap, because I know that
>C is not object-oriented!. There are 4 commonly
>accepted tenets required for a language to be
>object-oriented:
You *are* falling into a trap. And you're not paying attention to what you are being told; i.e. GTK+ is object-oriented. Note, GTK+, not C.
The fact of the matter is that an object-oriented language is one that has/syntax/ to support the features you mentioned (abstraction, encapsulation, etc). This does not mean that those features cannot be implemented in a language that does not support it explicitely.
>Abstraction - Simply the model in question, i.e.,
>make it more abstract to simply the building of
>the model.
GTK+ does this.
>Encapsulation - Hide the implementation details.
>As the user of a class, you don't have to worry
>about how it works, you just use it
GTK+ does this too.
>Inheritance - The ability to reuse components.
>(collary is 'polymorphism')
GTK+ does this too.
>Messaging - Components use messages to
>communicate. Passing data around to functions
>does not consitute a message, BTW.
GTK+ propogates events and associated data through signals.
>I think you will agree that C only supports
>Abstraction. Thus, it is not object-oriented.
And noone was arguing that is was.
>In addition, your example of 'reuse' of the
>gtk_menu_new() is not actually reuse because I
>cannot (in C) create a derived class
>johanns_gtk_menu_new() and inherit the functions
>from gtk_menu_new().
Wow, amazing that I've been programming things for years that "can't" be done. Of course you can make a derived class of GtkMenu.
In fact, GtkMenu is derived from GtkMenuShell, which is derived from GtkContainter, which is derived from GtkWidget, which is derived fro GtkObject.
Re:GNOME vs KDE Episode 18: Pointlessness
on
KDE Strikes Back
·
· Score: 1
>double-clicking a taskbar icon will iconify that
>application. great for getting stuff out of your
>way.
Gnome does this with single-click.
>right-clicking a taskbar icon gives you a menu
>which includes 'iconify other windows', which is
>really handy since I usually have like 14
>Konsoles, 11 Netscapes, GAIM, XMMS, Quanta+ and
>StarOffice open simultaneously.
This is one Gnome doesn't have.
I personally never have more than a couple windows per virtual desktop, so I doubt I'd ever use this feature. But I can see how it might be useful.
>Alt-F2 brings up a little input field which I can
>use to start an app quicker than using the
>menus. It keeps a history too, so I can cycle
>through previous commands.
As it ships, this is the same key to call gnome-run. I like that Gnome allows you to define this, since I use ALT-F# for virtual desktops.
>Rotating desktop wallpapers. I have a directory
>of about 450 hi-color psychedelic 1024x768
>wallpapers, and I have KDE set to switch to
>a random one every 30 seconds. Keeps things
>interesting.
There are panel applets for this on Gnome. Don't recall the name off the top of my head.
>Right click on desktop gives you a menu which
>includes 'Logout'. I find that much easier to
>deal with than windows, which requires you
>to hit Ctrl-Alt-Del or click on the Start button.
Hrm. Don't think the Gnome file managers does this either. Another feature I don't miss because I'd never use it. (I don't log out.)
>So, I guess it's subtle things like that, that
>make me like KDE so much.
>For a growing number of Gnome projects, Helixcode
>now demands that contributors assign their
>copyright to them. This scares me. The only good
>reason for this demand is that Helixcode wants to
>be able to fork proprietary non-free versions.
First, this was brought up on the Gnome devel mailing list a week ago. After a day of discussion, the requirement was dropped.
Second, this wasn't on a "growing number of Gnome projects" - it was only on the Helix Setup tools.
Third, Miguel was upfront about the purpose being partially to allow releasing versions that were licenced with the MPL (another Open Source licence).
Fourth, there are other reasons for copyright assignment to a single entity. Remember, the FSF has been doing this since its inception in order to make legal protection easier.
>Has anyone noticed that back-up devices have
>always exceeded hard drive capacities by at
>least a factor of 2, but now with the new 75GB
>storage, you'll need at least 2 tapes to back-up
>everything.
Actually, this isn't quite true. Common formats available today, including Mammoth-2, AIT-2, 3590E and SLR100, have 50-60GB native capacity. And a large amount of the data out there will compress 2-3 times over, giving an effective capacity of 100-180GB per tape.
If that doesn't satisfy you, LTO drives are about to hit the market with a native capacity of 100GB to start, giving an effective capacity of up to 300GB, given highly compressable data. Plans are to scale the technology up to 800GB native over the next 3 generations.
Though not quite as close to market, Quantum has begun shipping evaluation SuperDLT drives to manufacturers, also with native capacities over 100GB.
So no, we don't have to worry about tape technology scaling to meet capacity QUITE yet.
>Now, to head off the inevitable "What about
>(insert cheezy tape system here)?" - I've used
>OnStream, etc. They fail to meet the designations
>of either fast or reliable. Not that I'm a big
>fan of DLT either, but DLT is a lot better.
There are some reasonable low-cost tape technologies out there.
My personal favourite is Ecrix, with their VXA-1 line of drives. Depending on the tape type, you can pack 12GB, 20GB or 33GB per tape native. Their reliability is VERY impressive. Transfer rates are reasonable at 3MB/sec native. And they're inexpensive - normally about $1000, but they have a deal for first time buyers where you can pick up a drive for $400.
There's also DDS-4, which is reasonably reliable. Capacity of 20GB native. Transfer rates of 3MB/sec. And fairly inexpensive, about $800.
And it doesn't involve backing up to hard disk.:)
Re:Good luck, maybe you can set Hollywood straight
on
Computer Historian?
·
· Score: 1
>Good luck getting a job like that, but maybe you >can set Hollywood straight. Such things like
>
>Big spinning 9 track tapes have been obsolete for
>years (The X-files had the sense to use DAT).
But a lot of companies still use them regardless.
Back when I worked at a major computer distributor, I got a lot of calls for old 7, 9 and 21 track tapes. And I wasn't even working on the storage line.
>The rows and rows of blinking lights have move to
>the server rooms, and are no longer on the front
>of the computer.
Well, I'll give you this, but I love blinkenlights.:)
>Everything is done with windowing systems, you
>don't look up a driver's license with a command
>line anymore (except maybe in a cop car).
This is just plain wrong.
I got a lot of first hand experience in this during my stint in support. Not only are old systems still running, but a lot of new terminal systems are being in production.
Among the common appications are law enforcement databases, medical databases, accounting systems, warehouse systems, point of sale terminals, banking systems, airline reservation systems, etc, etc.
Terminals are the original "thin client". They are basically throw-away boxes with little to no configuration that can be centerally managed.
>Nope, but eazel can sell their services from a
>much better position than other competing
>companies with their filemanager being default --
>which is unfair to say the least...
They are developing but one component of the desktop.
Now call me silly, but I find the distributions MUCH more likely to be who end-users turn to for support. Or even OEMS.
And as the source is GPLed, the folks at Eazel do not have the "its us or nothing" for support even on the back-end of the support structure.
Unlike traditional multi-tier support, where end users have contracts with VARs and ISVs, who have contracts with distribution, who have contracts with the vendor, it is far from unlikely to short circuit this process and just do support directly for the product internally.
>As forking would mean coding against dozens of
>other company-driven developers forking only
>works in theory. Nobody except for your mom would
>be interested in your fork...
And this is different from Open Source development how?
The fact of the matter, the only reason there would be to fork would be if the maintainer (be it person or company) was doing an inadequate job. This is no different that Open source.
>Hint: Then why are core-developers on the
>gnome-foundation-mailinglist so concerned on
>lacking company-independent developers right
>now???????
Odd, I read it as a discussion as how to safeguard against it in the future. Kind of like buying health insurance even though you're not currently sick.
Take note of the charter:
"The membership will be populated with all the
consenting members of the gnome-hackers mailing
list, people holding CVS accounts, and anyone
else who speaks out and wants to join when
asked."
So far I haven't seen any major concern on the main Gnome lists. Most of it has been KDE advocates slinging around rumours of Gnome being commercialized, overhyped, yadda yadda yadda.
Aside from that, about the only thing I've seen on the lists are complaints about press releases from some of the new memers and articles not making it clear that the community *is* very much a part of the foundation.
>BTW: you should stop reading those Q&A-FAQs. They
>are bad for your health:
BTW: you should stop making completely ad hominum arguments. They're bad for your credibility.
Slashdot Mirror
* The threading vs. processes was indeed my bad. :)
Since I have no idea why I said one when I
meant the other.
* No, those numbers are meaningless unless more
background is given. What backend are they
using? What proportion of selects to inserts?
Are they simple or complex queries? How big
are the tables? What operating system and
hardware platform are they running on?
The "numbers speak for themselves" arguments
rank only below the "we lack all these features,
but you shouldn't use them anyways, and besides,
we're planning them in the next few major
release" arguments in sullying the reputation
of MySQL in a lot of people's eyes.
* Unless your website is publishing false
information, you're wrong about locking on
MyISAM tables. I quote, "Currently MySQL only
supports table locking for ISAM/MyISAM and HEAP
tables and page level locking for BDB tables."
* MVCC has been part of Postgresql since June
1999; InnoDB was originally interfaced with
MySQL September 2000 and made part of the
mainstream distribution March 2001.
Likewise, MVCC is the locking backend for EVERY
Postgres installation, whereas InnoDB likely
constitutes a small portion of MySQL installs.
Guess which one has proven itself in production
environments?
* Again with the "usually". Your statement is
meaningless and only serves to discredit your
repute if you don't give at least some context.
Yes, MySQL *can* be up to 100 times faster; it
can also curl up in a little ball and cry like
a little girl under loads that Postgres and
other more featureful databases would handle
gracefully.
No, not every database is suited for every
application, but as I pointed out in my
original comment, there are very few instances
I can see where MySQL makes a better choice.
The lack of a robust implementation of ANSI
SQL make anything but trivial database schema
painful to implement and typically requires
reimplementing the missing features in each and
every piece of client code. Though the latest
release of MySQL adds many missing features,
most of them are in table backends that are
not widely adopted and thus lack rigorous
testing (and I'm not talking about a simple
regression test).
The main complain is the lack of fine-grained
locking, which makes most common usage patterns
(save data warehousing, which someone was kind
enough to reminds me of) perform worse as
access grows. This very real limit on practical
scalability makes theoretical performance edge
nigh meaningless in many situations.
* If you'll re-read my comments on the benchmark
on the InnoDB site, the complaint about the
Postgres test was not that it was missing
instructions for recreating the results, but
that the ONLY comparison was on select speed,
single client.
However, my issue with the test against a
"market-leading database" was in fact a matter
of them using different methedology for testing
each database, and only publishing the perl
code for the InnoDB test:
"Source code of tests for InnoDB is included
at the end of this email. Note that the tests
were not run in exactly the same way for the
other database."
* Regardless of whether its hard to write
benchmarks that cover concurrent access or not,
it doesn't change the fact that what is
currently published on the MySQL website is
nothing more than marketing material. To recap
a previous analogy, its like choosing a sports
car over a pick-up truck for hauling on the
basis that the sports car goes REALLY fast
when carrying a single two by four.
* I've read innumerable comparisons between
Postgres and MySQL. Not to mention having a
fair amount of experience with both in a
production environment.
It was, in fact, my research and the limitations
and poor performance I have experienced with
MySQL in a large-scale deployment that have
formed my opinions on the matter.
Given that one of my "simple faults" was a slip
of the tongue and another is backed up by
published material on your own website,
coupled with your failure to adequately
address my "opinions", you might want to
reconsider the condescending tone you chose
to take in the first paragraph of your
response.
>I played with Postgres again recently, and
>realized that because it (proudly) supports
>transactions and integrity constraints, I expect
>it to support a reasonable subset of SQL92. And
>yet, no subselects. And other annoying omissions
>I've forgotten.
Maybe what you forgot to do is actually look at the feature list and/or try using the features you think are missing. Postgresql supported sub-selects even in the 6.X series.
Matt
If you take a close look at the benchmarking on the InnoDB site, you'll notice their comparison against Postgresql is only measuring speeds with a since query running against the database. Likewise for their MyISAM vs. InnoDB test, and their MySQL vs "market-leading database test".
So all of these suffer from the same thing that the default MySQL benchmarks do - they're meaningless save for marketing. There are very few real world applications that are going to have serialized queries, and those that do are likely not going to require a lot of raw speed.
If you'll notice, the only test that they use multiple connections with is their scalability test, in which they make no comparison to other databases, and that showed performance dropping sharply on selects after 50 clients, and didn't even bother giving performance on more than 20 for inserts (I'd be interested in knowing whether they were just embarassing or if the server actually crashed).
And none of the tests include a mixed load of selects and inserts. And they flat out admit their methodology was different for MySQL and the contender in one test. And they ran all of it on a single server. And none of the tests include large tables, joins, transactions, sub-selects, etc, etc. The number of faults with their benchmarks are innumerable.
Part of the beauty of the newer releases of Postgresql (aside from the improvements to the query optimizer) is their new "no-locking" MVCC (Multi Version Concurrency Control) system. Selects NEVER block inserts and vice versa.
This is a _huge_ win in terms of performance in real world situations; coupled with the row (or even cell level) locking pretty much guarante better scalability than MySQL, even if running a table type that supports finer grain locking (I believe the best they do right now is page level).
I like to think of MySQL as a sports car. It'll get to zero to sixty faster than an 18-wheel truck. But if you try to put any load on it, it won't even more.
(Note - the company I work for uses MySQL for a large production database. And it has worked even for a fairly large database under a somewhat heavy load. However, it is performing adequately, not well. And there are a lot of things we simply CANNOT do (e.g. a large query against the database for statistics purposes, since the select would lock all inserts and deadlock the database. Even under normal load its not uncommon for us to see 20-30 selects locked waiting for an insert to complete).
And to be honest, even if MySQL performed half as well as their documentation implied, I find the lack of features like sub selects, select into table, transactions (under the heavily tested table types), stored procedures, triggers, foreign keys and views make it a waste of my time and a waste of the programmers time.
We have dozens of programs and scripts that all have to access the database and they all have to work around the deficiencies in MySQLs capabilities. And, to be honest, not every attempt to do so is ultimately successful, resulting in hours wasted doing cleanup work (when it actually CAN be done without killing the database.).
I don't begrudge other people their preferences, but it would take a LOT of improvement and real benchmarks to convince me MySQL is a better database.
Matt
Well, once and for all it is indisputable that bare lfs in a message body are forbidden.
In particular, LSMTP until recently allowed them. In fact me and several employees of L-Soft got into a pissing match over the matter when a large mailing list started flooding our servers with something on the order of 4 million SMTP connections a day using their software. Their argument was that, since it was only an Internet Draft and the RFCs only RECOMMENDED bare LFs be filtered, they were perfectly justified in not fixing the issue.
>
/bin/grep: Argument list too long
./waters.roger/Bring_the_Boys_Back_Home
./shakespears.sister/_Hello_(Turn_Your_Radio_On)
./pink.floyd/Is_there_anybody_out_there?
/bin/ls | xargs grep "foo"
.: directory
./Roger_Waters-It's_a_Miracle.mp3: symbolic link
../../.mp3/3155
/bin/ls | xargs -i grep "foo" {}
Main Entry: pedant
obsolete : a male schoolteacher
2 a : one who makes a show of knowledge b : one
who is unimaginative or who unduly emphasizes
minutiae in the presentation or use of knowledge
c: a formalist or precisionist in teaching
Which one of these applies exactly? Because your post is incorrect.
>Your commandline does not solve the problem that
>the original invocation of xargs was intended to
>solve - passing a *huge* number of files to grep
>on the commandline (grep * in a directory with a
>ton of files) causes it to break.
Actually, it *does* solve the issue that xargs was intended to solve - shells have finite (often 100 or 255 character) commandline buffers.
For example:
bash-2.04$ find . -type f | wc -l
35416
bash-2.04$ grep -il "is there anybody out \
there" `find -type f`
bash:
bash-2.04$ find . -type f -print0 | xargs -0 \
grep -il "is there anybody out there"
I've done this on Linux, Solaris, OpenBSD, HP/UX, Openserver and Unixware without any problems.
> $
> is the equivilant to
> $ grep "foo" `/bin/ls`
This is almost, but not quite true.
First difference is that `/bin/ls` will be executed and substituted into the commandline buffer of the shell you're using, thus giving the possibility of an overrun.
The second difference is that you don't have to worry about escaping out special characters when using the backtick operators, but you do when using xargs.
For example, I have a directory containing a file with a single quote in its name. So this happens:
bash-2.04$ ls | xargs file
xargs: unmatched single quote
To work around this, its usually much better to use find.
bash-2.04$ find . -print0 | xargs -0 file
to
You brought up syntax like:
> $
This is mostly for cases where you need to repeat a command with a series of arguments, but again where the argument would be too long.
It is roughly equivilent to
for I in `/bin/ls`; do $I; done
Matt
10 watts may not make not make or break your air conditioner, but how many server rooms have a single machine? The company I work for currently has 112 dual processor servers.
The "10 watt difference" suddenly is 537.6kwh/day, or 193536kwh/year.
Even if you look at that in terms of just how much the electricity itself costs, we'd be paying $27,095.04 more a year if we were using (the currently non-existent) dual athlon boxen.
>I think this whole "they project each frame
>multiple times" thing is some weird urban
>legend...
Sorry, but speculation does not make fact. If you bother to go to the rec.arts.movie.tech FAQ, they refer to how the use of a double-bladed shutter does in fact cause each frame to be shown twice.
The issue of the matter is how the human eye percieves light. By cutting the display time in half, even if it is the same image, the eye percieves change, thereby creating an optical illusion that cuts down on the perception of the actual jerkiness of the changing images.
As I am not disciplined in this field, I did not retain the information on this particularly well. However I have come across a large number of sites backing this up. (Mostly stumbled across when looking into HDTV and progressive scan video technology).
Matt
>Instead I get a bunch of CDs that are now
>useless.
By that definition of useless, EVERY data CD is useless. There is no such thing as a bug-free release of any piece of software.
>Oh I guess I could install RH 7.0 and then
>download a million patches.
Oh you poor thing. You have to type 'up2date' at the console.
>Service packs are a great idea because you can
>consolidate all of the fixes into a comprehensive
>unit and thus you can tell people, my software
>will work on Redhat 7.0 service pack 3
I have to agree with you on this one. The concept of a service pack or a patch bundle is usefull at times.
However, patches SHOULD be made available as soon as there is one, and should continue to be available individually.
I don't know how many times during my stint as a support person I ran into a service pack or patch bundle that broke other things that were working fine.
Matt
>"Speaking of USB scanners, what the hell was that
>on the SuSE website about XFree86 4.0 supporting
>scanners on parallel ports???"
This is an easy one. Scanners with parallel port interfaces. Before USB became prevelant in 98-99, the two major interface types for scanners were either SCSI or parallel.
>I honestly don't know; this seems to defy logic.
>I would assume that this works out for a DB-25
>connector, but aren't the pinouts for the SCSI
>DB-25 and the Parallel DB-25 totally different?
Yes, they are. In fact, they're different signalling types, so they can't even be compared on a pin for pin basis.
>Maybe not, because Iomega's Zip Plus actually
>autodetected whether the connection was parallel
>or SCSI. But an LPT controller used as a SCSI
>device? This is making my head spin!
The Zip Plus actually had a built in parallel to SCSI converter built in. If you pluged into a real SCSI bus, it would connect directly to the ZIP drive, otherwise it would use the converter.
(Basically worked by having a driver that encapsulates SCSI commands over parallel.)
>Heh, and how many of those 40,000 clients are
>bots? It's amazing how many bots you need now
>just to hold a channel.
How about none? I'm a regular on one of the original IRC channels on EFNET and we haven't had a bot protecting the channel for years.
>Well, freshmeat has it's appindex as text here:
:) Doesn't have the more lenghty descriptions, but I think I can live with that.
>freshmeat.net/backend/
I showhow didn't notice that
Thanks.
I'm not aware of one that is cross-platform, though there is one for Linux called the "Linux Software Map."
The format includes the following fields:
Title
Version
Entered-date
Description
Keywords
Author
Maintained-by
Primary-site
Alternate-site
Original-site
Platforms
Copying-policy
Given that there is a platform field, despite it being refered to as the *Linux* Software Map, this does qualify on most of the criteria that you mentioned.
Freshmeat, though not a format, is also a fairly comprehensive database of software which provides much the same information as you mentioned, including:
Title
Description
Author
Licence
Category
Download
Packages
Homepage
Changelog
Freshmeat, aside from providing updates on their site, also provide them via text files, which are suitable for simple automated parsing.
Though neither solution is entirely perfect, both are definitely close to what you're looking for.
What I would like to see is an SQL backend, with a simplified query engine on top of it that returns an XML formated document back. This would take care of the extensibility portion of it, as fields could be added to the backend and XML format, without breaking compatibility with the client.
Likewise, I would like the database to be available as a download so that mirrors could be created and/or alternative front-ends.
(E.g. The search functions of Freshmeat aren't always flexible enough for me to easily pinpoint what I am looking for. I would definitely prefer being able to download a snapshot of the database and run custom SQL queries locally.)
In any case, freshmeat and lsm are likely your best choices for the time being.
>But more often than not since the reality is that
:P)
:)
>Winodws owns >80% of the market, a windows person
>will attempt to setup the mac and there ignorance
>will lead to an unstable Platform.
And more often that not, Apple claims that you the only setup their machine needs is to plug it in and turn it on. (There is no step three!
Given that they market their platform as ideal to ignorant users, and most Mac zealots tout the fact that you don't need to be skilled to set one up, this claim seems VERY suspect.
Not to mention that my support days were spent supporting VARs, many of whom had only ever sold Macintosh.
>The error reported is IRQ Conflicts. I have
>personally worked on this for a long time. I have
>consulted "experts" with windows. The problems
>have never been solved, so I have to hack around
>the problems.
Congratulations. You're a rare case. I spent a year and a half on the general PC support line and got only ONE call with an IRQ conflict, out of around 80-100 a day.
Given the list of hardware, I'd guess its either an OS issue, a BIOS issue or broken hardware, rather than a dearth of interrupts.
>Then, on top of that I tried to hook up my new
>digital Camera through USB. What a joke. After
>calling the cameras tech support, they stated
>that I need to isolate the IRQ for the USB
>device. Well that is all well and good, but
>I seem to be out of IRQ positions. So basically I
>am trying to cram 10 pounds of crap into a 5
>pound bag. Nice...
Tech support being stupid is not a fault of PC hardware. One of the advantages of USB is that only the controller needs an interupt, not the device.
>And yes, some of us want the computer on our desk
>to be "cool" looking. We do not want to feel that
>the thing we just spent a pile of hard earned
>money is relegated to _under_ the desk. We want
>to show it off. Let people look at it.
Yes, but a supercomputer is hardly a desktop.
>Depends on what you are testing it against. If
>you are doing Photoshop/DV for a living, then the
>G4 is BETTER than an Athlon. Tests have shown
>this to be true. If you are doing other things,
>then the Athlon would be faster.
And those tests are of a piece of software which lacks optimization for the Athlon.
Given that we're dealing with a platform being used to run custom scientific applications though, it can be tuned for either processor.
Tests which bench optimized code vs optimized code show the Athlon to provide MUCH better performance at each processors current clock speeds.
>Again, I am paying a bit more for two things,
>both of which I prioritize over raw speed. I am
>paying for a Nice looking Box and an User
>Interface that is both pleasing to my eye and
>logical for _me_ to use.
When building a cluster, you'd be a fool to pay for a 'Nice Looking Box' over raw speed. The point of a Beowulf cluster is performance.
Likewise, the interface is a non point, as you will not be using these machines directly. If you want, build the control software on MacOS and have a ball.
>Considering My PC does not seem to want to work
>well at all, then I would have to disagree with
>the second part of your Sentence.
Your broken PC does not invalidate my experience with thousands of users and hundreds of PCs.
>Remember, other peoples Milage may vary from
>yours. Feel free to debate. Point out problems
>with the post. State your case, but when you make
>wide sweeping statements be able to back them up
>with Facts not religous war type hype crap.
Funny, thats what I thought I was responding to.
>Yes, standard PC hardware is cheaper- but with
>all of the options come support nightmares and
>driver conflicts that would drive the most stable
>person into the loony bin [what in the HELL is an
>IRQ, ANYWAY?!]- yes,
1. I've supported Macs, PCs, HP/9000s and Sparcs. Mac hardware is not any less a support nightmare than PCs.
2. Driver conflicts are going to be an OS issue.
3. The whole trying hand-setting IRQs issue was taken care of with PCI.
>not only is it aesthetically pleasing
Supercomputers are typically not build to be furniture.
>[arranged in a circle, they'd look quite
>eye-catching compared to the average beige boxen]
Which would be a waste of space and complicate administration for no good reason.
The more likely configuration is a bunch of 1U machines with a KVM switch.
>yon iMac currently goes for about 800$ at the
>minimum end.
And yon $800 iMac has a 350MHz G3. Considering even the brand new shiny G4s can't match an Athlon (or god forbit an Alpha) for performance, this is just *such* a great choice. Really.
>runs on a PPC chip [WAY cooler, far more stable,
>need I go on?]
Cooler? In terms of the chip running cooler, yes. This is one thing Motorolla got right.
Stable? You're full of shit. I'm an admin at a place with over fifty PC servers. Their uptimes don't make them seem unstable at all.
>It's the cheapest reliable computer package out
>there,
Macintoshes are FAR from cheap from a price/performance ratio persepective. Not to mention that PCs are *JUST AS RELIABLE*.
Not to mention that, in order to make the things reasonably compact (yes, floor space costs money) you have to rip them apart and likely void their warranties.
>and you're never going to have to worry about
>hardware driver conflicts or a thousand other
>setup nightmares common to the PC end of things.
Kindly stop talking out of your ass. It doesn't make for a pleasant debate.
>KDE is written in C++ and therefore KDE is more
>object oriented, more robust, more maintainable,
>more extensible and a better choice for a
>desktop.
Wow, you win the award for the most contrived non-sequiter of the year.
I'm getting sick of saying it, but GTK+ and GNOME are OBJECT ORIENTED. Every itsy bitsy widget in it.
As for robustness and maintainability, that is a function of the programmer, not the programming language. I've seen snippets of C++ that would make a Perl hacker blush.
Better choice for the desktop? I appreciate your offer to think for the rest of us, but its unecessary.
Matt
Erm. I honestly don't know where the hell I got that number. Twenty times faster. Duh.
But why would 1384B (800 megaBITS) be sufficient when compared with AGP 8x (2 gigaBYTES)? Not to mention a future serial bus which will undoubtably be even faster?
"Gee, this technology only provides 2621 times the throughput. No need for that!"
>Do you realize that GNOME itself is the 1st
>successful software project based on Corba ?
No more than I realize that up is down and black is white. No offence, but that comment is asinine. Do you seriously believe that there would be over 50 available ORBs for a technology that had never been used successfully?
If you'd like to see some examples of where it IS used successfully, just go to the OMG homepage and follow the links.
>Why should a technology not produce any good
>results for over 10 years and then suddenly
>become worthwhile when an open source project
>starts to use it ?
See above, CORBA is a widely deployed, industry standard technology.
The only way you would be even remotely right is if you had said that GNOME was the first successful implementation of a DESKTOP ENVIRONMENT based on CORBA, which is true. But on the other hand, to my knowledge the only effort towards that end that has failed is KDE.
>Not just any Open Source project either but one
>with lots of backing and funding from everywhere.
And this is relevant how?
>You see Corba is broken. but only a little. In
>order to use it you must build something else on
>top that actually talks to your apps. Gnome usees
>Bonobo. KDE used Kom. Despite being built on the
>same technology they couldn't communicate with
>each other. Not even when Gnome used the same ORB
>as KDE ( Mico ).
You see TCP/IP is broken, but only a little. In order to use it you must build something else on top that actually talks to your apps....
See how stupid that sounds?
>This is the power of the Hacker mentality at
>work. They took a broken twisted pile of junk and
>built a wonderful interface on top of that.
Okay, why exactly is CORBA a "broken twisted pile of junk"? Real arguments please, not complaints from KDE hackers that they couldn't make it work.
>Best of all being Corba makes it 100% buzzword
>compliant.
Well look here, we got us another completely non-techinical argument.
If you want to see a discussion about the advantages of CORBA over a proprietary solution, such as COM or Kparts, look on the KDE list around September, when the decision to drop CORBA as the embedding technology was first made. Hint - it was not universally accepted as "the right decision".
>Read this post to asses how much of a "buzzword"
>it is.
Well, nice of you to provide some arguments, even if they weren't yours. Let's take a look
>Whenever a performant and lightweight
>communication is required, shared library
>components, languange dependend and toolkit
>dependend, are chosen (in KDE).
Whenever performance and lightweight communication is required in Gnome, language and toolkit independence are still maintained by use of an ORB that allows for using a shared library approach for local objects.
>Noone is going to embed a remote spreadsheet
>document into a word document, running on a
>machine on the other side of the ocean. This is a
>nice dream and it is certainly technically
>interesting (no doubt about that), but it is not
>what the average desktop user really wants.
Maybe not across the ocean, but what about across the office, or from ASP to consumer.
Also, what do you mean by the "average desktop user"? Someone on a PC in a home or business?
What about the benefits of a network transparent component model when dealing with internet appliances or thin clients?
And note that after saying that the mythical average user doesn't want this, he immediately gives an example of where it does make sense
>Here language independence and network
>transparency have priority, no doubt. And that's
>why KDE uses DCOP (based on the standard ICE
>library)
Standard here needs to be defined as standard only on X11 implementations on MOST Unixes.
So you can forget about using this standard for interoperability with Windows, Mac, BeOS, etc. You can forget about it for handhelds. You can forget about it for alternate Unix windowing systems.
But wait, they have a solution for that as well! XML-RPC layered on top of DCOP layered on top of libICE.
Now mind you, the base XML-RPC spec is an XML description of an interface sent via HTTP. On top of that there are consideration of nameservices, authentication, encryption, interoperability (only four xml-rpc implementations have been validated as interoperable), etc, etc.
>In the Windows world Microsoft defined COM as
>standard. Who/Which/What defined CORBA as
>"standard" in the Unix world?
The 800+ membergs of OMG and all the companies that built their infrastructure on it? Like many of the standards in the Unix world, it is through industry adoption that CORBA has arisen.
Also, it is a misnomer to say that CORBA is a "Unix" standard, as it is a cross-platform, cross-language standard. It is used in a number of enterprises to tie together heterogenous environments.
In closing, get a clue. Though KDE official documentation and some of the developers like to bad mouth CORBA as a technology, it is proven, mature and widely available. And GNOME shows that it can be used as an effective foundation for a desktop.
>>You seem to be falling into the trap, though, of
/syntax/ to support the features you mentioned (abstraction, encapsulation, etc). This does not mean that those features cannot be implemented in a language that does not support it explicitely.
>>thinking that gtk+ isn't object oriented just
>>because it's written in C. In fact, it is.
>I am not falling into a trap, because I know that
>C is not object-oriented!. There are 4 commonly
>accepted tenets required for a language to be
>object-oriented:
You *are* falling into a trap. And you're not paying attention to what you are being told; i.e. GTK+ is object-oriented. Note, GTK+, not C.
The fact of the matter is that an object-oriented language is one that has
>Abstraction - Simply the model in question, i.e.,
>make it more abstract to simply the building of
>the model.
GTK+ does this.
>Encapsulation - Hide the implementation details.
>As the user of a class, you don't have to worry
>about how it works, you just use it
GTK+ does this too.
>Inheritance - The ability to reuse components.
>(collary is 'polymorphism')
GTK+ does this too.
>Messaging - Components use messages to
>communicate. Passing data around to functions
>does not consitute a message, BTW.
GTK+ propogates events and associated data through signals.
>I think you will agree that C only supports
>Abstraction. Thus, it is not object-oriented.
And noone was arguing that is was.
>In addition, your example of 'reuse' of the
>gtk_menu_new() is not actually reuse because I
>cannot (in C) create a derived class
>johanns_gtk_menu_new() and inherit the functions
>from gtk_menu_new().
Wow, amazing that I've been programming things for years that "can't" be done. Of course you can make a derived class of GtkMenu.
In fact, GtkMenu is derived from GtkMenuShell, which is derived from GtkContainter, which is derived from GtkWidget, which is derived fro GtkObject.
>double-clicking a taskbar icon will iconify that
>application. great for getting stuff out of your
>way.
Gnome does this with single-click.
>right-clicking a taskbar icon gives you a menu
>which includes 'iconify other windows', which is
>really handy since I usually have like 14
>Konsoles, 11 Netscapes, GAIM, XMMS, Quanta+ and
>StarOffice open simultaneously.
This is one Gnome doesn't have.
I personally never have more than a couple windows per virtual desktop, so I doubt I'd ever use this feature. But I can see how it might be useful.
>Alt-F2 brings up a little input field which I can
>use to start an app quicker than using the
>menus. It keeps a history too, so I can cycle
>through previous commands.
As it ships, this is the same key to call gnome-run. I like that Gnome allows you to define this, since I use ALT-F# for virtual desktops.
>Rotating desktop wallpapers. I have a directory
>of about 450 hi-color psychedelic 1024x768
>wallpapers, and I have KDE set to switch to
>a random one every 30 seconds. Keeps things
>interesting.
There are panel applets for this on Gnome. Don't recall the name off the top of my head.
>Right click on desktop gives you a menu which
>includes 'Logout'. I find that much easier to
>deal with than windows, which requires you
>to hit Ctrl-Alt-Del or click on the Start button.
Hrm. Don't think the Gnome file managers does this either. Another feature I don't miss because I'd never use it. (I don't log out.)
>So, I guess it's subtle things like that, that
>make me like KDE so much.
>For a growing number of Gnome projects, Helixcode
>now demands that contributors assign their
>copyright to them. This scares me. The only good
>reason for this demand is that Helixcode wants to
>be able to fork proprietary non-free versions.
First, this was brought up on the Gnome devel mailing list a week ago. After a day of discussion, the requirement was dropped.
Second, this wasn't on a "growing number of Gnome projects" - it was only on the Helix Setup tools.
Third, Miguel was upfront about the purpose being partially to allow releasing versions that were licenced with the MPL (another Open Source licence).
Fourth, there are other reasons for copyright assignment to a single entity. Remember, the FSF has been doing this since its inception in order to make legal protection easier.
>Has anyone noticed that back-up devices have
>always exceeded hard drive capacities by at
>least a factor of 2, but now with the new 75GB
>storage, you'll need at least 2 tapes to back-up
>everything.
Actually, this isn't quite true. Common formats available today, including Mammoth-2, AIT-2, 3590E and SLR100, have 50-60GB native capacity. And a large amount of the data out there will compress 2-3 times over, giving an effective capacity of 100-180GB per tape.
If that doesn't satisfy you, LTO drives are about to hit the market with a native capacity of 100GB to start, giving an effective capacity of up to 300GB, given highly compressable data. Plans are to scale the technology up to 800GB native over the next 3 generations.
Though not quite as close to market, Quantum has begun shipping evaluation SuperDLT drives to manufacturers, also with native capacities over 100GB.
So no, we don't have to worry about tape technology scaling to meet capacity QUITE yet.
>Now, to head off the inevitable "What about
:)
>(insert cheezy tape system here)?" - I've used
>OnStream, etc. They fail to meet the designations
>of either fast or reliable. Not that I'm a big
>fan of DLT either, but DLT is a lot better.
There are some reasonable low-cost tape technologies out there.
My personal favourite is Ecrix, with their VXA-1 line of drives. Depending on the tape type, you can pack 12GB, 20GB or 33GB per tape native. Their reliability is VERY impressive. Transfer rates are reasonable at 3MB/sec native. And they're inexpensive - normally about $1000, but they have a deal for first time buyers where you can pick up a drive for $400.
There's also DDS-4, which is reasonably reliable. Capacity of 20GB native. Transfer rates of 3MB/sec. And fairly inexpensive, about $800.
And it doesn't involve backing up to hard disk.
>Good luck getting a job like that, but maybe you >can set Hollywood straight. Such things like
:)
>
>Big spinning 9 track tapes have been obsolete for
>years (The X-files had the sense to use DAT).
But a lot of companies still use them regardless.
Back when I worked at a major computer distributor, I got a lot of calls for old 7, 9 and 21 track tapes. And I wasn't even working on the storage line.
>The rows and rows of blinking lights have move to
>the server rooms, and are no longer on the front
>of the computer.
Well, I'll give you this, but I love blinkenlights.
>Everything is done with windowing systems, you
>don't look up a driver's license with a command
>line anymore (except maybe in a cop car).
This is just plain wrong.
I got a lot of first hand experience in this during my stint in support. Not only are old systems still running, but a lot of new terminal systems are being in production.
Among the common appications are law enforcement databases, medical databases, accounting systems, warehouse systems, point of sale terminals, banking systems, airline reservation systems, etc, etc.
Terminals are the original "thin client". They are basically throw-away boxes with little to no configuration that can be centerally managed.
>Nope, but eazel can sell their services from a ...
...
>much better position than other competing
>companies with their filemanager being default --
>which is unfair to say the least
They are developing but one component of the desktop.
Now call me silly, but I find the distributions MUCH more likely to be who end-users turn to for support. Or even OEMS.
And as the source is GPLed, the folks at Eazel do not have the "its us or nothing" for support even on the back-end of the support structure.
Unlike traditional multi-tier support, where end users have contracts with VARs and ISVs, who have contracts with distribution, who have contracts with the vendor, it is far from unlikely to short circuit this process and just do support directly for the product internally.
>As forking would mean coding against dozens of
>other company-driven developers forking only
>works in theory. Nobody except for your mom would
>be interested in your fork
And this is different from Open Source development how?
The fact of the matter, the only reason there would be to fork would be if the maintainer (be it person or company) was doing an inadequate job. This is no different that Open source.
>Hint: Then why are core-developers on the
>gnome-foundation-mailinglist so concerned on
>lacking company-independent developers right
>now???????
Odd, I read it as a discussion as how to safeguard against it in the future. Kind of like buying health insurance even though you're not currently sick.
Take note of the charter:
"The membership will be populated with all the
consenting members of the gnome-hackers mailing
list, people holding CVS accounts, and anyone
else who speaks out and wants to join when
asked."
So far I haven't seen any major concern on the main Gnome lists. Most of it has been KDE advocates slinging around rumours of Gnome being commercialized, overhyped, yadda yadda yadda.
Aside from that, about the only thing I've seen on the lists are complaints about press releases from some of the new memers and articles not making it clear that the community *is* very much a part of the foundation.
>BTW: you should stop reading those Q&A-FAQs. They
>are bad for your health:
BTW: you should stop making completely ad hominum arguments. They're bad for your credibility.