one of your points, ZoneAlarm (at least) does checksum all the apps and compares them when they request a connection.
Wow, I would have thought that that would have been prohibitively expensive performancewise, which is why I would assume that only a "trusted OS" would do that. Interesting. So I'd assume (since Google fails to turn up a detailed whitepaper on the first few hits) that ZA MD5s the binary at the first socket access the app tries during an invocation (it certainly can't be every time the app tries to do something, or performance would be completely unbearable).
But you really don't have to go to all this work. Copy (or contain) a copy of a trusted binary. Drop it into a directory somewhere. Drop a modified msvcrt.dll in the same directory, and let the program link to said DLL, and you've easily got untrusted code running within your "trusted" application.
Frankly, as long as the OS doesn't have pretty low level support for this, you're going to be able to bypass it.
I wonder what ZA could do to fix this? MD5summing linked to DLLs would be kind of expensive, and wouldn't work at all if there was application-initiated (rather than load-time OS-initiated) dynamic linking going on. I guess you could do that, take the performance hit...then ZA could hook LoadLibrary() and handle application-initiated linking....
Still, as you and I mentioned, the monolithic design of IE, providing application-level services and using components left and right, is pretty much an unstoppable impediment to securing a Windows-based system.
Generally, yes. And if the service was bad (I remember a notable case of a platter of spaghetti being spilled all over, for example), no.
The analogy isn't entirely accurate, either. Wrkers aren't really paid enough without their tips. The tips likely form a majority of their pay. The business model essentially dictates that a portion of your bill is simply paid differently. This is not the case for regular employees expecting a Christmas bonus -- if that Christmas bonus is comprising the majority of their pay, something is seriously unusual.
No one needs 65M a year, and taking that much for herself just shows he's not as loyal to the company as she should be to be the CEO.
"Loyalty to a company" in just about any company over fifty people or so is a sweet-sounding nonexistant Grail. It's lovely material to feed a worker to make him more productive, but it's silly. The company has no particular loyalty to you -- to HR, you're just another statistic that might potentially be sucking down money, and if you ever become a liability instead of an asset (after, of course, factoring in the cost of firing you and the effects on your coworkers of doing so, and considering your future potential value), the company will drop you like a hot potato. The company has no loyalty to you -- why should you to it?
Now, that doesn't mean that justifies things like stealing from the company or trying to shaft it (as some people seem to feel) -- things like this frequently come back and hurt you far worse than any possible benefit. However, whenever you get stuck in your head that the company you work at is a kind, loving father or something, instead of a cold, profit-seeking institution, you're running the risk of painful dillusionment.
I see people post here ever so frequently that "I gave 80 hours a week of work to my company and they didn't give me anything back" or "Times are tight, so my company is firing because it's best for all of us, but they really don't want to fire me". Bad mental state to be in. Don't come to rely on your company for more than they signed on for in your contract, and you won't have any nasty surprises.
This wasn't all aimed at you, more of a general feeling towards Slashdotters complaining that they didn't get what they expected...
Whilst that's something that iptables/chains just can't cope with (sadly) I have Norton Internet Firewall, for my remaining Windows PC, which is application based. ie, you can accept/deny any connection for each application.
I believe you refer to process name matching, which was added to iptables-1.2.7.
Of course, iptables doesn't have a pretty GUI interface like NIF, but there are plenty of people that have made front ends for it.
I don't like the approach much, as there are lots of ways for a programmer to get around it -- I mean, process name/(application name under Windows) is not some immutable thing, and worst case, the program copies itself to a file of a different name and executes itself.
I suppose if the OS's loader SHA-fingerprinted binaries at load time (expensive, but secure) and granted rights based on said SHAsum, you might manage to securely pull something off like this. Then said application couldn't support "components" or plugins, as MSIE unfortunately relies upon rather heavily. However, in general the "security" provided by NIF/ZA is pretty much an illusion, though it makes end users feel good. You really need lower-level OS support to build a "secure" environment like this.
Mostly, the point of NIF/ZA is to make the sort of people that read Maximum PC and impress people with their framerates in FPSes feel that their system is "secure".
You know, not to say that your CEO is doing this, but despite the fact that Jobs drew $1 salary for two years at Apple (and trumpeted that fact around quite a bit), he didn't make a big deal of the the millions of dollars in options *or* the LearJet that the company gave him over that time period.
What did the CEO do that is so special that it creates his/her expectation of 6-figure salaries with use of company assets and a golden parachute regardless of the time of year?
Uh...he expects it because he negotiated said deal when he was getting hired. If you feel that you can negotiate similar perks, go for it.
Are they that much better educated or hard working? Probably not. Are they really that good of a manager? Probably not. It's hard not to be lazy when you have a staff of assistants and your leather chair and hardwood desk are so comfy after that prime rib lunch today...
Whether or not CEOs deserve their pay is up to debate (I suspect they don't, and that the reason that they get paid so highly is because they frequently know/are friends with members of the board). However, that has nothing to do with expectations *after* their contract is signed.
I don't buy the whole "times are tough" bullshit when stuff like this goes on. I'm talking about hooking people up with less than a $1000 to show some appreciation for those who stick around and put up with company politics, backstabbing, and egos.
"I deserve extra because I worked here and interacted with people." What?
Use it as a voodoo doll and stick pins in the wretched thing!
This kind of statement, "funny" though it may be, is a pretty good reflection of the current (IMHO stupid) feelings of a lot of people on Slashdot, judging from their comments.
A bonus is a special reward -- an employee did something really exceptional and their employer wanted to show their appreciation.
A bonus is *not* something that an employer is required or expected to give to an employee. If you wanted more *salary*, you should have negotiated it.
I'm not sure at what point workers started feeling that they were "entitled" to this gift. A Christmas bonus is a nice idea, but it certainly isn't something guaranteed. And, readers, if you're relying on it to support your finances around Christmas time, harsh as this may sound, you deserve whatever's coming. It's time for some actual financial management.
Blizzard's support of Linux gamers is better than Bioware's
AHAHAHAHAHAHAHA! That's a keeper.
None of them have a working game for Linux
I suppose you're too uninformed to be aware of the Linux dedicated server that Bioware has had out for NWN.
We'll be generous and assume that you were just talking about the client. One has put plenty of effort and risk into writing Linux based code and is about to release a supported Linux client. The other has repeatedly stated flat out that they will not support Linux, that there is no money in the Linux market, and has attacked an open-source server project (bnetd). You must be using some rather original reasoning to reach your conclusion s.
Incidentally, the sound system used by NWN has been ported to Linux by Sam Lantinga -- currently a Blizzard employee
Again, it seems that you don't know what you're talking about, but I'll make it simple. SL is a great guy, and has been doing Linux gaming work for ages, well before he worked for Blizzard or anyone. He was actually *paid* by Loki. Blizzard, on the other hand, hasn't put a single cent into supporting Linux, and is not supporting SL in his work. About the only thing you can say in their favor is that they aren't threatening to fire him or something for doing what coding he wants to do in his free time, which is a pretty pathetic endorsement.
Blizzard is about as solidly anti-Linux as an entertainment dev house can get, and Bioware is one of the few companies that's taken some risk to support Linux users. Your comment is both uninformed and out of line.
I remember World of Xeen running about $75 for the Mac, and a couple of the "interactive movie" titles in the days when "multimedia" was a big deal running upwards of $60.
I utterly agree about the late adopter model. Buy a game later and you get better prices, a better community, a game with the bugs fixed...
There will, for the forseeable future, be separate console and computer markets.
consoles: * simple, easy, good for Joe Average * efficiently built -- you can make 'em cheap * good game-playing controllers
computers: * Much more flexible -- there's only a small market for people that really like tweaking/playing with the guts of their games, but it'll always be there * Good general-purpose input peripherals. The mouse is still utterly unbeaten by console controllers -- Halo's weakest point, for instance, is *easily* the controller and the dreadfully slow turn rate. * Currently better network connections. I expect this will change rapidly -- A cable ISP would *much* rather service idiot-proof boxes that people only use to do low-bandwidth gaming than a service swamped by Kazaa users. * Much better resolution. This is likely to stay around for some time -- TV monitor resolutions suck, and suck badly. I particularly hate split-screen console games, with only 200 pixels or so vertically.
Just as an aside, I've never really enjoyed the core line of Mario games all that much. Mario Kart was okay, but it isn't *that* good. A huge number of people seem to absolutely love them.
They just don't seem to measure up to some of Nintendo's other offerings, like the Metroid or Zelda series.
I'd just like to say that the amount of benefit that Sam Latinga has brought the Linux community is incredible. He did SDL, and released it freely. He did a few support libraries, and released them freely. He worked with Loki to port commercial games, and even now that he's working at the ever-so-nasty-and-Linux-hating Blizzard, he's still churning out good stuff.
This is a *Linux* program and you're advising against using it because it doesn't work properly...on your *BSD* box! Did you ever consider the far-more-likely possibility that it's a *BSD* issue -- improperly emulating the Linux environment -- instead of a NWN issue?
If you wanted things working out of box (you "don't wish to spend an hour tweaking stuff") and you purchased a *Linux* program, for God's sake, *use Linux*.
just ship the lib with your package and link your app with it
That's why I said it's not an issue for commercial game developers -- they have a "frozen" copy that goes out on a CD anyway (so stuff is going to "get out of date" anyway)...and the package size of the software isn't really an issue. If you have an open source project on, say, sourceforge, it is.
This hits particularly close to home for me -- I developed a Linux game for a class this semester, and one thing I had to throw out was 3d audio, because there's piss-poor 3d audio support on Linux. Don't get me wrong -- I love Linux, and chose not to work on Windows -- but I had to throw out a feature that would have been relatively easy to do with DirectX.
The entire state of Linux sound support is somewhere between "bad" and "pathetic". Let's take a look:
* Sound servers. Sound servers are essentially the currently accepted way to do sound mixing on the local host. They are, however, simply awful from a performance standpoint -- high latency, CPU overhead, and inability to take advantage of hardware mixing capabilities are pretty much showstoppers.
Esd is probably the best general-purpose Linux sound server. It has an ugly hack for "giving up" the sound device -- a simple time delay. It's very inefficient and blows CPU time, and adds latency. The quality of its resampling sucks. It has notoriously poorly written internals, and the author (and maintainer) has been out of the picture for years. The GNOME Project adopted esd, but has done very little work on it.
Artsd is, impressively, even worse than esd. It is *extremely* heavyweight in RAM and CPU usage. It's a pain to get it to give up the audio device. It's even slower, and as most distros I've seen don't nice it to a negative value, it's frequently the cause of audio breakups. One of the ugliest parts of KDE, and a very ugly wart to new Linux users.
The only legitimate reason to have sound servers is to do network-transparent sound. And while I frequently use network-transparent graphics, I and the vast majority of people simply do not care about network transparent sound (other than beeps, which X does nicely). You can't reasonably stream a decoded sound stream over the network with sane performance.
Sound servers should be *much* less common than they are now. They give Linux awful media performance, are confusing to new users, and have almost no utility to most users.
* OSS/Free
OSS/Free is, well, free. It's also fairly reliable and simple. That's about it. It has only supports common sound cards. It doesn't do cards that require NDA, supports essentially no advanced features (wavetable MIDI, hardware mixing, bass/treble/reverb/etc on the DSPs). It doesn't manage sound requests at *all* -- basically, if you've got the device, you've got it, and if you don't have the device, you don't have it. End of story. The vast majority of Linux installations are still using OSS/Free.
* OSS/Linux Supports some less common sound cards, since it can use information released only under NDA. Costs money, so very very few people use it. Fixes some of the failures of OSS/Free (like a lack of hardware mixing), but the pricetag pretty much kills it as a general solution. If you're doing hardware mixing, but all the channels on the card are currently being used, this thing simply fails. There's no "software mixing" fallback that starts being used if all the existing hardware channels are being occupied.
* ALSA This is The Future. It has good support for many modern features. *Still* does not support major features for which commercial documentation is available for -- no treble and no bass on my SB Live, for instance. More than a little complex to set up, though most distros have patched over the ugly installation process by giving you a GUI that autogenerates necessary files. Supports hardware mixing, but again has *no software fallback* (which the ALSA coders have specifically said they will not support). I can't have an 8 channel soundcard, play 8 sounds at once, and then have the next sound be mixed in hardware. Half of the software out there is written to the incompatible and obsolete version.5 API instead of the.9 API. This is the best bet if you're willing to do some work -- xmms actually now has an ALSA plugin that *works*.
* Linux kernel SB driver If you have an SB-compatible soundcard, you can probably use this. It has somewhat less than convenient hardware mixing support -- the series of dsp devices, each of which can only have a single program attached, may be technically accurate, but is incredibly annoying to use -- you have to arrange your applications to share your DSPs (in my case, only two -- and I wanted to be able to play snes games, play mp3s, and still get ICQ sounds.
Creative Opensource drivers: Not pre-installed, so essentially not acceptable for a newbie. Even though this is from Creative, incredibly enough, it does not do MIDI synth OR have bass/treble/reverb/etc support.
I've poked around with the sound system on my box for quite some time, and have worked with a number of sound cards -- at the moment I have multiple ones installed. I'm fairly disappointed with the piss-poor functionality that users can expect from their audio hardware under Linux.
I can not justify spending double for a product that yeilds a diff less than 365kb
That's silly. If you were really so cash-strapped that this was an issue, why do you have a machine capable of *running* the "latest and greatest"?
Most of the time, I've seen people that trail releases by about 12 months are the happiest. They get the bug-fixed copies on *release* (i.e. no corrupted saved games 30 hrs into a game), good performance on a computer that doesn't cost an arm and a leg, better community support (fan websites are up, mods made, walkthroughs done, etc), and sometimes better prices.
OpenAL is cool (the only way I know of to get 3d panning sound mixed in hardware on Linux), but nobody has the thing installed.
May not be an issue for commercial game vendors like Bioware, but it's a pain in the ass for open source types who would like to have its features available.
I have not been paying a particularly significant amount of attention to DivX's legal issues. However, my rough understanding was that the very first DivX release was a modified version of a leaked copy of MS's MPEG4 decoder implementation. I think the major change was allowing MPEG4 streams to be stored in.AVI files, not just.ASF. This was DivX version 3.11a.
Since then, Project Mayo (aka OpenDivx) was formed, and built an open source (legal, at least from a copyright infringement standpoint) DivX codec.
Project Mayo went closed source and became DivXNetworks, and a closed source DivX4 codec was released. They also did DivX5.
XviD is the open source fork of the Mayo codebase. The mplayer people are fanatical about XviD -- I've seen quite a bit of XviD pimping there.
So both the current DivXNetworks and XviD implementations should be kosher from a copyright point of view, and one is even open source.
It wouldn't surprise me if coders on one or both projects looked at disassembly from the original codec, so there could be argument about a lack of clean-room implementation (which is a *bitch* to do properly). However, in general, if XviD or DivXNetworks's implementations were used, I think that copyright infringement issues are not an issue.
That does, however, ignore the issue of patents. I'm not sure about the legal status of this code. I know that commercial implementations of MPEG4 (which DivX was originally based on) have some patent claims impacting them, so you can't run out and just make an MPEG4 implementation.
I'm not sure whether these still affect DivX. I would suspect that the DivX implementors at least gave it a thought, but given the fact that DivX is primarily used for pirated movies, they may not have dug too deeply.
If I were going to found a product based on DivX code, I'd want to be *damn* clear about the legal status of DivX as regards patents.
I've never understood why people can't get comfortable with dial-up. At the moment, I'm using a pretty high-speed 10Mbps connection to the Internet. Next week, I'll be on a 56k connection. I transition pretty seamlessly.
There's a bit more latency on the modem, which I could see as an issue if you ssh a lot (thought ISDN wipes that out and you don't seem to go for ISDN), but web browsing on a 56k modem is *fine*. You *do* need to have multiple windows loading while you're browsing instead of click-wait-load but I do that anyway...
Slashdot Mirror
one of your points, ZoneAlarm (at least) does checksum all the apps and compares them when they request a connection.
Wow, I would have thought that that would have been prohibitively expensive performancewise, which is why I would assume that only a "trusted OS" would do that. Interesting. So I'd assume (since Google fails to turn up a detailed whitepaper on the first few hits) that ZA MD5s the binary at the first socket access the app tries during an invocation (it certainly can't be every time the app tries to do something, or performance would be completely unbearable).
But you really don't have to go to all this work. Copy (or contain) a copy of a trusted binary. Drop it into a directory somewhere. Drop a modified msvcrt.dll in the same directory, and let the program link to said DLL, and you've easily got untrusted code running within your "trusted" application.
Frankly, as long as the OS doesn't have pretty low level support for this, you're going to be able to bypass it.
I wonder what ZA could do to fix this? MD5summing linked to DLLs would be kind of expensive, and wouldn't work at all if there was application-initiated (rather than load-time OS-initiated) dynamic linking going on. I guess you could do that, take the performance hit...then ZA could hook LoadLibrary() and handle application-initiated linking....
Still, as you and I mentioned, the monolithic design of IE, providing application-level services and using components left and right, is pretty much an unstoppable impediment to securing a Windows-based system.
Generally, yes. And if the service was bad (I remember a notable case of a platter of spaghetti being spilled all over, for example), no.
The analogy isn't entirely accurate, either. Wrkers aren't really paid enough without their tips. The tips likely form a majority of their pay. The business model essentially dictates that a portion of your bill is simply paid differently. This is not the case for regular employees expecting a Christmas bonus -- if that Christmas bonus is comprising the majority of their pay, something is seriously unusual.
No one needs 65M a year, and taking that much for herself just shows he's not as loyal to the company as she should be to be the CEO.
"Loyalty to a company" in just about any company over fifty people or so is a sweet-sounding nonexistant Grail. It's lovely material to feed a worker to make him more productive, but it's silly. The company has no particular loyalty to you -- to HR, you're just another statistic that might potentially be sucking down money, and if you ever become a liability instead of an asset (after, of course, factoring in the cost of firing you and the effects on your coworkers of doing so, and considering your future potential value), the company will drop you like a hot potato. The company has no loyalty to you -- why should you to it?
Now, that doesn't mean that justifies things like stealing from the company or trying to shaft it (as some people seem to feel) -- things like this frequently come back and hurt you far worse than any possible benefit. However, whenever you get stuck in your head that the company you work at is a kind, loving father or something, instead of a cold, profit-seeking institution, you're running the risk of painful dillusionment.
I see people post here ever so frequently that "I gave 80 hours a week of work to my company and they didn't give me anything back" or "Times are tight, so my company is firing because it's best for all of us, but they really don't want to fire me". Bad mental state to be in. Don't come to rely on your company for more than they signed on for in your contract, and you won't have any nasty surprises.
This wasn't all aimed at you, more of a general feeling towards Slashdotters complaining that they didn't get what they expected...
Whilst that's something that iptables/chains just can't cope with (sadly) I have Norton Internet Firewall, for my remaining Windows PC, which is application based. ie, you can accept/deny any connection for each application.
:-) )
I believe you refer to process name matching, which was added to iptables-1.2.7.
Of course, iptables doesn't have a pretty GUI interface like NIF, but there are plenty of people that have made front ends for it.
I don't like the approach much, as there are lots of ways for a programmer to get around it -- I mean, process name/(application name under Windows) is not some immutable thing, and worst case, the program copies itself to a file of a different name and executes itself.
I suppose if the OS's loader SHA-fingerprinted binaries at load time (expensive, but secure) and granted rights based on said SHAsum, you might manage to securely pull something off like this. Then said application couldn't support "components" or plugins, as MSIE unfortunately relies upon rather heavily. However, in general the "security" provided by NIF/ZA is pretty much an illusion, though it makes end users feel good. You really need lower-level OS support to build a "secure" environment like this.
Mostly, the point of NIF/ZA is to make the sort of people that read Maximum PC and impress people with their framerates in FPSes feel that their system is "secure".
No insult intended...(see "mostly"
But, yes I would stay with $45M over $65M.
It sure is easy to say, isn't it?
What on God's green earth do you donate a cow to? An African charity or something?
Instead, one of my vendors (a Sun reseller) is taking us out on a cruise around Manhattan island. Now *THAT'S* nice!
God, I hate corporate corruption.
And I'm sure this won't influence buying decisions at all...
You know, not to say that your CEO is doing this, but despite the fact that Jobs drew $1 salary for two years at Apple (and trumpeted that fact around quite a bit), he didn't make a big deal of the the millions of dollars in options *or* the LearJet that the company gave him over that time period.
What did the CEO do that is so special that it creates his/her expectation of 6-figure salaries with use of company assets and a golden parachute regardless of the time of year?
Uh...he expects it because he negotiated said deal when he was getting hired. If you feel that you can negotiate similar perks, go for it.
Are they that much better educated or hard working? Probably not. Are they really that good of a manager? Probably not. It's hard not to be lazy when you have a staff of assistants and your leather chair and hardwood desk are so comfy after that prime rib lunch today...
Whether or not CEOs deserve their pay is up to debate (I suspect they don't, and that the reason that they get paid so highly is because they frequently know/are friends with members of the board). However, that has nothing to do with expectations *after* their contract is signed.
I don't buy the whole "times are tough" bullshit when stuff like this goes on. I'm talking about hooking people up with less than a $1000 to show some appreciation for those who stick around and put up with company politics, backstabbing, and egos.
"I deserve extra because I worked here and interacted with people." What?
Use it as a voodoo doll and stick pins in the wretched thing!
This kind of statement, "funny" though it may be, is a pretty good reflection of the current (IMHO stupid) feelings of a lot of people on Slashdot, judging from their comments.
A bonus is a special reward -- an employee did something really exceptional and their employer wanted to show their appreciation.
A bonus is *not* something that an employer is required or expected to give to an employee. If you wanted more *salary*, you should have negotiated it.
I'm not sure at what point workers started feeling that they were "entitled" to this gift. A Christmas bonus is a nice idea, but it certainly isn't something guaranteed. And, readers, if you're relying on it to support your finances around Christmas time, harsh as this may sound, you deserve whatever's coming. It's time for some actual financial management.
Blizzard's support of Linux gamers is better than Bioware's
AHAHAHAHAHAHAHA! That's a keeper.
None of them have a working game for Linux
I suppose you're too uninformed to be aware of the Linux dedicated server that Bioware has had out for NWN.
We'll be generous and assume that you were just talking about the client. One has put plenty of effort and risk into writing Linux based code and is about to release a supported Linux client. The other has repeatedly stated flat out that they will not support Linux, that there is no money in the Linux market, and has attacked an open-source server project (bnetd). You must be using some rather original reasoning to reach your conclusion s.
Incidentally, the sound system used by NWN has been ported to Linux by Sam Lantinga -- currently a Blizzard employee
Again, it seems that you don't know what you're talking about, but I'll make it simple. SL is a great guy, and has been doing Linux gaming work for ages, well before he worked for Blizzard or anyone. He was actually *paid* by Loki. Blizzard, on the other hand, hasn't put a single cent into supporting Linux, and is not supporting SL in his work. About the only thing you can say in their favor is that they aren't threatening to fire him or something for doing what coding he wants to do in his free time, which is a pretty pathetic endorsement.
Blizzard is about as solidly anti-Linux as an entertainment dev house can get, and Bioware is one of the few companies that's taken some risk to support Linux users. Your comment is both uninformed and out of line.
I remember World of Xeen running about $75 for the Mac, and a couple of the "interactive movie" titles in the days when "multimedia" was a big deal running upwards of $60.
I utterly agree about the late adopter model. Buy a game later and you get better prices, a better community, a game with the bugs fixed...
There will, for the forseeable future, be separate console and computer markets.
consoles:
* simple, easy, good for Joe Average
* efficiently built -- you can make 'em cheap
* good game-playing controllers
computers:
* Much more flexible -- there's only a small market for people that really like tweaking/playing with the guts of their games, but it'll always be there
* Good general-purpose input peripherals. The mouse is still utterly unbeaten by console controllers -- Halo's weakest point, for instance, is *easily* the controller and the dreadfully slow turn rate.
* Currently better network connections. I expect this will change rapidly -- A cable ISP would *much* rather service idiot-proof boxes that people only use to do low-bandwidth gaming than a service swamped by Kazaa users.
* Much better resolution. This is likely to stay around for some time -- TV monitor resolutions suck, and suck badly. I particularly hate split-screen console games, with only 200 pixels or so vertically.
Just as an aside, I've never really enjoyed the core line of Mario games all that much. Mario Kart was okay, but it isn't *that* good. A huge number of people seem to absolutely love them.
They just don't seem to measure up to some of Nintendo's other offerings, like the Metroid or Zelda series.
Don't be an idiot -- do you prefer the Linux support (or complete lack thereof) from some other game companies, like Blizzard?
I'd just like to say that the amount of benefit that Sam Latinga has brought the Linux community is incredible. He did SDL, and released it freely. He did a few support libraries, and released them freely. He worked with Loki to port commercial games, and even now that he's working at the ever-so-nasty-and-Linux-hating Blizzard, he's still churning out good stuff.
A hearty thanks from us all!
This is a *Linux* program and you're advising against using it because it doesn't work properly...on your *BSD* box! Did you ever consider the far-more-likely possibility that it's a *BSD* issue -- improperly emulating the Linux environment -- instead of a NWN issue?
If you wanted things working out of box (you "don't wish to spend an hour tweaking stuff") and you purchased a *Linux* program, for God's sake, *use Linux*.
just ship the lib with your package and link your app with it
That's why I said it's not an issue for commercial game developers -- they have a "frozen" copy that goes out on a CD anyway (so stuff is going to "get out of date" anyway)...and the package size of the software isn't really an issue. If you have an open source project on, say, sourceforge, it is.
This hits particularly close to home for me -- I developed a Linux game for a class this semester, and one thing I had to throw out was 3d audio, because there's piss-poor 3d audio support on Linux. Don't get me wrong -- I love Linux, and chose not to work on Windows -- but I had to throw out a feature that would have been relatively easy to do with DirectX.
.5 API instead of the .9 API. This is the best bet if you're willing to do some work -- xmms actually now has an ALSA plugin that *works*.
The entire state of Linux sound support is somewhere between "bad" and "pathetic". Let's take a look:
* Sound servers. Sound servers are essentially the currently accepted way to do sound mixing on the local host. They are, however, simply awful from a performance standpoint -- high latency, CPU overhead, and inability to take advantage of hardware mixing capabilities are pretty much showstoppers.
Esd is probably the best general-purpose Linux sound server. It has an ugly hack for "giving up" the sound device -- a simple time delay. It's very inefficient and blows CPU time, and adds latency. The quality of its resampling sucks. It has notoriously poorly written internals, and the author (and maintainer) has been out of the picture for years. The GNOME Project adopted esd, but has done very little work on it.
Artsd is, impressively, even worse than esd. It is *extremely* heavyweight in RAM and CPU usage. It's a pain to get it to give up the audio device. It's even slower, and as most distros I've seen don't nice it to a negative value, it's frequently the cause of audio breakups. One of the ugliest parts of KDE, and a very ugly wart to new Linux users.
The only legitimate reason to have sound servers is to do network-transparent sound. And while I frequently use network-transparent graphics, I and the vast majority of people simply do not care about network transparent sound (other than beeps, which X does nicely). You can't reasonably stream a decoded sound stream over the network with sane performance.
Sound servers should be *much* less common than they are now. They give Linux awful media performance, are confusing to new users, and have almost no utility to most users.
* OSS/Free
OSS/Free is, well, free. It's also fairly reliable and simple. That's about it. It has only supports common sound cards. It doesn't do cards that require NDA, supports essentially no advanced features (wavetable MIDI, hardware mixing, bass/treble/reverb/etc on the DSPs). It doesn't manage sound requests at *all* -- basically, if you've got the device, you've got it, and if you don't have the device, you don't have it. End of story. The vast majority of Linux installations are still using OSS/Free.
* OSS/Linux
Supports some less common sound cards, since it can use information released only under NDA. Costs money, so very very few people use it. Fixes some of the failures of OSS/Free (like a lack of hardware mixing), but the pricetag pretty much kills it as a general solution. If you're doing hardware mixing, but all the channels on the card are currently being used, this thing simply fails. There's no "software mixing" fallback that starts being used if all the existing hardware channels are being occupied.
* ALSA
This is The Future. It has good support for many modern features. *Still* does not support major features for which commercial documentation is available for -- no treble and no bass on my SB Live, for instance. More than a little complex to set up, though most distros have patched over the ugly installation process by giving you a GUI that autogenerates necessary files. Supports hardware mixing, but again has *no software fallback* (which the ALSA coders have specifically said they will not support). I can't have an 8 channel soundcard, play 8 sounds at once, and then have the next sound be mixed in hardware. Half of the software out there is written to the incompatible and obsolete version
* Linux kernel SB driver
If you have an SB-compatible soundcard, you can probably use this. It has somewhat less than convenient hardware mixing support -- the series of dsp devices, each of which can only have a single program attached, may be technically accurate, but is incredibly annoying to use -- you have to arrange your applications to share your DSPs (in my case, only two -- and I wanted to be able to play snes games, play mp3s, and still get ICQ sounds.
Creative Opensource drivers:
Not pre-installed, so essentially not acceptable for a newbie. Even though this is from Creative, incredibly enough, it does not do MIDI synth OR have bass/treble/reverb/etc support.
I've poked around with the sound system on my box for quite some time, and have worked with a number of sound cards -- at the moment I have multiple ones installed. I'm fairly disappointed with the piss-poor functionality that users can expect from their audio hardware under Linux.
I can not justify spending double for a product that yeilds a diff less than 365kb
That's silly. If you were really so cash-strapped that this was an issue, why do you have a machine capable of *running* the "latest and greatest"?
Most of the time, I've seen people that trail releases by about 12 months are the happiest. They get the bug-fixed copies on *release* (i.e. no corrupted saved games 30 hrs into a game), good performance on a computer that doesn't cost an arm and a leg, better community support (fan websites are up, mods made, walkthroughs done, etc), and sometimes better prices.
OpenAL is cool (the only way I know of to get 3d panning sound mixed in hardware on Linux), but nobody has the thing installed.
May not be an issue for commercial game vendors like Bioware, but it's a pain in the ass for open source types who would like to have its features available.
I have not been paying a particularly significant amount of attention to DivX's legal issues. However, my rough understanding was that the very first DivX release was a modified version of a leaked copy of MS's MPEG4 decoder implementation. I think the major change was allowing MPEG4 streams to be stored in .AVI files, not just .ASF. This was DivX version 3.11a.
Since then, Project Mayo (aka OpenDivx) was formed, and built an open source (legal, at least from a copyright infringement standpoint) DivX codec.
Project Mayo went closed source and became DivXNetworks, and a closed source DivX4 codec was released. They also did DivX5.
XviD is the open source fork of the Mayo codebase. The mplayer people are fanatical about XviD -- I've seen quite a bit of XviD pimping there.
So both the current DivXNetworks and XviD implementations should be kosher from a copyright point of view, and one is even open source.
It wouldn't surprise me if coders on one or both projects looked at disassembly from the original codec, so there could be argument about a lack of clean-room implementation (which is a *bitch* to do properly). However, in general, if XviD or DivXNetworks's implementations were used, I think that copyright infringement issues are not an issue.
That does, however, ignore the issue of patents. I'm not sure about the legal status of this code. I know that commercial implementations of MPEG4 (which DivX was originally based on) have some patent claims impacting them, so you can't run out and just make an MPEG4 implementation.
I'm not sure whether these still affect DivX. I would suspect that the DivX implementors at least gave it a thought, but given the fact that DivX is primarily used for pirated movies, they may not have dug too deeply.
If I were going to found a product based on DivX code, I'd want to be *damn* clear about the legal status of DivX as regards patents.
I've never understood why people can't get comfortable with dial-up. At the moment, I'm using a pretty high-speed 10Mbps connection to the Internet. Next week, I'll be on a 56k connection. I transition pretty seamlessly.
There's a bit more latency on the modem, which I could see as an issue if you ssh a lot (thought ISDN wipes that out and you don't seem to go for ISDN), but web browsing on a 56k modem is *fine*. You *do* need to have multiple windows loading while you're browsing instead of click-wait-load but I do that anyway...
Slashdot needs to use "802.11b" instead of "WiFi" so that people can understand what others are talking about.
Be an *exact* explanation of the problem.
If they're using squid, they can recompile and tell it to not use the internal resolver...otherwise, it'll ignore searchdomains.