The Fedora 10 name is inconsequential, though I should say I'm not crazy about any of the choices. Picking another element is kind of dull because EVERY software team names stuff after elements for a while (either that, or classic cars, or Star Trek characters). Most people have heard of Cambridge because of Sir Isaac Newton. However, there has been a lack of love for Mississippi in the software development world. Time to do something about that. If we can change the startup sound to Mountain, even better. Bad names though. Ow. Next time, I suggest we go really easy on the names-must-be-associated requirements to generate more interesting names.

However there is more important work afoot. As skvidal has pointed out on many occasions, Fedora 11 MUST be named "GoesTo".
Given this, it only makes sense that Spinal Tap has never played a gig in Mississippi. There is the connection. If they have, that also works. It works EITHER way! How brilliant is that?

If there was a character named "Farnsworth" (or even a key grip) in Spinal Tip, this would be acceptable. Feel free to propose other links to Spinal Tap and I will change my vote.

As a NCSU grad, I would suggest that Chapel Hill would be good for a connection for F10, but it's not in the running. Not only does it connect with Sulphur ("Chapel Hell"), Spinal Tap refered to it directly: "It's just a crappy university" :)

For those of you who use Sieve to control their mail filtering, you probably know the web interface to create rules is a huge pain to use. Here's a quick little script I wrote to automate setup of rules based on list ID's of mailing lists I'm subscribed to.

List each list-id, one per line, in a text file like this:


acme-list.example.org
foo-list.example.org


and run the following


python makesieve.py < sievedata.txt > sieverules.txt


Here's the source: makesieve.py

After some pruning and unsubscriptions, I'm only a member of 36 lists that I know about. Not too bad.

Ah, more fun with the Wiki of death.

Basically:

* Anyone can delete a page at any time.
* It is possible to delete a page calling it "spam" or "not interesting" when it is not spam and /might/ be interesting, without ANY form of review
* When someone does this, there is no history of the previous page to revert, and the process is pretty darn arcane so it is easier to give up.
* Lots of moderators on power trips

Joy.

If Wikipedia were run on custom software that allowed for voting on each item, and was not grafted on, well, a Wiki, I can imagine it being a lot better. All that is needed is to seperate the moderation system from the Wiki system, so that proper audit logs, versioning, and data are preserved, and not scatter process out in arcane ways where you have to scroll through pages of cryptic codes to find out what the heck is going on. Maybe have ways to track that a moderator is disliked too.

Total collapse is imminent

I had someone ask today on IRC about how well Cobbler works with Debian. It works pretty well, but I was saddened they really wanted to know how to switch some systems from Fedora to Ubuntu for popularity contest reasons. Apparently they knew Fedora was better, but everyone else wanted Ubuntu because other people were using it -- they didn't actually have a real reason of why they wanted Ubuntu.

Proper open source is about constant community collaboration and contribution, not about whether you use open source components in your product. So many open source applications and distros don't have real communities -- they aren't really open, they just use open source as a bullet point or a marketing term. I feel Ubuntu does this. Open source is not a bullet point. You shouldn't be using it just because it's "free", you should be wanting to use it because it is "Free". So yeah, as recently posted on Fedora Planet, we /should/ be using "Free Software" and not just "Open Source". For instance, think of the collaboration you get with "Free Press" and "Free Market".

So, when choosing your distro, ask first how much of it is open, and then ask, is there a really active development community that anyone can play in? How many developers work on the project?

Ubuntu mainly rips off Debian and has a wicked marketing arm. I don't find that interesting. I would allow them to subsist if their entire existance weren't based on loosing money and feeding the marketing machine. Fedora could do that. It chooses instead to do Open Source the right way.

Since Fedora has a huge developer army, and is doing things the right way, I am confident we will continue to kick ass long after Shuttleworth's loss-leading sales ploys go away.

Honestly, I'm really not interested in whether we compete with Debian at all. I'm happy to coexist. They are open, they do things right and give back. No problem there. I'm also totally ok with CentOS. Since Red Hat is based on community work, it's only right that those bits are available for free. It's all by design, it's all good. CentOS guys give back a lot -- they contribute a lot to my projects for one, but it certaintly doesn't stop there.

I just think it's unfortunate that new users think Ubuntu is some kind of leader. They are a very loud about talking about themselves, that is about it.
You pretty much work for Canonical it seems, or you don't contribute (Fedora is on the other hand mostly NOT Red Hat!), and the Canonical guys are mostly just packaging up and using other stuff.

You will notice I didn't mention Oracle's "Unbreakable" -- which is another "take and don't give back" thing. From what I have heard about their managability lately I don't think anyone has anything to worry about with them.

It's all about the little "f" versus the capitol "F". It's not about how open your software is, it's about how open your community is, and how you interact with other outside communities.

(I admit that I have a Mac at home. Shoot me.)

Anyhow, I recently cleaned up a lot of desk real-estate by selling my mixer/audio-interface and volume controller thingy (a Mackie Big Knob) and replacing it with an Apogee Duet.
Not only does it take up absolutely no space (it's bus powered) it sounds completely freaking awesome. Drool. Best of all the volume controls just work with the OS controls. If you hit "mute" on the keyboard, you can switch it to headphones and back. Nice.

I was highly disappointed with my KRK Rokkit 6 speakers before, but it turns out my audio interface was pretty much to blame. They are actually great, as they are supposed to be.

While they aren't my absolutely favorite albums (they are kind of slow), I really recommend the Eagles Hell Freezes Over and Clapton's Chronicles for speaker testing. They are mastered really darn well.

Happy audio Friday.

A recent mailing list thread brought up on XMLRPC vs SOAP vs REST and so forth, and I noticed there were not a lot of articles on Google about this that really addressed some of the high points. I figured I might as well be on Google too, so here is my opinion.

This is based on not only a few apps like Cobbler and Func, but also past work where I've touched almost all of these first hand -- I always seem to get stuck working on the backend server components wherever I go. This is by design -- I like it there.

So here are the plusses and minuses to everything, and I'll put a mark beside all the ones I've used before. Hopefully this will provide useful ammo if someone faces the "you must use SOAP" mandate somewhere and is looking for good options -- or for people who are just looking for additional data before making a choice.

XMLRPC:
+ easy to route around firewalls
+ has very nice libraries available in a wide array of languages that make it feel just like a locally used library
+ widely used in for systems management type applications
+ simple libraries exist that do not require a "web app" stack to be a server for it
+ does provide a mechanism for signaling remote faults and raising them in the caller
+ while it is XML based the user doesn't have to care about the XML, auto-serialization is an awesome thing to have.
+ specification has been around for a long while and has not needed to change, which means it got most things right
+ easy to proxy security behind Apache and let it take the heat
- serialization works for basic nested data structures of normal types, so your API must be written to use basic datastructures or otherwise serialize data in XML. (Basic datastructures are fine for most applications)
- does not have a bool type and typically cannot represent "None" (NULL) without special parameters as it is not in the spec -- but this can be designed around easily. Should None be in an API? Probably not.
- is not deemed as "enterprisey" by some people as SOAP if you must deal with developers who like things to be called "enterprisey"
- not good for transport of large files because it ships things as XML.

REST:
+ easy to route around firewalls
+ useful for uploading files as it can be rather lightweight
+ very simple if you just want to shove simple things at something and get back an integer (like for uploaders)
+ you get it for free in some web application stacks and it is easy to pitch to "mash up" style web developers
+ easy to proxy security behind Apache and let it take the heat
- does not define any standard format for the way the data is being exchanged (could be JSON, YAML 1.0, YAML 2.0, arbitrary XML format, etc)
- does not define any convention about having remote faults sent back to the caller, integer codes are frequently used, but method of sending back data is not defined. Ideally this would be standardized.
- may require a lot of work on the client side caller of the library to make use of data (custom serialization and so forth)
- not pitchable as an enterprisey API in most cases, unless you are talking to web developers

SOAP:
+ easy to route around firewalls
+ widely used in for systems management type applications
+ supports complex objects if you absolutely need them and don't mind writing a lot of code for it
+ has crazy things like envelopes
+ does provide remote faults and raises them in the caller
+ easy to proxy security behind Apache and let it take the heat
- has crazy things like envelopes
- pretty high signal to noise ratio in wire format, might be a slight performance concern
- caller will probably have to do work to process return data and format objects correctly
- typically only has good libraries for "enterprisey" languages, though there are some nice looking exceptions
- not everyone understands all of it
- lots of related and optional standards are confusing and sometimes not complete
- typically causes dynamic language hackers to run screaming when it is mentioned.
- in most cases, all you really needed was XMLRPC anyway
- .NET tools say they speak SOAP, but if you look at the underlying implementations, they are encoding data in a giant XML glob inside the stream, making it only really work for .NET apps. Embrace and extend here, so if you are picking SOAP for compatibility with .NET apps, they speak a different language that isn't really in the spirit of the game.

CIM
+ Well supported by major players in the systems management space, allows you to do things with their software
+ Supported by a lot of storage and server related stuff
+ Definitely holds up as "enterprisey" if you need to play in that sandbox
- Way too complex for most developers to be efficient in it, or even be able to use it
- Not a lot of good dynamic language bindings, if any
- Hardly any implementations of it doing anything useful
- It's hard to not code to a specific implementation and make things portable.
- Poor (free) documentation, especially in terms of examples. Good documentation seems to require payment of fees and being on commitees.
- open implementations leave some things to be desired (memory consumption)
- lots of related and optional standards are confusing and sometimes not complete
- not really adopted much in the open source space due to barriers of entry
- typically causes dynamic language hackers to run screaming when it is mentioned.

WMI
- This is microsoft stuff and is not happily cross platform

WS-Man and WSDM
- Other attempts to redo CIM
- Still painful
- Most of the same problems
- In many cases, even less adoption

RMI
+ Feels like a local API, much like XMLRPC
+ Can provide some fairly nice remote exception data
- Java specific means this causes lock in and limits your options
- Has horrible versioning problems between different versions of clients
- Skeleton files must be compiled in like CORBA, which is not very flexible
- Serious pain in the ass to multiplex sockets and secure them
- Subjective, but feels like it blows up a lot.
- While this is Java tech, it's not "enterprisey" if you need that. Not anymore.
- Not firewall friendly (with exemptions, but they are pain)

CORBA
- Dinosaur tech. Very similiar to RMI.

Custom Socket Server implementations
- You will get the security part wrong.
- People will have a hard time talking to you.
- You will make extra work for yourself.
- It's a bad idea.

Just send commands as INSERTS through the database
+ This might be ok for some batch job kind of things
- Not really an API, too much access to maintain
- Unsuitable for remote or untrusted/read-only usage.

Just FTP files around into an "orders" directory
- Even worse, don't do this either. This does not an API make.

DBus
+ Great for local communication on the desktop on Linux
- Has a fair amount of dependencies
- Not something you (edit: typically) use remotely

Your Favorite Message bus (This post is not about message buses)
+ Nice if you want to address multiple things at a time and need complex routing options, especially if you are building it for a datacenter type setup where you control everything
+ May be very fast
+ Can be called "enterprisey" if you need that
- Can be a bit difficult to deploy and configure for your users in some cases
- Not all of them have a wide variety of language support and therefore may create lockin (thankfully AMQP does and does not have this problem!)
- Probably not right if you are writing multi-platform code

Conclusion? I like simple code that gets the job done while still covering all the bases I need to cover. I don't need it to cover ALL of the bases, just some of them.

I like XMLRPC because there are very good client libraries, standardizes it's serialization formats (and handles this all behind the scenes), does not show a language bias, and makes things trivial for the caller -- it looks just like a local API. If your marketect demands, you can call it a full fledged web service with a straight face -- it is one -- for instance, the Python API's provide a way to enumerate remote methods just like WSDL does (or close enough). There are some things it is not perfect at, but in the Linux space, it is omnipresent and very easy to use, and I like things that allow me to build infrastructure with the bare minimum of work and access it from multiple places without too much lock in. It is also a simple standard that you can read and instantly understand, it does not hide behind any hard to obtain knowledge that makes it seem superior.

Now, you don't have to do just one API format -- You could do something clever and expose things more than one way, too, but that's extra work and I like to be minimalistic.
Other people may have their own preferences. That's ok.

Google: have at.

Reality TV show producer types, you know you want to. Call me and we can discuss ideas and terms.

Nothing good ever happens on them. What's up with that?

[/jerry-seinfeld-voice]

Random things I've learned over the years in Software Development land, that I felt like writing down, for no good reason:

0. Paradox: Any interesting and powerful application needs to be fundamentally simple. As the application grows and gains features, it becomes complex until another application tries to rise up and replace it. It is therefore a constant battle to keep smashing an application back down into simplicity and to keep out features that are not useful to at least, say, 20% of the population or more. Corollary: Seeking 100% user happiness results in 0% happiness, 80% happiness is attainable. See game theory and Nash Equilibrium. Corollary: You can't conquer the world overnight, but you might be able to conquer Lichtenstein.

1. Perfectionism leads to madness, or at least, not getting a lot of things done. It is ok for things to break occasionally or for every use case of every user to not be covered. This is hard for me as I very much want to be a perfectionist, but that never scales -- I am waiting for human cloning.

2. Dependance and inclusion on certain components in a system may mean you include a component that causes people to not like your application. The trick is to be modular and support a component without requiring it. For instance: pizza with all the good toppings, plus broccoli. You've just ruined the pizza for some people. If you make a rule like that because you like broccoli, you'll have less users. Counter-example: too many layers of abstraction lead to madness and complicated code, see point #1. Modularity is awesome but know when to stop.

3. Supporting those who still use the old and busted means you can't use the new hotness. However, there is also volume in catering to the old and busted. Choose the balance wisely.

4. Communication and sharing knowledge is more important than sharing code with users, because they will be sharing ideas with you. That exchange is the most important in OSS space, and it's code that seems to get all of the credit in the OSS model. Not so much the case. That "Open Design" and collaboration model can be applied to lots of things other than code.

5. Your users always know what they want to do with your future software project/product more than you know what they do. If you aren't writing software directly for your usage -- ask often and don't be afraid to not have all the answers. The user experience is what matters. One of the worst experiences a developer can have is building an application that the user doesn't like because they didn't actually contact the user. In OSS land, where we have all public lists, it's very easy to do... much more so than in proprietary software space. All developers should be talking with users as it gives them lots of perspective. Some of the best days can be days where you don't write much code but still get a much better understanding of where things need to go. Design is as much about knowing your user as is thinking about boxes and arrows. However, don't solve the problem for every user, you have to write for the collective problem. Again, solving everything is impossible.

6. Backwards compatibility and seamless upgrades are some of the most important things ever, and also some of the most annoying to implement. Lots of people won't read the docs so you must do as much as possible to keep all things working or at least show what is broken.

7. conf.d style directories are awesome. We should do more of those.

8. Apps should be able to debug and report on common setup problems themselves. This helps enormously when doing support. Also, make useful log files. Don't make un-useful log files.

9. If you confuse people, an easy way to tell is they'll ask lots of questions about something. Rather than putting it in a FAQ (since not everyone will read it), figure out how to build your app so they stop asking that question.

10. "You Aint' Gonna Need It" is a pretty smart idea. "Keep It Simple" is a great idea. So are Larry Wall's 3 Virtues. Especially Laziness. Unix is about little apps talking to little apps for this reason. It's also about reusing packages and looking for stuff on the shelf before trying to build a lot of stuff. NIH is the inverse of laziness, which makes it bad. However, square wheels still have to be reinvented, as you do need round wheels.

11. Design Patterns Aren't.

12. Also, the chance that a random application is interesting to me (personally) as a normal user slash developer human is inversely proportional to the number of lines of code in the said app. That's just me though. The best days are days when you can delete code.

13. Eschew buzzwords. No one remembers what they mean anymore. Talk in normal sentences when you are describing what you do so others can understand you. Similarly, don't say eschew, nobody says that :)

14. Trying to support everything probably means you support nothing all that well. Know what you do and do it. Supercow powers are only for cows. Superllama powers are for llamas. Know the difference. Don't try to give supercow powers to a llama.