It might be considered premature, but its the direction things are moving in both the GNOME and KDE world. One thing that is rarely pointed out by the khicken littles is that this code hasn't been declared stable for GNOME either.
>changing KDE service types (thus, breaking third >party kde apps that use kparts/ktrader.)
They only changes the binary names. The whole point of ktrader is that you don't *need* to hard code names or paths.
>KDE and Gnome both have pretty faces at first >glance, but within minutes of use prove to be >slapped together messes. The solution isn't to >consolidate the two, rather it's to throw both >out and start over from scratch, this time with a >game plan going in. Neither will ever pose a real >threat to Windows and they are too far gone to >turn around.
Can you name a few things you think are insurmountable issues in either desktop? Not small complains, I mean something large enough to throw out a half decade of development and hundreds of thousands of lines of code on either project.
I can't comment on KDE much, but my impression has been that as of KDE 3.x, it is really coming into its own.
With GNOME 2.0, I *know* that it is, since I'm sitting here using it. They have a solid infrastructure for configuration and site management, accessibility, font management, and component technology. Around the corner is a full multimedia framework capable of handling most video and audio formats you can throw at it.
If you really believe you can do a better job, go ahead and start a project. I don't expect you'll have anything approaching either project in five years.
>Go with Mandrake. It's not just for newbies >anymore. They go to the edge... > >Postfix over sendmail
Postfix was added to Red Hat in 7.3.
>Postgres over MySQL
Postgres has been in since 5.0, about five years ago. (On a side note, MySQL didn't make it in until 7.0).
>i586 over i386
Red Hat compiles -mcpu=i586 -march=i386, which means optimization for i586, but without using instructions that are incompatible with i386. The performance increase for doing -march=i586 is negligable except in a few corner cases.
However, the kernel and glibc are shipped with optimizations for multiple architectures, so as to provide most of the benefits without locking out non-pentium architectures.
>While Gnome continues to bloat itself with poorly >designed projects (some of which are dead) and >dependencies from hell, KDE just gets better.
Quick quiz, which of the following projects are dead - GConf? Pkg-config? Glib? GDK/GTK? ATK? Fontconfig? Pango? GStreamer? ORBit? Bonobo? libxml? libxslt?
Here's a hint: the answer is none of them.
As for calling these "bloat", "dependency hell", and "poorly designed"... Well, I simply don't agree with you on any count. Gnome 2.0 is a lot leaner on my machine than any of the Gnome 1.x releases, and they're commiting to exactly what comprises the desktop and development platform, so third party applications can know exactly what they can depend on having.
Matt
Re:Actual Researched Percentages without Company F
on
More Switching Stories
·
· Score: 2
>Until you realize the percentage of Macs running >is the same statistic as the percentage of P.C.'s >in a landfill.
Until you present me with some solid facts backing that up, I'll just as soon believe you pulled that figure out of your ass rather than realizing anything.
Let's assume your correct. So, given Apple's claim that there are 20 million Mac currently in use worldwide. A little quick arithmatic shows us that comes out to 37% of all Macs ever produced running. For simplicity sake, for the PC side, we'll limit it to the 576 million produced since 1998. By your claim, only 37% of those are in a landfill, so that must mean 363 million are still running.
Oh dear, that's probably the answer you wanted to hear. Just for fun, lets plug in the figures that Jack Campbell would have us believe, i.e. that there are 32 million Macs currently in use. Now our figure rises to 59% of the total still being servicable. Ahhh, here we go. That comes out to the figure you're looking for - 236 million PCs in use.
Mind you, we're taking the word of someone who did a WHOLE 30 hours of research over a corporation that had no reason to understate its userbase by 12 million users. And we threw out all PCs manufactured before 1998. And we took your estimate of how many PCs are in landfills at face value, which is a little silly given the time frame we're using, and the fact that amortization of computer hardware happens over three years.
You know, I didn't realize just how much work you zealots did to make up statistics that suit you. I have a new found respect. Really.
>>pay-to-download services are rising in popularity > >That's kind of like saying this new car model we >introduced last year is selling better than it was >2 years ago.
No, it's more like saying this car model that was introduced four years ago is selling better than it was two years ago. E-music has been around since June 1998.
>actually, I think their prefferred title is "the >idle rich" > >If I had lots o cash to waste, SURE, I'd buy from >e-music. > >Instead I took my 100 free songs and bolted.
Ummm... since when did $9.99/mo become something only "the idle rich" could afford? That's one bargain bin CD or DVD. Or about the cost of a dial-up account. Or lunch for two at a fast food joint.
I don't pretend that e-music is to everyone's taste, since they don't carry a lot of "mainstream" music. For those of us with more eclectic tastes, though, it's a godsend.
I download at least 20 or 30 albums a month. I don't have to worry about whether the person on the other end is going to disconnect. I don't have to worry about crappy encoding. I don't have to worry that the song I'm downloading isn't a 5 minute loop of someone taking a shit.
And I regularly pull down *entire albums* in less than three minutes. Yeah, I really feel like a sucker.
>GNU is a stupid-sounding name to begin with, and
>their made-up pronunciation (Guh-New) is
>counterintuitive and only makes their name even
>less attractive.
It's only counterintuitive if you didn't grow up watching the Great Space Coaster
>Would you really install Red Hat or Mandrake on >your parent's machine, when you know all they >need is a web browser, an email client and >perhaps an instant messenger client? Would you >*really* take the time to install it, secure it, >solve dependency issues and then *teach* them >step-by-step how to use the OS until they reached >the point where they weren't calling you five >times a week for support?
I'm not going to come out and say flat out installing is necessarily the best idea for your parents, but you're overexagerating the difficulting of setting up Red Hat (not sure about Mandrake).
Install it = 10 minutes, mostly choosing packages.
Secure it = 5 minutes, one click to set up a firewall that rejects all incoming connections, half a dozen clicks to register the machines with RHN.
Solving dependency issues = 0 minutes, the installer does this automatically.
Teaching the 'rents = ??. Well, it depends. We're talking about just web, mail and IM here, right? Well, the default apps from Lindows are all the available in Red Hat, so there really shouldn't be any appreciable difference. Or, if you're like me and prefer GNOME, you can set up Galeon, Gaim and Evolution, all of which are just as easy to learn.
My mother first learned how to use a computer when she stayed with me for six months. At the time (around 1997?) she ended up using my machine, which was running Afterstep (classic), Postilion and Netscape 4.0.x. My total time teaching her consisted of a half hour of showing her what the programs did, after which she proceeded to take over my computer for a week. When she finally *did* get a Windows PC for herself, she complained that it was harder to use than the desktop I spent five minutes configuring.
Mind you, I'm not going to argue this is typical, but my point is that the basic functionality of two or three apps does not necessarily equate to five support calls a week. Since there's not a huge amount of difference between Windows and Linux offerings, it shouldn't take anyone long to figure out "click on new message to send, duh, a new message" or "type the url in this little box thingie to get to a web page" on EITHER platform.
>The point is moot, anyway, since they're not >really bundling the AOL client, but just Netscape >(which is what the poster above is complaining >about).
Right now at least... But, if you go to their website, they say they working on it:
Even though AOL can't currently be used as your
ISP to connect to the Internet from within
LindowsOS (that's being worked on)
And provide a link to download it:
http://www.lindows.com/aoloffer
And give you screenshots of AOL 7.0 running under Lindows:
http://info.lindows.com/aol/#client
It would hardly suprise me if, come the time of their Lindows 3.0 release, there was an AOL icon on the desktop like you get with a lot of OEM manufacturers.
Matt
Re:Actual Researched Percentages without Company F
on
More Switching Stories
·
· Score: 2
>Jack Campbell spent about 30 hours and about a >week's worth of research to gather his numbers.
He doesn't detail how he arrived at his numbers, which to me ruins any credibility in them.
>Even includes Linux, AS400, and mainframe OS and >application numbers.
And ignores Netware, OpenVMS, MPE/IX, OS/2, DOS, System/36, and numerous others.
It would be easy to say these are all legacy platforms, but it doesn't change the fact that there is a signifigant installed base of each. The last numbers published by IDC (in 1998) reported an installed base of 10 *million*. Even System/36 still has a signifigant userbase, despite being superceded by OS/400 in the early 1990's.
>At the end of the article he also includes the >hardware numbers per manufacturer over the last >20 years for those people wanting to know those >numbers. I will not tell you the results, you >should read the article for yourself.
How about some more hardware numbers... The total number of Macintoshes ever produced is 54 million, of which only 17 million are capable of running MacOS X.
On the other hand, the PC industry is pumping out somewhere in the neighborhood of 30 million units A QUARTER. That's 120 million units a year. And that is only the Intel compatible machines.
Somehow the figure of 275 million installed machines is starting to sound a little low, isn't it?
And, to put that into further perspective, Apple is selling about 800k units per quarter. Respectable? Yes. Enough to put them in the top five manufacturers? Yes. But it is still only 3% of the total market.
Please note that I am not expressing an opinion about the value of the Macintosh platform, nor its long term viability. I just dislike people who present unsubstantiated statistics as facts, and that's what Mr. Campbell apears to be.
>Wrong, on Darwin, NeXT STeP, OpenStep and Mac OS >X, the/usr/lib/dyld (which is like/lib/ld.so) >can find the libraries if there are in >/System/Library/Frameworks/XXX.framework/XXX, >/Library/Frameworks/XXX.framework/XXX, >~/Library/Frameworks/XXX.framework/XXX, and >/Network/Library/Frameworks/XXX.framework/XXX (not >in that order though), so the LD_LIBRARY_PATH >(actually DYLD_LIBRARY_PATH on Darwin/Mac OSX) >does not need to be touched at all.
Looking at the link you gave, it appears that it touches DYLD_FRAMEWORK_PATH instead. Same shit, different variable. And actually, if it doesn't find it in DYLD_FRAMEWORK_PATH, it *does* touch DYLD_LIBRARY_PATH, then DYLD_FALLBACK_FRAMEWORK_PATH, and finally DYLD_FALLBACK_LIBRARY_PATH.
You've convinced me, that sounds REALLY neat compared to just looking in LD_LIBRARY_PATH.
> The title and description is misleading. From the > comments further down in the article, Linus > points out that only 50 threads at a time were > running in parallel:
And the next comment down is from Ingo:
actually, that was Ulrich's other test, which
tests the serial starting of 100,000 threads.
the test i did started up 100,000 concurrent
threads which shot up the load-average to a
couple of thousands. [the default timeslice the
parent has is enough to start more than 50,000
parallel threads a pop or so.]
So, yes, they did manage 100,000 threads running in parallel.
>Of course, most of the lacking features were >implemented long ago or are about to see the light >of day in MySQL 4.1.
I use MySQL in a production environment (not my decision, it was there when I took the job), so I keep a fairly close eye on what developments are being made.
First off, "about to see the light of day" is a bit misleading. The 4.0 branch hasn't been declared stable yet, and still has a few months to go if the 3.23 development cycle is any indication, and it's already approaching two years since the first stable release of 3.23.
There were some major improvements in the 3.23 branch, with the InnoDB table type implementing some of the missing features, specifically row-level locking, transactions, and foreign keys.
There are a few areas where their foreign key implementation flawed though. For instance, you cannot alter a table or create a new index on it without the key constraints being dropped. Likewise, it will allow you to drop a table that another table references with a foreign key constraint. I don't know about you, but I kind of like my database to actually ENFORCE referential integrity.
There are still improvments being made, I'll grant you. They finally added in support for limited ON DELETE triggers (only SET NULL or CASCADE, but its a start).
A fair bit of work is still necessary to add the rest of the features they're missing. Subqueries, at least, are planned in 4.1, as are stable encypted connections and hot backups.
And there are features that are on their "things that have to be done sometime" list, such as stored procedures and triggers, that are crucial to a lot of database configruations. And there are others, like point in time recovery, that aren't even mentioned on their page.
I haven't looked too closely at the query optimizer and analysis tools in 4.0 yet, but the ones in 3.x pale in comparison to PostgreSQL.
(On a side note, I find some of their commentary on how development of MySQL and Postgres differ to be questionable.. They imply heavily that the PostgreSQL team adds features without much planning and without determining an "optimal, definite solution" before doing so, e.g.:
"PostgreSQL is based on a kernel with lots of contributors. In this setup it makes sense to prioritise adding a lot of new features, instead of implementing them optimally, because one can always optimise things later if there arises a need for this".
My impression is almost entirely opposite from following development of both systems, and reading the mailing lists for each. For example, the initial replication code for MySQL was extremely crude and incomplete, whereas the PostgreSQL team has been implementing full WAL and PITR subsystems to base their replication code on.
In fact, there was a discussion pgsql-hackers recently that brought up the question of whether they should START implementing "good enough for now" solutions in certain cases, as opposed to their policy of not including band-aid solutions.
>I've listed several reasons in other posts for
>other articles, hence my claim to knee-jerk
>reactions and my own reasons for not liking X. I
>don't want to be too redundant here. Take a look
>at this response:
Okay, lets go through your list of "reasons" in order.
>That's hardly ever been a reason not to make a
>change. If that was the reasoning years ago, open
>source and Linux and FreeBSD never would have
>come to be.
This has nothing to do with whether X sucks or no. No reason here.
>While that is useful for the corporate and geek
>environment, it is absolutely useless for a
>consumer.
Until you can argue why network transparency is DETRIMENTAL to the consumer experience this is irrelevant. No reason here.
>X is proven in the sysadmin and engineering
>environments. However, it has failed in the
>desktop realm.
This is merely restating your supposition. No reason here.
>Developers still have to choose whether to
>develop in KDE, Gnome, or X by itself, or develop
>their own widget sets (ala Mozilla).
Those aren't shortcomings of X itself. No reason here. (On a side note, it should be pointed out that under Windows a developer has to choose between the Windows API, MDI, QT, WxWindows, etc, etc. On Mac OS X, a deveeloper has to decide between Classic, Carbon, or Cocoa. And on both, you can make the decision to develop your own widget set, just like Mozilla did, on those platforms as well.)
>X by itself might be fast, but to get it to
>anywhere near the usability and even asthetic
>qualities of other GUIs, it becomes slow.
This is anecdotal, and fails to show how X would be the bottleneck. No reason here.
>Just another example of how X was designed with
>a completely different set of requirements than
>those that apply to a consumer desktop.
Again, this in no way proves that it is not also suitable for a consumer desktop. You haven't even deigned to list what you imagine the different requirements to be yet. No reason here.
>That's a major step, but how will it handle
>driver updates?
This is an implementation issue, not a design issue. Regardless, driver updates can be handled like they have been for years - as packages. Virtually all distributions can install these just by clicking on them. No reason here.
>Will grandma have to recompile her kernel?
Since X drivers are userspace, I'd give that a big no. No reason here either. As an aside, "grandma" hasn't had to upgrade a kernel for any reason for years. We have distributors for a reason.
>While not totally X-related, the split between
>KDE and Gnome is only making things more
>difficult. Competition generally benefits all,
>but it's creating a rift between an already niche
>market.
This is not an issue with X either, as you admit. No reason here. (BTW, if anything, the Unix desktop has been CONVERGING on KDE and Gnome. Not too far in the past things were a mishmosh of Xt, Athena, XForms, Motif, Tk, etc, etc.)
>If the desire is to keep X and open source
>desktops in the realm of the geek, then these
>steps are fine. But if there is really a desire
>to get them onto the desktop and bust the
>Microsoft monopolies, these flaws I've listed and
>many others need to be addressed by X or by a new
>GUI.
Nice how you've suddenly changed what you're arguing for without admitting you were wrong. Don't think you got away with changing from a straight "we need to ditch X" to "well, we need to ditch it, or address its problems" without notice.
Noone has stated that X shouldn't be improved, just that we shouldn't throw the baby away with the bathwater. Now, getting back to the rest of your current reply:
>I got tired of ugly fonts, poor performance,
>battling environments, the need for tinkering,
>and at the same time pretending it was somehow
>better than Windows, so I stopped using it.
The ugly fonts issue has two contributing factors - lack of quality free typefaces, which isn't an X issue, and lack of anti-aliasing (for some people, I hate AA fonts), which is already addressed.
Poor performance is more a function of the hardware you're running and the quality of your driver than X itself. Remember that high end graphics workstations have been running X for well over a decade without performance issues, and on much more modest hardware to boot.
The "battling environments" thing is largely a moot point. You don't have to use more than one if you don't want to. Simple.
Modern distributions require no "tinkering" to get it working. I haven't touched an XF86Config,.xinitrc,.xresources, etc file in YEARS, and I've done dozens of installations in that time.
As for "pretending it's better than windows"... It may not have been for what you use it for, but it is for a large number of us. And with ongoing development, it is becoming suitable for more and more people.
>I've done nothing but back up my claim, pointing >but the various problems with X and the reasons >they are affecting open source desktop >proliferation. Now you back up yours.
Um, where? You've only said "the problems are too numerous to list on a Slashdot post". I reread the thread to be sure I didn't miss anything, and no, you still haven't provided a SINGLE concrete explanation of what you think is wrong in X, much less proven that it can't be solved without a complete rewrite.
>There are so many things wrong with X that it >would take alot more than a slashdot post to list >them.
Give even a cursory summary of what you think the biggest issues are.
>Please, go ahead and list any benefits to X to the >consumer, I've never heard anyone from the X camp >list any, so if there are, I'd love to hear them.
It displays graphics. What do you want it to do? Perform oral sex?
You're the one who claimed it was a detriment in the first place, so the burden of evidence is on you.
>I've heard thus far are either knee-jerk rhetoric >damning my anti-X heresy, or benefits of X that >regular computer users could care less about.
And you're not going to hear anything more until you stop talking as if its a given fact that "X sucks" and present a well reasoned argument backing it up.
>Linux and open source needs to just drop X as the >GUI, and come up with something new. Something >developed with the general consumer in mind.
People are working on alternates - see DirectFB, Berlin, GGI, etc. Guess what? Aside from DirectFB, which has its place in embedded systems, virtually noone uses or cares about them.
The fact of the matter is there's nothing seriously wrong with X11. Most of the "X sucks" crowd are parroting something they read somewhere without any real understanding.
>Something that doesn't require KDE or Gnome to >patch it's many shortcomings.
KDE and Gnome are outside the scope of what X11 does. What you're saying is roughtly equivilent to saying you shouldn't buy a house that requires you to buy furniture to "patch its many shortcomings".
>It was my understanding that that single employee >was the guy Redhat chose to lead the KDE rework. >If that's the attitude by the guy in charge, I >don't expect much from Redhat's fork of KDE.
Do you have an evidence to back this up? All of the references I've seen state "a developer" and nothing more. Well, putting aside conjecture and conspiricy theories.
>hmmm...I don't think the latest redhat package is >sufficient here... I got bit by this worm on my >webserver today, and I had these latest packages >installed. > >My mod_ssl package and apache package WERE old, >however, so maybe the exploit isn't in openssl.
Well, there's a possibility it wasn't this exact worm, and something that hit your vulnerable Apache or mod_ssl packages.
The other thing is, did you restart Apache after you installed the SSL updates? The running process would still be vulnerable even if you installed the update.
> That Red Hat pours alot of money in to GNOME, > while they give hardly any support to KDE (in > act, they seem to refer KDE as "Crapland" > (according to the Red Hat bug-report where they > talked about renaming apps and removing the > "About" box)).
It was a leaked piece of internal mail, not a public bug report. A single employee expressing an opinion in a single piece of mail != Red Hat. How hard is that to understand?
> Maybe the 'g' build from openssh.org is
> necessary, but RedHat seems to think they've
> already fixed in in their "b-24" release
Red Hat typically backports security fixes from later releases to the version they shipped with the distribution release to avoid introducing unrelated changes.
Slashdot Mirror
>Things like using xft2 early without testing,
It might be considered premature, but its the direction things are moving in both the GNOME and KDE world. One thing that is rarely pointed out by the khicken littles is that this code hasn't been declared stable for GNOME either.
>changing KDE service types (thus, breaking third
>party kde apps that use kparts/ktrader.)
They only changes the binary names. The whole point of ktrader is that you don't *need* to hard code names or paths.
Matt
>KDE and Gnome both have pretty faces at first
>glance, but within minutes of use prove to be
>slapped together messes. The solution isn't to
>consolidate the two, rather it's to throw both
>out and start over from scratch, this time with a
>game plan going in. Neither will ever pose a real
>threat to Windows and they are too far gone to
>turn around.
Can you name a few things you think are insurmountable issues in either desktop? Not small complains, I mean something large enough to throw out a half decade of development and hundreds of thousands of lines of code on either project.
I can't comment on KDE much, but my impression has been that as of KDE 3.x, it is really coming into its own.
With GNOME 2.0, I *know* that it is, since I'm sitting here using it. They have a solid infrastructure for configuration and site management, accessibility, font management, and component technology. Around the corner is a full multimedia framework capable of handling most video and audio formats you can throw at it.
If you really believe you can do a better job, go ahead and start a project. I don't expect you'll have anything approaching either project in five years.
Matt
>Go with Mandrake. It's not just for newbies
>anymore. They go to the edge...
>
>Postfix over sendmail
Postfix was added to Red Hat in 7.3.
>Postgres over MySQL
Postgres has been in since 5.0, about five years ago. (On a side note, MySQL didn't make it in until 7.0).
>i586 over i386
Red Hat compiles -mcpu=i586 -march=i386, which means optimization for i586, but without using instructions that are incompatible with i386. The performance increase for doing -march=i586 is negligable except in a few corner cases.
However, the kernel and glibc are shipped with optimizations for multiple architectures, so as to provide most of the benefits without locking out non-pentium architectures.
Matt
>While Gnome continues to bloat itself with poorly
>designed projects (some of which are dead) and
>dependencies from hell, KDE just gets better.
Quick quiz, which of the following projects are dead - GConf? Pkg-config? Glib? GDK/GTK? ATK? Fontconfig? Pango? GStreamer? ORBit? Bonobo? libxml? libxslt?
Here's a hint: the answer is none of them.
As for calling these "bloat", "dependency hell", and "poorly designed"... Well, I simply don't agree with you on any count. Gnome 2.0 is a lot leaner on my machine than any of the Gnome 1.x releases, and they're commiting to exactly what comprises the desktop and development platform, so third party applications can know exactly what they can depend on having.
Matt
>Until you realize the percentage of Macs running
>is the same statistic as the percentage of P.C.'s
>in a landfill.
Until you present me with some solid facts backing that up, I'll just as soon believe you pulled that figure out of your ass rather than realizing anything.
Let's assume your correct. So, given Apple's claim that there are 20 million Mac currently in use worldwide. A little quick arithmatic shows us that comes out to 37% of all Macs ever produced running. For simplicity sake, for the PC side, we'll limit it to the 576 million produced since 1998. By your claim, only 37% of those are in a landfill, so that must mean 363 million are still running.
Oh dear, that's probably the answer you wanted to hear. Just for fun, lets plug in the figures that Jack Campbell would have us believe, i.e. that there are 32 million Macs currently in use. Now our figure rises to 59% of the total still being servicable. Ahhh, here we go. That comes out to the figure you're looking for - 236 million PCs in use.
Mind you, we're taking the word of someone who did a WHOLE 30 hours of research over a corporation that had no reason to understate its userbase by 12 million users. And we threw out all PCs manufactured before 1998. And we took your estimate of how many PCs are in landfills at face value, which is a little silly given the time frame we're using, and the fact that amortization of computer hardware happens over three years.
You know, I didn't realize just how much work you zealots did to make up statistics that suit you. I have a new found respect. Really.
Matt
>>pay-to-download services are rising in popularity
>
>That's kind of like saying this new car model we
>introduced last year is selling better than it was
>2 years ago.
No, it's more like saying this car model that was introduced four years ago is selling better than it was two years ago. E-music has been around since June 1998.
Matt
>actually, I think their prefferred title is "the
>idle rich"
>
>If I had lots o cash to waste, SURE, I'd buy from
>e-music.
>
>Instead I took my 100 free songs and bolted.
Ummm... since when did $9.99/mo become something only "the idle rich" could afford? That's one bargain bin CD or DVD. Or about the cost of a dial-up account. Or lunch for two at a fast food joint.
I don't pretend that e-music is to everyone's taste, since they don't carry a lot of "mainstream" music. For those of us with more eclectic tastes, though, it's a godsend.
I download at least 20 or 30 albums a month. I don't have to worry about whether the person on the other end is going to disconnect. I don't have to worry about crappy encoding. I don't have to worry that the song I'm downloading isn't a 5 minute loop of someone taking a shit.
And I regularly pull down *entire albums* in less than three minutes. Yeah, I really feel like a sucker.
Matt
>GNU is a stupid-sounding name to begin with, and
>their made-up pronunciation (Guh-New) is
>counterintuitive and only makes their name even
>less attractive.
It's only counterintuitive if you didn't grow up watching the Great Space Coaster
Matt
>Would you really install Red Hat or Mandrake on
>your parent's machine, when you know all they
>need is a web browser, an email client and
>perhaps an instant messenger client? Would you
>*really* take the time to install it, secure it,
>solve dependency issues and then *teach* them
>step-by-step how to use the OS until they reached
>the point where they weren't calling you five
>times a week for support?
I'm not going to come out and say flat out installing is necessarily the best idea for your parents, but you're overexagerating the difficulting of setting up Red Hat (not sure about Mandrake).
Install it = 10 minutes, mostly choosing packages.
Secure it = 5 minutes, one click to set up a firewall that rejects all incoming connections, half a dozen clicks to register the machines with RHN.
Solving dependency issues = 0 minutes, the installer does this automatically.
Teaching the 'rents = ??. Well, it depends. We're talking about just web, mail and IM here, right? Well, the default apps from Lindows are all the available in Red Hat, so there really shouldn't be any appreciable difference. Or, if you're like me and prefer GNOME, you can set up Galeon, Gaim and Evolution, all of which are just as easy to learn.
My mother first learned how to use a computer when she stayed with me for six months. At the time (around 1997?) she ended up using my machine, which was running Afterstep (classic), Postilion and Netscape 4.0.x. My total time teaching her consisted of a half hour of showing her what the programs did, after which she proceeded to take over my computer for a week. When she finally *did* get a Windows PC for herself, she complained that it was harder to use than the desktop I spent five minutes configuring.
Mind you, I'm not going to argue this is typical, but my point is that the basic functionality of two or three apps does not necessarily equate to five support calls a week. Since there's not a huge amount of difference between Windows and Linux offerings, it shouldn't take anyone long to figure out "click on new message to send, duh, a new message" or "type the url in this little box thingie to get to a web page" on EITHER platform.
Matt
>The point is moot, anyway, since they're not
>really bundling the AOL client, but just Netscape
>(which is what the poster above is complaining
>about).
Right now at least... But, if you go to their website, they say they working on it:
Even though AOL can't currently be used as your
ISP to connect to the Internet from within
LindowsOS (that's being worked on)
And provide a link to download it:
http://www.lindows.com/aoloffer
And give you screenshots of AOL 7.0 running under Lindows:
http://info.lindows.com/aol/#client
It would hardly suprise me if, come the time of their Lindows 3.0 release, there was an AOL icon on the desktop like you get with a lot of OEM manufacturers.
Matt
>Jack Campbell spent about 30 hours and about a
>week's worth of research to gather his numbers.
He doesn't detail how he arrived at his numbers, which to me ruins any credibility in them.
>Even includes Linux, AS400, and mainframe OS and
>application numbers.
And ignores Netware, OpenVMS, MPE/IX, OS/2, DOS, System/36, and numerous others.
It would be easy to say these are all legacy platforms, but it doesn't change the fact that there is a signifigant installed base of each. The last numbers published by IDC (in 1998) reported an installed base of 10 *million*. Even System/36 still has a signifigant userbase, despite being superceded by OS/400 in the early 1990's.
>At the end of the article he also includes the
>hardware numbers per manufacturer over the last
>20 years for those people wanting to know those
>numbers. I will not tell you the results, you
>should read the article for yourself.
How about some more hardware numbers... The total number of Macintoshes ever produced is 54 million, of which only 17 million are capable of running MacOS X.
On the other hand, the PC industry is pumping out somewhere in the neighborhood of 30 million units A QUARTER. That's 120 million units a year. And that is only the Intel compatible machines.
Somehow the figure of 275 million installed machines is starting to sound a little low, isn't it?
And, to put that into further perspective, Apple is selling about 800k units per quarter. Respectable? Yes. Enough to put them in the top five manufacturers? Yes. But it is still only 3% of the total market.
Please note that I am not expressing an opinion about the value of the Macintosh platform, nor its long term viability. I just dislike people who present unsubstantiated statistics as facts, and that's what Mr. Campbell apears to be.
Matt
>Wrong, on Darwin, NeXT STeP, OpenStep and Mac OS /usr/lib/dyld (which is like /lib/ld.so)
>X, the
>can find the libraries if there are in
>/System/Library/Frameworks/XXX.framework/XXX,
>/Library/Frameworks/XXX.framework/XXX,
>~/Library/Frameworks/XXX.framework/XXX, and
>/Network/Library/Frameworks/XXX.framework/XXX (not
>in that order though), so the LD_LIBRARY_PATH
>(actually DYLD_LIBRARY_PATH on Darwin/Mac OSX)
>does not need to be touched at all.
Looking at the link you gave, it appears that it touches DYLD_FRAMEWORK_PATH instead. Same shit, different variable. And actually, if it doesn't find it in DYLD_FRAMEWORK_PATH, it *does* touch DYLD_LIBRARY_PATH, then DYLD_FALLBACK_FRAMEWORK_PATH, and finally DYLD_FALLBACK_LIBRARY_PATH.
You've convinced me, that sounds REALLY neat compared to just looking in LD_LIBRARY_PATH.
Matt
> The title and description is misleading. From the
> comments further down in the article, Linus
> points out that only 50 threads at a time were
> running in parallel:
And the next comment down is from Ingo:
actually, that was Ulrich's other test, which
tests the serial starting of 100,000 threads.
the test i did started up 100,000 concurrent
threads which shot up the load-average to a
couple of thousands. [the default timeslice the
parent has is enough to start more than 50,000
parallel threads a pop or so.]
So, yes, they did manage 100,000 threads running in parallel.
Matt
>Of course, most of the lacking features were
:)
>implemented long ago or are about to see the light
>of day in MySQL 4.1.
I use MySQL in a production environment (not my decision, it was there when I took the job), so I keep a fairly close eye on what developments are being made.
First off, "about to see the light of day" is a bit misleading. The 4.0 branch hasn't been declared stable yet, and still has a few months to go if the 3.23 development cycle is any indication, and it's already approaching two years since the first stable release of 3.23.
There were some major improvements in the 3.23 branch, with the InnoDB table type implementing some of the missing features, specifically row-level locking, transactions, and foreign keys.
There are a few areas where their foreign key implementation flawed though. For instance, you cannot alter a table or create a new index on it without the key constraints being dropped. Likewise, it will allow you to drop a table that another table references with a foreign key constraint. I don't know about you, but I kind of like my database to actually ENFORCE referential integrity.
There are still improvments being made, I'll grant you. They finally added in support for limited ON DELETE triggers (only SET NULL or CASCADE, but its a start).
A fair bit of work is still necessary to add the rest of the features they're missing. Subqueries, at least, are planned in 4.1, as are stable encypted connections and hot backups.
And there are features that are on their "things that have to be done sometime" list, such as stored procedures and triggers, that are crucial to a lot of database configruations. And there are others, like point in time recovery, that aren't even mentioned on their page.
I haven't looked too closely at the query optimizer and analysis tools in 4.0 yet, but the ones in 3.x pale in comparison to PostgreSQL.
(On a side note, I find some of their commentary on how development of MySQL and Postgres differ to be questionable.. They imply heavily that the PostgreSQL team adds features without much planning and without determining an "optimal, definite solution" before doing so, e.g.:
"PostgreSQL is based on a kernel with lots of contributors. In this setup it makes sense to prioritise adding a lot of new features, instead of implementing them optimally, because one can always optimise things later if there arises a need for this".
My impression is almost entirely opposite from following development of both systems, and reading the mailing lists for each. For example, the initial replication code for MySQL was extremely crude and incomplete, whereas the PostgreSQL team has been implementing full WAL and PITR subsystems to base their replication code on.
In fact, there was a discussion pgsql-hackers recently that brought up the question of whether they should START implementing "good enough for now" solutions in certain cases, as opposed to their policy of not including band-aid solutions.
Anyways, enough of my OT rant...
Matt
>So if these people didn't 'agree' to the GPL, they
>are not bound to it, and can do whatever they want
>with the Linux source? Right.
You seem impervious to the point. If you don't agree to the GPL, that does not mean you can do whatever you want with copyrighted material.
Matt
>I've listed several reasons in other posts for
.xinitrc, .xresources, etc file in YEARS, and I've done dozens of installations in that time.
>other articles, hence my claim to knee-jerk
>reactions and my own reasons for not liking X. I
>don't want to be too redundant here. Take a look
>at this response:
Okay, lets go through your list of "reasons" in order.
>That's hardly ever been a reason not to make a
>change. If that was the reasoning years ago, open
>source and Linux and FreeBSD never would have
>come to be.
This has nothing to do with whether X sucks or no. No reason here.
>While that is useful for the corporate and geek
>environment, it is absolutely useless for a
>consumer.
Until you can argue why network transparency is DETRIMENTAL to the consumer experience this is irrelevant. No reason here.
>X is proven in the sysadmin and engineering
>environments. However, it has failed in the
>desktop realm.
This is merely restating your supposition. No reason here.
>Developers still have to choose whether to
>develop in KDE, Gnome, or X by itself, or develop
>their own widget sets (ala Mozilla).
Those aren't shortcomings of X itself. No reason here. (On a side note, it should be pointed out that under Windows a developer has to choose between the Windows API, MDI, QT, WxWindows, etc, etc. On Mac OS X, a deveeloper has to decide between Classic, Carbon, or Cocoa. And on both, you can make the decision to develop your own widget set, just like Mozilla did, on those platforms as well.)
>X by itself might be fast, but to get it to
>anywhere near the usability and even asthetic
>qualities of other GUIs, it becomes slow.
This is anecdotal, and fails to show how X would be the bottleneck. No reason here.
>Just another example of how X was designed with
>a completely different set of requirements than
>those that apply to a consumer desktop.
Again, this in no way proves that it is not also suitable for a consumer desktop. You haven't even deigned to list what you imagine the different requirements to be yet. No reason here.
>That's a major step, but how will it handle
>driver updates?
This is an implementation issue, not a design issue. Regardless, driver updates can be handled like they have been for years - as packages. Virtually all distributions can install these just by clicking on them. No reason here.
>Will grandma have to recompile her kernel?
Since X drivers are userspace, I'd give that a big no. No reason here either. As an aside, "grandma" hasn't had to upgrade a kernel for any reason for years. We have distributors for a reason.
>While not totally X-related, the split between
>KDE and Gnome is only making things more
>difficult. Competition generally benefits all,
>but it's creating a rift between an already niche
>market.
This is not an issue with X either, as you admit. No reason here. (BTW, if anything, the Unix desktop has been CONVERGING on KDE and Gnome. Not too far in the past things were a mishmosh of Xt, Athena, XForms, Motif, Tk, etc, etc.)
>If the desire is to keep X and open source
>desktops in the realm of the geek, then these
>steps are fine. But if there is really a desire
>to get them onto the desktop and bust the
>Microsoft monopolies, these flaws I've listed and
>many others need to be addressed by X or by a new
>GUI.
Nice how you've suddenly changed what you're arguing for without admitting you were wrong. Don't think you got away with changing from a straight "we need to ditch X" to "well, we need to ditch it, or address its problems" without notice.
Noone has stated that X shouldn't be improved, just that we shouldn't throw the baby away with the bathwater. Now, getting back to the rest of your current reply:
>I got tired of ugly fonts, poor performance,
>battling environments, the need for tinkering,
>and at the same time pretending it was somehow
>better than Windows, so I stopped using it.
The ugly fonts issue has two contributing factors - lack of quality free typefaces, which isn't an X issue, and lack of anti-aliasing (for some people, I hate AA fonts), which is already addressed.
Poor performance is more a function of the hardware you're running and the quality of your driver than X itself. Remember that high end graphics workstations have been running X for well over a decade without performance issues, and on much more modest hardware to boot.
The "battling environments" thing is largely a moot point. You don't have to use more than one if you don't want to. Simple.
Modern distributions require no "tinkering" to get it working. I haven't touched an XF86Config,
As for "pretending it's better than windows"... It may not have been for what you use it for, but it is for a large number of us. And with ongoing development, it is becoming suitable for more and more people.
>I've done nothing but back up my claim, pointing
>but the various problems with X and the reasons
>they are affecting open source desktop
>proliferation. Now you back up yours.
Um, where? You've only said "the problems are too numerous to list on a Slashdot post". I reread the thread to be sure I didn't miss anything, and no,
you still haven't provided a SINGLE concrete explanation of what you think is wrong in X, much less proven that it can't be solved without a complete rewrite.
>There are so many things wrong with X that it
>would take alot more than a slashdot post to list
>them.
Give even a cursory summary of what you think the biggest issues are.
>Please, go ahead and list any benefits to X to the
>consumer, I've never heard anyone from the X camp
>list any, so if there are, I'd love to hear them.
It displays graphics. What do you want it to do? Perform oral sex?
You're the one who claimed it was a detriment in the first place, so the burden of evidence is on you.
>I've heard thus far are either knee-jerk rhetoric
>damning my anti-X heresy, or benefits of X that
>regular computer users could care less about.
And you're not going to hear anything more until you stop talking as if its a given fact that "X sucks" and present a well reasoned argument backing it up.
>Linux and open source needs to just drop X as the
>GUI, and come up with something new. Something
>developed with the general consumer in mind.
People are working on alternates - see DirectFB, Berlin, GGI, etc. Guess what? Aside from DirectFB, which has its place in embedded systems, virtually noone uses or cares about them.
The fact of the matter is there's nothing seriously wrong with X11. Most of the "X sucks" crowd are parroting something they read somewhere without any real understanding.
>Something that doesn't require KDE or Gnome to
>patch it's many shortcomings.
KDE and Gnome are outside the scope of what X11 does. What you're saying is roughtly equivilent to saying you shouldn't buy a house that requires you to buy furniture to "patch its many shortcomings".
Matt
> A LinuxAndMain article [linuxandmain.com] has
> some references.
The article states nothing beyond "said to have been written by a Red Hat employee".
So, again, where's the indication that this was "the guy Redhat chose to lead the KDE rework"?
Matt
>It was my understanding that that single employee
>was the guy Redhat chose to lead the KDE rework.
>If that's the attitude by the guy in charge, I
>don't expect much from Redhat's fork of KDE.
Do you have an evidence to back this up? All of the references I've seen state "a developer" and nothing more. Well, putting aside conjecture and conspiricy theories.
Matt
>hmmm...I don't think the latest redhat package is
>sufficient here... I got bit by this worm on my
>webserver today, and I had these latest packages
>installed.
>
>My mod_ssl package and apache package WERE old,
>however, so maybe the exploit isn't in openssl.
Well, there's a possibility it wasn't this exact worm, and something that hit your vulnerable Apache or mod_ssl packages.
The other thing is, did you restart Apache after you installed the SSL updates? The running process would still be vulnerable even if you installed the update.
Matt
> That Red Hat pours alot of money in to GNOME,
> while they give hardly any support to KDE (in
> act, they seem to refer KDE as "Crapland"
> (according to the Red Hat bug-report where they
> talked about renaming apps and removing the
> "About" box)).
It was a leaked piece of internal mail, not a public bug report. A single employee expressing an opinion in a single piece of mail != Red Hat. How hard is that to understand?
Matt
> necessary, but RedHat seems to think they've
> already fixed in in their "b-24" release
Red Hat typically backports security fixes from later releases to the version they shipped with the distribution release to avoid introducing unrelated changes.
Note that RHSA-2002-155 is now superceded by RHSA-2002-160, which additionally addresses CAN-2002-0659.
Matt
> In many cases, the same TLA has more than one
> meaning, so the users of the acronym are able to
> keep the context straight.
Hear, hear! People should really make more judicous use of ETLAs instead.
Matt