Using a Mac is “selling out”

I was just reading The Big Mac Dilemma, who asks:

is using a Mac “selling out” from your OSS ideals?

and I’d like to be very unfriendly and answer unequivocally… YES.

Just like anything else non-free, it tempts you with shiny baubles and the promise of making all of your wishes come true. And just like anything else non-free, it shackles you into a sub-standard environment all the while telling you that your computer is now obviously superior. (Mail.app? Really? Oooh.. bouncing icons…)

I’ve been working on Drizzle recently, and in the not-so-terribly-long time we’ve been working together, we’re already having to deal with people from the OSX camp complaining about library dependencies. I can’t ingore them, because like Eric was saying, just about all the developers these days are running either OSX or Ubuntu. However, it seems that amongst the wonders and joys of running corporate evil from Apple, the powers that be at Apple haven’t seen fit to bless you with the gift of a set of magical tools for, oh, I don’t know Installing Packages and dealing with dependencies. Nevermind that Debian has had this for years and years and years now. Nevermind that even the slow-on-the-uptake folks at RedHat have finally started playing the game with YUM. (following CentOS’ lead… but props for learning from your community RH!) What do you get from Apple – kings of “empowering” the user and providing a wonderful user experience? You get zilch.

Nada.

Nothing.

Why? Because Steve Jobs doesn’t want you to have it. Because having an easily incrementally upgradable and extendable system does not help sell OS licenses. Because Apple does not care about you.

Because you have chosen to run a non-free OS.

And now there is nothing you can do about it

Yes, yes. I know. Fink. Darwin Ports, etc. I don’t run OSX so I can’t say empiracally, but each of these seem to have some deficiency that makes it unsuitable for a normal developer/user of OSX to use it to install libraries. I’d also like to point out that we’re not talking about odd libraries here… we’re talking about glib. Pretty stinking standard.

So go ahead, sell out. Buy a Mac. But when I want to use standard libraries to develop something and it’s hard for you to install them… I have no sympathy. You are the one who placed control of your machine in the hands of someone else.

Building Drizzle cleanly with all the warnings

I’ve been spending the last several weeks hacking on Drizzle, which is based on recent code from MySQL 6.0 and which Brian announced earlier today.

I’ve been having tons of fun, and have cleaned up lots of stuff which had bugged me for a while. I’m currently trying to end the reliance of the client library on mysys and mystrings… but that’s a story for later. One of the things I’m happiest about so far is that we are currently building with:

-W -Wall -Wextra -std=gnu++98 -pedantic -Wundef -Wredundant-decls -Wno-long-long -Wno-strict-aliasing -Werror

for C++ and:

-W -Wall -Wextra -std=gnu99 -pedantic -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wno-strict-aliasing -Werror

for plain C. In and of itself turning on a crapload of warnings did not solve any major problems… but going through and fixing them did point out some shady things, some places where code was unclean, etc. I really love though that we are have -Werror on now, which turns warnings in to errors, so that anyone writing crappy code can’t just say “oh, that one doesn’t matter” – they actually have to fix it.

You might notice that we have -Wno-strict-aliasing, to turn of strict aliasing warnings. I’d love to fix all of these, but there are so many places where we cast things to (char *) (why not void * at least?) to pass them around it’s not even funny. (I’d be happy to work with anyone who wants to help clean those up, btw)

Why bother turning on warnings, even if many of them are just annoying things like “unused parameters” or the like? Well, a couple of things. Once it’s clean, then it’s more checking at compile time that you’ve possibly done something silly. Second, if you do have tons of unused parameters, and you’ve added tons of __attribute__((__unused__)) in your code (which are thankfully very ugly) – you might notice that perhaps something isn’t designed so well and should be refactored.

They are warnings, though, so not all of them are dangerous, or bad – or even correct. But now that’s it’s “clean” – we’ll keep it that way. Yippee.