Stuff Michael Meeks is doing

AC_ARG_WITH(drink,
[
  --with-drink            The parameter is a favourite drink that unpack should advice you to take.
		      
			  Example: --with-drink=coffee],
,)

• This is particularly true when you take into account the typical hacker tendency to start things that never get finished. Those who would deny this tendency, should introspect: how many TeX-like bug-free & finished programs have they created; vs. how many mouldering half-finished proof-of-concepts ?. When I cast around for the programmers I respect most perhaps they have some of these defining characteristics:
  • Hackers that produced libraries or applications that have stood the test of time: became the canonical solutions in a given area, were cleanly designed & maintainable - and as such began to be taken for granted & disappear from view. ie. I love people that finish things.
  • Alternatively I see giants who took broken unfinished things, and heaved them upwards into a more usable, polished & consistent state - eg. getting nautilus from where Eazel left it to today's version.
  • Those who lead others by example: sheer hard work, determination and working to include, build and keep a developer community; oh and who compromise to ally with, and include other people. For example if your Foo project seeks to revolutionise the desktop - best to join up with Baa project and Baz project with similar goals, before trying to persuade everyone to work with you.
  It turns out having 'vision' is easy enough, you don't need any special (or even programming) skills. What is not easy is having an achievable vision, articulating it clearly, building consensus and delivering on it.
• Then of course, there is a wonderful (albit brief) paper by Jamie Zawinski on the revolutionary CADT development model. I'm personally not so convinced that version 0.8 is always followed (on re-write) by 0.8, often AFAICS it's 0.7 or 0.5. Having said that getting to 0.9 is perhaps possible, if the re-write is done by people wiser after suffering all the original mistakes. Sadly though re-writes are done by 'fresh blood'. Perhaps the reduction in CADT in GNOME is due (as people have pointed out) to an increasing proportion of the middle-aged: with pictures of babies replacing bungee-jumpers on the planet.
• Pyro / web-desktop type ideas as a way forward: I used to (somewhat) sneer at people who describe themselves thus: "I program HTML". Then I tried to make a web-site look as I wanted it to (ie. not grotesquely ugly), wow - perhaps they were onto something. Some think there is a pile of broken mess in our desktop, but at least you know where you are with a GtkHBox.
• Then of course - there is the thesis itself: of decadence. If people want pervasive & noticeable change you can instantly see - it means several things: potentially huge code changes, new metaphores and lots of experimentation. Doing that will inevitably screw up lots of the new things: or worse, they will be an excellent idea (eg. spatial nautilus) that the users will revolt against. Of course, that is no reason not to try, but the bigger the project, the harder it becomes, and the more necessary it is to have a clear and substantial benefit articulated.
• Personally, I think the thesis of slow decay is unconvincing: I look at the wider Linux desktop of which GNOME is a key part, and see us actually getting to a place where it works well enough that the positive feedback that entails gets us yet more users, developers and improvements. Simply because the UI involved in say draining the package management swamp is small - doesn't mean the effort fixing the mess is (or would be any easier in a new paradigm). Similarly, when it comes to resourcing decisions eg. I applaud Soeren, Federico & the X guys for working on the inglorious draining of the swamp of multi-monitor hot-plug from hardware to end-user. They could of course have been doing something else: perhaps adding 3D gizmos that only render properly on ultra-new hardware - would that be time better spent ? Personally I'm excited about new things like PackageKit, PulseAudio, working multi-display hot-plug, (finally) pervasive free-software X drivers, the latest compiz effects, and so on.
• I guess, ultimately we should aim at making our libraries and infrastructure as (apparently) boring as the kernel: which people take for granted, is just there, and expands incrementally. That might leave us to move up-stack and make our applications integrate beautifully with all our new technologies; dunging out the old libraries & APIs to make further change possible, and adding user functionality people want to use: but then, I'm always on the look out for more ooo-build hackers I guess.

I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures. This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash.

• The altar as an analog of Kuduru stones - marking out land as belonging to various people - erected by kings almost like a title deed. Indeed, 'altars' being created not always to sacrifice on but apparently for a similar purpose.
• The radical difference in the Israelite altar vs. pagan ones: worshiping the God 'who is', built very simply with un-dressed stones: with the maker's marks un-blemished by man's. cf. the law of the altar: Ex 20 either just earth for sacrifices, or un-dressed stones.
• God's ultimate ownership of everything, as soverign - whether palestine, England, or our lives: Abraham's confession of himself as God's own: calling on the name of the Lord.