it's not just the caliber of the ammo, it's also the velocity. I'm certainly not an expert, but I did my military service in a base used for tank training. Back then, it was already a done deal : no armor could resist the amount of energy released by anti-tank ordnance, in particular kinetic penetrators. I've seen up close old tanks which were used for training. On the entry side of the impact you have a perfectly cut circular hole a few cm in diameter, with slits all around like petal flowers. On the exit side you have a big open tear. In between, there was a jet stream of molten metal. Bottom line : a spotted tank is a dead tank.
That was a fairly long time ago, but unless armor has made huge progress since then, producing something hard enough to deflect this kind of force and yet light enough that the tank can move, I'd still bet on an A10 against anything rolling on the ground.
He was not a hacker and that's precisely why he could lead the creation of great end-user products. He certainly did know a whole lot about programming : check his WWDC 97 address, in particular this sequence at 22' :
he knew that coding isn't measured by the number of lines you write, and that providing a good environment to developers is absolutely essential. I don't know too many managers or CEOs who really grasp that.
I switched to OS X in 2008. Prior to that, I had been using Linux since 1995, and contributed quite a lot to Free Software (Gnome, gtkmm, KDE, Rosegarden). May be I saw one too many Apple add on a billboard. Or may be after trying my mom's macbook, I realized that OS X is pretty cool to use while I just had to google around some poorly written docs to restore my tilt-wheel mouse configuration which a Kubuntu upgrade had broken.
> at least 80% of my development I can do on my Linux machine.
That's the whole problem right there. The remaining 20% are all the desktop-integration features and UI polish that is not cross-platform, but which makes the difference between a run-o'-the mill app and a great one. And OSX does raise the bar quite high for the latter.
The fundamental flaw in CatB is that it was essentially an adaptation of ESR's libertarian creed, that Free Market is infallible and would always boil down to the best optimal solution. While that may work on the scale of a single project, it fails when applied to a full ecosystem, and thus we get dozens of competing projects aiming at the solving the same problems (WMs, desktops...).
It also postulated that code being open would incite devs to be as their technical best, in order to gain peer respect. That didn't happen either, quite the contrary the OSS community has proved to be rather conservative and traditional, Unix being seen as "The Right Way", not to be deviated from.
In short, the Bazaar model completely failed in its promise to always let the best solution win. What we got instead was perpetual chaos, and less than 1% of the desktop share.
I attended the 1st GUADEC back in 2000. If at that time we had known where we'd actually be 12 years later, we'd all have left in disgust.
I moved to OS X in 2008, my only regret was not doing it any sooner.
I know Objective C, C++, Java and have basic knowledge of C#. Of all these I'd rate Objective C as the easiest to learn and to handle. It's much more forgiving and easy on the programmer, and the syntax is trivial.
You seem to make a big case of the message passing syntax, but your example is very poorly chosen. Rather than 'performAction:withTwoParameters:' it should be 'performActionWithFirstParameter:andWithSecondParameter:' as are most Cocoa methods. Named parameters may seem verbose but they are much more readable than 'performAction(param1, param2)'.
If Objective C is a "large" language, I wonder what you'd call C++ or C#. Huge ? Humongous ? If you think Cocoa is large and complex, the C++ Standard Library or the Java library will make you weep.
The C++ standard library is actually quite small. Check Herb Sutter's keynote at Going Native 2012 for an entertaining visualization of its size compared to the Java or C# standard libraries:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
The IO libraries are kind of a mess but I don't find the algorithms and containers significantly more difficult to use than similar implementations in other languages.
> On a personal note, the effort required to maintain a stable Linux desktop made me switch to OS X in 2007, after using Linux for 13 years.
I did the exact same thing (except in early 2008 - been using Linux since 1995), for the exact same reasons. A Kubuntu upgrade breaking my mouse config was the last straw.
> Basically OS X destroyed Linux's chances on dominating the future desktop.
Yeah, because the constant feuds within the Linux community, the failure to settle on a common desktop platform, the crowd of "I-want-to-write-yet-another-irc-client" devs, and the utter lack of appreciation for end-user needs all have nothing to do with it.
What Stallman in particular and the Linux community in general fails to understand is that a broken or badly designed software for which you have the source is more of a prison to the user than a well-made, closed source one.
Before you flame me, I've been part of the Linux community from 1995 to 2008, and I dare say I was more than an annecdotic contributor. I still support the idea of free software, but community development simply doesn't scale.
Considering the huge progress that was made in the 90'ties on Linux and the lack of progress done after OS X came, I think it is safe to assume that OS X played a major role here.
Software needs resources to get created and lots of it. As a company or as an individual, you can't sink time and resources into software that isn't at least popular. You can try to invest in something, but sooner or later resources dry out, priorities change, etc, etc...
Desktop Linux seems to me that it was created by stitching obsolete software and quick hacks together with glue and spit. Even broken as it is, I still marvel at how functional it is for me. And even unpopular as it is, there are some normal people using it, which goes to show that it isn't totally broken or insane.
broken or badly designed software for which
you have the source is more of a prison to the user
than a well-made, closed source one.
I don't agree there - having the source is a huge advantage, even if you aren't capable of modifying it. Just as with cars, you don't necessarily have to go to the parent company and you don't have to fix it yourself. You can always choose a local shop for repairing and tunning.
community development simply doesn't scale
I wonder why are you saying that, when server-side Linux and related software is such a huge hit.
You can also point out to some desktop software that is free software, that is sponsored and yet community driven and that is usable. That's Firefox and it's the reason why we came out eventually from the dark-ages of IExplorer's domination.
> Considering the huge progress that was made in the 90'ties on Linux and the lack of progress done after OS X came, I think it is safe to assume that OS X played a major role here.
Progress in software development is not linear. You quickly get the basics done, and then the devil in the details. Also, the Gnome vs. KDE feud didn't help one bit.
That said, OS X being exactly what Linux dreams to be (Unix with a beautiful and useable UI, scriptable apps, reusable components, and a modern development platform), I know I'm not the only one to whom it provided a haven after years of Linux-induced frustration.
> Desktop Linux seems to me that it was created by stitching obsolete software and quick hacks together with glue and spit. Even broken as it is, I still marvel at how functional it is for me. And even unpopular as it is, there are some normal people using it, which goes to show that it isn't totally broken or insane.
No disagreement here.
> I don't agree there - having the source is a huge advantage, even if you aren't capable of modifying it. Just as with cars, you don't necessarily have to go to the parent company and you don't have to fix it yourself. You can always choose a local shop for repairing and tunning.
In theory it's true, in practice it rarely is, since taking over a code base of any significant size is a very hard challenge. I've yet to encounter a situation like you describe, or even hear about one. When the software doesn't work, you replace it, source available or not.
> I wonder why are you saying that, when server-side Linux and related software is such a huge hit.
Because the audience being other tech geeks, it's a much simpler endeavor.
> You can also point out to some desktop software that is free software, that is sponsored and yet community driven and that is usable.
Sponsored free software is usually mostly developed by the company sponsoring it, the community comes a distant second. This is a scheme which works, though, as the company has the final say. I hope it will keep on growing.
In theory it's true, in practice it rarely is, since taking over a code base of any significant size is a very hard challenge. I've yet to encounter a situation like you describe, or even hear about one. When the software doesn't work, you replace it, source available or not.
Even if you're replacing the software, having the source allows you to ensure that your replacement is fully backwards compatible with the original, and, if it is not, enables you to implement a compatibility shim that fixes those issues.
That said, OS X being exactly what Linux dreams to be (Unix with a beautiful and useable UI, scriptable apps, reusable components, and a modern development platform), I know I'm not the only one to whom it provided a haven after years of Linux-induced frustration.
You can't just blame the Linux community, though. I agree that the community could do a lot of things better (especially with regards to UI development). However, one big obstacle the Linux community has to work against is hardware support. Windows is the dominant OS - manufacturers essentially subsidize Microsoft by providing Windows drivers for their product. Apple, by choice, writes OSX to only work on a very limited subset of devices that have been approved by Apple. Linux has neither of those advantages.
In theory, the fact that Linux is open should make it easier for programmers to make their own drivers and release those drivers to the community at large. In practice, because of many of the concerns that you've cited, proprietary drivers still outclass Linux drivers for a number of components, including WiFi, ACPI power management, and graphics.
Even if you're replacing the software, having the source allows you to ensure that your replacement is fully backwards compatible with the original
Same answer : True in theory, very rarely practical in reality. The only thing that really matters is the spec of the data format used by the program.
You can't just blame the Linux community, though.
I agree, it's not just that, but it's the main reason. 15 years since the start of KDE and there's still no sign of a unified, viable platform. If there was one, hardware support would follow.
> Considering the huge progress that was made in the 90'ties on Linux and the lack of progress done after OS X came, I think it is safe to assume that OS X played a major role here.
I completely disagree with your assertion, but let's say for the moment that you're right -- Apple has thrown down a legal, legitimate gauntlet. So what the heck are you going to do about it? Complain? Say "that's not fair"?
> Yeah, because the constant feuds within the Linux community, the failure to settle on a common desktop platform, the crowd of "I-want-to-write-yet-another-irc-client" devs, and the utter lack of appreciation for end-user needs all have nothing to do with it.
Everyone seems to like bitching about these sorts of things in the open source commmunity, yet no one seems to like doing anything about it.
I think that depends on what you apply it to. Community development seems to work well enough for individual projects, but not in-between projects (see amount of duplication caused by LibreOffice/OpenOffice.org).
Well, it scales within projects (see Linux kernel for a good example of a distributed project run by a mixture of volunteers and people paid to work on it), it doesn't seem to scale as well to projects working together.
