Choice is a fine thing for now. Most of the world is still being introduced to desktop computing. It is not yet time to select the best technologies for any given application because we don't understand the application well enough yet.
Even something as "basic" as word processing has changed radically in the last 10 years as a wider variety of people have gained access to computers. The "outliers" in the sample set have, in some cases, become the majority of users.
Open source OSes are especially subject to this. Our systems are designed by those who have a combination of real-world-need and ability to implement. As time goes on that will be a broader and broader segment, and others will be brought in to implement for those who have the need, but not the ability (certainly already happened in some areas).
Give computing 20 or so more years to find its feet and it will be time to make hard decisions, but for now I think choice is a good thing.
Now, moving on to the officeplace (which is where most people think of desktop computing in terms of adoption strategies), I think it's key that OS vendors such as Red Hat, Mandrakesoft, SuSE/Novell and others produce a desktop with clear defaults and clear ways for admins to limit choices. This is important for large scale systems admin where you are maintaining 2,000 systems on people's desks. You need some uniformity in order to scale that support reasonably. This does NOT meant that choice should not be available, but that it should be available to the admins who install the systems and the system should behave well once those choices are made.
I think Red Hat and Mandrake do a decent job here. I'm not as familliar with SuSE, so I can't say. But, that is clearly one of the jobs of a vendor: to establish best practices and ease compatibility.
But poorly. To re-write his article in a more readable form:
1) Lack of formal support
Support from IBM, Red Hat, SuSE, HP, etc. make it clear that this is no longer an issue. The thing is you have to decide who your vendor is going to be.
2) Speed of change (not 'velocity')
All of his concerns boil down to: if you don't select a vendor, you're on your own.... well, duh.
3) Lack of roadmap
Again, the concerns boil down to: select a vendor. That vendor will have a loose road-map as modified by the needs of their vendors, partners, customers and internal goals. This is the same as any company.
4) Functional gaps
He comments, "The current market for Linux is dominated by low-end edge server applications" and he's dead wrong. The problem is that you can easily go out and look at the Netcraft survey and say "this is what's running" and when you're writing for a Web magazine, the Web seems like the whole world. Thankfully, most computers in industry have nothing to do with the Web.
From personal experience I can tell you that he's way off base, even on the Web, but the large-scale adoption of open source has been in a) the infrastructure that runs the Internet, not just the Web b) the scientific community c) government bodies around the world including the US d) education e) semi-embeded devices such as PoS systems and PVRs.
5) Licensing caveats
He cites "confusion about the various open source licensing schemes", which again requires the simple answer: talk to your vendor. Your vendor is responsible for making sure they have the right to sell you the software you're using. If SCO or anyone else sues you (including authors of the software you are running) you point firmly and your vendor and say "I dunno, ask them." I recommend picking a vendor with 800lb low-primates for lawyers for this very reason.
the randomizer chips and other control circuitry in a slot machine must be certified by the gambling commission, if tampered with the casino has a very good chance of being shut down
Well, yes and no. There's a great book on this topic, and if I remember to, I'll post it when I get home. Here's the deal though: companies that make slot machines set a "take" (how much the casino keeps) on the machine when they make it (and modern equipment can be re-adjusted by a central system on-site at a casino). The casino orders the machine with a goal in mind for that machine's take.
Now in most places that have a large amount of gambling, the take has a threshold, and you are not allowed to exceed it. How likely that threshold is to be enforced is mostly a political decision. HOWEVER, in Las Vegas, there is NO LIMIT imposed on the casino's take other than advertized settings must be accurate. Thus, when in Las Vegas (if you feel compelled to throw away money, but want a decent chance of not throwing it all away), either play cards/roulette/etc or play slots with an advertised return).
It's an interesting idea, but I'm not sure I see how using an object as a prototype in this way is valuable. For starters, it seems like it would force libraries to instantiate fully-formed objects instead of defining behaviors. That means you're going to carry around a LOT of baggage from every object type you might ever want to instantiate!
I also don't see how this can perform terribly well. There's certainly no such thing as inlining....
ADOM was a great game. I really should go back and play it again. Did he ever release the source like he said he was going to?
For those who don't know ADOM is a roguelike game which is entirely rendered in ascii text in a terminal window.
What always drew me to roguelikes was the fact that, without flashy graphics, they had to depend entirely on their playability and depth of content in order to gain popularity. In other words, if your character is just an at-sign and your BFG is just the text "(right hand) BFG" in inventory, then something other than the picture of a hulking muscular guy holding a large phalic symbol spewing forth glowing bolts of death has to be there to keep you playing... In the case of ADOM it was an intricate quest system that spanned an entire countryside, and involved several dungeons, towns and special areas. The magic system was awesome and the HUGE list of playable races and classes was just great.
I also recommend Nethack, Angband, Omega and even the relatively light Larn.
Let em have their fun..mail tld validation can be yet another test that my SpamAssassin installation will use to determine how likely mail is to be spam. If they implement it well, then the test will even get a largish score over the long haul...
This has been AOL's approach since the beginning. They started with convoluted means of "proving" that you were not a spammer. Then they moved on to refusing to listen to any servers that they considered "residential"...
I really expect that within the next 5 to 10 years, they will not send or recieve email at all unless it involves a "partner" of theirs.
Does anyone have a copy of the code that was taken from the site? Any chance of the KDE developers being able to reverse engineer some of the Gnome features from it?
Vector graphics have been with us since the beginning of electronic computing (the earliest systems used oscilliscopes, which were fundamentally a vector device). Formats for describing vector-oriented graphics have existed for as long in the form of everything from Logo to PostScript to SVG.
Desktops based on vector graphics have included NeWS and (as you mention, but to a lesser extent) 4DWM.
SVG on Gnome is not interesting because it's new, it's interesting because we've reached a point where it now really makes sense to describe all of these high-level objects on our desktops with something other than bitmapped graphics. It's just a matter of the abstraction existing before the complexity which necessitated it.
Being am EQ player, I just wanted to comment on a couple points:
1. Instantiated dungeons: no more kill stealing/loot stealing
I think LDoN came out about a year ago. That was the expansion to EQ that added this kind of feature to the game.
2. Best loot comes from quests: no more 'camp the best drop spot'
The best loot in EQ comes from instanced raid zones that are quest-like, and involve story-line-tied flagging to gain access.
3. Non-repeatable quests: camping the best quest giver won't help...better get out and explore
I liked LDoN's approach to this, though it had some flaws. For starters, items are dropped inside the instanced single-party zones, but there are also items that you can "buy" with points that you get for successful missions.
So for example, you might finish 10 adventures (missions) and get 100 points each for them. That gives you 1000 to spend total, and 1000 "lifetime earned" for this particular quest-giver. You can spend the points with ANY quest-giver, but only up to a per-purchase maximum of the lifetime earned with that quest-giver. Since every quest-giver has unique items to sell, you have to do lots of missions for all of them if you want to be able to pick-and-choose.
This gives you incentive to move around and experiment with different adventures, and keeps it from getting too boring too fast (and there are hundreds of zones to go explore if you get bored).
"There is exactly one thing holding Linux back from mainstream corporate and personal use: the lack of any unified and consistent message."
And thus it should stay. No, really.
Linux -- aw hell, just for the ability to distinguish between the kernel and the OS in this post, let me throw my lot in with RMS and say, "GNU/Linux" -- is not a platform, it's a concept. The concept is "you take a little bit of this and a little bit of that and add it to the Linux kernel and it looks a whole lot like UNIX, but... um... more Linuxish."
That's all GNU/Linux is. Now let me ask you a follow-up question: What is Red Hat Enterprise Linux? Aha! You know that, don't you? You can point at a THING and say "I know what this is, and what its message is." Red Hat Enterprise Linux should have a message. GNU/Linux should not. Get the difference?
It's good, therefore, that GNU/Linux is targetted by both Gnome and KDE (as well as other desktops of varying quality, scope and goals). It's good because the operating systems that start with GNU/Linux (e.g. FC1, RHEL, SuSE, Debian, etc.) can take from those what they please, and leave what they do not. Red Hat, for the most part, stresses Gnome as the desktop where, for example, Mandrake does not.
This is what defines a distribution: what tools it includes, what it emphasises and what it contributes to. You may think Debian is too generic and will never gain mainstream adoption. That's cool, because that's not Debian's goal. Debian's goal is to be a haven for free software. It does this admirably. And you can say that about every distribution, only it's a different set of priorities which are and which are not met by each.
"I must say to everyone that if you really want to see Linux take off on the desktop"
No one wants to see GNU/Linux on the desktop any more than Microsoft wants to see Spyglass Mosaic on the desktop. That just happens to be the software that IE started out life as, but it's not MS' goal to put Spyglass on the desktop. It's not Fedora's goal to put GNU/Linux on the desktop, just Fedora.
PS: Posted from a Linux desktop in a company staffed almost entirely by people who use nothing else. We're fine with the state of affairs today, thanks. Oh, and no the only thing holding back Linux on the desktop is distribution and supply channels which are locked in by MS and will take a decade or more to unlock.
Java's not a platform-friendly language, and as such will generally suck for writing platform-friendly apps. If you want your desktop to be a Java desktop, then fine, but if you're writing for other platforms I recommend writing the core of your application in C or C++ and the rest in Perl, Python, Scheme or one of the other languages that admits to platform specifics.
This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot as a back-end. You'll be able to take advantage of Ruby's OO model, but accomodate a third-party library from CPAN in Perl and tie it all to a UI layer that your last project wrote in Python with no ugly transitions through object brokers or external executables. UNIX-like systems have benefited from this homogeneity for decades because of the fact that tools all have a common vision of the system, but libraries have as yet not been able to standardize on ways to communicate across calling conventions, interpreted vs compiled modes of execution and data / object models. With Parrot in that gap I see a bright future for desktop development in high-level languages (as well as many other areas).
Yes, high level languages improve productivity, and yes Java is has that attribute, but you should select a language that is the right tool for the job, and when writing desktop apps, Java is the wrong tool for most jobs.
The line I found most interesting in IBM's "Why TCPA" paper was:
"... the TCPA chip is not well suited to DRM tasks, and IBM's implementation of the chip was neither designed nor evaluated for the necessary tamper resistance needed to provide effective copy protection..."
Interesting stuff, and certainly not what I had been lead to believe previously. Anyone out there that's looked at TCPA to verify this?
It might be corruption, but it's a handy technique on older fileysystem types if you know what you're doing. For example, if you make two partitions for root and swap for some UNIX or UNIX-alike which allocates blocks on the disk relatively linearly, you can give yourself a nice big, juicy swap space that overlaps the upper half of your filesystem.
When you get close to allocating half of the lower partition, you shut down the box and re-size your swap space down to 1/3 of the disk and again to 1/4 when needed. It's touchy but I've done it when I had no other options (e.g. had a very old SunOS installer that refused to install because of space it claimed to need (but did not)).
It's just a disgusting hack though, and no one should do it unless they are backed into a corner by growling tigers. It certainly has nothing to do with hidden partitions (like the OEM restore partitions on many Windows installs) or bad block allocation (10% of the disk at most).
Go read what I wrote... Start from the assumption that I disagree with my own position as you paraphrased it, and I think you'll find that you read in a few things that I didn't write. Specifically, re-read where I wrote "I think there will always be a place for space-based astronomy".
It's not that OWL can out-perform Hubble for the same money, it's that OWL can out-perform Hubble for the same money in certain areas. Which is, of course, what you said in your second paragraph.
The thing about Hubble is that maintaining it costs a LOT of money. If you subtract out the value that Hubble provides for the vast areas of research that can be done from the ground, your cost-benefit analysis for keeping Hubble in the air starts to look unfortunate. Wen you then include the fact that that Hubble money could be re-directed to long-term space telescope emplacements (e.g. on the moon), it really starts to look like a bad plan to maintain Hubble.
And, bold-text aside, how does that contradict anything I said?
Yes, there are limitations to ground-based observing.
However, "the science" (I'd like to find the guy who started that trend...) is no less valuable because you could get more or different data from an orbital device.
Given the choice of putting money into a 5 year effort to put a scope in orbit or a 15 year effort to put a scope on the moon, why is living with ground-based observation for an extra 10 years a big deal? This is astronomy we're talking about, not measuring pop-music trends...
Personally, I doubt either will happen though. The US is going to be in a severe budget crunch for a few years before the baby-boom-deficit really kicks in and we're simply out of money.
PS: zillion must be one of those "astronomers" terms, could you enlighten me? Is that smaller or larger than "billions and billions";-)
You are correct to an extent, but AO renders much of the atmospheric interference moot. Yes, there is loss, but not to the extent that hubble is more valuable than a scope that costs the same amount to build and maintain on the ground. Such a scope (or scopes, OWL for example) would yield far more valuable information long-term and be far more easily upgraded in the future.... I think there will always be a place for space-based astronomy, but I would hold off on replacing hubble until we can build one on the moon. That presents a much better long-term prospect (as long as you don't get smacked with an asteroid TOO soon).
That's funny on the one hand, but let's not take it too seriously. A drop in SCO's market cap is no more a vindication of our position than the skyrocketting market cap was a vindication of SCO's. The market does what the market will, and we should take it all with a grain of salt.
Can we once and for all just declare that ANYTHING can be misued
There are degrees of misuse. Yes, a hammer can be used to build a nuclear weapon (well, not really, but you get the idea).
But this technique on the other hand practically invites misuse. Psycotherapy has moved from being a field that was primarily oriented around counseling to a field first-and-foremost about medication. To that particular fox, the hen-house we now present is a tool for electrically modifying mood or stimulus response.
This technology SHOULD be a good thing, but cautious application of the Hipocratic Oath isn't exactly something that this field is known for.
I don't think it's out of line to point out the potential for abuse.
I'm sorry if you find it off-putting to be given the party line. I understand, really.
However, while I would agree that it's unreasonable to be wasteful in your application and just brush it off as "well, hardware/memory/dist/etc is cheap", I also feel that it's only fair to make certain trade-offs that benefit the users of modern hardware when most OS distributions won't pick up a new software version for six months to two years.
An older box is essentially a different platform. That software runs on it at all is cool, but in order to support it well, you really have to do a full port, with all of the tuning that is involved in any port. That would be a great goal for a distribution vendor... to put out the "P1-P3 Optimized Desktop" would be quite and excellent contribution, but to say that making trade-offs like memory-for-speed is unreasonable in the core project seems to me to be a bit difficult to swallow.
There are, of course, many things you can do to enhance performance on low-end boxes:
1. Load a very lightweight, texture-free theme 2. Re-compile all of the core Gnome software and toolkits with env CFLAGS="-O3"./autogen.sh --enable-debug=minimum 3. Use a light-weight WM like MetaCity 4. Check each core application for performance settings
Following these steps, you can tune your environment to your needs. Good luck!
As well Mononoke (dub script by Neil Gaiman, no less). Mononoke (Web site, DVD), IMHO, was his finest work, and anyone who has not seen it should rush out and grab the DVD.
Trademarks of these films tend to be: children (usually girls) as main characters; flight as a major theme (both magical and realistic, often in the same film e.g. Kiki's); powerful older women (both good and evil); technology as a force of decay or at least at odds with nature.
I would say that his films are the finest examples of children's storytelling to hit the big screen. So much so, in fact, that even jaded adults often find the films captivating and meaningful.
I know that's harsh, and I'm actually being a bit hyperbolic, but only a bit. If people who have specialized hardware don't contribute, the software won't be tailored to them. You have specialized hardware in that it's fairly old. That means that software won't be customized well for you, but you can help possibly millions of people by working on Gnome and finding the performance gotchas for lower-end systems.
I would expect that in order to perform really well on low-end hardware, Gnome will need some compile-time flags to turn off functionality that on higher-end systems might be more ideal. Perhaps some of it could be made run-time, but there are features (like double-buffering in the toolkit) where I think you're going to need to make sure that NO APPLICATION ANYWHERE can possibly make the mistake of using the feature.
That doesn't mean these are bad features, they're just features that are only appropriate for modern, mainstream hardware.
It's open source. You have the power. Think outside of the proprietary software box!
Quote you: "the most you're going to get out of me is that there's an obfuscated Perl contest and no counterpart for Java."
[link mine for emphasis] Note, I'm not familliar with a programming language that lacks such a contest, and C was the first (IOCCC was famous before Perl existed).
Quote you: "operators often have side effects"
You don't actually program in Java, do you? This is just getting silly. Are you saying that Java operators have no side effects?! Let's try out "a=b" for starters....
"there are arcane variables like $["
One man's arcane is another man's "perfectly well documented and easily found via the table of contents, and no it doesn't affect the whole program, read the docs"... but to each his own.
That's beside the point though. You spoke not of variable names, but of syntax.
"as well as the community that uses Perl (there's sort of a celebration of difficult to read code going on)."
Nope. I highly disagree. There is humor and entertainment in whiddling down people's few-line RSA encryption algorithms into the minimum line-count so that it fits on a T-shirt for political reasons... there's command-line usage where how little you type matters, but I don't think anyone celebrates difficult-to-read code in the large... more to the point, those who upload such code to CPAN get the words "maintainable code" explained to them rather harshly.
Again, I was not talking about your feelings about the language or its developers. You said, "there's less obfuscation possible in java syntax". That is incorrect, as far as I know... but feel free to PROVE that wrong.
Slashdot Mirror
Choice is a fine thing for now. Most of the world is still being introduced to desktop computing. It is not yet time to select the best technologies for any given application because we don't understand the application well enough yet.
Even something as "basic" as word processing has changed radically in the last 10 years as a wider variety of people have gained access to computers. The "outliers" in the sample set have, in some cases, become the majority of users.
Open source OSes are especially subject to this. Our systems are designed by those who have a combination of real-world-need and ability to implement. As time goes on that will be a broader and broader segment, and others will be brought in to implement for those who have the need, but not the ability (certainly already happened in some areas).
Give computing 20 or so more years to find its feet and it will be time to make hard decisions, but for now I think choice is a good thing.
Now, moving on to the officeplace (which is where most people think of desktop computing in terms of adoption strategies), I think it's key that OS vendors such as Red Hat, Mandrakesoft, SuSE/Novell and others produce a desktop with clear defaults and clear ways for admins to limit choices. This is important for large scale systems admin where you are maintaining 2,000 systems on people's desks. You need some uniformity in order to scale that support reasonably. This does NOT meant that choice should not be available, but that it should be available to the admins who install the systems and the system should behave well once those choices are made.
I think Red Hat and Mandrake do a decent job here. I'm not as familliar with SuSE, so I can't say. But, that is clearly one of the jobs of a vendor: to establish best practices and ease compatibility.
Dan Farber succicently [sic] explains each point
But poorly. To re-write his article in a more readable form:
1) Lack of formal support
Support from IBM, Red Hat, SuSE, HP, etc. make it clear that this is no longer an issue. The thing is you have to decide who your vendor is going to be.
2) Speed of change (not 'velocity')
All of his concerns boil down to: if you don't select a vendor, you're on your own.... well, duh.
3) Lack of roadmap
Again, the concerns boil down to: select a vendor. That vendor will have a loose road-map as modified by the needs of their vendors, partners, customers and internal goals. This is the same as any company.
4) Functional gaps
He comments, "The current market for Linux is dominated by low-end edge server applications" and he's dead wrong. The problem is that you can easily go out and look at the Netcraft survey and say "this is what's running" and when you're writing for a Web magazine, the Web seems like the whole world. Thankfully, most computers in industry have nothing to do with the Web.
From personal experience I can tell you that he's way off base, even on the Web, but the large-scale adoption of open source has been in a) the infrastructure that runs the Internet, not just the Web b) the scientific community c) government bodies around the world including the US d) education e) semi-embeded devices such as PoS systems and PVRs.
5) Licensing caveats
He cites "confusion about the various open source licensing schemes", which again requires the simple answer: talk to your vendor. Your vendor is responsible for making sure they have the right to sell you the software you're using. If SCO or anyone else sues you (including authors of the software you are running) you point firmly and your vendor and say "I dunno, ask them." I recommend picking a vendor with 800lb low-primates for lawyers for this very reason.
6) ISV endorsements
He writes this one off quickly and effectively.
the randomizer chips and other control circuitry in a slot machine must be certified by the gambling commission, if tampered with the casino has a very good chance of being shut down
Well, yes and no. There's a great book on this topic, and if I remember to, I'll post it when I get home. Here's the deal though: companies that make slot machines set a "take" (how much the casino keeps) on the machine when they make it (and modern equipment can be re-adjusted by a central system on-site at a casino). The casino orders the machine with a goal in mind for that machine's take.
Now in most places that have a large amount of gambling, the take has a threshold, and you are not allowed to exceed it. How likely that threshold is to be enforced is mostly a political decision. HOWEVER, in Las Vegas, there is NO LIMIT imposed on the casino's take other than advertized settings must be accurate. Thus, when in Las Vegas (if you feel compelled to throw away money, but want a decent chance of not throwing it all away), either play cards/roulette/etc or play slots with an advertised return).
It's an interesting idea, but I'm not sure I see how using an object as a prototype in this way is valuable. For starters, it seems like it would force libraries to instantiate fully-formed objects instead of defining behaviors. That means you're going to carry around a LOT of baggage from every object type you might ever want to instantiate!
I also don't see how this can perform terribly well. There's certainly no such thing as inlining....
ADOM was a great game. I really should go back and play it again. Did he ever release the source like he said he was going to?
For those who don't know ADOM is a roguelike game which is entirely rendered in ascii text in a terminal window.
What always drew me to roguelikes was the fact that, without flashy graphics, they had to depend entirely on their playability and depth of content in order to gain popularity. In other words, if your character is just an at-sign and your BFG is just the text "(right hand) BFG" in inventory, then something other than the picture of a hulking muscular guy holding a large phalic symbol spewing forth glowing bolts of death has to be there to keep you playing... In the case of ADOM it was an intricate quest system that spanned an entire countryside, and involved several dungeons, towns and special areas. The magic system was awesome and the HUGE list of playable races and classes was just great.
I also recommend Nethack, Angband, Omega and even the relatively light Larn.
Recessions are classically a gold-mine for entertainment. Just look at the boom in hollywood during the great depression.
Let em have their fun. .mail tld validation can be yet another test that my SpamAssassin installation will use to determine how likely mail is to be spam. If they implement it well, then the test will even get a largish score over the long haul...
This has been AOL's approach since the beginning. They started with convoluted means of "proving" that you were not a spammer. Then they moved on to refusing to listen to any servers that they considered "residential"...
I really expect that within the next 5 to 10 years, they will not send or recieve email at all unless it involves a "partner" of theirs.
Does anyone have a copy of the code that was taken from the site? Any chance of the KDE developers being able to reverse engineer some of the Gnome features from it?
;-)
Oh right, *open* source software....
Vector graphics have been with us since the beginning of electronic computing (the earliest systems used oscilliscopes, which were fundamentally a vector device). Formats for describing vector-oriented graphics have existed for as long in the form of everything from Logo to PostScript to SVG.
Desktops based on vector graphics have included NeWS and (as you mention, but to a lesser extent) 4DWM.
SVG on Gnome is not interesting because it's new, it's interesting because we've reached a point where it now really makes sense to describe all of these high-level objects on our desktops with something other than bitmapped graphics. It's just a matter of the abstraction existing before the complexity which necessitated it.
Being am EQ player, I just wanted to comment on a couple points:
1. Instantiated dungeons: no more kill stealing/loot stealing
I think LDoN came out about a year ago. That was the expansion to EQ that added this kind of feature to the game.
2. Best loot comes from quests: no more 'camp the best drop spot'
The best loot in EQ comes from instanced raid zones that are quest-like, and involve story-line-tied flagging to gain access.
3. Non-repeatable quests: camping the best quest giver won't help...better get out and explore
I liked LDoN's approach to this, though it had some flaws. For starters, items are dropped inside the instanced single-party zones, but there are also items that you can "buy" with points that you
get for successful missions.
So for example, you might finish 10 adventures (missions) and get 100 points each for them. That gives you 1000 to spend total, and 1000 "lifetime earned" for this particular quest-giver. You can spend the points with ANY quest-giver, but only up to a per-purchase maximum of the lifetime earned with that quest-giver. Since every quest-giver has unique items to sell, you have to do lots of missions for all of them if you want to be able to pick-and-choose.
This gives you incentive to move around and experiment with different adventures, and keeps it from getting too boring too fast (and there are hundreds of zones to go explore if you get bored).
"There is exactly one thing holding Linux back from mainstream corporate and personal use: the lack of any unified and consistent message."
... um... more Linuxish."
And thus it should stay. No, really.
Linux -- aw hell, just for the ability to distinguish between the kernel and the OS in this post, let me throw my lot in with RMS and say, "GNU/Linux" -- is not a platform, it's a concept. The concept is "you take a little bit of this and a little bit of that and add it to the Linux kernel and it looks a whole lot like UNIX, but
That's all GNU/Linux is. Now let me ask you a follow-up question: What is Red Hat Enterprise Linux? Aha! You know that, don't you? You can point at a THING and say "I know what this is, and what its message is." Red Hat Enterprise Linux should have a message. GNU/Linux should not. Get the difference?
It's good, therefore, that GNU/Linux is targetted by both Gnome and KDE (as well as other desktops of varying quality, scope and goals). It's good because the operating systems that start with GNU/Linux (e.g. FC1, RHEL, SuSE, Debian, etc.) can take from those what they please, and leave what they do not. Red Hat, for the most part, stresses Gnome as the desktop where, for example, Mandrake does not.
This is what defines a distribution: what tools it includes, what it emphasises and what it contributes to. You may think Debian is too generic and will never gain mainstream adoption. That's cool, because that's not Debian's goal. Debian's goal is to be a haven for free software. It does this admirably. And you can say that about every distribution, only it's a different set of priorities which are and which are not met by each.
"I must say to everyone that if you really want to see Linux take off on the desktop"
No one wants to see GNU/Linux on the desktop any more than Microsoft wants to see Spyglass Mosaic on the desktop. That just happens to be the software that IE started out life as, but it's not MS' goal to put Spyglass on the desktop. It's not Fedora's goal to put GNU/Linux on the desktop, just Fedora.
PS: Posted from a Linux desktop in a company staffed almost entirely by people who use nothing else. We're fine with the state of affairs today, thanks. Oh, and no the only thing holding back Linux on the desktop is distribution and supply channels which are locked in by MS and will take a decade or more to unlock.
Java's not a platform-friendly language, and as such will generally suck for writing platform-friendly apps. If you want your desktop to be a Java desktop, then fine, but if you're writing for other platforms I recommend writing the core of your application in C or C++ and the rest in Perl, Python, Scheme or one of the other languages that admits to platform specifics.
This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot as a back-end. You'll be able to take advantage of Ruby's OO model, but accomodate a third-party library from CPAN in Perl and tie it all to a UI layer that your last project wrote in Python with no ugly transitions through object brokers or external executables. UNIX-like systems have benefited from this homogeneity for decades because of the fact that tools all have a common vision of the system, but libraries have as yet not been able to standardize on ways to communicate across calling conventions, interpreted vs compiled modes of execution and data / object models. With Parrot in that gap I see a bright future for desktop development in high-level languages (as well as many other areas).
Yes, high level languages improve productivity, and yes Java is has that attribute, but you should select a language that is the right tool for the job, and when writing desktop apps, Java is the wrong tool for most jobs.
It might be corruption, but it's a handy technique on older fileysystem types if you know what you're doing. For example, if you make two partitions for root and swap for some UNIX or UNIX-alike which allocates blocks on the disk relatively linearly, you can give yourself a nice big, juicy swap space that overlaps the upper half of your filesystem.
When you get close to allocating half of the lower partition, you shut down the box and re-size your swap space down to 1/3 of the disk and again to 1/4 when needed. It's touchy but I've done it when I had no other options (e.g. had a very old SunOS installer that refused to install because of space it claimed to need (but did not)).
It's just a disgusting hack though, and no one should do it unless they are backed into a corner by growling tigers. It certainly has nothing to do with hidden partitions (like the OEM restore partitions on many Windows installs) or bad block allocation (10% of the disk at most).
Go read what I wrote... Start from the assumption that I disagree with my own position as you paraphrased it, and I think you'll find that you read in a few things that I didn't write. Specifically, re-read where I wrote "I think there will always be a place for space-based astronomy".
It's not that OWL can out-perform Hubble for the same money, it's that OWL can out-perform Hubble for the same money in certain areas. Which is, of course, what you said in your second paragraph.
The thing about Hubble is that maintaining it costs a LOT of money. If you subtract out the value that Hubble provides for the vast areas of research that can be done from the ground, your cost-benefit analysis for keeping Hubble in the air starts to look unfortunate. Wen you then include the fact that that Hubble money could be re-directed to long-term space telescope emplacements (e.g. on the moon), it really starts to look like a bad plan to maintain Hubble.
And, bold-text aside, how does that contradict anything I said?
;-)
Yes, there are limitations to ground-based observing.
However, "the science" (I'd like to find the guy who started that trend...) is no less valuable because you could get more or different data from an orbital device.
Given the choice of putting money into a 5 year effort to put a scope in orbit or a 15 year effort to put a scope on the moon, why is living with ground-based observation for an extra 10 years a big deal? This is astronomy we're talking about, not measuring pop-music trends...
Personally, I doubt either will happen though. The US is going to be in a severe budget crunch for a few years before the baby-boom-deficit really kicks in and we're simply out of money.
PS: zillion must be one of those "astronomers" terms, could you enlighten me? Is that smaller or larger than "billions and billions"
You are correct to an extent, but AO renders much of the atmospheric interference moot. Yes, there is loss, but not to the extent that hubble is more valuable than a scope that costs the same amount to build and maintain on the ground. Such a scope (or scopes, OWL for example) would yield far more valuable information long-term and be far more easily upgraded in the future.... I think there will always be a place for space-based astronomy, but I would hold off on replacing hubble until we can build one on the moon. That presents a much better long-term prospect (as long as you don't get smacked with an asteroid TOO soon).
That's funny on the one hand, but let's not take it too seriously. A drop in SCO's market cap is no more a vindication of our position than the skyrocketting market cap was a vindication of SCO's. The market does what the market will, and we should take it all with a grain of salt.
Can we once and for all just declare that ANYTHING can be misued
There are degrees of misuse. Yes, a hammer can be used to build a nuclear weapon (well, not really, but you get the idea).
But this technique on the other hand practically invites misuse. Psycotherapy has moved from being a field that was primarily oriented around counseling to a field first-and-foremost about medication. To that particular fox, the hen-house we now present is a tool for electrically modifying mood or stimulus response.
This technology SHOULD be a good thing, but cautious application of the Hipocratic Oath isn't exactly something that this field is known for.
I don't think it's out of line to point out the potential for abuse.
I'm sorry if you find it off-putting to be given the party line. I understand, really.
./autogen.sh --enable-debug=minimum
However, while I would agree that it's unreasonable to be wasteful in your application and just brush it off as "well, hardware/memory/dist/etc is cheap", I also feel that it's only fair to make certain trade-offs that benefit the users of modern hardware when most OS distributions won't pick up a new software version for six months to two years.
An older box is essentially a different platform. That software runs on it at all is cool, but in order to support it well, you really have to do a full port, with all of the tuning that is involved in any port. That would be a great goal for a distribution vendor... to put out the "P1-P3 Optimized Desktop" would be quite and excellent contribution, but to say that making trade-offs like memory-for-speed is unreasonable in the core project seems to me to be a bit difficult to swallow.
There are, of course, many things you can do to enhance performance on low-end boxes:
1. Load a very lightweight, texture-free theme
2. Re-compile all of the core Gnome software and toolkits with env CFLAGS="-O3"
3. Use a light-weight WM like MetaCity
4. Check each core application for performance settings
Following these steps, you can tune your environment to your needs. Good luck!
Disney did Spirited Away for the US market
As well Mononoke (dub script by Neil Gaiman, no less). Mononoke (Web site, DVD), IMHO, was his finest work, and anyone who has not seen it should rush out and grab the DVD.
Trademarks of these films tend to be: children (usually girls) as main characters; flight as a major theme (both magical and realistic, often in the same film e.g. Kiki's); powerful older women (both good and evil); technology as a force of decay or at least at odds with nature.
I would say that his films are the finest examples of children's storytelling to hit the big screen. So much so, in fact, that even jaded adults often find the films captivating and meaningful.
Well then it's your fault.
I know that's harsh, and I'm actually being a bit hyperbolic, but only a bit. If people who have specialized hardware don't contribute, the software won't be tailored to them. You have specialized hardware in that it's fairly old. That means that software won't be customized well for you, but you can help possibly millions of people by working on Gnome and finding the performance gotchas for lower-end systems.
I would expect that in order to perform really well on low-end hardware, Gnome will need some compile-time flags to turn off functionality that on higher-end systems might be more ideal. Perhaps some of it could be made run-time, but there are features (like double-buffering in the toolkit) where I think you're going to need to make sure that NO APPLICATION ANYWHERE can possibly make the mistake of using the feature.
That doesn't mean these are bad features, they're just features that are only appropriate for modern, mainstream hardware.
It's open source. You have the power. Think outside of the proprietary software box!
Ah ok... I thought we were discussing this like rational people, not just flinging random phrases around. Cool, that means I can leave now.
Quote you: "the most you're going to get out of me is that there's an obfuscated Perl contest and no counterpart for Java."
[link mine for emphasis] Note, I'm not familliar with a programming language that lacks such a contest, and C was the first (IOCCC was famous before Perl existed).
Quote you: "operators often have side effects"
You don't actually program in Java, do you? This is just getting silly. Are you saying that Java operators have no side effects?! Let's try out "a=b" for starters....
"there are arcane variables like $["
One man's arcane is another man's "perfectly well documented and easily found via the table of contents, and no it doesn't affect the whole program, read the docs"... but to each his own.
That's beside the point though. You spoke not of variable names, but of syntax.
"as well as the community that uses Perl (there's sort of a celebration of difficult to read code going on)."
Nope. I highly disagree. There is humor and entertainment in whiddling down people's few-line RSA encryption algorithms into the minimum line-count so that it fits on a T-shirt for political reasons... there's command-line usage where how little you type matters, but I don't think anyone celebrates difficult-to-read code in the large... more to the point, those who upload such code to CPAN get the words "maintainable code" explained to them rather harshly.
Again, I was not talking about your feelings about the language or its developers. You said, "there's less obfuscation possible in java syntax". That is incorrect, as far as I know... but feel free to PROVE that wrong.