Slashdot Mirror
Apple's Grand Central Dispatch Ported To FreeBSD
bonch writes "Apple's Grand Central Dispatch, which was recently open sourced, has been ported to FreeBSD and is planned to be included by default in FreeBSD 8.1. Also known as libdispatch, the API allows the use of function-based callbacks but will also support blocks if built using FreeBSD's clang compiler package. There's already discussion of modifying BSD's system tools to use the new technology." The port was originally unveiled last month at the 2009 Developer Summit in Cambridge. Slides from that presentation are available via the Dev Summit wiki.
Always taking from the open source community, and never giving back!
#DeleteChrome
My first question was "So...what does this do?" Apparently it is a more efficient way of scheduling threads on multi-core systems http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf apple's site says this: "Grand Central Dispatch (GCD) in Mac OS X Snow Leopard addresses this pressing need. It’s a set of first-of-their-kind technologies that makes it much easier for developers to squeeze every last drop of power from multicore systems. With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between. Once developers start using GCD for their applications, you’ll start noticing significant improvements in performance. " So this seems good then.
Apple maintains their own gcc fork which supports blocks/closures.
Do you even lift?
These aren't the 'roids you're looking for.
So, basically this is a tool to streamline concurrent code on multi core machines? Did BSD not have something like this already?
now it can die in parallel, optimized for the number of cores and other system activity.
Do you even lift?
These aren't the 'roids you're looking for.
Netcraft confirms it: This joke is dying.
Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
The other two things you mentioned are ways for programs to more easily use multiple threads, but they are still threads under the main process and not centrally managed - so you have to decide blind how much of the system you can take for your threading needs.
You can compare the Blocks syntax to ways those two systems specify work units to be done in parallel, but that is just a part of the story.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's unclear that this buys you much over OpenMP 3.0. GCD gives you a little bit more flexibility, but that's not needed in many applications, and GCD is quite inconvenient without closures.
Grand Central is not introducing multithreading - it's introducing comprehensive thread management. So, how many threads are you going to spin for that task? Too many, and you waste a lot of time on thread management and preemption. Too few, and you have processors sitting idle. Now how will you handle this with multiple CPU's? Multiple cores? Hyperthreading? Different cache amounts and layout? OpenCL and GPU processing? Do you know what the rest of the operating system is doing to plan appropriately?
In short, your program can at best make a stab at these issues, and possibly even do a reasonable job if you put a lot of time, effort, and profiling into it. Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
It's good stuff. And Apple gave it to the community (much like WebKit enhancements, launchd, etc).
I don't know what kind of crack I was on, but I suspect it was decaf.
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.
Can someone explain how this is different from a normal OS with kernel level threads and not userland threads? What can this do that e.g. Windows threading, native posix threading (NPTL) in Linux, etc... Is this just apple "inventing" kernel level threads or is it something new?
er... isn't that what modern preemptive multi-tasking OSes already do?
Modern OS's move applications or (even threads) across different cores. But applications can have many threads, and the threads until now have been mostly managed by the applications themselves. The choice to spin off 10 or 100 threads? Up to the application. And that choice was made without the application being able to understand what choices other applications had made... the OS was left to manage as best it could with a large pile of threads, or sometimes apps with no threads that could just run on one core.
With GCD, instead you simply create as many threads as you like, and the central manager decides how many can be run across all the cores. The other part (Blocks) simply makes is easier to define the parts that can run off in separate threads, as noted that is more comparable to the other libraries because you want to encourage every app to have some parallel components. But the other approaches run back into the same problem that once you have defined the parts that can be run in parallel - how many threads should you spawn?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm sure it will come to Linux in some shape. You might not see it bundled and it may never work with every distro, but not everyone in the Linux community is as much a fanatic as RMS.
...It probably won't benefit single cores at all...
Actually, it should reduce management overhead for applications on a machine using a single core.
Meh..BSD isnt dead, pot smoking is good, and Linux is just for broke rejects who are mad cause they cant afford MS. Its hardly superior to anything, and the only reason it continues to thrive is because the developers make it easy for tards who need a GUI.
Do I understand it correctly if I oversimplify it as "centralized thread pool"?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The other often-overlooked advantage of GCD is that submitting work to a queue is thread-safe, queues themselves are lightweight, and queues can be made internally-serial but parallel to all other queues. Apple's documentation has a lot of good examples of how to use this structure to eliminate almost all locking code (which is usually pretty heavyweight). If you need to serialize access to a resource, just create a serial queue and any other queue can send tasks to it without worrying about any synchronization.
As someone who's struggled with performance from trying to determine how fine-grained to make locks, this seems like an awesome approach.
It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.
Yep, apple didn't give back all their code on WebKit, or all of Darwin, or all of launchd, or all their patches on zfs, or their code on MacPorts, or darwin streaming server, or CalDav, or iCal format, or their Calander server, or their code on their X server, or their code on ruby, or a bunch of code on smart card services...
Wait, yes they did.
Awesome! They have almost reinvented lexical closures, etc. In another ten years this will be as awesome as using continuations for UI navigation in a web framework, which was done yesterday.
Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!
Wait... what is that? Oh, nevermind then...
You obviously know sarcasm when you see it... :-P
"Freedom" is what he calls his beard.
it seems like the ability to share work across machines, not just cores, would be a critical difference.
Neither GCD nor OpenMP allow you to "share work across machines".
all their patches on zfs
Did they really have a choice there?
How does this fit in with Debian now also providing a FreeBSD kernel? I'm assuming that the FreeBSD kernel uses a BSD licence... but I might well be wrong... but assuming it does, I would guess GCD would be fine?
On their stolen computer next to all the other things they stole from school. They even steal the flies from outside who swarm around their unwashed bodies. linux is the devolvement of humanity - a linux user is like an anti-human - taking the opposite form of what a real human should be. They do not know how to reproduce, they cannot interact with others and they long ago forgot the concept of personal hygiene. They believe communism is something we should strive for and believe klingon is a real language. yes... we know of your type.
That's not quite correct. There are two parts to GCD: libdispatch and the kernel support. The kernel support is MIT license, so is compatible with GPL. Besides, the kernel component wouldn't be ported anyway--it would be rewritten from scratch if one were doing GCD Linux, so the license doesn't matter.
Libdispatch is Apache license. It runs in the applications, not the kernel, so the kernel being GPLv2 is irrelevant. What's relevant are the licenses of the applications that might want to use libdispatch. Many of those will be licensed as GPLv2 or later. Those are OK, because Apache license is compatible with GPLv3.
Finally, if libdispatch were to be included as a standard part of Linux, even GPLv2 code could dynamically link to it, because it would fall under the system library exception.
There's nothing stopping the Linux kernel team or a third party from implementing an equivalent feature for Linux. It may not happen overnight, but if the interest is there it will be done.
And unless someone has benchmarks, I suspect the performance edge of Grand Central Dispatch isn't going to obsolete Linux - or for that matter, Microsoft Server - overnight.
They could have chosen not to ship with zfs support.
Given how little OS X supports zfs, they could have left it out without any big deal.
Help! I'm a slashdot refugee.
So any modifications to ZFS that they included in their shipped product had to be distributed? GEEE THANKS FOR THAT APPLE and isnt webkit based on khtml?
Apple maintains their own gcc fork which supports blocks/closures.
The probability that Apple migrates away from gcc is approaching 1 at great speed.
Yes, WebKit is based on KHTML; Apple forked it, IIRC.
SSC
does he get derivative works?
Yeah, you beat me to it. Sounds like another case of confusing copyright with patents.
And their fork is publicly available under the BSD license and in SVN for all to enjoy.
Interested in open source engine management for your Subaru?
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.
Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.
(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)
If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.
Sam ty sig.
Several things didn't need to be open sourced, such as WebObjects and GCD. Quit your crying. FOSS zealots love to whine about Apple only doing what's required, but they fail to realize that it's a symbiotic relationship. Apple can use existing code to fit their needs, and in return, the open source community gets all of the improvements made by professional coders. It's a win/win, but the mini-Stallmans will never see it that way.
why won't gcc take the patches?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Don't you dare compare me to the parent.. he is certainly no commie...
Tobias Ussing http://www.nearby.dk
Because Apple is sticking with GPLv2
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his speech.
Fixed that for you.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Your post can quite literally be summarized as:
"this stuff that they improved, they didnt invent it so improving it doesnt count!"
also known as:
"I'm dont understand open source"
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads
True enough, but it is the part that differentiates GCD from the other frameworks and thus deserved the most explanation.
This is only useful because OS X has horrendous per-thread overhead.
Actually it's useful because threads on all platforms have overhead, which is why the reuse of them by GCD to run these lightweight blocks matters. It's why it's being integrated into BSD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
That is true and what makes it likely we'll see many apps actually take advantage of this where we haven't seen that many apps even bother to thread much before. Frankly even though it will not help with performance (because there is no GCD) I'm excited to have blocks (closures) on the iPhone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's a win/win, but the mini-Stallmans will never see it that way.
To the contrary: I am a huge fan of Stallman's philosophy and see Apple's work as win/win.
The people that are complaining are the looney Apple Haters, who try and find any point possible by which to attack Apple - never realizing until it is to late the latest position they are attacking from makes no sense.
Please do not taint all those of us who respect the GPL with the same brush the Haters paint themselves in corners with.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Actually what I'm saying is that just because they play by the rules doesn't make them special.
They use the best software available to them for the job they want to complete. If that happens to be an open source product then they are going to use the open source project. If they use an open source project they are going to want to fix and improve it. With open sources fixes and improvements must be contributed back to the community. They do not deserve any special acknowledgement because they are doing things in their best interest that also happen to follow the rules.
When is the last time that Apple released an entirely new project? For example Sun released ZFS under the CDDL.
It will support C++ soon enough.
The benefits of clang are that it uses llvm as the compiler, which produces better optimized machine code than gcc currently does. Also, it supports Apple's block syntax (kind of like a pointer to a function), which allows things like libdispatch to do its magic. Also, as a C front end, it has much less cryptic error messages, and actually does a pretty good job of finding missed initializations and other hard to find bugs that usually will get caught at the code execution stage.
You should check out Siricusa's more thorough explanation at arstechnica, in his Mac OS X 10.6 Snow Leopard review. He goes into some detail to show how Apple's use of clang in the new XCode is almost "pornographic for developers..." You wouldn't have the same IDE in BSD or Linux, but the same functionality is there. Someone posted a link much higher in the thread.
-- Len
When is the last time that Apple released an entirely new project? For example Sun released ZFS under the CDDL.
Why reinvent the wheel? They adopt it, improve it and release the improvements. At least they add. They deliver. When is the last time Stallman released an entirely new project? Or finished one? "Although nearly all components have been completed long ago and have been in production use for a decade or more, its official kernel, GNU Hurd, is incomplete and not all GNU components work with it." from the reliable-as-ever Wikipedia. Apple is not Stallman. They do not serve the same market. Apple is in hardware/software/platform, Stallman is in philosophy. Fair enough, einen Unterschied muß es geben.
All those moments will be lost in time, like tears in rain. Time to die.
The probability that Apple migrates away from gcc is approaching 1 at great speed.
That writing's been on the wall for quite a long time now. GCC has been a severe limitation on what they could do with Xcode for far too long. With LLVM, I'm expecting shortly to get away from the edit/compile/debug cycle and have a pause/edit/resume cycle instead.
Right now in Quartz Composer, you can write GL SLANG shaders that are compiled on the fly as you type. It's amazing to see the effects of changes immediately.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
This is just yet another API to do what competent parallel system programmers have been doing since the first thread.
RTFM, and learn what you're missing.
The point of GCD is that taking advantage of multiple cores becomes much less work. When I say "much less", thinks minutes versus days. Besides the ease of use, the underlying implementation also deals with scaling the queues across the number of available cores on the fly, and makes the management of serial dependencies trivial.
Another benefit of GCD over managing the threads yourself is performance. Apple changed the implementation of Objective-C's garbage collector from running on a dedicated thread to running in GCD, and picked up a double-digit improvement in the speed of memory recovery.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
So, in other words, sobbing.
And yeah, I messed the simile up.
Well, we have the subject of this article, Grand Central Dispatch. We also have Darwin & XNU, their version of the Mach kernel. There is also Bonjour, their version of zeroconf, and their streaming server (Quicktime Streaming Server). They also purchased the source to gimp-print (now called Gutenprint) so they no longer have any obligation to keep it open source, but they do, and they keep releasing the source. How much more do you need?
Check out DRM-free movies at http://www.bside.com
Apparently it is a more efficient way of scheduling threads on multi-core systems ...
...So this seems good then.
duh!
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Oh REAAAAALLLY?
If you mod me down, I shall become more powerful than you could possibly imagine.
Apple isn't "sticking with GPLv2" so much as "actively working to replace every last scrap of GPLvn code with BSD/MIT/Apache code." They appear to be under the impression that GPL is unfriendly to business, which impression is defensible. They are investing many programmer years in Clang/LLVM, and soon enough will be liberated from the tyranny of gcc.
If you mod me down, I shall become more powerful than you could possibly imagine.
Well, we have the subject of this article, Grand Central Dispatch. We also have Darwin & XNU, their version of the Mach kernel. There is also Bonjour, their version of zeroconf, and their streaming server (Quicktime Streaming Server). They also purchased the source to gimp-print (now called Gutenprint) so they no longer have any obligation to keep it open source, but they do, and they keep releasing the source. How much more do you need?
I agree, they could go closed/proprietary like Opera, yet they choose to keep things open and improve on them. They're in it for the money, like a lot of companies, and if that means cooperating with OpenSource Software, so be it. It's a bit of a win/win situation. It's just that their business-model does not allow to go fully free and open, bit of a shame, but oh well, one can't have ones cake and eat it.
Disclaimer: former Apple employee, now in education and liking all things open and free, but still without losing touch with reality.
All those moments will be lost in time, like tears in rain. Time to die.
Could you show me the link you mention, I can't find it?
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Well a GCD queue also has overhead, right? The OP is correct - on systems that get threading right (ie not OS X) if you have 200 tasks that can run in parallel, the easiest way forward is to create 200 threads.
When might you not want to do this? One is if each task has a large associated memory overhead so you don't want the data for every task to be in memory at once. In that case maybe you want fewer threads, and a controller thread that loads data and keeps the thread pool queue long enough that it never stalls but short enough that you use minimal memory.
Another situation is when a thread is very expensive. This is not true on Linux (at least if you're careful with stack size) and used to be true on Windows but I believe has been improved over time.
Another situation is where the tasks aren't available all at once. This is just a variant of the first scenario.
The final one is when a task blocks, eg, reading from disk. In that case you might want a very large number of threads in order to keep the CPUs busy and not waiting around on disk.
But apart from CUPS, LLVM/clang, Webkit, Darwin, launchd, patches for zfs, MacPorts, darwin streaming server, CalDav, iCal, the Calendar server, code for Ruby, code for X server and GCD, what has Apple ever done for us?
Webkit is kinda special. For ages, Apple did nothing other than releasing the full source every time they released binaries.
They did _not_ release anything under SCM control, which meant tracking patches etc was _literally_ impossible for the KDE team. No matter what the KDE team did or how often they asked, this did not change. This is a large part of why KHTML and Webkit are as different as they are now. Using both KHTML and the Webkit Kpart in KDE 4.3.2, I can tell you that there are a lot of little differences in rendering and, that is where it hurts, usability. Sucks.
So while Apple followed the letter of the license, they went against its spirit in every possible way for a long time. This may have changed somewhat (iPod, iTunes...?), but one should be aware of the history.
Has anyone asked them?
The FLOSS community gives all their mailing lists, internal processes, every single commit along with the commit message to Apple.
Apple (this has improved) gave the FLOSS community one huge source tarball without any context with every OS X release.
Those bad, bad FLOSS zealots, look at all the win/win they received!
A massive case of NIH from the GCC team with regard to Apple. See also the patches that Apple submitted well over a year ago adding declared property support to GNU gcc. I found it easier to write all of the code required for clang to support the GNU Objective-C runtime than make even small changes to Objective-C support in GCC (in spite of not having used C++ for a few years and really hating the language).
Oh, and I've had blocks working with clang on FreeBSD for quite a while (since several months before Apple publicly released an OS supporting them, in fact). I added the required runtime library support into Etoile's ObjectiveC2 framework a while ago, which also provides the run time support for most of the Objective-C 2 features. This framework is going to go away soon, because I'm now maintaining a fork of the GNU Objective-C runtime in the GNUstep repository, which merges these improvements and also incorporates most of the ideas from my experimental Objective-C runtime library (without breaking backwards compatibility, although you don't get all of the features if you don't use the new ABI).
By the way, porting to *BSD is much easier than porting to Linux. Libdispatch is based around the kqueue mechanism for unifying kernel event sources, and there is currently no in-tree equivalent for Linux. There are four out-of-tree sets of patches providing equivalent functionality (that I know of, there may be more), as is common with Linux development. On Solaris you can do the same thing with completion ports, which are roughly semantically equivalent but have a different interface.
I am TheRaven on Soylent News
Libdispatch is Apache 2 licensed, not BSD licensed. There is no legal issue porting libdispatch to Linux (although the lack of sane interfaces on Linux means that there are technical issues; there's nothing equivalent to kqueue/kevent, so you'd have to go via a - slow - wrapper library). The issue is that GPL'd applications can not depend on it. Not really a problem; they also already can't depend on any of the other nice Apache 2 libraries, so this is just one more reason to avoid the GPL for your code.
I am TheRaven on Soylent News
From the professional coders at AT&T?
(ducks...)
In Soviet Washington the swamp drains you.
This is between one and two orders of magnitude more expensive than adding a block to a work queue with GCD.
Switching between the threads is also relatively expensive. At the very least, you need to save all of the registers and update the stack pointer (probably in response to a timer interrupt, so also factor in the cost of a transition from kernel space to users pace). With GCD, the kernel will give you one thread per CPU for each priority level (or fewer if there are already lots of CPU-bound threads), so you minimise number of context switches.
This is effectively what an N:M scheduler does, but is slightly better. With an N:M scheduler, you are switching between some threads in userspace, which saves some overhead, but the threads still have largely-disjoint working sets and so you end up with more cache churn (performance killer on modern CPUs). With GCD, you will only be switching between work queues in a given thread between blocks, so there is no cache churn (the old block's cache lines are no longer needed, so you'll kick them out but not then bring them back in immediately). The other nice side effect of this is that, because GCD knows which work queues are assigned to which threads, it can remove locks used for passing messages between work queues if both queues are in the same threads.
In short, it's an N:M threading model with preemptive kernel threads and cooperative userspace threads. If you read an OS textbook, you'll see that this is, at least in theory, about the most efficient scheduling model possible.
I am TheRaven on Soylent News
That's not quite correct. There are two parts to GCD: libdispatch and the kernel support. The kernel support is MIT license, so is compatible with GPL.
Assume you're going to distribute a large program on an embedded device, with paper documentation along with it.
Assume a program put together with pieces from five hundred of other sources, following the promise of open source.
Assume these sources are all licenses with the GPLv2. How many pages of documentation do you need to distribute with the embedded device to comply with the license?
Assume these sources are all licensed under different variations of the MIT/BSD license. How many pages of documentation do you need to distribute with the embedded device to comply with the licenses?
What extra cost do you think this adds to each device sold?
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I am TheRaven on Soylent News
"All" including the in-house closed-source stuff they paid a huge bunch of coders to write, or do you think that literally everything Apple turns out is just "polished" OSS material with a fancy GUI on it?
I think the GP's context is that "professional" in this term means "coders who do it for a living" rather than just as a hobby, or a professional who contributes to OSS in their spare time. I know it's clearly not that simple, but I don;t think the inference is that OSS coders are not professionals, just that they don't get to spend as much time on non-commercial projects in most cases (excepting things like Firefox, or something like Open Office or other 'keynote' large, supported projects).
Apple have released a lot more to the FOSS community than they were "forced to" by the licences - in that respect they are similar to other big fishes like IBM and even Microsoft (shock horror).
So sure, Apple haters will jump on "Webkit came from KHTML, they *have* to release changes!" (read: they wouldn't if they could find any legal way around it) and ignore things that they did write in house and open source with no prodding. libdispatch just happens to be one of those things.
I seem to remember something about loggerheads from both Apple and the KHTML team on those source code releases. Like two tigers in a room trying to decide how to cook a goat.
When is the last time that Apple released an entirely new project?
The "last time" would be the very subject of this article.
(this has improved)
Yes, let's leave this in parenthesis and pretend it never happened, pretend they never turned KHTML into one of the most successful open source projects, across many platforms, and endlessly complain about something that happened for a few months while Apple was setting up their real project.
In actual fact, they *did* chose not to ship with zfs support, and still provide their source.
Uh, yes? Sure, you *made* them give up their source if they used your project, but that doesn't change the fact that they *did* use your project, and then contribute back hundreds of thousands of improvements. Or are you suggesting that khtml without apple's assistance would be in the position WebKit is now?
Actually what I'm saying is that just because they play by the rules doesn't make them special.
That's kinda the point I'm making. FOSS zealots single out apple as *being* special. They tend to regard them as a special kind of evil, while in reality, they're both contributing back to the projects they are involved in, *and* starting more projects of their own (see libdispatch, clang, etc).
In the mean time... When is the last time that Apple released an entirely new project?
You do realise this article is *about* apple releasing the source code to libdispatch?
You do realise that Konquerer is moving to WebKit, from apple's svn repository? How do you think google contribute code to WebKit? Through the magical monolithic-patch portal?
It goes further and deeper(and uglier) than that. Remember when Apple released the G5's? Apple actually submitted patches to GCC, but they were declined, with GCC's official stance being "It would reduce GCC's portability". However, a few weeks later, IBM submitted some patches for GCC, that were summarily accepted. IBM's patch package contained many of Apple's patches for GCC.
Ars Technica has a great explanation on Grand Central Dispatch (GCD), and how LLVM and OpenCL fits into the grand scheme of things:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Note: all links from same article, which is 23 proper pages long (not 5 line jobs).
Jumpstart the tartan drive.
You know, part of the problem with the FOSS world sometimes is the fixation on "new, shiny, awesome". Sometimes it's more important to do that last 1% that turns a great idea, and cool neat project into something production quality.
/. too. This story, however, happens to be about Apple (and, amusingly, them releasing the source to something *new*).
Refinement, improvement, and stability fixes are all things that are the least sexy for FOSS devs to donate their time towards, and some of the most useful things for their users. A lot of that work is done by people being *paid* to work on that software, like, say, by Apple!
Is apple the only one? Of course not! When Sun releases something impressive, or IBM, or Intel, or.. etc we have a sotry about that on
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
See this page on Ars Technica for an explanation: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
Jumpstart the tartan drive.
While it's true that some signs point to KDE migrating to WebKit at some point,
a) KHTML will _not_ be removed before KDE 5
b) WebKit has still a long way to go. I just submitted half a dozen bugs to Qt.
c) KDE will move to WebKit from Qt, not Apple
Not sure how your Google comment relates to anything I said, though. Unless you missed me talking to the past tense in the earlier post ;)
a) How am I pretending it has never improved? I even say so in what you quoted :)
b) KHTML was very successful and widely in use before WebKit forked off
c) Endlessly? Others would say I am pointing something relevant and new out in a discussion about a particular topic, but hey..
d) A few months? While poor Apple was setting up stuff? Reread what I said about several releases.
Do I get a prize for being trolled by an Apple fanboy, now? I think this was my first time..
when we start using octal cores
High end workstations are already shipping with dual quad (8 cores total) and will probablly be shipping with dual hex (12 cores total) in the not too distant future. Quad core is fairly common in the midrange and is even available on some fairly low end machines (e.g. the dell vostro 420). Laptops and low end desktops are generally shipping with dual cores.
With the exception of nettops and netbooks single cores are pretty much history.
The bottom line is that cores aren't getting that much faster so most of our gains in computing power are likely to come from more cores and software that needs to get the most out of CPUs is going to need to embrace that and soon.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Because professional coders are the only people who contribute to open source, right?
Um, KHTML was not in wide use, at least nowhere even remotely close to Webkit today. Konqueror had diddly squat for marketshare.
Where do you think WebKit from Qt comes from? Oh yes... Apple's svn servers >.
Google relates to this because they too are working on web kit's svn in writing chrome.
Several projects used it, but yes WebKit made usage explode. Still, KHTML has been successful before WebKit, as well.
Where do you think WebKit from Apple comes from? Oh yes... KDE's svn servers >.
The point is that while Apple, Qt, Google etc will certainly work together, the code level I care about and with which I am familiar with when it comes to community, reporting, etc is Qt, not Apple. Apple may or may not merge back what Qt does to fix WebKit from KDE's pov, but as Apple has been known to make strange usability decisions, I'd rather not bet onto it.
As an aside, no one would have stopped Apple from contributing to KHTML. Instead, they decided to fork the codebase before doing anything else. Maybe understandably so from a business level, but certainly not so much from a code level.
Which is, by the way, the reason why I don't care for Apple's WebKit, either: They did not extend the same courtesy to "us".
Where do you think WebKit from Apple comes from? Oh yes... KDE's svn servers >.
No, they don't, webkit's svn repository is at http://svn.webkit.org/repository/webkit/trunk.
Now go whois that domain, and tell me who owns it?
The point is that while Apple, Qt, Google etc will certainly work together, the code level I care about and with which I am familiar with when it comes to community, reporting, etc is Qt, not Apple. Apple may or may not merge back what Qt does to fix WebKit from KDE's pov, but as Apple has been known to make strange usability decisions, I'd rather not bet onto it.
No, the point is, you're trying to slag off apple saying that they don't give back the source code in any usable form, and yet, there, sat right in front of you is apple's svn server containing the authoritative source for WebKit.
At a guess, you'll be complaining that their bug database isn't open yet... which... yep, you guessed it, it *is*.
https://bugs.webkit.org/query.cgi?format=specific&product=WebKit
People keep spreading FUD about how much of a bad citizen apple is being with WebKit, and yet, there are at least two companies (nokia and google) and a large open source project (Qt) interacting with them quite happily.
What I meant is "where did it come from originally". The point you are missing is that while Qt syncs WebKit from upstream on a more or less regular basis, but they keep the right to have their own local modifications. Just as WebKit did with KHTML.
> No, the point is, you're trying to slag off apple saying that they don't give back the source code in any usable form, and yet, there, sat right in front of you is apple's svn server containing the authoritative source for WebKit.
No, I am saying that for years, they went fuck all and did _not give a damn about anyone except themselves_. There was no public SVN. All there was were monolithic tarballs every time OS X was released in a new version.
Things may have changed, and in fact, they have. But there is no reason to forget the past. Apple is not the bunch of nice altruists you want to make them appear as.
They play hard ball when they think it benefits them (iTunes, iPhone, iPod, WebKit in former times) and play nice when they think it benefits them (WebKit today, Grand Central).
It is their privilege do so as they are a distinct entity on the marketplace with internal decision processes. This may not be the best for the community or humanity at large, but it is their privilege to do so.
Same as it is the privilege of the community at large to remember this fact and base future decisions on the past behaviour of other entities, be they Apple, MS or Oracle.
> People keep spreading FUD about how much of a bad citizen apple is being with WebKit, and yet, there are at least two companies (nokia and google) and a large open source project (Qt) interacting with them quite happily.
Au contraire. I refuse to to stop spreading factual and easily proven facts about Apple's _past behaviour_ when people seem to forget what history WebKit has. Counting Nokia and Qt separately does not make sense, btw ;)
In any case, this will be my last post regarding this topic as we clearly will not be able to agree on anything.
My experience is that its no more likely to crap out than linux when installing, and if anything less likely, as there tends to be less "automatic" guessing of where/how to install by the installer.
Its text mode, but it works. GUI installers look pretty, but they're not inherently any better just because they look nice.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Thank you for the great response. May the meritocracy work this out.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The roads?
I drank what? -- Socrates
Tigers don't cook goats. They pretty much eat them as they catch them.
I drank what? -- Socrates