Closed Source Linux Distribution Launched
|In a press release dated 00:01, 2003Apr01, Random Hackers, Ink., announced the release of Randlix 0.01, a new Linux distribution. The distro, according to the announcement, includes proprietary code and doesn't exactly look like open source. Our reporter managed to contact one of the principals of this new company earlier today. |
"We are in compliance with the terms of the GPL", said Rupert Goldberg, president and cofounder of Random Hackers, Ink. "Technically, our product is open source. However, we intend to charge $25,000 for a single license of the binary distribution. A coupon for a free copy of the source CD will be included at no charge with each binary distribution and license. The catch, heh heh, is that we bill in two stages. We initially charge only a nominal media fee -- fifty dollars -- for the binary distribution. Included along with the advance binary media kit is the bill for the balance due, $24,950. Upon receipt of the balance due and the coupon, we ship the source CD. No one has yet completed the licensing terms to the point of receiving a source CD -- and we suspect that no one ever will. This method of closing the source of a GPL product does have the disadvantage of rendering all of our binary users uncompliant with our license, but we don't care."
"Technically, we have no official users. There is no one out there who can legally request the source to our Linux distribution. And that's the way we like it."
'Rube', as the Random Hackers, Ink. president prefers to be called, went on to explain at some length how his method of distribution allows the buyer to look over the distribution and, in contrast with many other software products, lets the buyer complete the transaction only after they agree to the terms of the included license.
"We don't believe in the legality of the shrink-wrap license", said Mr. Goldberg. "With our system, there are no surprises. Uh, except one.", he added with a sly laugh.
For more information on Randlix Linux, click the [read more] link below.
|mail this link | permapage | score:9211 | -Ray, April 1, 2003|
No, RMS, Linux is not GNU/Linux
|No, Richard, it's 'Linux', not 'GNU/Linux'. The most important contributions that the FSF made to Linux were the creation of the GPL and the GCC compiler. Those are fine and inspired products. GCC is a monumental achievement and has earned you, RMS, and the Free Software Foundation countless kudos and much appreciation. |
Following are some reasons for you to mull over, including some already answered in your FAQ.
- One guy, Linus Torvalds, used GCC to make his operating system (yes, Linux is an OS -- more on this later). He named it 'Linux' with a little help from his friends. Why doesn't he call it GNU/Linux? Because he wrote it, with more help from his friends, not you. You named your stuff, I named my stuff -- including the software I wrote using GCC -- and Linus named his stuff. The proper name is Linux because Linus Torvalds says so. Linus has spoken. Accept his authority. To do otherwise is to become a nag. You don't want to be known as a nag, do you?
- (An operating system) != (a distribution). Linux is an operating system. By my definition, an operating system is that software which provides and limits access to hardware resources on a computer. That definition applies whereever you see Linux in use. However, Linux is usually distributed with a collection of utilities and applications to make it easily configurable as a desktop system, a server, a development box, or a graphics workstation, or whatever the user needs. In such a configuration, we have a Linux (based) distribution. Therein lies your strongest argument for the unwieldy title 'GNU/Linux' (when said bundled software is largely from the FSF). Go bug the distribution makers on that one. Take your beef to Red Hat, Mandrake, and Slackware. At least there you have an argument. Linux alone is an operating system that can be used in various applications without any GNU software whatsoever. Embedded applications come to mind as an obvious example.
- Next, even if we limit the GNU/Linux title to the GNU-based Linux distributions, we run into another obvious problem. XFree86 may well be more important to a particular Linux installation than the sum of all the GNU contributions. More properly, shouldn't the distribution be called XFree86/Linux? Or, at a minimum, XFree86/GNU/Linux? Of course, it would be rather arbitrary to draw the line there when many other fine contributions go unlisted. Yes, I know you've heard this one before. Get used to it. You'll keep hearing it until you can cleanly counter it.
- You seem to like the lines-of-code metric. There are many lines of GNU code in a typical Linux distribution. You seem to suggest that (more LOC) == (more important). However, I submit to you that raw LOC numbers do not directly correlate with importance. I would suggest that clock cycles spent on code is a better metric. For example, if my system spends 90% of its time executing XFree86 code, XFree86 is probably the single most important collection of code on my system. Even if I loaded ten times as many lines of useless bloatware on my system and I never excuted that bloatware, it certainly isn't more important code than XFree86. Obviously, this metric isn't perfect either, but LOC really, really sucks. Please refrain from using it ever again in supporting any argument.
- Last, I'd like to point out that we Linux and GNU users shouldn't be fighting among ourselves over naming other people's software. But what the heck, I'm in a bad mood now. I think I'm feeling sufficiently obnoxious to make the point that GCC is so very famous and, yes, so very useful only because Linux was developed. In a show of proper respect and gratitude, shouldn't you and everyone refer to GCC as 'the Linux compiler'? Or at least, 'Linux GCC'? Seriously, where would your masterpiece be without Linux? Languishing with the HURD?
If there is a moral buried in this rant, maybe it is this:
Be grateful for your abilities and your incredible success and your considerable fame. Continue to use that success and fame for good, not evil. Also, be especially grateful for Linux' huge contribution to that success. You, RMS, the Free Software Foundation, and GNU software have reached their current high profiles largely on the back of Linux. You have changed the world. Now, go forth and don't be a nag.
Thanks for listening.
|mail this link | permapage | score:9202 | -Ray, September 26, 2002 (Updated: September 27, 2002)|
Space Tyrant: Multithreading lessons learned on SMP hardware
|There is much to report in this update of Space Tyrant. Before getting into the new features and functions, I’ll dispense with the crisis of The Bug. |
For a couple of weeks, we had been noticing odd anomalies with Space Tyrant (ST) running on the virtual server at Ioresort.com (now offline -Ed.). We never saw the problem on any other box -- and it was tested on at least four other Linux boxes and a Mac OS X system. We did all manner of stress testing, locally and over the Internet, script based and even feeding the game the output of /dev/random. Nothing caused the anomaly on any other box.
At first, I suspected that it might just be an obscure problem with the virtual server itself; after all, I had been forced to modify the TLR code to get it to run properly there. That problem turned out to be merely a limitation of NFS, not a bug with the virtual server software. However, the environment was clearly different from any other system I had used which raised my suspicions -- and reduced my urgency about looking for the bug.
While the bug wasn’t frequent, it was persistent. The bug appeared to be related to corrupted buffers or corrupted buffer indexes. Out of idle curiosity, I lowered the number of buffers used by ST to see if that affected the bug. Somewhat counter-intuitively, it substantially raised the frequency of the problem.
Brian Estabrooks (the hero of this release) and I spent more and more of our efforts hunting this incredibly elusive bug until that was all we were doing. I implemented various diagnostic routines hunting for clues. The all seemed to point to buffer indexes being changed incorrectly. Both Brian and I audited the code. It seemed impossible for the indexes to be changed improperly. Brian even went so far as to replace the ring buffer scheme with a high watermark approach but to no avail.
While I continued to suspect it to be a simple logic error in the code, Brian turned his efforts elsewhere. What he came up with was quite interesting. It seems that on many hardware architectures (most? all?), modifying a bit field can temporarily modify other bit fields in the same word! Now, this isn’t a problem on a single-CPU system; it repairs the damage in the same operation, making it, effectively, atomic. On an SMP machine, however, two different CPU’s working on different bit fields of the same word simultaneously create havoc. The operation isn’t really atomic and it doesn’t work.
Did I mention that the virtual server is a 4-way Xeon system?
The ring buffer indexing in ST relies on unsigned integer bit fields to automate wrapping back around to the first buffer after using the last one. My parsimonious programming, of course, packed all the bit fields together, several to a word. Brian’s test version of ST added a pad after each buffer index to round it out so that each bit field lived alone in its own complete word. We abused the new version for nearly an hour before either of us would dare say it. The bug was gone.
So, the moral of this story is: Operations on sub-word fields affect other bits in that word (at least on many hardware architectures). Tread very carefully if multiple threads are accessing different bits in shared words. It may appear to work perfectly, only to crumble into a pile of smoldering rubble the first time it's loaded on a multiple CPU system!
Other than the primary lesson, some other good things came out of (the search for) the bug. Several other latent bugs were found and fixed and Brian and I are both much more intimate with the code.
And, on to the enhancements. ST is starting to look like an actual playable game. The following functions implement the new major features.
players(): We now have player rankings. It works by adding all the players’ ship resources to an integer array. Then it scans the universe looking for deployed fighters and adds those to the array as well. Currently, those two items comprise the total strength of a player.
It then sorts the array with a recursive bit-plane sort that I wrote for Starship Traders in 1998. The qsort() function in the C library was plenty fast, but took too much memory for my taste. Memory was a bit scarcer in those days and, worse, the SST software model gave each player his own copy of the server.
The sort reorders the array in place as follows. It scans the high-order bit in each element of the array. It then moves all elements starting with ‘1’ bits to the top and all starting with ‘0’ bits to the bottom. Next, it calls itself twice to reorder the first and second chunks of the array on the second bit. Each of those two instances of the sort then call the sort twice again, now giving 4 new sorts for the third bit, and so on. When all 32 bits are accounted for, the array is in the correct order with the top player on top, etc.
Scanning the entire universe can be expensive with a large map. Therefore, the player rankings function keeps the result and time stamps it. If another player asks for a player ranking within five seconds, the system just gives them the old one. After five seconds, however, any new request triggers a fresh listing.
autopilot(): We’ve added an autopilot to let a player find a specific sector -- or to locate the nearest planet. If you type a ‘0’ (zero), you’ll be prompted for a sector number within 1000 of the sector you’re currently in. You then will have the option of pressing ‘/’ to automatically warp to the destination sector.
If you’re looking for a planet, type the ‘L’ command that you would normally use to land on a planet in your sector. In the absence of a planet, the L key will engage the autopilot which will search for the nearest planet and give you a ‘/’ command to autowarp to it.
The new autopilot function consists of two other functions in addition to autopilot(), which is merely a control function. I had intended to use the old shortest path algorithm function from TLR but it was big and complicated. I decided to try to write a simpler, recursive shortest path algorithm instead. The new recursive function is much simpler but not quite as efficient as the giant for loop in TLR.
The actual algorithm is implemented in two functions called pathdepth() and pathcalc(). The pathdepth() function repeatedly calls pathcalc() with an increasing ‘depth’ parameter. ‘Depth’ tells pathcalc() how many levels deep to search before giving up.
The pathcalc() function simply looks to see if the sector it is looking at is the target sector. If not, it calls itself for each new sector that the current sector connects to. If the current sector is the target sector, it starts filling in an array for the autowarp() function to follow to reach the target sector. As the previous recursive calls to the pathcalc() function exit, they fill in the remainder of the path array.
And, yes, I seem to like reinventing the wheel. ;-)
The other interesting addition to the code is the backup thread. It is implemented by a function called backupdata() and works as follows: It scans the player data, the map data, and the history data looking for ‘dirty’ flags. (Whenever any persistent data is changed anywhere in the game, a dirty flag is set to tell the backup thread to write it out to disk.) This process is quite fast for a small game, but for a game with millions of sectors, it’s a significant waste of resources to scan the dirty flag array frequently.
Therefore, for the map and history data, I’ve implemented a ‘dirty block’ scheme as well. When a dirty flag is set, its corresponding dirty block flag is set too. Then, the backup thread need only scan the dirty block arrays, typically only about one percent the size of the arrays it represents. When a dirty block is found, only the hundred or so records it points to are scanned to find the actual dirty records for backup.
The backup file, named ‘st.9999.dat’ -- where ‘9999’ varies with the port number you run the game on -- goes into the current working directory from where you start the daemon. If the file doesn’t exist, a new game is started. Also, if you’ve modified the game in a way that changes the size of the data -- by increasing the map size, for example -- it will start a new game upon startup.
The game can be shut down from the command line by sending a signal 15 (kill -15 pid) or by the admin with the ^ command. Note that the first player to create an account in a new game automatically becomes the admin of the game!
makehistory(): The storing of historical data is new as well. Whenever another player attacks your ship while you’re logged off, you’ll get a report of the action and any losses when you next log on. Also, for remote deployed fighters, you never get immediate notification, so that information is stored in the history log even if you're logged on when it happens. You can view any accumulated event information since your login time by pressing the ‘e’ key.
deploy(): This simple function allows a player to deploy, or retrieve, guard fighters in a sector. Those fighters will not let another player pass through or view any of the contents of that sector. Any ships parked under the fighters are automatically protected against all attacks except for an attack by the fighters’ owner. Once the fighters are destroyed, of course, all ships there are visible and can be attacked.
There is also a newly implemented time limit in the game to limit the total online time of a day’s sessions to 4 hours. Like most other parameters, it can be changed by modifying a #define statement near the top of the code.
command(): The help page, a menu of available commands that a player can perform, has been redesigned and rewritten. This menu is attached to the '?' key.
The old debugger thread is gone, replaced by an in-game command function called showdata(). Press the ‘z’ key to see information on buffers, buffer indexes, and the backup thread’s state and history. Only if you’re serious about modifying the code will this information be useful.
The section of the gameloop thread that broadcasts radio and news messages has been modified to show only one of each type of message per pass. That way, replaying a long radio history won’t flood the output buffers and longer radio and news histories can therefore be retained.
The old jumprtn() movement function has been consolidated into the warprtn() function. It’s only slightly more complicated than having them separate.
The current source code can be downloaded from http://librenix.com/st/st.158.c. and the original article in this series is here. As usual, the compile script is embedded in the comments at the top of the source file. You’ll have to rename the source st.c for the script to work unchanged.
[A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]
|mail this link | permapage | score:9195 | -Ray, June 26, 2005 (Updated: July 26, 2008)|
Download: Linux 3D Client for Starship Traders
|[Note: Katrina Kirellii now maintains the Linux and Windows versions of the graphical client. The new code can be downloaded from this page.]|
Linux game testers wanted
A new version of the Starship Traders multiplayer strategy game is under development. The new version, ST2, has a 3D interface and includes an X-Window-based client program. ST2 is considerably faster than its WWW predecessor and integrates a graphical display and point-and-click mouse controls with a complete keyboard interface. Linux users are needed to participate in the first test game since no other operating systems are yet supported.
The new server is up and running now and a Linux version of the client is available. The client is a dynamically linked Linux x86 binary and requires the Mesa3D or OpenGL libraries -- which should already be installed on most modern distros. Internet access is also required to play in the test game, of course.
To participate in the game you must download, gunzip, and run the Linux binary as described below. It should connect to the ST2 test game automatically and you will be prompted to log in.
[Here is a screenshot of a sector with a starbase, a planet, a tradingpost, some sector debris, a few fighters, a wormhole, and, if you look closely, a couple of small starships in the lower left quadrant intermixed with the text. This screenshot is with the window at 640x480. For a less cluttered appearance you can click resize -- while playing -- to expand (or shrink) the window.]
Download and setup instructions
... and you should be online.
- Right click here
- select Save ...
- gunzip sst012.gz (your browser may do this step automatically)
- chmod 555 sst012
The source code, released 17 September, 2001, can be downloaded from this page.
Starship Traders II is a trading and war game set in a universe divided into multiple galaxies. Individual locations within the game, called 'sectors', can contain ports, planets, nebulas, wormholes, and black holes, as well as objects owned by players. Players can park their starships, deploy their fighters, and build starbases in sectors.
Players can earn money ('microbots') by hauling commodities between ports and from planets. These microbots can be used as cash to buy equipment and military hardware at trading posts, or microbots can be used directly in combination with commodities to build fighters or starbases.
Players can deploy fighters and build starbases to guard prime trading territories and valuable sectors or they can use fighters to attack the deployed forces of other players. Players can also attack and destroy the starships of other players that they find.
Players can create teams which are ranked separately from the player standings. Players can apply to a team and the team captain can then either accept or reject the application. Team members can move safely through the fighter and starbase fortifications of their teammates and allied attack-mode starbases will not attack them.
Obviously, as in any multiplayer strategy game, politics and diplomacy can be important. Try to avoid making too many enemies early in the game!
F1 and F2 will scroll you back and forward in the scrolling portion of the heads-up display. F10, F11, and F12 will select different size windows. Running the client with a -w argument (eg.: sst012 -w) will cause it to load into a normal, resizeable window with the standard borders and window controls. Otherwise, it runs in a full-screen mode which may not include borders.
You can fly around within a sector using the arrow keys and pageup/pagedown. Don't do much of this or you may get lost. As you enter each new sector, you start out in the same relative position that you were in in the previous sector so it's possible to fly far away from the center of a sector and not easily find it again. If that happens, log out and back in to get back to the center of the sector.
Move the mouse over any clickable menu option (those that change color when the pointer is over them) and wait about 2 seconds for a popup tip about that menu item.
There is a log off (quit) command in the menu that logs you out, disconnects from the server, terminates the client, and closes the window. If you go link-dead while playing, however, or are otherwise left with an unresponsive client, press Escape to close the window and terminate the client.
Routine trading and galaxy exploration can be accomplished with as little effort as clicking Computrade on the heads-up display. You can also click on anything in the top half of the display to select that option. Note that options containing a capital letter can also be selected by pressing the appropriate key. Therefore, pressing the c key is equivalent to clicking Computrade.
Options without a capital letter generally have the hot key designated with parens. For example, "keyboard map (?)" can also be accessed by the '?' key.
Right click on any item in the top half of the heads-up display for a brief explanation of that menu option (and the corresponding keyboard key).
Starship Traders II is derived, through a long and meandering lineage, from The Last Resort, which evolved from Tsarwars, itself inspired by Czarwars. Czarwars was a DOS-based BBS game dating back to December, 1986. Czarwars was inspired by Chris Sherrick's version of Trade Wars, which drew it's inspiration from Hewlett-Packard's Star Trader, from The People's Book of Computer Games.
5/22/01, v.0.02: Lockup after 5 minutes idle bug fixed
5/24/01, sst004: Menu items change color, Star clusters added
5/24/01, sst005: Popup tips added on clickable items
5/24/01, sst006: Rotating ports
5/26/01, sst007: Bigger, moving fighters, more popup tips
5/26/01, sst008: Moving ships, more popup tips
5/27/01, sst009: All heads-up display items now have popup tips
5/27/01, sst010: Bug fix: resizable window works again
5/29/01, sst011: Colors won't wash out on some displays, cursor added, in-sector movement speed scales better on high-speed displays, bar charts work correctly, bottom line of text doesn't disappear on some window sizes
5/31/01, sst012: minor popup documentation changes
5/12/02, sst012d: bug fix, new menu options added
|mail this link | permapage | score:9090 | -Ray, May 12, 2002 (Updated: March 21, 2007)||