First of all, good work Bioware on finally get something into our hands. . . . This is why we need API's like OpenGL, OpenAL, SDL and the likes. It makes things a lot easier to release on a multiple platforms.
And yet there is no Mac client, which is a platform that not only has the wonderful open technologies you mention, but also has a larger and more captive desktop game market than Linux does. Seems to me that their Linux support is more of a cover-your-ass move than any intelligent development decision that should be praised.
However, all of these primitives are not proven secure. How do you feel about cryptology being built on such a fragile foundation, essentially making it a house of cards?
Are you aware how amusing it is that you posted this question over a connection based on IP primitives?
They may not be able to break the encryption, but they sure as hell can break you.
Then it would be pointless to encrypt in the first place. If you're so weak willed that you'll give up the content (vis encryption key) before you give up your life, then your willingness to be tortured for that access accomplishes nothing.
Now I'm sure some will come to your defense and site a situation where encryption is used for non-life-or-death data, but then the logic breaks down there, too, because while you can encrypt all your email with GPG or the like, doing so without the resolve to meet any attack the encryption may face is an indicator of just how important the content is. For most, encryption is merely a "prying eyes" issue, not an "oh fuck; they've crippled me and may kill me (or jail me for contempt of court, for those dealing with more benign powers)" issue.
It's pretty obvious you can't copyright a length 1 bit string, so how many bits do you need before you own it and I don't?
Ah, a man after my own heart (sorry, I don't swing that way:-). This why I started a Data Fetish web site, to explore the nature of the beast that is binary representation. So the interesting followup question to your is: for what arbitrary encodings can you make a claim of ownership of data? Just because you could claim ownership of a certain binary string, do you get to claim ownership of its inverse and reverse? The gzip and uuencoding? How may transformations could something go through before it overlaps some binary string that someone else would claim ownership for? The courts haven't even begun to deal with the stickiness of the issue.
There have been a number of cases since 9-11 where would-be hijackings etc. have been stopped by the PASSENGERS. The equation is changed.
This is so true it isn't even funny. I have said to friends that the people who should really be pissed at the terrorists should be the other political groups that hijacked. Why 9/11 worked is because everyone expected a standard hijacking, were you'd be redirected and delayed for negotiations but had a high probability of survival. Now? Well, fuck, the assumption is that you're dead if you don't act. The whole "stay calm and everyone will be OK" line just won't work anymore.
Well I am glad the Internet architects were poser geeks or IP routers would have lookup tables with 2 billion entries.
You're looking at my comments the wrong way. Hierarchies often make things easier for computers, and that was necessary when a lot of the technology (networking and otherwise) was new. It's the same way a file hierarchy made sense for simple storage, but a database is usually a better choice when you want to deal with the actual properties of the data rather than their path. So the properties a domain might have are entity="commercial" and location="United Kingdom". Those could be abbreviated to co and uk respectively, and discarding the hierarchy would actually reduce the size of lookup tables because register.co.uk and register.uk.co (to say nothing of all the other combinations) would resolve to the same entry. The only tricky part is doing discovery without a hierarchy in place, but that could be addressed by associating a priority with a property.
Heirarchies are a Good Thing, as any geek should know.
Only a poser geek, really (based on moderation you received, we clearly have a lot of those on/.). Hierarchies are actually a very bad thing because they obscure information. That is, in fact, what this whole story is about!
The real situation is this: we have companies in the United Kingdom that want to be found on the Internet. The problem is that there are two actual hierarchies in place that could be the root under which to file such a domain, those being.com and.uk. Then there are the "off" hierarchies that get used not because of their geographical location as intended, but because their abbreviation corresponds to some common usage (.co being the case here).
So the hierarchy adds to the confusion of both the user and the company. The company has to figure out and register domains in whatever branch of the hierarchy the user may have wandered into, and the user never learns how addressing on the Internet is supposed to work and so they continue to wander around without aim. Elimination of the hierarchy would go a long way to clearing up the confusion and getting back to the simple idea of looking for, among other things, a company in the UK.
Of course, nobody should expect that to happen any time soon. Getting rid of the hierarchy means getting rid of the need to create new top-level domains and therefore eliminates that ICANN profit center.
Wow, I'd fire him immediately if I were his boss. He just opened up the company to massive litigation. It'd be akin to the phone company saying "we're going to monitor phone traffic and don't want common carrier status anymore". Moronic.
Thats one way to stop this stuff at work.
Stop what stuff? Creating a pleasant environment to do your job? There is nothing illegal about having music on your computer at home or at work.
Companies will take action and institute policies against downloading copywritten materials.
Of course, the only real way to do that is to shut off the Internet connection completely. There are very few things people access online that are actually in the public domain.
Ah, now you've gone and reminded me of my favorite interview moment. The manager sat smugly behind the desk and asked me the age old "What do you consider your greatest strength?" to which I promptly replied "I like to be wrong."
The look of horror on his face spoke volumes, both of what he no doubt thought of me, and of exactly why that wasn't the kind of company I'd want to work for. I couldn't get out the door fast enough, and he couldn't wait to see me go. So I highly suggest doing the "brimming over with wrongability" thing right off the bat.:-)
Running more than one app doesn't utilise multiple processors, as 99% of the time if you're not interacting with an application it's simply sitting in an event loop waiting for input.
As I pointed out, that is true for any common architecture. A single processor isn't used 99% of the time it waits on input. You're actually supporting my point when you start talking idle times (which is kinda why I brought it up:-).
How responsive the system feels has little to do with how many processors it has.
Tell that to anyone who has ever owned an Amiga, or currently owns an accelerated video card. Co-processing, in whatever form you can get it, puts in place an abstraction that you can potentially derive great benefit from. Alll I know is that when I run a single, compute-bound thread, I'm happy to have a second processor around that isn't getting hammered at 100%.
No, very few people have machines that constantly utilise their processor, but when they DO utilise it, they want it to be as fast as possible.
See, now here you have something that is testable. Burst processing can be an issue, but the question is whether or not it's an issue for you in reality. To test it, you can simply put a process in place (or mod the kernel to log similar) that snapshots when the system is at >98% (or whatever) CPU usage and for how long. Then you could reasonably determine how much of your burst potential you're actually using. Only if those stats support your point could you can reasonably say a PC would be a better choice than a Mac based on the CPU gap alone. Otherwise, you're just trying to start a pissing match for some unknown reason. For what is done on the desktop these days, the Mac is plenty fast.
This line is getting tired.
Then maybe PC people should shut up with their own bogus claims that Macs cost twice as much. As for claims of not wanting Firewire, how about me not wanting to shell out for a floppy drive or PS/2 port when I buy a PC? At least when Apple includes technology with their system, it isn't some shit I haven't used in 5 years. This coin has two sides, so why flip it?
If you are able to build machines yourself, why is that not as good as buying a machine from Apple?
Because then it isn't a parity comparison. Just because you've spent a lot of time and effort picking out and building a system for yourself (at some hourly rate which you will no doubt leave off of the bill for the cost of the PC) doesn't mean anyone who wants a computer can do the same. If you are so certain you can system build for the masses better than the likes of Dell, go into business and get rich. Now point me to the URL of a name brand that shows you can get a built PC that is on par with a Mac for half the price. Otherwise, it's you guys that have all the tired lines.
It apparently means you couldn't bother to educate yourself before posting. Here's a starter link: Mach Scheduling and Thread Interfaces. The long and short of it is that each process is run in a main thread that may start other threads, none of which are tied to a particular processor and all of which are given time slices at a priority. So if I have four things going at once, they (and any other threads they start up) will be pushed to whatever can handle them, and quitting two doesn't lead to a situation where one CPU is left at 100% and the other is idle.
No it isn't. How many multi-threaded programs have you written? It is nowhere near as simple as just creating a thread and setting it loose in a program that wasn't designed to be multi-threaded.
My guess is that I've written more than you, but I've used an API (Cocoa) that doesn't penalize me for the use of threads unless it has to. I'm sorry you're stuck with something less elegant, but I look forward to you writing a single OS X app and seeing what OpenStep made possible over a decade ago.
They don't just idle faster. They do work faster as well. Why would they just idle faster?
Because, as those who actually read my post saw, they are unlikely to be pegging the CPU at 100% even when they are in use. Do you think your word processor (unless it's a really crappy one) really needs 3GHz to keep up with your typing? Unless you're talking about something specialized like a render farm, your argument isn't valid. These are desktop systems, and being twice as fast as a Mac only means your computer is twice as wastefully idle as mine. I'd estimate that I'm hitting the burst limits of my system less that 1% of the time.
Further, if you are talking about something like a render farm then you will find that one of the abstractions provided by Cocoa for threads is called an NSConnection, which also allows the processing to abstract to another machine altogether! If you won't get a Mac for whatever reason, at least look into something like GNUstep so you can actually start taking advantage of the systems you already have.
... and even then you only get the horses if you're actually doing something that take advantage of SMP. Which most users don't. Ever.
You never run more than one app? Or are you saying that threading on the OS you'd use is screwed up? On Mac OS X, threading is done at the Mach level, and it is dynamically shifted between processors. For those situation where an app can take advantage of multiple threads, adding support to a Cocoa app can be simple call to an NSThread object. I've had single processes suck up 180% of the CPU while 40 other ones ran just fine on my box. Buying a 2x Mac is something I have not regretted, but thank you for letting me know it would be a regrettable thing to do if I ever upgrade my Linux server.
Are there applications for SMP? Sure. No question. But even most geeks who lust after SMP won't ever actually utilize it to the fullest.
The truth is that no CPU architecture that's popular is being used to the fullest. Computers are sitting idle 95+% of the time waiting for the user to do something. And the other 5-% is unlikely to be a burst that pegs usage at 100%. All those 3GHz Intel boxes aren't any faster really, they just idle faster; that's not something to brag about.
Frankly, for the price of the Dual G4 1.42 GHz I can buy more than 2 P4 3.06 GHz boxes, which is a much better solution for most cases.
Please point to a major manufacturer that offers two PCs that are similarly spec'd to the one Mac, with the addition of the high revving engine, for the same price. Note that being able to hobble parts together in your parent's basement doesn't make you a business on par with Apple.
While this wouldn't be so practical for work (except for maybe switching keyboard nationality at the press of a button), how badass would that be for gaming?
Actually, it may be extremely practical for work, just not in the way everyone (or even the manufacturers, apparent) thinks. I see this sort of thing as being really useful as an extra, programmable keyboard. I mean, I could honestly do without the keypad most of the time, and surely I'm not the only one who remember when software relied heavily on function key template maps. You could virtualize those things and, in fact, could provide a number of custom layouts for macros or toolbar items as well. Just in typing this reply, I can see the use of being able to call up a special HTML keyboard that would easily allow me to tag a selection (an <i> key, a <p> key, etc.). Really, these people should forget about the stagnant PDA market and focus on providing a virtualized interface for the desktop market.
Depending on these percentages, Mac vs. Linux could go either way.
I don't see how anyone could imagine the Linux game market is larger than the Mac game market, let alone enough larger to make up for the lack of similar market penetration. Linux simply isn't a player on the home desktop, regardless of how many desktops you run it on personally. It mainly sees work as a server and/or a semi-acceptable alternative in the corporate environment. Looking at that, you'd have to do a great deal of hand waving to even pretend that the game markets on both are even close. Some should be getting fired at Bioware over this, plain and simple.
Given that a full audit of all computers on the planet is not likely, I'm as sure as IDC is. Numbers can be cooked, and PC types love to cook Mac numbers, as though somehow making the Mac less significant makes their platform any better. Real world stats like the Google Zeitgeist still show Macs have four times the usage as Linux, and I would further guess that the Linux use comes more from a corporate setting than a home setting where a game purchase would be likely. Mac users are also used to paying for commercial software, whereas Linux user support is a bigger question mark. When all is said and done, I would guess the Mac game market is an order of magnitude larger than the Linux game market. Both are, of course, absolutely dwarfed by the Windows monopoly. Regardless, smart money would have done a Mac port first.
Probably not. However, it appears Bioware are pressing ahead (and doing it inhouse) because they are a games company that wants to be around in the long run, and stay one step ahead of its competitors.
That doesn't make sense. If it's a sink hole, they're less likely to be around for the long run. A company basically has to be moronic to put out a Linux client before a Mac client. Not only is the Mac market bigger (and captive; no ability to just boot Windows if they wanted to play), the support for OpenGL is more polished and it would give them a proving ground for their work.
That makes me think they value the experience and want to keep it internal to the company.
Odd, it makes me think the code is a damn mess that relies heavily on both Windows and x86 funk. You'd think these companies would have learned something from id when it came to creating games with a portable core. I predict you'll see DOOM 3 for Linux before you see NWN.
One problem with online games (a lot of online things these days) is that they usually demand and involved registration process before you can do anything worthwhile. I honestly don't have the inclination to register like that for every game that comes out just to find out it sucks (or, less likely, doesn't suck). Snowcrash had generic avatars, and Slashdot has ACs. Regardless of how much you favor or disfavor the idea, I know I wouldn't have spent much time on Slashdot at all if I didn't initially have a voice as an AC.
Actually, the eDonkey network (and I believe Overnet too) verify seperate chunks of the file as they're downloading.
That's only slightly better. You still have to download those bad chunks, though, so it only shifts the problem to being one of limited file sizes, with the tradeoff being validation, keeping, and moving around an even larger database of what the chunk checksums should be. Having multiple valid encodings of a file doesn't help, either.
This is a real system, really in place right now. I haven't downloaded a bad file (blank, bad rip, etc) since I switched. All you need is a trusted source of links.
That is the equivalent of "security through obscurity". Just because those networks haven't become a target of sabotage yet doesn't mean they won't become targets in the future. They are vulnerable, but just haven't been exploited yet. Any time "trust" enters into the picture, it's a bad thing. You have to assume that every transfer is via the man in the middle. Until P2P networks reach a level of maturity to deal with that, you will constantly find yourself switching to new ones to stay ahead of detection.
. . . you never have to download another bad file again.
Wow, the mods are as dense as you seem to be. All a checksum does it allow you to verify that a file matches a fingerprint of the file. It is a form of derived meta information. The problem with that is that your peer cannot be trusted in these cases, and can initially give out a checksum that does not actually match the file that will be served for the request. The only way would be to download it and run the checksum locally. This is to say nothing about knowing the validity of entries in a checksum repository. So, in fact, your "Yawn" solution essentially solves nothing.
Takes away the advantage of developing on a operating system with a rubust api.
What does that have to do with Microsoft?
But, seriously, Apple seemed to be able to bridge Java for their Cocoa API. The problem on Windows is Microsoft's wanting to control everything, not Java (aka, Sun wanting to control everything).
Why don't you try reading the comment? There is a difference between a trivial comment and a trivial relationship.
Sorry, but I did read the comment and wisely determined that any relationship based on "you don't need to think twice before messaging someone about something totally trivial" is itself trivial. The last thing I need are people messaging me shit like "I see kittens" or "It's raining" for no good reason; it's a form of spam as far as I'm concerned.
You can make a five second international phone call that a) conveys any information whatsoever and b) only costs 2 cents. I'm impressed.
We both know the example was as bogus as the response. The foundation of SMS isn't built on international messaging. There is seldom someone in some distant land that anyone needs to reach immediately by way of a telephone keypad. You'd make the sensible decision to wait the 15 minutes it took to get home or to work and use a proper keyboard to easily type what is likely an un-urgent message, or you'd pony up the dough if it was important.
Now tell us all the real reason you're defending SMS. You've offered no scenario that shows it actually offers an advantage compared to other methods of communication. Without that, your efforts just look silly.
No furtive and very annoying (to those around you) conversations, no cryptic number on a little tiny pager display.
These points have nothing to do with SMS, but reflect the class of the person receiving the message. I can bet you some prick with a text pager is still going to be disruptive and scream something like, "Guys, guys! Check out the message Bobby sent me!"
I can take it to the pub and not have to find a quiet place to hear messages. I have on more than one occasion been unable to receive an ordinary call because of ambient noise. SMS might have been very helpful.
People don't know where you are, so they can't know what the best method is to talk to you. What it sounds like you'd really prefer is something different: voice-to-text of your voice mail. That actually makes some sense, but I don't know of a single provider that does SMS with anything other than hunt and peck keypad entry.
Slashdot Mirror
First of all, good work Bioware on finally get something into our hands. . . . This is why we need API's like OpenGL, OpenAL, SDL and the likes. It makes things a lot easier to release on a multiple platforms.
And yet there is no Mac client, which is a platform that not only has the wonderful open technologies you mention, but also has a larger and more captive desktop game market than Linux does. Seems to me that their Linux support is more of a cover-your-ass move than any intelligent development decision that should be praised.
However, all of these primitives are not proven secure. How do you feel about cryptology being built on such a fragile foundation, essentially making it a house of cards?
Are you aware how amusing it is that you posted this question over a connection based on IP primitives?
They may not be able to break the encryption, but they sure as hell can break you.
Then it would be pointless to encrypt in the first place. If you're so weak willed that you'll give up the content (vis encryption key) before you give up your life, then your willingness to be tortured for that access accomplishes nothing.
Now I'm sure some will come to your defense and site a situation where encryption is used for non-life-or-death data, but then the logic breaks down there, too, because while you can encrypt all your email with GPG or the like, doing so without the resolve to meet any attack the encryption may face is an indicator of just how important the content is. For most, encryption is merely a "prying eyes" issue, not an "oh fuck; they've crippled me and may kill me (or jail me for contempt of court, for those dealing with more benign powers)" issue.
It's pretty obvious you can't copyright a length 1 bit string, so how many bits do you need before you own it and I don't?
Ah, a man after my own heart (sorry, I don't swing that way :-). This why I started a Data Fetish web site, to explore the nature of the beast that is binary representation. So the interesting followup question to your is: for what arbitrary encodings can you make a claim of ownership of data? Just because you could claim ownership of a certain binary string, do you get to claim ownership of its inverse and reverse? The gzip and uuencoding? How may transformations could something go through before it overlaps some binary string that someone else would claim ownership for? The courts haven't even begun to deal with the stickiness of the issue.
There have been a number of cases since 9-11 where would-be hijackings etc. have been stopped by the PASSENGERS. The equation is changed.
This is so true it isn't even funny. I have said to friends that the people who should really be pissed at the terrorists should be the other political groups that hijacked. Why 9/11 worked is because everyone expected a standard hijacking, were you'd be redirected and delayed for negotiations but had a high probability of survival. Now? Well, fuck, the assumption is that you're dead if you don't act. The whole "stay calm and everyone will be OK" line just won't work anymore.
Well I am glad the Internet architects were poser geeks or IP routers would have lookup tables with 2 billion entries.
You're looking at my comments the wrong way. Hierarchies often make things easier for computers, and that was necessary when a lot of the technology (networking and otherwise) was new. It's the same way a file hierarchy made sense for simple storage, but a database is usually a better choice when you want to deal with the actual properties of the data rather than their path. So the properties a domain might have are entity="commercial" and location="United Kingdom". Those could be abbreviated to co and uk respectively, and discarding the hierarchy would actually reduce the size of lookup tables because register.co.uk and register.uk.co (to say nothing of all the other combinations) would resolve to the same entry. The only tricky part is doing discovery without a hierarchy in place, but that could be addressed by associating a priority with a property.
Heirarchies are a Good Thing, as any geek should know.
Only a poser geek, really (based on moderation you received, we clearly have a lot of those on /.). Hierarchies are actually a very bad thing because they obscure information. That is, in fact, what this whole story is about!
The real situation is this: we have companies in the United Kingdom that want to be found on the Internet. The problem is that there are two actual hierarchies in place that could be the root under which to file such a domain, those being .com and .uk. Then there are the "off" hierarchies that get used not because of their geographical location as intended, but because their abbreviation corresponds to some common usage (.co being the case here).
So the hierarchy adds to the confusion of both the user and the company. The company has to figure out and register domains in whatever branch of the hierarchy the user may have wandered into, and the user never learns how addressing on the Internet is supposed to work and so they continue to wander around without aim. Elimination of the hierarchy would go a long way to clearing up the confusion and getting back to the simple idea of looking for, among other things, a company in the UK.
Of course, nobody should expect that to happen any time soon. Getting rid of the hierarchy means getting rid of the need to create new top-level domains and therefore eliminates that ICANN profit center.
The admin at my work was way ahead on this one.
Wow, I'd fire him immediately if I were his boss. He just opened up the company to massive litigation. It'd be akin to the phone company saying "we're going to monitor phone traffic and don't want common carrier status anymore". Moronic.
Thats one way to stop this stuff at work.
Stop what stuff? Creating a pleasant environment to do your job? There is nothing illegal about having music on your computer at home or at work.
Companies will take action and institute policies against downloading copywritten materials.
Of course, the only real way to do that is to shut off the Internet connection completely. There are very few things people access online that are actually in the public domain.
DasBlinkenLights
"It's Magic!" is ok for childrens, but not if you want do to something serious.
I hereby declare this technology sufficiently advanced!
Be prepared to be wrong.
Ah, now you've gone and reminded me of my favorite interview moment. The manager sat smugly behind the desk and asked me the age old "What do you consider your greatest strength?" to which I promptly replied "I like to be wrong."
The look of horror on his face spoke volumes, both of what he no doubt thought of me, and of exactly why that wasn't the kind of company I'd want to work for. I couldn't get out the door fast enough, and he couldn't wait to see me go. So I highly suggest doing the "brimming over with wrongability" thing right off the bat. :-)
Running more than one app doesn't utilise multiple processors, as 99% of the time if you're not interacting with an application it's simply sitting in an event loop waiting for input.
As I pointed out, that is true for any common architecture. A single processor isn't used 99% of the time it waits on input. You're actually supporting my point when you start talking idle times (which is kinda why I brought it up :-).
How responsive the system feels has little to do with how many processors it has.
Tell that to anyone who has ever owned an Amiga, or currently owns an accelerated video card. Co-processing, in whatever form you can get it, puts in place an abstraction that you can potentially derive great benefit from. Alll I know is that when I run a single, compute-bound thread, I'm happy to have a second processor around that isn't getting hammered at 100%.
No, very few people have machines that constantly utilise their processor, but when they DO utilise it, they want it to be as fast as possible.
See, now here you have something that is testable. Burst processing can be an issue, but the question is whether or not it's an issue for you in reality. To test it, you can simply put a process in place (or mod the kernel to log similar) that snapshots when the system is at >98% (or whatever) CPU usage and for how long. Then you could reasonably determine how much of your burst potential you're actually using. Only if those stats support your point could you can reasonably say a PC would be a better choice than a Mac based on the CPU gap alone. Otherwise, you're just trying to start a pissing match for some unknown reason. For what is done on the desktop these days, the Mac is plenty fast.
This line is getting tired.
Then maybe PC people should shut up with their own bogus claims that Macs cost twice as much. As for claims of not wanting Firewire, how about me not wanting to shell out for a floppy drive or PS/2 port when I buy a PC? At least when Apple includes technology with their system, it isn't some shit I haven't used in 5 years. This coin has two sides, so why flip it?
If you are able to build machines yourself, why is that not as good as buying a machine from Apple?
Because then it isn't a parity comparison. Just because you've spent a lot of time and effort picking out and building a system for yourself (at some hourly rate which you will no doubt leave off of the bill for the cost of the PC) doesn't mean anyone who wants a computer can do the same. If you are so certain you can system build for the masses better than the likes of Dell, go into business and get rich. Now point me to the URL of a name brand that shows you can get a built PC that is on par with a Mac for half the price. Otherwise, it's you guys that have all the tired lines.
What the hell does that mean?
It apparently means you couldn't bother to educate yourself before posting. Here's a starter link: Mach Scheduling and Thread Interfaces. The long and short of it is that each process is run in a main thread that may start other threads, none of which are tied to a particular processor and all of which are given time slices at a priority. So if I have four things going at once, they (and any other threads they start up) will be pushed to whatever can handle them, and quitting two doesn't lead to a situation where one CPU is left at 100% and the other is idle.
No it isn't. How many multi-threaded programs have you written? It is nowhere near as simple as just creating a thread and setting it loose in a program that wasn't designed to be multi-threaded.
My guess is that I've written more than you, but I've used an API (Cocoa) that doesn't penalize me for the use of threads unless it has to. I'm sorry you're stuck with something less elegant, but I look forward to you writing a single OS X app and seeing what OpenStep made possible over a decade ago.
They don't just idle faster. They do work faster as well. Why would they just idle faster?
Because, as those who actually read my post saw, they are unlikely to be pegging the CPU at 100% even when they are in use. Do you think your word processor (unless it's a really crappy one) really needs 3GHz to keep up with your typing? Unless you're talking about something specialized like a render farm, your argument isn't valid. These are desktop systems, and being twice as fast as a Mac only means your computer is twice as wastefully idle as mine. I'd estimate that I'm hitting the burst limits of my system less that 1% of the time.
Further, if you are talking about something like a render farm then you will find that one of the abstractions provided by Cocoa for threads is called an NSConnection, which also allows the processing to abstract to another machine altogether! If you won't get a Mac for whatever reason, at least look into something like GNUstep so you can actually start taking advantage of the systems you already have.
You never run more than one app? Or are you saying that threading on the OS you'd use is screwed up? On Mac OS X, threading is done at the Mach level, and it is dynamically shifted between processors. For those situation where an app can take advantage of multiple threads, adding support to a Cocoa app can be simple call to an NSThread object. I've had single processes suck up 180% of the CPU while 40 other ones ran just fine on my box. Buying a 2x Mac is something I have not regretted, but thank you for letting me know it would be a regrettable thing to do if I ever upgrade my Linux server.
Are there applications for SMP? Sure. No question. But even most geeks who lust after SMP won't ever actually utilize it to the fullest.
The truth is that no CPU architecture that's popular is being used to the fullest. Computers are sitting idle 95+% of the time waiting for the user to do something. And the other 5-% is unlikely to be a burst that pegs usage at 100%. All those 3GHz Intel boxes aren't any faster really, they just idle faster; that's not something to brag about.
Frankly, for the price of the Dual G4 1.42 GHz I can buy more than 2 P4 3.06 GHz boxes, which is a much better solution for most cases.
Please point to a major manufacturer that offers two PCs that are similarly spec'd to the one Mac, with the addition of the high revving engine, for the same price. Note that being able to hobble parts together in your parent's basement doesn't make you a business on par with Apple.
While this wouldn't be so practical for work (except for maybe switching keyboard nationality at the press of a button), how badass would that be for gaming?
Actually, it may be extremely practical for work, just not in the way everyone (or even the manufacturers, apparent) thinks. I see this sort of thing as being really useful as an extra, programmable keyboard. I mean, I could honestly do without the keypad most of the time, and surely I'm not the only one who remember when software relied heavily on function key template maps. You could virtualize those things and, in fact, could provide a number of custom layouts for macros or toolbar items as well. Just in typing this reply, I can see the use of being able to call up a special HTML keyboard that would easily allow me to tag a selection (an <i> key, a <p> key, etc.). Really, these people should forget about the stagnant PDA market and focus on providing a virtualized interface for the desktop market.
Depending on these percentages, Mac vs. Linux could go either way.
I don't see how anyone could imagine the Linux game market is larger than the Mac game market, let alone enough larger to make up for the lack of similar market penetration. Linux simply isn't a player on the home desktop, regardless of how many desktops you run it on personally. It mainly sees work as a server and/or a semi-acceptable alternative in the corporate environment. Looking at that, you'd have to do a great deal of hand waving to even pretend that the game markets on both are even close. Some should be getting fired at Bioware over this, plain and simple.
Are you sure about this?
Given that a full audit of all computers on the planet is not likely, I'm as sure as IDC is. Numbers can be cooked, and PC types love to cook Mac numbers, as though somehow making the Mac less significant makes their platform any better. Real world stats like the Google Zeitgeist still show Macs have four times the usage as Linux, and I would further guess that the Linux use comes more from a corporate setting than a home setting where a game purchase would be likely. Mac users are also used to paying for commercial software, whereas Linux user support is a bigger question mark. When all is said and done, I would guess the Mac game market is an order of magnitude larger than the Linux game market. Both are, of course, absolutely dwarfed by the Windows monopoly. Regardless, smart money would have done a Mac port first.
Probably not. However, it appears Bioware are pressing ahead (and doing it inhouse) because they are a games company that wants to be around in the long run, and stay one step ahead of its competitors.
That doesn't make sense. If it's a sink hole, they're less likely to be around for the long run. A company basically has to be moronic to put out a Linux client before a Mac client. Not only is the Mac market bigger (and captive; no ability to just boot Windows if they wanted to play), the support for OpenGL is more polished and it would give them a proving ground for their work.
That makes me think they value the experience and want to keep it internal to the company.
Odd, it makes me think the code is a damn mess that relies heavily on both Windows and x86 funk. You'd think these companies would have learned something from id when it came to creating games with a portable core. I predict you'll see DOOM 3 for Linux before you see NWN.
One problem with online games (a lot of online things these days) is that they usually demand and involved registration process before you can do anything worthwhile. I honestly don't have the inclination to register like that for every game that comes out just to find out it sucks (or, less likely, doesn't suck). Snowcrash had generic avatars, and Slashdot has ACs. Regardless of how much you favor or disfavor the idea, I know I wouldn't have spent much time on Slashdot at all if I didn't initially have a voice as an AC.
Actually, the eDonkey network (and I believe Overnet too) verify seperate chunks of the file as they're downloading.
That's only slightly better. You still have to download those bad chunks, though, so it only shifts the problem to being one of limited file sizes, with the tradeoff being validation, keeping, and moving around an even larger database of what the chunk checksums should be. Having multiple valid encodings of a file doesn't help, either.
This is a real system, really in place right now. I haven't downloaded a bad file (blank, bad rip, etc) since I switched. All you need is a trusted source of links.
That is the equivalent of "security through obscurity". Just because those networks haven't become a target of sabotage yet doesn't mean they won't become targets in the future. They are vulnerable, but just haven't been exploited yet. Any time "trust" enters into the picture, it's a bad thing. You have to assume that every transfer is via the man in the middle. Until P2P networks reach a level of maturity to deal with that, you will constantly find yourself switching to new ones to stay ahead of detection.
. . . you never have to download another bad file again.
Wow, the mods are as dense as you seem to be. All a checksum does it allow you to verify that a file matches a fingerprint of the file. It is a form of derived meta information. The problem with that is that your peer cannot be trusted in these cases, and can initially give out a checksum that does not actually match the file that will be served for the request. The only way would be to download it and run the checksum locally. This is to say nothing about knowing the validity of entries in a checksum repository. So, in fact, your "Yawn" solution essentially solves nothing.
Takes away the advantage of developing on a operating system with a rubust api.
What does that have to do with Microsoft?
But, seriously, Apple seemed to be able to bridge Java for their Cocoa API. The problem on Windows is Microsoft's wanting to control everything, not Java (aka, Sun wanting to control everything).
Why don't you try reading the comment? There is a difference between a trivial comment and a trivial relationship.
Sorry, but I did read the comment and wisely determined that any relationship based on "you don't need to think twice before messaging someone about something totally trivial" is itself trivial. The last thing I need are people messaging me shit like "I see kittens" or "It's raining" for no good reason; it's a form of spam as far as I'm concerned.
You can make a five second international phone call that a) conveys any information whatsoever and b) only costs 2 cents. I'm impressed.
We both know the example was as bogus as the response. The foundation of SMS isn't built on international messaging. There is seldom someone in some distant land that anyone needs to reach immediately by way of a telephone keypad. You'd make the sensible decision to wait the 15 minutes it took to get home or to work and use a proper keyboard to easily type what is likely an un-urgent message, or you'd pony up the dough if it was important.
Now tell us all the real reason you're defending SMS. You've offered no scenario that shows it actually offers an advantage compared to other methods of communication. Without that, your efforts just look silly.
No furtive and very annoying (to those around you) conversations, no cryptic number on a little tiny pager display.
These points have nothing to do with SMS, but reflect the class of the person receiving the message. I can bet you some prick with a text pager is still going to be disruptive and scream something like, "Guys, guys! Check out the message Bobby sent me!"
I can take it to the pub and not have to find a quiet place to hear messages. I have on more than one occasion been unable to receive an ordinary call because of ambient noise. SMS might have been very helpful.
People don't know where you are, so they can't know what the best method is to talk to you. What it sounds like you'd really prefer is something different: voice-to-text of your voice mail. That actually makes some sense, but I don't know of a single provider that does SMS with anything other than hunt and peck keypad entry.