Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 1
Hi,
implement it in itself: Not sure what your point is, but you can certainly implement the Python VM in itself. The Python VM is actually quite portable as is demonstrated by the excellent Java based implementation found in Jython.
PyPy is an implementation of the python interpreter, in python, that is seeking to optimize the interpreter. Is there any similar project in Perl?
Too dog slow? Uh, no. See the Twisted project for an example of an "internet event server" whose web server implementation is faster-- and more flexible-- than apache.
Umm... not to look a gift horse in the mouth, but, do you have any numbers on this? As far as I know, Twisted is only faster than Apache on some configurations of MacOS X. Generally it benchmarks slower. We have a lot of optimization left to do in that arena. Of course, twisted.web has been powering our moderately high-traffic site for well over a year at this point, as this graph will show, and we've had zero performance problems.
Twisted Web is "fast enough", and nobody seems seriously interested in optimizing it, but I would hesitate to boldly claim it's "faster than" something else if it doesn't have a clear advantage. I'd have no problem if you said it was faster than Jigsaw, for example: if you want to talk about dog-slow systems, that's a good example.
With a real production webserver like Apache, though, there are a lot of variables to tune. There are obscure interactions to be taken into account. Twisted will surely be slower than well-configured Apache on an SMP system, for example, unless you've got 2 processes working in parallel behind a proxy... and of course, then there's dynamic content, which is an entirely different set of measurements.
The issues are complex, and it doesn't help to advocate the project by oversimplifying them.
What you say is true, but potentially misleading: one thing that you have to consider is that a good game engine will reduce, by a fairly significant factor, the amount of effort required to produce the content for the game. The logic for the game is a grey area, where certain bits of it are "engine" and others are not, but the logic is traditionally easy to develop but hard to decide on. Extreme Programming (http://xprogramming.com) can help here, because getting a working prototype early on will allow game designers to manipulate the design concretely in the short term, reducing the amount of overhead it requires to fix bad decisions -- and you WILL make bad decisions.
A good engine can only help so much, but a bad game engine can add an arbitrarily large amount of overhead to your art production pipeline and game logic code development.
If you're really trying to develop a massively multiplayer game, make sure that you're ready for a collossal failure.
I can already see the debate about C# heating up over this -- but that's tangential to the real problem. It's not that C# will doom your project, it's that you wouldn't choose C# if you knew what you were doing (and your project weren't already doomed).
First, my personal suggestion (and I say this as a developer with 2 years commercial MMP development experience at this point): EITHER you want to write an infrastructure, OR you want to write a game. Writing both by yourself will take you the better part of 10 years. Having another programmer around who is doing the other part is handy -- but making sure that they are separate tasks is important. I recommend ditching C# to use Python, and my personal infrastructure project, the Twisted network framework (http://twistedmatrix.com), but if you're not going to use that, then find another high-level language with good asynchronous networking support and the ability to load code at runtime. Other good possibilities are Common Lisp and Scheme.
If you don't have any experience in the area, and this is for an Open Source project, join an existing project and learn some things from there. I can also highly recommend getting involved with a failed project in the game industry to see how difficult the whole thing really is:-)
Be prepared to fail at least once. The number of failure points in an MMP project is astronomical: client code, server code, internet latency, even the community itself is a potential "bug". If your technology is great and your game is fun, but it attracts really mean-spirited people for some reason, you might see your servers empty out over the course of a few months, or never even get to a real "massively" multiplayer state.
we know it will stand up, and if it doesn't, there are people to sue.
Please re-read your licensing agreements with these respective vendors. You can't sue them, you can't even think about suing them. With oracle, I think they can actually have all of your children killed if you think about suing them and they find out.
It's amazing how long elementary FUD like this can abound, especially after it's been refuted countless times in OSS diatribes. Who do you know who has ever sued Microsoft for lost data and won? Have you ever heard of Sun getting busted up over a hardware failure? It is EXTREMELY difficult to prove that the system failed in the first place (who's to say you configured it correctly? not the experts from Oracle, that's for sure), and even if you can, you agree to a LOT of things when you put that software on your server.
I'd trust Postgres against Linux any day (and YES, I do work at the "enterprise level") simply because at least they're straightforward about there being no-one to sue. If I really needed to get hard-core (not too many machines, lots of RAM and processor, zero tolerance for failure) maybe FreeBSD would fit the bill.
Most likely though, I would be averse to anything that involved x86 hardware for real reliability. So it would probably be NetBSD.
This is, perhaps, one of those situations where you are rather unlikely to find an OSS solution. An enterprise-level operating system kernel is not exactly an overnight hack. It would take an enormous kind of time and effort to put an enterprise-level UNIX kernel together.
I'm not even sure that an enterprise-level OSS kernel makes sense. If you're talking about an enterprise-level product, you probably have the resources to afford to purchase a commercial Operating System. Both Sun and QNX have decades of experience building robust, rock hard, operating systems that you can bet your company jewels on, and both companies have x86 versions of their OSs. I'm not sure about Compaq (Digital), they may have an x86 version of their OS too.
Right now, attempting to deliver an OSS kernel that can beat time-tested operating systems from Sun and QNX would be quite a challenge, to say the least. People will just have to accept the fact that OSS can't solve every problem in the world. It's certainly feasible that one day Sun or QNX might decide to release their respective kernels under an OSS license (which should certainly be quite a shock to many people), that's probably the most likely scenario.
Before the advent of the 'net, the ability of a human being to contain ideas was pretty severely limited by their cranial capacity.
Ideas were not expressions on a purely quantitative basis -- x=5 is an idea. x=5.81356108301851851760183838886151373753111185 was an expression; unless you were exceptionally bright. Lengthen it by a few hundred digits, and it's an expression for everybody, since no-one can remember it without writing it down.
"Defacing tree carcasses" has a lot of protected rights in the US because that's the only way that we used to be able to get those ideas into a format that we could use efficiently. "The Press" was a sacred and special piece of technology.
Authoritarians even tolerated it, since it was a pretty hefty physical thing, and it meant that one could regulate ideas using the same rules that you would use to regulate physical objects, as long as you applied a few special rules to the way things were copied; and this made sense, too, due to the various technical aspects of physically producing a book. (The rationale behind copyright was not paying the author of the book -- it was the associated cost of figuring out where to put the letters on the page so that they would fit. This is not an easy problem to solve... but now we can all do it automatically, for free, thanks to TeX.)
Ideas are no longer different from expressions, and this is Katz's point. Now, it's possible to put an entire book on a floppy disk in under a minute, and this costs the original publisher exactly the same as it costs the next guy who comes along and wants to make a knockoff version. People are no longer arguing over how to sell the physical objects (books, disk drives, or what have you) but how to sell the information itself, in a pure form, over the ether.
You may notice that I've overlooked the fact that computers are still separate from human beings, just as paper is. I don't believe they are -- I interact with more people via my keyboard than with my voice. My "internet persona" has a better memory than I do, because of the vast amount of data instantly available on the web, and the information stored in my own home directory. I can think faster, better, and more clearly when hooked up to such a machine, because I can swap huge amounts of state out to it without worrying about it suddenly 'forgetting'. (Windows NT, of course, is a leprosy of the mind.)
The distinction in beliefs about intellectual property may stem from the degree to which we percieve ourselves to be cyborgs, augmented by our computers, versus the degree to which we view computers as merely tools that we use. If you see the computer as just a fancy VCR, you're probably ambivalent about having it regulated -- if it's an intrinsic part of your brain, though, you probably feel a little more strongly about it.
Since we seem to be resorting to the arguement by authority, this is from someone with extensive experience with both perl and python. I am writing a large application in python, and I'm very pleased with it, and I've written several large applications in perl in the past.
What? Because Python forces you to a strict coding style doesn't mean that your code is "correct". It's still possible to write a bad algorithm in Python, just as it is in Perl.
Yes, you're correct. It's also possible to write correct, clean, fast programs in x86 assembler. One could even argue that it is equally possible to write everything directly to ELF binary format. -- decent hex-editors exist, and the format is well defined. However, the whole point of language design is to encourage certain practices, not to make them possible. Python encourages writing clean, consistent code. This makes it easier to deal with. If your code is formatted in a very specific style and written consistently, it's more likely that it will be correct, although it's not garuanteed.
Perhaps you should actually point out some limitations of Perl's OOP. Maybe you could also explain what this has to do with your own code quality.
$x->{'y'} versus x.y -- and let's not forget about x.__class__=mypackage.MyClass. Can you even do the latter in perl?
The distinction seems pretty clear to me... perl's class / package syntax is MUCH obviously cruftier. If you think that it's not... well, then use perl for OOP. We disagree.
What are you talking about? Sure it's possible to write Perl code on one line, just as in many other languages. Unless you're an idiot, or purposefully writing obfuscated code, it's generally not done. I'm sick of all these comments complaining about how hard Perl code is to read. Providing that:
a) you actually know the language, and b) the code was written by someone who actually knows the language
You should have zero problems with readability. Remarkably enough, the above applies for nearly every other programming language.
Have you ever tried to read befunge, or brainf***? I know these languages, and this is certainly NOT true for them. Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing. In fact, a quote from Larry Wall himself is "admittedly, readability suffers..."
Perl is not as readable as python. If you don't have any trouble reading perl, that's anecdotal evidence... there is a statistically significant number of people who don't have any problems -- and in fact, enjoy -- reading python (read the python mailinglists, or c.l.python, or www.python.org, or #python on IRC... I've been to the perl equivalents, and I've never seen them advertising readability or maintainability), because it was designed to encourage that. This doesn't mean perl is worthless: it's a language feature of python to be consistent and easy to read. It is a language feature of perl to be terse and easy to write.
Finally, consider this python statement: x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]. I admit that perhaps I'm not the swiftest perl programmer ever, but it is certainly not that easy to make a data structure which is a list of strings, hashes of strings and lists, and lists of lists in perl. The syntax gets really hideous and doesn't mean what it looks like it should. (I can't even come up with a way to write that in perl on they short notice required for posting this comment: perhaps a better perl hacker than I can elucidate..)
First of all, let me say that I think we can have a discussion about languages on slashdot WITHOUT flaming each others' brains out. I will do my best to respond to these comments in the civil tone in which they were first stated.
Now, on to the indentation: I am switching my "large project" from Java to CPython, explicitly because it *does* have such strict indentation rules. If your project is large and has to be maintained by many people, it's VERY important that the indentation be consistent.
One thing that I will agree is an annoyance in python is copying and pasting -- but one thing you're missing if you believe this is an important feature for a language is you should never ever copy and paste code! If you're repeating yourself, you should have to stop and think, "Do I really need to do this?" I have hit that a few times, and after middle-clicking, while I was correcting my indentation, I realized that I should really be using a subroutine or some sort of object abstraction for whatever it was I was copying.
This is also why I believe Python is better suited towards being a systems language, despite it's creators protestations about it being a scripting language -- when I have simple scripting to do, perl would win out. Although I'll dump on Perl in a strictly perl-versus-python debate, it is completely indespensable to me as a 'better sed'. For one-shot, throwaway programs, it is almost always better than python.
Finally, about splitting long lines where you have a long list of arguements: again, you really shouldn't have arguement lists that long. This isn't really a hard-and-fast programming rule though, so if you *do* run into that, the rule in python is simple. Break lines on the commas. Indent them in the same way you would in C. Xemacs does this for me automatically. This never really occurred to me as a problem, and I do it all the time.
Basically, it's a bad idea to mix tab and space indentation. I prefer 1 tab == 1 indent, but the official dogma on the matter is that one tab is equivalent to eight spaces. (Hence, if your editor displays a tab as 4 spaces, as mine does, it's REALLY bad to mix tabs and spaces.) Regardless of this limitation, python is my favorite language, and I've only discovred it recently.
"Consumers could not turn from Intel-compatible PC operating systems to Intel-compatible server operating systems without incurring substantial costs, since the latter type of system is sold at a significantly higher price than the former. A consumer intent on acquiring a server operating system would also have to buy a computer of substantially greater power and price than an intel-compatible PC, because server operating systems generally cannot function properly on PC hardware.... "
I don't think the judge "gets it" at all.
First of all, that is blatantly incorrect. The costs associated with switching from a "PC operating system" to a "server operating system" (I assume he means Win98/BeOS vs. commercial UNIX, since he's obviously not considering linux or *BSD.) is not the cost of the system itself, but the re-education and adjustment period of figuring out how the new system works. Consider the cost of a company switching to linux. Is $2.00 for the CD really going to set you back? Even Solaris x86 can be had for a fairly reasonable pricetag, compared to the maintenance cost of NT... but teaching everyone in the office to use an entirely new operating environment could really bite into your computing budget.
I'm as happy as the next guy that MS is getting kicked in the balls, and I'm glad to see their stock dropping. Since our stupid system of intellectual property (how did we start to consider an operating system with no support and no features a salable good?), enforced by our government, is what got MS into this sweet position to begin with, it's nice to see it turn around and bite them on the ass. But we should realize what it is: this finding of fact is not well informed. It is a case of Sun FUD + Netscape FUD + Corel FUD + DOJ FUD > MS FUD. Granted, Sun and Corel and NS and the DOJ have more truth on their side, but they are NOT interested in painting an accurate picture to the judge than Microsoft is. And, as we can see from the fact that the judge classifies "servers" and "PCs" as two magical, completely disparate kinds of hardware, this can lead to some pretty severe misunderstandings. I really hope that the precedents this sets are never used again...
That said, I also hope this drives their stock price through the floor:-). I just wish it had been a suit about fraud, since that's what I really object to -- all the lying that they do in their advertising, in their prospectuses... hell, they even lied to the court, repeatedly and under oath.
The hordes of script-kiddies who bombarded that nice lady over at Unisys with vulgar hate-mail actually have a point.
First of all, Unisys knows that they have pissed some people off now. They understand that it's not just a few random idiots, but a well-organized (if immature) movement of at least several thousand people.
Second, Unisys's point (in a nutshell) is: "We don't mind if you use Licensed Software (read: products from people we are extorting from) to create GIFS -- as long as it's from a Reputable Company (read: an entrenched part of the military-industrial complex) you don't have to worry." This *is* immoral, vulgar, distasteful, and stupid. We can't ignore the fact that it is a horrible abuse of the U.S.'s patent system, whether or not that system is broken. I'm NOT going to license an idea that I could work out how to do on my own time by reading published specifications to write software that I'm not going to sell anyway, and it's totalitarian to insist that I do so.
Unisys is saying that they have the right to charge you an arbitrarily large sum of money for a product which they had nothing to do with the development of (I'm sure no Unisys code was used in the creation of the Gimp) based on the content of your web-site. First amendment anyone?
Third, that "nice lady" is working for a large, powerful, horrible corporation. If she can't deal with the orwellian machinations of her employer, she should quit, not be portrayed as a heroine for reading all the hate mail that was indended for her boss. Unfortunate that nice people have to get slagged sometimes for things that aren't directly their fault -- but imagine a pretty, well-spoken girl working as the receptionist for the American Nazi Party. A similiar article could be written about her -- "To all you jews who were harrassing Christina, you should really apologize!" Even if she just answered the phones for them, her presence there relates her to them, and makes her responsible by extension.
If you think my comparison to Nazism is a bit extreme, keep in mind what Unisys wants to do here -- they want to own the web. Right now, they can only lay claim to the LZW-compressed parts of it, but they're not providing a service to consumers, they're extorting money from random people who happen to live in the U.S. and use their stupid graphics format.
Luckily, we have a choice. We can use PNG. I certainly plan to: but not because of Unisys's patent -- it's because it's a better graphics format. What would a boycott say about patent law, anyway? What if someone patents some relevant compression algorythm for PNG, or JPEG, and then all of a sudden everyone in the world owes 15 years of late-fees for not paying their "licensing" bills.
Some laws should not be obeyed, and this patent law is one of them. Don't be scared of the big, bad Unisys. If they actually start bothering you, form user groups and start a class-action suit -- I'm sure that given the incredibly long time they haven't been enforcing this and the number of public-domain implementations of LZW would be ample legal grounds for a case (although not a victory by default).
Unisys did not sell me anything, not even a piece of software (I'm not a total FSF zealot -- I just bought Myth2 and CivCTP from Loki -- I *like* commercial software to be available for my platform!) and I don't intend to pay them for their legal department.
The repetitive shoot-em-up games are not "what people want". They are what stereotypical 14-year-old boys want.
Now, don't get me wrong. There are a quite a few stereotypical shooter-droids out there, and I've enjoyed shooters myself a few times, but there are other markets in there that the games industry isn't targeting. Who is it that says that housewives wouldn't play video games if an intensive marketing campaign were targeted at them?
Video games are a unique new art form, but they're not regarded as such by the world, because the industry is afraid to step outside the bounds have been imposed upon it. The people with actual vision (artists, programmers, writers) are squelched by management who doesn't know what they're doing, but knows that another Quake clone will keep people pumping quarters into their disk-drives, or whatever it is that they do that keeps money flowing into the game company.
It also seems silly to me that those violence-obsessed 14-year-old boys get so much attention from the industry. How much purchasing power could they possibly have, when compared with literate, college educated adults? If you could make games that adults with actual jobs would think are worthwhile, I think a few of them might buy it. It's unfortunate that the entire gaming industry has been running a counter-marketing campaign against that for years.
Laissez-faire capitalism isn't about bailing out industry. I am a capitalist in that vein, but I think that government intervention on the behalf of corporations is *worse* than government intervention on behalf of the underpriveleged -- after all, whatever your political philosophy, the corporations *already have* resources to donate to their own causes, and poor families certainly don't.
I don't think that it's the responsability of the rich to support the poor, but it is certainly NOT the reseponsability of the government to support the rich. I can see both sides of the issue on whether or not it's the govt's responsability to support the poor, but it's only hypocritical republicans, not actual capitalists, who would support subsidizing corporations over subsidizing measures to decrease unemployment.
I adhere to objectivist epistomology, but I'd agree that those that call themselves "objectivists" (especially on the web) have issues with reality.
Just because social darwinism is wrong (and you're right -- it's just wrong, pretty much no discussion there) doesn't mean that those who have acquired wealth through legitimate means don't have the right to enjoy that wealth. After all, most rich people aren't hoarding their money, they're spending it, and recirculating it into the economy! Even Big Bill donates a ton of money to charity every year.
Just think -- with a vaguely worded enough patent on my internet gaming software, I could force the makers of chess sets everywhere to pay me!!
How does the patent office decide who to give patents to, seriously? This patent seems to be applicable to a gramophone. It's digital, after all -- it has 2 states, "on" and "off".
The idea that one could patent something this broad indicates that there is a paradigmatic problem with the *concept* of a patent. It shouldn't even make sense (wrt the law) to own a patent on something this broad... this is a mistake it should not be possible to make.
However, this patent is just in the U.S.... I think I'm going to move to China -- their government is starting to seem less totalitarian than ours.
First of all: end users are *supposed* to be able to get it running!:-)
A 1.0 release is scheduled for this saturday, seeing as how it's been in pre-X for a six months now... If you haven't been able to get the software running at all, the TME staff would welcome your patches, comments, bug reports, etcetera. Requests for documentation in specific areas would be nice too, because at this point we're not sure what's documented and what's not.
I will spare you the long plug for TR's design, and say simply this: the ideas which you are discussing could easily be implemented on top of TR, and TR was designed with things like that in mind. I would really encourage you to look at the TR API before going off and reinventing the wheel yet another time. TR stores everything (in a fairly efficient manner) as something like a relational database of MOO objects, like LambdaMOO, but without all the permissions (and IMHO with a much better authoring toolkit) Also -- depending on what kind of game you want to make, the Entity project is pretty interesting too. Also written in Java, also Open Source. (Personally, I don't care for their statistics model or heavy use of reflection, but then, I'm odd)
Divunal, by the way, is a different project from TR (we've been kinda vague about that) it's the game itself, whereas TR is just the engine. Divunal is going to be a commercial product, though, and contains lots of really specific code to *our* game, that we don't feel would be generally useful.
The generally useful bits will probably be released under the GPL in a few months, or sooner if anyone voices a specific interest.
We're writing a video game written entirely on Linux using Java (see http://www.divunal.com) and Kaffe is the JVM I'm currently using to run the server.
It's faster and better than blackdown, and more Sun-spec compliant in many places (even the AWT) than the Sun JVM is. All of my Java-apps run on it.
AFAIK, Kaffe doesn't even really run on Windows... although I assume it must if that's what this article is about - but it was originally an OpenSource project running on all the free Unices.
It's a wonderful JVM... if you're into java, I highly recommend checking it out. Good JIT, nice support for JDK 1.1.
And now, "The Standard Software License Tidbit", performed by the Glyph.
Ahem...
THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU, AND YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
While this license tidbit is copied verbatim from the Iomega Zip[(tm), (r), (c), whatever] drive software, I believe that many other commercial pieces of software carry the exact same disclaimer.
This license is preposterous (how can you sell something without the implied warranty of merchantability??) but it is on lots of software and I assume that it is legally sound, since equivalent legalese shows up on every box of commercial software I've ever seen.
However, it *doesn't* give you someone to sue. You can explicitly *not* sue the vendor who sold you the software that you're using because you agreed not to by using it!!
I wish to be corrected, because I'd like to sue Microsoft for software of sub-merchantable (is that a word?) quality.
I think that this argument is largely FUD coming from corporations though, so PHB's can have a sense of security.
(If I am wrong, please correct me, but please also answer this: if it's not legally binding, why do they bother?)
Apple is attempting to piggy-back the media success of the Open Source movement while at the same time providing the part of the operating system that we have done better than they have already.
Their kernel is slow and buggy -- Linux and *BSD are not -- why would we want to work on a part of an operating system which locks us into a particular vendor for a usable display server if we actually want to *do* anything with the OS?
Sorry, but GNOME is catching up on YellowBox fast and I hope that apple dies the slow death that should become the hallmark of companies that attempt to keep platform technologies proprietary. What, then, could OSS do to benefit apple?
They could keep their stinking mess of a kernel to themselves (sorry for the constant harping on that -- but I've never used a MacOS X box for more than 2 hours without a friendly little kernel panic window popping up...) and start opensourcing the things that they've done that are truly revolutionary. YellowBox for Linux under the APSL (despite the APSL's problems) would gain Apple instant popularity -- "Look, we can code to their APIs without proprietary code!"
Apple would sell more boxes that way, because more people would write applications for MacOS X. The brilliance of this strategy? They already allow developers to develop on NT. They'd vastly expand their market *for developers* if they also allowed us all to use Linux. If they didn't rely on charging developers for the right to use their platform, they'd attract more consumers by the number of available applications.
Apple could live out the cross-platform promise that Java affords us linux hackers in a rather half-assed way right now. Imagine if we all had access to a free Yellow Box -- integrated with GNOME or KDE, choose your environment -- wouldn't you code *your* next app to run on MacOS, WinXX, and Linux, too?
However, they have merely provided us with yet another crashy kernel that they want the community to do their dirty work in debugging, and we'll all have to wait for GNUstep (if that ever gets done) to write yellowbox apps under Linux.
Brilliant move, apple. Open source the problem that someone else has already solved better.
If you're embarrased to post something, perhaps it's because it sounds stupid, or vulgar. Maybe it's because you're talking out of your ass and somebody's going to ask you to back yourself up. I am willing to stand by what I say and either back it up or admit I'm wrong -- why can't we ask that of *all*/.ers?
Patents on software are just a bad idea. They don't help you make money, they help reduce demand for whatever it is that you're selling.
Imagine if Microsoft patented the concept of a "window". There would be evidence for prior work in this area, but just for argument's sake, let's say that's what they did.
Patenting that wouldn't make us OSS people say, "Gee whiz, look at that cool MicroSoft technology. Guess we're just all gonna hafta buy Windows and run it now, 'cause we can only use the console"
It would mean that a lot of software business would go out of the country, that MS would rule the home desktop COMPLETELY, and that everyone would be beholden to them.
Until, of course, the patent expired, and years of seething hatred for the company that had restricted creativity through irresponsable licensing fees and patent law rushed out and swept them from the market completely.
Of course, this has happened before. Binary XOR anyone?
--glyph
A GNOME user tries KDE. You should try both too!
on
QPL 1.0 Released
·
· Score: 1
I was heavily impressed by the KDE desktop, which I had avoided for so long.
Much of the flaming in the free software world is totally unwarranted -- unfortunately, the intense and negative response to GNOME's 1.0 release was warranted. I hope that they got a heavy dose of our much-touted "peer review" as a development aide.
However, I still use GNOME, and I still believe it is a good idea. Just not useful in its current form. I plan to develop for it for a variety of reasons, however, we really ought to think about merging these two desktop environments into a cohesive unit. How cool would it be not to need GMC to work, because KFM already does? Drag-n-drop between Java, GNOME apps, KDE apps, Motif apps... and choice between all of them not just between desktop environments, but for each individual app!!
I'm pretty happy with the state of things as they are, but I'd like to see more.
As The Honorable Mr. Torvalds said, now we can stop the political discussion about KDE and just concentrate on getting code to work. GNOME has a number of cool features (especially in their libraries) and KDE has the distinct advantage of being able to just install and work instantly, in the here-and-now. I can replace windows completely with a copy of WordPerfect, WINE, and KDE. For the more adventurous, I add GNOME's panel in, and a couple of gtk apps.
Congrats to everyone who contributed to both efforts!! A pox on the house of whoever's brain-dead idea it was to release GNOME before it was ready, but most of the developers have been doing good work.
I hope that everybody tries to work together more in the future.
To anyone from the GNOME development effort who's reading this: it is broken. It is broken beyond all possible releasability -- take this release down now, lest it be an example to the corporate world of the impetuousness and instability of the free software movement and the unreliability of the code it produces. I was using 0.99.8 relatively happily (with a few bugs, of course, but that was development software -- this is supposed to be a release!!! Now, almost every GNOME component is broken, even after removing every remnant of the previous install including all preferences and libraries.
I really like GNOME's proposed feature set -- however, the importance of features must be measured concurrently with the importance of bugfixes. This release was supposed to be concentrating on bugfixes!!!
Because of this release, I will be re-installing KDE and waiting for a release of GNOME that I can actually work with. Until one comes out, I'm done testing this crap and waiting on a bunch of developers who, it seems, don't know how to debug, or don't care about their users.
This is a cruel mockery of a desktop environment. It is supposed to be competing with products like windows. We all love to mock microsoft's substandard operating system -- but in terms of actually working with software, GNOME is much, much worse. I hope that the developers will see their error here, mark 1.0 as unreleasable software and publicly state that there will be a release soon including ONLY BUG FIXES, so it is stable enough to use and develop for and on.
--glyph
Be happy! (Red Hat != Microsoft, Red Hat != GNOME)
on
GNOME 1.0 Released
·
· Score: 1
RedHat doesn't own GNOME. They contribute a great deal of money and time to a wonderful desktop project, which they then GPL and give away for free!!
Support choice! Use GNOME! Use KDE! Use EMACS! Use VI! Use LyX, use WordPerfect, use Quake, use Twisted Reality. Use computers! They're cool.
Let's all stop trolling and PARTY! This is a great day in free software's history. We finally have a garuanteed static API which we can code to. GNOME can start moving onto the desktop, in tandem with KDE, replacing those proprietary standards who shall remain nameless to protect the guilty.
Although MacOS X's kernel is hideously unstable, I don't think we should encourage Apple to take any more liberties with GPL'd code as they already have. They've taken large chunks of code from several GPL'd projects (Emacs, GCC, etcetera), made proprietary "improvements" and refused to re-release the source code.
I'm not a 'pure free software' zealot, but I do believe that if we are expected to respect the "rights" of defenders of intellectual property, that when a program is made GPL, it should stay GPL.
As they did when they copied code from EMACS to make the editor for Macintosh Common Lisp, and when NeXT took GCC and made their compiler with it, yet refused to provide their "improvements" in source code, claiming they were proprietary (read the license, people!)... I'm sure Apple would be more than happy to take a Linux kernel and GPL'd 'mount' command and make proprietary versions of both.
Who's supposed to sue when you violate the GPL, anyway? Apple doesn't have to provide their source, they can just claim that they didn't use GPL'd stuff...
Slashdot Mirror
Twisted Web is "fast enough", and nobody seems seriously interested in optimizing it, but I would hesitate to boldly claim it's "faster than" something else if it doesn't have a clear advantage. I'd have no problem if you said it was faster than Jigsaw, for example: if you want to talk about dog-slow systems, that's a good example.
With a real production webserver like Apache, though, there are a lot of variables to tune. There are obscure interactions to be taken into account. Twisted will surely be slower than well-configured Apache on an SMP system, for example, unless you've got 2 processes working in parallel behind a proxy... and of course, then there's dynamic content, which is an entirely different set of measurements.
The issues are complex, and it doesn't help to advocate the project by oversimplifying them.
What you say is true, but potentially misleading: one thing that you have to consider is that a good game engine will reduce, by a fairly significant factor, the amount of effort required to produce the content for the game. The logic for the game is a grey area, where certain bits of it are "engine" and others are not, but the logic is traditionally easy to develop but hard to decide on. Extreme Programming (http://xprogramming.com) can help here, because getting a working prototype early on will allow game designers to manipulate the design concretely in the short term, reducing the amount of overhead it requires to fix bad decisions -- and you WILL make bad decisions.
A good engine can only help so much, but a bad game engine can add an arbitrarily large amount of overhead to your art production pipeline and game logic code development.
If you're really trying to develop a massively multiplayer game, make sure that you're ready for a collossal failure.
:-)
I can already see the debate about C# heating up over this -- but that's tangential to the real problem. It's not that C# will doom your project, it's that you wouldn't choose C# if you knew what you were doing (and your project weren't already doomed).
First, my personal suggestion (and I say this as a developer with 2 years commercial MMP development experience at this point): EITHER you want to write an infrastructure, OR you want to write a game. Writing both by yourself will take you the better part of 10 years. Having another programmer around who is doing the other part is handy -- but making sure that they are separate tasks is important. I recommend ditching C# to use Python, and my personal infrastructure project, the Twisted network framework (http://twistedmatrix.com), but if you're not going to use that, then find another high-level language with good asynchronous networking support and the ability to load code at runtime. Other good possibilities are Common Lisp and Scheme.
If you don't have any experience in the area, and this is for an Open Source project, join an existing project and learn some things from there. I can also highly recommend getting involved with a failed project in the game industry to see how difficult the whole thing really is
Be prepared to fail at least once. The number of failure points in an MMP project is astronomical: client code, server code, internet latency, even the community itself is a potential "bug". If your technology is great and your game is fun, but it attracts really mean-spirited people for some reason, you might see your servers empty out over the course of a few months, or never even get to a real "massively" multiplayer state.
we know it will stand up, and if it doesn't, there are people to sue.
Please re-read your licensing agreements with these respective vendors. You can't sue them, you can't even think about suing them. With oracle, I think they can actually have all of your children killed if you think about suing them and they find out.
It's amazing how long elementary FUD like this can abound, especially after it's been refuted countless times in OSS diatribes. Who do you know who has ever sued Microsoft for lost data and won? Have you ever heard of Sun getting busted up over a hardware failure? It is EXTREMELY difficult to prove that the system failed in the first place (who's to say you configured it correctly? not the experts from Oracle, that's for sure), and even if you can, you agree to a LOT of things when you put that software on your server.
I'd trust Postgres against Linux any day (and YES, I do work at the "enterprise level") simply because at least they're straightforward about there being no-one to sue. If I really needed to get hard-core (not too many machines, lots of RAM and processor, zero tolerance for failure) maybe FreeBSD would fit the bill.
Most likely though, I would be averse to anything that involved x86 hardware for real reliability. So it would probably be NetBSD.
This is, perhaps, one of those situations where you are rather unlikely to find an OSS solution. An enterprise-level operating system kernel is not exactly an overnight hack. It would take an enormous kind of time and effort to put an enterprise-level UNIX kernel together.
I'm not even sure that an enterprise-level OSS kernel makes sense. If you're talking about an enterprise-level product, you probably have the resources to afford to purchase a commercial Operating System. Both Sun and QNX have decades of experience building robust, rock hard, operating systems that you can bet your company jewels on, and both companies have x86 versions of their OSs. I'm not sure about Compaq (Digital), they may have an x86 version of their OS too.
Right now, attempting to deliver an OSS kernel that can beat time-tested operating systems from Sun and QNX would be quite a challenge, to say the least. People will just have to accept the fact that OSS can't solve every problem in the world. It's certainly feasible that one day Sun or QNX might decide to release their respective kernels under an OSS license (which should certainly be quite a shock to many people), that's probably the
most likely scenario.
Before the advent of the 'net, the ability of a human being to contain ideas was pretty severely limited by their cranial capacity.
Ideas were not expressions on a purely quantitative basis -- x=5 is an idea. x=5.81356108301851851760183838886151373753111185 was an expression; unless you were exceptionally bright. Lengthen it by a few hundred digits, and it's an expression for everybody, since no-one can remember it without writing it down.
"Defacing tree carcasses" has a lot of protected rights in the US because that's the only way that we used to be able to get those ideas into a format that we could use efficiently. "The Press" was a sacred and special piece of technology.
Authoritarians even tolerated it, since it was a pretty hefty physical thing, and it meant that one could regulate ideas using the same rules that you would use to regulate physical objects, as long as you applied a few special rules to the way things were copied; and this made sense, too, due to the various technical aspects of physically producing a book. (The rationale behind copyright was not paying the author of the book -- it was the associated cost of figuring out where to put the letters on the page so that they would fit. This is not an easy problem to solve... but now we can all do it automatically, for free, thanks to TeX.)
Ideas are no longer different from expressions, and this is Katz's point. Now, it's possible to put an entire book on a floppy disk in under a minute, and this costs the original publisher exactly the same as it costs the next guy who comes along and wants to make a knockoff version. People are no longer arguing over how to sell the physical objects (books, disk drives, or what have you) but how to sell the information itself, in a pure form, over the ether.
You may notice that I've overlooked the fact that computers are still separate from human beings, just as paper is. I don't believe they are -- I interact with more people via my keyboard than with my voice. My "internet persona" has a better memory than I do, because of the vast amount of data instantly available on the web, and the information stored in my own home directory. I can think faster, better, and more clearly when hooked up to such a machine, because I can swap huge amounts of state out to it without worrying about it suddenly 'forgetting'. (Windows NT, of course, is a leprosy of the mind.)
The distinction in beliefs about intellectual property may stem from the degree to which we percieve ourselves to be cyborgs, augmented by our computers, versus the degree to which we view computers as merely tools that we use. If you see the computer as just a fancy VCR, you're probably ambivalent about having it regulated -- if it's an intrinsic part of your brain, though, you probably feel a little more strongly about it.
$x->{'y'} versus x.y -- and let's not forget about x.__class__=mypackage.MyClass. Can you even do the latter in perl?
The distinction seems pretty clear to me... perl's class / package syntax is MUCH obviously cruftier. If you think that it's not ... well, then use perl for OOP. We disagree.
Have you ever tried to read befunge, or brainf***? I know these languages, and this is certainly NOT true for them. Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing. In fact, a quote from Larry Wall himself is "admittedly, readability suffers..."Perl is not as readable as python. If you don't have any trouble reading perl, that's anecdotal evidence... there is a statistically significant number of people who don't have any problems -- and in fact, enjoy -- reading python (read the python mailinglists, or c.l.python, or www.python.org, or #python on IRC... I've been to the perl equivalents, and I've never seen them advertising readability or maintainability), because it was designed to encourage that. This doesn't mean perl is worthless: it's a language feature of python to be consistent and easy to read. It is a language feature of perl to be terse and easy to write.
Finally, consider this python statement: x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]. I admit that perhaps I'm not the swiftest perl programmer ever, but it is certainly not that easy to make a data structure which is a list of strings, hashes of strings and lists, and lists of lists in perl. The syntax gets really hideous and doesn't mean what it looks like it should. (I can't even come up with a way to write that in perl on they short notice required for posting this comment: perhaps a better perl hacker than I can elucidate..)
First of all, let me say that I think we can have a discussion about languages on slashdot WITHOUT flaming each others' brains out. I will do my best to respond to these comments in the civil tone in which they were first stated.
Now, on to the indentation: I am switching my "large project" from Java to CPython, explicitly because it *does* have such strict indentation rules. If your project is large and has to be maintained by many people, it's VERY important that the indentation be consistent.
One thing that I will agree is an annoyance in python is copying and pasting -- but one thing you're missing if you believe this is an important feature for a language is you should never ever copy and paste code! If you're repeating yourself, you should have to stop and think, "Do I really need to do this?" I have hit that a few times, and after middle-clicking, while I was correcting my indentation, I realized that I should really be using a subroutine or some sort of object abstraction for whatever it was I was copying.
This is also why I believe Python is better suited towards being a systems language, despite it's creators protestations about it being a scripting language -- when I have simple scripting to do, perl would win out. Although I'll dump on Perl in a strictly perl-versus-python debate, it is completely indespensable to me as a 'better sed'. For one-shot, throwaway programs, it is almost always better than python.
Finally, about splitting long lines where you have a long list of arguements: again, you really shouldn't have arguement lists that long. This isn't really a hard-and-fast programming rule though, so if you *do* run into that, the rule in python is simple. Break lines on the commas. Indent them in the same way you would in C. Xemacs does this for me automatically. This never really occurred to me as a problem, and I do it all the time.
Basically, it's a bad idea to mix tab and space indentation. I prefer 1 tab == 1 indent, but the official dogma on the matter is that one tab is equivalent to eight spaces. (Hence, if your editor displays a tab as 4 spaces, as mine does, it's REALLY bad to mix tabs and spaces.) Regardless of this limitation, python is my favorite language, and I've only discovred it recently.
"Consumers could not turn from Intel-compatible PC operating systems to Intel-compatible server operating systems without incurring substantial costs, since the latter type of system is sold at a significantly higher price than the former. A consumer intent on acquiring a server operating system would also have to buy a computer of substantially greater power and price than an intel-compatible PC, because server operating systems generally cannot function properly on PC hardware. ... "
:-). I just wish it had been a suit about fraud, since that's what I really object to -- all the lying that they do in their advertising, in their prospectuses... hell, they even lied to the court, repeatedly and under oath.
I don't think the judge "gets it" at all.
First of all, that is blatantly incorrect. The costs associated with switching from a "PC operating system" to a "server operating system" (I assume he means Win98/BeOS vs. commercial UNIX, since he's obviously not considering linux or *BSD.) is not the cost of the system itself, but the re-education and adjustment period of figuring out how the new system works. Consider the cost of a company switching to linux. Is $2.00 for the CD really going to set you back? Even Solaris x86 can be had for a fairly reasonable pricetag, compared to the maintenance cost of NT... but teaching everyone in the office to use an entirely new operating environment could really bite into your computing budget.
I'm as happy as the next guy that MS is getting kicked in the balls, and I'm glad to see their stock dropping. Since our stupid system of intellectual property (how did we start to consider an operating system with no support and no features a salable good?), enforced by our government, is what got MS into this sweet position to begin with, it's nice to see it turn around and bite them on the ass. But we should realize what it is: this finding of fact is not well informed. It is a case of Sun FUD + Netscape FUD + Corel FUD + DOJ FUD > MS FUD. Granted, Sun and Corel and NS and the DOJ have more truth on their side, but they are NOT interested in painting an accurate picture to the judge than Microsoft is. And, as we can see from the fact that the judge classifies "servers" and "PCs" as two magical, completely disparate kinds of hardware, this can lead to some pretty severe misunderstandings. I really hope that the precedents this sets are never used again...
That said, I also hope this drives their stock price through the floor
The hordes of script-kiddies who bombarded that nice lady over at Unisys with vulgar hate-mail actually have a point.
First of all, Unisys knows that they have pissed some people off now. They understand that it's not just a few random idiots, but a well-organized (if immature) movement of at least several thousand people.
Second, Unisys's point (in a nutshell) is: "We don't mind if you use Licensed Software (read: products from people we are extorting from) to create GIFS -- as long as it's from a Reputable Company (read: an entrenched part of the military-industrial complex) you don't have to worry." This *is* immoral, vulgar, distasteful, and stupid. We can't ignore the fact that it is a horrible abuse of the U.S.'s patent system, whether or not that system is broken. I'm NOT going to license an idea that I could work out how to do on my own time by reading published specifications to write software that I'm not going to sell anyway, and it's totalitarian to insist that I do so.
Unisys is saying that they have the right to charge you an arbitrarily large sum of money for a product which they had nothing to do with the development of (I'm sure no Unisys code was used in the creation of the Gimp) based on the content of your web-site. First amendment anyone?
Third, that "nice lady" is working for a large, powerful, horrible corporation. If she can't deal with the orwellian machinations of her employer, she should quit, not be portrayed as a heroine for reading all the hate mail that was indended for her boss. Unfortunate that nice people have to get slagged sometimes for things that aren't directly their fault -- but imagine a pretty, well-spoken girl working as the receptionist for the American Nazi Party. A similiar article could be written about her -- "To all you jews who were harrassing Christina, you should really apologize!" Even if she just answered the phones for them, her presence there relates her to them, and makes her responsible by extension.
If you think my comparison to Nazism is a bit extreme, keep in mind what Unisys wants to do here -- they want to own the web. Right now, they can only lay claim to the LZW-compressed parts of it, but they're not providing a service to consumers, they're extorting money from random people who happen to live in the U.S. and use their stupid graphics format.
Luckily, we have a choice. We can use PNG. I certainly plan to: but not because of Unisys's patent -- it's because it's a better graphics format. What would a boycott say about patent law, anyway? What if someone patents some relevant compression algorythm for PNG, or JPEG, and then all of a sudden everyone in the world owes 15 years of late-fees for not paying their "licensing" bills.
Some laws should not be obeyed, and this patent law is one of them. Don't be scared of the big, bad Unisys. If they actually start bothering you, form user groups and start a class-action suit -- I'm sure that given the incredibly long time they haven't been enforcing this and the number of public-domain implementations of LZW would be ample legal grounds for a case (although not a victory by default).
Unisys did not sell me anything, not even a piece of software (I'm not a total FSF zealot -- I just bought Myth2 and CivCTP from Loki -- I *like* commercial software to be available for my platform!) and I don't intend to pay them for their legal department.
The repetitive shoot-em-up games are not "what people want". They are what stereotypical 14-year-old boys want.
Now, don't get me wrong. There are a quite a few stereotypical shooter-droids out there, and I've enjoyed shooters myself a few times, but there are other markets in there that the games industry isn't targeting. Who is it that says that housewives wouldn't play video games if an intensive marketing campaign were targeted at them?
Video games are a unique new art form, but they're not regarded as such by the world, because the industry is afraid to step outside the bounds have been imposed upon it. The people with actual vision (artists, programmers, writers) are squelched by management who doesn't know what they're doing, but knows that another Quake clone will keep people pumping quarters into their disk-drives, or whatever it is that they do that keeps money flowing into the game company.
It also seems silly to me that those violence-obsessed 14-year-old boys get so much attention from the industry. How much purchasing power could they possibly have, when compared with literate, college educated adults? If you could make games that adults with actual jobs would think are worthwhile, I think a few of them might buy it. It's unfortunate that the entire gaming industry has been running a counter-marketing campaign against that for years.
Laissez-faire capitalism isn't about bailing out industry. I am a capitalist in that vein, but I think that government intervention on the behalf of corporations is *worse* than government intervention on behalf of the underpriveleged -- after all, whatever your political philosophy, the corporations *already have* resources to donate to their own causes, and poor families certainly don't.
I don't think that it's the responsability of the rich to support the poor, but it is certainly NOT the reseponsability of the government to support the rich. I can see both sides of the issue on whether or not it's the govt's responsability to support the poor, but it's only hypocritical republicans, not actual capitalists, who would support subsidizing corporations over subsidizing measures to decrease unemployment.
I adhere to objectivist epistomology, but I'd agree that those that call themselves "objectivists" (especially on the web) have issues with reality.
Just because social darwinism is wrong (and you're right -- it's just wrong, pretty much no discussion there) doesn't mean that those who have acquired wealth through legitimate means don't have the right to enjoy that wealth. After all, most rich people aren't hoarding their money, they're spending it, and recirculating it into the economy! Even Big Bill donates a ton of money to charity every year.
Just think -- with a vaguely worded enough patent on my internet gaming software, I could force the makers of chess sets everywhere to pay me!!
... I think I'm going to move to China -- their government is starting to seem less totalitarian than ours.
How does the patent office decide who to give patents to, seriously? This patent seems to be applicable to a gramophone. It's digital, after all -- it has 2 states, "on" and "off".
The idea that one could patent something this broad indicates that there is a paradigmatic problem with the *concept* of a patent. It shouldn't even make sense (wrt the law) to own a patent on something this broad... this is a mistake it should not be possible to make.
However, this patent is just in the U.S.
First of all: end users are *supposed* to be able to get it running! :-)
A 1.0 release is scheduled for this saturday, seeing as how it's been in pre-X for a six months now... If you haven't been able to get the software running at all, the TME staff would welcome your patches, comments, bug reports, etcetera. Requests for documentation in specific areas would be nice too, because at this point we're not sure what's documented and what's not.
I will spare you the long plug for TR's design, and say simply this: the ideas which you are discussing could easily be implemented on top of TR, and TR was designed with things like that in mind. I would really encourage you to look at the TR API before going off and reinventing the wheel yet another time. TR stores everything (in a fairly efficient manner) as something like a relational database of MOO objects, like LambdaMOO, but without all the permissions (and IMHO with a much better authoring toolkit) Also -- depending on what kind of game you want to make, the Entity project is pretty interesting too. Also written in Java, also Open Source. (Personally, I don't care for their statistics model or heavy use of reflection, but then, I'm odd)
Divunal, by the way, is a different project from TR (we've been kinda vague about that) it's the game itself, whereas TR is just the engine. Divunal is going to be a commercial product, though, and contains lots of really specific code to *our* game, that we don't feel would be generally useful.
The generally useful bits will probably be released under the GPL in a few months, or sooner if anyone voices a specific interest.
We're writing a video game written entirely on Linux using Java (see http://www.divunal.com) and Kaffe is the JVM I'm currently using to run the server.
It's faster and better than blackdown, and more Sun-spec compliant in many places (even the AWT) than the Sun JVM is. All of my Java-apps run on it.
AFAIK, Kaffe doesn't even really run on Windows... although I assume it must if that's what this article is about - but it was originally an OpenSource project running on all the free Unices.
It's a wonderful JVM... if you're into java, I highly recommend checking it out. Good JIT, nice support for JDK 1.1.
And now, "The Standard Software License Tidbit", performed by the Glyph.
Ahem...
THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU, AND YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
While this license tidbit is copied verbatim from the Iomega Zip[(tm), (r), (c), whatever] drive software, I believe that many other commercial pieces of software carry the exact same disclaimer.
This license is preposterous (how can you sell something without the implied warranty of merchantability??) but it is on lots of software and I assume that it is legally sound, since equivalent legalese shows up on every box of commercial software I've ever seen.
However, it *doesn't* give you someone to sue. You can explicitly *not* sue the vendor who sold you the software that you're using because you agreed not to by using it!!
I wish to be corrected, because I'd like to sue Microsoft for software of sub-merchantable (is that a word?) quality.
I think that this argument is largely FUD coming from corporations though, so PHB's can have a sense of security.
(If I am wrong, please correct me, but please also answer this: if it's not legally binding, why do they bother?)
Apple is attempting to piggy-back the media success of the Open Source movement while at the same time providing the part of the operating system that we have done better than they have already.
Their kernel is slow and buggy -- Linux and *BSD are not -- why would we want to work on a part of an operating system which locks us into a particular vendor for a usable display server if we actually want to *do* anything with the OS?
Sorry, but GNOME is catching up on YellowBox fast and I hope that apple dies the slow death that should become the hallmark of companies that attempt to keep platform technologies proprietary. What, then, could OSS do to benefit apple?
They could keep their stinking mess of a kernel to themselves (sorry for the constant harping on that -- but I've never used a MacOS X box for more than 2 hours without a friendly little kernel panic window popping up...) and start opensourcing the things that they've done that are truly revolutionary. YellowBox for Linux under the APSL (despite the APSL's problems) would gain Apple instant popularity -- "Look, we can code to their APIs without proprietary code!"
Apple would sell more boxes that way, because more people would write applications for MacOS X. The brilliance of this strategy? They already allow developers to develop on NT. They'd vastly expand their market *for developers* if they also allowed us all to use Linux. If they didn't rely on charging developers for the right to use their platform, they'd attract more consumers by the number of available applications.
Apple could live out the cross-platform promise that Java affords us linux hackers in a rather half-assed way right now. Imagine if we all had access to a free Yellow Box -- integrated with GNOME or KDE, choose your environment -- wouldn't you code *your* next app to run on MacOS, WinXX, and Linux, too?
However, they have merely provided us with yet another crashy kernel that they want the community to do their dirty work in debugging, and we'll all have to wait for GNUstep (if that ever gets done) to write yellowbox apps under Linux.
Brilliant move, apple. Open source the problem that someone else has already solved better.
If you're embarrased to post something, perhaps it's because it sounds stupid, or vulgar. Maybe it's because you're talking out of your ass and somebody's going to ask you to back yourself up. I am willing to stand by what I say and either back it up or admit I'm wrong -- why can't we ask that of *all* /.ers?
Patents on software are just a bad idea. They don't help you make money, they help reduce demand for whatever it is that you're selling.
Imagine if Microsoft patented the concept of a "window". There would be evidence for prior work in this area, but just for argument's sake, let's say that's what they did.
Patenting that wouldn't make us OSS people say, "Gee whiz, look at that cool MicroSoft technology. Guess we're just all gonna hafta buy Windows and run it now, 'cause we can only use the console"
It would mean that a lot of software business would go out of the country, that MS would rule the home desktop COMPLETELY, and that everyone would be beholden to them.
Until, of course, the patent expired, and years of seething hatred for the company that had restricted creativity through irresponsable licensing fees and patent law rushed out and swept them from the market completely.
Of course, this has happened before. Binary XOR anyone?
--glyph
I was heavily impressed by the KDE desktop, which I had avoided for so long.
Much of the flaming in the free software world is totally unwarranted -- unfortunately, the intense and negative response to GNOME's 1.0 release was warranted. I hope that they got a heavy dose of our much-touted "peer review" as a development aide.
However, I still use GNOME, and I still believe it is a good idea. Just not useful in its current form. I plan to develop for it for a variety of reasons, however, we really ought to think about merging these two desktop environments into a cohesive unit. How cool would it be not to need GMC to work, because KFM already does? Drag-n-drop between Java, GNOME apps, KDE apps, Motif apps... and choice between all of them not just between desktop environments, but for each individual app!!
I'm pretty happy with the state of things as they are, but I'd like to see more.
As The Honorable Mr. Torvalds said, now we can stop the political discussion about KDE and just concentrate on getting code to work. GNOME has a number of cool features (especially in their libraries) and KDE has the distinct advantage of being able to just install and work instantly, in the here-and-now. I can replace windows completely with a copy of WordPerfect, WINE, and KDE. For the more adventurous, I add GNOME's panel in, and a couple of gtk apps.
Congrats to everyone who contributed to both efforts!! A pox on the house of whoever's brain-dead idea it was to release GNOME before it was ready, but most of the developers have been doing good work.
I hope that everybody tries to work together more in the future.
To anyone from the GNOME development effort who's reading this: it is broken. It is broken beyond all possible releasability -- take this release down now, lest it be an example to the corporate world of the impetuousness and instability of the free software movement and the unreliability of the code it produces. I was using 0.99.8 relatively happily (with a few bugs, of course, but that was development software -- this is supposed to be a release!!! Now, almost every GNOME component is broken, even after removing every remnant of the previous install including all preferences and libraries.
I really like GNOME's proposed feature set -- however, the importance of features must be measured concurrently with the importance of bugfixes. This release was supposed to be concentrating on bugfixes!!!
Because of this release, I will be re-installing KDE and waiting for a release of GNOME that I can actually work with. Until one comes out, I'm done testing this crap and waiting on a bunch of developers who, it seems, don't know how to debug, or don't care about their users.
This is a cruel mockery of a desktop environment. It is supposed to be competing with products like windows. We all love to mock microsoft's substandard operating system -- but in terms of actually working with software, GNOME is much, much worse. I hope that the developers will see their error here, mark 1.0 as unreleasable software and publicly state that there will be a release soon including ONLY BUG FIXES, so it is stable enough to use and develop for and on.
--glyph
RedHat doesn't own GNOME. They contribute a great deal of money and time to a wonderful desktop project, which they then GPL and give away for free!!
Support choice! Use GNOME! Use KDE! Use EMACS! Use VI! Use LyX, use WordPerfect, use Quake, use Twisted Reality. Use computers! They're cool.
Let's all stop trolling and PARTY! This is a great day in free software's history. We finally have a garuanteed static API which we can code to. GNOME can start moving onto the desktop, in tandem with KDE, replacing those proprietary standards who shall remain nameless to protect the guilty.
Although MacOS X's kernel is hideously unstable, I don't think we should encourage Apple to take any more liberties with GPL'd code as they already have. They've taken large chunks of code from several GPL'd projects (Emacs, GCC, etcetera), made proprietary "improvements" and refused to re-release the source code.
I'm not a 'pure free software' zealot, but I do believe that if we are expected to respect the "rights" of defenders of intellectual property, that when a program is made GPL, it should stay GPL.
As they did when they copied code from EMACS to make the editor for Macintosh Common Lisp, and when NeXT took GCC and made their compiler with it, yet refused to provide their "improvements" in source code, claiming they were proprietary (read the license, people!)... I'm sure Apple would be more than happy to take a Linux kernel and GPL'd 'mount' command and make proprietary versions of both.
Who's supposed to sue when you violate the GPL, anyway? Apple doesn't have to provide their source, they can just claim that they didn't use GPL'd stuff...