So what, "Here's our source tree" is obfuscation? That's a pretty extreme position to take.
I suspect it's more of a cultural clash. To someone being paid, being told to take the patches from the source tree is a minor irritant at best. For a volunteer, any extra effort streches allready scarce donated time.
A lot of their changes make no sense to merge. They do lots of things to ahve the compiler fit with their development and library model, which is quite a bit different from how everyone else does things.
And some Apple patches, especially with regards to Objective-C, have made their way into GCC. Maybe they could be doing more, but they're allready doing more than many corperations of their stature.
Maybe the grandparent post was referring to the use of the Alivec? You can do lots of single-precision floating point operations at once.
I don't think there is anything more you can do, but you can't deny the amazing speed with which the Altivec can get certain operations accomplished. I've personally experience a scenario in which it was feasible to do a more accurate approximation because the Altivec made it easy and fast.
So, maybe speed can translate into ability when you look over a given unit of time? I dunno.
Oh, and the 970fx has about a hojillion registers when compared to the x86 world. The grandparent was right about that. I'm hoping that the GCC4.0 optimizations that Apple and the GNU teams have been working on will better leverage an architecture with strict alignment rules, more registers and a powerful vector unit.
The original Bondi iMac was what pushed USB into the mainstream. No one was doing it, then Apple pushed it with their iMac, and then everyone realized what a great idea it was.
Apple is on the ball with some things, but not others. It's fine to criticize them about PCI Express and their video cards and heck, even SATA. But USB? Bzzt.
There are people who still maintain, track, and use the Linux 2.2 kernels, even to this day. There are also people who make linux distributions that are stripped right down to the bare minimum, and then add software on as needed.
As a platform for millions of dollars worth of software, this is the only sane way to go.
As for MS extended support? They offer it for some things, not others. And it's very expensive. FOSS OS's would help the Air Force mitigate the long-term expense of keeping their mini-linux distro up to date, because other groups (probably within the government itself!) would be working on similar problems.
AIX is a spawn of purest evil. A cul-de-sac of closed source, vulnerabilities, expensive hardware, and incompatibility. It is a bit better now. But years ago it was even more unimaginably horrible. The old system we're replacing was built mainly on AIX mainframes. There is a reason we're replacing them.
You know an OS is bad when even its original vendors are dumping it. IBM is moving to supporting a FOSS Operating System, along with everyone else, because it's the only sane route to take these days.
MS is not at fault for not keeping win2k running for enternity for you. I agree that is a tough problem you are in...but it is not the fault of closed source software...
Well, it is in the sense that we based our platform on a closed system, and now we're being hurt by the nature of that closed system. If we decided on linux, then the process of sustainment would much cheaper, would be easier (linux developers are readily available for hire), and there would be no issue here.
did any one really believe that win2k would be around forever?
Probably. It was brand-new when the specs were defined. It's more a by-product of the outdated "Thou-Shalt" design methodology. Schedules slip, slip again, and suddenly your target platform is end-of-lifed.
Hey, look at that. One example is both a FSF plug and a plug for agile development methodologies. I should get a blog. People eat this stuff up. I'm sure I could make bank selling the RSS feeds. (*pokepoke*@daringfireball)
I know I'm supposed to represent LMCO in a positive light when I talk about them in public, but honestly I can't see why they made this choice. It's hurt us in so many ways... it's hard to even express. It was a dumb decision, especially in light of this EOL news.
Despite that, I'll defend them a little. Often LMCO's decisions on what to deliver are direct results of the Air Force's mandates. They are the customer, and you know the contract worker's age-old adage: "Customer Is Always Right. Especially When They're Rich, Wrong, and Willing To Sign a Cost-Plus Contract."
So in LMCO's defense, the Air Force wanted AIX or a Windows Flavor. We gave them the lesser of two evils.
How wrong you are. You are free to choose whether or not to use a product based on all factors, such as the license, format restrictions, etc. You are always free to not buy it, and either do without, or purchase a competing product that satisfies your requirements.
Strictly speaking, that is correct. However, there is a twofold problem with this approach:
Firstly, many consumers simply aren't educated in the issues we're talking about. They do not know, they do not care to know. They'd probably be irritated if you told them. The only time they're going to care about it is when it butts right up against what they want to do.
Which leads me to problem number two. The difficulty of solving the issue is directly proportional to the amount of software out there that's legally encumbered. If we didn't make any free software, and everything was proprietary, then we'd set so many bad precedents and make so much bad and legally encumbered software that we'd be chained to the practice.
It's a simple mental excercise to see how this can come about. Please give it a shot.
Let me give you an example, from real life. If you're a US Citizen, the following story is an example of how closed software is going to cost you money by way of tax dollars.
I work for Lockheed, and thus I am a contrator for the Air Force. I work the RSA project, who's goal is to standardize software and hardware between all the different air force bases that launch things into space.
Several years ago, the decision was made to base a significant portion of the software on Windows 2000. This decision seemed fine at the time, and so the Process that the Air Force requires began to move. Specs were written, schedules drafted, software created, schedules slipped.
Now, years later, we learn that Win2k is being discontinued. This is very bad. Millions and millions of dollars have been spent developing systems around Win2k, and all that work is going to be invalidated because we can no longer get up-to-date security for our operating systems (satellite launch facilities have strict IT security policies, for obvious reasons).
If LMCO and the Air Force had chosen to use Linux as a platform, this problem couldn't occur. At any point in time, we can freeze linux, archive the source, and maintain it until the Earth's orbit around the Sun decays. Moreover, it is certain that at least a few other companies and individuals will have a similar interest in freezing at that version, so they can share efforts (or at least hire someone who can do the maint).
We have no such exit strategy for Win2k, and quite frankly the Air Force has no idea what to do. It's either going to force MS to keep supporting them (probably with huge heaping gobs of tax money) or force MS to turn over the code so that the Air Force can do it itself.
There you go. A real life example of what the FSF is trying to prevent.
No, because of how the companies handle it. MS will actively move to block you from using these APIs. I worked in a shop where I saw it done. They changed it on us by reversing the order of all parameters. That's adding insult to injury.
Every O/S has undocumented APIs.
Also untrue.
They're undocumented for a reason, often because there are strange subtleties to their operation that are hard to understand.
Or are not done yet. Or didn't make it into the documentation budget this quarter. Apple has a ton of code, but in order to release it they have to document it and agree on an interface. This doesn't always make sense to do.
If they could wave a magic documentation wand and make everything documented, I'm willing to be they would for a vast number of APIs.
But they *exist* because someone needed to do something that they *couldn't* do under the documented API. Is the Mac somehow different? Why?
Your statement is trivially true, but not very profound. Many hidden APIs accomplish things that are out of scope for other APIs. This isn't because of a deficiency in the first API, which is what you're implying with your attitude and previous posts, but rather because the of the division of responsibilities.
As an example, the Apple Data Kit that Apple uses for its Mail.app filters and its summary service is an API that does something very specialized that wouldn't make sense to put into Cocoa.
The difference is in intent and in the shape of things over time. Over time, less and less Apple APIs remain hidden. On the MS side, it's my observation that the rate of documentation is far lower. They seem busy inventing totally new APIs and making their old API's documentation more readable and accessible.
So what you're doing it coming from a Windows perspective and trying to make intelligent and topical assertions about the mac development platform.
This is a mistake. Disabuse yourself of such notions. They will get you nowhere. Apple has a very different policy towards its developers. They give as much power as they can do their developers, and the tools are so good that often applications do not need to go outside the standard APIs.
You might not believe me, because of the perspective you bring to the table. Let me try and illustrate why Apple approaches this differently:
Microsoft views third party developers as competition. Microsoft is a software company, so you compete directly with them when you write a Windows app that fufils a function they want to control. Therefore, they create hidden "advantages" in the OS that only select MS developers can access correctly.
Apple, on the other hand, is a hardware company. While OS X is a serious product for them, ultimately it's leverage to sell more computers. Therefore, they make their development tools very good, and encourage 3rd party developers. If a 3rd party developer makes a killer app, they get a direct benefit from it. This is in sharp contrast to Microsoft, who would actually lose business.
Apple's "hidden" APIs are only hidden because one one of two reasons:
They are not complete yet.
They didn't make it into the documentation budget this year.
Yes, other vectors of communication could be established. I even mentioned they allready get most of the data via a satellite uplink (along with other things that only a NOAAPort subscription will get you, like the raw data of their high detail forecast models).
The point is that many places aren't doing that. The procedure says, "Check the NOAA website for..." That's where the cost is represented. And it's not an insignificant cost and it's easy to show how expensive it is.
Combine that with the general argument that the government-gathered weather data is government property and thusly subject to standard information disclosure rules, and you're going to have a hard time getting this bill to go anywhere.
Basically, the Air Force will not let this happen. The Air Force is reliant in many ways upon the NOAA data for its forecasts.
While NOAA does make its data available over a satellite uplink (called a NOAAPort), this data is typically only used for detailed local modeling and display on AWIPS terminals. I've personally witnessed Air Force Forecasters using the NOAA website and its XML data to do their reports, and that is part of The Procedure.
Which means, it costs a huge boat of money to change, which means it costs concrete tax dollars which must be allocated to cover the costs to change. You and I might find such a change trivial, but I assure you the sheer volume of paperwork that needs to be revised, analyized, reported on and certified means that the process would easily take millions, and take years.
No. As much as Accuweather would like to stifle NOAA to turn a profit, they're too late on the scene.
I heard that G5s do object to having those NULs filled in. I don't own one to test it personally, though.
If so,it'd be nice. Those bits are reserved, but that doesn't mean that they should be unchecked.
Err, why not just buy a mac then?
on
Longhorn Preview
·
· Score: 1
Everything you're excited about is allready here:
I like the 3D enviroment and Avalon graphics (Though I still want animated program icons:-(...maybe that's just me).
Got it. 3d accelerated environment, beautiful effects and useful effects(expose).
enjoy the concept of steaming video to any window
Allready got it. Developers use the standard Quicktime libraries and they can set hardware-accelerated video to be displayed on any window. They can also do crazy things lke rotate and composite the video. No one does it because it's not terribly useful to do.
and think that eliminating the difference between web and desktop apps is great.
What do you think Dashboard is trying to do? You make desktop applets with web technologies. Heck, OSX has been working this angle for a long time with Sherlock/Watson.
I didn't like what they pulled with WinFS but if it means the final product is better, than I say fine by me.
How can a product be made better by removing one of the premiere features of the product? This is also going to impact their desktop search stuff. WinFS was part of that movement and now it's cut off (yet again).
Seriously man. The grass is pretty green over here, and gets greener all the time. This isn't an idle boast or even zealous mactivism. Everything you're mentioning is literally in Panther or about to be released in Tiger.
If Longhorn really is 2 years out, it's possible we'll see OS 10.5 by the time it comes out. Think about the position Apple is in. They've beaten Longhorn to market on a whole slew of features, and done so with at least a year (if not more!) to spare. 10.5 can continue to push forward and serve as a feature bulwark against any surprises that Microsoft might be able to come up with for the Longhorn release.
Are you really going to wait another 12-24 months for a product that's going to be released in less than one?
It has its roots not in NeXTSTEP development tools but in the terrible, terrible IDEs that Apple's OS 9 development group churned out in the past. Really quite surprisingly bad.
Having developed software for NeXTSTEP machines, I can say with confidence your statement is false.
XCode is a huge mess of compiler options, makefile thingamabobs, unnecessary cover scripts for compiling (MakeC? Why not just say gcc?), and yet it can't do basic things right, like code completion in Java, or use of CVS without requiring the developer to structure his CVS module just like XCode likes it.
XCode handles CVS just fine. Not that this is any major accomplishment. People are shifting away from CVS to SVN, and now we're seeing more distributed source control tools (Darcs, for example). Apple does have some catchup to do.
This comes from XCode trying to be the IDE That Does Everything.
Umm, what? XCode is actually a rather lightweight IDE. It does very little compared to, say... oh...I dunno... Eclipse. It compiles C, C++ and Objective-C, but that's just GCC. It does command line tools just fine, unless you're demanding autoconf-automake (in which case, too bad. They're out-of-scope).
I can understand some people being mad about OS X's Java support. All I can say is that Mono is allready getting more work than the Sun Java Runtime on OS X, and it's still young. This is because it's open source. Go bang on Sun's door to open their JVM and we'll see some serious progress. Mono is changing the rules, and unless Sun gets their game on, Java is going to be ousted from the open source world.
XCode also violates just about every conceivable Apple GUI Guideline there is. It's astonishing. My use of XCode has told me one thing is definitely true: Steve Jobs' UI Police have never bothered to click on XCode.
Developer environments have very unusual usability requirements. Nearly every IDE violates usability rules. It's because they're not-at-all like other applications. They have to jam a huge amount of functionality into a small amount of screen space to make developers happy.
Look, it's one thing to say "I had a bad experience with XCode." It's another to say, "XCode is the worst thing ever." I can't even find words to describe how juvenille calling an IDE "stupid" is in this context.
When you just want to build a damn executable it has you messing with build targets and all sorts of garbage that I will never care about.
Umm, it starts out working with sane defaults. In practice, I almost never need to mess with those settings until the very last steps of my application. Not the beginning. The only thing you might mess with in there is what libraries you link, but that's the wrong place to add them.
Sorry, but I liked my old way of working - you know, where I was productive and didn't have to learn the quirks of your stupid IDE.
You're advocating Eclipse and claim you don't have time to learn the quirks of a "stupid IDE"? Gee, that's the pot calling the kettle black, don't you think? Eclipse is one of the single most... erhem... "feature rich" products I've ever seen. Learning it is more of a chore than learning emacs, and that's saying something.
If I was ONLY developing for the Mac I might take the time to learn it.. but I'm not, so I will never waste my time on it.
XCode is-say it with me now-a OS X Application Development Environment. If you're expecting it to be something else, prepare to have those expectations failed. It can do a lot, and it's a complete, lightweight IDE with a very natural way of organizing OS X projects and integrating with IB.
... AND I still get command-line compilation if I don't feel like using an IDE that day.
It sounds like you had unreasonable expectations for XCode, and they weren't met. And now you think it's the tool's fault for being nothing more than what it is.
"not because they have vendor-lock-in".. how can you tell this?
Because the story of people using an iPod but not iTMS is all too common in my experience. I don't have a statistically significant sample, but the iPod was cool beans even before iTMS. Every time it's been exposed to a new market (first mac users, then the rest of the computing world) it's exploded in popularity.
It's an educated guess.
DRM becomes much much less evil when you can have interoperability.
DRM is evil no matter what kind of pretty face you put on it. Making it interoperable would make it no less evil.
Currently, there is no guarantee that you can use any of the iTunes songs in the future should Apple decide to stop supporting that particular DRM.
We can remove the DRM with a variety of programs. Developed by independant parties. So yes, there is a guarantee.
You may say that market forces would prevent them from doing this, but I disagree-- Sometimes the most profit lies in the path that is most destructive to the society as a whole.
If this is your concern, shouldn't you be attacking Napster? They've got a far more "destructive" sales model.
If the point of the DRM is vendor lock-in, then that is a different issue than what Congress was trying to address with the DCMA, which is currently what makes it illegal to reverse-engineer the DRM on those songs, even for interoperability..
The DMCA is evil, indeed. But TFA is talking about some competing vendors trying to use Congress to force Apple to open their format because it's supposed to somehow be "good" for the consumer. They want to make a special hole in the laws and the rules of captialism so that they can compete.
Nothing short of the removal of said DRM will be good for the consumer. You're not suddenly going to be free-as-in-bird with your music if you can play it on other players.
Apple made a great set of products, and they're succeeding so incredibly that the competition hardly even seems to be there. What Napster and Real really want is for Apple to be less successful. They don't like competition, because they aren't savvy enough to get in on it.
Slashdot Mirror
So what, "Here's our source tree" is obfuscation? That's a pretty extreme position to take.
I suspect it's more of a cultural clash. To someone being paid, being told to take the patches from the source tree is a minor irritant at best. For a volunteer, any extra effort streches allready scarce donated time.
Prototype needs docmentation badly. Probably the best way for you to learn it is to email the author and ask for some pointers.
You can also go to some Ajax-Enabled rails sites and see their source.
It's unfortunate, but that's just the way a lot of web development is these days. People just don't document they way they do in other circles.
A lot of their changes make no sense to merge. They do lots of things to ahve the compiler fit with their development and library model, which is quite a bit different from how everyone else does things.
And some Apple patches, especially with regards to Objective-C, have made their way into GCC. Maybe they could be doing more, but they're allready doing more than many corperations of their stature.
It's called Prototype, and it's available right here.
It's very well written, gets a lot of maintenance, and even has some eye candy as a bonus.
Forgive me for being slow to reply. I'm trying to throw off the wicked shivers you've given me.
Wait, you're a troll! Oh man, how did I not see that?
Man, you trolls get me good every time.
Maybe the grandparent post was referring to the use of the Alivec? You can do lots of single-precision floating point operations at once.
I don't think there is anything more you can do, but you can't deny the amazing speed with which the Altivec can get certain operations accomplished. I've personally experience a scenario in which it was feasible to do a more accurate approximation because the Altivec made it easy and fast.
So, maybe speed can translate into ability when you look over a given unit of time? I dunno.
Oh, and the 970fx has about a hojillion registers when compared to the x86 world. The grandparent was right about that. I'm hoping that the GCC4.0 optimizations that Apple and the GNU teams have been working on will better leverage an architecture with strict alignment rules, more registers and a powerful vector unit.
Please, try and remember.
The original Bondi iMac was what pushed USB into the mainstream. No one was doing it, then Apple pushed it with their iMac, and then everyone realized what a great idea it was.
Apple is on the ball with some things, but not others. It's fine to criticize them about PCI Express and their video cards and heck, even SATA. But USB? Bzzt.
Well then I never get to talk. Because according to my dusty new-hire handbook I'm representing them 24/7 as one of their employees.
No joke. Kinda disturbing.
There are people who still maintain, track, and use the Linux 2.2 kernels, even to this day. There are also people who make linux distributions that are stripped right down to the bare minimum, and then add software on as needed.
As a platform for millions of dollars worth of software, this is the only sane way to go.
As for MS extended support? They offer it for some things, not others. And it's very expensive. FOSS OS's would help the Air Force mitigate the long-term expense of keeping their mini-linux distro up to date, because other groups (probably within the government itself!) would be working on similar problems.
You have been told wrong.
AIX is a spawn of purest evil. A cul-de-sac of closed source, vulnerabilities, expensive hardware, and incompatibility. It is a bit better now. But years ago it was even more unimaginably horrible. The old system we're replacing was built mainly on AIX mainframes. There is a reason we're replacing them.
You know an OS is bad when even its original vendors are dumping it. IBM is moving to supporting a FOSS Operating System, along with everyone else, because it's the only sane route to take these days.
Well, it is in the sense that we based our platform on a closed system, and now we're being hurt by the nature of that closed system. If we decided on linux, then the process of sustainment would much cheaper, would be easier (linux developers are readily available for hire), and there would be no issue here.
Probably. It was brand-new when the specs were defined. It's more a by-product of the outdated "Thou-Shalt" design methodology. Schedules slip, slip again, and suddenly your target platform is end-of-lifed.
Hey, look at that. One example is both a FSF plug and a plug for agile development methodologies. I should get a blog. People eat this stuff up. I'm sure I could make bank selling the RSS feeds. (*pokepoke*@daringfireball)
I know I'm supposed to represent LMCO in a positive light when I talk about them in public, but honestly I can't see why they made this choice. It's hurt us in so many ways... it's hard to even express. It was a dumb decision, especially in light of this EOL news.
Despite that, I'll defend them a little. Often LMCO's decisions on what to deliver are direct results of the Air Force's mandates. They are the customer, and you know the contract worker's age-old adage: "Customer Is Always Right. Especially When They're Rich, Wrong, and Willing To Sign a Cost-Plus Contract."
So in LMCO's defense, the Air Force wanted AIX or a Windows Flavor. We gave them the lesser of two evils.
Strictly speaking, that is correct. However, there is a twofold problem with this approach:
Firstly, many consumers simply aren't educated in the issues we're talking about. They do not know, they do not care to know. They'd probably be irritated if you told them. The only time they're going to care about it is when it butts right up against what they want to do.
Which leads me to problem number two. The difficulty of solving the issue is directly proportional to the amount of software out there that's legally encumbered. If we didn't make any free software, and everything was proprietary, then we'd set so many bad precedents and make so much bad and legally encumbered software that we'd be chained to the practice.
It's a simple mental excercise to see how this can come about. Please give it a shot.
Let me give you an example, from real life. If you're a US Citizen, the following story is an example of how closed software is going to cost you money by way of tax dollars.
I work for Lockheed, and thus I am a contrator for the Air Force. I work the RSA project, who's goal is to standardize software and hardware between all the different air force bases that launch things into space.
Several years ago, the decision was made to base a significant portion of the software on Windows 2000. This decision seemed fine at the time, and so the Process that the Air Force requires began to move. Specs were written, schedules drafted, software created, schedules slipped.
Now, years later, we learn that Win2k is being discontinued. This is very bad. Millions and millions of dollars have been spent developing systems around Win2k, and all that work is going to be invalidated because we can no longer get up-to-date security for our operating systems (satellite launch facilities have strict IT security policies, for obvious reasons).
If LMCO and the Air Force had chosen to use Linux as a platform, this problem couldn't occur. At any point in time, we can freeze linux, archive the source, and maintain it until the Earth's orbit around the Sun decays. Moreover, it is certain that at least a few other companies and individuals will have a similar interest in freezing at that version, so they can share efforts (or at least hire someone who can do the maint).
We have no such exit strategy for Win2k, and quite frankly the Air Force has no idea what to do. It's either going to force MS to keep supporting them (probably with huge heaping gobs of tax money) or force MS to turn over the code so that the Air Force can do it itself.
There you go. A real life example of what the FSF is trying to prevent.
As an example, the Apple Data Kit that Apple uses for its Mail.app filters and its summary service is an API that does something very specialized that wouldn't make sense to put into Cocoa.
The difference is in intent and in the shape of things over time. Over time, less and less Apple APIs remain hidden. On the MS side, it's my observation that the rate of documentation is far lower. They seem busy inventing totally new APIs and making their old API's documentation more readable and accessible.
So what you're doing it coming from a Windows perspective and trying to make intelligent and topical assertions about the mac development platform.
This is a mistake. Disabuse yourself of such notions. They will get you nowhere. Apple has a very different policy towards its developers. They give as much power as they can do their developers, and the tools are so good that often applications do not need to go outside the standard APIs.
You might not believe me, because of the perspective you bring to the table. Let me try and illustrate why Apple approaches this differently:
Microsoft views third party developers as competition. Microsoft is a software company, so you compete directly with them when you write a Windows app that fufils a function they want to control. Therefore, they create hidden "advantages" in the OS that only select MS developers can access correctly.
Apple, on the other hand, is a hardware company. While OS X is a serious product for them, ultimately it's leverage to sell more computers. Therefore, they make their development tools very good, and encourage 3rd party developers. If a 3rd party developer makes a killer app, they get a direct benefit from it. This is in sharp contrast to Microsoft, who would actually lose business.
Apple's "hidden" APIs are only hidden because one one of two reasons:
Yes, other vectors of communication could be established. I even mentioned they allready get most of the data via a satellite uplink (along with other things that only a NOAAPort subscription will get you, like the raw data of their high detail forecast models).
The point is that many places aren't doing that. The procedure says, "Check the NOAA website for..." That's where the cost is represented. And it's not an insignificant cost and it's easy to show how expensive it is.
Combine that with the general argument that the government-gathered weather data is government property and thusly subject to standard information disclosure rules, and you're going to have a hard time getting this bill to go anywhere.
Basically, the Air Force will not let this happen. The Air Force is reliant in many ways upon the NOAA data for its forecasts.
While NOAA does make its data available over a satellite uplink (called a NOAAPort), this data is typically only used for detailed local modeling and display on AWIPS terminals. I've personally witnessed Air Force Forecasters using the NOAA website and its XML data to do their reports, and that is part of The Procedure.
Which means, it costs a huge boat of money to change, which means it costs concrete tax dollars which must be allocated to cover the costs to change. You and I might find such a change trivial, but I assure you the sheer volume of paperwork that needs to be revised, analyized, reported on and certified means that the process would easily take millions, and take years.
No. As much as Accuweather would like to stifle NOAA to turn a profit, they're too late on the scene.
It wouldn't have made it slightly harder, it would have made it much harder. Bummer.
I heard that G5s do object to having those NULs filled in. I don't own one to test it personally, though.
If so,it'd be nice. Those bits are reserved, but that doesn't mean that they should be unchecked.
Seriously man. The grass is pretty green over here, and gets greener all the time. This isn't an idle boast or even zealous mactivism. Everything you're mentioning is literally in Panther or about to be released in Tiger.
If Longhorn really is 2 years out, it's possible we'll see OS 10.5 by the time it comes out. Think about the position Apple is in. They've beaten Longhorn to market on a whole slew of features, and done so with at least a year (if not more!) to spare. 10.5 can continue to push forward and serve as a feature bulwark against any surprises that Microsoft might be able to come up with for the Longhorn release.
Are you really going to wait another 12-24 months for a product that's going to be released in less than one?
Not that it invalidates any of your other statements. I just wanted to point out those little ear buds are pretty good.
I can understand some people being mad about OS X's Java support. All I can say is that Mono is allready getting more work than the Sun Java Runtime on OS X, and it's still young. This is because it's open source. Go bang on Sun's door to open their JVM and we'll see some serious progress. Mono is changing the rules, and unless Sun gets their game on, Java is going to be ousted from the open source world.
Developer environments have very unusual usability requirements. Nearly every IDE violates usability rules. It's because they're not-at-all like other applications. They have to jam a huge amount of functionality into a small amount of screen space to make developers happy.It sounds like you had unreasonable expectations for XCode, and they weren't met. And now you think it's the tool's fault for being nothing more than what it is.
Nothing short of the removal of said DRM will be good for the consumer. You're not suddenly going to be free-as-in-bird with your music if you can play it on other players.
Apple made a great set of products, and they're succeeding so incredibly that the competition hardly even seems to be there. What Napster and Real really want is for Apple to be less successful. They don't like competition, because they aren't savvy enough to get in on it.
Is if it's signed in order to run, or if it's signed in order to gain privleges to the PSP's firmware.
Either is a possibility.