There's as many things that can go wrong with a Windows install as there is with a Linux install these days with a game. These days, it's actually rather easy to get a game going under Linux- in fact, with the good hardware (which, by the way, happens to largely be the same on both OSes...) you're going to get no major issues with a Linux game whatsoever. However, you've got one other thing that seems to be an issue with Windows (XP in particular) that doesn't seem to be so with Linux on the same hardware.
The PCI latencies can be off (That's a VERY common thing in Windows)- it can throw the OS or the app completely off, causing stuttering in sound or skipped frames with the video. Doesn't seem to happen on Linux based setups on the same hardware, but under XP, it does bizarre things with your applications.
Suffice it to say, basing the current state of affairs off of what they were a year or two ago is making an error in that you're operating off of old info.
I DO work in the games industry as a consultant/contractor. My current moonlight gig happens to be Linux Game Publishing. Michael Simms isn't an idiot by any stretch of the imagination. And, I do know for a fact that Id's not ran by idiots nor is Epic. The remainder may be up for debate, but the generalization's pretty much wrong.
Id doesn't take an extra six months because of that. Epic doesn't take an extra six months because of that.
It all depends on the quality of the developers- if it's going to take an extra six months to come out, you may want to wonder about the quality of the code coming from the game company at that point.
Couldn't have put it better myself. You missed one other option, though- buy the games that are natively available for Linux, such as Neverwinter Nights, UT2k3, DooM 3, Majesty, Ballistics (Yes, I know it's not available yet, but it's in beta right now...), Bandits, etc.
More games purchased means showing that there is an actual market there. In the case of buying LGP published titles, it means we can afford to buy the rights to more titles to be produced.
Uh, then why do we have UT2k3, Ballistics, Heavy Gear, Descent3 and others on the way? All of those games happen to be DirectX games. Unless they wove DirectX throughout the ENTIRE game engine code (not bloody likely from what I've seen in the past from other game companies), DirectX doesn't preclude at least an x86 version for Linux.
Now, having said that, Valve has a tight relationship with MS. It's not likely that there will be a port because of that reason, but not for the reason you state.
None are equivalent to the speed and power of DirectX. Hate Microsoft all you want, but that's just something you have to cede at this point in time. Why don't YOU do "research" before spouting off and insulting people for giving their opinions on the poor state of Linux gaming development?
Speed and power?
Obviously you've not done your research.
The code for replacing DirectPlay (one of the many libraries in the DirectX framework) with OpenPlay is actually simpler and produces smaller code. How is that powerful? The resultant code is no slower than the DirectPlay code that we can tell. How is that faster?
I know these things because I just recently did the work to port the network code for Ballistics over from Windows to Linux.
Unless you have done the work in both worlds, how do you know that it's faster or more powerful?
You don't.
I suggest that you speak from real experience next time.
It's a complex of several different ones accessable under COM calls to the same. Microsoft markets the thing as one unified thing, but it's more akin to the multiple libraries- much more than most people think.
Carbon doesn't provide 3D. OpenGL does. Carbon doesn't provide Networking. OpenTransport/OpenPlay/NetSprockets does.
Carbon only provides input layer code.
Once you port to Linux, you already have the makings of a MacOS X game since the code uses OpenGL and either Activision's ActiveNet (LGPL) or OpenPlay/NetSprockets (Apple's public license). SDL handles the input layer issues.
Mike Phillips just provided the patches for the GPLed SoulRide that allow the game to compile for and run on MacOS X. They were a logical consequence of the clean-up work on the Linux version we're doing for the commercial release of the same.
We're pondering what to do with Ballistics and Bandits in the same regard- because it's a short hop over from the Linux version.
If they're abstracting the DirectX stuff, like most games seem to be doing (Well, some do a better job of it than others...:-) then it's a moderately simple matter of sliding in the changes to the abstraction layer to support the other platforms. Some of the code's warped because of DirectX, but unless they're doing some bog stupid things like thoroughly intermixing the DirectX code throughout the game engine code (Not likely, but possible), then a port is possible- if they're amenable to the act and willing to license the rights for a reasonable rate.
Loki didn't go out of business because there wasn't a market. Loki went out of business because the upper management was utterly clueless.
Scott bought some 50k units of those stupid tins, etc. and delayed the release of the Linux version (which SHOULD have went out only a week or so AFTER the Windows version) by nearly a month. Worse, he wasted the money on the massive production run when he should have done something more reasonable like 5k units to limit his losses. Had he done that, the margins per unit would have been smaller, but the game might have broke even.
Loki bit off more games than they could comfortably afford and did pathetically stupid business decisions with the ones they DID have.
I assure you, Linux Game Publishing, Hyperion, and others would be more than happy to help w/the testing, tuning, etc. with a game company. And we'd not be mis-managing the situation like Loki did.
They could have easily written the engine to use OpenGL as well as DirectX. It's that plain, that simple. I should know, Linux Game Publishing does this sort of thing on a regular basis.
A Handspring or earlier model Palm uses several design decisions that make them go a LONG time on the batteries that they have.
A Dragonball CPU consumes something around 20mA at full operation.
An ARM based CPU, say like one of the current X-Scales, recently popular in PPC's and now Palms consumes something along the lines of 275mA at full operation. While impressive, performance-wise, over the Dragonball, it DOES eat power a lot more aggressively (some 10x moreso...). To be sure, other ARM based CPUs such as the OMAP consume less power than this, but they DO consume a lot more than the Dragonball all the same (at the expense of being lower performers than the XScale model...).
Couple that with some other power consumptive design decisions like displays that, generally speaking, need a backlight and you eat batteries like candy.
It's why the early PDA's, including the early WinCE devices could get away with running on Alkalines or NiMH AA's or AAA's and now you have integral or removable Lithium-ion batteries as a requirement. I'm sure there are some PDA designs using an ARM that can go several hours with continuous operation, but most of them are weak in that arena. You're paying for the performance in operational span.
The ARTICLE said that they'd planned to go to market with a PDA with the specs you mentioned, but canned the idea before going there with it. The article itself didn't indicate what the specs were going to be for Royal's new attempt.
Now, having said this, they're going to be hard to believe since they backed down the first time. As to why they backed down, your guess is as good as mine- could be that the applications provided by Pixil wasn't good enough (Stock apps (and application availability in general) will make or break your PDA in the market- ask Franklin about the eBookman sometime...) or perhaps they determined that the overall design was too lacking compared to the Zaurus and the non-Linux based competition. Who knows for sure, except Royal?
I think that it's laughable that there's so many people on/. that think that Big Business has a handle on things any better than anyone else (Hello? Enron? Worldcom?).
Without all three aspects of a business, namely marketing/sales, engineering/production, and funding/capitalization, you're NOT going to get very far past the small partnership level (and even then you may not get there...).
EQUALLY valuable. Get that in your head- I don't care how, but etch/burn that permanantly into your mind.
Without marketing, you largely can't sell a product. Without engineering, you don't have a product to sell. Without funding (capitalization), you don't have money to do either of the above.
One without the others is like trying to set up a one or two-legged stool- just isn't going to work well. For a small business, you might get away with it, but for anything but a little partnership, you're going to need all THREE aspects of a business.
IBM's contributions are IBM's to give in the first place. SCO's claiming some pretty twisted contractual rights are being violated by the act in question- namely IBM giving pieces of their IP to the Linux community under GPL. A thorough reading of the evidence that SCO provides on their own website invalidates that claim- i.e. that SCO, through it's purchase of this and that has a control right over whether IBM may or may not give away it's IP.
The simplest way out is to not listen to SCO in the first place and wait and see what comes of ALL of this- the Red Hat filing and the IBM one.
On the 15th, SCO HAS to respond, come up with a fairly compelling reason for the court to allow another delay, or face a summary judgement. If they don't come up with something to counter Red Hat properly, they face a summary judgement.
Later in the month, they have to answer IBM under a similar set of circumstances.
Combine this with what we're all discussing, if ESR's little program works like it appears that it does- while ESR's grandstanding, it would very easily hurt their position with the Red Hat filing.
...lacking in good CHEAP hardware, along with DRM issues that always seem to get in the way of things more than they ought to.
Most of the excellent e-book readers ran $200-300 (including the top of the line eBookman when they weren't clearing them out- they're going for about $50-90 right now...)- and most of them weren't useful past being an e-book reader for THAT specific platform. You can get a PDA for that kind of cash (and Franklin was running the eBookman play that way- but sadly they went against an already entrenched market with somewhat weaker than average software that was buggy when they initially released the e-book reader...) and get similar results (though not quite as good as something like a hiebook).
A basic, capable e-book reader needs to be:
- Able to be read equally well in low light levels as well as high. - Able to go at least a couple of hours on a single set of batteries and use something like AAA or AA batteries. - Able to be easily portable - Have a DRM system that allows for behaviors like upgrading the unit, re-installing the books on a new unit that is a replacement for a damaged one, etc. (Franklin's DRM scheme fails on that last count- it's tied to the specific unit you're using. Lose the unit for any reason and you have to re-purchase apps and Franklin format e-books.) - Cost UNDER $100
The last item is what really, really is hurting e-books more than anything else. The second to last is the other one.
The kids in question shot at 25 cars with a.22 calibre rifle. In the state they were in, it'd be a common thing for a kid to actually OWN a.22 rifle- which is legal. Now, having said this, it's STILL the parent's responsibility to ensure that the kids do not misuse the weapon (It's allowed for the purposes of HUNTING...) and to watch what in the hell they're consuming in the form of magazines, movies, videogames, etc.
Suing the game company for their negligence is a sad sign of the times.
Much of what Transgaming is selling is proprietary. Perhaps legitimately so (like the copy protection support...)- but it is still closed source all the same. In some areas, they're ahead of WINE, in others, they're behind.
Keep these things in mind when you think about all of this, though...
They were going to only go after the stuff that wasn't getting active ports and actually encourage native porting work. They turned around and came up with that bastardized "port" of The Sims and Kohan- which had issues out of the box in both cases. The Sims WAS going to be a native app and Kohan WAS a native app that had lost the porting company (Timegate got the rights to the Loki port, but they didn't want to wait and find out it's fate- they went with Transgaming.).
They were going to only work at making Linux gaming possible. Now, they're making game "ports" for Windows and MacOS of console games, but NO Linux versions of the same.
RPC's are Remote procedure calls- they're technically IPC's, but they're over a network connection to a remote machine in most cases. DCOM would be an example. DCE RPC would be another, which is associated with Exchange servers and clients. Sockets would be yet another one.
All of which are used on MS products extensively.
IPC is difficult to exploit- but not impossible.
RPC is a lot easier to exploit- after all, that is how most exploits happen, it's through an RPC or communications channel over the network to a server of some sort.
It's debatable whether or not you need RPC on a desktop machine- higher risks. Most of the time, you install an RPC system on selected machines that need it and those machines are usually behind a firewall. Fortunately, most CORBA ORBs are designed with security in mind, so they're at less risk than most of the Microsoft product offerings. This doesn't, however, mean I'm 100% happy with the use of CORBA in GNOME because it still presents a risk that could have otherwise been avoided by way rolling an IPC or reusing one that was available at the time they chose CORBA.
No on all regards. The law prohibits this. So, if you can manage to be able to pass the investigation required for a Secret or better clearance, and you make the cut on the requirements for the positions they're looking for, you can get work that will not be outsourced any time soon.
Slashdot Mirror
There's as many things that can go wrong with a Windows install as there is with a Linux install these days with a game. These days, it's actually rather easy to get a game going under Linux- in fact, with the good hardware (which, by the way, happens to largely be the same on both OSes...) you're going to get no major issues with a Linux game whatsoever. However, you've got one other thing that seems to be an issue with Windows (XP in particular) that doesn't seem to be so with Linux on the same hardware.
The PCI latencies can be off (That's a VERY common thing in Windows)- it can throw the OS or the app completely off, causing stuttering in sound or skipped frames with the video. Doesn't seem to happen on Linux based setups on the same hardware, but under XP, it does bizarre things with your applications.
Suffice it to say, basing the current state of affairs off of what they were a year or two ago is making an error in that you're operating off of old info.
I DO work in the games industry as a consultant/contractor. My current moonlight gig happens to be Linux Game Publishing. Michael Simms isn't an idiot by any stretch of the imagination. And, I do know for a fact that Id's not ran by idiots nor is Epic. The remainder may be up for debate, but the generalization's pretty much wrong.
Id doesn't take an extra six months because of that.
Epic doesn't take an extra six months because of that.
It all depends on the quality of the developers- if it's going to take an extra six months to come out, you may want to wonder about the quality of the code coming from the game company at that point.
Couldn't have put it better myself. You missed one other option, though- buy the games that are natively available for Linux, such as Neverwinter Nights, UT2k3, DooM 3, Majesty, Ballistics (Yes, I know it's not available yet, but it's in beta right now...), Bandits, etc.
More games purchased means showing that there is an actual market there. In the case of buying LGP published titles, it means we can afford to buy the rights to more titles to be produced.
Uh, then why do we have UT2k3, Ballistics, Heavy Gear, Descent3 and others on the way? All of those games happen to be DirectX games. Unless they wove DirectX throughout the ENTIRE game engine code (not bloody likely from what I've seen in the past from other game companies), DirectX doesn't preclude at least an x86 version for Linux.
Now, having said that, Valve has a tight relationship with MS. It's not likely that there will be a port because of that reason, but not for the reason you state.
Actually, it's a recipe for SDL, OpenGL, OpenAL, and OpenPlay or ActiveNet.
Speed and power?
Obviously you've not done your research.
The code for replacing DirectPlay (one of the many libraries in the DirectX framework) with OpenPlay is actually simpler and produces smaller code. How is that powerful? The resultant code is no slower than the DirectPlay code that we can tell. How is that faster?
I know these things because I just recently did the work to port the network code for Ballistics over from Windows to Linux.
Unless you have done the work in both worlds, how do you know that it's faster or more powerful?
You don't.
I suggest that you speak from real experience next time.
It's a complex of several different ones accessable under COM calls to the same. Microsoft markets the thing as one unified thing, but it's more akin to the multiple libraries- much more than most people think.
OpenAL sits on Linux, Windows, and MacOS X. Unreal Tournament 2k3 uses it. America's Army:Operations uses it. Most Linux games use it.
There's a solution that actually makes sense that allows you to target all three OS platforms without much more effort than targeting Windows solely.
Carbon doesn't provide 3D. OpenGL does.
Carbon doesn't provide Networking. OpenTransport/OpenPlay/NetSprockets does.
Carbon only provides input layer code.
Once you port to Linux, you already have the makings of a MacOS X game since the code uses OpenGL and either Activision's ActiveNet (LGPL) or OpenPlay/NetSprockets (Apple's public license). SDL handles the input layer issues.
Mike Phillips just provided the patches for the GPLed SoulRide that allow the game to compile for and run on MacOS X. They were a logical consequence of the clean-up work on the Linux version we're doing for the commercial release of the same.
We're pondering what to do with Ballistics and Bandits in the same regard- because it's a short hop over from the Linux version.
If they're abstracting the DirectX stuff, like most games seem to be doing (Well, some do a better job of it than others... :-) then it's a moderately simple matter of sliding in the changes to the abstraction layer to support the other platforms. Some of the code's warped because of DirectX, but unless they're doing some bog stupid things like thoroughly intermixing the DirectX code throughout the game engine code (Not likely, but possible), then a port is possible- if they're amenable to the act and willing to license the rights for a reasonable rate.
Loki didn't go out of business because there wasn't a market. Loki went out of business because the upper management was utterly clueless.
Scott bought some 50k units of those stupid tins, etc. and delayed the release of the Linux version (which SHOULD have went out only a week or so AFTER the Windows version) by nearly a month. Worse, he wasted the money on the massive production run when he should have done something more reasonable like 5k units to limit his losses. Had he done that, the margins per unit would have been smaller, but the game might have broke even.
Loki bit off more games than they could comfortably afford and did pathetically stupid business decisions with the ones they DID have.
THAT is what killed Loki.
I assure you, Linux Game Publishing, Hyperion, and others would be more than happy to help w/the testing, tuning, etc. with a game company. And we'd not be mis-managing the situation like Loki did.
They could have easily written the engine to use OpenGL as well as DirectX. It's that plain, that simple. I should know, Linux Game Publishing does this sort of thing on a regular basis.
A Handspring or earlier model Palm uses several design decisions that make them go a LONG time on the batteries that they have.
A Dragonball CPU consumes something around 20mA at full operation.
An ARM based CPU, say like one of the current X-Scales, recently popular in PPC's and now Palms consumes something along the lines of 275mA at full operation. While impressive, performance-wise, over the Dragonball, it DOES eat power a lot more aggressively (some 10x moreso...). To be sure, other ARM based CPUs such as the OMAP consume less power than this, but they DO consume a lot more than the Dragonball all the same (at the expense of being lower performers than the XScale model...).
Couple that with some other power consumptive design decisions like displays that, generally speaking, need a backlight and you eat batteries like candy.
It's why the early PDA's, including the early WinCE devices could get away with running on Alkalines or NiMH AA's or AAA's and now you have integral or removable Lithium-ion batteries as a requirement. I'm sure there are some PDA designs using an ARM that can go several hours with continuous operation, but most of them are weak in that arena. You're paying for the performance in operational span.
The ARTICLE said that they'd planned to go to market with a PDA with the specs you mentioned, but canned the idea before going there with it. The article itself didn't indicate what the specs were going to be for Royal's new attempt.
Now, having said this, they're going to be hard to believe since they backed down the first time. As to why they backed down, your guess is as good as mine- could be that the applications provided by Pixil wasn't good enough (Stock apps (and application availability in general) will make or break your PDA in the market- ask Franklin about the eBookman sometime...) or perhaps they determined that the overall design was too lacking compared to the Zaurus and the non-Linux based competition. Who knows for sure, except Royal?
I think that it's laughable that there's so many people on /. that think that Big Business has a handle on things any better than anyone else (Hello? Enron? Worldcom?).
Without all three aspects of a business, namely marketing/sales, engineering/production, and funding/capitalization, you're NOT going to get very far past the small partnership level (and even then you may not get there...).
EQUALLY valuable. Get that in your head- I don't care how, but etch/burn that permanantly into your mind.
Without marketing, you largely can't sell a product.
Without engineering, you don't have a product to sell.
Without funding (capitalization), you don't have money to do either of the above.
One without the others is like trying to set up a one or two-legged stool- just isn't going to work well. For a small business, you might get away with it, but for anything but a little partnership, you're going to need all THREE aspects of a business.
IBM's contributions are IBM's to give in the first place. SCO's claiming some pretty twisted contractual rights are being violated by the act in question- namely IBM giving pieces of their IP to the Linux community under GPL. A thorough reading of the evidence that SCO provides on their own website invalidates that claim- i.e. that SCO, through it's purchase of this and that has a control right over whether IBM may or may not give away it's IP.
The simplest way out is to not listen to SCO in the first place and wait and see what comes of ALL of this- the Red Hat filing and the IBM one.
On the 15th, SCO HAS to respond, come up with a fairly compelling reason for the court to allow another delay, or face a summary judgement. If they don't come up with something to counter Red Hat properly, they face a summary judgement.
Later in the month, they have to answer IBM under a similar set of circumstances.
Combine this with what we're all discussing, if ESR's little program works like it appears that it does- while ESR's grandstanding, it would very easily hurt their position with the Red Hat filing.
...lacking in good CHEAP hardware, along with DRM issues that always seem to get in the way of things more than they ought to.
Most of the excellent e-book readers ran $200-300 (including the top of the line eBookman when they weren't clearing them out- they're going for about $50-90 right now...)- and most of them weren't useful past being an e-book reader for THAT specific platform. You can get a PDA for that kind of cash (and Franklin was running the eBookman play that way- but sadly they went against an already entrenched market with somewhat weaker than average software that was buggy when they initially released the e-book reader...) and get similar results (though not quite as good as something like a hiebook).
A basic, capable e-book reader needs to be:
- Able to be read equally well in low light levels as well as high.
- Able to go at least a couple of hours on a single set of batteries and use something like AAA or AA batteries.
- Able to be easily portable
- Have a DRM system that allows for behaviors like upgrading the unit, re-installing the books on a new unit that is a replacement for a damaged one, etc. (Franklin's DRM scheme fails on that last count- it's tied to the specific unit you're using. Lose the unit for any reason and you have to re-purchase apps and Franklin format e-books.)
- Cost UNDER $100
The last item is what really, really is hurting e-books more than anything else. The second to last is the other one.
The kids in question shot at 25 cars with a .22 calibre rifle. In the state they were in, it'd be a common thing for a kid to actually OWN a .22 rifle- which is legal. Now, having said this, it's STILL the parent's responsibility to ensure that the kids do not misuse the weapon (It's allowed for the purposes of HUNTING...) and to watch what in the hell they're consuming in the form of magazines, movies, videogames, etc.
Suing the game company for their negligence is a sad sign of the times.
Much of what we call "data" IS in the Public Domain.
What it seems that they're asking for is "Copyright" protection for all data, no matter WHERE it came from.
Much of what Transgaming is selling is proprietary. Perhaps legitimately so (like the copy protection support...)- but it is still closed source all the same. In some areas, they're ahead of WINE, in others, they're behind.
Keep these things in mind when you think about all of this, though...
They were going to only go after the stuff that wasn't getting active ports and actually encourage native porting work. They turned around and came up with that bastardized "port" of The Sims and Kohan- which had issues out of the box in both cases. The Sims WAS going to be a native app and Kohan WAS a native app that had lost the porting company (Timegate got the rights to the Loki port, but they didn't want to wait and find out it's fate- they went with Transgaming.).
They were going to only work at making Linux gaming possible. Now, they're making game "ports" for Windows and MacOS of console games, but NO Linux versions of the same.
Would YOU trust this bunch?
...which was Blaster's exploit.
RPC's are Remote procedure calls- they're technically IPC's, but they're over a network connection to a remote machine in most cases. DCOM would be an example. DCE RPC would be another, which is associated with Exchange servers and clients. Sockets would be yet another one.
All of which are used on MS products extensively.
IPC is difficult to exploit- but not impossible.
RPC is a lot easier to exploit- after all, that is how most exploits happen, it's through an RPC or communications channel over the network to a server of some sort.
It's debatable whether or not you need RPC on a desktop machine- higher risks. Most of the time, you install an RPC system on selected machines that need it and those machines are usually behind a firewall. Fortunately, most CORBA ORBs are designed with security in mind, so they're at less risk than most of the Microsoft product offerings. This doesn't, however, mean I'm 100% happy with the use of CORBA in GNOME because it still presents a risk that could have otherwise been avoided by way rolling an IPC or reusing one that was available at the time they chose CORBA.
No on all regards. The law prohibits this. So, if you can manage to be able to pass the investigation required for a Secret or better clearance, and you make the cut on the requirements for the positions they're looking for, you can get work that will not be outsourced any time soon.