I think that your analysis of the licensing problems is quite right. The two responses that are usually given are also usually countered with the following arguments:
When you compile KDE, you also include some
code from the Qt header files (macros, types, etc.) so a part of the KDE binaries is derived from Qt. This code is not compatible with the GPL, which implies that you are not allowed to
re-distribute it in a GPL'ed package.
Indeed, you could assume that the "Qt
exception" (a suggested addition to the KDE
license in order to make it compatible with Qt)
is implicitely included in the code that was
written specifically for KDE, because it is
obvious that the authors of this code intended to
have it distributed with KDE and together with Qt.
However, a (very) small part of the KDE code was
borrowed from other projects for which you cannot
make this assumption. Thus the license for the
whole package is a problem.
But there is hope, especially about the second
point... As reported on Wednesday, Mozilla is going to be dual licensed. In order to change the license,
they will get in touch will all contributors in order to be sure that they agree with the re-licensing. More precisely, as explained in their relicensing FAQ, they will make a reasonable attempt to contact and obtain consent from each of the contributors (it may not be possible to contact all of them, so the law only requires them to be able to prove that they made a reasonable effort).
If the Mozilla team can do it, then the KDE team should not be scared to do it. Maybe there
is still hope for KDE2 to be released with the
"Qt exception" in all source files. This would
put an end to this licensing controversy, and
this would benefit KDE (a lot!).
This would probably not end the GNOME vs. KDE
flamewars, but at least they would have to
consider some more technical arguments instead of
flaming KDE for its licensing problems.
Well, my point was kind of different. Trolls are a Norwegian company and copyright issues would be resolved in Oslo City Court. European copyright laws are different from American (I don't really know how)
Well, as a matter of fact I live in Europe, not in the US. The copyright laws are not really different. All countries that have signed the Berne copyright convention have implemented the same basic rules in their national laws. I do not think that Norway is different in that respect. For more informations about copyrights, you could have a look at:
The last page contains lots of links to useful documents, including several copyright FAQs.
[...] and Trolls do not think that the "viral clause" would be effective in Norwegian court.
Now, this is another matter. It is not related to the copyright laws, but to the interpretation of the GPL. I have seen several statements by TrollTech employees saying that, in their opinion, "neither the GPL nor the LGPL legally protect libraries." However, you have to pay attention to the wording of these statements and what exactly is meant by "protect" in that context.
The GPL does protect the libraries in that it does not allow someone to distribute a compiled version of the library itself without the sources. It also prevents the distribution of a compiled program that links with this library, unless the sources are made available.
However, the GPL does not prevent the distribution of the sources of a program (or another library) that is under a restrictive license and links with the GPL'd or LGPL'd library. For example, I could release the sources of a program under a license that forbids non-commerical use (ha!) and tell the user to compile and link with the GPL'd library. The GPL does nothing against that, because it does not restrict the usage of the GPL'd code, only its distribution or modification. It this case, it would only be possible to distribute the sources or the program (separately from the library), but not the compiled code.
Also, the GPL allows you to use the code freely for your personal use (even for commercial purposes) as long as you do not re-distribute the code (compiled or not).
In his editorial, Eirik Eng says: "If the GPL effectively protected a GPLed library from being used to develop proprietary software, we would allow relicensing Qt under the GPL." As explained above, the GPL effectively prevents the distribution of binary-only programs linked with the library, because the compiled program is considered to be a derivative work as soon as it uses some code (macros, typedefs,...) from the header files of the library. However, it does not prevent the distribution of source-only programs, and it does not prevent the development of proprietary software using the library as long as the software is not distributed.
Contrary to the GPL, the QPL does not allow the latter, and I think that this puts an unnecessary restriction on the usage of the software. Let's suppose that I am the owner of a small shop and I want to develop my own virtual cash register on my PC using Qt. Well, according to the QPL I would have to get a commercial license if I use this little application in my shop, because that would be a "commercial use". Depending on your point of view, you can consider this as a good or a bad feature of the QPL compared to the GPL.
So they cannot release Qt with GPL as an alternative license because they are afraid that it might ruin their business model, because anyone could then use Qt Free Edition in any project, proprietary or not
Well, of course TrollTech has to earn money somehow. But I do not think that the GPL would ruin their business model. With the GPL, anybody who distributes a program built on top of the library would have to release the sources as well (under the GPL or a compatible license). If by "proprietary" you mean "without sources" or "with a restrictive license, then no, the GPL would not allow that.
If Troll Tech wanted to have "GPL with a commercial exception", they could simply license Qt under the GPL and offer a separate commercial license for sale like other companies do.
You did read this and Matthias Ettrich's comments here?
Unfortunately, even Matthias Ettrich misses the target in several of his replies (arguing about something different for what James Ramsey wrote and not adressing the real issues).
As I wrote at the bottom of this article on Advogato, there are a few things to keep in mind when you read the articles and comments posted on Freshmeat:
There are no problems if you distribute a GPL'd program using Qt, as long as you only distribute the source code. But the GPL and QPL are incompatible if you distribute a compiled executable, because it would be a derivative work (see the explanation below) and the GPL does not allow the distribution of derivative works unless all parts of the work can be released under the GPL, with some exceptions that are debated in the editorial. For example, according to the exception stated at the end of section 3 of the GPL, it could be possible to distribute KDE binaries if Qt can be considered to be a standard part of the operating system and KDE is not distributed together with Qt (which would be a problem for all Linux distributions).
The GPL cannot force you to change the license of other pieces of code and it cannot force you to use the code in some specific way (in fact, it allows you to do almost whatever you want with the code for private purposes), but it can (and does) prevent you from re-destributing the GPL'd code if you do not meet some conditions. One of these conditions is that all parts of a derivative work must be distributed under the GPL (see section 2b, the so-called "viral clause").
If you are the author of a piece of code, you are free to distribute it under any license and to change the license (for new versions) at any time. However, this is only possible if you are the only copyright holder. If you have used any code that was contributed by someone else, then all contributors must agree on the new license. This is a problem because some KDE applications (not many, fortunately) have borrowed some code from other applications and it is not easy to get the agreement on the "Qt exception" from all authors and contributors. So although more than 90% of the KDE code could be considered to implicitely have the "Qt exception" because the code was written specifically for KDE, the status of the remaining parts of the code (especially in KDE applications that are not part of the core) should be clarified.
Some people say that we need a new version of the GPL without the viral clause, because the current version is too restrictive and the new one would solve the KDE problems. But they fail to understand that some authors of GPL'd code do want this restriction, and chose to release their code under the GPL precisely because of it (this does not necessarily apply to all authors of GPL'd code, but those who are in that category cannot be ignored).
I recommend that you read Sam Tobin-Hochstadt's diary entry on Advogato (16 Jul 2000), in which he describes what is a ``derivative work'' according to the copyright law (17 USC Sec. 101). Since KDE falls in this category, section 2b of the GPL requires all parts of the derivative work to be published under the terms of the GPL. Parts of Qt (at least the macros and types defined in the Qt header files if you are linking dynamically, or even the whole Qt library if you are linking statically) are included in KDE binaries, and therefore must be re-distributable under the terms of the GPL. This is in conflict with the QPL version 1.0 (used for Qt 2.0), which adds some restrictions that are not compatible with the GPL. Even the QPL version 2.0 (planned for a future release of Qt?) would not solve these problems, as discussed in the Freshmeat editorial.
About more dynamic selection tools... a better selection representation would be good, especially with regards to feathered selections and stuff... Maybe a sort of 'convolve' tool to selectively feather particular edges of a selection would be good. Maybe something else to 'nudge' selection areas... as in push the border in and out but retain some level of connectivity - sort of moulding tool for selections.
I see... What you want is the QuickMask feature that is available in the latest releases: by clicking on the little square buttons that are in the bottom left corner of the image, you can activate the quick mask which allows you to view your selection as a semi-transparent mask and to edit it with the usual painting tools. When you are satisfied with the result, you can click again to convert the mask back to a selection. I think that it does exactly what you want.
oh and I would like to see brushes displayed something like selections are, so that you can see your brush edges.
This has been discussed several times on the developers' mailing list. Unfortunately, some limitations of the X Servers make this feature much more difficult to implement than it seems. Basically, it is difficult to create a cursor that is larger than 16x16 pixels, which is obviously a problem for most of the brushes.
In playing around with Gimp I haven't seen any kinds of utilities that even approach this level of web graphics functionality. This may be due to my ignorance in using Gimp, so I may very well be judging too harshly here.
Some parts of the user interface should definitely be improved, and hopefully this will be easier to implement in version 2.0. I don't think that any of the current developers would implement the full range of features of "Save for Web" or ImageReady in version 1.x. However, some of the features that you are looking for are already there. For example:
If you save an image as JPEG, you can see a preview and adjust the quality of the image.
To split an image for web use, you can try the Guillotine or Perlotine scripts (Image->Transforms->Guillotine or Image->Filters->Web->Perl-o-tine). They split an image along the guides and the second one will output the HTML table for you.
You can easily create or modify an image map using Image->Filters->Web->ImageMap. It creates or modifies the HTML code for you.
Several scripts and plug-ins allow you to create animations easily. For example, try Image->Filters->Distorts->IWarp or any of the scripts in Image->Script-Fu->Animators. You can preview and optimize your animation with Image->Filters->Animation->Animation Playback and Image->Filters->Animation->Animation Optimize.
If you want to create more complex animations involving several moving objects in multiple layers, there is a whole set of GAP plug-ins available under Image->Video.
These features could be integrated a bit better and presented in a way that even new users find them easily, but they exist already. One thing that could be improved in the future versions is the "Export" feature which could include some features of "Save for Web": for example, a preview for GIF and PNG (not only JPEG) allowing you to change the number of GIF colors easily and compare the results with the original.
Last point: When I'm doing some serious editing inside of PS I find myself playing the keyboard like a piano. After a number of years working with it, my mouse and keyboard hands work independently switching between tools and using them. I have a feeling that a lot of serious PS users work in a very similar manner. I don't believe that Gimp should strive to just be a PS clone, but it would be helpful to a lot of PS users such as myself to perhaps provide a loadable keyboard mapping that equates back to PS.
It is already there: look for a file called ps-menurc in the top-level directory of the source distribution. If you install this file in your ~/.gimp directory, you will get the same keyboard mapping as PS.
What you want to do is to increase the "Tile Cache Size" (in File->Preferences/Environment) to a value that as large as possible. Set it to a value that is close to the amount of physical RAM available on your system and the GIMP should work much faster. The recent 1.1.x versions of the GIMP (soon to be 1.2) include a nice dialog box that pops up during the installation and explains how to set up this value.
But that would only solve a part of the problem: it would still take time to refresh the image during panning operations if your the factor is 1:8 or 1:16, because the GIMP has to fetch every 64th or 256th pixel in the original image before drawing it. This leads to cache misses in the CPU, and the coordinate scaling requires some additional operations for every pixels that is drawn. As explained in other comments, some programs are storing temporary copies of the image at various resolutions in order to speed up the panning operations on zoomed-out images. The advantage is that you can move around faster, the disadvantage is that these temporary views have to be re-computed every time you change the zoom factor. The GIMP is fast when zooming in/out but slow at redrawing large images. Other programs are fast when panning a zoomed-out image, but slow if you want to change the zoom factor.
As with many other things that involve a tradeoff between CPU cycles and memory, this should probably be configurable. Yet another idea for version 2.0...
Vector layers. They are no there yet, although this has been discussed several times among the GIMP developers. The current implementation of paths (using the bezier tool) is already using some vectors and the FreeType plug-in can convert text to paths, but this is not exactly what you want. Note that you can apply some basic transformations to the paths (rotation, scaling, shearing), but the support for vectors in the GIMP is still limited. Currently, if you want to work with vectors, it is better to try Gill, the GNOME illustration app. Maybe Gill and GIMP could be merged in the future?
Non-linear history. This has also been discussed several times, and this will be part of version 2.0. This was even mentioned on a page that the article refers to.
Line tools. Did you know that you can already draw straight lines, circles, squares and other shapes with the GIMP? To draw a straight line, select any painting tool, click where you want to start your line, then hold shift and click a second time. To draw a circle or a square, use the corresponding selection tools to make a selection, then use Edit->Stroke. The latest development version of the GIMP contains some tips explaining how to do that easily. You can even do some exotic things such as drawing lines with a gradient or with a fading brush.
Dynamic seletors. Well, I am not sure that I understand what you want. I would be interested in more details...
Many things are already possible with the upcoming version 1.2 of the GIMP. I suggest that you have a look at the tips and on-line help that are distributed with the current version, or that you have a look at some of the recent books, such as Grokking the GIMP or the GIMP handbook by Sven.
I think that you are confusing two things: wavelet coding of an image and hierarchical editing. Wavelets should can be useful for the final output (saving the final image as JPEG2000), but they should not be used as the internal representation while you are editing the image. You cannot (in most cases) mix wavelets and lossless editing.
On the other hand, some kind of hierarchical editing can be interesting if you are working on huge images. It could be implemented by extending the current concept of layers in the GIMP, and it would not even require a major re-write of the plug-ins and tools. If I have too much spare time (cough!), I may even consider implementing this for version 1.4 or 2.0.
The only thing that would have to be done is to allow the layers of an image to have different resolutions. So the background layer of the image could be stored at 300dpi while the other layers are stored at 2400dpi. Most of the plug-ins and tools work on one layer at a time and are independent of the resolution of the image, so they would not have to be modified. Some other operations such as "Merge visible layers" or "Bump Map" would have to be re-written, but it should not be that difficult.
But I am not sure if there would be a big advantage in doing that. You would save some memory, but several operations (including displaying the image) would be slowed down because it would be necessary to check the resolution of all layers and to re-scale them at the same resolution before merging them.
There was one easter egg in version 1.0.x of The GIMP, introduced in 1998 by Adam D. Moss. It was rather hard to find because you had to use the DB Browser and see that one plug-in registered itself as "plug-in-the-egg" but did not appear in any of the menus. If you tried to invoke this procedure, it would display some pretty animations on your screen.
But a few weeks after this was added, it was taken out of hiding in the developer's version of the GIMP (versions 1.1.x), where it registers itself as Filters->Toys->The Egg. As Adam wrote when the hidden plug-in was revealed, I guess we need a new easter egg for version 1.2...
Despite the fact that Microsoft Word documents are able to be read and modified on most desktop platforms (Linux/xBSD, Windows, Mac OS, OS/2), [...]
I disagree. I have a PC that has both Linux and Windows on it. Neither of these can modify Word documents. On the Windows side, I cannot even view the Word documents created with recent versions of Word, because I did not buy the latest version of the program. On the Linux side, I can view most documents but I do not have any good editor that can be used to modify the documents easily.
So using Word as a file format would prevent some people from reading or modifying the documents unless they buy some proprietary software. I fully support the fact that Word should be considered as an "Opaque" file format.
Well, if you can show me a program that is freely available on all platforms described above and that can view and edit all documents produced by Word 2000 without loosing any graphics, cross-references or other meta-information, then I could think twice about it...
Ah well, I should have been a bit more careful before posting: Octave is not really a symbolic math program. So I wouldn't mind if my previous comment as well as all others that suggest using Octave were moderated down as "Offtopic"...
For symbolic math, maybe SciLab (Open Source, not much symbolic stuff but a bit of it anyway) or MuPAD (free but not Open Source) could help, although I haven't personally tested them.
You should have a look at GNU Octave, which is mostly compatible with Matlab.
I tried it under Solaris and Linux and it works quite well. If you have the opportunity to compare Matlab and Octave running on the same platform, you will find that Octave is a bit slower and consumes more resources, but not up to the point that it becomes a problem. Several of the Matlab examples can be ported to Octave and they run fine.
You can find Octave in the latest Debian and SuSE Linux distributions. If you want to compile it yourself, you will need a recent version of gcc (with support for C++ and FORTRAN), the C++ library and optionally gnuplot for the graphics. You will also need some disk space and some patience while the stuff compiles, but the package is reasonably easy to configure, compile and install. Good luck!
I tried to find out where the server for the.cx domain could be located. Here are the results of a traceroute done from the nice tools page of SamSpade.Org:
1 206.117.161.1 (206.117.161.1) [AS226] 1 ms 2 isi-acg.ln.net (130.152.136.1) [AS226] 2 ms 3 triton.cerf.net (198.32.146.20) [AS226] 3 ms 4 atm11-0.lax-bb1.cerf.net (134.24.29.17) [AS1740] 8 ms 5 pos8-0-155M.lax-bb4.cerf.net (134.24.32.230) [AS1740] 3 ms 6 so1-0-0-622M.dfw-bb2.cerf.net (134.24.29.78) [AS1740] 40 ms 7 pos2-0-622M.chi-bb4.cerf.net (134.24.46.82) [AS1740] 64 ms 8 pos1-0-622M.nyc-bb8.cerf.net (134.24.32.214) [AS1740] 86 ms 9 pos1-0-0-155M.nyc-bb3.cerf.net (134.24.32.226) [AS1740] 84 ms 10 gxn-gw.nyc-bb5.cerf.net (134.24.130.114) [AS1740] 84 ms 11 hs8-0-0-llb-ny1.TH1.core.rtr.xara.net (194.143.164.161) [AS5413/AS5519] 157 ms 12 gb6-0-0-llb-x-many.TH25.core.rtr.xara.net (194.143.163.132) [AS5413/AS5519] 157 ms 13 gb6-0-0-llb-x-many.TH7.core.rtr.xara.net (194.143.163.131) [AS5413/AS5519] 157 ms 14 se0-xfs-d416-th7.planet3.cust.rtr.xara.net (195.224.216.227) [AS5519] 163 ms 15 ChiefWiggum.planet-three.net (195.224.98.130) [AS5519] 165 ms 16 * * *
Also, all the hosts that I could find and that seemed to be related to the top-level.cx domain (DNS, mail servers, etc.) are aliases for some machines in the domain.planet-three.net.
And whois reports the following for planet-three.net:
Planet Three Ltd (PLANET-THREE4-DOM) 3A West Point Warple Way London, London W3 0RG UK
Record last updated on 04-Feb-2000. Record created on 05-Jan-1999. Database last updated on 20-Feb-2000 12:45:15 EST.
But the location of the DNS servers should not matter, because the DNS can map a domain name to an IP address that is located anywhere in the world. So you can keep your server in a cool and dry room without having to worry about the weather in the Christmas Island.
I don't know about you but this doesn't seem to be the most appropriate conditions for keeping your servers fine and funky...
He he he.:-) That's right: usually, computers and water do not mix very well.
But if I am not mistaken, the servers for the.cx domain are not located on the Christmas Islands. I could not find this information on their pages, but I think that they are somewhere in the US or Australia, probably in a slightly drier place. So the servers should be safe.
Aw... Poor Raph! I have enjoyed the low-traffic / high-quality nature of advogato.org since the end of last year, and I was hoping that nobody would post a link to your site on Slashdot. Well, not only do you get a link to it on Slashdot, but even better than that: you make it to the front page. Ouch!
That being said, I read Knuth's interview when it was published and I liked it very much.
If the author is in a country where reverse engineering has been made illegal [...] the author could find a friendly party in a safe country and have them take credit for the release.
That could be a good idea, indeed. However, the most important advice (document everything) will then become very tricky. The ghost author will have to explain how he has acquired the information, written the code, and so on. The ghost author will also need one or several friends who can testify that he has found all this by himself.
Nevertheless, finding a friendly party in a country that allows reverse-engineering might be a good solution for people living in the USA or in other countries that have stupid restrictions on reverse-engineering. Alas, even European countries are now modifying their laws to prohibit reverse-engineering because of the pressure from several big companies.
First, release it from a country where the patents and trademarks do not apply.
Easier said than done... However, this brings an important point: it is crucial to check for patents before releasing something that is considered to be a trade secret. If something is proprietary but not patented, then it is perfectly legal to re-implement it (as long as you use a "clean room" process and you do not copy anything directly from the current solution). But if anything is patented, then it is not possible to release this to the community.
Second, release it to the public domain.
Why? If he has spent a significant amount of time studying the problem and the existing solutions, I doubt that he would be happy to see some companies taking his solution and making a proprietary product out of it.
Third, release it anonymously.
Bad advice. If the intent of the author is to release something to the community, then he probably wants to be sure that it would be possible for others to use his work. Releasing the code or documentation anonymously would not help anyone, because they would have to prove that the original information was obtained legally, which would be impossible if it comes from an anonymous source.
I think that the only good advice is: document everything. If you want to release something (possibly controversial) to the community, then the only way to make sure that others can really benefit from what you have done is to be accountable for it. You have to be able to prove that all the information was obtained legally, and that it does not come from any confidential documents. If every source of information is legal, then the community can benefit legally from your work (and you will be able to cover your back because you can prove how you obtained the information).
After reading the paragraphs in which Chris DiBona explains how the developers were selected for the IPO, I conclude that the list of people was based on the number of times each e-mail address appeared in the 11 GB of source code he had selected. Or more probably, on the number of files in which the addresses appeared (it would be too easy to cheat by inserting your e-mail address a thousand times in the same file).
I understand that it is not easy to find an objective way to select the developers who contributed the most to the Open Source community. It is especially difficult to have a process that could be automated as much as possible. And it is extremely difficult to be fair.
But still... Now I realize that modesty does not pay when you write your code. Instead of inserting your e-mail address only once at the top of the AUTHORS file (and in the ChangeLog) but not in any source file, it seems to be better to include your e-mail address in every source file that you touch. Sigh!
And of course, don't use spam-traps if you want to get the opportunity to participate in some IPO. Sigh!
Hmmm... As far as I am concerned, I think that I will stick to the old habit of being credited only once or twice, not in every source file.
I've spent the past several years working on a project devloped solely under Visual Studio on Windows 95. This summer, I ported it to Linux using GCC and to Mac using Code Warrior. We regularly build all three versions using three different compilers and three different makefiles with little difficulty.
I think that we are talking about slightly different issues: you present a project that was once developed on one platform, then it was ported to other platforms. I suppose that you still add some features and bug fixes afterwards, but I assume that you do not re-structure large parts of the project regularly. I mentioned a project in which most of the code is being actively developed for all platforms at the same time, and there are some major changes done in the cross-platform code. When you have many platforms to support, including their variants (e.g. Windows CE for MIPS processor is not the same as Windows CE for SH3), then you have to be sure that any new source file added, deleted or renamed in the cross-platform libraries is correctly updated in all Makefiles (or whatever build system you are using).
In my project, we solved that problem by using included Makefiles that are shared by several platform-specific Makefiles, which allows the various builds to use the same source files even if each platform uses a different compiler and different settings. Another poster described a very similar solution. But even that is not always easy to manage, especially with several hundred source files in many different directories. If I break something, then it does not take long until a colleague complains that the version for this or that platform does not build anymore (or at the latest, the nightly build will send me a message about it).
The original poster in this thread said that he likes CodeWarrior because it is easier for him to manage his build system. If he is used to it and if that works well, then why not? I think that for large projects, some IDEs may be better than Makefiles if your applications contain a lot of stuff that is not pure code (i.e. icons, bitmaps, pre-made dialogs, hotkeys, etc.) and if that stuff must be available in more than one language. Some IDEs are quite good at handling all this "extra stuff" and I suppose that this is one of the reasons why he said that he relies on CodeWarrior.
I mean, if you like Code Warrior, then you're obviously unhappy that they've dropped linux support. But it certainly shouldn't destroy your project!
Note that I am not the same person as the one who complained about the lack of CodeWarrior for Linux. In fact, I have never used CodeWarrior in any real project (and it is unlikely that I ever will, because I am quite experienced in writing good Makefiles). I was simply trying to explain that Open Source tools are not always available for developing software, especially on non-UN*X platforms, and this is why some companies rely on closed source IDEs.
Yet Another Reason Not To Depend On Closed Source Products -- your future is not in your own hands.
Open Source software is not always an option if you are writing cross-platform code: most Open Source development tools are available for Linux and various flavours of UN*X, but not for MacOS, Windows 95/98/NT/2K, Windows CE (a totally different beast), EPOC, PalmOS and so on. If you start with a product that was developed on the Mac and you want to port it to Linux, chances are that the product was relying on CodeWarrior, because CodeWarrior is one of the best integrated environments available on the Mac and there is no Open Source equivalent that comes close. If CodeWarrior is not available for Linux, then it will be harder to convert this product.
I am sure that many companies would not mind using Open Source tools, be it only for being sure that they have their future in their hands. But this is not always possible. And many companies do not have the resources (time and money) to invest in porting the best Open Source tools to their target platforms before starting to develop their products. They just have to live with the closed source IDEs, and hope that their suppliers will support their target platforms in the future.
At work, I am developing some software that is ported to Linux, Solaris, Windows 95/98/NT, Windows CE, EPOC, and maybe a few others soon. We decided to use Makefiles (handwritten or generated) for most of our build system, and to rely on included Makefiles (with nested includes) for making it easier to maintain the global settings and so on. Still, this can be a pain to maintain when you have dozens or hundreds of directories with their own Makefiles. I think that we made the right decision because Makefiles are future-proof and we have more control over what is going on in your build system. But we have to pay the price for that, and it is counted in extra hours when some significant change has to be applied to the build system.
Many companies prefer to set up their build system around some tools such as CodeWarrior, which are supposed to make it much easier to manage large projects. I don't blame them for that, because this is probably what gives them the best benefits compared to the set-up and maintenance costs in the short- or medium-term, especially for (very) large projects. If you have the opportunity to even think about the long term (not always an option when you have to get a product out of the door in the next few weeks), then I would always recommend using a system that does not rely on closed source products, such as Makefiles.
You can make your life easier under UN*X by using autoconf, automake and various other goodies for generating your Makefiles automatically, but these tools do not exist (yet) for Windows or for the Mac. And the cross-compilers are not always an option either. I'm still dreaming of a system that would allow me to have only one Makefile for compiling my code with the correct options under any system (or at least UN*X, Windows and MacOS)...
Here's a fairly simple way to detect aimbots... From the server, send a packet that says to a client "there's a guy right behind you". Not a fake guy, make it real. The guy doesn't really have to exist.. The server keeps track of things like that, so as long as the server knows it's fake, no biggie. Plus, the server doesn't broadcast one message to all clients, it's quite easy for the server to send "there's a guy right behind you" only to the guy that has the guy right behind him. Since it's right behind him, he'll never see it. Since other clients aren't told about it, they'll never see it. But that pesky bot will see it and fire away.
Good idea. But as others have pointed out, this could lead to another generation of bots, which would not shoot at these dummy fake targets so that the server would not detect that they are bots. Here are a few examples of things that a clever bot could do to check if a target is valid or bogus:
If the target has a fully transparent skin, it is bogus.
If the target is stuck inside a wall, it is bogus (requires BSP tests).
If the target is on the other side of a wall and is not moving, do not shoot: it may be a fake or a real player, but in any case it is not moving so we should not shoot at it yet.
If the target is behind you (let's say between -150 and +150 degrees) and it has never been seen before and it is not shooting at you, then do not shoot. But turn around from time to time to check if this could be a real player.
If the target is behind and it has been identified before as a real player, then flip 180 degrees and shoot.
If the target is moving in a way that would be impossible even with movement prediction/correction (e.g. a player that is constantly behind you even if you do some fast spins) then it is bogus.
In all other cases, shoot.
This could probably be refined a bit, but as you can see it would be possible to create a bot that tries to fool the server-side aimbot detection schemes.
But... there is still one thing that could be done to detect the bots, and maybe that could make the aimbots much less useful: instead of inserting bogus players into the walls or immediately behind or under the bot, put them in another hallway that is part of the PVS. Make the dummy run like if it was about to be visible a few milliseconds later. And make it disappear just when the bot would expect it to be visible. This has to be timed right in order to ensure that the dummy does not become visible even if there is some network lag, but I think that it would be nice to have something like this to detect the aimbots.
So if the bot shoots at the location where the invisible player would have entered the room, then mark it as a bot and the problem is solved (ban the cheater). If the bot does not shoot, then the problem is also solved because that bot will only shoot at visible targets.
Besides that, I think that two of the best solutions mentioned in the other replies to this article are:
Reputation servers. If you want to play, you have to be registered. If you are marked as being a cheater, most servers will ban you.
Signed clients and servers. Everyone can use and modify the source code of the clients and servers, but from time to time there are some "official" releases of the client and server that are digitally signed and contain some challenge-response mechanism. The signed servers have an option to accept only signed clients, so that nobody can cheat on these servers.
Of course both of these solutions can be abused too, but it is more difficult. You could register multiple players and move to another one when one is marked as a cheater, but it would be difficult to go very far with that. Also, a clever hacker could break the challenge-response mechanism in the signed client and create a hacked client that gives the same responses as the official one, but that would take time (hopefully longer than the time between releases).
No system is perfect and nobody has an infinite amount of time to spend on making the games more secure. But some solutions can make cheating difficult, especially if the cheat is obsoleted by a new release.
The impression I had after reading the whole interview is that the editors get the ideas for stories from us as opposed to going out looking for stories on their own. In that sense, they will get a feel for what more people want to see posted because they'll get more stories about that given area.
I disagree: the people who submit stories are not necessarily the same as those who moderate comments (and could also moderate stories). In order to be allowed to moderate, you have to "earn" your moderator status. There is no such thing for submitting stories.
The moderators are selected among the people who have posted interesting comments (OK, the karma thing has some flaws, but the general idea is good). The moderators are supposed to have a good judgement, or at least to have some sensible opinions. But there is no "filter" for submitting stories, so I don't think that the number of submissions is a good metric to judge if a story will be appreciated by the/. readers.
Let's take an example: a link to a story about Micro$oft is submitted by 50 AC's (or registered users with low karma). Another story, more technical and less controversial, is submitted by two or three users. If I had the opportunity to moderate the stories and if the second one is really interesting, then I would probably give it a +1 and ignore the first story. On the other hand, if you only judge a story based on the number of people who submitted it (or later, on the number of replies), then you would always select the first one and maybe the second one would never be posted.
That's why I think that allowing the moderators to rate the stories as well as the comments would be an interesting addition to/.
Another interesting addition would be to rate comments and stories on different criteria and to allow readers to filter the comments based on the criteria that are important to them, and not only on the total score. I would start with three critaria:
technical content. Is the comment "interesting" or "insightful" from a technical point of view? Does it give link to other sources of information or does it contain good explanations for the topic being discussed?
good advocacy. Does the comment do a good job at promoting Linux, nanotech or any other thing that nerds might be interested in? The comment might not contain many technical facts but contain enough good ideas or state things in a clear way so that you would rate it as "interesting" in the current system.
humour. Is it funny? Are you ROTFL after reading the comment?
The current system covers these criteria, but as a reader your are only able to filter the comments based on their total score. I have seen several old-timers on/. complain about the fact that some comments got a +5 because they were funny, despite the fact that they were off-topic and did not contain much information. If it was possible to separate the moderation criteria, then an elitist techie could select "tech content" only and ignore any points given in the "advocacy" and "humour" categories. And someone who wants to have a good time reading/. would set her filter to use the points in the "humour" category. Maybe this could be a multiplier, so that one could filter the comments based on "(tech + 2 * advocacy + 3 * humour)". Now, that's a good system for Nerds...
Now that I think about it, a fourth criterion could be "on-topicness". An article can be off-topic but still contain interesting ideas. Some people like to read such articles, some others don't. By giving the appropriate weight to this criterion in the comment filter, then every reader would be able to select what he wants to see.
Re:Is the Metaverse nearing practicality?
on
Quake 1 GPL'ed
·
· Score: 1
Basically, for the Metaverse to work, you need a massive, distributed, dynamically load-balanced database. You need near-zero latency between servers to handle synchronization. You need to be able to have servers dynamically hand off clients to one another without the user being able to perceive it happening. You need to be able to support the one guy wandering off by him/herself in the "frontiers" of the metaverse.
I may be over-simplifying things here, but I don't see why this should be such a problematic issue.
If you want to build a realistic universe, you need to provide a way for the players to move freely from one area to another without even noticing that the two areas of the universe are handled by different servers.
You could of course include teleporters, subways, or special doors to move the player from one server to another (IIRC, that idea was mentioned by John Carmack and also by John Romero in the pre-Quake days). But that would not really give the feeling of a single large universe because switching from one server to another would still require a specific action. So the areas would only be semi-connected.
Note that even this simple scheme contains some interesting problems:
Server A must check that server B is on-line before attempting to transfer the player. Server B must be reacheable by server A but also by the user.
Server A must also check that server B is ready to accept a new player. What if B is full? Will the player be stuck? Will a new server be spawned automatically?
The transfer must be performed as an atomic operation, so that the player does not get lost or duplicated if there is a failure in one server, in the client or in the network.
The transfer should also be performed in a somewhat secure way (depending on the application, you may want to prevent spoofing, replay attacks, etc.)
The servers must trust each other to some extent, and maybe trust the client too (depending on the application). i.e. if you use the metaverse concept for a game, you do not want someone to insert a new server that will modify some players and send them back into the game with unfair advantages or disadvantages.
But the real challenge is to implement a seamless world, in which people can move around as if everything was part of a single huge map. The players should not be able to see that they are moving to a different server. In addition to the problems mentioned above, you get a lot of problems in the "frontiers" of the metaverse, as mentioned by the original poster.
For example, how will you be able to see an area that is handled by a different server than the one you are connected to? One solution would be to replicate (cache) the visible parts of the "foreign" areas on each server, but that would not work for players or any other moving objects. So the servers must exchange some informations whenever something changes near the frontiers. But there are some latency problems. If you are familiar with the QuakeWorld/QuakeII/QuakeIII problems regarding lag and movement prediction, you can imagine what will happen if more than one server is involved.
Anyway, I have been playing around with these ideas for a while and I think that I have found some solutions for building a fully distributed world (taking input from Quake, CrossFire and my personal experience about building distributed and redundant systems). Maybe I will write them down someday, and maybe even build a library that implements the necessary network protocols. Maybe...
Slashdot Mirror
I think that your analysis of the licensing problems is quite right. The two responses that are usually given are also usually countered with the following arguments:
But there is hope, especially about the second point... As reported on Wednesday, Mozilla is going to be dual licensed. In order to change the license, they will get in touch will all contributors in order to be sure that they agree with the re-licensing. More precisely, as explained in their relicensing FAQ, they will make a reasonable attempt to contact and obtain consent from each of the contributors (it may not be possible to contact all of them, so the law only requires them to be able to prove that they made a reasonable effort).
If the Mozilla team can do it, then the KDE team should not be scared to do it. Maybe there is still hope for KDE2 to be released with the "Qt exception" in all source files. This would put an end to this licensing controversy, and this would benefit KDE (a lot!).
This would probably not end the GNOME vs. KDE flamewars, but at least they would have to consider some more technical arguments instead of flaming KDE for its licensing problems.
Well, as a matter of fact I live in Europe, not in the US. The copyright laws are not really different. All countries that have signed the Berne copyright convention have implemented the same basic rules in their national laws. I do not think that Norway is different in that respect. For more informations about copyrights, you could have a look at:
The last page contains lots of links to useful documents, including several copyright FAQs.
Now, this is another matter. It is not related to the copyright laws, but to the interpretation of the GPL. I have seen several statements by TrollTech employees saying that, in their opinion, "neither the GPL nor the LGPL legally protect libraries." However, you have to pay attention to the wording of these statements and what exactly is meant by "protect" in that context.
The GPL does protect the libraries in that it does not allow someone to distribute a compiled version of the library itself without the sources. It also prevents the distribution of a compiled program that links with this library, unless the sources are made available.
However, the GPL does not prevent the distribution of the sources of a program (or another library) that is under a restrictive license and links with the GPL'd or LGPL'd library. For example, I could release the sources of a program under a license that forbids non-commerical use (ha!) and tell the user to compile and link with the GPL'd library. The GPL does nothing against that, because it does not restrict the usage of the GPL'd code, only its distribution or modification. It this case, it would only be possible to distribute the sources or the program (separately from the library), but not the compiled code.
Also, the GPL allows you to use the code freely for your personal use (even for commercial purposes) as long as you do not re-distribute the code (compiled or not).
In his editorial, Eirik Eng says: "If the GPL effectively protected a GPLed library from being used to develop proprietary software, we would allow relicensing Qt under the GPL." As explained above, the GPL effectively prevents the distribution of binary-only programs linked with the library, because the compiled program is considered to be a derivative work as soon as it uses some code (macros, typedefs, ...) from the header files of the library. However, it does not prevent the distribution of source-only programs, and it does not prevent the development of proprietary software using the library as long as the software is not distributed.
Contrary to the GPL, the QPL does not allow the latter, and I think that this puts an unnecessary restriction on the usage of the software. Let's suppose that I am the owner of a small shop and I want to develop my own virtual cash register on my PC using Qt. Well, according to the QPL I would have to get a commercial license if I use this little application in my shop, because that would be a "commercial use". Depending on your point of view, you can consider this as a good or a bad feature of the QPL compared to the GPL.
Well, of course TrollTech has to earn money somehow. But I do not think that the GPL would ruin their business model. With the GPL, anybody who distributes a program built on top of the library would have to release the sources as well (under the GPL or a compatible license). If by "proprietary" you mean "without sources" or "with a restrictive license, then no, the GPL would not allow that.
Unfortunately, even Matthias Ettrich misses the target in several of his replies (arguing about something different for what James Ramsey wrote and not adressing the real issues).
As I wrote at the bottom of this article on Advogato, there are a few things to keep in mind when you read the articles and comments posted on Freshmeat:
I recommend that you read Sam Tobin-Hochstadt's diary entry on Advogato (16 Jul 2000), in which he describes what is a ``derivative work'' according to the copyright law (17 USC Sec. 101). Since KDE falls in this category, section 2b of the GPL requires all parts of the derivative work to be published under the terms of the GPL. Parts of Qt (at least the macros and types defined in the Qt header files if you are linking dynamically, or even the whole Qt library if you are linking statically) are included in KDE binaries, and therefore must be re-distributable under the terms of the GPL. This is in conflict with the QPL version 1.0 (used for Qt 2.0), which adds some restrictions that are not compatible with the GPL. Even the QPL version 2.0 (planned for a future release of Qt?) would not solve these problems, as discussed in the Freshmeat editorial.
I see... What you want is the QuickMask feature that is available in the latest releases: by clicking on the little square buttons that are in the bottom left corner of the image, you can activate the quick mask which allows you to view your selection as a semi-transparent mask and to edit it with the usual painting tools. When you are satisfied with the result, you can click again to convert the mask back to a selection. I think that it does exactly what you want.
This has been discussed several times on the developers' mailing list. Unfortunately, some limitations of the X Servers make this feature much more difficult to implement than it seems. Basically, it is difficult to create a cursor that is larger than 16x16 pixels, which is obviously a problem for most of the brushes.
Some parts of the user interface should definitely be improved, and hopefully this will be easier to implement in version 2.0. I don't think that any of the current developers would implement the full range of features of "Save for Web" or ImageReady in version 1.x. However, some of the features that you are looking for are already there. For example:
These features could be integrated a bit better and presented in a way that even new users find them easily, but they exist already. One thing that could be improved in the future versions is the "Export" feature which could include some features of "Save for Web": for example, a preview for GIF and PNG (not only JPEG) allowing you to change the number of GIF colors easily and compare the results with the original.
It is already there: look for a file called ps-menurc in the top-level directory of the source distribution. If you install this file in your ~/.gimp directory, you will get the same keyboard mapping as PS.
What you want to do is to increase the "Tile Cache Size" (in File->Preferences/Environment) to a value that as large as possible. Set it to a value that is close to the amount of physical RAM available on your system and the GIMP should work much faster. The recent 1.1.x versions of the GIMP (soon to be 1.2) include a nice dialog box that pops up during the installation and explains how to set up this value.
But that would only solve a part of the problem: it would still take time to refresh the image during panning operations if your the factor is 1:8 or 1:16, because the GIMP has to fetch every 64th or 256th pixel in the original image before drawing it. This leads to cache misses in the CPU, and the coordinate scaling requires some additional operations for every pixels that is drawn. As explained in other comments, some programs are storing temporary copies of the image at various resolutions in order to speed up the panning operations on zoomed-out images. The advantage is that you can move around faster, the disadvantage is that these temporary views have to be re-computed every time you change the zoom factor. The GIMP is fast when zooming in/out but slow at redrawing large images. Other programs are fast when panning a zoomed-out image, but slow if you want to change the zoom factor.
As with many other things that involve a tradeoff between CPU cycles and memory, this should probably be configurable. Yet another idea for version 2.0...
Hey Sven, it's better if you include a link to your great FreeType plug-in. :-) Here it is: http://freetype.gimp.org/.
Here are some answers to your suggestions:
Many things are already possible with the upcoming version 1.2 of the GIMP. I suggest that you have a look at the tips and on-line help that are distributed with the current version, or that you have a look at some of the recent books, such as Grokking the GIMP or the GIMP handbook by Sven.
I think that you are confusing two things: wavelet coding of an image and hierarchical editing. Wavelets should can be useful for the final output (saving the final image as JPEG2000), but they should not be used as the internal representation while you are editing the image. You cannot (in most cases) mix wavelets and lossless editing.
On the other hand, some kind of hierarchical editing can be interesting if you are working on huge images. It could be implemented by extending the current concept of layers in the GIMP, and it would not even require a major re-write of the plug-ins and tools. If I have too much spare time (cough!), I may even consider implementing this for version 1.4 or 2.0.
The only thing that would have to be done is to allow the layers of an image to have different resolutions. So the background layer of the image could be stored at 300dpi while the other layers are stored at 2400dpi. Most of the plug-ins and tools work on one layer at a time and are independent of the resolution of the image, so they would not have to be modified. Some other operations such as "Merge visible layers" or "Bump Map" would have to be re-written, but it should not be that difficult.
But I am not sure if there would be a big advantage in doing that. You would save some memory, but several operations (including displaying the image) would be slowed down because it would be necessary to check the resolution of all layers and to re-scale them at the same resolution before merging them.
There was one easter egg in version 1.0.x of The GIMP, introduced in 1998 by Adam D. Moss. It was rather hard to find because you had to use the DB Browser and see that one plug-in registered itself as "plug-in-the-egg" but did not appear in any of the menus. If you tried to invoke this procedure, it would display some pretty animations on your screen.
But a few weeks after this was added, it was taken out of hiding in the developer's version of the GIMP (versions 1.1.x), where it registers itself as Filters->Toys->The Egg. As Adam wrote when the hidden plug-in was revealed, I guess we need a new easter egg for version 1.2...
I disagree. I have a PC that has both Linux and Windows on it. Neither of these can modify Word documents. On the Windows side, I cannot even view the Word documents created with recent versions of Word, because I did not buy the latest version of the program. On the Linux side, I can view most documents but I do not have any good editor that can be used to modify the documents easily.
So using Word as a file format would prevent some people from reading or modifying the documents unless they buy some proprietary software. I fully support the fact that Word should be considered as an "Opaque" file format.
Well, if you can show me a program that is freely available on all platforms described above and that can view and edit all documents produced by Word 2000 without loosing any graphics, cross-references or other meta-information, then I could think twice about it...
Ah well, I should have been a bit more careful before posting: Octave is not really a symbolic math program. So I wouldn't mind if my previous comment as well as all others that suggest using Octave were moderated down as "Offtopic"...
For symbolic math, maybe SciLab (Open Source, not much symbolic stuff but a bit of it anyway) or MuPAD (free but not Open Source) could help, although I haven't personally tested them.
You should have a look at GNU Octave, which is mostly compatible with Matlab.
I tried it under Solaris and Linux and it works quite well. If you have the opportunity to compare Matlab and Octave running on the same platform, you will find that Octave is a bit slower and consumes more resources, but not up to the point that it becomes a problem. Several of the Matlab examples can be ported to Octave and they run fine.
You can find Octave in the latest Debian and SuSE Linux distributions. If you want to compile it yourself, you will need a recent version of gcc (with support for C++ and FORTRAN), the C++ library and optionally gnuplot for the graphics. You will also need some disk space and some patience while the stuff compiles, but the package is reasonably easy to configure, compile and install. Good luck!
I tried to find out where the server for the .cx domain could be located. Here are the results of a traceroute done from the nice tools page of SamSpade.Org:
Also, all the hosts that I could find and that seemed to be related to the top-level .cx domain (DNS, mail servers, etc.) are aliases for some machines in the domain .planet-three.net.
And whois reports the following for planet-three.net:
But the location of the DNS servers should not matter, because the DNS can map a domain name to an IP address that is located anywhere in the world. So you can keep your server in a cool and dry room without having to worry about the weather in the Christmas Island.
He he he. :-) That's right: usually, computers and water do not mix very well.
But if I am not mistaken, the servers for the .cx domain are not located on the Christmas Islands. I could not find this information on their pages, but I think that they are somewhere in the US or Australia, probably in a slightly drier place. So the servers should be safe.
Aw... Poor Raph! I have enjoyed the low-traffic / high-quality nature of advogato.org since the end of last year, and I was hoping that nobody would post a link to your site on Slashdot. Well, not only do you get a link to it on Slashdot, but even better than that: you make it to the front page. Ouch!
That being said, I read Knuth's interview when it was published and I liked it very much.
That could be a good idea, indeed. However, the most important advice (document everything) will then become very tricky. The ghost author will have to explain how he has acquired the information, written the code, and so on. The ghost author will also need one or several friends who can testify that he has found all this by himself.
Nevertheless, finding a friendly party in a country that allows reverse-engineering might be a good solution for people living in the USA or in other countries that have stupid restrictions on reverse-engineering. Alas, even European countries are now modifying their laws to prohibit reverse-engineering because of the pressure from several big companies.
Easier said than done... However, this brings an important point: it is crucial to check for patents before releasing something that is considered to be a trade secret. If something is proprietary but not patented, then it is perfectly legal to re-implement it (as long as you use a "clean room" process and you do not copy anything directly from the current solution). But if anything is patented, then it is not possible to release this to the community.
Why? If he has spent a significant amount of time studying the problem and the existing solutions, I doubt that he would be happy to see some companies taking his solution and making a proprietary product out of it.
Bad advice. If the intent of the author is to release something to the community, then he probably wants to be sure that it would be possible for others to use his work. Releasing the code or documentation anonymously would not help anyone, because they would have to prove that the original information was obtained legally, which would be impossible if it comes from an anonymous source.
I think that the only good advice is: document everything. If you want to release something (possibly controversial) to the community, then the only way to make sure that others can really benefit from what you have done is to be accountable for it. You have to be able to prove that all the information was obtained legally, and that it does not come from any confidential documents. If every source of information is legal, then the community can benefit legally from your work (and you will be able to cover your back because you can prove how you obtained the information).
After reading the paragraphs in which Chris DiBona explains how the developers were selected for the IPO, I conclude that the list of people was based on the number of times each e-mail address appeared in the 11 GB of source code he had selected. Or more probably, on the number of files in which the addresses appeared (it would be too easy to cheat by inserting your e-mail address a thousand times in the same file).
I understand that it is not easy to find an objective way to select the developers who contributed the most to the Open Source community. It is especially difficult to have a process that could be automated as much as possible. And it is extremely difficult to be fair.
But still... Now I realize that modesty does not pay when you write your code. Instead of inserting your e-mail address only once at the top of the AUTHORS file (and in the ChangeLog) but not in any source file, it seems to be better to include your e-mail address in every source file that you touch. Sigh!
And of course, don't use spam-traps if you want to get the opportunity to participate in some IPO. Sigh!
Hmmm... As far as I am concerned, I think that I will stick to the old habit of being credited only once or twice, not in every source file.
I think that we are talking about slightly different issues: you present a project that was once developed on one platform, then it was ported to other platforms. I suppose that you still add some features and bug fixes afterwards, but I assume that you do not re-structure large parts of the project regularly. I mentioned a project in which most of the code is being actively developed for all platforms at the same time, and there are some major changes done in the cross-platform code. When you have many platforms to support, including their variants (e.g. Windows CE for MIPS processor is not the same as Windows CE for SH3), then you have to be sure that any new source file added, deleted or renamed in the cross-platform libraries is correctly updated in all Makefiles (or whatever build system you are using).
In my project, we solved that problem by using included Makefiles that are shared by several platform-specific Makefiles, which allows the various builds to use the same source files even if each platform uses a different compiler and different settings. Another poster described a very similar solution. But even that is not always easy to manage, especially with several hundred source files in many different directories. If I break something, then it does not take long until a colleague complains that the version for this or that platform does not build anymore (or at the latest, the nightly build will send me a message about it).
The original poster in this thread said that he likes CodeWarrior because it is easier for him to manage his build system. If he is used to it and if that works well, then why not? I think that for large projects, some IDEs may be better than Makefiles if your applications contain a lot of stuff that is not pure code (i.e. icons, bitmaps, pre-made dialogs, hotkeys, etc.) and if that stuff must be available in more than one language. Some IDEs are quite good at handling all this "extra stuff" and I suppose that this is one of the reasons why he said that he relies on CodeWarrior.
Note that I am not the same person as the one who complained about the lack of CodeWarrior for Linux. In fact, I have never used CodeWarrior in any real project (and it is unlikely that I ever will, because I am quite experienced in writing good Makefiles). I was simply trying to explain that Open Source tools are not always available for developing software, especially on non-UN*X platforms, and this is why some companies rely on closed source IDEs.
Open Source software is not always an option if you are writing cross-platform code: most Open Source development tools are available for Linux and various flavours of UN*X, but not for MacOS, Windows 95/98/NT/2K, Windows CE (a totally different beast), EPOC, PalmOS and so on. If you start with a product that was developed on the Mac and you want to port it to Linux, chances are that the product was relying on CodeWarrior, because CodeWarrior is one of the best integrated environments available on the Mac and there is no Open Source equivalent that comes close. If CodeWarrior is not available for Linux, then it will be harder to convert this product.
I am sure that many companies would not mind using Open Source tools, be it only for being sure that they have their future in their hands. But this is not always possible. And many companies do not have the resources (time and money) to invest in porting the best Open Source tools to their target platforms before starting to develop their products. They just have to live with the closed source IDEs, and hope that their suppliers will support their target platforms in the future.
At work, I am developing some software that is ported to Linux, Solaris, Windows 95/98/NT, Windows CE, EPOC, and maybe a few others soon. We decided to use Makefiles (handwritten or generated) for most of our build system, and to rely on included Makefiles (with nested includes) for making it easier to maintain the global settings and so on. Still, this can be a pain to maintain when you have dozens or hundreds of directories with their own Makefiles. I think that we made the right decision because Makefiles are future-proof and we have more control over what is going on in your build system. But we have to pay the price for that, and it is counted in extra hours when some significant change has to be applied to the build system.
Many companies prefer to set up their build system around some tools such as CodeWarrior, which are supposed to make it much easier to manage large projects. I don't blame them for that, because this is probably what gives them the best benefits compared to the set-up and maintenance costs in the short- or medium-term, especially for (very) large projects. If you have the opportunity to even think about the long term (not always an option when you have to get a product out of the door in the next few weeks), then I would always recommend using a system that does not rely on closed source products, such as Makefiles.
You can make your life easier under UN*X by using autoconf, automake and various other goodies for generating your Makefiles automatically, but these tools do not exist (yet) for Windows or for the Mac. And the cross-compilers are not always an option either. I'm still dreaming of a system that would allow me to have only one Makefile for compiling my code with the correct options under any system (or at least UN*X, Windows and MacOS)...
Since the article did not contain links to the web sites that have some pictures and movies, here are some of the well-known sites:
- www.battlebots.com
- www.robotwars.com (look at the History section)
- www.botbash.com
- www.robotrumbles.com
- www.dangerousmachines.com
- www.sorc.org (Society of Robotic Combat)
- www.robohoo.com (a Yahoo-style index of all things robotic)
Have fun!Good idea. But as others have pointed out, this could lead to another generation of bots, which would not shoot at these dummy fake targets so that the server would not detect that they are bots. Here are a few examples of things that a clever bot could do to check if a target is valid or bogus:
- If the target has a fully transparent skin, it is bogus.
- If the target is stuck inside a wall, it is bogus (requires BSP tests).
- If the target is on the other side of a wall and is not moving, do not shoot: it may be a fake or a real player, but in any case it is not moving so we should not shoot at it yet.
- If the target is behind you (let's say between -150 and +150 degrees) and it has never been seen before and it is not shooting at you, then do not shoot. But turn around from time to time to check if this could be a real player.
- If the target is behind and it has been identified before as a real player, then flip 180 degrees and shoot.
- If the target is moving in a way that would be impossible even with movement prediction/correction (e.g. a player that is constantly behind you even if you do some fast spins) then it is bogus.
- In all other cases, shoot.
This could probably be refined a bit, but as you can see it would be possible to create a bot that tries to fool the server-side aimbot detection schemes.But... there is still one thing that could be done to detect the bots, and maybe that could make the aimbots much less useful: instead of inserting bogus players into the walls or immediately behind or under the bot, put them in another hallway that is part of the PVS. Make the dummy run like if it was about to be visible a few milliseconds later. And make it disappear just when the bot would expect it to be visible. This has to be timed right in order to ensure that the dummy does not become visible even if there is some network lag, but I think that it would be nice to have something like this to detect the aimbots.
So if the bot shoots at the location where the invisible player would have entered the room, then mark it as a bot and the problem is solved (ban the cheater). If the bot does not shoot, then the problem is also solved because that bot will only shoot at visible targets.
Besides that, I think that two of the best solutions mentioned in the other replies to this article are:
- Reputation servers. If you want to play, you have to be registered. If you are marked as being a cheater, most servers will ban you.
- Signed clients and servers. Everyone can use and modify the source code of the clients and servers, but from time to time there are some "official" releases of the client and server that are digitally signed and contain some challenge-response mechanism. The signed servers have an option to accept only signed clients, so that nobody can cheat on these servers.
Of course both of these solutions can be abused too, but it is more difficult. You could register multiple players and move to another one when one is marked as a cheater, but it would be difficult to go very far with that. Also, a clever hacker could break the challenge-response mechanism in the signed client and create a hacked client that gives the same responses as the official one, but that would take time (hopefully longer than the time between releases).No system is perfect and nobody has an infinite amount of time to spend on making the games more secure. But some solutions can make cheating difficult, especially if the cheat is obsoleted by a new release.
I disagree: the people who submit stories are not necessarily the same as those who moderate comments (and could also moderate stories). In order to be allowed to moderate, you have to "earn" your moderator status. There is no such thing for submitting stories.
The moderators are selected among the people who have posted interesting comments (OK, the karma thing has some flaws, but the general idea is good). The moderators are supposed to have a good judgement, or at least to have some sensible opinions. But there is no "filter" for submitting stories, so I don't think that the number of submissions is a good metric to judge if a story will be appreciated by the /. readers.
Let's take an example: a link to a story about Micro$oft is submitted by 50 AC's (or registered users with low karma). Another story, more technical and less controversial, is submitted by two or three users. If I had the opportunity to moderate the stories and if the second one is really interesting, then I would probably give it a +1 and ignore the first story. On the other hand, if you only judge a story based on the number of people who submitted it (or later, on the number of replies), then you would always select the first one and maybe the second one would never be posted.
That's why I think that allowing the moderators to rate the stories as well as the comments would be an interesting addition to /.
Another interesting addition would be to rate comments and stories on different criteria and to allow readers to filter the comments based on the criteria that are important to them, and not only on the total score. I would start with three critaria:
- technical content. Is the comment "interesting" or "insightful" from a technical point of view? Does it give link to other sources of information or does it contain good explanations for the topic being discussed?
- good advocacy. Does the comment do a good job at promoting Linux, nanotech or any other thing that nerds might be interested in? The comment might not contain many technical facts but contain enough good ideas or state things in a clear way so that you would rate it as "interesting" in the current system.
- humour. Is it funny? Are you ROTFL after reading the comment?
The current system covers these criteria, but as a reader your are only able to filter the comments based on their total score. I have seen several old-timers onNow that I think about it, a fourth criterion could be "on-topicness". An article can be off-topic but still contain interesting ideas. Some people like to read such articles, some others don't. By giving the appropriate weight to this criterion in the comment filter, then every reader would be able to select what he wants to see.
If you want to build a realistic universe, you need to provide a way for the players to move freely from one area to another without even noticing that the two areas of the universe are handled by different servers.
You could of course include teleporters, subways, or special doors to move the player from one server to another (IIRC, that idea was mentioned by John Carmack and also by John Romero in the pre-Quake days). But that would not really give the feeling of a single large universe because switching from one server to another would still require a specific action. So the areas would only be semi-connected.
Note that even this simple scheme contains some interesting problems:
But the real challenge is to implement a seamless world, in which people can move around as if everything was part of a single huge map. The players should not be able to see that they are moving to a different server. In addition to the problems mentioned above, you get a lot of problems in the "frontiers" of the metaverse, as mentioned by the original poster.
For example, how will you be able to see an area that is handled by a different server than the one you are connected to? One solution would be to replicate (cache) the visible parts of the "foreign" areas on each server, but that would not work for players or any other moving objects. So the servers must exchange some informations whenever something changes near the frontiers. But there are some latency problems. If you are familiar with the QuakeWorld/QuakeII/QuakeIII problems regarding lag and movement prediction, you can imagine what will happen if more than one server is involved.
Anyway, I have been playing around with these ideas for a while and I think that I have found some solutions for building a fully distributed world (taking input from Quake, CrossFire and my personal experience about building distributed and redundant systems). Maybe I will write them down someday, and maybe even build a library that implements the necessary network protocols. Maybe...