Expect Script Examples
|Expressions, if statements, for loops, and while loops examples are covered in this mini-tutorial:|
This article explains the following in the expect scripting language. read more...
- Expressions – arithmetic operation
- if construct in expect
- looping constructs
|permapage | score:9166 | -Ray, January 21, 2011|
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:9158 | -Ray, June 26, 2005 (Updated: July 26, 2008)|
System monitoring: Icinga, Nagios, and Opsview
|Three open-source system monitoring software packages, two of which are derived from Nagios...|
If in your work you are responsible for just one server, you will surely wonder: What is the best way to get the situation under control? read more...
In the world there are good open source software that allow you to monitor the status of servers, services and programs.
In this article we’ll see an overview some of the softwares in this category, and in particular some related to Nagios...
|mail this link | permapage | score:9154 | -Ray, March 24, 2011|
64-bit Desktop: SuSE vs. Fedora vs. Windows XP
|The 64-bit versions of SuSE and Fedora are compared against both the 64-bit version of Windows XP and the 32-bit versions as well.|
To get a well-rounded breakdown of where Linux is going, and where it trumps (or fails against) Windows, we took the two largest 64-bit Linux distributions, their 32-bit counterparts, and the Windows XP 64-bit public beta for a test drive. The way that we are running the benchmark is slightly unique; we do not recompile or optimize benchmarks per hardware platform. Our goal is to see which out-of-the-box operating system performs the best with as much support as possible.[If you don't already have a 64-bit box, here's a shortcut to building a 64-bit system based on an Athlon 64 dual core processor or a cheaper single core chip.] read more...
|mail this link | permapage | score:9097 | -Ray, July 13, 2004 (Updated: October 28, 2005)|
Beginner Ubuntu Tips
|Twenty-five tips for Ubuntu beginners...|
Adding another source for software is easy; once you've installed addrepo, you can do it in the terminal by typing something along the lines of addrepo deb http://mirror2.ubuntulinux.nl/ lucid-seveas all.
If you find new repositories online, they will usually give you the right details to enter. You could also do it graphically by going to 'System | Administration | Software Sources | Third Party Software | Add'. read more...
|permapage | score:9077 | -Ray, November 9, 2010|
Tutorial: Run multiple OSes with free VMWare Player
|This HOWTO will take you through the steps necessary to use VMWare Player to run multiple operating systems simultaneously on your PC.|
VMware Workstation has always been (and still is) a commercial product, and you have to pay a fairly large sum to get your hands on it, but VMware have now released a free application dubbed “VMware Player”, which can run virtual machines produced by VMware and a few other companies. Yet, with some simple hacks, we can use VMware Player to run any x86 Operating System we like. read more...
|mail this link | permapage | score:9074 | -Ray, December 19, 2005|
Space Tyrant: A threaded game server project in C
|[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]|
[Update, March 21, 2007: A Space Tyrant has its own website! It's small but growing and will provide quick access to the latest code and developments in the ST universe.]
Space Tyrant: Today we kick off a new multithreaded, network socket programming project which we will call Space Tyrant. Our mission is to write an open source, multiplayer, networked, strategy game in the C programming language. The goal of this project is to make a solid code base which implements a simple space trading game upon which other games can then be built. The game will be a subset of The Last Resort (TLR) that currently runs at [offline]. This project will be a learning exercise for me as well as for any interested readers. The current state of the source code will be released with each article update.
The game design: While my TLR game consists of over 25,000 lines of C source code and supports a web interface as well as telnet and a graphical client, this code will be far smaller and simpler. It will initially only support telnet and will implement a far simpler game design.
Players will be able to telnet into the game, create an account, and play in a universe that contains ports, planets, as well as other players. Each player will be issued a starship, some cargo holds, and an amount of starship fuel. Additional fuel will be issued hourly and will accumulate in the starship. Fuel will be used to move the ship between sectors -- locations within the game universe -- and to dock with ports. Once a ship runs out of fuel it can't move at all until new fuel is issued.
Players will be able to buy and sell commodities (Iron, alcohol, and hardware) between the three different kinds of ports. Each port type will sell one of the three commodities and buy the other two. Prices will be based on supply and demand with rarely-used ports offering the better prices.
With the money players earn trading they will be able to buy more cargo holds to make their ships more efficient for trading. They will also be able to buy fighters -- small military drones -- that can be used to attack other ships or deployed to guard a sector and its contents. The fighters carried with a ship will guard it against attacks from other players.
Games will run for a predetermined length of time, then reset and start anew.
The programming model: Now, on to the software design. I've compared and considered various models for the server design. TLR is based on the forking model using inetd or xinetd to handle the listening and forking. While the forking model is inherently distributable to multiple processors, it introduces inefficiencies (forking multiple processes) and makes interprocess communications more difficult and slower.
Next, I considered a non-blocking, single process model. In this approach, one process handles everything in a single thread. It would use non-blocking IO (read and write functions that never wait for completion but, rather, return immediately if they aren't ready to read or write actual data). The thttpd web server is an example of a non-blocking, single process server. It's extremely fast and efficient. However, this model is quite complicated to code, and, I believe would make it more likely to introduce subtle timing bugs.
Next, I considered a pure multithreaded, single process model with a thread for each player. While appealing in many ways, this model would require the same kind of coordination between threads that the forking model requires between processes. Such interprocess communication would be simplified in that the various threads share memory, but the coordination issues otherwise remain the same.
Last, I considered another multithreaded model, this time with only IO threads for each user and a single thread that implements all game logic. While that one central thread might someday be a bottleneck that limits scalability on large SMP systems, it does distribute the IO on any additional processors that might be present, and requires minimal coordination. In short, this model combines the logic simplicity of the non-blocking single process model with the coding simplicity of the threaded model, while separating the IO from the main logic. There will also be two other simple threads in this model. There will be a thread that listens for new connections and spawns the IO threads for each new connection. There will also be a thread that writes the data to disk periodically.
This is the approach that I intend to take for this project. The code will be written for both Linux and Mac OS X.
More info: I have set up an email address for programmers following this series to provide recommendations, bug reports, and other feedback. Send email about this project to spacetyrant [at] librenix.com.
|mail this link | permapage | score:9072 | -Ray, March 18, 2005 (Updated: July 26, 2008)|
Microsoft to push unlicensed users to Linux
|Microsoft has long had a conflict of interest about software piracy. By pretending not to notice, they encouraged the use of unlicensed Microsoft software, thereby letting dependence on their formats, packages, and protocols grow. The time is approaching when that will change.|
Microsoft has historically made much noise and took little action against unlicensed users of its software. In the case of some developing countries, the reason was obvious. Let them develop a US-style de facto Microsoft business standard and they then become owned by Microsoft.
We've all seen Windows users circulate simple text-only notes in Microsoft Word .doc files. While it may be annoying to those without .doc capabilities (including users of older versions of Word, itself), it is a beautiful thing from Microsoft's point of view. It perpetuates their monopoly while forcing upgrades among the faithful, all in the same simple act. The widespread use of proprietary formats tends to lead to even more use of those same formats.
However, as Microsoft's markets in the US approach the saturation point -- and start to recede -- they are faced with a dilemma. Do they try desperately to hold on to as much market share as possible, or do they cash in while accepting -- and accelerating -- the inevitable decline in share?
I think Microsoft will be increasingly choosing the 'cash in' option as the pressure rises to keep earnings high. The first victims of this gradual policy shift will be business and government users in developed countries with strong IP protection laws.
Next, in approximate order, comes consumers in developed countries and business / government users in rapidly developing countries -- especially those countries seeking easy access to western markets. Last to pay up will be students and consumers in the poorest developing countries.
But, for all of you still getting a free ride from Microsoft, the good times will inevitably come to an end. They are simply waiting until you, and your compatriots, are too invested in the knowlege, skills, and standards of Microsoft products to quit. Then, they will charge you.
If you are an unlicensed Windows user who can't afford to someday become a profit center in the vast Microsoft empire, you should consider the alternatives. I recommend you start by downloading and burning a live Linux CD of Knoppix, booting it up on your Windows box, and trying it out. It's free and since it runs straight from the CD, you don't need to install it on your hard drive.
|mail this link | permapage | score:9067 | -Ray, August 1, 2005|
Linux vs. Windows: Why Linux will win
|One of the oft-mentioned weaknesses of Linux, fragmentation, just happens to be one of its greatest strengths. A broad range of choices in an immature market is a good thing. Of course, choice does come at a cost. For example, there may be no standard way to do a particular task. Further, development resources will sometimes be split among two or more projects. However, these are weaknesses in the short term only. |
One could similarly argue that evolution of species suffers from the same 'weakness' of fragmentation. However, in the long term, the survival and consolidation of the best traits results in an improved breed. Eventually, one of the many approaches to some desktop task will rise to dominance and show the market the right way to do it, and, at the same time, reduce the fragmentation problem.
Based on my observations, business continuity considerations are starting to place more emphasis on portable data formats and protocols. Relational databases, contrasted with the counter examples provided by Microsoft formats, are helping to raise awareness of the value of portable data.
For a private business to blithely entrust their data to proprietary formats and protocols is irresponsible at best. For a public company to do so can be looked upon as a breach of the shareholder's trust; an unnecessary liability. It's quietly overlooked now partly because of the ubiquity of the practice and partly because no Microsoft-dependent organization wants to point out a liability from which they also suffer. This situation will change with growing awareness of the problem and as the Linux-plus-free-applications option makes vendor lock-in increasingly harder to justify. The time is coming when the stock market will recognize and reward data independence among public companies.
Linux is entrenched in the server world. That provides a huge opportunity to expand into more and larger server niches. It also provides a small contributing stream of desktop users in influential places.
Major market shifts, when limited by ingrained attitudes, are generational. It takes the replacement of one generation by the next for a market to complete such a transition. Even after Linux comes to dominate in new installations, there will naturally be Windows holdouts for many years, in both homes and organizations. This diehard tenacity is not an unexpected sign of strength, but it will be interpreted as such by a certain class of industry analysts for many years.
The IT industry has an inertia that is almost unimaginable to someone who hasn't spent significant time immersed in it. Application systems built on one operating system or architecture are extremely expensive to port to an unrelated OS or architecture. While this effect does slow the uptake of Linux in business, it also prevents a sudden loss of the Linux market share. But, mostly, it masks the rise of Linux so that it is possible for much of the IT industry to simply ignore its growth. I think that this effect of the slow and gradual adoption of Linux is the main support for the ‘Windows has won the desktop’ analysts’ arguments.
Linux is free as in ‘free beer’. Yes, you can buy it -- and many do -- but when you pay money for Linux you are really buying something else: support, non-free components, and convenience, to name a few. The reality, however, is that Linux is as free as you need it to be.
Linux is also open. It can be extended, embedded, and used as needed without restrictive licenses and without fear of vendor lock-in. This characteristic of Linux can only improve Linux’s profile with each business continuity study and proprietary counter example. The significant restrictions of Linux’s license, the GNU General Public License (GPL), establish rules of redistribution, not limitations of use.
Linux is also scalable -- but just what does that mean? Scalability runs in several directions. To say an OS is scalable doesn't simply mean that it scales to very large systems. Rather, scale refers to the entire range from the very small to the very large. It refers not just to the vertical dimension but also to the horizontal, across arrays of clustered systems. On this measure, Linux truly excels. Linux powers an amazing range of systems, from tiny devices to supercomputers. Of the several operating systems that scale to very large systems, Linux seems to be the one destined to own the small end of the size spectrum.
Security may be even more important than scalability to the IT industry. Security concerns are also gaining mind share among home users as identity theft becomes more widespread. SELinux is beginning to be integrated into major Linux distributions -- which will expand the number of security-conscious IT shops that can deploy it. At the same time, Windows has spawned a healthy industry dedicated to screening out viruses and worms.
I believe that Microsoft's practice of neglecting security is one of the biggest reasons for Firefox's phenomenal success, just as it is steadily contributing to Linux’s growth.
Meanwhile, there are a few features that many Linux distributions are still missing out of the box. As each of those areas is addressed, end-user Linux adoption will increase. As this process adds to the size of the Linux installed base, the newly enlarged base will increase the value of solving other such problems, continuing to fuel the positive feedback loop. As Linux reaches ‘critical mass’, almost all of the other arguments against Linux will fall, one by one. For example, when major vendors start offering preconfigured Linux systems to home desktop users, one of the most persistent complaints against Linux, that ‘it is hard to install’, will become irrelevant. As many readers surely realize, Windows is difficult to install as well. The difference is that users generally don't have to install Windows. It comes preinstalled, and with a preconfigured 'restore' CD. The implication of this is that as Linux approaches critical mass, its period of fastest growth may still lie ahead!
Meanwhile, Microsoft's desktop network effect advantage is weakening due to cross platform software packages such as Firefox, OpenOffice, and, for programmers, gcc.
Even some game makers could conceivably abandon Windows by releasing custom Linux LiveCD versions of their games. Granted, there might need to be some embedded graphics support, but this need not be an insurmountable problem since many games only support a limited number of graphics adapters anyway.
Linux has a certain ‘coolness factor’ that appeals disproportionately to young people. Further, Linux is strongest among the technological elite, i.e., those who help and advise others, run websites, write code, and generally set technology trends. This slice of the market is more important to the future than their numbers suggest
Microsoft has, as they say in politics, ‘high negatives’. That is, a substantial percentage of people very much dislike Microsoft. These people will go to considerable efforts to avoid buying or using Microsoft products as alternative products become more visible.
Capitalism, like open source, is relentless and efficiency based. A central planner can never fully predict a market's evolution -- yet capitalism moves in lockstep with it. In much the same way, various Linux distributions will be born and die as desktop evolution relentlessly marches on. Even the current 'Linus' branch of the kernel can and will be replaced (forked) if it doesn't follow the main market closely enough. The ‘planned economy’ of Microsoft is at a disadvantage when facing the evolutionary dynamics of the laissez faire open source bazaar.
Compounding the problem for Microsoft, Linux is poised and ready to pounce upon any new, Windows-incompatible, hardware platform; perhaps IBM’s upcoming cell processor will be the next Linux success story. Linux runs on almost everything and gets quickly ported to new hardware. Linux is agile, Microsoft is not.
Microsoft's biggest remaining asset is probably the vendor lock-in ‘feature’ of Microsoft Office. Of course, that lock-in is also one of the biggest reasons not to use Microsoft Office. As free office suites achieve acceptable levels of command, feature, and file compatibility with MS Office, more and more user’s desktops will become available to Linux. Microsoft will, as always, try to leverage their current lock-in into future lock-in. But with the pace of office software development slowing as the market nears saturation, that is easier said than done. Changing Office to render a competitor incompatible will also hinder older versions of Office, creating more ill will. Also, if a competitor ever does achieve close compatibility with the current version of Office, customers will have the option of jumping to the competitor if Microsoft changes the file formats. With bad timing or a bit of bad luck, such a lock-in maneuver by Microsoft runs the risk of hastening the abandonment of Office.
Microsoft has always shrewdly leveraged their network effect and mind share advantage to maintain themselves and grow. They will continue to use this strength -- but they face many hazards. They must correctly identify the real threats early enough to fight and nullify them. Microsoft can win many battles and still lose the war. They simply can't win all the battles and yet their relentless adversary, Linux, can lose battles indefinitely and still come back to win the war. Unfortunately for Microsoft, ‘Linux’ doesn’t need to make a profit and can’t be put out of business by an upside down balance sheet.
Linux does, however, have one looming vulnerability. Microsoft could possibly kill Linux with some unwitting help from the Linux kernel team or the open source applications development community. Governments, through trademark, copyright, and patent law, wield such power over common business practices that runaway software patents -- like those now being issued in the US -- could kill off commercial Linux use and support in affected countries. For example, heavy participation in a scenario such as this one could lead to a near-death experience for Linux. This scenario, though, is best classified as a government action. Linux has already penetrated so many niches that the chances of Microsoft rooting it out via market mechanisms seem pretty slim.
And, no, Linux isn't yet ready for every desktop that Windows occupies. However, it wasn't long ago that Linux wasn't ready for many server roles either. The server situation has changed drastically just as the desktop situation is now changing. The desktop will change more slowly since it is not transparent to the user, but similar forces are pushing it inexorably forward. Each year new niches are added to the Linux desktop installed base and other, more established, niches grow. With each such increment of desktop growth, another marginal niche becomes viable. A few more years of this growth and the big market niches will gradually go from inaccessible to marginal to viable to dominated. No, Linux can’t yet replace Windows, but time is on Linux’s side.
Meanwhile, if you’re impatient, you can help to speed things up. Help a friend install Firefox or OpenOffice.org. Give a Windows user a Knoppix CD to play with or install a Desktop Linux distribution on their 'old' machine and show them a software repository full of nice, friendly, and free binary applications. If you’re a programmer, find an open source project that interests you and lend a hand.
|mail this link | permapage | score:9041 | -Ray, May 8, 2005 (Updated: May 13, 2005)|
MiniLesson: An introduction to Linux in ten commands
|This tutorial is the first in a series of introductory Linux lessons. This first article will cover navigating around a Linux filesystem along with a brief passage -- with examples -- on using ten of the most essential GNU/Linux commands. |
You should have access to a Linux system in order to perform the example commands as we progress through the tutorial. If you don't have a dedicated Linux box, you can use a Live Linux CD-ROM-based distribution such as Knoppix. Knoppix will let you run Linux directly from the CD without modifying anything on your hard drive.
Once you're logged in to a Linux system, open a terminal session. Each of the commands covered here will be typed directly into a command line terminal window. Under Red Hat Linux, terminal is found in the 'system tools' section of the menu. (Your system may, alternatively, have a terminal program called 'konsole', 'xterm', or 'shell'. Look around your system for a menu with 'tools' or 'utilities' in the name if necessary.)
The first command we will use is 'pwd' -- which stands for 'print working directory'. The pwd command shows you your current position within the Linux filesystem. The position is known as your 'current working directory'. Type pwd now. The example below shows my command prompt and the pwd command followed by the output from the pwd command:
[rayy@barton0 rayy]$ pwdFrom the output (/home/rayy) we can tell that I am in my 'home directory' -- the directory where I keep my personal files and the directory where I always start out in a new session.
The ls command lets you list files. For example, here is the (shortened) output of an ls command on my system:
[rayy@barton0 code]$ lsAlternatively, you can get a 'long listing' that shows file sizes, timestamp, ownership, and permissions as follows:
artdir countdir machine
[rayy@barton0 code]$ ls -lYou can also supply a target directory to the ls command. For example, to view the contents of the /tmp directory, I enter the following:
drwxr-xr-x 2 rayy rayy 4096 Feb 3 2002 artdir
drwxr-xr-x 2 rayy rayy 4096 Feb 3 2002 countdir
drwxr-xr-x 2 rayy rayy 4096 Feb 3 2002 machine
drwxr-xr-x 2 rayy rayy 4096 Feb 3 2002 sortdir
drwxr-xr-x 2 rayy rayy 4096 Feb 3 2002 tsardir
[rayy@barton0 code]$ ls /tmpFor more information on the ls command you can reference the manual page for ls with the following command:
flp kde-rayy mcop-rayy
[rayy@barton0 code]$ man lscd
This next command, 'cd', lets you change your current working directory. for example, you can change your current working directory to /usr/bin by entering the following command:
[rayy@barton0 rayy]$ cd /usr/binNote that after I entered the cd command, my command prompt changed to reflect the change in the last node of my current working directory. Your command prompt may not be configured to do that.
Change your current working directory to /usr/bin now and enter the ls command.
[rayy@barton0 code]$ cd /usr/binThe preceding is a partial listing. There are many, many files in the /usr/bin directory on most Linux systems.
[rayy@barton0 bin]$ ls
If you have a background in Windows or are familiar with DOS, you are used to file extensions that signify the file type. Linux (and Unix) have no such requirement. That is, an executable program can be named anything. Therefore, a handy command is supplied with Linux named 'file'. For example, I have a file named 'sample.c' in my code directory. I can learn a bit about that file by entering the following command:
[rayy@barton0 code]$ file sample.cAlternatively, I can use the '*' wildcard -- which represents all filenames -- to examine all of my code files at once. The following is a shortened example:
sample.c: C++ program text
[rayy@barton0 code]$ file *The file command can be very useful to avoid minor annoyances -- such as when using one of the following three commands.
code.tar: GNU tar archive
genart.c: ASCII C program text
sample.c: C++ program text
xor: ELF 32-bit LSB executable
The cat command is useful for concatenating multiple files -- or just for dumping a single text file to the screen. Before you use the cat command to dump a file to the screen, use the file command to make sure it's some variety of text file such as ascii text, commands/text, C source code, html/text, etc. The following is a shortened example of using file and cat to identify and dump a text file:
[rayy@barton0 code]$ file xor.cmore
xor.c: ASCII C program text
[rayy@barton0 code]$ cat xor.c
unsigned char buff,
The more command is useful when a text file is larger than a single screen. The following is a shortened example of using more to view a large C program:
[rayy@barton0 code]$ more xor.cNote the '--More--(29%)' at the end of the screen. That means that 29% of the file is above that line, implying that another 71% of the file is below. Press the space bar to page through the file, a screenful at a time. Press the b key to back up. If you finish looking before reaching the end of the file, press the q key to quit.
unsigned char buff,
The grep command, short for 'get regular expression and print', is useful for finding occurances of a particular string in a text file. To find the 'printf' statements in the example C program above, enter the following command:
[rayy@barton0 code]$ grep printf xor.cThe grep command has far more capability than I describe here and, as usual, enter
[rayy@barton0 code]$ man grep for more information.
The cp command will let you copy files. Unlike the commands used above, this one includes a hazard; if you copy filename1 to filename2 and filename2 already exists, you will destroy the original filename2 file. Use cp with caution!
To make a duplicate copy of my xor.c file I could enter the following command:
[rayy@barton0 code]$ cp xor.c xor.c.bakNote that the cp command returned no output -- I had to enter an ls command to see the results of the copy. [By adding the * wildcard to the original filename, I asked for a listing of all files that started with xor.c -- including those with no additional characters in the name.]
[rayy@barton0 code]$ ls xor.c*
The rm command is used for removing files. To remove the duplicate file I created in the cp command example, I would enter the following:
[rayy@barton0 code]$ rm xor.c.bakAgain, note the absense of any feedback from the rm command. I had to enter an ls command to verify that the xor.c.bak file had really been removed.
[rayy@barton0 code]$ ls xor.c*
As with other commands, rm can remove multiple files at once when used with wildcards or with the -r (recursive) option. See the man page for more information on rm.
Ok, this is really two commands, but they are complementary. Use the mkdir command to make a new directory and use the rmdir command to remove an empty directory. For example:
[rayy@barton0 tmp]$ mkdir testdirIn the preceding series of commands I first created a new directory named 'testdir'. I then used the ls command to verify its presence. Then, I removed 'testdir' and verified that it was gone by using ls again.
[rayy@barton0 tmp]$ ls
[rayy@barton0 tmp]$ rmdir testdir
[rayy@barton0 tmp]$ ls
For more information on the commands covered in this article, take a look at the general commands man pages over at the LinuxQuestions.org website.
|mail this link | permapage | score:9041 | -Ray, February 19, 2004 (Updated: April 18, 2007)|
Install Liferay 6.0.5, Tomcat on Ubuntu 10.04
| Liferay Portal is an enterprise web platform for building business solutions that deliver immediate results and long-term value. Get the benefits of packaged applications and an enterprise application framework in a single solution. read more...|
|permapage | score:9024 | -falko, September 7, 2010|
Apple to Intel move no threat to Linux
|John C. Dvorak's recent Marketwatch commentary, 'Linux is likely the big loser', is completely off base. His fundamental mistake is to assume that 'the X86 platform' is more appealing than the freedom of Open Source and that the x86 processor is the important consideration for development: |
It's likely that developer interest will wane when Apple is fully engaged on the X86 platform. While Apple ran on the PowerPC chip the amount of developer effort in the Open Source camps was nil. But now that Apple is using the same processor as everyone else, targeting the Macs will now be an easy decision to make. This will be at the expense of Linux.No, the Apple announcement doesn't mean that you'll be able to run OS X on a Dell. In the unlikely event that the Intel-based Macs are insufficiently different from PC's, Apple will build in additional hardware security features. Mac OS X will check for these features and will refuse to run in their absence.
Realistically, Apple will not make generic PC’s nor will the upcoming Intel version of Mac OS X run on non-Apple hardware. The new Apples will be just as proprietary as the PowerPC-based Apple hardware -- and just as distinct from the generic 'PC market'.
Above all, Apple is still a hardware company and a switch to commodity hardware -- or even making their new computers PC compatible -- would be a far more dangerous business risk than simply switching CPU architectures. Apple is not changing their business plan. They are changing their processor architecture and supplier only.
Try as they might, even Microsoft can’t stop Linux. And Apple isn't even trying.
The Apple switch to Intel processors is quite simply irrelevant to Linux.
Meanwhile, Apple's move makes sense from a market perspective. And it's not about clock speed or raw performance as some have suggested -- although those considerations are important. The obvious reason that rules out performance as the overriding consideration is simply that they didn’t choose the AMD Opteron for the Power Mac.
Rather, it appears that this strategic shift is (almost) all about laptops (and perhaps Mac Minis -- which technologically are just battery-less laptops in a new form factor). Laptops are now outselling desktops -- and that trend will increasingly drive hardware makers' profits. And at Apple, that trend may be even more important than in the general PC market. If this were about performance and price/performance at the high end, the partner would be AMD. This move is primarily about power-per-watt at the low end, hence, Intel.
Of course, we mustn't forget that the high-end systems will be migrated last, possibly more than two years from now. That gives Apple plenty of time to add a second partner if Intel's vast resources are unable to rein in AMD on the performance front. And, obviously, a move to AMD at that point would be a small technical task compared to the PowerPC-to-Intel switch.
With some luck and continuing success at the high-end, AMD could still get a major design win out of this transition.
|mail this link | permapage | score:9024 | -Ray, June 9, 2005 (Updated: August 1, 2005)|
Space Tyrant: A threaded C game project: First Code
|First code: This is the first code release of Space Tyrant. This is an early stage of development and, at this point, only implements the listening thread, the two IO threads for each player connection, and a skeletal game logic thread that does little beyond proof-of-concept code.|
The design of the code was discussed in this article so you should probably go back and read that article if this is your first brush with this project.
The first code release -- what we will be discussing in this article -- is online as spacetyrant1.c. Download it as well as the shell script you’ll need to compile it: makeit1.sh. The script should work under both Linux and Mac OS X. The code will require a single line change to compile under Mac OS X. Search the code for the string OSX to find the line to decomment and the corresponding line to comment out.
Currently, the program allows multiple people to connect using telnet and echos anything they type to all other connected sessions. Some familiarity with the C programming language will be assumed in this article and those to follow.
Configuration constants: There are several ‘configuration constants’ defined by #define statements. The key constants and their meanings are:
MAXTH: This number represents the maximum number of users that can connect simultaneously. This constant is used to set limits on loops and to define the number of elements in various arrays. This number must be a power of 2.
MAXTHBITS: This is simply the number of bits necessary to form an unsigned int to index into arrays of MAXTH size. This number is used to declare bit fields for use with various items that occur MAXTH times. In the code we use a MAXTH of 256 and since 2^8 equals 256, MAXTHBITS is set to 8. Note that if you change MAXTH, you must make an appropriate change to MAXTHBITS!
MAXBUF: This is the number of buffers used in various places. For example, the input threads each get MAXBUF numbers of buffers.
MAXBUFBITS: This number matches MAXBUF in that it is the number of bits necessary to express the number MAXBUF in the same way that MAXTHBITS relates to MAXTH.
MAXLINE: This is the maximum length (in bytes) that is allowed for network input and output. The IO buffers, for example, are declared to be size MAXLINE + 1. The ‘+ 1’ is to allow room for a terminating 0.
RADPAD: This is added to MAXLINE to determine the length of a radio buffer. Radio buffers need to be larger than IO buffers since they must allow room for headers.
Data structures: Next, we declare a struct to contain most of the data associated with each thread. Note that this struct contains no player-specific data; it is used only to contain the data necessary to define an input thread and an output thread used to define one user connection. ‘threc’, as we will call the struct, will be an array with MAXTH elements. It will contain the thread ID of both the input and output threads, the timestamp of the last input from the input thread, the number of the socket descriptor, and various flags and indexes that will be used to coordinate the activities of the input, output, and game logic threads. Look at the code comments themselves for details on the variables.
Note that MAXBUFBITS is used to declare the size of inndx, outndx, inptr, and outptr. These variables, when incremented past the number of buffers, wrap back to zero, making it easy to implement ring buffers. That is why the MAXBUF number must be a power of 2.
The thread functions: In this program main() has two primary functions. First, it calls any initialization functions and clears the various data structures and spawns any other permanent threads. Second, it goes into an endless loop of accepting user connections and spawning IO threads to handle the newly connected users.
The next thread function, gameloop(), has the hard job. It constantly loops though the input buffers, looks for input that needs to be processed, and does it. While looping around the buffers, it also looks for input threads that have gone idle and terminates (‘reaps’) them. Currently, the only input processing it does to call a function named broadcast() with any data it finds in the input buffers. The broadcast() function simply copies the input to output buffers. This bit of processing is for proof-of-concept purposes only and will be replaced by actual game logic as it is developed.
The last important thread functions, userin() and userout(), exist in multiple pairs to perform network input and output duties for each connected user. The userin() thread reads the network connection and loads data into the next available input buffer (‘inbuf’). It then timestamps it, and goes back to waiting for more input. The userout() thread loops continously waiting for anything to appear in the next output buffer (‘outbuf’). When new data is placed in an output buffer by the gameloop() thread, userout() writes it to the user’s network socket.
Note that because userout() and gameloop() loop continously, they sleep after each ‘idle’ loop. That is, when they pass through their logic loop and find no actual work to do, they call the usleep() function to sleep a tiny fraction of a second. This sleeping prevents them from consuming unnecessary processor cycles.
[Update, June 25, 2005: 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:9018 | -Ray, March 27, 2005 (Updated: June 25, 2005)|
Alternative operating systems
|The ten best alternative OSes, none of which are from Microsof or Apple, nor are any based on Linux. Operating systems covered are:|
From the article:
- GNU/HURD (RMS' never-quite-done free OS, predates Linux(!))
- JNode (written in Java)
- FreeVMS (DEC's famous VMS)
- DexOS (tiny, console-like GUI)
- Inferno (distributed, device-sharing)
- KolibriOS (MenuetOS fork, tiny, written in Assembly)
- OpenBSD (a BSD variant specializing in security, correctness)
- AROS (Amiga Research Operating System )
- ReactOS (Windows clone)
- Haiku (BeOS clone)
Big companies can grow reticent to change, slow to move and adopt new technologies. Features must be escalated through approval bodies, management and bean-counters. Hobbyist projects don't have those commercial pressures and can experiment freely. read more...
It might seem audacious to claim that the next Windows is cooking in some part-time coder's house, but it's nothing new. Microsoft's OS empire started with the purchase of QDOS, which stood for 'Quick and Dirty Operating System'. Apple didn't create Mac OS X out of thin air, but took an open source kernel and some BSD code (grounded in academia) to get the foundations of its operating system working.
|mail this link | permapage | score:9014 | -Ray, March 16, 2011|
Benchmarks: NFS v3 vs. NFS v4 Performance
|NFS3 vs. NFS4 file operations speed compared...|
NFS version 4, published in April 2003, introduced stateful client-server interaction and "file delegation," which allows a client to gain temporary exclusive access to a file on a server. NFSv4 brings security improvements such as RPCSEC_GSS, the ability to send multiple operations to the server at once, new file attributes, replication, client side caching, and improved file locking. Although there are a number of improvements in NFSv4 over previous versions, this article investigates just one of them -- performance. read more...
|mail this link | permapage | score:9005 | -Ray, June 20, 2008|
Space Tyrant: A multiplayer network game for Linux
|Since the last release of Space Tyrant, it has gained some actual game-like functionality. The new code can be downloaded from st2.c. Download it as well as the shell script you’ll need to compile it: makeit2.sh.|
It’s now possible to connect to the game via telnet and to create an account, log in, and be issued a ship. Once you’re logged in, there is a universe to explore filled with ports for buying and selling goods and planets for scooping free goods. From those trading activities you can earn money, called microbots. Other than trading to earn more money, you only use your microbots to buy fighters -- which you can use to attack other players or the neutral fighters that guard some sectors.
The neutral fighters are only good for parking under while you’re not playing. They afford a little bit of free protection for your ship since no one can attack you until they first destroy the neutral fighters. Note that you can attack other players whether they are logged in or not and any fighters with their ship will automatically try to defend them.
Each player starts out with a specific supply of fuel, called antimatter. Each minute a small amount of additional antimatter is issued by a function called updatefuel(). If you’re not logged in, fuel just accumulates in your ship. This continuous allocation of fuel makes Space Tyrant a type of turn-based game. Unlike traditional turn-based games, however, you can play your fuel all at once or a little at a time and completely independently of how and when other players play.
You can also talk to other players on the radio. There is only one channel so everyone who is logged in hears everything that is said on the radio.
The game isn’t yet playable in any reliable sense, however, because it doesn’t yet back up and reload the data from disk files. The software creates an instance of the game when you run it and it remains running until you stop it or the system goes down. There is also no way to establish a time limit on a game.
That’s pretty much the extent of the functionality changes. Now, on to the code.
First, there is a login function. That function looks in the player database struct and, if the player name doesn’t already exist, it creates an account there. If the name does exist, it prompts for a password, matches it against the stored password, and logs you in if the two match. There is not yet a way to change your password.
Once a player is logged in, he is faced with a sector description and a ‘choice:’ prompt. Any character that the player types at this prompt is immediately acted on as if it were a command. There is a string called ‘commlist’, short for command list, containing the letters and characters that are used as commands. A function pointer array, ‘fp()’, is used to store the locations of the command functions. Another function called ‘commscan()’ looks up the command letter typed and returns an index into the fp() function pointer array. This combination of the commlist string, the commscan function, and the fp function pointer array constitute the command processing loop of the game, as shown below:
These lines are embedded in a loop where each user’s input thread, represented by the variable ‘th’, is examined for new input. The new input arrives in string called inbuf. Since each thread has several buffers, an index called inptr is used to keep track of which one is currently being processed.
And, as described above, commscan is used to extract the appropriate function index and place it in a variable called ‘userndx’. Then, userndx is used to index into the fp function pointer array and the thread index (th) is passed to the appropriate command-processing function.
There’s a small amount of misdirection in that first line but, once understood, it becomes trivial to add additional commands. Basically, you just need to replace the placeholder function, ‘nullrtn’, with your new function name adjacent to the command letter you select in the fp() definition list.
The new functions are discussed below.
In keeping with the evolving game nature of this project, several actual game functions have been added. The first new function, makemap(), builds a 20,000-sector single-galaxy universe and populates it with objects. By changing the GAMESIZE constant, you can build a universe of arbitrary size, but make sure you don’t try to build a universe so big as to consume too much of your system’s memory. I’ve tested universes of up to 1,000,000 sectors, which seem to work just fine. The makemap() function randomly puts ports, planets, fleets of neutral fighters, and nebulas in various sectors throughout the universe, and interconnects the sectors with randomly-generated one-way ‘warps’. Note that planets and ports are randomly given varying productivity's and random initial inventories of our three commodities: Iron, Alcohol, and Hardware.
Note that makemap() builds each sectors array of six warps, sorts them into ascending order, and then looks for duplicate warps. If any duplicates are found, it decrements the loop-controlling variable and simply rebuilds that entire sector from scratch. The sorted warps are a convention that we will maintain throughout the project. Each new galaxy type that we add in the future will adhere to that convention and other functions (and users) will be allowed to assume that warps are in ascending order.
We have added a function to simply list the implemented commands and a short line of description. For now, the function is attached to the command letters ‘?’ and ‘H’ via the function pointer array and the commlist array. This function is mostly useful to illustrate a design limitation. The output of any single sprintf buffer-building function cannot exceed the MAXLINE buffer size constant. This function produces a single buffer out output very near the current 511-byte limit and will soon have to be split to produce two buffers of output. Assuming, of course, that we don’t increase the MAXLINE buffer size.
The ‘J’ command activates the jettison() function. It’s only purpose is to dump any cargo out of your cargo holds. It illustrates the method we use to let a function that requires multiple characters of input -- or simple confirmation -- to temporarily turn off command processing and send the next character of input back to it. Jettison requires confirmation so that you don’t accidentally dump your cargo just by hitting the J key. (Since all commands operate as ‘hot’ keys you do not have to hit the [Enter] key to activate a command -- each command immediately executes as soon as you press a key.)
Each command function has the ability to set the thread’s control variable to it’s own command letter. That way, the command processing loop can simply check ‘control’ pass the next buffer of input directly to whichever function is indicated.
The warprtn and jumprtn functions process requests to move to another sector. warprtn() processes the commands 1, 2, 3, 4, 5, and 6, which represent a user’s request to move to the first through the sixth sector number in the warp list, respectively. jumprtn() processes requests to move to a randomly selected sector in the warp list via the ‘-’ (or ‘=’) key. jumprtn() also implements commands to move to the next larger sector, the next smaller sector, as well as the largest and smallest sector number via the ‘.’, ‘,’, ‘>’, and ‘game design and the programming model. The second article discusses the IO handling code and more of the details of the programming model.]
[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]
[Update, March 21, 2007: Space Tyrant now has a website of its own!. This site is new but growing and will be the quickest way to find new information and code on the Space Tyrant project.]
|mail this link | permapage | score:9001 | -Ray, May 30, 2005 (Updated: March 21, 2007)|
Space Tyrant Index Page: Linux game server development project
|This page links to the various articles that have been published about Space Tyrant, a multithreaded, network socket programming Linux game server project in C.|
Read below for the history and overview or just click these links for the articles:Space Tyrant is a C language Linux game server development project. It started out in February, 2005 as a humble echo server with high ambitions. On March 18, ST had its design and intentions announced to the world.
Today we kick off a new multithreaded, network socket programming project which we will call Space Tyrant. Our mission is to write an open source, multiplayer, networked, strategy game in the C programming language. The goal of this project is to make a solid code base which implements a simple space trading game upon which other games can then be built. The game will be a subset of The Last Resort (TLR) that currently runs at Ioresort.com. This project will be a learning exercise for me as well as for any interested readers. The current state of the source code will be released with each article update.Source code to ST, then just an echo server, was not released.
Then, on March 27, 2005, ST was promoted to a crude chatserver.
This is the first code release of Space Tyrant. This is an early stage of development and, at this point, only implements the listening thread, the two IO threads for each player connection, and a skeletal game logic thread that does little beyond proof-of-concept code.Next, on May 30, 2005, ST started to resemble some sort of incomplete text game.
It’s now possible to connect to the game via telnet and to create an account, log in, and be issued a ship. Once you’re logged in, there is a universe to explore filled with ports for buying and selling goods and planets for scooping free goods. From those trading activities you can earn money, called microbots. Other than trading to earn more money, you only use your microbots to buy fighters -- which you can use to attack other players or the neutral fighters that guard some sectors. As of this release, the source code was placed under the GPL, version 2.
On June 26, 2005, Space Tyrant was released with many shiny new abilities. Players can now deploy fighters to guard sectors, navigate with the aid of an autopilot, rank the various players in the universe, and sleep peacefully knowing their alternate universe is being backed up constantly by a sporty new backup thread. Yes, good times are surely upon us.
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.There is normally a copy of the development version of the server running on my decTOP on port 23. To access it, type (or click, if it works for you) the following command:
(telnet to my ST server)
The current development version of the code is usually at http://librenix.com/st/st.c but the individual articles link to the specific versions discussed in each article.
You can mail me about the project at spacetyrant [at] librenix.com -- or you can just telnet into Space Tyrant, as listed above, and send me a radio message. I'm likely to get that faster. ;)
The Space Tyrant project has a new website, SpaceTyrant.com, where the latest source code is always available. Also, new articles about ST programming and about ST gameplay will be posted there as they come available.
Information on The Last Resort follows. TLR is one of the two games that Space Tyrant is intended to replace someday. Space Tyrant has a long way to go before it replicates TLR's 25,000 lines of C code. So far, it has reused only about 40 lines of TLR code, a handy 'bit-plane' sort dating back to 1998.
TLR Survival Manual
Is this game for you? read more...
|mail this link | permapage | score:8990 | -Ray, June 25, 2005 (Updated: April 26, 2011)|
Linux Games: Angry Birds
|How to install and play Angry Birds on Ubuntu Linux...|
Angry Birds have surely created an amazing buzz in the cyber world. In 2010, there were more than 12 million downloads, and this shows it all. If you work on Linux, and wondering if you can install and play Angry Birds on Ubuntu Linux, then we have got some good news for you. read more...
|permapage | score:8962 | -Ray, April 19, 2011|
Mono-culture and the .NETwork effect
|Consider a future where Microsoft has succeeded in migrating most Windows development to the .NET framework. With the considerable power that Microsoft wields over corporate desktop computing, the success of .NET is easy to foresee.|
Now, imagine for a moment that Mono, following in .NET's footsteps, is also hugely successful. Further, imagine that, in its success, Mono displaces a large portion of traditional Linux software development over the next few years.
I believe that if the above scenario becomes reality it could lead to a disaster for Linux. In such a future, Microsoft would have tremendous leverage over Linux, Linux programmers, and businesses using Linux.
Microsoft can, at a carefully selected time, change key interfaces, sue for patent infringement, and release otherwise standard .NET components that break or obsolete pieces of Mono. They can also use the powers of the DMCA to prevent Mono developers from gaining access to obfuscated components of .NET technology. While hobbyists and Linux-centric companies will be able to withstand such inconveniences (with the possible exception of patent suits, of course), general businesses and organizations will not be able to resist such pressure.
Of course, Microsoft is well aware of how this scenario could unfold and has thought of many more exploitable details than a casual observer such as myself.
Mono, if successful, is a gift from heaven to Microsoft that, when the timing is right, can be used to set Linux deployment back years, or worse, depending on the devastating psychological and economic effects such a maneuver would have on Linux developers and businesses.
For Microsoft, their best strategy to do real damage to Linux is to make it easy for Mono to succeed while carefully laying their traps. They can quietly go about the business of patenting all of the key functions of .NET. Anyone who has followed the trend of software patents must realize that Microsoft could have dozens of patent claims covering .NET before Mono rises to prominence.
Then, Microsoft need only wait. The optimum time to shut down Mono will be after much Linux development has committed to it. By then, Mono technology will have infected many projects. Perhaps worse, it will be easier for Mono programmers to simply switch platforms and become Windows developers rather than learn alternative methods and tools of Linux development. Programmers have to eat and software development houses must pay the bills. In such a scenario, there is not a year to burn while everyone ramps up their skills with new tools and practices.
Meanwhile, businesses will be forced to abandon any Linux packages that are .NET-encumbered. Since a .NET version of each Mono-based program would already exist, it would take only a few such packages to convince a business to migrate off of Linux. The headaches of replacing such packages under Linux need only exceed the alternative headache of simply switching to Windows.
A company with their own custom Mono-based software would have fewer options. Microsoft, however, would likely provide an easy solution; simply move the Mono software to .NET and it will all be legal.
I am not the first person to have thought about this. Several Slashdot users have posted cautionary messages about developers placing their trust in the good intentions of Microsoft. [1, 2, 3, 4, and 5].
Dave Winer also seems to wonder about Microsoft's oddly open behavior:
The first clue should be that Microsoft is not protecting the source of .NET, in fact they're publishing it, with some constraints, but if you want to see how they do it, they say there will be no mysteries and no poison pills. So they're making it not impossible to clone. Why are they being so generous? (A little sarcasm, sorry.)Even Miguel de Icaza1, the founder of the Mono project, acknowledges the compatibility hazards:
If Microsoft decided to make our life really hard in terms of compatibility, it would also hurt its own customers. If it changes the APIs, that affects its customers as well. So I think the APIs will remain fairly stable, and I hope that Microsoft won't go into proprietary protocols or protocols that would make it really hard for us to implement Mono. There's is always the possibility it will do so. Microsoft has some strange patterns in terms of how it competes. I really hope it will "behave like a good citizen," as Steve Ballmer said recently it would.What I've described here is probably a worst-case scenario; in all likelihood Mono will not be so successful as to cause a large problem for Linux if and when Microsoft decides to kill it. However, even in a favorable sequence of events, Microsoft will still hold the power to cause a large amount of open source effort and code to be lost.
1. Miguel rebuts one of my points here.
|mail this link | permapage | score:8950 | -Ray, October 13, 2003 (Updated: October 14, 2003)|
FreeBSD 8.0: First Look
|A look at the newest FreeBSD distribution...|
The ZFS file system is included in FreeBSD 8.0 and from previous experience I've found it to work very well. However, my little server didn't really have the resources to properly experiment with it. For systems with enough RAM and disk to justify its use, I highly recommend taking a look at FreeBSD's ZFS implementation - for the snapshots feature, if nothing else. Being able to restore files without reaching for separate backup media can be a wonderful time saver. read more...
|mail this link | permapage | score:8946 | -Ray, December 8, 2009||
Buy Large Abstract Art Prints
Debian 6, Squid, Kerberos/LDAP authentication, Active Directory integration, Cyfin Reporter
Install Apache2, PHP5, MySQL on CentOS 5.7
Virtual Users/Domains with Postfix/Courier/MySQL/SquirrelMail (Debian 7)
PDNSD HowTo: A DNS Caching Personal Server
webOS: The latest Linux distribution
Run Unity desktop on Linux Mint 12
Tutorial: Run Joomla 1.7 on Nginx on Debian 6, Ubuntu 11.10
Using Multiple PHP Versions (PHP-FPM FastCGI) With ISPConfig 3 (Ubuntu 12.04)
GhostBSD 2.5 review
Set up Ubuntu PV DomU via xen-image-create at Xen 3.3 Ubuntu Dom0 with Novell kernel 2.6.27
Tutorial: Webcam streaming your desktop plus audio with ffmpeg, crtmpserver, Flowplayer
Tutorial: Replace Windows with Pinguy OS 11.10
Linpus Lite 1.9 review
Tutorial: Install Postfix, Courier, MySQL, SquirrelMail on CentOS 6.2
Tutorial: USB-Over-IP server, Client on Ubuntu 10.04
Reviewing Kali Linux - the distro for security geeks
Giada – Audio tool for DJs, live performers and electronic musicians
The Coming HTML 5 Revolution in Linux
Tutorial: Install Lighttpd, PHP5, MySQL on CentOS 6.0
Tutorial: Install Debian 7 (testing) with debootstrap from a Grml live Linux
The Debate OS Project
How to install postgresql 9.2 on Ubuntu 13.04 Server
Python Client/Server Tutorial
Usability, user-friendliness and the Linux desktop
Currency Traders Telnet Game
Fedora 16 KDE review
Arronax: Nautilus Plugin to create and modify Application Launchers
HowTo: HTTP Status: 206 Partial Content and Range Requests Using Curl
Install MySQL 5.6, memcached on Ubuntu 12.10
VPS: Xen vs. OpenVZ
Conky Manager – Simple GUI for managing Conky config files
Pear OS Linux Panther 3 screenshot preview
Stella: RH/CentOS 6.3 based Desktop OS
Tutorial: Dual-boot Linux Mint 13 Cinnamon/MATE and Windows 7
Apple DIY Repair
Install Deepin desktop environment on ubuntu 13.04
CMS: Serendipity 1.0
Pissed Off Penguins: A Free Game Project
Upgrade Fedora 18 to 19 With FedUp
Linux file manager comparison review