The first poster is wrong in that he won't be able to make money from the game. Most GPL:ed 3D engines are available under dual licenses, the GPL and one commercial license that comes with a fee. That is perfect for him since he can start developing without a commercial license and then get a commercial license if/when he decides to release the game commercially. Just be sure to check the details of the license first though and possibly get some kind of guarantee that they won't change the commercial licenses during your development.
The second poster is somewhat wrong in his interpretation of the GPL. You do have to release your entire codebase under the GPL, but not the textures, models etc.
The GPL works on a program-wide level while the LGPL works more like the above poster described (but not entirely, you are for example required to keep the LGPL:ed codebase in a DLL, which shouldn't cause the developer any bigger troubles but gives the user the benefit of being able to modify or replace the LGPL:ed part of the program), so I guess he mixed them up a bit.
Just a request and LGPL has its drawbacks too.
on
OGRE GPL'ed 3D Engine
·
· Score: 2
As allready pointed out by others earlier within this topic thread, the thing about the splash-screen is just a request (and a very fair one I must say), not a requirement, and thus doesn't clash with the GPL. You can still do as you see fit with the code, but if you base a program on OGRE you really should give credit where credit is due.
Using the LGPL would mean that also commercial game developers could use the engine royalty-free, which is a good thing in some cases and less good in other. Using dual licenses means that the author can milk any commercial projects for some money that could be put back into development, while free software developers can use the fruits of that for free.
Dual licenses can really be a big win for program infrastructure projects like this and I'm kind of surprised not more developers are using it. Commercial users pay for the product with real money that keeps the company alive, while the free software community contribute bugreports, improvements and some free work labor in return for free use, not to mention the free advocating, exposure and wider acceptance.
...especially considering the nature of distributed computing where participants might sign up on a whim and then drop out a little bit later because they have to reinstall everything or upgrade their system or change work or simply gets tired of the project or it conflicts with some other program or gives their system performance degradation.
I don't know how much amount of immediate data that needs to be stored, but there definitely should still be a mechanism for periodically sending up progress-dumps so that somebody else can take over from wherever you were. This could at least shorten the time for having all the data run since you would notice participant drop-outs earlier and could hand over the rest of the calculations to another participant.
It could also be used to sort out really bad seeds at an earlier stage where the system, for example already after 10 or 20 years discover that you are way off and could hand you another seed instead.
Until Star Office or Open Office can match up with MS Office, Linux on the desktop is only viable for geeks. (I also like Photoshop, Dreamweaver, Cakewalk Pro, but don't see them being ported any time soon. GIMP ain't in the Photoshop caliber league inspite of what some people may think.)
As far as I'm concerned Open Office allready matches up with MS Office. I'm using it both at work and home for all my Wordprocessing and Spreadsheet needs and yes, I do need good MS Office import/export ability. All my colleagues use MS Office, but I have no trouble keeping up with them although Open Office still is a beta.
I can't speak about the other programs because I don't use them.
Hardware compatibility is another problem. With all the winmodems and NICs out there that don't work with Linux how can you expect to get people to use it if you can't network? Replacing the NICs and winmodems isn't always the answer if you've got a cash strapped school.
I can't imagine many schools using a winmodem for each and every computer. They have a local network and one or a handful of connection points to the outside world. A new NIC is cheaper than one license of Windows, but I don't think many schools needs to replace those either.
I still like Linux on the servers, but on the desktop, it's got a long way to go.
I'm not a server guy, in fact I've nerver set up a server in my whole life. I'm only running deskop computers, but I still prefer Linux. Sure, there are a lot of areas that needs to be improved, but there are also a lot of things I like better with the Linux desktops (both Gnome and KDE) than Windows, for example:
A lot of standard programs (editors, compilers, graphics tools, webbrowsers, games, scripting languages, IM clients etc) installed and correctly configured by default. I don't need to install them one by one.
More themability and eye-candy. I want my computer to be fun and friendly to work with and I like to play around with look'n feel settings. It's fun!:)
A good text shell. The MS-DOS prompt sucks.
Linux has another kind of user community which I find more fun to be a part of.
It's more adapted to multi-user environments. It will be perfect when me and my fiance get kids, I just give them their own account and let them play around, knowing that they can't screw up my files.
Most good, standard programs are free. I save a lot of money.:)
As you can see, there is already a lot of reasons for me to run Linux on the desktop. I'm absolutely more techsavy than the average user (I'm a programmer by profession) and some of the points only apply to me, but quite many do apply to the average user as well.
I know others have allready said this but as a former game developer, with more than 6 years of professional experience, I just want to add some weight to the argument that SDL indeed is what you are asking for.
I've never used SDL professionally (I've used Direct-X, Glide, PlayStation specific API's and some old inhouse stuff for DOS), but I've toyed around with it in my sparetime and I would have no trouble trusting it as the foundation for a high-quality cross-platform game (both 2D and 3D). In fact, I would rather use it than Direct-X since I find the API simpler and more straight forward as long as I don't need some obscure Direct-X feature for performance reasons (most games don't).
The URL is www.libsdl.org if you want to check it out.
The author seems to believe that the key for survival of Linux is to focus on what is does best *now* (server tasks) and hardly put any resources at all on improving what it doesn't do so well (desktop).
I'm totally of the opposite opinion. The key to Linux's success so far has been it's openness and flexibility, all steaming from the fact that it's a free operating system and developed/improved jointly by a large number of developers with different goals in mind. Why stear away from that winning path?
In nature we have two different approaches among animals and plants, the specialists and the generalists. Normally it's the generalists that draw the longer straw when sudden changes in the environment occurs, although they are at a disadvantage under long periods of stability.
What the author of the article doesn't seem to understand is that the free software movement is like a pack of small and furry rhodents in a world of big and impressive but slow dinosaurs (Microsoft, SUN, Oracle, IBM etc). We're not playing at all along the same rules as a normal company. Focusing entirely on what you do best might be the right approach for a company that has scarce resources and need to think about the short-term returns in order to stay in business.
Linux and the rest of the free software movement on the other hand has virtually unlimited resources (there's a limited amount of skilled programmers, but they have virtualy unlimited time to get the product out the door, a delay is not game over) and therefore is the diversity a good longterm strategy that will pay back wastly in the long run. We can afford to run many diverse projects and that is our best guarantee of staying in the business longterm. That way we are also increasing our chances to be early in the next quickly expanding field and take the lions share of the next big thing. We will simply be there before it makes business sense.
Concentrating to much on what we do good right now is the recipe for failure in the long run. My conclusion is that the author simply doesn't understand that Linux isn't a company and therefore plays according to a different set of rules.
The problem here is not that IBM uses a screwed up patent system to their advantage, the problem is that the patent system is screwed up in the first place.
What if it wasn't IBM that got this patent, but somebody who would use it more like a sword? What if IBM in ten years changes their policy and starts to use patents for attacking? What if IBM indeed intends to use it as a weapon against somebody?
I think most of the aggression here was pointed against the patent office and not IBM in particular. The patent system has just become one big machinery who's main goal seems to be to sustain itself and all the lawyers working with patent issues. It simply doesn't protect and promote innovation anymore the way it was meant to, at least not in the fields of software and business models.
I see a lot of comments here bashing the article for not giving the whole picture and you're right, it doesn't give the whole picture, but neither was it intended to.
As a programmer doing cross-platform software development I find it interesting and useful. What I want to know is that if I use pipes for IPC, how does it affect performance on the different platforms? I'm not interested in any additional features of Microsoft's implementation of it, because in my project I just want an easy, simple and fast way for cross-program communication that works very similarly on all platforms.
When I wrote BladeEnc I envisioned that the pipe-support I included in around 0.80 would be useful for using BladeEnc in for example realtime recording applications. Now I know that solution would give quite some performance penalty on WinXP systems and thanks to the detailed graphs I also know better how to tweak the size of the chunks I send/receive to gain some performance.
Take this article for what it is, a guiding light for software developers that helps them to write better and more efficient applications. It was written by a programmer for programmers (it's on developerWorks) and doesn't make any claims to be a valid benchmark between the platforms in general. It just shows what performance you can expect on different platforms if you use pipes in the most simple way for IPC, combined with different chunksizes.
I think the whole question sounds a bit silly, because where do you draw the line between commandline tools and GUI tools?
If I use Glade for designing user interfaces and gEdit as my code editor and compile the program by writing "make" in a console. Am I using commandline or GUI development tools?
What if I use a texteditor with some project management abilities (for example listing of files in a leftside pane) and that automatically runs make when I press a certain button combination and pipes the make output into a window. Is that GUI or commandline based development?
What if we agree that the above mentioned example is GUI based and I simply replace the editor with emacs running from a console? Am I then suddenly running a commandline based environment just because I changed the editor?
As allready stated in other comments, most GUI-based development environments are only wrappers for commandline tools. Both MSVC and KDevelop (to an even greater extent) works that way. Personally I think that KDevelop's solution is great. I can write my project in KDevelop and send it off, with project files and everything, to somebody who only uses make and vi from a commandline and he can still edit the code and compile without a problem.
I guess my point is that commandline based and GUI based development isn't so different. When you get into designing and implementing complex systems (either in group or alone) you will have good use of some tools for helping you with project layout and management that for example automatically keeps your makefiles up-to-date when you add or remove includes and a multi-source editor that easily lets you jump between function call, the functions definition and documentation. Nearly all GUI environments have that built in, but you can also achieve it in a commandline based environment through a smorgasbord of small and specialised utilities.
That said, I still think that too many programmers just goes on working in the environment and with the tools they settled on like 5 years ago without taking any look at the new modern (and mostly GUI based) tools and environments that might be very useful and speed up and simplify their work once they have managed the transition. Personally I think that both KDevelop and MSVC are great integrated development environments and they have turned me into a much more efficient programmer.
I see loads and loads of comments here in support of the medicine company that either bashes or seriously questions Brasil's decision in this matter. I also see how their comments are given high moderation points for their insightfullness and I also see flaws in their reasoning and logic.
I therefore thinks it's time for a reality check and discuss some FACTS before we start to take sides:
1.Quite some comments says or hints that Brasil is breaking "international laws". Wake up. There is no international body declaring international laws. What Brasil is breaking is international AGREEMENTS on how to treat patents. Brasil is in their full right to break this agreement if they discover that it costs more and gives less than they anticipated. That the medicine company is crying "foul" is just to be expected, but their handling of this situation really asked for it.
2. How much of the medical research is actually financed by medical corporations that rely on patents for their income? I have no real statistics, but I remember reading that here in Sweden around half of the funding of cancer research is financed by "Cancerfonden" that gathers donations (from government, companies and individuals) for cancer research. Add to that all funding done by institutions as universities and hospitals and you find that commercial medical research is in the minority. Remember, this is in Sweden where we have an unproportionally big medicine industry compared to our population.
3. Remember that patents isn't just a protection of your discovery, it also blocks your competition from inovating along the same branch! Patents both rewards and stiffles inovation from time to time. There is no proof whatsoever that the patent system has led to a higher rate of innovation in any field ever. We have just followed a logical string of thoughts and reasonings to come to the conclusion that patents do increase inovation. This reasoning is built on the assumption that we have a mostly correct perception of the world.
4. People here are commenting on how patents affect a business that they don't know anything about. Many falls into making the same kind of generalisation that we constantly have to defend ourselves against, that patents are good and drive inovation and that there would be much less inovation without it. We know that it isn't true for software development. How can you state it as a truth for another industry that also differs a lot from normal mechanical innovation without really knowing anything about that industry?
5. Doesn't the fact that we are forced to chose between peoples lives and getting money to future research that will save peoples lives tell you that something is wrong with the system? We need competition and rewards to get research in medicine, but we don't need the blocking (in both research and applying the results) that the patent system gives.
There are other ways to raise funding, encourage competition and give rewards than just applying the patent system. Isn't it time we take a look at some other possible sollutions now that we clearly can see that the patent system doesn't work as it should in the medical field?
I see all these comments on how it's a waste to throw away or recycle old hardware and how even the oldest machines can be configured to handle certain tasks, but I just keep thinking if it's really worth it.
If you send away an old computer to a school they might initially do a small saving compared to buy new equipment, but in the long run I believe the school will suffer enormously from having a diverse range of out of date hardware. The service costs must get enormous since all computers are very different and old parts keeps breaking down and have to be replaced so things will have to be reinstalled. All computers will also have to be configured individually since some are too old and slow to run the same OS and programs as the latest ones. I can understand the benefit of a big company donating a large batch of almost identical computers to a school though, but I also believe that donations to schools just are second grade sollutions, government should push in enough money to keep the schools with a healthy machine park since the kids are our future and investing in their knowledge is a good investment. Graciously providing schools with old equipment that is "just enough" might in worst case actually counteract its purpose since it then might get harder for the school to demand money for new equipment.
The second idea of keeping them around as routers and firewalls is also something I see as doubtful in the long run. Compare for example the power consumption of an old 486-66 with a modern dedicated router without any moving parts. Add to that other factors as the likely breakdown frequency, space requirements, noise generation, air flow needs and risks like causing fires due to old dusty hardware that will run very hot if a fan breaks down and I doubt that it's a saving in the long run.
Giving them to schools and institutions in third world countries or just playing with them yourself or giving them to a relative who might need a second word processing computer to use when the kids play on the family's main machine might still be a good idea though, but I doubt many of the suggestions given here.
One of the co-authors on my book (Linux Game Programming, just out) is responsible for the LInux port of Creatures 3, and guess what? He did it on company time.
Then I stand corrected. However, I still believe in the company mostly doing it because he pushed it and they decided to take a shot in the dark to keep him happy and test the waters (but you are the one who knows better in that case).
I clearly choose SDL/OpenGL ahead of Direct X unless I really need an obscure feature that SDL/OpenGL doesn't have. In all game projects I know of that have been based on Direct X the programmers have made their own abstraction layers for initialization etc since you need so bloody much of Direct X code to get things up and running. To me, SDL is that higher abstraction layer while still providing everything you need in more than 90% of the case. There are a lot of Windows hackers who use SDL instead of Direct X since it's soo much easier to learn and quick and straight forward to set up things.
Direct X is of course better supported both in mailing lists, documentation and from hardware developers. But OpenGL has very good documentation and both SDL and OpenGL have good, active developer lists. You still easily get all the info you need in a timely manner.
However, I'm looking forward to read your book, the title looks interesting.;)
Unfortunatelly I find Mark's article quite substance-less and quite a number of erros. Since I've investigated the situation of gaming on Linux quite extensively for the last few months I think I should correct/add some things:
1. I don't know any game developer who have formed inhouse Linux teams. The Creatures port is done by one or more of the original coders, mostly or completely on their sparetime since some of them are Linux fans. The company just decided to take a shot to test the waters and make their developers happy when they practically gets the port for free anyway. This was quite obvious from an interview that I *think* was headlined here on Slashdot.
2. If I remember correctly Carmack said that Linux sales "were a disappointment, but covered the costs". Of course, it's up to anyone to interprete that but I wouldn't translate it to worse than bad.
3. There are already games that have been released for Windows and Linux simultaneously, but most of them have been distributed on the same CD so it's hard to separate sales according to platform. No bestseller has done that so far though.
4. He forget what I see as the main reason for low Linux sales of Q3A: The terrible state of 3D support back then, making it almost impossible for people to run even the demo. Would you buy a game that you can't run? With XFree 4.0x the situation has improved drastically. Note that Loki didn't port any 3D games until later, when 3D acceleration was a little bit more in order, a wise decision I would say...
5. See some earlier posts regarding the state of Vertex Shaders in OpenGL.
6. Microsoft has Direct X, we have OpenGL/OpenAL/SDL which works great in combination and provides us with a very nice, cross-platform API that I (professional game developer for more than 5 years) and many with me clearly prefer instead of Direct X since the API is so much easier and straight forward. Granted, Direct X has a lead, but OpenGL/OpenAL/SDL keeps up quite nicely in the development.
7. He forgot to mention that we now have at least 3 porting houses. Loki, Tribsoft (www.tribsoft.com) and Hyperion Software (www.hyperion-software.com). Which I think is very promising.
However, I do agree with his analysis that things keep getting better. The technology (especially 3D acceleration) has taken a big step forward, more games are coming from more developers/porting houses and total game sales are increasing.
I also know some more good news, but unfortunatelly I can't tell you about it...;)
Actually, I would say that Linux is ready for games now.
Most things you mention about having to upgrade to Linux 2.4, install XFree 4.0x, install drivers etc will be a mooth point for anyone who installs any of the distros that will be comming now.
You say: "apps first and then games", I say: "some apps first, then some games, then some more apps, then some more games...".
We are not in the dark ages of DOS gaming. With SDL we have standardized Graphics, sound, 3d and a few other things taken care of. As far as I'm concerned, SDL *is* Linux's Direct X, plus that it runs on many other platforms as well. Granted, we haven't covered all kinds of funky controlers yet, but we are getting there.
Things are looking better and better. We're not yet where we want to be, but we have allready covered quite some distance and the first part was the hardest...
My gut feeling when something like this happens is that they really made a report on OSS software and its developers, programs and deployments.
Then somebody thought they should rename the paper to "Linux Developer Survey" since that would sell it better than "OSS Developer Survey" and thus they needed to change some things, but forgot to remove FreeBSD from the list.
(RANT_MODE_ON)Personally I don't understand why this is news. Things like this happens all the time and it's not really a big deal. Personally I would like to see how FreeBSD relates to some of the Linux distributions. To me, as a (non-kernel/non-system level) developer and everyday user I do put Free/Open/NetBSD into the same category as all the Linux distributions, A package with OS, programs, manuals and services containing everything I need and to at least 95% based on free software (wish I could say 100% but I still need Netscape and StarOffice although I hopefully can replace them soon with their free sucessors). That the kernel and system tools are xBSD instead of Linux I don't care a shit about. I still run the same XFree, the same desktop environment and the same programs. For what it's worth, the system still works the same for nearly everything I do and for me as a user there might be much bigger differences between various Linux distributions than a certain distribution and FreeBSD since they package different desktop environments and programs and configure them differently.
I can't understand why this upsets people so much. It's one thing to politely write them and ask them to correct their report and another to go balistic over these details. Is it the Linux and BSD elitists that doesn't want to be associated with each other?
Just face it, FreeBSD, Red Hat, SuSE, Caldera etc are "Distributions of Free Implementations of UNIX bundled with associated programs, manuals, services and stuff". That some of them are based on different kernels and have differences in design policies doesn't make them THAT different! My and one of my friends computers differs a lot more from the choice of installed window managers and programs from a users perspective than the fact that he runs FreeBSD and I run Linux.
I don't say we shouldn't teach and correct them, but everytime something like this happens it is totally blown out of proportions.(RANT_MODE_OFF)
I haven't been able to reach the article since it appears to be Slashdotted, but I would be surprised if it is anything more than a rehash of the press-release with the obligatory journalist missunderstandings and confusing rephrasing.
A quick-n-dirty summary/analyzis from someone with *some* economic education and experience:
Red Hat's fiscal year 2001 ranges from February 28 2000 to February 28 2001 and that's what they have released figures for.
They made a "reported net loss" of $24.2 million, compared to a net loss of $24.6 million the year before, which by first look might seem like an extremely small improvement. However, their revenue rised by 100%, from $42 million in 2000 to $84 million in 2001, hinting that they are expanding rapidly so their losses are likely to come from investments that haven't payed off yet.
However, their "adjusted net loss" changed much more, from $19 million in 2000 to $5.9 million in 2001. It's very typical that a company that makes large aquisitions/investments wants to spread the cost over a few years and that's most likely what they have done here. This is actually good since it keeps the company's result level (and thus its shareprice) a bit more stable. You can't make your big cost magically disappear, you can only spread it over a few years.
The thing that Red Hat emphasizes is that they only made an adjusted net loss of $600.000 for the *LAST QUARTER*, trying to give the impression that they are on the virge of going break-even. However, remember that this is an _adjusted_ net loss, so they can have done some magic here, but I do find their statement believable considering their rapid increase in revenue, but we can't know for sure until we see the next report.
What I find to be most promising is the rapid increase in revenue. Up 100% compared to a year ago. That shows to me that Red Hat is on the right track.
Yes, it could be nice in embedded and special systems, but wouldn't be an option in a normal computer where we still want things like memory protection between processes.
Btw. a similar sollution was implemented in Atari's Jaguar 64-bit console, the RISC processors (two of them) both had 64 registers, divided into two banks of 32 registers each. Then they had a special instruction for switching banks. This was very useful in the Jaguar architecture which was very depending on fast interrupt handling (hardware like the blitter sent back an interrupt request as soon as it was finished with its task), you simply let your main thread get one bank and your interrupts share the other one. Never had to push/pop registers on the stack.
Use OpenGL for the 3D and SDL (www.libsdl.org) for everything else and you have the game easily portable between Windows, Linux, MacOS, BeOS, FreeBSD, Solaris and IRIX. SDL works perfectly in tandem with OpenGL.
Seriously, I'm a game developer myself (more than 7 years experience of game programming and project management) and after having looked at SDL I find that it contains nearly everything that anyone would need in terms of high performing hardware abstraction for a cross platform tripple A title.
There is also a promising alternative in ClanLib (www.clanlib.org), but I haven't tried that myself.
My experience from the game industry (I've been working there for about 6 years) is that the artists do the game maps and level designs.
All graphics artists needs to know a lot about the engines limitations all the time. If you draw textures you need to know about the constraints on textures like:
1. Max texture sizes (to fit in on a 3Dfx card).
2. Main memory set aside for textures.
3. Memory of texture on chip texture cache (limiting number of different textures visible at once).
4. What different texture formats are available (compressed/uncompressed, with and without alpha channels, colordepth etc) and the advantages/disadvantages between them.
5. How mipmapping and interpolation affects the visuality.
And that is just for the texture artist, the 3D artists needs to have a lot more understanding.
So, as you can see, level/map design doesn't demand so much more in technical knowledge than other artist assignments. But it does demand a LOT in imagination and design to make them fun and playable and that's why we have artists doing them.
My experience is that programmers too often design maps that they find technically fascinating, but are boring to play ("look! I've made a level that pushes the engine to the maximum no matter where you look, it's always 20.000 polygons on screen, but no more!").
Btw. I'm a programmer myself, but recognize my limitations in the design department and know that my technical knowledge often gets in the way of my imagination and artistic talents. If you know too much about the underlying architecture you seem to limit yourself.
Seems like Derek Burney hasn't understood what Open Source really is about. The.Net approach he describes is really the oposite of Open Source: even more tight vendor control over software and users having even less power.
With Open Source we get:
The freedom to run the program how much we want or use it for whatever we want at no additional cost
The freedom to share the program with our friends
The power to examine the program and make sure that it works properly (is this formula I'm going to use really doing the right calculations?)
The power to modify the program and thus build upon what allready has been made so we don't have to reinvent the wheel.
Do we get anything of this if we use.Net the way he envisioned?! No, we get to pay per use fees and we get dependent on internet connections every time the formula shall be applied!:(
Also, what happens if the company offering the service goes out of business? Poof, thousands of documents can't calculate the formulas anymore!
The first category, in terms of investiment in Linux development, will be focusing on ease of installation and deinstallation as well as ease of use. The second category will tend to focus on driver development and hardware support. The third category will focus on either things that aren't viewed as commercially viable or at best niche categories of software.
Reminds me a bit of how BSD has evolved:
One distribution for "mainstream" (FreeBSD).
One distribution for portability and hardware manufacturers (NetBSD).
One distribution for some special niche needs (OpenBSD, with their security focus).
So, I think you managed to hit the nail on the head here. We will naturally have more than one distribution in all categories since Linux is so decentralized, but history has shown with BSD that these are the three categories we are likely to end up with.
The company I used to work for (UDS, a game developer www.uds.se) had at least 3 forreign employees (two from England and one from Holland) that didn't speak Swedish and that worked well.
The skills in the English language is generally good enough at Swedish IT companies to not make it a real hazard.
Unfortunately I would say it's a little bit too good, because those three people never bothered to learn Swedish and therefore still are kind of outside the Swedish culture and things happening in town etc.
However, you might discover that sallaries are generally much lower outside the US (and living expenses are naturally a bit lower as well). Sweden is not the place to go to if you have a lot of debts or are anxious to build up a fortune, but nice to spend some time in if you allready have a bunch of money...;)
I've found that sallaries here are about 30-40% of what they are in the US and taxes are higher as well.
On the other hand, you can get a nice 2 room appartment in downtown in most cities for around $4-500 and you hardly need a car at all (cities are generally more compact with good bike-only roads and bus connections).
As an ex-gamedeveloper and project manager with some experience of recruitment I would just like to add one thing to the otherwise very good answer above:
It's ESSENTIAL that the people you want to show your work can look at it without too much effort! Don't give them just a floppy or CD with the source and makefiles that only compiles under Linux if you have the right distribution and libraries installed. Make sure to give them a Windows executable with no non-standard external dependencies (or include all needed DLL and stuff).
Make sure that they can take your little demo for a testride right away without any hassle. Also supply sourcecode and stuff so they can investigate (or have a coder investigating) your code once they've gotten interested.
Be eager, show them that you really want to work for them. If you don't get any response or a "thanks, but we allready have all the people we need", keep on working on your small demos and projects and send them your new stuff a few months later, showing that you've progressed and that you still are interesting.
From the look of it they seem to be using the following:
1. Enlightenment as a window manager.
2. gkrellm for the stuff along the right side.
3. The Clip-application from Window Maker for the menues on the left side.
4. And a background from one of the Propaganda collection.
So, if they are using XFree on Linux to run this, then it's all free software and put together in a quite inspiring way.:)
What strikes me the most from reading this conversation is RMS total lack of tactical/strategical understanding of the importance of a cross-platform game API for furthering the goals of free software.
It's also surprising that the other part didn't do anything to make it clear to him. Seems like he hasn't giving any thought to the importance of his job to the movement as a whole either.
The free software movement will be helped in at least three major ways if Crystal Space becomes a popular 3D engine in commercial games:
1. Games based on Crystal Space will be more portable than those based on the proprietary APIs (Direct-X for Windows and whatever for PS2), increasing the possibility for ports to Linux. That would help us to get more home users to switch to Linux and once switched, they will be more open to the gospel and start to appreciate the freedom. That translates to more potential advocates and contributors, helping to grow the movement. I know that hardcore gamers probably are a minority here, but don't underestimate how many teenagers would switch to Linux if the same games were available there. Since they are teenagers they also belong to the category of people who still have a clear mind and like to think for them selves, making them more open to our ideas.
2. The barriers for doing high quality free software games will be lowered drastically, giving us more free high-quality games that can be enjoyed by everyone. That will help free software to break into new, tactically valuable territories.
3. Open standards have always been good for free software. Standardised and well documented fileformats, APIs and communication protocols makes it harder for single vendors to try to capture a market by providing their own proprietary solution. Microsoft is doing this with Direct X, Sony is doing it with their NDAs and stuff for PS2 etc.
So, if nobody uses the PS2-port of Crystal Space, then no harm is done except the developers wasting their time. But if it is a success it will bring more attention, support and developers to Crystal Space which is good for the whole movement.
Slashdot Mirror
The first poster is wrong in that he won't be able to make money from the game. Most GPL:ed 3D engines are available under dual licenses, the GPL and one commercial license that comes with a fee. That is perfect for him since he can start developing without a commercial license and then get a commercial license if/when he decides to release the game commercially. Just be sure to check the details of the license first though and possibly get some kind of guarantee that they won't change the commercial licenses during your development.
The second poster is somewhat wrong in his interpretation of the GPL. You do have to release your entire codebase under the GPL, but not the textures, models etc.
The GPL works on a program-wide level while the LGPL works more like the above poster described (but not entirely, you are for example required to keep the LGPL:ed codebase in a DLL, which shouldn't cause the developer any bigger troubles but gives the user the benefit of being able to modify or replace the LGPL:ed part of the program), so I guess he mixed them up a bit.
As allready pointed out by others earlier within this topic thread, the thing about the splash-screen is just a request (and a very fair one I must say), not a requirement, and thus doesn't clash with the GPL. You can still do as you see fit with the code, but if you base a program on OGRE you really should give credit where credit is due.
Using the LGPL would mean that also commercial game developers could use the engine royalty-free, which is a good thing in some cases and less good in other. Using dual licenses means that the author can milk any commercial projects for some money that could be put back into development, while free software developers can use the fruits of that for free.
Dual licenses can really be a big win for program infrastructure projects like this and I'm kind of surprised not more developers are using it. Commercial users pay for the product with real money that keeps the company alive, while the free software community contribute bugreports, improvements and some free work labor in return for free use, not to mention the free advocating, exposure and wider acceptance.
...especially considering the nature of distributed computing where participants might sign up on a whim and then drop out a little bit later because they have to reinstall everything or upgrade their system or change work or simply gets tired of the project or it conflicts with some other program or gives their system performance degradation.
I don't know how much amount of immediate data that needs to be stored, but there definitely should still be a mechanism for periodically sending up progress-dumps so that somebody else can take over from wherever you were. This could at least shorten the time for having all the data run since you would notice participant drop-outs earlier and could hand over the rest of the calculations to another participant.
It could also be used to sort out really bad seeds at an earlier stage where the system, for example already after 10 or 20 years discover that you are way off and could hand you another seed instead.
As far as I'm concerned Open Office allready matches up with MS Office. I'm using it both at work and home for all my Wordprocessing and Spreadsheet needs and yes, I do need good MS Office import/export ability. All my colleagues use MS Office, but I have no trouble keeping up with them although Open Office still is a beta. I can't speak about the other programs because I don't use them.
Hardware compatibility is another problem. With all the winmodems and NICs out there that don't work with Linux how can you expect to get people to use it if you can't network? Replacing the NICs and winmodems isn't always the answer if you've got a cash strapped school.
I can't imagine many schools using a winmodem for each and every computer. They have a local network and one or a handful of connection points to the outside world. A new NIC is cheaper than one license of Windows, but I don't think many schools needs to replace those either.
I still like Linux on the servers, but on the desktop, it's got a long way to go.
I'm not a server guy, in fact I've nerver set up a server in my whole life. I'm only running deskop computers, but I still prefer Linux. Sure, there are a lot of areas that needs to be improved, but there are also a lot of things I like better with the Linux desktops (both Gnome and KDE) than Windows, for example:
As you can see, there is already a lot of reasons for me to run Linux on the desktop. I'm absolutely more techsavy than the average user (I'm a programmer by profession) and some of the points only apply to me, but quite many do apply to the average user as well.
I know others have allready said this but as a former game developer, with more than 6 years of professional experience, I just want to add some weight to the argument that SDL indeed is what you are asking for.
I've never used SDL professionally (I've used Direct-X, Glide, PlayStation specific API's and some old inhouse stuff for DOS), but I've toyed around with it in my sparetime and I would have no trouble trusting it as the foundation for a high-quality cross-platform game (both 2D and 3D). In fact, I would rather use it than Direct-X since I find the API simpler and more straight forward as long as I don't need some obscure Direct-X feature for performance reasons (most games don't).
The URL is www.libsdl.org if you want to check it out.
The author seems to believe that the key for survival of Linux is to focus on what is does best *now* (server tasks) and hardly put any resources at all on improving what it doesn't do so well (desktop).
I'm totally of the opposite opinion. The key to Linux's success so far has been it's openness and flexibility, all steaming from the fact that it's a free operating system and developed/improved jointly by a large number of developers with different goals in mind. Why stear away from that winning path?
In nature we have two different approaches among animals and plants, the specialists and the generalists. Normally it's the generalists that draw the longer straw when sudden changes in the environment occurs, although they are at a disadvantage under long periods of stability.
What the author of the article doesn't seem to understand is that the free software movement is like a pack of small and furry rhodents in a world of big and impressive but slow dinosaurs (Microsoft, SUN, Oracle, IBM etc). We're not playing at all along the same rules as a normal company. Focusing entirely on what you do best might be the right approach for a company that has scarce resources and need to think about the short-term returns in order to stay in business.
Linux and the rest of the free software movement on the other hand has virtually unlimited resources (there's a limited amount of skilled programmers, but they have virtualy unlimited time to get the product out the door, a delay is not game over) and therefore is the diversity a good longterm strategy that will pay back wastly in the long run. We can afford to run many diverse projects and that is our best guarantee of staying in the business longterm. That way we are also increasing our chances to be early in the next quickly expanding field and take the lions share of the next big thing. We will simply be there before it makes business sense.
Concentrating to much on what we do good right now is the recipe for failure in the long run. My conclusion is that the author simply doesn't understand that Linux isn't a company and therefore plays according to a different set of rules.
The problem here is not that IBM uses a screwed up patent system to their advantage, the problem is that the patent system is screwed up in the first place.
What if it wasn't IBM that got this patent, but somebody who would use it more like a sword? What if IBM in ten years changes their policy and starts to use patents for attacking? What if IBM indeed intends to use it as a weapon against somebody?
I think most of the aggression here was pointed against the patent office and not IBM in particular. The patent system has just become one big machinery who's main goal seems to be to sustain itself and all the lawyers working with patent issues. It simply doesn't protect and promote innovation anymore the way it was meant to, at least not in the fields of software and business models.
I see a lot of comments here bashing the article for not giving the whole picture and you're right, it doesn't give the whole picture, but neither was it intended to.
As a programmer doing cross-platform software development I find it interesting and useful. What I want to know is that if I use pipes for IPC, how does it affect performance on the different platforms? I'm not interested in any additional features of Microsoft's implementation of it, because in my project I just want an easy, simple and fast way for cross-program communication that works very similarly on all platforms.
When I wrote BladeEnc I envisioned that the pipe-support I included in around 0.80 would be useful for using BladeEnc in for example realtime recording applications. Now I know that solution would give quite some performance penalty on WinXP systems and thanks to the detailed graphs I also know better how to tweak the size of the chunks I send/receive to gain some performance.
Take this article for what it is, a guiding light for software developers that helps them to write better and more efficient applications. It was written by a programmer for programmers (it's on developerWorks) and doesn't make any claims to be a valid benchmark between the platforms in general. It just shows what performance you can expect on different platforms if you use pipes in the most simple way for IPC, combined with different chunksizes.
I think the whole question sounds a bit silly, because where do you draw the line between commandline tools and GUI tools?
If I use Glade for designing user interfaces and gEdit as my code editor and compile the program by writing "make" in a console. Am I using commandline or GUI development tools?
What if I use a texteditor with some project management abilities (for example listing of files in a leftside pane) and that automatically runs make when I press a certain button combination and pipes the make output into a window. Is that GUI or commandline based development?
What if we agree that the above mentioned example is GUI based and I simply replace the editor with emacs running from a console? Am I then suddenly running a commandline based environment just because I changed the editor?
As allready stated in other comments, most GUI-based development environments are only wrappers for commandline tools. Both MSVC and KDevelop (to an even greater extent) works that way. Personally I think that KDevelop's solution is great. I can write my project in KDevelop and send it off, with project files and everything, to somebody who only uses make and vi from a commandline and he can still edit the code and compile without a problem.
I guess my point is that commandline based and GUI based development isn't so different. When you get into designing and implementing complex systems (either in group or alone) you will have good use of some tools for helping you with project layout and management that for example automatically keeps your makefiles up-to-date when you add or remove includes and a multi-source editor that easily lets you jump between function call, the functions definition and documentation. Nearly all GUI environments have that built in, but you can also achieve it in a commandline based environment through a smorgasbord of small and specialised utilities.
That said, I still think that too many programmers just goes on working in the environment and with the tools they settled on like 5 years ago without taking any look at the new modern (and mostly GUI based) tools and environments that might be very useful and speed up and simplify their work once they have managed the transition. Personally I think that both KDevelop and MSVC are great integrated development environments and they have turned me into a much more efficient programmer.
I see loads and loads of comments here in support of the medicine company that either bashes or seriously questions Brasil's decision in this matter. I also see how their comments are given high moderation points for their insightfullness and I also see flaws in their reasoning and logic.
I therefore thinks it's time for a reality check and discuss some FACTS before we start to take sides:
1.Quite some comments says or hints that Brasil is breaking "international laws". Wake up. There is no international body declaring international laws. What Brasil is breaking is international AGREEMENTS on how to treat patents. Brasil is in their full right to break this agreement if they discover that it costs more and gives less than they anticipated. That the medicine company is crying "foul" is just to be expected, but their handling of this situation really asked for it.
2. How much of the medical research is actually financed by medical corporations that rely on patents for their income? I have no real statistics, but I remember reading that here in Sweden around half of the funding of cancer research is financed by "Cancerfonden" that gathers donations (from government, companies and individuals) for cancer research. Add to that all funding done by institutions as universities and hospitals and you find that commercial medical research is in the minority. Remember, this is in Sweden where we have an unproportionally big medicine industry compared to our population.
3. Remember that patents isn't just a protection of your discovery, it also blocks your competition from inovating along the same branch! Patents both rewards and stiffles inovation from time to time. There is no proof whatsoever that the patent system has led to a higher rate of innovation in any field ever. We have just followed a logical string of thoughts and reasonings to come to the conclusion that patents do increase inovation. This reasoning is built on the assumption that we have a mostly correct perception of the world.
4. People here are commenting on how patents affect a business that they don't know anything about. Many falls into making the same kind of generalisation that we constantly have to defend ourselves against, that patents are good and drive inovation and that there would be much less inovation without it. We know that it isn't true for software development. How can you state it as a truth for another industry that also differs a lot from normal mechanical innovation without really knowing anything about that industry?
5. Doesn't the fact that we are forced to chose between peoples lives and getting money to future research that will save peoples lives tell you that something is wrong with the system? We need competition and rewards to get research in medicine, but we don't need the blocking (in both research and applying the results) that the patent system gives.
There are other ways to raise funding, encourage competition and give rewards than just applying the patent system. Isn't it time we take a look at some other possible sollutions now that we clearly can see that the patent system doesn't work as it should in the medical field?
If the system is broken, then fix it...
If you send away an old computer to a school they might initially do a small saving compared to buy new equipment, but in the long run I believe the school will suffer enormously from having a diverse range of out of date hardware. The service costs must get enormous since all computers are very different and old parts keeps breaking down and have to be replaced so things will have to be reinstalled. All computers will also have to be configured individually since some are too old and slow to run the same OS and programs as the latest ones. I can understand the benefit of a big company donating a large batch of almost identical computers to a school though, but I also believe that donations to schools just are second grade sollutions, government should push in enough money to keep the schools with a healthy machine park since the kids are our future and investing in their knowledge is a good investment. Graciously providing schools with old equipment that is "just enough" might in worst case actually counteract its purpose since it then might get harder for the school to demand money for new equipment.
The second idea of keeping them around as routers and firewalls is also something I see as doubtful in the long run. Compare for example the power consumption of an old 486-66 with a modern dedicated router without any moving parts. Add to that other factors as the likely breakdown frequency, space requirements, noise generation, air flow needs and risks like causing fires due to old dusty hardware that will run very hot if a fan breaks down and I doubt that it's a saving in the long run.
Giving them to schools and institutions in third world countries or just playing with them yourself or giving them to a relative who might need a second word processing computer to use when the kids play on the family's main machine might still be a good idea though, but I doubt many of the suggestions given here.
Then I stand corrected. However, I still believe in the company mostly doing it because he pushed it and they decided to take a shot in the dark to keep him happy and test the waters (but you are the one who knows better in that case).
I clearly choose SDL/OpenGL ahead of Direct X unless I really need an obscure feature that SDL/OpenGL doesn't have. In all game projects I know of that have been based on Direct X the programmers have made their own abstraction layers for initialization etc since you need so bloody much of Direct X code to get things up and running. To me, SDL is that higher abstraction layer while still providing everything you need in more than 90% of the case. There are a lot of Windows hackers who use SDL instead of Direct X since it's soo much easier to learn and quick and straight forward to set up things.
Direct X is of course better supported both in mailing lists, documentation and from hardware developers. But OpenGL has very good documentation and both SDL and OpenGL have good, active developer lists. You still easily get all the info you need in a timely manner.
However, I'm looking forward to read your book, the title looks interesting. ;)
Unfortunatelly I find Mark's article quite substance-less and quite a number of erros. Since I've investigated the situation of gaming on Linux quite extensively for the last few months I think I should correct/add some things:
;)
1. I don't know any game developer who have formed inhouse Linux teams. The Creatures port is done by one or more of the original coders, mostly or completely on their sparetime since some of them are Linux fans. The company just decided to take a shot to test the waters and make their developers happy when they practically gets the port for free anyway. This was quite obvious from an interview that I *think* was headlined here on Slashdot.
2. If I remember correctly Carmack said that Linux sales "were a disappointment, but covered the costs". Of course, it's up to anyone to interprete that but I wouldn't translate it to worse than bad.
3. There are already games that have been released for Windows and Linux simultaneously, but most of them have been distributed on the same CD so it's hard to separate sales according to platform. No bestseller has done that so far though.
4. He forget what I see as the main reason for low Linux sales of Q3A: The terrible state of 3D support back then, making it almost impossible for people to run even the demo. Would you buy a game that you can't run? With XFree 4.0x the situation has improved drastically. Note that Loki didn't port any 3D games until later, when 3D acceleration was a little bit more in order, a wise decision I would say...
5. See some earlier posts regarding the state of Vertex Shaders in OpenGL.
6. Microsoft has Direct X, we have OpenGL/OpenAL/SDL which works great in combination and provides us with a very nice, cross-platform API that I (professional game developer for more than 5 years) and many with me clearly prefer instead of Direct X since the API is so much easier and straight forward. Granted, Direct X has a lead, but OpenGL/OpenAL/SDL keeps up quite nicely in the development.
7. He forgot to mention that we now have at least 3 porting houses. Loki, Tribsoft (www.tribsoft.com) and Hyperion Software (www.hyperion-software.com). Which I think is very promising.
However, I do agree with his analysis that things keep getting better. The technology (especially 3D acceleration) has taken a big step forward, more games are coming from more developers/porting houses and total game sales are increasing.
I also know some more good news, but unfortunatelly I can't tell you about it...
Actually, I would say that Linux is ready for games now.
Most things you mention about having to upgrade to Linux 2.4, install XFree 4.0x, install drivers etc will be a mooth point for anyone who installs any of the distros that will be comming now.
You say: "apps first and then games", I say: "some apps first, then some games, then some more apps, then some more games...".
We are not in the dark ages of DOS gaming. With SDL we have standardized Graphics, sound, 3d and a few other things taken care of. As far as I'm concerned, SDL *is* Linux's Direct X, plus that it runs on many other platforms as well. Granted, we haven't covered all kinds of funky controlers yet, but we are getting there.
Things are looking better and better. We're not yet where we want to be, but we have allready covered quite some distance and the first part was the hardest...
My gut feeling when something like this happens is that they really made a report on OSS software and its developers, programs and deployments.
Then somebody thought they should rename the paper to "Linux Developer Survey" since that would sell it better than "OSS Developer Survey" and thus they needed to change some things, but forgot to remove FreeBSD from the list.
(RANT_MODE_ON)Personally I don't understand why this is news. Things like this happens all the time and it's not really a big deal. Personally I would like to see how FreeBSD relates to some of the Linux distributions. To me, as a (non-kernel/non-system level) developer and everyday user I do put Free/Open/NetBSD into the same category as all the Linux distributions, A package with OS, programs, manuals and services containing everything I need and to at least 95% based on free software (wish I could say 100% but I still need Netscape and StarOffice although I hopefully can replace them soon with their free sucessors). That the kernel and system tools are xBSD instead of Linux I don't care a shit about. I still run the same XFree, the same desktop environment and the same programs. For what it's worth, the system still works the same for nearly everything I do and for me as a user there might be much bigger differences between various Linux distributions than a certain distribution and FreeBSD since they package different desktop environments and programs and configure them differently.
I can't understand why this upsets people so much. It's one thing to politely write them and ask them to correct their report and another to go balistic over these details. Is it the Linux and BSD elitists that doesn't want to be associated with each other?
Just face it, FreeBSD, Red Hat, SuSE, Caldera etc are "Distributions of Free Implementations of UNIX bundled with associated programs, manuals, services and stuff". That some of them are based on different kernels and have differences in design policies doesn't make them THAT different! My and one of my friends computers differs a lot more from the choice of installed window managers and programs from a users perspective than the fact that he runs FreeBSD and I run Linux.
I don't say we shouldn't teach and correct them, but everytime something like this happens it is totally blown out of proportions.(RANT_MODE_OFF)
http://www.redhat.com/about/presscenter/2001/press _Q42001.html
I haven't been able to reach the article since it appears to be Slashdotted, but I would be surprised if it is anything more than a rehash of the press-release with the obligatory journalist missunderstandings and confusing rephrasing.
A quick-n-dirty summary/analyzis from someone with *some* economic education and experience:
Red Hat's fiscal year 2001 ranges from February 28 2000 to February 28 2001 and that's what they have released figures for.
They made a "reported net loss" of $24.2 million, compared to a net loss of $24.6 million the year before, which by first look might seem like an extremely small improvement. However, their revenue rised by 100%, from $42 million in 2000 to $84 million in 2001, hinting that they are expanding rapidly so their losses are likely to come from investments that haven't payed off yet.
However, their "adjusted net loss" changed much more, from $19 million in 2000 to $5.9 million in 2001. It's very typical that a company that makes large aquisitions/investments wants to spread the cost over a few years and that's most likely what they have done here. This is actually good since it keeps the company's result level (and thus its shareprice) a bit more stable. You can't make your big cost magically disappear, you can only spread it over a few years.
The thing that Red Hat emphasizes is that they only made an adjusted net loss of $600.000 for the *LAST QUARTER*, trying to give the impression that they are on the virge of going break-even. However, remember that this is an _adjusted_ net loss, so they can have done some magic here, but I do find their statement believable considering their rapid increase in revenue, but we can't know for sure until we see the next report.
What I find to be most promising is the rapid increase in revenue. Up 100% compared to a year ago. That shows to me that Red Hat is on the right track.
Btw. a similar sollution was implemented in Atari's Jaguar 64-bit console, the RISC processors (two of them) both had 64 registers, divided into two banks of 32 registers each. Then they had a special instruction for switching banks. This was very useful in the Jaguar architecture which was very depending on fast interrupt handling (hardware like the blitter sent back an interrupt request as soon as it was finished with its task), you simply let your main thread get one bank and your interrupts share the other one. Never had to push/pop registers on the stack.
Seriously, I'm a game developer myself (more than 7 years experience of game programming and project management) and after having looked at SDL I find that it contains nearly everything that anyone would need in terms of high performing hardware abstraction for a cross platform tripple A title.
There is also a promising alternative in ClanLib (www.clanlib.org), but I haven't tried that myself.
All graphics artists needs to know a lot about the engines limitations all the time. If you draw textures you need to know about the constraints on textures like:
1. Max texture sizes (to fit in on a 3Dfx card).
2. Main memory set aside for textures.
3. Memory of texture on chip texture cache (limiting number of different textures visible at once).
4. What different texture formats are available (compressed/uncompressed, with and without alpha channels, colordepth etc) and the advantages/disadvantages between them.
5. How mipmapping and interpolation affects the visuality.
And that is just for the texture artist, the 3D artists needs to have a lot more understanding.
So, as you can see, level/map design doesn't demand so much more in technical knowledge than other artist assignments. But it does demand a LOT in imagination and design to make them fun and playable and that's why we have artists doing them.
My experience is that programmers too often design maps that they find technically fascinating, but are boring to play ("look! I've made a level that pushes the engine to the maximum no matter where you look, it's always 20.000 polygons on screen, but no more!").
Btw. I'm a programmer myself, but recognize my limitations in the design department and know that my technical knowledge often gets in the way of my imagination and artistic talents. If you know too much about the underlying architecture you seem to limit yourself.
With Open Source we get:
Do we get anything of this if we use
Also, what happens if the company offering the service goes out of business? Poof, thousands of documents can't calculate the formulas anymore!
Reminds me a bit of how BSD has evolved:
One distribution for "mainstream" (FreeBSD).
One distribution for portability and hardware manufacturers (NetBSD).
One distribution for some special niche needs (OpenBSD, with their security focus).
So, I think you managed to hit the nail on the head here. We will naturally have more than one distribution in all categories since Linux is so decentralized, but history has shown with BSD that these are the three categories we are likely to end up with.
The skills in the English language is generally good enough at Swedish IT companies to not make it a real hazard.
Unfortunately I would say it's a little bit too good, because those three people never bothered to learn Swedish and therefore still are kind of outside the Swedish culture and things happening in town etc.
However, you might discover that sallaries are generally much lower outside the US (and living expenses are naturally a bit lower as well). Sweden is not the place to go to if you have a lot of debts or are anxious to build up a fortune, but nice to spend some time in if you allready have a bunch of money... ;)
I've found that sallaries here are about 30-40% of what they are in the US and taxes are higher as well.
On the other hand, you can get a nice 2 room appartment in downtown in most cities for around $4-500 and you hardly need a car at all (cities are generally more compact with good bike-only roads and bus connections).
As an ex-gamedeveloper and project manager with some experience of recruitment I would just like to add one thing to the otherwise very good answer above:
It's ESSENTIAL that the people you want to show your work can look at it without too much effort! Don't give them just a floppy or CD with the source and makefiles that only compiles under Linux if you have the right distribution and libraries installed. Make sure to give them a Windows executable with no non-standard external dependencies (or include all needed DLL and stuff).
Make sure that they can take your little demo for a testride right away without any hassle. Also supply sourcecode and stuff so they can investigate (or have a coder investigating) your code once they've gotten interested.
Be eager, show them that you really want to work for them. If you don't get any response or a "thanks, but we allready have all the people we need", keep on working on your small demos and projects and send them your new stuff a few months later, showing that you've progressed and that you still are interesting.
From the look of it they seem to be using the following:
:)
1. Enlightenment as a window manager.
2. gkrellm for the stuff along the right side.
3. The Clip-application from Window Maker for the menues on the left side.
4. And a background from one of the Propaganda collection.
So, if they are using XFree on Linux to run this, then it's all free software and put together in a quite inspiring way.
What strikes me the most from reading this conversation is RMS total lack of tactical/strategical understanding of the importance of a cross-platform game API for furthering the goals of free software.
It's also surprising that the other part didn't do anything to make it clear to him. Seems like he hasn't giving any thought to the importance of his job to the movement as a whole either.
The free software movement will be helped in at least three major ways if Crystal Space becomes a popular 3D engine in commercial games:
1. Games based on Crystal Space will be more portable than those based on the proprietary APIs (Direct-X for Windows and whatever for PS2), increasing the possibility for ports to Linux. That would help us to get more home users to switch to Linux and once switched, they will be more open to the gospel and start to appreciate the freedom. That translates to more potential advocates and contributors, helping to grow the movement. I know that hardcore gamers probably are a minority here, but don't underestimate how many teenagers would switch to Linux if the same games were available there. Since they are teenagers they also belong to the category of people who still have a clear mind and like to think for them selves, making them more open to our ideas.
2. The barriers for doing high quality free software games will be lowered drastically, giving us more free high-quality games that can be enjoyed by everyone. That will help free software to break into new, tactically valuable territories.
3. Open standards have always been good for free software. Standardised and well documented fileformats, APIs and communication protocols makes it harder for single vendors to try to capture a market by providing their own proprietary solution. Microsoft is doing this with Direct X, Sony is doing it with their NDAs and stuff for PS2 etc.
So, if nobody uses the PS2-port of Crystal Space, then no harm is done except the developers wasting their time. But if it is a success it will bring more attention, support and developers to Crystal Space which is good for the whole movement.