Queensland is somewhat better because police are required to have a sign out saying that there are speed cameras in use, however this sign is usually conveniently placed behind a bush or behind the car with the camera in it. Queensland is also better off because the police do not rely so heavily on the revenue that their cameras drum up, it seems at times the only thing paying for Melbournes police is speeding offiences.
One thing is certain, these cameras do not save any lives. I remember clearly once in high school a Policeman came to give a talk on vehicle safety he showed us a big graph with a stedily declining death rate over the years, he pointed out the huge drop after the introduction of seat bealts, then one after they banned drink driving, and a smaller drop after the introduction of airbags. My hand immediently shot up and I asked him when speed cameras were introduced, my teachers just laughed and he never answered the question.
I see people go through the most insane and convoluted justifications for why something preventing them from speeding is bad.
Why on earth just not speed? I've never gotten a ticket in my life or worried about "sneaky cops" or "rigged cameras". I use the simple expedient of not speeding. It's not that big a deal. If you're doing 85 mph in a 70 zone, for example, you're getting there 21% faster -- big deal. In exchange, you risk the lives and property of others, your own life and property (which, I guess, is up to you to do if you want), and have to worry about speed traps constantly.
I know, I know. You're a "skilled driver", and the speed doesn't affect you at all. Everyone's a "skilled driver" in their own perception. When you hit someone, it still jacks the impact damage way up.
I didn't get a chance to mention this after the defcon talk, but your experience with people blocking you en masse after your experiments reminded me of a project I did back in 2000. I decided to crawl and record the.us cctld by using simple AXFR crawling. I chose.us because it wasn't tiny (you could crawl.za in about 5 minutes), but still had a TLD nameserver who allowed AXFRs as a starting point (uunet). You wouldn't believe how many nameservers back then gladly gave out their entire zone files to anyone who asked.
I remember when people used SNMP "public" community names and everyone allowed AXFR and it was no big deal.
Anyways, the punchline is my ISP received about 50 complaints of me "hacking" their servers.
Because every clueless sysadmin with money buys an intrusion detection system. To justify its own cost, it flags things as "hack attempts". They're probably just reading off some screen somewhere.
I remember the last time I had a question about domain name policy (I wanted to know whether it violated any policies to have a CNAME for our domain aimed at an A record in another domain). This was at a Fortune 500 company. After about a week, I had the "DNS admin", some guy with an Indian accent, get back to me. He had no idea what a CNAME was, but eventually said "oh, an *alias*". I've no idea whether there is some GUI nameserver config tool somewhere that refers to CNAMEs solely as "aliases", but it scared hell out of me to have someone responsible for a vast network's name servers that had that little idea of what he was adminning.
2. Distributing it isn't illegal, either. If a package exports functionality via an exposed API, and that package and its API aren't GPL, you can still write a "plugin" that uses that API. And you can GPL it. And you can distribute it under the GPL. And it doesn't "contaminate" the parent product.
No, that requires the LGPL or Guile license.
The only way you can interface a non-GPL-compatible package with a GPL package is via sockets, the command line, or some other non-same-process mechanism.
So, more than simply YasT. One of the things that drove me away from Fedora was that it is publically acknowledged to be public grounds for vetting Red Hat's technology which will be the basis for RHEL.
Uh...yes. But the kernel is just public grounds for vetting Linux technology which will be the basis for all distributions and so forth.
It's not like RH doesn't have a pretty rich legacy of contributing back -- if you fixed something that really was Fedora-specific, like, oh, a package dependency, White Box Linux and the other folks would pick it up. Compared to SuSE, RH's pretty decent (Caldera and SuSE are the two distributions are I find to have an uncomfortably non-free feel to them -- though Caldera really isn't an issue any more). I'm glad to see that SuSE appears to have picked up on the fact.
I don't understand the deal with YaST. Okay, I understand that people want GUI config tools. Fine, nothing wrong with that -- the ease of writing GUI frontends is a great thing about Linux. But in very recent times, I've noticed a disturbing number of moves towards making the console a second-class citizen, which *does* bother me. Red Hat seems to have come out with Network Manager in FC4, which has only a GUI configuration utility (and no documentation on how to configure it in the console), which is my latest beef. The system-config* tools no longer all work in the console -- some require a display (take system-config-services, for instance). The people who get irritable when console users are snubbed are very often the people that actually *work* on the software.
So, while GUI utils are important (they help bring in the bread-and-butter folks), console utils/ease of functioning in the CLI is at least as important, as it encourages developers to use/test on your distribution -- the entire point for your company in producing an Open Source product in the first place.
Apple's Human Interface Guidelines, back in the day, contained a number of constraints on design, like never having a modal dialog that led to another modal dialog, or always making actions available in a submenu or through a keystroke available through a regular menu as well. The Linux distros need a similar mindset, but WRT providing an equally good quality approach to CLI use as GUI use.
Now, I'm not going to demand that someone run out and write more code to pander to me (I think it's a good idea long-term for a distro, but I'm not going to whine about it.) It *does* irritate me, however, when a system that *used* to be configurable via the console (like the network) suddenly starts relying on GUI-only config tools. That sucks.
And GNOME and KDE are both quite complicit in this. Both have members who are apparently enthralled with the idea of tying apps to their respective DEs, and absolutely *stupid* architectural decisions have been made on this basis. Microsoft tying IE to the OS really was more reasonable. Take, for instance, the VFS layers. It makes absolutely no bloody sense for GNOME to have a VFS or KDE to have kioslaves. These functions have *nothing* to do with a desktop environment -- they are generic functionality that would be useful anywhere. They *should* be available in a separate library. You wouldn't make kxml and gnome-xml -- you'd use libxml So why all the tying into DEs?
While the hypothetical Linux code in the LKP may or may make the SCO kernel GPL, it most certainly makes the LKP GPL.
No, it doesn't. Mingling code with GPLed code can never make your own code GPLed (and this is actually a misconception that Microsoft has been playing off for a while -- managers worried that one of their in-house developers will cause them to "license out" their software). It may be *illegal* to use GPLed code in GPL-incompatible software, as you are infringing on the copyright of the GPL software authors, but it does not GPL your own code. If the GPL software authors wanted to file a lawsuit for damages, they could, but they could not force you to GPL your software.
glibc bugs. Pure and simple, they did some things to glibc in recent times that even statically linked apps that relied on some functions broke completely.
I understand that libraries underneath do change. I'm not out to *blame* LGP. I've been happy with what I've bought, and I intend to continue buying them.
I think that it is damn hard to target Linux as a platform for binary software, that's all. I'm quite willing to put up with the quirks. My concern is just with people getting an overly-rosy view of the issue. If someone decides to do a Linux release, great, but I'd like them to do it with their eyes wide open and comfortable with what they're doing. It beats the heck out of them getting burned and swearing off Linux forever.
Correct. This is why I said "...Loki-ported titles, Jagged Alliance, Quake 3 Arena, Majesty, and NWN". JA II, Q3A, Majesty, and NWN are all non-Loki-ported software. I was distinguishing them from Loki-ported software.
I admit that I haven't tried Descent 3 (I didn't like the earlier ones much) and I don't own HGII.
I lied, though. I did buy a copy of Darwinia (which is quite new, and works well), and forgot about it. So NWN isn't the only one.
And while I realize that Windows has its own compatibility woes -- I suspect that plenty of older games that directly accessed hardware under the Win9x series (and certainly DOS games) do not work under Windows XP -- they are not, in my limited experience, as bad as the issues with keeping Linux binaries working.
That being said, Microsoft *has* played dirty tricks in the past (like modifying IIS to service MSIE requests before Netscape's). They haven't exactly earned the benefit of the doubt.
But still, if you look at the standard OpenGL implementation in Windows nowadays, you'll notice that it's still basically crap.
What's wrong with it?
I'm not challenging your statement, just curious.
I do agree that the OGL/DX debate is significant -- Microsoft would not be putting significant development resources into something if it wasn't going to produce money for them, and being the standard-setter for game APIs makes it more difficult to port games. But all that being said, the only time I've ever had a Windows box around, the party who seemed to be at fault was Matrox (not providing support for all card features in their OGL driver, which was rough for those NT 4 users who couldn't use the latest version of DX).
Hmm...just started SMAC. It shows the Loki logo, the Firaxis logo, the "running without CD" dialog, and then promptly quits, return code 1, with no debug or other output.
As for some other goodies...getting Hyperspace Delivery Boy working (one of LGP's products, I might add) required writing a library interposer to modify the color key values going to SDL. See the HappyPenguin entry for details.
Getting Jagged Alliance II working required writing a wrapping script, LD_PRELOADing an old copy of Xlib extracted from an old Red Hat RPM and disabling NPTL.
I'm not saying that you can't get things running, I'm saying that no sane consumer with anything better to do on his weekends than I do is going to go through this.
I don't blame the porters. I'm saying that Linux, in its present state, is an exceedingly difficult platform to target for binary-only software. LGP is not to blame, Loki is not to blame; it's just the way things are.
Open-source software is a different story, however. I believe that there are a few people still selling IF adventures targetting the open-source TADS VM, and (at least a year ago) you could buy Lucasarts adventures and run them under scummvm.
...if Majesty doesn't work, have you bothered to let us know it's broken? If not, how do you expect us to fix it for you (speaking as an LGP representative right at the moment...)
IIRC, the first time I ran into a segfault in Majesty, I tried going to your support site. IIRC, I had some difficulty with the bug tracker (I just went there now and there was no Majesty entry, so that might have been it.) The email link on your support page for Majesty was also dead.
I figured "the hell with it -- they clearly aren't into fixing bugs -- I'll just make do with what I have".
To the best of MY knowlege, Majesty works just fine- or at least it did with Fedora Core 3 when I'd last installed it all on my laptop.
Well, it runs incredibly, unplayably, slowly (maybe a frame a second on my Pentium 4 Fedora Core 4 box). Looks kind of like what happens when I run programs with SDL_VIDEODRIVER=x11 and no root privileges and a program does fullscreen updates. If I try running it su'd to root and SDL_VIDEODRIVER=dga, my keyboard and mouse become inoperative and I'm left looking at a black screen.
I'm running a Radeon 9250.
IIRC, it was playable when I was using FC3.
If you have the time and funding to fix it, that's cool, but I'm not holding my breath.
I'll try SMAC, but I remember it not working as well.
See, there is just time-wasting discussion surrounding video games. That's one thing that is quite arguably not valuable. System advocacy arguments, chatting about some game.
But really trying to analyze the social impact of video games and the mechanisms through which video games function in society is not only relevant and important (video games have had quite an impact on us, and are consuming an increasing amount of human time, eating away from the previously-more-influential television), but interesting.
Consider how much mass media or inexpensive, rapid long-distance communications interacted with and changed society, at least in the United States. I'd say that, while video games may not be as influential as these, they are certainly important.
They provide a medium that allows for more experimentation than, say, movies, so they allow more exploration of what people like. They are interactive -- they are systems that must not only provide stimuli to people but do so in response to input, and make those people happy.
The Japanese bit is, I'd say, of interest to many people, and something that Japan can be proud of. I hear plenty of complaints about Westernization, but the East *does* have its own spreading culture, and Japan has had its own impact. (cowboys:ninjas::US:Japan, consider anime, consider video games). Exporting culture through media is valuable in that it increases demand for things produced by that culture. In that sense, if video games are the largest media export of Japan to the West, they may be economically valuable.
You can look at the discussion and say "this is so highly-specialized that it's unlikely to have direct, practical impact to me", and probably be right, unless you're involved in marketing or the video game industry. But there are all *kinds* of things that I read and do that aren't going to have a practical benefit to me. I play chess every now and then, for instance, and it's nothing more than a fun mental exercise, like analyzing video games.
Wikipedia does one amazing thing that Google + random web searches can't start to compete with.
Wikipedia provides overviews of things.
The problem is that when I want information about, say, USB 2.0, the Web *does* provide just about everything I might want (an improvement over writing letters to people requesting documents, for certain). However, I may have no idea what to request.
A Wikipedia article gives me a brief overview that is useful to a human, and provides me with enough information that I know where to go for further, detailed information.
It might take a long time to obtain this information normally, but Wikipedia allows me to get ahold of it almost instantly.
And one other point -- while I agree that to a security theorist, Wikipedia is horribly insecure, and can suffer many attacks, it is also inarguably *not* falling apart. So, clearly there are some important factors that we have not taken into consideration, like the fact that people may just like Wikipedia a lot.
I've mused many a time on whether a Wiki might be a good way to bootstrap an encyclopedia, but not the best once there is valuable information finished and present that one must simply keep from being vandalized. So an unmodified wiki approach might make sense for the early days of Wikipedia, but some sort of trust system might make more sense later on.
Also, for people who disagree with this policy change, remember that you can always "fork" Wikipedia.
If we can live with a bit more time to update things, there might be an "unstable Wikipedia" and a "stable Wikipedia", where editors have approved changes and dropped them into the stable release. [shrug] lots of possibilities. All I know is that Wikipedia is a great sign of the same fundamental value that drives open source -- that it is so phenomenally inexpensive to produce something that can then provide good for so many people that traditional market economics may not do a good job of serving us any more in an information age.
I know a lot of people who were tied up with SCS who didn't have a very high opinion of SEI.
Anyway, CMU SCS is where research about, y'know, neat computer science comes from, and SEI is where you get, well, management procedures. Not that management procedures can't be important and all, but they sure are a lot less interesting.
Or you could pay a tax to TrollTech, a company that wants to make money by controlling the GUI on Linux and taxing anyone that writes a non-OSS application. It is, of course, a free choice, but it seems pretty straightforward to me.
We disagree about whether or not binary-only drivers are acceptable; this is pretty much a value call.
Secondly, binary compatibility is no more troublesome these days than it is between versions of Windows, eg running a game made for Win95 on XP - occassionally an issue.
Horseshit. MSDN lists, for every API call, what behavior is supported on what OSes. Microsoft has strong constraints on binary compatibility. None of this exists in the Linux world. The Linux world is great if you are open source, because you can update your code as APIs and ABIs change, and cruft doesn't build up, but the price of that is that binaries are a pain in the butt.
Yes, in theory, this can be done. In practice, because library authors change behavior and people don't write perfect code, Linux binary-only games stop running extremely quickly. I currently can play Windows games that are many years old, like Starcraft, on my computer via WINE. I can't play Linux games from that era, like Hopkins FBI. The only commercial Linux game in my collection I have that works properly out-of-box on Fedora Core 4 is Neverwinter Nights. I have a whole *shelf* of Linux game CDs in the other room that should work that don't.
Installation of binaries can be done easily using a system like Autopackage if one doesn't want to find and or become an *.rpm/*.deb package maintainer.
RPMs and DEBs are not designed for forwards-compatibility across distributions. They are designed to provide the distro vendor with a mechanism for handling package interactions. It is not feasible to simply make an RPM and ship it -- names change frequently and are not frozen or guaranteed to stay the same. Even Red Hat's own RPMs aren't necessary safe to use across distros (i.e. dependencies are incorrect). Don't claim that I'm wrong -- I've upgraded to every Red Hat distro since 5.2 in a "live", piecemeal fashion RPMs at a time, and I'm *quite* familiar with cross-distro-version dependency problems.
Where devices are concerned, the trouble you speak of is many years in the past - udev works in userspace, and uses hotplug calls that the kernel signals whenever a device is added or removed from the kernel. Permissions, naming and control is all done in userspace.
[shrug] Maybe I'll have to take another look at it. I upgraded an FC3 system to FC4 by hand, and udev seemed mostly to be a compatibility-breaking annoyance, but I'm hoping that it solves the ordering problem, as another poster claimed, given that this has been a very long-standing issue. It would be really great if it was in a way that would be usable for the masses, too.
PS. Game development, as a culture, needs free software if a) small to medium sized developers are to survive and b) if micro-markets (like that of the indie-film industry) are to burgeon. Tools are increasingly expensive and publishers offset this cost with IP tradeoffs (buy outs). If I were you I'd ship the engine as free software (binary checksum for login, cheat protection and validation) and sell the data and/or subscription time. More on why here.
That works for certain types of games.
The main problems come in in the form of:
(a) cheating. It is *fucking hard* to design an efficient engine for any sort of a real-time game that is not vulnerable to cheating, and it is much easier to cheat with an open-source game. xpilot, bzflag, etc, have all had their own problems.
(b) For many games, it's hard to intertwine that binary code effectively with the source code, in a way that isn't easy to hack.
(c) Selling data is nice, but it means that more people will pirate it. That eats sales. That's just a fact of life.
Binary compatibility is NOT a bitch on Linux for closed-source games, espcially games. Staticly compiled software, even very old ones, work without problems.
I own a large number of Loki-ported titles, Jagged Alliance, Quake 3 Arena, Majesty, and NWN. The *only* game that works properly out-of-box on a Fedora Core 4 system is NWN. I have put extensive work into troubleshooting my games, I am running the most mainstream Linux distro around, and I would like to hear what your explanation for this state of affairs is.
Old Loki games actually install without binary compatibility problems, unlike what you say.
Nope. As a matter of fact, not only do they generally not work, but the patch binary crashes and has crashed for some time on at least Red-Hat based systems when attempting to update a current game.
Of course it's reasonnable to ship a Linux binary, as long as it's statically compiled and in a self-contained package. Even when not statically compiled, there are simple ways to include your library, and make your app use them if it can't find them on the host system.
Unless your API stops being maintained (DGA1).
Unless the behavior of the libraries change (SDL alpha mask values).
Unless the coder has not written correct C code (I don't write correct C code; nobody does. Read comp.lang.c if you want some humbling).
You're also wrong to compare to a distro vendor. Most of distro's software are NOT written for the distro, they integrate it.
compat-libstdc++ doesn't ring a bell for you?
Of course, a new distro shipping Apache won't package all the old versions of Apache, only the latest version. So what you say is wrong anyway.
And closed-source game vendors don't keep releasing new binaries.
And you surely don't love Linux, especially since your advice of "second platform" being the Mac just shows your way of thinking : despite the author saying that he developed the game on Mac first, you managed to understand Windows, which just show you are an astroturfer to me.
I have publically written extensive troubleshooting advice for binary-only games; provide an email address and I will be glad to email you a reference.
I have written patches for quite a number of open-source games.
I have been using Linux for years, and exclusively run Linux as my home system for years.
Yes, there are probably people that "love Linux" more than I do, but I'm inclined to think that they are just being dishonest. Linux is a great system for some things, but getting people's hopes up (such as about game potential) and then dashing them does not help long run.
I never heard of Jagged Alliance btw...
I'm sorry. It's a fun game.
3rd point : The state of 3D under Linux does not suck like you say. You can be all sorry you want. Every binary drivers produce friction from the kernel folks, because they are unstable, meaning all the system becomes unstable, and they can't fix them. So they advertise the most they can about the fact that binary drivers taint the kernel : this has nothing to do with the state of 3D on Linux. And be specific instead of spreading FUD : the state of open source 3D in Linux has regressed, NOT the state of closed source 3D.
[shrug] I figure that most people that use Linux want to enjoy open source; this is why I use a Linux box. I suspect that most people for whom open source is not a big concern are off using Mac OS or something else Unixy.
5th point : The installer world for Linux is already suitable to do a Windows-style "download this file and use it", but you did not notice autopackage or the Loki installer, despite it being very old... Several Open Source games for Linux uses it btw, like Privateer Remake. You did not notice because you are not a Linux user (I am FYI).
I have used Linux continuously since Red Hat 5.2, and finally blew away my dead copy of Windows NT
I'm playing NWN on Linux with the ATI open drivers, as I'm not willing to use anything other than open source drivers, and I generally see between one lock-up every two days to three lockups a day.
While I agree that copyright-infringing uses will probably dominate this software (just as has happened on other P2P filesharing networks), I can tell you that there is definitely spam from spyware, etc. And content rating en-masse *is* a significant problem with major practical applications to society.
Actually, while I doubt the OP intended it, he has a good point.
See, let's be honest about this. While there will *always* be jackasses out there who spam networks just because they can, and a few more people trying to shove spyware down people's throats, a pretty big chunk of the folks producing spam are those trying to prevent their copyrights (however overly-long-lived they may be) from being infringed upon.
So, the point is, that it's a good bet that a sizeable chunk of the files being shared aren't exactly legal.
Which means that you don't really want to make it especially obvious that you're sharing said file.
What this system does is provides a cryptographic signature on a small, publically downloadable piece of data that establishes that you have downloaded and *consciously examined* the file.
Frankly, this is pretty good evidence for someone trying to push an infringement lawsuit that you have infringed upon their copyright (yes, our work has MD5sum "foo" the same as the thing this guy is rating.
That being said, I do think that a more sophisticated method to this approach will win.
The largest problem on the Internet has always been rating and attributing data -- Google takes a pretty decent stab at some of the problem, and look how essential they've become. This just does a much better job.
First, I've seen various system-specific mailing lists be used by people who are interested in hiring someone to do a job. Perl-specific mailing lists, SDL-specific mailing lists, and so forth. This is one way to find people familiar with a system.
Second, if you are doing a closed-source game for Linux, be aware that binary compatibility is a *bitch*. I have done a fair amount of work on getting older Linux binary games that I've purchased to work, and I'm pretty much convinced that it's not reasonable to just ship "a Linux binary" in the same sense that one ships a Windows binary that one simply expects to work. In the past, companies that have attempted to do Linux ports of their games have generally not had a binary that continues to work for more than a year or several. The Linux world is not really oriented around guaranteeing binary compatability -- vendors do not generally feel constrained to make sure that software written for their distro a few versions back continues to work. This is *not* a minor undertaking. Much as I love Linux, I would suggest that a better target for a "second platform port" would be the Mac. You appear to have done that, and if you're really pleased with the results, you've made your money back and all, then it might be worthwhile to consider Linux. In general, though, folks attempting to do commercial Linux releases have not done very well -- I understand that Jagged Alliance 2, for instance, shipped something like a couple hundred copies in the first few weeks. That was a pretty high-profile game with a solid port, and no fancy requirements (3d, etc).
Third, be aware that the state of 3d under Linux sucks. I'm sorry, but that's how it is. ATI and NVidia ship binary drivers that produce friction from the kernel folks. The fastest cards with open-source drivers are some of ATIs, and those drivers are *not* rock-solid. Linux was actually better off in the 3d arena a couple of years back, when Matrox had good open source support and ATI was allowing open source drivers -- the state of Linux 3d has actually regressed.
Fourth, if you do this, if at *all* possible, use the existing standard libraries. SDL is the closest thing to a standard game development environment out there across Linux distros. SDL_image and SDL_mixer are also good sidekicks. SDL has lots of oddball competitors that are more or less a pain to get running on various systems.
Fifth, take a look at the strategies that Loki and the other Linux game developers used for deploying patches, for dealing with shared/static libraries, for handling installation/uninstallation, and so forth. The installer world for Linux is not currently suitable to do a Windows-style "download this file and use it" and vendors currently aren't really set up (with the possible exception of Linspire) to provide for-sale applications through their package management system.
Sixth, *let users specify devices*. Nothing is more annoying than some random developer who decides that/dev/dsp is always going to be the sound card and/dev/js0 is always going to be the joystick. If you want to detect them, great, but let the user specify.
Seventh, be aware that Linux currently is not capable of maintaining joystick orderings, so if the user has two joysticks, one may wind up being/dev/js0 on a particular boot and/dev/js1 on the next boot.
Eighth, furries rock. Good job.
Nineth, while this almost certainly isn't appropriate for your game or your scale of operation, be aware that some of the most technically successful cross-platform vendors have built VMs and then targetted that VM. Sierra's AGI and SCI engines, Lucasarts' SCUMM, Infocom's Z-engine (and the free competitor, TADS) all made for generations of highly-portable adventure games (yet none of these games were extremely sluggish or technically limited for their day).
Tenth, let your users toggle between full screen and wi
Slashdot Mirror
Some of us like to switch to new accounts now and then.
Queensland is somewhat better because police are required to have a sign out saying that there are speed cameras in use, however this sign is usually conveniently placed behind a bush or behind the car with the camera in it. Queensland is also better off because the police do not rely so heavily on the revenue that their cameras drum up, it seems at times the only thing paying for Melbournes police is speeding offiences.
One thing is certain, these cameras do not save any lives. I remember clearly once in high school a Policeman came to give a talk on vehicle safety he showed us a big graph with a stedily declining death rate over the years, he pointed out the huge drop after the introduction of seat bealts, then one after they banned drink driving, and a smaller drop after the introduction of airbags. My hand immediently shot up and I asked him when speed cameras were introduced, my teachers just laughed and he never answered the question.
I see people go through the most insane and convoluted justifications for why something preventing them from speeding is bad.
Why on earth just not speed? I've never gotten a ticket in my life or worried about "sneaky cops" or "rigged cameras". I use the simple expedient of not speeding. It's not that big a deal. If you're doing 85 mph in a 70 zone, for example, you're getting there 21% faster -- big deal. In exchange, you risk the lives and property of others, your own life and property (which, I guess, is up to you to do if you want), and have to worry about speed traps constantly.
I know, I know. You're a "skilled driver", and the speed doesn't affect you at all. Everyone's a "skilled driver" in their own perception. When you hit someone, it still jacks the impact damage way up.
I didn't get a chance to mention this after the defcon talk, but your experience with people blocking you en masse after your experiments reminded me of a project I did back in 2000. I decided to crawl and record the .us cctld by using simple AXFR crawling. I chose .us because it wasn't tiny (you could crawl .za in about 5 minutes), but still had a TLD nameserver who allowed AXFRs as a starting point (uunet). You wouldn't believe how many nameservers back then gladly gave out their entire zone files to anyone who asked.
I remember when people used SNMP "public" community names and everyone allowed AXFR and it was no big deal.
Anyways, the punchline is my ISP received about 50 complaints of me "hacking" their servers.
Because every clueless sysadmin with money buys an intrusion detection system. To justify its own cost, it flags things as "hack attempts". They're probably just reading off some screen somewhere.
I remember the last time I had a question about domain name policy (I wanted to know whether it violated any policies to have a CNAME for our domain aimed at an A record in another domain). This was at a Fortune 500 company. After about a week, I had the "DNS admin", some guy with an Indian accent, get back to me. He had no idea what a CNAME was, but eventually said "oh, an *alias*". I've no idea whether there is some GUI nameserver config tool somewhere that refers to CNAMEs solely as "aliases", but it scared hell out of me to have someone responsible for a vast network's name servers that had that little idea of what he was adminning.
2. Distributing it isn't illegal, either. If a package exports functionality via an exposed API, and that package and its API aren't GPL, you can still write a "plugin" that uses that API. And you can GPL it. And you can distribute it under the GPL. And it doesn't "contaminate" the parent product.
No, that requires the LGPL or Guile license.
The only way you can interface a non-GPL-compatible package with a GPL package is via sockets, the command line, or some other non-same-process mechanism.
So, more than simply YasT. One of the things that drove me away from Fedora was that it is publically acknowledged to be public grounds for vetting Red Hat's technology which will be the basis for RHEL.
Uh...yes. But the kernel is just public grounds for vetting Linux technology which will be the basis for all distributions and so forth.
It's not like RH doesn't have a pretty rich legacy of contributing back -- if you fixed something that really was Fedora-specific, like, oh, a package dependency, White Box Linux and the other folks would pick it up. Compared to SuSE, RH's pretty decent (Caldera and SuSE are the two distributions are I find to have an uncomfortably non-free feel to them -- though Caldera really isn't an issue any more). I'm glad to see that SuSE appears to have picked up on the fact.
I don't understand the deal with YaST. Okay, I understand that people want GUI config tools. Fine, nothing wrong with that -- the ease of writing GUI frontends is a great thing about Linux. But in very recent times, I've noticed a disturbing number of moves towards making the console a second-class citizen, which *does* bother me. Red Hat seems to have come out with Network Manager in FC4, which has only a GUI configuration utility (and no documentation on how to configure it in the console), which is my latest beef. The system-config* tools no longer all work in the console -- some require a display (take system-config-services, for instance). The people who get irritable when console users are snubbed are very often the people that actually *work* on the software.
So, while GUI utils are important (they help bring in the bread-and-butter folks), console utils/ease of functioning in the CLI is at least as important, as it encourages developers to use/test on your distribution -- the entire point for your company in producing an Open Source product in the first place.
Apple's Human Interface Guidelines, back in the day, contained a number of constraints on design, like never having a modal dialog that led to another modal dialog, or always making actions available in a submenu or through a keystroke available through a regular menu as well. The Linux distros need a similar mindset, but WRT providing an equally good quality approach to CLI use as GUI use.
Now, I'm not going to demand that someone run out and write more code to pander to me (I think it's a good idea long-term for a distro, but I'm not going to whine about it.) It *does* irritate me, however, when a system that *used* to be configurable via the console (like the network) suddenly starts relying on GUI-only config tools. That sucks.
And GNOME and KDE are both quite complicit in this. Both have members who are apparently enthralled with the idea of tying apps to their respective DEs, and absolutely *stupid* architectural decisions have been made on this basis. Microsoft tying IE to the OS really was more reasonable. Take, for instance, the VFS layers. It makes absolutely no bloody sense for GNOME to have a VFS or KDE to have kioslaves. These functions have *nothing* to do with a desktop environment -- they are generic functionality that would be useful anywhere. They *should* be available in a separate library. You wouldn't make kxml and gnome-xml -- you'd use libxml So why all the tying into DEs?
Some people prefer to chatter with their friends constantly instead of musing over their own thoughts when alone for a while.
While the hypothetical Linux code in the LKP may or may make the SCO kernel GPL, it most certainly makes the LKP GPL.
No, it doesn't. Mingling code with GPLed code can never make your own code GPLed (and this is actually a misconception that Microsoft has been playing off for a while -- managers worried that one of their in-house developers will cause them to "license out" their software). It may be *illegal* to use GPLed code in GPL-incompatible software, as you are infringing on the copyright of the GPL software authors, but it does not GPL your own code. If the GPL software authors wanted to file a lawsuit for damages, they could, but they could not force you to GPL your software.
glibc bugs. Pure and simple, they did some things to glibc in recent times that even statically linked apps that relied on some functions broke completely.
I understand that libraries underneath do change. I'm not out to *blame* LGP. I've been happy with what I've bought, and I intend to continue buying them.
I think that it is damn hard to target Linux as a platform for binary software, that's all. I'm quite willing to put up with the quirks. My concern is just with people getting an overly-rosy view of the issue. If someone decides to do a Linux release, great, but I'd like them to do it with their eyes wide open and comfortable with what they're doing. It beats the heck out of them getting burned and swearing off Linux forever.
NWN isn't a loki game.
Correct. This is why I said "...Loki-ported titles, Jagged Alliance, Quake 3 Arena, Majesty, and NWN". JA II, Q3A, Majesty, and NWN are all non-Loki-ported software. I was distinguishing them from Loki-ported software.
I admit that I haven't tried Descent 3 (I didn't like the earlier ones much) and I don't own HGII.
I lied, though. I did buy a copy of Darwinia (which is quite new, and works well), and forgot about it. So NWN isn't the only one.
And while I realize that Windows has its own compatibility woes -- I suspect that plenty of older games that directly accessed hardware under the Win9x series (and certainly DOS games) do not work under Windows XP -- they are not, in my limited experience, as bad as the issues with keeping Linux binaries working.
That being said, Microsoft *has* played dirty tricks in the past (like modifying IIS to service MSIE requests before Netscape's). They haven't exactly earned the benefit of the doubt.
But still, if you look at the standard OpenGL implementation in Windows nowadays, you'll notice that it's still basically crap.
What's wrong with it?
I'm not challenging your statement, just curious.
I do agree that the OGL/DX debate is significant -- Microsoft would not be putting significant development resources into something if it wasn't going to produce money for them, and being the standard-setter for game APIs makes it more difficult to port games. But all that being said, the only time I've ever had a Windows box around, the party who seemed to be at fault was Matrox (not providing support for all card features in their OGL driver, which was rough for those NT 4 users who couldn't use the latest version of DX).
And, BTW, I'm still waiting with checkbook in hand for you folks to release Knights and Merchants...
Hmm...just started SMAC. It shows the Loki logo, the Firaxis logo, the "running without CD" dialog, and then promptly quits, return code 1, with no debug or other output.
As for some other goodies...getting Hyperspace Delivery Boy working (one of LGP's products, I might add) required writing a library interposer to modify the color key values going to SDL. See the HappyPenguin entry for details.
Getting Jagged Alliance II working required writing a wrapping script, LD_PRELOADing an old copy of Xlib extracted from an old Red Hat RPM and disabling NPTL.
I'm not saying that you can't get things running, I'm saying that no sane consumer with anything better to do on his weekends than I do is going to go through this.
I don't blame the porters. I'm saying that Linux, in its present state, is an exceedingly difficult platform to target for binary-only software. LGP is not to blame, Loki is not to blame; it's just the way things are.
Open-source software is a different story, however. I believe that there are a few people still selling IF adventures targetting the open-source TADS VM, and (at least a year ago) you could buy Lucasarts adventures and run them under scummvm.
...if Majesty doesn't work, have you bothered to let us know it's broken? If not, how do you expect us to fix it for you (speaking as an LGP representative right at the moment...)
IIRC, the first time I ran into a segfault in Majesty, I tried going to your support site. IIRC, I had some difficulty with the bug tracker (I just went there now and there was no Majesty entry, so that might have been it.) The email link on your support page for Majesty was also dead.
I figured "the hell with it -- they clearly aren't into fixing bugs -- I'll just make do with what I have".
To the best of MY knowlege, Majesty works just fine- or at least it did with Fedora Core 3 when I'd last installed it all on my laptop.
Well, it runs incredibly, unplayably, slowly (maybe a frame a second on my Pentium 4 Fedora Core 4 box). Looks kind of like what happens when I run programs with SDL_VIDEODRIVER=x11 and no root privileges and a program does fullscreen updates. If I try running it su'd to root and SDL_VIDEODRIVER=dga, my keyboard and mouse become inoperative and I'm left looking at a black screen.
I'm running a Radeon 9250.
IIRC, it was playable when I was using FC3.
If you have the time and funding to fix it, that's cool, but I'm not holding my breath.
I'll try SMAC, but I remember it not working as well.
I'd say that it *can* be important.
See, there is just time-wasting discussion surrounding video games. That's one thing that is quite arguably not valuable. System advocacy arguments, chatting about some game.
But really trying to analyze the social impact of video games and the mechanisms through which video games function in society is not only relevant and important (video games have had quite an impact on us, and are consuming an increasing amount of human time, eating away from the previously-more-influential television), but interesting.
Consider how much mass media or inexpensive, rapid long-distance communications interacted with and changed society, at least in the United States. I'd say that, while video games may not be as influential as these, they are certainly important.
They provide a medium that allows for more experimentation than, say, movies, so they allow more exploration of what people like. They are interactive -- they are systems that must not only provide stimuli to people but do so in response to input, and make those people happy.
The Japanese bit is, I'd say, of interest to many people, and something that Japan can be proud of. I hear plenty of complaints about Westernization, but the East *does* have its own spreading culture, and Japan has had its own impact. (cowboys:ninjas::US:Japan, consider anime, consider video games). Exporting culture through media is valuable in that it increases demand for things produced by that culture. In that sense, if video games are the largest media export of Japan to the West, they may be economically valuable.
You can look at the discussion and say "this is so highly-specialized that it's unlikely to have direct, practical impact to me", and probably be right, unless you're involved in marketing or the video game industry. But there are all *kinds* of things that I read and do that aren't going to have a practical benefit to me. I play chess every now and then, for instance, and it's nothing more than a fun mental exercise, like analyzing video games.
Wikipedia does one amazing thing that Google + random web searches can't start to compete with.
Wikipedia provides overviews of things.
The problem is that when I want information about, say, USB 2.0, the Web *does* provide just about everything I might want (an improvement over writing letters to people requesting documents, for certain). However, I may have no idea what to request.
A Wikipedia article gives me a brief overview that is useful to a human, and provides me with enough information that I know where to go for further, detailed information.
It might take a long time to obtain this information normally, but Wikipedia allows me to get ahold of it almost instantly.
And one other point -- while I agree that to a security theorist, Wikipedia is horribly insecure, and can suffer many attacks, it is also inarguably *not* falling apart. So, clearly there are some important factors that we have not taken into consideration, like the fact that people may just like Wikipedia a lot.
I've mused many a time on whether a Wiki might be a good way to bootstrap an encyclopedia, but not the best once there is valuable information finished and present that one must simply keep from being vandalized. So an unmodified wiki approach might make sense for the early days of Wikipedia, but some sort of trust system might make more sense later on.
Also, for people who disagree with this policy change, remember that you can always "fork" Wikipedia.
If we can live with a bit more time to update things, there might be an "unstable Wikipedia" and a "stable Wikipedia", where editors have approved changes and dropped them into the stable release. [shrug] lots of possibilities. All I know is that Wikipedia is a great sign of the same fundamental value that drives open source -- that it is so phenomenally inexpensive to produce something that can then provide good for so many people that traditional market economics may not do a good job of serving us any more in an information age.
I know a lot of people who were tied up with SCS who didn't have a very high opinion of SEI.
Anyway, CMU SCS is where research about, y'know, neat computer science comes from, and SEI is where you get, well, management procedures. Not that management procedures can't be important and all, but they sure are a lot less interesting.
Not true. Proprietary software suffers from version inflation.
QT provides a ton of functionality for networking, XML, collections, database programming.
Or you could use GTK's free equivalents -- gnet, libxml, glib's collections, and gnomedb.
Or you could pay a tax to TrollTech, a company that wants to make money by controlling the GUI on Linux and taxing anyone that writes a non-OSS application. It is, of course, a free choice, but it seems pretty straightforward to me.
We disagree about whether or not binary-only drivers are acceptable; this is pretty much a value call.
Secondly, binary compatibility is no more troublesome these days than it is between versions of Windows, eg running a game made for Win95 on XP - occassionally an issue.
Horseshit. MSDN lists, for every API call, what behavior is supported on what OSes. Microsoft has strong constraints on binary compatibility. None of this exists in the Linux world. The Linux world is great if you are open source, because you can update your code as APIs and ABIs change, and cruft doesn't build up, but the price of that is that binaries are a pain in the butt.
Yes, in theory, this can be done. In practice, because library authors change behavior and people don't write perfect code, Linux binary-only games stop running extremely quickly. I currently can play Windows games that are many years old, like Starcraft, on my computer via WINE. I can't play Linux games from that era, like Hopkins FBI. The only commercial Linux game in my collection I have that works properly out-of-box on Fedora Core 4 is Neverwinter Nights. I have a whole *shelf* of Linux game CDs in the other room that should work that don't.
Installation of binaries can be done easily using a system like Autopackage if one doesn't want to find and or become an *.rpm/*.deb package maintainer.
RPMs and DEBs are not designed for forwards-compatibility across distributions. They are designed to provide the distro vendor with a mechanism for handling package interactions. It is not feasible to simply make an RPM and ship it -- names change frequently and are not frozen or guaranteed to stay the same. Even Red Hat's own RPMs aren't necessary safe to use across distros (i.e. dependencies are incorrect). Don't claim that I'm wrong -- I've upgraded to every Red Hat distro since 5.2 in a "live", piecemeal fashion RPMs at a time, and I'm *quite* familiar with cross-distro-version dependency problems.
Where devices are concerned, the trouble you speak of is many years in the past - udev works in userspace, and uses hotplug calls that the kernel signals whenever a device is added or removed from the kernel. Permissions, naming and control is all done in userspace.
[shrug] Maybe I'll have to take another look at it. I upgraded an FC3 system to FC4 by hand, and udev seemed mostly to be a compatibility-breaking annoyance, but I'm hoping that it solves the ordering problem, as another poster claimed, given that this has been a very long-standing issue. It would be really great if it was in a way that would be usable for the masses, too.
PS. Game development, as a culture, needs free software if a) small to medium sized developers are to survive and b) if micro-markets (like that of the indie-film industry) are to burgeon. Tools are increasingly expensive and publishers offset this cost with IP tradeoffs (buy outs). If I were you I'd ship the engine as free software (binary checksum for login, cheat protection and validation) and sell the data and/or subscription time. More on why here.
That works for certain types of games.
The main problems come in in the form of:
(a) cheating. It is *fucking hard* to design an efficient engine for any sort of a real-time game that is not vulnerable to cheating, and it is much easier to cheat with an open-source game. xpilot, bzflag, etc, have all had their own problems.
(b) For many games, it's hard to intertwine that binary code effectively with the source code, in a way that isn't easy to hack.
(c) Selling data is nice, but it means that more people will pirate it. That eats sales. That's just a fact of life.
Binary compatibility is NOT a bitch on Linux for closed-source games, espcially games. Staticly compiled software, even very old ones, work without problems.
...
... Several Open Source games for Linux uses it btw, like Privateer Remake. You did not notice because you are not a Linux user (I am FYI).
I own a large number of Loki-ported titles, Jagged Alliance, Quake 3 Arena, Majesty, and NWN. The *only* game that works properly out-of-box on a Fedora Core 4 system is NWN. I have put extensive work into troubleshooting my games, I am running the most mainstream Linux distro around, and I would like to hear what your explanation for this state of affairs is.
Old Loki games actually install without binary compatibility problems, unlike what you say.
Nope. As a matter of fact, not only do they generally not work, but the patch binary crashes and has crashed for some time on at least Red-Hat based systems when attempting to update a current game.
Of course it's reasonnable to ship a Linux binary, as long as it's statically compiled and in a self-contained package. Even when not statically compiled, there are simple ways to include your library, and make your app use them if it can't find them on the host system.
Unless your API stops being maintained (DGA1).
Unless the behavior of the libraries change (SDL alpha mask values).
Unless the coder has not written correct C code (I don't write correct C code; nobody does. Read comp.lang.c if you want some humbling).
You're also wrong to compare to a distro vendor. Most of distro's software are NOT written for the distro, they integrate it.
compat-libstdc++ doesn't ring a bell for you?
Of course, a new distro shipping Apache won't package all the old versions of Apache, only the latest version. So what you say is wrong anyway.
And closed-source game vendors don't keep releasing new binaries.
And you surely don't love Linux, especially since your advice of "second platform" being the Mac just shows your way of thinking : despite the author saying that he developed the game on Mac first, you managed to understand Windows, which just show you are an astroturfer to me.
I have publically written extensive troubleshooting advice for binary-only games; provide an email address and I will be glad to email you a reference.
I have written patches for quite a number of open-source games.
I have been using Linux for years, and exclusively run Linux as my home system for years.
Yes, there are probably people that "love Linux" more than I do, but I'm inclined to think that they are just being dishonest. Linux is a great system for some things, but getting people's hopes up (such as about game potential) and then dashing them does not help long run.
I never heard of Jagged Alliance btw
I'm sorry. It's a fun game.
3rd point : The state of 3D under Linux does not suck like you say. You can be all sorry you want. Every binary drivers produce friction from the kernel folks, because they are unstable, meaning all the system becomes unstable, and they can't fix them. So they advertise the most they can about the fact that binary drivers taint the kernel : this has nothing to do with the state of 3D on Linux. And be specific instead of spreading FUD : the state of open source 3D in Linux has regressed, NOT the state of closed source 3D.
[shrug] I figure that most people that use Linux want to enjoy open source; this is why I use a Linux box. I suspect that most people for whom open source is not a big concern are off using Mac OS or something else Unixy.
5th point : The installer world for Linux is already suitable to do a Windows-style "download this file and use it", but you did not notice autopackage or the Loki installer, despite it being very old
I have used Linux continuously since Red Hat 5.2, and finally blew away my dead copy of Windows NT
I'm playing NWN on Linux with the ATI open drivers, as I'm not willing to use anything other than open source drivers, and I generally see between one lock-up every two days to three lockups a day.
While I agree that copyright-infringing uses will probably dominate this software (just as has happened on other P2P filesharing networks), I can tell you that there is definitely spam from spyware, etc. And content rating en-masse *is* a significant problem with major practical applications to society.
Actually, while I doubt the OP intended it, he has a good point.
See, let's be honest about this. While there will *always* be jackasses out there who spam networks just because they can, and a few more people trying to shove spyware down people's throats, a pretty big chunk of the folks producing spam are those trying to prevent their copyrights (however overly-long-lived they may be) from being infringed upon.
So, the point is, that it's a good bet that a sizeable chunk of the files being shared aren't exactly legal.
Which means that you don't really want to make it especially obvious that you're sharing said file.
What this system does is provides a cryptographic signature on a small, publically downloadable piece of data that establishes that you have downloaded and *consciously examined* the file.
Frankly, this is pretty good evidence for someone trying to push an infringement lawsuit that you have infringed upon their copyright (yes, our work has MD5sum "foo" the same as the thing this guy is rating.
That being said, I do think that a more sophisticated method to this approach will win.
The largest problem on the Internet has always been rating and attributing data -- Google takes a pretty decent stab at some of the problem, and look how essential they've become. This just does a much better job.
A couple thoughts.
/dev/dsp is always going to be the sound card and /dev/js0 is always going to be the joystick. If you want to detect them, great, but let the user specify.
/dev/js0 on a particular boot and /dev/js1 on the next boot.
First, I've seen various system-specific mailing lists be used by people who are interested in hiring someone to do a job. Perl-specific mailing lists, SDL-specific mailing lists, and so forth. This is one way to find people familiar with a system.
Second, if you are doing a closed-source game for Linux, be aware that binary compatibility is a *bitch*. I have done a fair amount of work on getting older Linux binary games that I've purchased to work, and I'm pretty much convinced that it's not reasonable to just ship "a Linux binary" in the same sense that one ships a Windows binary that one simply expects to work. In the past, companies that have attempted to do Linux ports of their games have generally not had a binary that continues to work for more than a year or several. The Linux world is not really oriented around guaranteeing binary compatability -- vendors do not generally feel constrained to make sure that software written for their distro a few versions back continues to work. This is *not* a minor undertaking. Much as I love Linux, I would suggest that a better target for a "second platform port" would be the Mac. You appear to have done that, and if you're really pleased with the results, you've made your money back and all, then it might be worthwhile to consider Linux. In general, though, folks attempting to do commercial Linux releases have not done very well -- I understand that Jagged Alliance 2, for instance, shipped something like a couple hundred copies in the first few weeks. That was a pretty high-profile game with a solid port, and no fancy requirements (3d, etc).
Third, be aware that the state of 3d under Linux sucks. I'm sorry, but that's how it is. ATI and NVidia ship binary drivers that produce friction from the kernel folks. The fastest cards with open-source drivers are some of ATIs, and those drivers are *not* rock-solid. Linux was actually better off in the 3d arena a couple of years back, when Matrox had good open source support and ATI was allowing open source drivers -- the state of Linux 3d has actually regressed.
Fourth, if you do this, if at *all* possible, use the existing standard libraries. SDL is the closest thing to a standard game development environment out there across Linux distros. SDL_image and SDL_mixer are also good sidekicks. SDL has lots of oddball competitors that are more or less a pain to get running on various systems.
Fifth, take a look at the strategies that Loki and the other Linux game developers used for deploying patches, for dealing with shared/static libraries, for handling installation/uninstallation, and so forth. The installer world for Linux is not currently suitable to do a Windows-style "download this file and use it" and vendors currently aren't really set up (with the possible exception of Linspire) to provide for-sale applications through their package management system.
Sixth, *let users specify devices*. Nothing is more annoying than some random developer who decides that
Seventh, be aware that Linux currently is not capable of maintaining joystick orderings, so if the user has two joysticks, one may wind up being
Eighth, furries rock. Good job.
Nineth, while this almost certainly isn't appropriate for your game or your scale of operation, be aware that some of the most technically successful cross-platform vendors have built VMs and then targetted that VM. Sierra's AGI and SCI engines, Lucasarts' SCUMM, Infocom's Z-engine (and the free competitor, TADS) all made for generations of highly-portable adventure games (yet none of these games were extremely sluggish or technically limited for their day).
Tenth, let your users toggle between full screen and wi