Parrot is heavy on the vapor and light on the languages
Incorrect. There is a wild difference between alpha an vapor in the open soruce world, and Parrot is distinctly alpha.
Parrot executes 4 languages that I know of, though only 2 well. The two are IMCC (a very lightweight language "skin" on top of Parrot assembly (PASM)) and Fourth.
The other two are Befunge (a toy) and Perl 5. Perl 5 is in alpha release now, and should be stable by the end of the year. Python is expected to be in an alpha state by this summer (for OSCON) and Ruby and Scheme will likely follow.
Is Parrot done to a point you can use it for real work? No. Is Parrot done to a point where it's reasonable to speak about its development progress and potential once released? Certainly.
Take a look at the most recent release of Parrot. It now has objects in the core, JIT, full support for math, Unicode, regular expressions and multi-method dispatch.
Yeah, XP is actually fairly stable. It's still not an OS I would install in production, but it's come a LONG way. I would certainly consider it for desktop work if I didn't already use Linux everywhere, and that's a far cry from NT or 98 where I wouldn't have considered either OS for anything but gaming.
Of course, if I were going to switch desktops at work, it would be to MacOS/X, at this point.
At home I have the game box that runs nothing but XP and games, the laptop and two servers running Linux. They all have comparable uptimes, punctuated mostly by me bringing them down, rather than crashes.
And how is Sun going to force IBM to go along? Sun can abandon their own JVM in favor of the CLR, but theu can't outlaw JVM implementations that they have already licensed.
Sun's Java is the primary engine that people use "in the wild"... I suspect that if Sun ports to CLR, everyone else will throw up their hands and move to that implementation or a competing one on an open CLR implementation.
Like MS or hate them, CLR was built on the back of the mistakes made by Sun in defining the JVM (which, lest we forget, was a damn nice VM at the time). CLR has some features which make it much more desirable for implementing arbitrary languages on top of, and JVM would need a major revamp to match this flexibility... we shall see.
In other news, Parrot is shaping up nicely as the third potential player in this space (second if you don't count JVM because of its Java-centric bias). Parrot is already being targetted by a large number of languages that are starting to move on their (as yet unfinished) implementations now that Parrot has become fairly usable. The addition of objects was holding up the Python and Ruby camps for a while, and while Perl 6 is still awaiting the final definition of objects and modules from Larry Wall, Perl 5's second alpha release to Parrot was finished last week.
What I see as the major win here is that Parrot allows you, the developer, to choose the language that is right for your task, regardless of what language the libraries happen to be written in. You will even be able to do scary things like sub-class a Ruby class in Python, instantiate it and pass the resulting object to a Perl module that uses a C library to process it. This universal interchangability will, I hope, move the language-warring camps up a level of functionality into the application framework space -- a tremendously more useful place to argue which path to choose.
The more important problem solved by texturing the road surface is that there is no point at which the wheel "wants to fall". In other words, you never change the wheel's center of mass vertically, and that means that there is no period in the cycle where you have to pump in an extra amount of energy to raise it's center of mass. On an untextured surface, you not only have the usual rolling friction, but also the rising and dropping of the wheel to overcome (represented by the points where the wheel is flat and you have to pedal hard to raise it or when it is in a diamond position, and you merely tap forward to initiate it "falling" back to flat). This is independant of any technique that might keep the payload / engine from moving up and down.
Textured surfaces have their purposes, but outside of gears and certain printing processes, I can't think of a practical use.
SCO is the very best mirror in which to look if you wish to know what the open source community will look like at its worst. The flaming, hatred and threats are all characteristics that we're not too proud of, but SCO makes us face our demons and admit that we too are no angels.
The number of ways in which the SCO situation is actually good for the open source community are kind of scary.
It's one measure, and as such not an unreasonable one. It doesn't mean that there aren't other valid ways to slice the data that would yield eqaully interesting and possibly contradictory results.
Just as an example of another way of looking at it: living in Boston, I can certainly say that our traditional strength is still firmly in place, we're a college city. No, not in the way that NY is or LA is. Yes, those cities have lots of colleges too, so do most cities.
But, we have colleges the way most cities have fire hydrants. I've never seen another city where traffic drops to about 1/3 of its normal volume during school breaks. Commuting in the summer is SUCH A JOY. We're one of the densest cities in the country, occupying about the size of the LA central Post Office, and most of that area is covered by schools.
Why is this useful? Because MIT, Harvard, Northeastern, Tufts, BU, BC, UMass and many other local schools produce not just graduates but techologies, businesses, infrastructure and more. I work for a company founded by MIT post-grads who spun off their schoolwork as a business. The same was true for one other company I've worked for, and just about EVERY company has benefited from the colleges in some way (hiring at the very least).
Lest I forget, we also have a large number of highly respected specialty colleges which add in an element of niche expertise in many areas. The ones that come to mind at first are Berkely College of Music and The Mass. College of Pharmacy... though you could probably make all sorts of jokes about what sorts of expertise those two would produce together;-)
Back to topic, there are many ways to look at the data and many data-sets to look at. Don't write off this particular report as useless, just don't take ANY such report as conclusive.
No, an implied warranty is not good enough. If someone comes looking to sue over IP violations (SCO is a bad example because, no hyperbole at all here, they're stupid), then you need to know that your vendor a) cares enough to defend their own software b) has the legal/financial means to do so.
Sometimes that's not possible and you need to go with something that doesn't satisfy this rule. That's called taking risk, and a cost/benefit analysis should take that risk into account. It's really not that complex.
You do realize that there are open source applications provided by individuals without "800lb gorillas for lawyers", don't you?
Yes, and while I would use them at home or play with them at work, I would advise against using them for "real work" unless we got them from a vendor like IBM, Red Hat or Novell (just as examples).
You're taking just as much risk using software that is not backed by a company with lawyers who have a vested interest in the commercial viability and reputation of that software regardless of how much source code you have available (in this sense, though source protects you against other risks).
Ok, so the question is... does your vendor have lawyers who have a vested interest in the commercial viability and reputation of that software? If the answer is yes, STOP. You're done. Open source vs. closed source is a red herring and to imply otherwise is, I think, rather misleading.
You do realize that there are closed-source applications provided by individuals without corporate backing out there, don't you? I don't mean that to be insulting, but I'm honestly not sure if you started this discussion thinking about that. Some are works for hire, some are distributed freely and yet others are sold by people who don't have the ability (for whatever reason) to start a company that can market/publish the software.
Just because open source software is far more popular on average is no reason to treat it differently; if you have a business that is going to be concerned with its long-term future, get your software from a reputable vendor with 800lb gorillas for lawyers.
Backports are evil for exactly the reason you describe
I don't think I described anything evil at all. Backporting functionality should be avoided when possible only because it's easier to let someone else maintain the software for you. But, nearly every piece of software in a traditional open source OS distribution (from FreeBSD to Fedora) will involve local changes, feature additions etc.
At the very least, if you've got a security update, it's just downright wrong to require that all of your users upgrade to some random next version of that package just to make your OS secure. You released an OS and should be responsible for fixing bugs without introducing spurious breakage or feature-creep.
Re-read what I said (past your short clip of my statement). You're agreeing with me, and I responded to the issue of PARTS of a large system like Gnome violating patents.
Second, you cite a Sun patent. Sun has contributed a great deal to Gnome and Gtk+... being co-authors I don't see how their own patent would be of concern.
Third, the glib object system (GObject) would be a pain in the *** to replace, but there's no reason it could not be. The obvious solutions would be a) proceduralize the whole thing or b) move to an OO language and re-implement GObject as a wrapper around that language's functionality (thus, perhaps, avoiding the patent).
Fourth, I only scanned the patent, but it seems fairly specific to XView.
the best solution is to do whatever is most efficient at performing those tasks
And if you've ever had to pick up and maintain a system from someone who left you will know that this is just about 100% wrong.
The best solution is one that works and is maintainable. If you are willing to put in the extra work involved in making your from-source installations clearly maintainable and upgradable so that the next guy isn't going to have to spend 6 hours learning how everything works when he needs to upgrade foobnitz to version 2.0, then great. If not, think about letting someome else do that work for you.
"There are just TOO MANY software patents out there for a developer to worry about avoiding them"
I disagree on several points. First off, there is wide precident for file formats that are patented or contain patented encodings being ripped out of applications (LZW comes to mind, but many other formats have been removed for this sort of reason).
What's more, you're not talking about a case where these folks could claim ignorance. It is widely known even to many lay users that MP3 uses patented encodings. Red Hat and Fedora could not hide behind ignorance in thise case.
But, the most DANGEROUS statement that you make here is, ""Willful ignorance" is the official policy of the Linux Kernel developers, who've had some formal legal advice on the matter". First off, there is no official policy. One developer (albeit the lead developer for most purposes) has aspoused this position, but I guarantee you that that's not the IBM developers' veiw, whose activities are scrutinized by IBM's legal department. It's also not at all reasonable to suggest that one should take someone else's example as "safe" simply on the basis of your belief that their legal advice was sound.
"For example, both Debian and Red Hat are violating patents by shipping GNOME, so should they stop that too on the off-chance of an enforcement?"
Gnome does not violate any patents (for starters, I've never seen a patent that broad). Some Gnome technologies may, and yes, I think they should be stripped out before a vendor makes them available to their customers.
It's not that this isn't damaging, but we need to start accepting that software patents stifle innovation and fix the process. We can't just act as if there is no problem and build our house on a foundation of poor legal decisions.
This is still pre-release so your comments aren't too unreasonable, but just so that people understand that this isn't always the right way to look at the problem:
The way version numbering works in Red Hat (and by extension, Fedora), is that the package version number is the version of the software that the package STARTED from, but it may have little to do with the state of the software as installed.
For example, you might have openssh version 3.1 on a box, but if you look at the SRPM for that package, you will find security bug-fixes applied from all of the openssh versions between 3.1 and the current day.
The SRPM is essentially three things: A tar-ball(s) of the original source as shipped by the developers; a set of patches or add-ons that the vendor has decided to include and a Makefile-like thing that RPM knows how to read called a spec file.
Thus, FC2 might ship with Linux 2.6.4, but that doesn't mean it lacks a feature or bug-fix from 2.6.5... you have to check the patch-set in the SRPM to know that.
Every time the contents of that SRPM are updated, the RPM version changes, so you'll see something like "foo-1.2-2", where 1.2 is the version of foo that the SRPM was based on, and this is the second build from Fedora.
If Debian has MP3 support, then they are violating the patents. Debian can do this just as long as the holders of said patents let them get away with it, but I don't recommend it. FAR more importantly, I don't recommend that anyone attempt to "keep up" with other platforms that violate patents.
"What? Sorry, no. More than ten years ago, I was doing word-processing"
Please, go back and re-read what I wrote. You clearly to not fit into the class of users who have changed the industry by bringing in new viewpoints and tasks in the last 10 years. Rather, you were an early adopter, and the tools were suited to the needs of you and those like you 10 years ago.
Also, don't assume I mean MS Word when I say word processing.
This is exactly what I was refering to. You get the people who say that "the UNIX desktop hasn't changed much at all since X10 in the late 80s", but that's just fundamentally untrue. It's only true that when those people are done throwing away all of the "bells and whistles" that they feel they don't need, the same infrastructure can still be found.
Well, true, but those bells and whistles were added precisely because the needs of the next generation of users was different, and the platform grew to encompas their needs.
Sounds great. Given your track-record, I can't wait to see what you're refering to.
Gtk+ is a nice toolkit, and had a very novel (Novell?;-) approach to C programming, but almost all of that has been factored out at this point, and I could certainly see a Gnome/Gtk hybrid library sitting on top of Gdk and Glib that would be far, far better suited to modern development.
"try and do a cost analysis of the Evolution and Kontact PIM suites"
Let's not get into the "we developed X faster than Y" thing... If you want to prefer your tool to some other, great, go have fun with it. But, don't complain about Gtk because you don't like the time that the developers spent releasing a version for you.
"The hype, vapourware and blog entries have got to stop Miguel"
Miguel has delivered on a great many things, and while (like all developers) he speculates about "the nifty next tools", I don't think it's reasonable to try to shut up those you disagree with. Miguel, you may not have noticed, is not a politician, and you don't get a vote in his public discorse.
"seems like i remember seeing a frontend for nethack that did just this"
Yep, and just about everyone I know who tried both found that the graphics were distracting.
The thing about text is that it's about as compressed as you can get the information that you need, and still allow your brain to model a full 2D environment. I can keep track of a HECK of a lot more information when it's desplayed as text characters, rather than pictographs of some sort.
When you see someone playing ADOM or Nethack who really knows the game, you find that they are assimilating the information on the screen FAR faster than anyone could assimilate graphics. Graphics are just too complex and require too much processing to analyze.
I'm not sure I buy that phrase. The display for Nethack, ADOM, etc. displays as much information as I tend to need in a single-person, turn-based, fantasy adventure RPG. Why do I need flashy graphics? Are they there to distract me from something else?
If I want great art, I can get CDs full of wonderful pictures, but that's not why I play a game: I play it for the challenge.
Now, I'm not saying Mission: Thunderbolt doesn't have anything going for it. It might be a great game, but I don't see how snazzy graphics are anything more than a selling point for people who have not already come to understand what these games have to offer.
-Harmil, 20th level @
PS: In the words of The Matrix, "after a while you don't even see them anymore... I just see" a dragon, a cockatrice,...
"What of open source software that no vendor chooses to adopt?"
That's too limited a question. The answer is the same for, "what of software that no vendor chooses to adopt". You're taking just as much risk using software that is not backed by a company with lawyers who have a vested interest in the commercial viability and reputation of that software regardless of how much source code you have available (in this sense, though source protects you against other risks).
I would never run a large business on software that did not have such backing unless I had no choice. Sometimes you have no choice, but if the need is that strong, you will usually see a vendor spring up around it. Often several.
Slashdot Mirror
Parrot is heavy on the vapor and light on the languages
Incorrect. There is a wild difference between alpha an vapor in the open soruce world, and Parrot is distinctly alpha.
Parrot executes 4 languages that I know of, though only 2 well. The two are IMCC (a very lightweight language "skin" on top of Parrot assembly (PASM)) and Fourth.
The other two are Befunge (a toy) and Perl 5. Perl 5 is in alpha release now, and should be stable by the end of the year. Python is expected to be in an alpha state by this summer (for OSCON) and Ruby and Scheme will likely follow.
Is Parrot done to a point you can use it for real work? No. Is Parrot done to a point where it's reasonable to speak about its development progress and potential once released? Certainly.
Take a look at the most recent release of Parrot. It now has objects in the core, JIT, full support for math, Unicode, regular expressions and multi-method dispatch.
That's not vapor in my book.
Yeah, XP is actually fairly stable. It's still not an OS I would install in production, but it's come a LONG way. I would certainly consider it for desktop work if I didn't already use Linux everywhere, and that's a far cry from NT or 98 where I wouldn't have considered either OS for anything but gaming.
Of course, if I were going to switch desktops at work, it would be to MacOS/X, at this point.
At home I have the game box that runs nothing but XP and games, the laptop and two servers running Linux. They all have comparable uptimes, punctuated mostly by me bringing them down, rather than crashes.
And how is Sun going to force IBM to go along? Sun can abandon their own JVM in favor of the CLR, but theu can't outlaw JVM implementations that they have already licensed.
Sun's Java is the primary engine that people use "in the wild"... I suspect that if Sun ports to CLR, everyone else will throw up their hands and move to that implementation or a competing one on an open CLR implementation.
Like MS or hate them, CLR was built on the back of the mistakes made by Sun in defining the JVM (which, lest we forget, was a damn nice VM at the time). CLR has some features which make it much more desirable for implementing arbitrary languages on top of, and JVM would need a major revamp to match this flexibility... we shall see.
In other news, Parrot is shaping up nicely as the third potential player in this space (second if you don't count JVM because of its Java-centric bias). Parrot is already being targetted by a large number of languages that are starting to move on their (as yet unfinished) implementations now that Parrot has become fairly usable. The addition of objects was holding up the Python and Ruby camps for a while, and while Perl 6 is still awaiting the final definition of objects and modules from Larry Wall, Perl 5's second alpha release to Parrot was finished last week.
What I see as the major win here is that Parrot allows you, the developer, to choose the language that is right for your task, regardless of what language the libraries happen to be written in. You will even be able to do scary things like sub-class a Ruby class in Python, instantiate it and pass the resulting object to a Perl module that uses a C library to process it. This universal interchangability will, I hope, move the language-warring camps up a level of functionality into the application framework space -- a tremendously more useful place to argue which path to choose.
The more important problem solved by texturing the road surface is that there is no point at which the wheel "wants to fall". In other words, you never change the wheel's center of mass vertically, and that means that there is no period in the cycle where you have to pump in an extra amount of energy to raise it's center of mass. On an untextured surface, you not only have the usual rolling friction, but also the rising and dropping of the wheel to overcome (represented by the points where the wheel is flat and you have to pedal hard to raise it or when it is in a diamond position, and you merely tap forward to initiate it "falling" back to flat). This is independant of any technique that might keep the payload / engine from moving up and down.
Textured surfaces have their purposes, but outside of gears and certain printing processes, I can't think of a practical use.
Just sounds like an NFS-based apt to me... and then ROX has hooks for it... ok.
Am I missing some actuall revolutionary feature, or did the submitter just get some bad koo aid?
How exactly did I compare anyting to SCO as a negative? I've simply pointed out OUR reaction to SCO, and said nothing about THEM.
I think you were a bit to trigger-happy with a comment you'd been waiting to post or you just mis-read my statement.
SCO is the very best mirror in which to look if you wish to know what the open source community will look like at its worst. The flaming, hatred and threats are all characteristics that we're not too proud of, but SCO makes us face our demons and admit that we too are no angels.
The number of ways in which the SCO situation is actually good for the open source community are kind of scary.
Or perhaps just... "you are false data [...] Let there be light."
;-)
I won't give away where the quote is from, since out-of-context it's not much of a spoiler
Just wait for SCO-IPLint... *shudder*
It's one measure, and as such not an unreasonable one. It doesn't mean that there aren't other valid ways to slice the data that would yield eqaully interesting and possibly contradictory results.
;-)
Just as an example of another way of looking at it: living in Boston, I can certainly say that our traditional strength is still firmly in place, we're a college city. No, not in the way that NY is or LA is. Yes, those cities have lots of colleges too, so do most cities.
But, we have colleges the way most cities have fire hydrants. I've never seen another city where traffic drops to about 1/3 of its normal volume during school breaks. Commuting in the summer is SUCH A JOY. We're one of the densest cities in the country, occupying about the size of the LA central Post Office, and most of that area is covered by schools.
Why is this useful? Because MIT, Harvard, Northeastern, Tufts, BU, BC, UMass and many other local schools produce not just graduates but techologies, businesses, infrastructure and more. I work for a company founded by MIT post-grads who spun off their schoolwork as a business. The same was true for one other company I've worked for, and just about EVERY company has benefited from the colleges in some way (hiring at the very least).
Lest I forget, we also have a large number of highly respected specialty colleges which add in an element of niche expertise in many areas. The ones that come to mind at first are Berkely College of Music and The Mass. College of Pharmacy... though you could probably make all sorts of jokes about what sorts of expertise those two would produce together
Back to topic, there are many ways to look at the data and many data-sets to look at. Don't write off this particular report as useless, just don't take ANY such report as conclusive.
No, an implied warranty is not good enough. If someone comes looking to sue over IP violations (SCO is a bad example because, no hyperbole at all here, they're stupid), then you need to know that your vendor a) cares enough to defend their own software b) has the legal/financial means to do so.
Sometimes that's not possible and you need to go with something that doesn't satisfy this rule. That's called taking risk, and a cost/benefit analysis should take that risk into account. It's really not that complex.
You do realize that there are open source applications provided by individuals without "800lb gorillas for lawyers", don't you?
Yes, and while I would use them at home or play with them at work, I would advise against using them for "real work" unless we got them from a vendor like IBM, Red Hat or Novell (just as examples).
You do realize that there are closed-source applications provided by individuals without corporate backing out there, don't you? I don't mean that to be insulting, but I'm honestly not sure if you started this discussion thinking about that. Some are works for hire, some are distributed freely and yet others are sold by people who don't have the ability (for whatever reason) to start a company that can market/publish the software.
Just because open source software is far more popular on average is no reason to treat it differently; if you have a business that is going to be concerned with its long-term future, get your software from a reputable vendor with 800lb gorillas for lawyers.
Backports are evil for exactly the reason you describe
I don't think I described anything evil at all. Backporting functionality should be avoided when possible only because it's easier to let someone else maintain the software for you. But, nearly every piece of software in a traditional open source OS distribution (from FreeBSD to Fedora) will involve local changes, feature additions etc.
At the very least, if you've got a security update, it's just downright wrong to require that all of your users upgrade to some random next version of that package just to make your OS secure. You released an OS and should be responsible for fixing bugs without introducing spurious breakage or feature-creep.
Re-read what I said (past your short clip of my statement). You're agreeing with me, and I responded to the issue of PARTS of a large system like Gnome violating patents.
Second, you cite a Sun patent. Sun has contributed a great deal to Gnome and Gtk+... being co-authors I don't see how their own patent would be of concern.
Third, the glib object system (GObject) would be a pain in the *** to replace, but there's no reason it could not be. The obvious solutions would be a) proceduralize the whole thing or b) move to an OO language and re-implement GObject as a wrapper around that language's functionality (thus, perhaps, avoiding the patent).
Fourth, I only scanned the patent, but it seems fairly specific to XView.
the best solution is to do whatever is most efficient at performing those tasks
And if you've ever had to pick up and maintain a system from someone who left you will know that this is just about 100% wrong.
The best solution is one that works and is maintainable. If you are willing to put in the extra work involved in making your from-source installations clearly maintainable and upgradable so that the next guy isn't going to have to spend 6 hours learning how everything works when he needs to upgrade foobnitz to version 2.0, then great. If not, think about letting someome else do that work for you.
"There are just TOO MANY software patents out there for a developer to worry about avoiding them"
I disagree on several points. First off, there is wide precident for file formats that are patented or contain patented encodings being ripped out of applications (LZW comes to mind, but many other formats have been removed for this sort of reason).
What's more, you're not talking about a case where these folks could claim ignorance. It is widely known even to many lay users that MP3 uses patented encodings. Red Hat and Fedora could not hide behind ignorance in thise case.
But, the most DANGEROUS statement that you make here is, ""Willful ignorance" is the official policy of the Linux Kernel developers, who've had some formal legal advice on the matter". First off, there is no official policy. One developer (albeit the lead developer for most purposes) has aspoused this position, but I guarantee you that that's not the IBM developers' veiw, whose activities are scrutinized by IBM's legal department. It's also not at all reasonable to suggest that one should take someone else's example as "safe" simply on the basis of your belief that their legal advice was sound.
"For example, both Debian and Red Hat are violating patents by shipping GNOME, so should they stop that too on the off-chance of an enforcement?"
Gnome does not violate any patents (for starters, I've never seen a patent that broad). Some Gnome technologies may, and yes, I think they should be stripped out before a vendor makes them available to their customers.
It's not that this isn't damaging, but we need to start accepting that software patents stifle innovation and fix the process. We can't just act as if there is no problem and build our house on a foundation of poor legal decisions.
This is still pre-release so your comments aren't too unreasonable, but just so that people understand that this isn't always the right way to look at the problem:
The way version numbering works in Red Hat (and by extension, Fedora), is that the package version number is the version of the software that the package STARTED from, but it may have little to do with the state of the software as installed.
For example, you might have openssh version 3.1 on a box, but if you look at the SRPM for that package, you will find security bug-fixes applied from all of the openssh versions between 3.1 and the current day.
The SRPM is essentially three things: A tar-ball(s) of the original source as shipped by the developers; a set of patches or add-ons that the vendor has decided to include and a Makefile-like thing that RPM knows how to read called a spec file.
Thus, FC2 might ship with Linux 2.6.4, but that doesn't mean it lacks a feature or bug-fix from 2.6.5... you have to check the patch-set in the SRPM to know that.
Every time the contents of that SRPM are updated, the RPM version changes, so you'll see something like "foo-1.2-2", where 1.2 is the version of foo that the SRPM was based on, and this is the second build from Fedora.
If Debian has MP3 support, then they are violating the patents. Debian can do this just as long as the holders of said patents let them get away with it, but I don't recommend it. FAR more importantly, I don't recommend that anyone attempt to "keep up" with other platforms that violate patents.
"What? Sorry, no. More than ten years ago, I was doing word-processing"
Please, go back and re-read what I wrote. You clearly to not fit into the class of users who have changed the industry by bringing in new viewpoints and tasks in the last 10 years. Rather, you were an early adopter, and the tools were suited to the needs of you and those like you 10 years ago.
Also, don't assume I mean MS Word when I say word processing.
This is exactly what I was refering to. You get the people who say that "the UNIX desktop hasn't changed much at all since X10 in the late 80s", but that's just fundamentally untrue. It's only true that when those people are done throwing away all of the "bells and whistles" that they feel they don't need, the same infrastructure can still be found.
Well, true, but those bells and whistles were added precisely because the needs of the next generation of users was different, and the platform grew to encompas their needs.
Sounds great. Given your track-record, I can't wait to see what you're refering to.
;-) approach to C programming, but almost all of that has been factored out at this point, and I could certainly see a Gnome/Gtk hybrid library sitting on top of Gdk and Glib that would be far, far better suited to modern development.
Gtk+ is a nice toolkit, and had a very novel (Novell?
"try and do a cost analysis of the Evolution and Kontact PIM suites"
Let's not get into the "we developed X faster than Y" thing... If you want to prefer your tool to some other, great, go have fun with it. But, don't complain about Gtk because you don't like the time that the developers spent releasing a version for you.
"The hype, vapourware and blog entries have got to stop Miguel"
Miguel has delivered on a great many things, and while (like all developers) he speculates about "the nifty next tools", I don't think it's reasonable to try to shut up those you disagree with. Miguel, you may not have noticed, is not a politician, and you don't get a vote in his public discorse.
"seems like i remember seeing a frontend for nethack that did just this"
Yep, and just about everyone I know who tried both found that the graphics were distracting.
The thing about text is that it's about as compressed as you can get the information that you need, and still allow your brain to model a full 2D environment. I can keep track of a HECK of a lot more information when it's desplayed as text characters, rather than pictographs of some sort.
When you see someone playing ADOM or Nethack who really knows the game, you find that they are assimilating the information on the screen FAR faster than anyone could assimilate graphics. Graphics are just too complex and require too much processing to analyze.
"ridiculous ANSI graphics"
...
I'm not sure I buy that phrase. The display for Nethack, ADOM, etc. displays as much information as I tend to need in a single-person, turn-based, fantasy adventure RPG. Why do I need flashy graphics? Are they there to distract me from something else?
If I want great art, I can get CDs full of wonderful pictures, but that's not why I play a game: I play it for the challenge.
Now, I'm not saying Mission: Thunderbolt doesn't have anything going for it. It might be a great game, but I don't see how snazzy graphics are anything more than a selling point for people who have not already come to understand what these games have to offer.
-Harmil, 20th level @
PS: In the words of The Matrix, "after a while you don't even see them anymore... I just see" a dragon, a cockatrice,
"What of open source software that no vendor chooses to adopt?"
That's too limited a question. The answer is the same for, "what of software that no vendor chooses to adopt". You're taking just as much risk using software that is not backed by a company with lawyers who have a vested interest in the commercial viability and reputation of that software regardless of how much source code you have available (in this sense, though source protects you against other risks).
I would never run a large business on software that did not have such backing unless I had no choice. Sometimes you have no choice, but if the need is that strong, you will usually see a vendor spring up around it. Often several.