Er. If they called it "pussy", people would likely realize that it was costing them $129, and would finally complain about the price of the update.:)
There's a lot of really random comments, here.
on
Passport to Nowhere
·
· Score: 3, Informative
Time to clear this up.
1) Liberty Alliance protocols aren't about setting up a single auth provider that the world uses to authenticate you: It's a way of businesses and sites to create an agreement to allow each other to cross-login, or to support logins from foreign systems. Any site wishing to turn its login system into an Identity Provider is free to do so - other sites can then use that federated identity.
2) Liberty Alliance protocols don't require that one central identity hold all information. Each service provider has a local account which can hold information specific to that service without requiring your private information to be shared indiscriminately.
You can Liberty-enable a set of websites today. This can be done transparently to users, and is about businesses sharing sign-ons and authentication information without actually having to share your data. Site X doesn't need to have your account information, or your password; it can find out from the identity provider enough information to know whether you've been authenticated, or direct you over to them to authenticate safely.
Read the docs, folks. It's not Passport. It's not even really *like* passport, in its intended use. It's real, it's implementable, it serves a real purpose, and it's going to be BIG.
It's not vapor folks. The fact that you may not *see* the fact that your name is getting federated across a set of services as a federated namespace in Liberty has nothing to do with whether or not federated names are in use.
We're just about to ship, transparently, a Liberty architecture here - and we're doing so internally amongst ourselves and our assembled services. There's nothing vapor about the technology.
The fact that there's no pretty website offering a "Passport" to be used anywhere on the internet for Liberty is missing the point: that isn't what Liberty is all about. The fact that you could has nothing to do with whether or not you *would* do so.
I mean, let's be honest. If you write JSPs, you think of yourself as a java programmer; if you go to university and take a Java 101 course, you think of yourself as a java programmer.
The first time you end up in a real project, you're doomed. The idea that 68% of the people who identify themselves as java programmers either wrote a bunch of JSPs, or took a few java courses and did the coursework for it, isn't exactly shocking.
And given that it's Gartner we're talking about, a group of people who, throughout the dot com boom, exaggerated in the *extreme* the potential markets of a broad range of subjects, I wouldn't be surprised to find that the numbers are actually not as pessimistic as those made out; but that's just the nature of reports like this and those of other research groups - they're research. They represent reality in the same way as every other abstraction: they're a generalisation.
The truth is probably more complicated and interesting.
Not necessarily. The technology being chosen is a combination of native code - which can do any necessary 'transitions' to a 'normal' endian mechanism at the API boundary between WINE and the application - and the emulator in question.
The emulator in question is based on something similar to the FX! Alpha code recompiler; it provides an execution environment, yes, but also dynamically recompiles code into native.
Between the core Windows libraries being "native" (in that they're wine lib, and therefore PPC-compiled native on OSX, not native x86) and the remainder in this 'recompiled' code execution environment, it's possible to strip out much of the endian issues.
Not saying they will - only that there's a lot of room to manoeuvre here.
Free.fr, where the project is hosted, is (of course) being slashdotted.
One of the performance metrics lists the QEMU version of gzip (x86 on PPC) being 5 times slower than native (for example) - and comparison to bochs put bochs well behind (however, qemu had no MMU emulation).
let's look at it as a wake-up call. This is the *one* area of open source development that the movement has not solved: A central, 'open source' authority/patent-holder to which we can safely patent ideas and hand over that patent to.
Anything that we do could be patentable; individuals with enough money could file for that patent, and hand that patent over to the 'open source' patent provider, who could then ensure that this would be free for us to use in perpetuity.
*THEN* we can start to use the patent system against our competitors, the closed-source world.
Until then, *someone* has to take that patent; whether it be someone with good intentions or bad intentions, it will go. Without some way of ensuring that we can keep 'open source' ideas patented and open to all, we've got no way, short of lengthy court suits and 'prior art' proof, of defending ourselves.
I can read my Software Update window, thanks.
on
iCal 1.5.2 Released
·
· Score: 1, Funny
Good god, talk about Slow News Day. It's an insignificant point release. They turned a drawer into a bleeding panel, not water into wine.
Pixar was feeling around a while back to see whether or not there was interest in getting RenderMan back to the Mac. (Once upon a time, yes, it was on the mac.:)
But it wouldn't be 'better' than Maya - Maya's strength isn't in its renderer, it's in the modeller. The renderer's not bad, but it can generate RIB format data, and is a world-class modeller if you're using it to create scenes to be rendered in RenderMan-compliant renderers.
More of a Mental Ray vs RenderMan thing, really. There's competition there. But the procedural nature of RenderMan's textures and the world - along with being what makes it so difficult to master - is what makes it beautiful and unique. RenderMan's shader language is bizarre and wonderful, both in terms of scope and capability. All of this new 'procedural texture' stuff in current-generation 3D hardware owes an awful lot to RenderMan's shader language.
But it's worked out pretty good, hasn't it. Let's be honest - the product has come along a lot faster now that they're not maintaining multiple platforms.
- GarageBand: Basic, entry-level music production. Supports "Apple Loops", a format of sample loop data. Ships with buttloads of plugins - more than Logic do at the moment, quite frankly - and has what appears to be an incredible sample and synthesis engine. Looks like baby versions of the ones to be included in Logic, actually.
- Soundtrack: Audio editor/compositor, and loop manager. Supports loop-based audio editing, playback, and scoring. Supports video-scoring, which makes it good for doing video work with; one of the reasons it's shipped with Final Cut Pro 4. It is designed to be exactly what the name says: A supporting role for soundtrack creation, where the music, or its pieces, are already composed and prepared. While it supports composing, composing isn't its primary feature - and on the whole, GarageBand or Logic will be a better choice. If you need MIDI, GarageBand or Logic are your only choice.
Logic: Entry-level pro editing... Comes with a playback-only version of the sampler (so no sample editing) and all of the other things that Logic Audio has traditionally shipped with. Unclear as to what other new functionality will be provided. GarageBand eats into this product on the low-end, with its additional plugins and support for the amp, but Logic has a lot more high-end features that you'd use if you spent a lot of time producing music, while still offering all of the basic capabilities that GarageBand does (except the plugins - but one can successfully argue that this market isn't necessarily going to mind).
- Logic Pro. Everything that was in Logic Audio Platinum. Along with every plugin you used to buy separately, for another $1000. Basically, everything EMagic ever produced, in one box, with everything that apple's produced alongside them for the new series. The Rolls Royce of systems, by a very, very, very long way.
Hell, that reverb alone is pretty much worth it.
-
XLC's code generation makes it worthwhile for two features: auto-vectorisation, where it will attempt to organize and discover vectorizable code and use AltiVec to process when/where possible, and for OpenMP support, which allows you to tell the compiler that a given section of code *can* be run in parallel, and how to divide the task amongst CPUs; the compiler takes care of setting up threads on the CPUs, etc., and doing the actual work in parallel, while your code stays nice and tidy.
The long answer is yes. The short answer is yes.:) XCode as an IDE is a long way from perfect, but the compilers are rock-solid dependable, and XLC's a great code generator.
As there's work going into XCode to ensure that any project can specify which compiler it uses on a target-by-target basis, I fully expect we'll see several core projects in the Darwin codebase switch over to using both compilers (where XLC will be used to compile specific branches) in 10.4.
OpenMP, at app-level, is pretty much guaranteed to get some use, and Apple will very likely spend some time in the vec/math libs fully OpenMPing that code to get parallel use of both CPUs.
CoreGraphics would probably get some small, critical sections built with it, but it's much more difficult to figure out how to get good benefit out of OpenMP code in those circumstances.
Anything else introduces problems; OpenMP will spawn off threads to do work, and if those threads start accessing code that isn't actually MT safe and/or fully reentrant at that level, it's going to get zero beneift.
"binary' refers, indeed, to the binary compatibility of object files; in GCC terms, when there's an "ABI" change, you have to re-compile all applications, as new stuff compiled in the new Application Binary Interface can't access stuff compiled in the old ABI.
What it REALLY means:
1) You can compile the majority of your application in GCC, and selectively compile in IBM's XLC.
2) You can compile one library in XLC, and link it in to your GCC application.
3) You can compile a library in GCC, and link it in to your XLC application.
Etc. You get the point. Essentially, while the code they generate is very, very different in terms of optimization and performance, they are, in fact, completely interchangeable in terms of the things they produce as output.
XLC is, in fact, a very different beast than GCC. The number of optimizations it provides goes well beyond what GCC currently provides, and does include auto-vectorization and support for OpenMP - things which don't suck on parallel systems.
So XLC is a good thing for commercial software developers, and at minimum, the compatibility of the systems means that we as developers have no excuse not to be compiling, at bare minimum, the most *important* functions (and if we're doing it this way, it might as well be specific functions) in XLC, and link in that parallelized and optimized object file into our existing project.
As for commandline switches... nope. Almost never compatible. No hope. Basic stuff is mildly similar, but the guts you'd use once optimizing are very different.
But at a high level, yes, you just say xlc -O3 instead of gcc -O3, only you might say xlc -O5.
Re:If the dock had been introduced back in the day
on
Tog Takes on Mac OS X 10.3
·
· Score: 2, Informative
Sidenote: NeXTStep, from day one, was multi-user compatible, and ran many more than one application at a time in perfect multitasking under a mach-based kernel.
Mac OS, in any incarnation, did not support any kind of 'multi-application usage' which required things like notification when background apps needed your attention, and the like, until the MultiFinder hacks and the official release of MultiFinder. Far from being a decade and a half old, Apple released MultiFinder in 1987.
Now, as Jobs had been kicked out by then, you'll find that NeXT was founded one year before this, and NeXTStep's revolutionary dock was basically part-and-parcel a part of the system as of its release, with that beautiful black cube, in 1988.
So not only has MacOS not really been doing it longer - but MacOS wasn't designed, really, for multiple applications to be used anything like simultaneously, to a degree where it might actually need this kind of UI design.
And in the version of MultiFinder that was released at the time, open applications where in the *APPLE* menu. Only Mac OS 8 added, through an *extension*, the Application Switcher.
Erm. So, maybe it wasn't so new. Matter of fact, maybe the NeXT boys *did* get there first after all. And, erm, maybe, in fact, they got it right.:)
It is not clear that WMA DRM, as implemented by PortalPlayer's core firmware, would be compatible with all of the current implementations of DRM being used in all of the storefronts, nor which versions of WMA audio codec are supported in the iPod's various PP families.
The Golden Prize of Next-Generation Codecs...
on
No WMA for HP iPod
·
· Score: 1
Goes to whichever open-source team can develop a codec optimized *for re-encoding*.
The trick, as always, is to know enough about the source format's mechanisms of encoding, and problems, to only assume significant information in the areas of the stream where the codec performs well, and not spend as much time trying to model and integrate what is, in fact, noise created by the compression process.
Someone do that to OGG, and watch the world flock to it. Because we need something for all of this commercial DRM'd music to be downcoded to so that we can remove the DRM for our own fair use - if for nothing else, then for backup purposes - with, ideally, no loss of quality from the original encoding form through a careful understanding, on the codec's part, of which parts of the audio stream have the significant bits.
No, that's absolutely right: The customer does not know what "DRM" means.
But you can *BET* that the customer knows "I can only play this song on one of three computers I've registered with Apple for listening to this" when he buys commercial music on Apple's FairPlay DRM.
You can bet that the WMA-purchasing other guy also knows that he can't bring those locked WMA files to his office and put them on the office MP3 server, because they're locked to *one* machine.
You can bet that the third guy knows that if he, at any point, ceases to pay his monthly fee, all his WMA-DRM'd music just vanishes.
Reason one to avoid "WMA": The customer doesn't know what DRM is. The fact that WMA's most well-known DRM mechanisms currently in use are draconic at best is the first and foremost reason not to associate yourself or your products with that marketing name, let alone that music format.
Congratulations, you've successfully missed a point. Question: Are you really of the opinion that the most important point, the one worth arguing with, was the date of publication? Or are you just saying you agree with the remaining, obviously non-controversial elements in that post.
JAVAHurt, as referenced, is an article entitled "How java's Floating-Point Hurts Everyone Everywhere", and was presented in 1988. Many of the arguments it contains no longer applies - though not all.
1.5 has major improvements to java.lang.Math and java.lang.StrictMath that bring performance in line with libm, and correct rounding precision issues with BigDecimal.
1.5 includes static imports - meaning that you can import all of the static functions, allowing sin(x) instead of Math.sin(x) if you're a freak about that issue.
1.5 also improves a lot of the math capabilities. So while this kind of slating may be fuzzy feel-good, it's also one that's well on its way to being a solved problem, and in many of the arguments made, has already been corrected.
Try reading up on the Java Grande tests that issues like his were meant to benchmark, address, and solve.
Changes in 3.0 go a long way towards fixing the dot-completion handling; and the way they've implemented refactoring and global import optimization, as well as auto-fix for found problems, is a definite, definite time-saver.
The only thing missing yet is 'auto-fix' for groups of errors, and that's meant to be coming soon.
Everyone had to know, all along, that it would be very difficult for Sun to support Eclipse when Eclipse is not 100% java. It's marketing seppuku - proof that big applications would need native code to really work.
The fact that there's truth in that is all the more reason for Sun to not get anywhere near it. You only need to use netbeans for a day, and switch back to Eclipse, to really see the difference in UI performance. Sun can change that, over time - it may improve the performance of Swing, and a Swing that rendered native could indeed be built (and has been done - by Apple - so it does work and work well).
Whether or not Sun will bite? Who knows. Future versions of java on Linux are said to indeed use a GL canvas for some rendering. I'll say this - it's going to be a tough slog for Sun to get the JDK up to par with what SWT does today in terms of native performance; and any advance they make to the JDK immediately provides the opportunity for SWT to improve its own performance through similar API.
I'll say this though: Everyone should have seen this coming. IBM isn't going to budge from its native direction, as it's practical, and Sun can't possibly go down that road. The two architectures are so fundamentally different that it's nigh-on impossible to imagine them merging, especially when IBM is going through such huge core changes in the way that plugins are soon to be dynamically loaded and unloaded from the core through OSGi.
Sun doesn't stand a chance; it's unfortunate that they're unable to move out of the way of that oncoming train, from NetBeans as market-leader to lagging well behind.
Actually...
First time I remember seeing anything like this was from a company called FullCircle, who had a bug reporting tool that Netscape had packaged up into its client and called it the Netscape Quality Feedback Agent - but it was indeed FullCircle.
Those crash reports got logged, and people actually did go through on a regular basis, especially after beta releases and milestone releases, and go looking through at all of the top crashers; top crash analysis days were regularly held, and people did honestly get a lot of useful information out of these crash reports.
I sincerely wish there was something like this in open source land; something that tracked all of the crashes and created crash logs in open source software, that we could all use in our software.
Hell, just imagine how much quicker games like EverQuest, WOW, or Shadowbane would get fixed if we didn't have to go through the headache of manual reporting to guarantee any kind of report whatsoever; if the company knew, within hours of a software release, that their software release was utterly fscked. (Which Netscape did, on occasion.:)
Yes, but unless they open the source to the SDK, there's no way we can get the kind of cross-platform support we'd need to use it in, say, CrystalSpace.
I've done some work to a VFS implementation that treats bits of the local filesystem as 'cache' and checks the contents of the remote server for updates for each file; and while this works in specific cases, it's not a replacement for a general updater for an application. Something like this would be a great boon to the open source dev community.
But there's just no way I could consider it unless it's open-sourced at the SDK level, and not just an open API.
That would kill off their commercial ideas, unfortunately, IMO, and as such, I doubt they'll do it. Hopefully, though, it'll spur someone else into doing the job.
Slashdot Mirror
Er. If they called it "pussy", people would likely realize that it was costing them $129, and would finally complain about the price of the update. :)
Time to clear this up.
1) Liberty Alliance protocols aren't about setting up a single auth provider that the world uses to authenticate you: It's a way of businesses and sites to create an agreement to allow each other to cross-login, or to support logins from foreign systems. Any site wishing to turn its login system into an Identity Provider is free to do so - other sites can then use that federated identity.
2) Liberty Alliance protocols don't require that one central identity hold all information. Each service provider has a local account which can hold information specific to that service without requiring your private information to be shared indiscriminately.
You can Liberty-enable a set of websites today. This can be done transparently to users, and is about businesses sharing sign-ons and authentication information without actually having to share your data. Site X doesn't need to have your account information, or your password; it can find out from the identity provider enough information to know whether you've been authenticated, or direct you over to them to authenticate safely.
Read the docs, folks. It's not Passport. It's not even really *like* passport, in its intended use. It's real, it's implementable, it serves a real purpose, and it's going to be BIG.
It's not vapor folks. The fact that you may not *see* the fact that your name is getting federated across a set of services as a federated namespace in Liberty has nothing to do with whether or not federated names are in use.
We're just about to ship, transparently, a Liberty architecture here - and we're doing so internally amongst ourselves and our assembled services. There's nothing vapor about the technology.
The fact that there's no pretty website offering a "Passport" to be used anywhere on the internet for Liberty is missing the point: that isn't what Liberty is all about. The fact that you could has nothing to do with whether or not you *would* do so.
I mean, let's be honest. If you write JSPs, you think of yourself as a java programmer; if you go to university and take a Java 101 course, you think of yourself as a java programmer.
The first time you end up in a real project, you're doomed. The idea that 68% of the people who identify themselves as java programmers either wrote a bunch of JSPs, or took a few java courses and did the coursework for it, isn't exactly shocking.
And given that it's Gartner we're talking about, a group of people who, throughout the dot com boom, exaggerated in the *extreme* the potential markets of a broad range of subjects, I wouldn't be surprised to find that the numbers are actually not as pessimistic as those made out; but that's just the nature of reports like this and those of other research groups - they're research. They represent reality in the same way as every other abstraction: they're a generalisation.
The truth is probably more complicated and interesting.
Let's face it. The beeb is the world's last, best hope for decent documentaries of this nature.
Not necessarily. The technology being chosen is a combination of native code - which can do any necessary 'transitions' to a 'normal' endian mechanism at the API boundary between WINE and the application - and the emulator in question.
The emulator in question is based on something similar to the FX! Alpha code recompiler; it provides an execution environment, yes, but also dynamically recompiles code into native.
Between the core Windows libraries being "native" (in that they're wine lib, and therefore PPC-compiled native on OSX, not native x86) and the remainder in this 'recompiled' code execution environment, it's possible to strip out much of the endian issues.
Not saying they will - only that there's a lot of room to manoeuvre here.
Free.fr, where the project is hosted, is (of course) being slashdotted.
One of the performance metrics lists the QEMU version of gzip (x86 on PPC) being 5 times slower than native (for example) - and comparison to bochs put bochs well behind (however, qemu had no MMU emulation).
let's look at it as a wake-up call. This is the *one* area of open source development that the movement has not solved: A central, 'open source' authority/patent-holder to which we can safely patent ideas and hand over that patent to.
Anything that we do could be patentable; individuals with enough money could file for that patent, and hand that patent over to the 'open source' patent provider, who could then ensure that this would be free for us to use in perpetuity.
*THEN* we can start to use the patent system against our competitors, the closed-source world.
Until then, *someone* has to take that patent; whether it be someone with good intentions or bad intentions, it will go. Without some way of ensuring that we can keep 'open source' ideas patented and open to all, we've got no way, short of lengthy court suits and 'prior art' proof, of defending ourselves.
Good god, talk about Slow News Day. It's an insignificant point release. They turned a drawer into a bleeding panel, not water into wine.
Meanwhile, Apple isn't going broke, so why go after the blissfully ignorant 98% who use Windows? :)
Pixar was feeling around a while back to see whether or not there was interest in getting RenderMan back to the Mac. (Once upon a time, yes, it was on the mac. :)
But it wouldn't be 'better' than Maya - Maya's strength isn't in its renderer, it's in the modeller. The renderer's not bad, but it can generate RIB format data, and is a world-class modeller if you're using it to create scenes to be rendered in RenderMan-compliant renderers.
More of a Mental Ray vs RenderMan thing, really. There's competition there. But the procedural nature of RenderMan's textures and the world - along with being what makes it so difficult to master - is what makes it beautiful and unique. RenderMan's shader language is bizarre and wonderful, both in terms of scope and capability. All of this new 'procedural texture' stuff in current-generation 3D hardware owes an awful lot to RenderMan's shader language.
But it's worked out pretty good, hasn't it. Let's be honest - the product has come along a lot faster now that they're not maintaining multiple platforms.
- GarageBand: Basic, entry-level music production. Supports "Apple Loops", a format of sample loop data. Ships with buttloads of plugins - more than Logic do at the moment, quite frankly - and has what appears to be an incredible sample and synthesis engine. Looks like baby versions of the ones to be included in Logic, actually. - Soundtrack: Audio editor/compositor, and loop manager. Supports loop-based audio editing, playback, and scoring. Supports video-scoring, which makes it good for doing video work with; one of the reasons it's shipped with Final Cut Pro 4. It is designed to be exactly what the name says: A supporting role for soundtrack creation, where the music, or its pieces, are already composed and prepared. While it supports composing, composing isn't its primary feature - and on the whole, GarageBand or Logic will be a better choice. If you need MIDI, GarageBand or Logic are your only choice. Logic: Entry-level pro editing... Comes with a playback-only version of the sampler (so no sample editing) and all of the other things that Logic Audio has traditionally shipped with. Unclear as to what other new functionality will be provided. GarageBand eats into this product on the low-end, with its additional plugins and support for the amp, but Logic has a lot more high-end features that you'd use if you spent a lot of time producing music, while still offering all of the basic capabilities that GarageBand does (except the plugins - but one can successfully argue that this market isn't necessarily going to mind). - Logic Pro. Everything that was in Logic Audio Platinum. Along with every plugin you used to buy separately, for another $1000. Basically, everything EMagic ever produced, in one box, with everything that apple's produced alongside them for the new series. The Rolls Royce of systems, by a very, very, very long way. Hell, that reverb alone is pretty much worth it. -
XLC's code generation makes it worthwhile for two features: auto-vectorisation, where it will attempt to organize and discover vectorizable code and use AltiVec to process when/where possible, and for OpenMP support, which allows you to tell the compiler that a given section of code *can* be run in parallel, and how to divide the task amongst CPUs; the compiler takes care of setting up threads on the CPUs, etc., and doing the actual work in parallel, while your code stays nice and tidy. The long answer is yes. The short answer is yes. :) XCode as an IDE is a long way from perfect, but the compilers are rock-solid dependable, and XLC's a great code generator.
As there's work going into XCode to ensure that any project can specify which compiler it uses on a target-by-target basis, I fully expect we'll see several core projects in the Darwin codebase switch over to using both compilers (where XLC will be used to compile specific branches) in 10.4.
OpenMP, at app-level, is pretty much guaranteed to get some use, and Apple will very likely spend some time in the vec/math libs fully OpenMPing that code to get parallel use of both CPUs.
CoreGraphics would probably get some small, critical sections built with it, but it's much more difficult to figure out how to get good benefit out of OpenMP code in those circumstances.
Anything else introduces problems; OpenMP will spawn off threads to do work, and if those threads start accessing code that isn't actually MT safe and/or fully reentrant at that level, it's going to get zero beneift.
"binary' refers, indeed, to the binary compatibility of object files; in GCC terms, when there's an "ABI" change, you have to re-compile all applications, as new stuff compiled in the new Application Binary Interface can't access stuff compiled in the old ABI.
What it REALLY means:
1) You can compile the majority of your application in GCC, and selectively compile in IBM's XLC.
2) You can compile one library in XLC, and link it in to your GCC application.
3) You can compile a library in GCC, and link it in to your XLC application.
Etc. You get the point. Essentially, while the code they generate is very, very different in terms of optimization and performance, they are, in fact, completely interchangeable in terms of the things they produce as output.
XLC is, in fact, a very different beast than GCC. The number of optimizations it provides goes well beyond what GCC currently provides, and does include auto-vectorization and support for OpenMP - things which don't suck on parallel systems.
So XLC is a good thing for commercial software developers, and at minimum, the compatibility of the systems means that we as developers have no excuse not to be compiling, at bare minimum, the most *important* functions (and if we're doing it this way, it might as well be specific functions) in XLC, and link in that parallelized and optimized object file into our existing project.
As for commandline switches... nope. Almost never compatible. No hope. Basic stuff is mildly similar, but the guts you'd use once optimizing are very different.
But at a high level, yes, you just say xlc -O3 instead of gcc -O3, only you might say xlc -O5.
Sidenote: NeXTStep, from day one, was multi-user compatible, and ran many more than one application at a time in perfect multitasking under a mach-based kernel. Mac OS, in any incarnation, did not support any kind of 'multi-application usage' which required things like notification when background apps needed your attention, and the like, until the MultiFinder hacks and the official release of MultiFinder. Far from being a decade and a half old, Apple released MultiFinder in 1987. Now, as Jobs had been kicked out by then, you'll find that NeXT was founded one year before this, and NeXTStep's revolutionary dock was basically part-and-parcel a part of the system as of its release, with that beautiful black cube, in 1988. So not only has MacOS not really been doing it longer - but MacOS wasn't designed, really, for multiple applications to be used anything like simultaneously, to a degree where it might actually need this kind of UI design. And in the version of MultiFinder that was released at the time, open applications where in the *APPLE* menu. Only Mac OS 8 added, through an *extension*, the Application Switcher. Erm. So, maybe it wasn't so new. Matter of fact, maybe the NeXT boys *did* get there first after all. And, erm, maybe, in fact, they got it right. :)
It is not clear that WMA DRM, as implemented by PortalPlayer's core firmware, would be compatible with all of the current implementations of DRM being used in all of the storefronts, nor which versions of WMA audio codec are supported in the iPod's various PP families.
Goes to whichever open-source team can develop a codec optimized *for re-encoding*. The trick, as always, is to know enough about the source format's mechanisms of encoding, and problems, to only assume significant information in the areas of the stream where the codec performs well, and not spend as much time trying to model and integrate what is, in fact, noise created by the compression process. Someone do that to OGG, and watch the world flock to it. Because we need something for all of this commercial DRM'd music to be downcoded to so that we can remove the DRM for our own fair use - if for nothing else, then for backup purposes - with, ideally, no loss of quality from the original encoding form through a careful understanding, on the codec's part, of which parts of the audio stream have the significant bits.
No, that's absolutely right: The customer does not know what "DRM" means. But you can *BET* that the customer knows "I can only play this song on one of three computers I've registered with Apple for listening to this" when he buys commercial music on Apple's FairPlay DRM. You can bet that the WMA-purchasing other guy also knows that he can't bring those locked WMA files to his office and put them on the office MP3 server, because they're locked to *one* machine. You can bet that the third guy knows that if he, at any point, ceases to pay his monthly fee, all his WMA-DRM'd music just vanishes. Reason one to avoid "WMA": The customer doesn't know what DRM is. The fact that WMA's most well-known DRM mechanisms currently in use are draconic at best is the first and foremost reason not to associate yourself or your products with that marketing name, let alone that music format.
Congratulations, you've successfully missed a point. Question: Are you really of the opinion that the most important point, the one worth arguing with, was the date of publication? Or are you just saying you agree with the remaining, obviously non-controversial elements in that post.
JAVAHurt, as referenced, is an article entitled "How java's Floating-Point Hurts Everyone Everywhere", and was presented in 1988. Many of the arguments it contains no longer applies - though not all. 1.5 has major improvements to java.lang.Math and java.lang.StrictMath that bring performance in line with libm, and correct rounding precision issues with BigDecimal. 1.5 includes static imports - meaning that you can import all of the static functions, allowing sin(x) instead of Math.sin(x) if you're a freak about that issue. 1.5 also improves a lot of the math capabilities. So while this kind of slating may be fuzzy feel-good, it's also one that's well on its way to being a solved problem, and in many of the arguments made, has already been corrected. Try reading up on the Java Grande tests that issues like his were meant to benchmark, address, and solve.
Changes in 3.0 go a long way towards fixing the dot-completion handling; and the way they've implemented refactoring and global import optimization, as well as auto-fix for found problems, is a definite, definite time-saver. The only thing missing yet is 'auto-fix' for groups of errors, and that's meant to be coming soon.
Everyone had to know, all along, that it would be very difficult for Sun to support Eclipse when Eclipse is not 100% java. It's marketing seppuku - proof that big applications would need native code to really work. The fact that there's truth in that is all the more reason for Sun to not get anywhere near it. You only need to use netbeans for a day, and switch back to Eclipse, to really see the difference in UI performance. Sun can change that, over time - it may improve the performance of Swing, and a Swing that rendered native could indeed be built (and has been done - by Apple - so it does work and work well). Whether or not Sun will bite? Who knows. Future versions of java on Linux are said to indeed use a GL canvas for some rendering. I'll say this - it's going to be a tough slog for Sun to get the JDK up to par with what SWT does today in terms of native performance; and any advance they make to the JDK immediately provides the opportunity for SWT to improve its own performance through similar API. I'll say this though: Everyone should have seen this coming. IBM isn't going to budge from its native direction, as it's practical, and Sun can't possibly go down that road. The two architectures are so fundamentally different that it's nigh-on impossible to imagine them merging, especially when IBM is going through such huge core changes in the way that plugins are soon to be dynamically loaded and unloaded from the core through OSGi. Sun doesn't stand a chance; it's unfortunate that they're unable to move out of the way of that oncoming train, from NetBeans as market-leader to lagging well behind.
Actually... First time I remember seeing anything like this was from a company called FullCircle, who had a bug reporting tool that Netscape had packaged up into its client and called it the Netscape Quality Feedback Agent - but it was indeed FullCircle. Those crash reports got logged, and people actually did go through on a regular basis, especially after beta releases and milestone releases, and go looking through at all of the top crashers; top crash analysis days were regularly held, and people did honestly get a lot of useful information out of these crash reports. I sincerely wish there was something like this in open source land; something that tracked all of the crashes and created crash logs in open source software, that we could all use in our software. Hell, just imagine how much quicker games like EverQuest, WOW, or Shadowbane would get fixed if we didn't have to go through the headache of manual reporting to guarantee any kind of report whatsoever; if the company knew, within hours of a software release, that their software release was utterly fscked. (Which Netscape did, on occasion. :)
Yes, but unless they open the source to the SDK, there's no way we can get the kind of cross-platform support we'd need to use it in, say, CrystalSpace. I've done some work to a VFS implementation that treats bits of the local filesystem as 'cache' and checks the contents of the remote server for updates for each file; and while this works in specific cases, it's not a replacement for a general updater for an application. Something like this would be a great boon to the open source dev community. But there's just no way I could consider it unless it's open-sourced at the SDK level, and not just an open API. That would kill off their commercial ideas, unfortunately, IMO, and as such, I doubt they'll do it. Hopefully, though, it'll spur someone else into doing the job.