20:33: We Will Celebrate Grav-mass.

My son's school is culturally sensitive and diverse place; to wit, they've sent out a `holidy traditions' survey asking questions like:

• What holiday will you be celebrating in December?
• What traditions and customs does your family follow?
• Where is the holiday celebrated?
• What foods are cooked/eaten?

We've written in "Grav-mass" as our holiday, and are in the process of trying to come up with answers to the other questions tonight. It's perhaps too new a holiday to have real traditions (yet), but traditions have to start somewhere--and that's actually a pretty nice set of prompts to get us started.

The food questions is especially interesting: the obvious answer is "Apples and apple-based things" (perhaps a `2(apple)π'), but what else? `Engineered foods' seems like it might actually be a fitting alimentary theme, except that there's a pretty popular dislike of `science in food' (people are generally much more comfortable with food-preparation techniques that are more like `food alchemy' than `food science'...), and even more popular (and stronger) dislike for `food engineering'. And I have to admit that `celebrating the holidays with engineered foods' initially sounds somewhat off even to me. We could, perhaps, bring in my family's tradition of going out for Chinese food (since the Chinese restaurants are generally the only ones that are open on Grav-mass; this tradition actually pre-dates Grav-mass, since it's--fittingly--grounded in observed and verified realities of the world around us).

I wrote RMS and asked him if he'd had, or heard, any ideas for `traditional Grav-mass' foods--since the definitive web-page on the holiday is his at this point, but it doesn't mention foods. We're definitely going to work with his suggestion:

Are there any foods that would bounce if you dropped them on a table?
Want to experiment with them?

And there are, in fact foods that bounce.

From memory, I can say that gelatin blocks do have a certain amount of bounce in them if they're sufficiently low in water-content (too much water and they tend to splat rather than bonce). In fact, remember seeing some television advertisements for Jell-O that made use of this, years ago. Some experimentation reveals that the `jigglers' recipe on the side of a Jell-O package actually yields fairly bouncy stuff--and the closer to spherical the formations of the stuff get, the better they seem to bounce (so, cubes bounce better than thin sheets; and, interestingly, `metricated Jell-O bounces better than imperial Jell-O'--which is to say that ~1-cm cubes seem to bounce better than 1-inch cubes; perhaps this is for the same reason that a 100-lb ball of silly putty doesn't bounce like smaller balls do). I have a feeling that gelatin might also bounce better with less sugar in it, so we'll have to run that experiment.

I believe there are also recipes for bouncing eggs, as well--though I'm not sure how tasty the eggs end up being, and I'm not clear on whether the typical `rubber hard-boiled egg with its shell dissolved in vinegar' kitchen science-experiment actually bounces any better than a hard-boiled egg with its shell removed by more conventional means.

Cornstarch-thickened creamy puddings also seem like they might be appropriate: though it's not particularly interesting after it's cooked, these puddings start out as ooblick before they're cooked. Non-newtonian foods for the newtonian holiday? I wonder if there's a way to make ooblick that tastes good without it being cooked. Preliminary experiments seemingly point to `no'. After trying this experiment with prepackaged pudding mixes, I can say that they do actually have a passable taste even before cooking, but they do not pass through an ooblick stage: they appear to contain far too little actual, unmodified corn starch in relation to sugar and other ingredients. No, the `ooblick to pudding pudding' experiment must be properly home-made, starting from scratch rather than reusing someone else's prepackaged science, and followed through to completion. Not only is it better science, it's much more fun.

We're looking for more ideas for `traditional Grav-mass foods' (especially things other than desserts, which seems to be where most of my ideas lay). Maybe you can help? If you have a StatusNet account somewhere, join the Grav-mass discussion group and post some suggestions! If you don't have a StatusNet account yet, there are plenty of StatusNet services where accounts are available (some public where you can just create an account, and many `by invitation' where you can ask and receive an invitation by e-mail).

Let's make plants to get Grav-mass going as a worldwide phenomenon this year.

[Reply]

13:00: That's no moon, Son....

Someone gave my 3-year-old a 3-D puzzle-sphere deathstar for his birthday.

When he looked at the picture on the box, he said, "Look--it's a moon, Daddy!"

Of course, I had to tell him: "That's no moon...."

[Reply]

20:15: The Mac OS X Look & Feel: so... chintzy?

It seems like every time someone expresses any sort of dissatisfaction with some aspect their operating system--for example esr's recent complaints that he doesn't like Ubuntu Unity or the new GNOME 3-- the Mac people come out of the woodwork and start chiding "get a Mac!"; that "`the GUI done right' already exists--it's called Mac OS X!".

After a recent weeks-long stint with Mac OS X..., I have to disagree with the Mac proselytizers.

People like to talk about the Mac `look and feel' as defining the platform, and this is usually done in adulation, but the more time I spend with it, the more I find that Mac OS X really just feels... like a cheap knock-off of a GNU/Linux desktop.

The Mac people will say `it's not a knock-off at all! Its lineage goes back to NeXTStep! And BSD! Before Linux even existed!'. But I'm not talking about lineage, I'm talking about refinement--it doesn’t matter whether Mac OS X actually is or isn’t actual a copy of GNU/Linux by lineage--it still feels like a cheap one. And pedigree is no excuse for a poor showing--actually, it just makes it all the more damning.

What's perhaps at least a bit surprising is that most of my complaints are actually with the much-vaunted GUI--for example...:

• Why do I have to go find the tiny little title-bar to move a window instead of just grabbing the window wherever's convenient like I've been able to do forever in `the other X'?

• Why do I have to go find one specific little corner of a window to resize it? And why can't I make a window grow to the left or upward? Why do I have to do a series of move-then-resize steps instead of just pulling the top half of the window up further like I've been able to do forever in X?

• Where's the `roll-up' or `shade' feature like I've been using forever in X?

• In the `scaled window previews' mode, why can't I filter the view instead of having to pick through all of my windows manually?

• Maybe this isn't strictly a GUI complaint..., but it's definitely a UI complaint: where's my Compose key!? If I want to, for example, type a smiley--why can't I just type it with something obvious like "<Compose> : )", instead of having to go find it in a character-picker or memorize arcane keystrokes that bear no obvious relation to what I'm actually trying to type?

• Similarly, where's CircularScrolling? Why do I have to keep pawing at the touchpad to scroll from one end to the other?

• And where's LockedDrags? It's physically fatiguing, that the only way to drag beyond the length of a single trackpad-swipe requires holding down the springloaded trackpad (though I note that this might not be as bad if the physical `click' mechanism in Apple's trackpads wasn't as awkward as it is--with the touch surface itself doubling as the (giant) button instead of having a defined button area outside of the touch surface, and with the spring resistance increasing exponentially as the fingers move from bottom to top).

Yes, I do also have complaints that aren't with the GUI--like the fact that the Mac laptop goes to sleep when closed ("even if plugged into the wall", most critics say; though my criticism is more that it immediately goes to sleep even if it's not plugged into the wall, because I'm much more likely to close a laptop and want my computations to keep running if I'm walking to another room with it). It's vexing that there's no apparent way to remedy that as a user. It's also vexing that so much beyond mDNS actually goes through mDNSResponder--and that it just spontaneously stops working and requires a sudo killall -HUP mDNSResponder (if you're suitably savvy, or a reboot if you're not; just like the bad old days, a decade ago, when we nscd used to cause the same problems).

But those are nits compared to the GUI problems--because the GUI is a constant source of frustration. And the Mac `whoosh factor' doesn't even begin to make up for it--because even that is lacking: you want `whoosh'? Where are the `wobbly windows' with the sense of mass and... palpability that I've had on my desktops for years?

And, oh--what really cements the "cheap Linux clone" image? That, when Steve Jobs first announced Mac OS X to the world, the best thing that even he had to say about it was, "it's very Linux-like".

Given how much work from 10 years prior Apple apparently got to reuse in building Mac OS X, it seems surprising that, almost another decade in, they still hadn't found the resources to actually polish it to the level of the open-source systems.

[Reply]

01:32: Whole-Home Audio with MPD + PulseAudio

I have a whole-home audio system that I cobbled together out of spare PCs and low-cost, low-power plug-computers running a mostly-stock Debian 6.0 with MPD and PulseAudio, and which works better than any of the prefabricated solutions that I could find. Not only is it better, but it deployed cheaper, and it was actually quicker to build it than it would have been to finish evaluating the canned solutions and buy one. And, since the protocols (and software) in use are all open standards and Open Source, there's no danger of vendor-lock.

This setup uses multicast RTP with latency-matching across all nodes in the network; I have only one `channel' right now (in the radio-tuner or input-switching sense, not in the `mono vs. stereo' sense), but it's possible to define multiple channels (or `sources', in proper home-audio vocabulary) by giving them separate multicast addresses, and then a given receiver can be siwtched to another channel just by changing the multicast address on which that receiver listens.

Because of the latency-matching, multiple receiver-nodes (to the extent that the ear can tell) all have their playback perfectly time-synced such that there's no `echo' or `reverb' effect when standing between two adjacent rooms with separate receivers. I actually compared this against how well two different FM radios in adjacent rooms sync to the same radio station, and the RTP system did better. Really, multicast RTP over ethernet + dynamic resampling-algorithms with latency-analysis on pentium-class CPUs with network time-sync... provides quite a convincing emulation of speaker-wire. Of course, it also provides a lot of dreamy features that speaker-wire... can't even dream about.

That it's MPD-based means that I can have a single playback- and playlist-control server for the entire house, accessible from anywhere on the network; in other words, I have multiple `single points of control': client UIs are available for desktop and laptop computers of all OSes, Android devices, my friends' Apple iThings (which can automagically discover the MPD server via ZeroConf), etc.--there's even an adaptor that enables `dumb phones' with Java ME to control MPD via bluetooth (or Wi-Fi, if they have it).

MPD manages playlists on the server, and can be told by the clients to load them or to create and store new ones--and playlists can include not just any of the tracks stored on the server, but also anything available via an HTTP URL (e.g.: Internet radio, or an audio-file shared by a laptop or other system on the LAN).

Of course, Using MPD also means that I can use all of the tools and plugins that exist for MPD--like last.fm/audioscrobbler support, and my `mpdjay' autojockey script (which elicited such a positive response from my wife--along the lines of `OMG it's so awesome! Can you make me a portable version‽'--that we now both have NanoNote units running a pocket-sized setup similar to this, but without the multicast).

And MPD does gapless playback, and it can use ReplayGain to automatically adjust for differences in overall volume between different tracks or albums--or even do dynamicrange compression when you want background-music in a relatively noisy environment. And, on the subject of volume-control: there's even a central volume-control--so that you can turn the whole house's volume up or down, after you've got the individual output-volumes set relative to each other.

We generally run GMPC or Sonata on our desktop and laptop systems (though I sometimes like ncmpc for its extremem keyboard-friendliness--and it's what I run on my NanoNote..., but that's mostly another story), my wife runs the Remuco JME app on her Nokia (Symbian) phone, we use PMix on our Android tablet, and our iFriends use something called "MPoD", when they're visiting. And there are plenty of other clients available.

How does it all work?

MPD runs on the machine hosting all of the audio-files, which is set-up as an RTP sender--and, in my case, without any local speakers: all of the `actual audio output' is done on `receiver' nodes elsewhere on the network (my MPD server is a noisy old machine that we keep down in the oubliette/basement).

In /etc/mpd.conf, MPD can be told to use PulseAudio for output with a stanza like:

audio_output {
    type            "pulse"
    name            "MPD Stream"
    sink            "rtp"
    description     "what's playing on the stereo"
    mixer_type      "software"
}

... where "rtp" is the name of a sink defined in /etc/pulse/default.pa via:

load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100
load-module module-rtp-send source=rtp.monitor

That last line is the one that actually makes the RTP multicasting happen.

Now, keep all of the system clocks tightly synchronised so that PulseAudio can actually determine the network latency (by comparing the source timestamp on the RTP packets to the system time on the receiver), and then it's just a matter of also running Pulseaudio on the other hosts--but with those PulseAudio instances setup as receivers, which can be done in the respective /etc/pulseaudio/default.pa files with...:

load-module module-rtp-recv

... or, if you have a GUI running on the receiver machine(s), you can just toggle-on the `enable Multicast/RTP receiver' setting in paprefs.

Caveats

Actually, it can be a little more complicated, because:

• PulseAudio defaults to doing something clever that should make playback better but which, as I understand it, tends to trigger bugs in ALSA; so any "load-module module-udev-detect" directives in default.pa may need to be modified to be "load-module module-udev-detect tsched=0" on each host.

• There were major problems in PulseAudio's latency-matching code that weren't resolved until this past January; so you want PulseAudio 0.9.23 or later, but that didn't actually exist yet when Debian 6.0 was released. I just grabbed src/modules/rtp/module-rtp-recv.c from git and spliced it into the version of PulseAudio that Debian already had (there were a couple of minor wrinkles, there, that I needed to smooth out--nothing hard, though). Figuring out that this module was just buggy and needed to be updated was probably the biggest problem that I ran into.

• The ARM-based plug-computers that I'm using have no floating-point units, which means that PulseAudio needs a little bit of additional configuration before it will work entirely right on them and produce sound reliably through the USB audio-adaptor.

• If your RTP-transmitter machine has multiple network interfaces, make sure that you're routing the multicast packets out over the correct one--I did run into that problem!

• If you're using DHCP, the system may hiccough when the hosts go through DHCP cycles, so you'll want to find a way of setting your network up such that your audio-system doesn't decide to renew its DHCP leases in the middle of a party.

Addenda

I initially installed PTPd for super-accurate clock-sync between hosts, but ntpd should actually provide sufficient precision. You can use PTP to ensure that all of the nodes on a LAN are kept in very tight sync, even if their collective idea of `what time is it?' isn't actually accurate. If your LAN is connected to the Internet, then it's probably sufficient to just use NTP--which will allow your clocks to also be accurate in addition to being reasonably precise.

I also installed rtkit, which PulseAudio can use to get realtime scheduling; in Debian, I had to get this from Wheezy/testing, but it installed fine on 6.0/Squeeze.

Under GNOME on my normal PCs, PulseAudio starts automatically; on the plug-computers, I had to find another way to make PulseAudio run automatically, and the most sensible thing was to hook into Debian's `ifupdown' system by adding `up' and `down' options to the definition of the plug's ethernet interface in /etc/network/interfaces, such that the complete definition of eth0 looks like this:

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
        up su pulse --login --shell /bin/sh \
                    --command 'pulseaudio --exit-idle-time=-1 --daemonize'
        down killall pulseaudio

The day after I got everything working, the hard disk in one of my `speaker-wire emulator' nodes died....

[Reply]

21:26: What have you tried?

If you've regularly googled for technical stuff as part of your job as a professional hacker over the past decade, you may have noticed the (ever increasing, it seems) number of dumb questions on developer forums--questions where people not only don't RTFM, but aren't even trying to solve it themselves. A friend of mine found himself wading through this when he came across Matt Gemmell's article, `What Have You Tried?'.

It made both of us smile, but I wish it hadn't--I wish it wasn't so right....

I've been periodically trying to reconnect with the Python programming community, over the past few years; I go back to the newsgroup/mailing-list... and, every time, find that a greater and greater share of the traffic is people just wanting someone else to do their homework for them.

Some of them, at least, are quite bluntly honest about it--writing things like, "I don't want to learn how to program or how to write Python, I just want to solve this problem". Some of them aren't. Neither group is really the type I want to hang with, though.

So I find myself drifting further away from the Python community, and thinking that maybe it's just not even a world I want to be part of anymore--I seem to remember a time when most of the people there seemed bright and help-ful, but now they're all so dull and help-less, and most of the ones who have any intent seem to be set on just making rude noises. And I wonder if maybe it's just that I've changed since that time--if maybe I used to be more like the current crowd.

But I'll bet that the crowd has actually changed, too--and that it's largely just the sort of change that comes as a side-effect of popularity.

Back in 2004, Paul Graham wrote `The Python Paradox', which starts out:

In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.

I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.

Seven years later, Python programmers are dumb. What happened? Well, now Python is something that can get you a job--it's actually popular. And so is programming in general--I guess college-bound kids finally got wind of how much some of us get paid, in this field (or something--though I guess they somehow missed the parts about things like 80-hour work-weeks).

I guess it just makes those of us who can actually think and learn and do stuff look better, though....

[Reply]