Sigh. Go back to the beginning (or near the beginning) of the thread you replied to. The post I replied to said:
"Apple are doing a lot of good, as you mention, with things like Grand Central Dispatch, but the multiprocessing features in earlier versions of OS X, and even more OS 9, were nothing that was in any major way any better than that offered by, say, Windows or other Unix based OSs"
Note "earlier version of OS X" i.e., those without GCD.
I've never used DCOM, but it's supposed to be a simple extension of COM and there's a big difference in usability between COM and the NeXt distributed objects.
I don't remember the US seriously claiming Iraq had anything more than some chemical weapons of dubious quality that were actually deployable, and even that was more spin to try to get the UN to endorse the invasion. There's a big difference between some unreliable chemical weapons that you can counter with gas masks and a nuke.
Note that Iran and North Korea haven't been invaded yet, even though either one is a much more credible threat than post 1991 Iraq.
Cocoa has both vending and communication systems to work with the shared objects. You can, for example, create a shared object in your program and advertise it (via Bonjour/zeroconf) to the network. Other processes running on other threads or other machines can then connect to that shared object and it appears to be just another local object to them. Messages (method calls) to that "local" object are passed along to the actual object, wherever it is, and executed on it's thread or machine, then results are sent back, transparently to the programmer.
With little work you can make some very nice distributed applications.
I believe MS provides thread pool libraries which do the "making it easier" part that GCD does. GCD also has the feature (which Windows doesn't, AFAIK) that the thread pools are managed by the system and there are some advantages there. If you've got a couple of heavy apps running GCD might decide to break their workloads into fewer threads each for efficiency.
Meh. The thread vs. process crusaders get all uptight. In reality both have their advantages and can be used almost interchangeably. Other arguments against threads usually boil down to not actually letting the programmer play with the threads directly, but abstracting them away in some form (which is not a bad idea, but is also not as revolutionary as some would like to think).
If you've got multiple processors you need some way of parceling out work to them so any parallel processing machine is going to have something like threads or processes at it's basic level, just like any serial machine has instructions. Should crappy programmers be allowed to play with threads directly? Probably not, just like they shouldn't be allowed to program in assembly or use pointers.
It doesn't make it as different as you seem to think.
I think GCD is a great idea, and a very useful tool, but it's not a magic bullet. GCD can schedule some things more effectively because it has a system-wide view. The closure extensions and GCD interface makes it reasonably easy for novice programmers to get things actually running in parallel.
Of the two, the latter has a MUCH bigger impact in terms of actually getting programs to take advantage of multiple cores. Actually sending
BUT, it's nothing you can't do (and hasn't been done) with various multiprocessing libraries, many of which run on Windows, or with good old threads and processes if you've got a moderate level of skill. In order for it to work effectively the programmer still has to a) structure his program in such a way that the parallelism is exposed and b) actually use GCD.
Contrary to what you seem to suggest, GCD does not really "creates and manages threads on its own, even in applications that are not written to be threaded." It creates threads at the (indirect) request of the application and schedules them appropriately. The application MUST be designed to take advantage of multithreading. The only difference is that GCD makes it easier for the programmer to actually get those threads up and running, and can possibly schedule them more effectively.
Perhaps multicore is just was OS design needs. The OS gets to hog, er, use effectively, a couple of cores and the rest are available for the things that should be using them - whatever apps the user wants to run.
Maybe the OS could provide some better parallel programming tools, but parallel code is always going to be harder to write than serial, although it isn't overly difficult if you're using reasonable practices anyway.
I'm not sure if Windows has something similar, but the shared object system in ObjC/Cocoa is pretty fantastic. I think it's inherited from NeXt, so I suspect it's been in OS X all along. Nobody seems to know anything about it though.
OS X has also always been a home-level OS that is designed to be (and always has been) used on multiprocessor machines.
You're right, OS 9 and previous were sadly behind.
You might be right. It's equally likely that it's diverging from a desktop/notebook computer. Apple is positioning it as a portable (outside or just to the couch) web surfing / reading / casual gaming platform. All things that you could do on your desktop/notebook but Apple is betting you might like to do on an iPad instead.
The argument for it being a convergence device seems to be the weakest of the three possibilities.
I'm curious. Did this Schell person say this before, after or during the iPad release in the US where they took preorders for a couple hundred thousand of the things?
My teenage cousins got MacBooks because they don't have to take them to a computer guy regularly for maintenance. Garage Band was important to them as well - one is studying music at university, one musical theatre, and another has a band.
I don't think that's the way it works. A wire transfer either goes through or it doesn't. The funds don't show up in your account until it goes through.
However, just because you tell the bank to go ahead with the transfer doesn't mean they do it right away, so there's still a chance to call them and tell them not to do it. Once they do it though, you're SOL.
Because Stallman believes it is immoral to create software that doesn't live up to his definition of "free." He would like very much to stop everyone from doing so. In other words, Stallman would like to remove everyone's freedom to create software in ways and forms which he doesn't agree with.
Slashdot Mirror
Charging for saves... now that's diabolical.
Wait, isn't it Steam that's moving to a model where all your save games are stored on their servers? And they're touting it as a feature?
Sigh. Go back to the beginning (or near the beginning) of the thread you replied to. The post I replied to said:
"Apple are doing a lot of good, as you mention, with things like Grand Central Dispatch, but the multiprocessing features in earlier versions of OS X, and even more OS 9, were nothing that was in any major way any better than that offered by, say, Windows or other Unix based OSs"
Note "earlier version of OS X" i.e., those without GCD.
I've never used DCOM, but it's supposed to be a simple extension of COM and there's a big difference in usability between COM and the NeXt distributed objects.
I don't remember the US seriously claiming Iraq had anything more than some chemical weapons of dubious quality that were actually deployable, and even that was more spin to try to get the UN to endorse the invasion. There's a big difference between some unreliable chemical weapons that you can counter with gas masks and a nuke.
Note that Iran and North Korea haven't been invaded yet, even though either one is a much more credible threat than post 1991 Iraq.
FreeBSD has already implemented GCD.
I guess by "outside of Apple" you meant "Microsoft."
Ever used DCOM?
Very little helps with concurrency problems. Ease of communication and setting up threads and processes is important as well.
I think it's actually distributed objects, not shared.
I did say "system."
Cocoa has both vending and communication systems to work with the shared objects. You can, for example, create a shared object in your program and advertise it (via Bonjour/zeroconf) to the network. Other processes running on other threads or other machines can then connect to that shared object and it appears to be just another local object to them. Messages (method calls) to that "local" object are passed along to the actual object, wherever it is, and executed on it's thread or machine, then results are sent back, transparently to the programmer.
With little work you can make some very nice distributed applications.
I believe MS provides thread pool libraries which do the "making it easier" part that GCD does. GCD also has the feature (which Windows doesn't, AFAIK) that the thread pools are managed by the system and there are some advantages there. If you've got a couple of heavy apps running GCD might decide to break their workloads into fewer threads each for efficiency.
Meh. The thread vs. process crusaders get all uptight. In reality both have their advantages and can be used almost interchangeably. Other arguments against threads usually boil down to not actually letting the programmer play with the threads directly, but abstracting them away in some form (which is not a bad idea, but is also not as revolutionary as some would like to think).
If you've got multiple processors you need some way of parceling out work to them so any parallel processing machine is going to have something like threads or processes at it's basic level, just like any serial machine has instructions. Should crappy programmers be allowed to play with threads directly? Probably not, just like they shouldn't be allowed to program in assembly or use pointers.
It doesn't make it as different as you seem to think.
I think GCD is a great idea, and a very useful tool, but it's not a magic bullet. GCD can schedule some things more effectively because it has a system-wide view. The closure extensions and GCD interface makes it reasonably easy for novice programmers to get things actually running in parallel.
Of the two, the latter has a MUCH bigger impact in terms of actually getting programs to take advantage of multiple cores. Actually sending
BUT, it's nothing you can't do (and hasn't been done) with various multiprocessing libraries, many of which run on Windows, or with good old threads and processes if you've got a moderate level of skill. In order for it to work effectively the programmer still has to a) structure his program in such a way that the parallelism is exposed and b) actually use GCD.
Contrary to what you seem to suggest, GCD does not really "creates and manages threads on its own, even in applications that are not written to be threaded." It creates threads at the (indirect) request of the application and schedules them appropriately. The application MUST be designed to take advantage of multithreading. The only difference is that GCD makes it easier for the programmer to actually get those threads up and running, and can possibly schedule them more effectively.
Perhaps multicore is just was OS design needs. The OS gets to hog, er, use effectively, a couple of cores and the rest are available for the things that should be using them - whatever apps the user wants to run.
Maybe the OS could provide some better parallel programming tools, but parallel code is always going to be harder to write than serial, although it isn't overly difficult if you're using reasonable practices anyway.
I'm not sure if Windows has something similar, but the shared object system in ObjC/Cocoa is pretty fantastic. I think it's inherited from NeXt, so I suspect it's been in OS X all along. Nobody seems to know anything about it though.
OS X has also always been a home-level OS that is designed to be (and always has been) used on multiprocessor machines.
You're right, OS 9 and previous were sadly behind.
A deterrent is a defence. The most effective one, in fact, the one that keeps the other guy from even trying anything.
A country possessing nuclear weapons pretty much guarantees that the US won't invade. Even possibly having nukes is a very good deterrent.
XP had a suspend option, didn't it? And Vista and Windows 7 definitely do.
Whether it works or not is another question.
It's a system level thread pool library, along with a nice interface for sending off little bits of code to the pool.
Starting out slow isn't really a solution to the "getting slow" problem.
You might be right. It's equally likely that it's diverging from a desktop/notebook computer. Apple is positioning it as a portable (outside or just to the couch) web surfing / reading / casual gaming platform. All things that you could do on your desktop/notebook but Apple is betting you might like to do on an iPad instead.
The argument for it being a convergence device seems to be the weakest of the three possibilities.
I'm curious. Did this Schell person say this before, after or during the iPad release in the US where they took preorders for a couple hundred thousand of the things?
Particularly since the lawyer appears to be at least a part time debt collector.
My teenage cousins got MacBooks because they don't have to take them to a computer guy regularly for maintenance. Garage Band was important to them as well - one is studying music at university, one musical theatre, and another has a band.
I don't think that's the way it works. A wire transfer either goes through or it doesn't. The funds don't show up in your account until it goes through.
However, just because you tell the bank to go ahead with the transfer doesn't mean they do it right away, so there's still a chance to call them and tell them not to do it. Once they do it though, you're SOL.
No, it seems the attorney covered the debtor's ability to pay.
Agreed. It doesn't seem like that sophisticated a scam. Just regular old cheque fraud.
I guess you feel better about it if you say the scam that got you was "sophisticated." Particularly if you're a lawyer and should know better.
You'll be irresistible to bugs.
Because Stallman believes it is immoral to create software that doesn't live up to his definition of "free." He would like very much to stop everyone from doing so. In other words, Stallman would like to remove everyone's freedom to create software in ways and forms which he doesn't agree with.