Last I checked GNU/RMS were hell-bent on making sure no one ever got "acknowledgement" for anything they ever create, that somehow it's "evil". Hell, the same/. "community" that's freaking out about such lack of acknowledgement now was mad as hell at XFree86 for daring to fight for exactly such acknowledgement.
Aside from the "kewl" factor, rack mount systems for the job described will be very expensive, underpowered, incredibly noisy, and of limited expandability. This is mostly because if you're talking about saving space you pretty much have to be talking about 1U systems, which sacrifice a lot for their form factor (thinness).
What's a better plan?
I'd recommend Shuttle mini-PCs or similar (a few makes are available now). Hugely cheaper then rackmount, much quieter, better expansion (two or three internal hard drives if you don't use floopy or CDROM), and honestly SMALLER then 1U systems. Remember as thin as 1U systems are they are 19" wide (before you add the rack which adds a few more) and are typically very deap (20+ inches often). They are also much heavier then Shuttle systems. Furthermore, so long as you stay away from the mini-ITX based brands (Via, yuck!) they have every wiz-bang feature you could ask from a full size PC (duel channel DDR400, hyperthreading, USB 2.0, Gigabit lan, firewire, etc, etc) built in (see the Shuttle X in particular).
You'll have a much easier time moving three of these small boxes around (get a small carry-on suitcase) then a 4U rack case, and your ears will thank you.
Allegiance uses DirectPlay v6 for networking which sadly means networking issues when clients play behind a NAT. This is because (much like active FTP) the server will need to make a connection back to the client.
If they are using UPnP on their NAT router it should just "work" and an (almost) unlimited number of players can play from behind the router. This is because UPnP dynamically handles the details listed below.
If they don't have UPnP running they must either map the entire set of possible inbound ports (see above) or throw their client completely in the DMZ. Either way only one such client can play per public IP in this manner.
That said, now that we have the source I'm sure one of the first efforts will be reworking the network code to be more NAT-friendly as well as making it easier to port the server to Unix. -Currently our main game servers are actually run on Linux...inside a VMWare instance running Windows 2003 Server. Not exactly optimal, especially since VMWare has issues with multiple VMs on one box and DirectPlay (odd timing issues that make the server unusable).
Note the "source" download also includes all raw media files, including all sound files, image files (bitmaps...), and the WAV file format CD music tracks.
Not a build as such (we just got the source yesterday...much less compiled it).
However, w/o source we've been supporting the game for years now. Head over to Free Allegiance and pick it up from the downloads section.
NOTE: Sadly...just as MS released this source to us, we had some serious hicups in the main lobby servers and auto-update server. They are offline at the moment (no, not/.ed, just bad timing). This means our "backup" server connection method must be used ("Lan" games with a DPlay routing hack one of us made called SOVRoute). But without the auto-updater getting the latest files to match is going to be an issue...
But I'm sure we'll have it figured out soon (day or so). At the very least we'll likely get a current snap-shot update made available for new players until we get the auto-update server back online.
Microsoft Research Games created Allegiance. You are very correct that they have little direct connection with the "entertainment division" (Microsoft Games).
Allegiance was created as a testing ground for new game technologies, in particular DirectPlay. The fact it grew into a commercial product at all is more luck/evolution then design. It's also one of the reasons why it had such bad marketing (say what else you will, MS Games has a fantastic marketing group...which sadly didn't touch Allegiance).
The developer participation and feedback during and after the beta was unlike any I've ever seen before or since in a game beta. A great many player ideas ended up in the game. The devs all played the game often with specially marked call signs so the players all knew who they were. Very open, very easy to talk to. The Allegiance beta has generally been considered by all that were in it to be one if not the most enjoyable and productive game betas ever. Allegiance at the start of the beta wasn't anything remotely close to Allegiance at the end. -For one thing, the game went from one faction (barely) to three during the beta.
Most of the dev team moved on to other parts of MS that weren't game related, but the leads have often expressed how much they appreciated the unusually strong community and were amazed at how much had been done over the years with basically nothing to work with.
No, they aren't. That's exactly the point. Even if MS doesn't know about them, it's still theirs, by the letter and spirit of that clause.
No, they aren't "theirs". They are still yours, to do with as you please, save for allowing MS to do with as they please as well (should they even care). You aren't handing copyright over to MS of your work, only agreeing that MS may use it gratias(sp?) as well. But MS can't restrict your usage of your copyrighted code in other projects or restrict is use by others beyond any limitations you place on it yourself.
They give you 1/2 GB and years of work to do with nearly as you please for free. Should they find something interesting of yours built from this, they get to use that for free. But MS still owns their code and you still own yours, which means both are still free to use their own code in whatever other projects they like completely free of the above agreement.
Basically yes, it's 99.9% of what the GPL does in practice.
But who cares? This isn't meant by anyone, the Allegiance devs at MS or the fan base, as some kind of FSF/GPL/OSS-Zelot "victory". If you love Allegiance and have some ideas to make it better, this greatly helps you do that and for that intention the license is a perfect fit. If you want to profit off the hard work and huge cash outlay MS paid to create this or hijack it as a sword for the OSS movement in general caring little for Allegiance, then quite frankly you can kiss my ass.
Yep, the "FreeZone" and the "AllegianceZone", they had it up at game launch.
Eventually they made the AZ free too...then a bit later dropped the AZ servers so it was only community hosted servers...then a bit later dropped the lobby and we had to create a utility that routed "local lan" DPlay connections to servers out on the internet (SOVRoute). Some time later MS gave the community the Lobby server install and some other toys and we got the FreeZone lobby back up on your own hardware.
Currently, as has been for a couple years, the community owns the Lobby server, the game servers, the auto-update server, etc. This source will help us greatly in restoring the AZ features as well (but of course it will remain free for all).
I'd be amazed if that demo actually still worked...
Allegiance is a multiplayer-only game and requires servers that once were hosted only by MS. The game has changed so drastically since that demo there's no way it would even be able to connect to the modern lobby server. -For starters you'd need to teak your reg just to try as the current lobby and auto-update servers aren't hosted by MS anymore.
The real game is a smaller download then most modern demos anyway, so just pick it up from http://www.FreeAllegiance.org/ and get your flight suit on!:-)
For any commercial software company to do this much is amazing, doubly so for a game company, and a hundred fold over for MS to do it. So this doesn't help you make a million bucks with "your" brand new video game or further the agenda of the misnamed FSF. So what? This release does exactly what it was intended to do and it does it extremely well: It allows those of us who love the game and have been workinghardtoimprove it for years a huge new arsenal with which to go about said improvements.
If you want to make a brand new space sim free to the public, go right ahead; it lets you do that too.
But really, boo-*&^$!ing-hoo that perhaps you can't throw yet another app into a KitchenSink(tm) Linux install. Who cares? FreeBSD solved such simple issues very cleanly nearly a decade ago now with the ports system, why can't Linux?
Allegiance came from MS Research Games, not MS Games, and infact was built to be a testing ground for Direct* pieces at the time (in particular DirectPlay was completely forged in Allegance). The fact it turned into a commercial game at all was a bit of happenstance, not original intention.
So yes, it's heavily Direct biased, likely including "beta" versions of some DirectX pieces that won't map directly to any real DirectX release. If this makes it harder to port (unknown/never published DirectX features) or easier (above are in the Allegiance code and thus come with it), we don't know yet.
We (fan community) run our own Lobby (MS gave us the Lobby server a couple years ago) and our own servers. No pay-to-play anymore. Come back and enjoy!:-)
Slippery slope and all that, yah, yah, yah...whatever.
So all the good games are moved off to a single, special location in the store and high enough so that my 31 year old back doesn't have to bend over constantly like at Fry's. Yay!
As a fan of the goriest, most depraved, most offensive games made, I would view such a change as only a good thing. I'm already hard-pressed to pickup a box that doesn't have a "mature" label on the package much like many movie goers quickly dismiss any film w/o an R rating. I'd love it if all the Mature games were all in one spot, away from the unwashed masses of "Dear Hunter" and "Poker" games.
The cvs command has two options sets, the first for cvs (like -q for quiet) and the rest per command (checkout, log, etc). Yes, the space thing is a quirk that shouldn't be, but the -H listings reliably show which it should be for a particular command.
Re:And still no Java (key technical leader quit)
on
FreeBSD 5.1 Released
·
· Score: 1
Much of 1.3.1 was mine from the days when I was at BSDi,
Many thanks; every little bit helps.
Basically, the FreeBSD Foundation paid another lower level engineer to do work that was pretty much in my technical domain without consultation with me asking if this was ok or not, etc..
I'm not upto date on the particulars, but perhaps the fact that Java on FreeBSD was happening so slowly that it might as well not have been happening at all have something to do with it? Personally I love FreeBSD, but since most all my work switched from Perl based to Java based I could no longer advocate my beloved OS. Sure, Java kinda, sorta, maybe was available on FreeBSD...enough that I coded on a FreeBSD work station...but nothing close to something anyone could resonablly present to a client as a "good idea to run this project on FreeBSD". No way in hell, period, when Sparc hardware was/is so cheap and actually supported today.
By doing this, they undermined my status within the group, pissed me off and effectively took over the entire FreeBSD Java effort without crediting me for my work over the last 2 years that stemmed originally from my BSDi day as a JVM internals engineer.
Java on FreeBSD was going no where, fast. Maybe they, like myself and pretty much every FreeBSD user that longed for Java to be supported well enough on FreeBSD to use it for professional work, just got sick and tired of the snails pace that Java on FreeBSD was going. Maybe they thought FreeBSD, effectively having been a non-player in the Java world from the get-go, needed to try a different tactic, some freash blood, because obviously whatever had been happening wasn't good enough by miles.
Seriously... For a modern IT setting Java is very often a primary focus for new development of server apps. FreeBSD will simply get left in the dust as a "Serious Server OS" if it doesn't have rock solid Java support upto and including the latest versions available for Linux/Solaris/Windows.
You can't just be getting 1.3 to laughably be called "production ready" when 1.4 is production ready everywhere else... Hell, I'm not even sure what's available for Java on FreeBSD these days because I gave up watching the grass not grow. I know a great many that are pretty much in the same boat.
You couldn't hack it for whatever reasons, so they went looking for someone who maybe could. Boo-who they didn't coddle you more before looking.
Another, similar option but which removes the problems of high-use NFS links, is to use one "build/test" machine and use it to target installs via NFS to the/usr/local of your "client" machines.
If you have a huge number of machines to update, it's pretty simple to script such port upgrades either using "make install LOCALBASE=/mnt/nfs_other_usr_local", or pkg_add, or rsync. Portupgrade might likely have some tricks as well, haven't tried it myself yet. The point is, there are a dozen ways to handle mass-installs/upgrades cleanly and reliably. I would not however, recommend live network (NFS or whatever)/usr/local for a large install base for any OS, be it FreeBSD, Linux, Solaris, Windows, whatever. Diskspace is a hell of a lot cheaper/faster then running a fast enough network to deal with a single app install network mount not to mention the lovely "single point of failure" issues also associated.
Don't much care for that either, but at least there is a reason I can follow: what version of perl with which options do you want? There are a lot of 'em...
Well, the real reasons were other then this for most really. Almost no one needs non-default perl build options (I was one of those that did, but I'm a "freak" as described by my friends). Perl has a very clean dynamic loader system as well as sane package versioning. In contrast, Java has no package versioning whatsoever and AFAIK no plans to add it, sadly. I'm thinking of something at least equal to Perl's:
use My::Class 2.3; # Compile time error if My::Class isn't version 2.3 or better.
Ditto: use 5.006; # I need Perl v5.006 or better
Simple, but highly effective. In the Java world to maintain any sanity I must keep a copy of each 3rd party package jar per application, even if they are all "identical". Nevermind the Java world rarely even puts version numbers in their.jar file names.
But there are only a few Java's(tm) that are worth mentioning: 1.1, 1.2.x, 1.3.x, 1.4.x. I'm willing to pass on 1.1. And I'm willing to ask for the latest and greatest by default.
Java tends to have pretty serious issues wrt jre/lib versioning (worse still that the Java world collectively doesn't give a damn). I could rant for ages about the broken "deprecation" design and such, but in short if you are running anything critical (basically, anything) on Java you'd do yourself a huge favor and install a JRE per-application as well as any/all 3rd party packages, completely ignoring whatever may or may not be installed in the base system. I say this from the perspective of a professional SCM; Java has one of the most unstable and problematic runtimes ever created. I personally wouldn't really care if Java was in the "base" system or not. Most of what I manage is on Solaris as it is now and we ignore/bin/java completely as well for our WebLogic servers. It wouldn't be any different on FreeBSD. At least with Perl on FreeBSD the only reason I ever built my own was to enable debugging options; All apps could reliably be said to run on the base install.
Maybe one day Java code will be able to do:
import java 1.4.1.03;// Must be Java 1.4.1 / 03 or better import com.whatever.* 3.4; import com.something.Barney 2.9;
Ports worked out well until they broke during an upgrade.
Install/usr/ports/sysutils/portupgrade, it makes managing ports much easier/cleaner/more reliable. Pretty much impossible to screw up installs using it, and even if you screw up installs when not using it (don't upgrade depends and sibling ports of those depends), portupgrade can fix them. The learning curve is pretty much nill as well. AFAIK it's only not part of the "base" system because it, like cvsup and other "must have" utilites, is written in Yet Another Funky Language that would also need to be added to the base.
Switching terminals was just plain wierd,
Er, virtual terminals? Alt-F#, just like Linux AFAIK? From XFree86 it's the same Ctrl-Alt-F# as Linux as well.
coming from the more logical Linux perspective, and I only had four of them (five with X-Windows when I could get it running.)
So you're bitching that FreeBSD has more enabled by default then Linux? (FreeBSD IIRC has 8 by default). Is this even an argument? Comment ones you don't want out of/etc/ttys if you really care that much (maybe the same for Linux, but honestly one of my major Linux complaints is that I can't ever find a "basic" Unix config where it's "expected" and it's likely different per distro anyway).
I suspect I would have had a better time of it if I had gone scavenger hunting for that magical bit of hardware that wasn't too old or too new to work, but in the end I figured screw it -- just about any distribution of Linux seemed to install properly and run efficiently, so why torture myself?
Hmm...if anything, FreeBSD tends to be leaps and bounds more compatiable on older hardware then Linux. "Bleeding edge" and "junk" hardware is another story, however. The FreeBSD world historically hasn't wasted too many brain cycles on making Joe's Fly By Night $5 eModem play nice, as it's mostly targeted at "power users" (server and workstation) that don't buy hardware based on what's available this week from Fry's for FREE (w/mail in rebate).
That said, FreeBSD's hardware support is within a percentage point or two of Linux (sometimes sooner, such as FreeBSD getting USB support ages before Linux did), and what is supported is often supported better.
So basically I've been running with Gentoo for the last couple of years. Has FreeBSD gotten any friendlier lately?
Depends. For a Unix system, FreeBSD has pretty much always been "friendlier" then most/all Linux distros. For a Windows desktop conversion/political statement system, stick to Linux. FreeBSD has Wine support and such, but it's really more of an afterthought and so far as politics go...M$ tends to like FreeBSD (witness Mono on FreeBSD).
In the end it's really a question of being an "anti" person or a "pro" person.
Linux: Anti-Microsoft FreeBSD: Pro-Unix
Personally I want/need a Better Unix and I've got no problems keeping a Win2k box on tap to play games, deal with.doc files, run my AIW-TiVo, etc. If someone finds a way to make EQ, PlanetSide, Unreal II, etc run on FreeBSD that's great for someone, but myself and the vast majority of FreeBSD users won't really care; We'll still use our Windows boxes. In the Linux community however, it often seems like if the lastest game or whatever doesn't have Linux support (at the Windows level or better to boot), then it's some kind of personal afront to the entire Linux world.
Seriously, whatever. If/when I ever publish desktop software (games, whatever) it's highly unlikely I'll ever bother with a FreeBSD version, much less a Linux version. If I'd publish for a non-Windows system it would be OS X ages before Linux...and I don't even own an OS X system.
Not that I'm against Java, but if you want Java included "out of the box" I'm afraid you understand neither FreeBSD's design or the fundamental issues of working with Java (on any platform).
Arguably Perl has a stronger basis for being in the base system, and even it was been taken out now.
Oh yah...and a couple months ago Ricochet bankruptcy creditors were also trying to get me to pay my "last bill". So now both Ricochet and Wellsfargo want me to independantly pay both of them hudreds of dollars for services never rendered.
Ricochet had it right when they started, then simply screwed it up over and over again as time passed.
$29.95/month + I think $5 or $10 for modem rental, total about $40/month. Reasonable, if only 28.8.
Oh, now you have to buy the modem for $300 upfront, well shit that's a high but it's a 1 time charge. This is the deal when I signed up. I loved my Ricochet access, most often working a 1/2 day at the coffee shop near the train, eat lunch, take train in to the office for the other 1/2. Some of my most productive coding was in that coffee shop. 28.8 was more then resonable for email and "work related" web surfing, and in a way it was a plus because it kept me from even trying to play games over it.
Ricochet was great, the network was expanding, they had a huge deal cut with MCI/Worldcom (yah, but at the time this sounded good) to expand the network and upgrade it. When I signed up they promised speeds of 128k for the next modem versions (with "substantial" rebate for current modems) or 64k with existing modems.
The new 128k service rolls out, for like $80/month. They never mentioned a more then double price hike for the new service when they signed me up... Oh yah, and if I want anything more then 28.8 I'll need to upgrade, my $300 less then a year old modem that was going to 64k on the new network now wasn't. We'll give you a $100 rebate off a new $300-500 modem for having the eariler one, but we'll still charge you $80/month to use it.
"Thankfully" I still had my modem, speed, and price that I liked (28.8 was fine at $30/month). But no new such modems or accounts were offered. If anyone new wanted Ricochet, they needed to shell out huge cash for the 128k "service" which still had much less coverage then the 28.8.
They were bankrupt within a year.
Just as they went bankrupt (same month) they decide to "renew" my annual subscription for another $300 charge to my Wellsfargo credit card. Never mind that A) the service didn't exist anymore, B) I had canceled it, and C) that credit card account itself had been CANCELED over a YEAR previous. Wellsfargo still let them put a charge on it without question. They said I could "clearly dispute it and it would be no problem", but later said I had to first personally try to resolve it with the vender....What, the now dead company with no active phone or employees? Explaining this, did nothing. I finally gave up and decided if they want "their" cash they will have to pry it from my cold, dead fingers.
To this day I still get a creditor of the month trying to get me to pay that now $500 "dept" that Wellsfargo allowed to be placed by a bankrupt company onto a credit card acount that had been canceled for over a year.
Fuck Ricochet and Fuck Wellsfargo. Long live WiFi!!!!
Exactly. With the exception of really old music, no two record companies ever sell the exact same album and most all have exclusive deals to everything a group produces (for a set number of albums or such, but effectively years). There is no competition in art.
What's needed is some system where the laws of the open market can be applied to an artform. One method might be to (drastically) reapply the first performance rules to apply simiarly to the actual publication of albums. The idea might go something like this:
Original production company gets exclusive first pressing rights for one year from start of publication.
After one year, any other pressing company can press and sell the exact same recording (minus box art and such, but titles are the same).
These second run pressing companies pay resonable and fixed royalties to both the musician and the production company of $1 per album each (if track list is sold unchanged) or $.25/song otherwise (to each, not split).
Online pressing rights are identical to second run pressing of real CDs with reguard to these rules.
The above idea is also very similar to the Brand Name/Generic Name drug markets (albeit with much shorter timelines, for obvious reasons). Record companies could still make their money hand over fist for new albums as they do now, AND not only cover the cost of bust albums with the high price of star albums, but they could use each other's older catalogs in open market form to help offset those costs as well. -And of course, if some other pressing company sells one of your albums, you get royalties as well, so your bust albums could even help offset your bust albums if/when someone else manages to sell them better then you. Furthermore it would open up a new business of the pressing company (which again could likely be an online only store, like Apple is doing, but without needing to cut deals with everyone under the sun, allowing startups to compete in a big player world).
Honestly I just pulled this idea out of my ass, but the more I reread my own idea the more I like it. Anyone see any major flaws in this thinking?
Slashdot Mirror
What "proper acknowledgements" would those be?
/. "community" that's freaking out about such lack of acknowledgement now was mad as hell at XFree86 for daring to fight for exactly such acknowledgement.
Last I checked GNU/RMS were hell-bent on making sure no one ever got "acknowledgement" for anything they ever create, that somehow it's "evil". Hell, the same
GNU/Hypocrites
Aside from the "kewl" factor, rack mount systems for the job described will be very expensive, underpowered, incredibly noisy, and of limited expandability. This is mostly because if you're talking about saving space you pretty much have to be talking about 1U systems, which sacrifice a lot for their form factor (thinness).
What's a better plan?
I'd recommend Shuttle mini-PCs or similar (a few makes are available now). Hugely cheaper then rackmount, much quieter, better expansion (two or three internal hard drives if you don't use floopy or CDROM), and honestly SMALLER then 1U systems. Remember as thin as 1U systems are they are 19" wide (before you add the rack which adds a few more) and are typically very deap (20+ inches often). They are also much heavier then Shuttle systems. Furthermore, so long as you stay away from the mini-ITX based brands (Via, yuck!) they have every wiz-bang feature you could ask from a full size PC (duel channel DDR400, hyperthreading, USB 2.0, Gigabit lan, firewire, etc, etc) built in (see the Shuttle X in particular).
You'll have a much easier time moving three of these small boxes around (get a small carry-on suitcase) then a 4U rack case, and your ears will thank you.
Al Frankens is the middle ground, that's what's scary...
Allegiance uses DirectPlay v6 for networking which sadly means networking issues when clients play behind a NAT. This is because (much like active FTP) the server will need to make a connection back to the client.
DirectX: Ports Required to Play on a Network
Allegiance Error Message: Your Connection to the Game Server Was Lost
Allegiance Error Message: Failed to Connect to the Lobby
If they are using UPnP on their NAT router it should just "work" and an (almost) unlimited number of players can play from behind the router. This is because UPnP dynamically handles the details listed below.
If they don't have UPnP running they must either map the entire set of possible inbound ports (see above) or throw their client completely in the DMZ. Either way only one such client can play per public IP in this manner.
That said, now that we have the source I'm sure one of the first efforts will be reworking the network code to be more NAT-friendly as well as making it easier to port the server to Unix. -Currently our main game servers are actually run on Linux...inside a VMWare instance running Windows 2003 Server. Not exactly optimal, especially since VMWare has issues with multiple VMs on one box and DirectPlay (odd timing issues that make the server unusable).
Note the "source" download also includes all raw media files, including all sound files, image files (bitmaps...), and the WAV file format CD music tracks.
95% of the source zip is media...
Not a build as such (we just got the source yesterday...much less compiled it).
/.ed, just bad timing). This means our "backup" server connection method must be used ("Lan" games with a DPlay routing hack one of us made called SOVRoute). But without the auto-updater getting the latest files to match is going to be an issue...
However, w/o source we've been supporting the game for years now. Head over to Free Allegiance and pick it up from the downloads section.
NOTE: Sadly...just as MS released this source to us, we had some serious hicups in the main lobby servers and auto-update server. They are offline at the moment (no, not
But I'm sure we'll have it figured out soon (day or so). At the very least we'll likely get a current snap-shot update made available for new players until we get the auto-update server back online.
Microsoft Research Games created Allegiance. You are very correct that they have little direct connection with the "entertainment division" (Microsoft Games).
Allegiance was created as a testing ground for new game technologies, in particular DirectPlay. The fact it grew into a commercial product at all is more luck/evolution then design. It's also one of the reasons why it had such bad marketing (say what else you will, MS Games has a fantastic marketing group...which sadly didn't touch Allegiance).
The developer participation and feedback during and after the beta was unlike any I've ever seen before or since in a game beta. A great many player ideas ended up in the game. The devs all played the game often with specially marked call signs so the players all knew who they were. Very open, very easy to talk to. The Allegiance beta has generally been considered by all that were in it to be one if not the most enjoyable and productive game betas ever. Allegiance at the start of the beta wasn't anything remotely close to Allegiance at the end. -For one thing, the game went from one faction (barely) to three during the beta.
Most of the dev team moved on to other parts of MS that weren't game related, but the leads have often expressed how much they appreciated the unusually strong community and were amazed at how much had been done over the years with basically nothing to work with.
No, they aren't. That's exactly the point. Even if MS doesn't know about them, it's still theirs, by the letter and spirit of that clause.
No, they aren't "theirs". They are still yours, to do with as you please, save for allowing MS to do with as they please as well (should they even care). You aren't handing copyright over to MS of your work, only agreeing that MS may use it gratias(sp?) as well. But MS can't restrict your usage of your copyrighted code in other projects or restrict is use by others beyond any limitations you place on it yourself.
They give you 1/2 GB and years of work to do with nearly as you please for free. Should they find something interesting of yours built from this, they get to use that for free. But MS still owns their code and you still own yours, which means both are still free to use their own code in whatever other projects they like completely free of the above agreement.
Basically yes, it's 99.9% of what the GPL does in practice.
But who cares? This isn't meant by anyone, the Allegiance devs at MS or the fan base, as some kind of FSF/GPL/OSS-Zelot "victory". If you love Allegiance and have some ideas to make it better, this greatly helps you do that and for that intention the license is a perfect fit. If you want to profit off the hard work and huge cash outlay MS paid to create this or hijack it as a sword for the OSS movement in general caring little for Allegiance, then quite frankly you can kiss my ass.
Yep, the "FreeZone" and the "AllegianceZone", they had it up at game launch.
Eventually they made the AZ free too...then a bit later dropped the AZ servers so it was only community hosted servers...then a bit later dropped the lobby and we had to create a utility that routed "local lan" DPlay connections to servers out on the internet (SOVRoute). Some time later MS gave the community the Lobby server install and some other toys and we got the FreeZone lobby back up on your own hardware.
Currently, as has been for a couple years, the community owns the Lobby server, the game servers, the auto-update server, etc. This source will help us greatly in restoring the AZ features as well (but of course it will remain free for all).
I'd be amazed if that demo actually still worked...
:-)
Allegiance is a multiplayer-only game and requires servers that once were hosted only by MS. The game has changed so drastically since that demo there's no way it would even be able to connect to the modern lobby server. -For starters you'd need to teak your reg just to try as the current lobby and auto-update servers aren't hosted by MS anymore.
The real game is a smaller download then most modern demos anyway, so just pick it up from http://www.FreeAllegiance.org/ and get your flight suit on!
*yawn*, whatever
For any commercial software company to do this much is amazing, doubly so for a game company, and a hundred fold over for MS to do it. So this doesn't help you make a million bucks with "your" brand new video game or further the agenda of the misnamed FSF. So what? This release does exactly what it was intended to do and it does it extremely well: It allows those of us who love the game and have been working hard to improve it for years a huge new arsenal with which to go about said improvements.
If you want to make a brand new space sim free to the public, go right ahead; it lets you do that too.
But really, boo-*&^$!ing-hoo that perhaps you can't throw yet another app into a KitchenSink(tm) Linux install. Who cares? FreeBSD solved such simple issues very cleanly nearly a decade ago now with the ports system, why can't Linux?
Allegiance came from MS Research Games, not MS Games, and infact was built to be a testing ground for Direct* pieces at the time (in particular DirectPlay was completely forged in Allegance). The fact it turned into a commercial game at all was a bit of happenstance, not original intention.
So yes, it's heavily Direct biased, likely including "beta" versions of some DirectX pieces that won't map directly to any real DirectX release. If this makes it harder to port (unknown/never published DirectX features) or easier (above are in the Allegiance code and thus come with it), we don't know yet.
http://www.freeallegiance.org/
:-)
We (fan community) run our own Lobby (MS gave us the Lobby server a couple years ago) and our own servers. No pay-to-play anymore. Come back and enjoy!
Slippery slope and all that, yah, yah, yah...whatever.
So all the good games are moved off to a single, special location in the store and high enough so that my 31 year old back doesn't have to bend over constantly like at Fry's. Yay!
As a fan of the goriest, most depraved, most offensive games made, I would view such a change as only a good thing. I'm already hard-pressed to pickup a box that doesn't have a "mature" label on the package much like many movie goers quickly dismiss any film w/o an R rating. I'd love it if all the Mature games were all in one spot, away from the unwashed masses of "Dear Hunter" and "Poker" games.
How could this be a bad thing?
cvs -H checkout
cvs -H log
cvs -H
The cvs command has two options sets, the first for cvs (like -q for quiet) and the rest per command (checkout, log, etc). Yes, the space thing is a quirk that shouldn't be, but the -H listings reliably show which it should be for a particular command.
Much of 1.3.1 was mine from the days when I was at BSDi,
Many thanks; every little bit helps.
Basically, the FreeBSD Foundation paid another lower level engineer to do work that was pretty much in my technical domain without consultation with me asking if this was ok or not, etc..
I'm not upto date on the particulars, but perhaps the fact that Java on FreeBSD was happening so slowly that it might as well not have been happening at all have something to do with it? Personally I love FreeBSD, but since most all my work switched from Perl based to Java based I could no longer advocate my beloved OS. Sure, Java kinda, sorta, maybe was available on FreeBSD...enough that I coded on a FreeBSD work station...but nothing close to something anyone could resonablly present to a client as a "good idea to run this project on FreeBSD". No way in hell, period, when Sparc hardware was/is so cheap and actually supported today.
By doing this, they undermined my status within the group, pissed me off and effectively took over the entire FreeBSD Java effort without crediting me for my work over the last 2 years that stemmed originally from my BSDi day as a JVM internals engineer.
Java on FreeBSD was going no where, fast. Maybe they, like myself and pretty much every FreeBSD user that longed for Java to be supported well enough on FreeBSD to use it for professional work, just got sick and tired of the snails pace that Java on FreeBSD was going. Maybe they thought FreeBSD, effectively having been a non-player in the Java world from the get-go, needed to try a different tactic, some freash blood, because obviously whatever had been happening wasn't good enough by miles.
Seriously... For a modern IT setting Java is very often a primary focus for new development of server apps. FreeBSD will simply get left in the dust as a "Serious Server OS" if it doesn't have rock solid Java support upto and including the latest versions available for Linux/Solaris/Windows.
You can't just be getting 1.3 to laughably be called "production ready" when 1.4 is production ready everywhere else... Hell, I'm not even sure what's available for Java on FreeBSD these days because I gave up watching the grass not grow. I know a great many that are pretty much in the same boat.
You couldn't hack it for whatever reasons, so they went looking for someone who maybe could. Boo-who they didn't coddle you more before looking.
Moderation 0
/. community. :-)
50% Informative
50% Troll
Got to love the
Another, similar option but which removes the problems of high-use NFS links, is to use one "build/test" machine and use it to target installs via NFS to the /usr/local of your "client" machines.
/usr/local for a large install base for any OS, be it FreeBSD, Linux, Solaris, Windows, whatever. Diskspace is a hell of a lot cheaper/faster then running a fast enough network to deal with a single app install network mount not to mention the lovely "single point of failure" issues also associated.
If you have a huge number of machines to update, it's pretty simple to script such port upgrades either using "make install LOCALBASE=/mnt/nfs_other_usr_local", or pkg_add, or rsync. Portupgrade might likely have some tricks as well, haven't tried it myself yet. The point is, there are a dozen ways to handle mass-installs/upgrades cleanly and reliably. I would not however, recommend live network (NFS or whatever)
Don't much care for that either, but at least there is a reason I can follow: what version of perl with which options do you want? There are a lot of 'em...
.jar file names.
/bin/java completely as well for our WebLogic servers. It wouldn't be any different on FreeBSD. At least with Perl on FreeBSD the only reason I ever built my own was to enable debugging options; All apps could reliably be said to run on the base install.
// Must be Java 1.4.1 / 03 or better
Well, the real reasons were other then this for most really. Almost no one needs non-default perl build options (I was one of those that did, but I'm a "freak" as described by my friends). Perl has a very clean dynamic loader system as well as sane package versioning. In contrast, Java has no package versioning whatsoever and AFAIK no plans to add it, sadly. I'm thinking of something at least equal to Perl's:
use My::Class 2.3; # Compile time error if My::Class isn't version 2.3 or better.
Ditto:
use 5.006; # I need Perl v5.006 or better
Simple, but highly effective. In the Java world to maintain any sanity I must keep a copy of each 3rd party package jar per application, even if they are all "identical". Nevermind the Java world rarely even puts version numbers in their
But there are only a few Java's(tm) that are worth mentioning: 1.1, 1.2.x, 1.3.x, 1.4.x. I'm willing to pass on 1.1. And I'm willing to ask for the latest and greatest by default.
Java tends to have pretty serious issues wrt jre/lib versioning (worse still that the Java world collectively doesn't give a damn). I could rant for ages about the broken "deprecation" design and such, but in short if you are running anything critical (basically, anything) on Java you'd do yourself a huge favor and install a JRE per-application as well as any/all 3rd party packages, completely ignoring whatever may or may not be installed in the base system. I say this from the perspective of a professional SCM; Java has one of the most unstable and problematic runtimes ever created. I personally wouldn't really care if Java was in the "base" system or not. Most of what I manage is on Solaris as it is now and we ignore
Maybe one day Java code will be able to do:
import java 1.4.1.03;
import com.whatever.* 3.4;
import com.something.Barney 2.9;
But I'm not going to hold my breath.
The funniest part of reading good jokes on /. is that there will always be somebody that just doesn't get it. Very amusing.
:-)
:)
Yep.
But there are times when a good in-joke can humor the clueful, and shake out the humor impaired.
-- Randal Schwartz
Ports worked out well until they broke during an upgrade.
/usr/ports/sysutils/portupgrade, it makes managing ports much easier/cleaner/more reliable. Pretty much impossible to screw up installs using it, and even if you screw up installs when not using it (don't upgrade depends and sibling ports of those depends), portupgrade can fix them. The learning curve is pretty much nill as well. AFAIK it's only not part of the "base" system because it, like cvsup and other "must have" utilites, is written in Yet Another Funky Language that would also need to be added to the base.
/etc/ttys if you really care that much (maybe the same for Linux, but honestly one of my major Linux complaints is that I can't ever find a "basic" Unix config where it's "expected" and it's likely different per distro anyway).
.doc files, run my AIW-TiVo, etc. If someone finds a way to make EQ, PlanetSide, Unreal II, etc run on FreeBSD that's great for someone, but myself and the vast majority of FreeBSD users won't really care; We'll still use our Windows boxes. In the Linux community however, it often seems like if the lastest game or whatever doesn't have Linux support (at the Windows level or better to boot), then it's some kind of personal afront to the entire Linux world.
Install
Switching terminals was just plain wierd,
Er, virtual terminals? Alt-F#, just like Linux AFAIK? From XFree86 it's the same Ctrl-Alt-F# as Linux as well.
coming from the more logical Linux perspective, and I only had four of them (five with X-Windows when I could get it running.)
So you're bitching that FreeBSD has more enabled by default then Linux? (FreeBSD IIRC has 8 by default). Is this even an argument? Comment ones you don't want out of
I suspect I would have had a better time of it if I had gone scavenger hunting for that magical bit of hardware that wasn't too old or too new to work, but in the end I figured screw it -- just about any distribution of Linux seemed to install properly and run efficiently, so why torture myself?
Hmm...if anything, FreeBSD tends to be leaps and bounds more compatiable on older hardware then Linux. "Bleeding edge" and "junk" hardware is another story, however. The FreeBSD world historically hasn't wasted too many brain cycles on making Joe's Fly By Night $5 eModem play nice, as it's mostly targeted at "power users" (server and workstation) that don't buy hardware based on what's available this week from Fry's for FREE (w/mail in rebate).
That said, FreeBSD's hardware support is within a percentage point or two of Linux (sometimes sooner, such as FreeBSD getting USB support ages before Linux did), and what is supported is often supported better.
So basically I've been running with Gentoo for the last couple of years. Has FreeBSD gotten any friendlier lately?
Depends. For a Unix system, FreeBSD has pretty much always been "friendlier" then most/all Linux distros. For a Windows desktop conversion/political statement system, stick to Linux. FreeBSD has Wine support and such, but it's really more of an afterthought and so far as politics go...M$ tends to like FreeBSD (witness Mono on FreeBSD).
In the end it's really a question of being an "anti" person or a "pro" person.
Linux: Anti-Microsoft
FreeBSD: Pro-Unix
Personally I want/need a Better Unix and I've got no problems keeping a Win2k box on tap to play games, deal with
Seriously, whatever. If/when I ever publish desktop software (games, whatever) it's highly unlikely I'll ever bother with a FreeBSD version, much less a Linux version. If I'd publish for a non-Windows system it would be OS X ages before Linux...and I don't even own an OS X system.
Not that I'm against Java, but if you want Java included "out of the box" I'm afraid you understand neither FreeBSD's design or the fundamental issues of working with Java (on any platform).
Arguably Perl has a stronger basis for being in the base system, and even it was been taken out now.
Oh yah...and a couple months ago Ricochet bankruptcy creditors were also trying to get me to pay my "last bill". So now both Ricochet and Wellsfargo want me to independantly pay both of them hudreds of dollars for services never rendered.
Again, long live WiFi!
Ricochet had it right when they started, then simply screwed it up over and over again as time passed.
...What, the now dead company with no active phone or employees? Explaining this, did nothing. I finally gave up and decided if they want "their" cash they will have to pry it from my cold, dead fingers.
$29.95/month + I think $5 or $10 for modem rental, total about $40/month. Reasonable, if only 28.8.
Oh, now you have to buy the modem for $300 upfront, well shit that's a high but it's a 1 time charge. This is the deal when I signed up. I loved my Ricochet access, most often working a 1/2 day at the coffee shop near the train, eat lunch, take train in to the office for the other 1/2. Some of my most productive coding was in that coffee shop. 28.8 was more then resonable for email and "work related" web surfing, and in a way it was a plus because it kept me from even trying to play games over it.
Ricochet was great, the network was expanding, they had a huge deal cut with MCI/Worldcom (yah, but at the time this sounded good) to expand the network and upgrade it. When I signed up they promised speeds of 128k for the next modem versions (with "substantial" rebate for current modems) or 64k with existing modems.
The new 128k service rolls out, for like $80/month. They never mentioned a more then double price hike for the new service when they signed me up... Oh yah, and if I want anything more then 28.8 I'll need to upgrade, my $300 less then a year old modem that was going to 64k on the new network now wasn't. We'll give you a $100 rebate off a new $300-500 modem for having the eariler one, but we'll still charge you $80/month to use it.
"Thankfully" I still had my modem, speed, and price that I liked (28.8 was fine at $30/month). But no new such modems or accounts were offered. If anyone new wanted Ricochet, they needed to shell out huge cash for the 128k "service" which still had much less coverage then the 28.8.
They were bankrupt within a year.
Just as they went bankrupt (same month) they decide to "renew" my annual subscription for another $300 charge to my Wellsfargo credit card. Never mind that A) the service didn't exist anymore, B) I had canceled it, and C) that credit card account itself had been CANCELED over a YEAR previous. Wellsfargo still let them put a charge on it without question. They said I could "clearly dispute it and it would be no problem", but later said I had to first personally try to resolve it with the vender.
To this day I still get a creditor of the month trying to get me to pay that now $500 "dept" that Wellsfargo allowed to be placed by a bankrupt company onto a credit card acount that had been canceled for over a year.
Fuck Ricochet and Fuck Wellsfargo. Long live WiFi!!!!
What's needed is some system where the laws of the open market can be applied to an artform. One method might be to (drastically) reapply the first performance rules to apply simiarly to the actual publication of albums. The idea might go something like this:
The above idea is also very similar to the Brand Name/Generic Name drug markets (albeit with much shorter timelines, for obvious reasons). Record companies could still make their money hand over fist for new albums as they do now, AND not only cover the cost of bust albums with the high price of star albums, but they could use each other's older catalogs in open market form to help offset those costs as well. -And of course, if some other pressing company sells one of your albums, you get royalties as well, so your bust albums could even help offset your bust albums if/when someone else manages to sell them better then you. Furthermore it would open up a new business of the pressing company (which again could likely be an online only store, like Apple is doing, but without needing to cut deals with everyone under the sun, allowing startups to compete in a big player world).
Honestly I just pulled this idea out of my ass, but the more I reread my own idea the more I like it. Anyone see any major flaws in this thinking?