Grab Xcode 4. It's still beta and buggy but it's all one window and is pretty good IMO.
There's keyboard shortcuts for spaces. And CMD` to switch between windows in apps.
OS X isn't perfect, I switched from KDE 5 years ago. Eventually you start noticing all the little touches that mean it is—really—light years ahead of Linux desktop options.
It does have a lot of little "Apple" touches though that you'll just have to take with a LOL.
This is pretty much the opposite of my opinions. Android documentation is awful. Mostly it isn't there at all. Many times I found that it was in fact wrong. iOS documentation is really good. Garbage collection on mobile devices means you get UI stutter because GC kicks in when you don't want it which means your app feels less slick. Xcode 4 is pretty good, but yeah Xcode 3… However Eclipse is slow, clunky and buggy.
Also I have found myself doing weeks worth of hacks on Android AND iOS. Both are large frameworks, and ultimately they don't have abstractions for everything you may want to do.
The article reads like the guy hasn't really got his feet wet with Android development yet. He's yet to be bitten by not handling the activity lifecycle correctly for instance. The real edge cases of that didn't start materialising until we had 20,000 beta testers.
http://github.com/mxcl/homebrew is my project. IMO anyone who is afraid of forking is actually just afraid of losing control. It's much easier now for people to do a better job than you. You have to work harder in order to keep your kudos. That guy who has submitted 20 patches a month since 2005 could in theory attract more attention than you and everyone would start using their fork.
/usr/local makes it far easier to install stuff like Gems with C extensions. It is a standard path checked by the C build system (eg. gcc).
There no good reason I have yet heard why using /usr/local is bad advise. I assume that since you provided no rationale for your statement you are in fact unaware of one.
But anyway having said this it is merely a recommendation — do whatever you want. The installation guide goes to great lengths to tell you that you should do whatever you want.
Back when I initially made Homebrew I was interested in the greatest goal of maximum awesome O99 CFLAG awesomeness. Now I'm only interested in reliable compiles and the default CFLAGS are pretty sensible. At the time I wouldn't have recommended the project to anyone particularly, but it got popular anyway.
But anyway, I never copy and pasted without reading a bunch first. I spent several days researching the stuff, the Gentoo wiki was a good source.
There is no anti MacPorts stuff in any of the docs anymore. I was never anti MacPorts at all, if anyone will believe me. I just found it to be not a great tool for developers. Homebrew is a grass roots project, at the time it seemed harmless fun to poke fun at the competition. As the project became more popular I took it all out. Now there is just a small gibe that I couldn't resist because it's too good a bit of wit.
Finally, no offence? May I suggest next time you say such a thing you don't immediately accuse the person to whom you mean no offence of being both ignorant and arrogant.
PS with offence, you're an ignorant twat, and probably ugly too.
It's worth pointing out that "sudo is up to you". So leave /usr/local alone if you like. Or install Homebrew to ~/homebrew. Whatever you choose. Homebrew was designed to be flexible and non-intrusive.
However the suggested step is suggested because:
1. On OS X /usr/local isn't even there on a fresh install, so nothing that should run as root is there by default.
2. Mostly people use Homebrew to install a few tools that are missing, these tools don't need to run as root, so they are as vulnerable as TextMate is (because you dragged it from the DMG to /Applications and it installed as your user).
Now you can argue that you should thus install to ~. And you can of course. However I've found over the last eight months that a great deal of build systems have bugs and don't find dependencies if you install the deps outside of /usr or /usr/local. So for a trouble free life we suggest /usr/local.
Finally sudo is dangerous. You should only use it with tools you trust. Do you really trust a half baked Makefile made by a developer who doesn't really know how to write Makefiles?
All in all I think depriviledging /usr/local is safe and the least hassle for Homebrew on OS X.
It's not that I hate sudo. But I encourage people not to use it because:
1. You're adding to OS X. It's very important that stuff that gets built definitely didn't touch any files in /usr or /System. Build systems for some projects are big pieces of half arsed software. It's quite a risk — and an unnecessary one at that — to trust them to not break the bit of the system that only Apple fully understands and controls.
2. Homebrew is for developers. I dev software. Mostly I am installing x library and will want to upgrade and fiddle with it readily. Sudo is basically unnecessary for most of Homebrew's packages. Although I agree some stuff should probably not be installed without a sudo. But with Homebrew at least you can decide which to do on a per package basis.
Also, this isn't rationale, but it's still worth pointing out: most people install software on Mac without a sudo anyway (eg. almost everything in /Applications), so it's not such a big step to suggest you do the same for the handful of tools you need that OS X doesn't provide.
Playgrub and Playdar have the potential to bring music to all sorts of sites that currently only talk about it or offer it in somewhat tedious ways. Much recommended!
Ten months ago RJ wanted to write Playdar in Erlang but was worried about the portability of packaging and distributing the Erlang VM. As it stands this is still an untested area for desktop software… but ten months gives you a long time to think about things, and it's going to work, so yay.
2) It's much harder to get contribution for a binary system (I expect). If you're installing foo and it doesn't work for some reason you probably won't want to install Xcode and Homebrew-dev in order to try and fix it. When you're installing from source you're already a `brew edit foo && git push` away from helping fix it.
It's also worth noting that most packages don't have dependencies in Homebrew. This is because we don't duplicate what is already there and OS X comes with quite a lot of the common low level libraries. So compiling foo takes significantly less time than it does with Macports.
Hi I wrote Homebrew, and this is one of my goals, I've always wanted installing from source on Linux to get package management too. I do a lot of cross platform dev, and would also love for this to work on Windows. But that may be too lofty a goal.
I also added the feature where you can specify a git:// or svn:// protocol for a formula so you can easily keep up with HEAD development for your favourite project.
God, are all documentaries in America like that? Like obviously biased? And scare-mongering? I couldn't watch more than a few minutes as it made me feel sick.