Going from zero
A friend of mine and I were discussing cars the other day. He said that he
thought the invention of the electric motor was a curse on cars, because it
meant you wouldn't have a gearbox to control which gear you were in. A
suitable electric motor has enough power to drive the car from zero to a
comfortable top speed (110km/hr) at a reasonable acceleration using a fixed
gear ratio - the car stays in (in this case third) gear and you drive it
around like that. He maintained, however, that you needed to know which
gear you were in, and to change gears, because otherwise you could find
yourself using a gear that you hadn't chosen.
I argued that, in fact, having to select a gear meant that drivers both new and experienced would occasionally miss a gear change and put the gearbox into neutral by mistake, causing grinding of gears and possible crashes as the car was now out of control. He claimed to have heard of a clever device that would sit over your gearbox and tell you when you weren't in gear, but you couldn't use the car like that all the time because it made the car too slow. So you tested the car with this gearbox-watcher, then once you knew that the car itself wouldn't normally miss a gear you just had to blame the driver if the car blew up, crashed, or had other problems. But he was absolutely consistent in attitude towards electric motors: you lost any chance to find out that you weren't in the right gear, and therefore the whole invention could be written off as basically misguided.
Now, clever readers will have worked out that at this point my conversation was not real, and was in fact by way of an analogy (from the strain on the examples, for one). The friend was real - Rusty Russell - but instead of electric motors we were discussing the Go programming language and instead of gearboxes we were discussing the state of variables.
In Go, all variables are defined as containing zero unless initialised otherwise. In C, a variable can be declared but undefined - the language standard AFAIK does not specify the state of a variable that is declared but not initialised. From the C perspective, there are several reasons you might not want to automatically pre-initialise a variable when you define it - it's about to be set from some other structure, for example - and pre-initialising it is a waste of time. And being able to detect when a variable has been used without knowing what its stage is - using valgrind, for example - means you can detect subtle programming errors that can have hard-to-find consequences when the variable's meaning or initialisation is changed later on. If you can't know whether the programmer is using zero because that's what they really wanted or because it just happened to be the default and they didn't think about it, then how do you know which usage is correct?
From the Go perspective, in my opinion, these arguments are a kludgy way of seeing a bug as a feature. Optimising compilers can easily detect when a variable will be set twice without any intervening examination of state, and simply remove the first initialisation - so the 'waste of time' argument is a non-issue. Likewise, any self-respecting static analysis tool can determine if a variable is tested before it's explicitly defined, and I can think of a couple of heuristics for determining when this usage isn't intended.
And one of the most common errors in C is use of undefined variables; this happens to new and experienced programmers alike, and those subtle programming problems happen far more often in real-world code as it evolves over time - it is still rare for people to run valgrind over their code every time before they commit it to the project. It's far more useful to eliminate this entire category of bugs once and for all. As far as I can see, you lose nothing and you gain a lot more security.
To me, the arguments against a default value are a kind of lesser Stockholm Syndrome. C programmers learn from long experience to do things the 'right way', including making sure you initialise your variables explicitly before you use them, because of all the bugs - from brutally obvious to deviously subtle - that are caused by doing things in any other way. Tools like valgrind work around indirectly fixing this problem after the fact. People even come to love them - like the people who love being deafened by the sound of growling, blaring petrol engines and associate the feeling of power with that cacophany. They mock those new silent electric motors because they don't have the same warts and the same pain-inducing behaviour as the old petrol engine.
I'm sure C has many good things to recommend it. But I don't think lack of
default initialisation is one.
posted at: 11:00 | path: /tech | permanent link to this entry
Critical Thinking
In the inevitable rant-fest that followed the LWN story on the proposal to
have /lib and /bin point to /usr/lib and /usr/bin respectively (short story), I
observe with wry amusement the vocal people who say "Look at PulseAudio - it's
awful, I have to fight against all the time, that's why we shouldn't do this".
The strange, sad thing about these people is that they happily ignore all those
people (like me) for whom PulseAudio just works. There's some little concieted
part of their brain that says "I must be the only person that's right and
everyone else has got it wrong." It's childish, really.
And in my experience, those people often make unrealistic demands on new software, or misuse it - consciously or unconsciously, and with or without learning about it. These people are semi-consciously determined to prove that the new thing is wrong, and everything they do then becomes in some way critical of it. Any success is overlooked as "because I knew what to do", every failure is pounced on as proof that "the thing doesn't work". I've seen this with new hardware, new software, new cars, new clothes, new houses, accommodation, etc. You can see it in the fact that there's almost no correlation between people who complain about wind generator noise and the actual noise levels measured at their property. Human beings all have a natural inclination to believe that they are right and everything else is wrong, and some of us fight past that to be rational and fair.
This is why I didn't get Rusty's post
on the topic. It's either completely and brilliantly ironic, or (frankly)
misguided. His good reasons are all factual; his 'bad' reasons are all
ad-hominem attacks on a person. I'd understand if it was e.g. Microsoft he was
criticising - e.g. "I don't trust Microsoft submitting a driver to the kernel;
OT1H it's OK code, OTOH it's Microsoft and I don't trust their motives" -
because Microsoft has proven so often that their larger motives are
anti-competition even if their individual engineers and programmers mean well.
But dmesg, PulseAudio, and systemd have all been (IMO) well thought out
solutions to clearly defined problems. systemd, for example, succeeds because
it uses methods that are simple, already in use and solve the problem
naturally. PulseAudio does not pretend to solve the same problems as JACK. I
agree that Lennart can be irritating some times, but I read an article once by
someone clever that pointed out
that you don't have to like the person in order to use their code...
posted at: 10:16 | path: /tech | permanent link to this entry
PHP Getopt::Long
In my current work I have to occasionally work with PHP code. I don't really
like PHP, for a variety of otiose reasons. But one of the things that
surprised me was that it didn't have an equivalent to Perl's
'Getopt::Long' module.
There are a couple of other modules that are in PHP's PEAR package repository
which attempt to handle more than PHP's built-in getopt function, but all of
these lack a couple of fundamental features:
So I wrote one.
The result is available from my nascent PHP Subversion library at:
http://tangram.dnsalias.net/repos/PWphp/getopt_long/.
It's released under version 3 of the GPL. It also comes with a simple test framework (written, naturally, in a clearly superior language: Perl).
This is still a work in progress, and there are a number of features I want to add to it - chief amongst them packaging it for use in PEAR. I'm not a PHP hacker, and it still astonishes me that PHP programmers have been content to use the mish-mash of different half-concocted options for command line processing when something clearly better exists - and that many of the PHP programs I have to work with don't use any of those but write their own minimal, failure-prone and ugly command line processing from scratch.
I'd love to hear from people with
patches, suggestions or comments. If you want write access to the repository,
let me know as well.
posted at: 13:19 | path: /tech | permanent link to this entry
Adding Cans to C
I've been meaning to copy some of my personal C libraries to
CCAN, Rusty Russell's C Code Archive.
It's not yet quite as comprehensive as he would like, I suspect, but it's
certainly a good project. And I think, bold as this may be, that I have
something to offer it even if I'm not
a full-time C programmer.
The thing that's scared me off is the whole "meeting someone else's standards" thing. So after Rusty's talk at OSDC this year, and finding out that 'ccanlint' can prompt you with what you need to do to make a good package, I decided to give it a go. And after I started having a few minor problems understanding exactly what I needed to do to get it working, I decided to write it down here for other people.
LED strip lighting for the deck
Yesterday we got the electrician to install a switch in the dining room which
would turn on a power point in the ceiling. This powers a 100W 12V DC power
supply which in turn powers twenty metres of LED strip lighting. The parts
list:
Trying to get a photo that shows what the eye sees of the strip when lit is hard - the camera just thinks it's way too bright. This is the closest I could get with our camera:
With the eye you can see the individual LEDs and they're bright but not so bright as to be difficult to look at. So the strip doesn't make the deck feel too bright or oversaturated. The light is warm without being monochrome or too intense. And the fact that it's a strip means that you don't get shadows or bits of the deck that are dark - the whole deck feels quite evenly lit, even at the corners.
100 watts feels like a lot, but in comparison to even one 18W fluorescent
globe per space between beams (12) it is still much more efficient on power.
That arrangement of fluorescent bulbs would also mean shadows, single point
sources, and having to put an extra beam in the middle of the deck. And let's
not even consider spot lights. No, this is a really good layout.
posted at: 09:01 | path: /tech | permanent link to this entry
Who are you trusting
The "Secure Boot" proposal from Microsoft - to turn on digital signatures on new
UEFI-enabled motherboards so that only signed operating systems get booted,
allowing them to get motherboard manufacturers to lock Linux out under the guise
of "preventing malware" - is worrying enough as it is. Several large Linux
companies - Canonical and Red Hat amongst them - have already been working on white
papers, and an expert in the field has proposed IMO a better
solution to the problem. But really, if you think about it, Microsoft should be
working to prevent the whole thing working at all.
Why? Very simple. Just think of the number of state-level attacks on software and Internet infrastructure in recent years. "Hackers" getting fraudulent SSL certificates issued for *.google.com and other sites. People requesting Mozilla remove CNNIC from the certificate authority list because of the Chinese government similar faking of SSL certificates. Malware created by the German government for spying on people. British companies selling malware to the Egyptian government. The list goes on.
One can easily imagine any government in the world telling motherboard manufacturers that they need to install the government's own public keys in order to import motherboards into the country. It's obvious in the case of countries like Iran, Syria, and Jordan, and it's no stretch to imagine the US, Australian or any other 'Western' government doing it under the guise of "protecting our citizens". After all, we do want the government to snoop on those evil child molesters, dont' we? Or at least, the people the government tells us are child molesters. Or, at least, the people who turn out to have child abuse material on their computers after the government has done their investigation. They wouldn't use those powers to spy on ordinary citizens, right? Right?
Wrong. For state-level actors, it's not about the ordinary citizens. It's about protecting the status quo. It's about protecting their access to information and protecting their powers. The idea that someone can lock government spyware out of their computer has an easy solution - make sure that the computer itself will always install the spyware. And they have the power to go to motherboard manufactuers and get these keys installed. It's a no-brainer for them, really.
I also have no doubt that secure booting to a secure operating system will do little to stop real malware. There's always flaws to be exploited in something as large and kludgy as Microsoft's software. The phenomena Microsoft is allegedly trying to protect against - rootkits that start at boot time - are a relatively small portion of the malware spectrum. And if you're going to let an unsigned binary run - the alternative being to lock all but the large players out of the Windows software market - then malware is already exploiting the user's trust in the system and their lack of knowledge about what is good software and what isn't. "Your PC is already infected" and all that; it's trojan horses all the way down.
I don't think Microsoft is going to care that state-level players can exploit
the system their proposing. It's not like they don't already give the source
code to the Chinese government and so forth. But I think the rest of the PC
using world has a right to be very worried about a system that will tell you
that it's running signed software without you being able to choose which
signatories you trust. And choice is never going to be on the agenda with
Microsoft.
posted at: 21:13 | path: /tech | permanent link to this entry
Wag
This is half a bleg and half an idea.
Trying to get useful information of log files that are being continually written is kind of frustrating. The usual Linux method is to tail -f the file and then apply a bunch of grep, cut, sed or awk filters to the pipeline. This is clumsy if you don't know what you're dealing with or looking for yet, and there are a bunch of other limitations with this approach. So my idea is to create an application with these features:
If such a thing even vaguely exists, please
email me. Otherwise I'll have to
think about learning how to write inotify-based ncurses-driven applications
in my copious free time.
posted at: 14:10 | path: /tech | permanent link to this entry
Every car should have one
What I want is a small device that has a fuel flow meter suitable for use in
a car or motorbike, and a digital radio (e.g. bluetooth) to connect to it.
It can run of the car's 12V power system, and simply reports the amount of
fuel used every second in serial form.
Then I want a piece of software, say on my android phone, which reads information from the fuel meter and GPS coordinates. It then records how much fuel is used and where the car was at the end of that second. This can be used simply to work out how much fuel is being used, or a kilometres per litre or miles per gallon figure based on the current distance travelled. The software can then show you your average fuel consumption and km/l 'score' per trip.
But what constitutes a trip? Well, the software can work that out fairly easily - the engine is consuming fuel constantly while it's on, and people usually start it before the start of the trip and turn it off at the end of the trip. A fairly simple check of start and end points could then group your trips by their purpose - going to work, going shopping, etc - and report your average and best score for each journey of the same purpose. You could then also compare fuel efficiency when going at different times and using different connecting roads to determine, on average, which paths and times were more efficient uses of your petrol.
But journeys often start the same way - if you live in a cul-de-sac, you always drive to the end of it to get any further, for example. So looking at the paths can then break those into segments that are common, and you can be scored on your individual performance per segment. This also means that if you drop into the shops on your way to work then this counts for two or more separate segments rather than one. The algorithm could both find short segments - roads you always went along and never deviated from - and long segments that you occasionally deviated from but mostly drove in one go.
For many journeys there's more than one way to get there, and after a period of time the software can tell you which route was the most optimal and even possibly when to drive it to get the best efficiency. This would have saved a friend of mine, who had to suffer her father going many different ways between two points on a common journey in Brisbane to determine, over time and in varying traffic, what the most efficient way was. Of course, it can tell you what your best time was and that may be a different route from the most fuel-efficient path.
And then it can start to challenge you. You want to drive to work? How about doing it using less fuel than your best effort so far? It may even be able to tell you specific segments where you can improve - where your fuel efficiency varies widely, or where it is greater than your average over similar terrain. Once you get something that can actually tell you how to improve your fuel efficiency, I think that'll make a lasting difference to how much money people spend on fuel. Classic positive feedback technique.
Finally, a device which would actually offer to provably improve your fuel efficiency.
Sadly, it joins every other device out there being touted by snake oil
salesman, because - like them - it doesn't exist.
posted at: 23:18 | path: /tech | permanent link to this entry
GNOME 3 improved
As part of starting at my new place of
employment, I've installed the beta of Fedora 15 (because the real thing
comes out tomorrow, curse it). With it comes GNOME 3, the latest update of
the GNOME window manager.
So far my experience is pretty good. Yes, it's different, but no, it's not that different that I can't learn how to use it. It's a case of not thinking "why can't I do that the old way" but "I wonder what the new way is", and for the most part it's not that painful. Of course, there were a few things that I did want to make work the same as my previous GNOME setup and the main one was focus following the mouse pointer. After a bit of research on the net, I found the necessary command and will post it here for reference:
gconftool-2 -s /apps/metacity/general/focus_mode -t string mouse(I'll spare my readers my cunning arguments about why focus following the mouse is the obvious, natural and optimal system for interfaces with an explicit focus indicator such as a mouse pointer. Save to say, just use it.)
Another thing that's changed is that Alt-TAB now groups all windows by application - all Firefox windows are treated as one group for the purpose of tabbing around, for example. When one application has multiple windows open, a little down-arrow appears at the bottom of its icon and, by mousing over it, you can then select the sub-window you require. This, however, is inconvenient if, like me, you use the keyboard a fair bit - moving to use the mouse takes time and effort. I discovered, with a bit of experimentation, that you can use the arrow keys for this as well - press Alt-TAB and use either TAB and Shift-TAB or left and right to navigate; when an application with sub-windows is selected, use down to show a list of its sub-windows and left and right to select from there.
Maybe there are other ways of using this; that's what worked for me. But it shows that a bit of experimentation can take less time than grumbling about how everything's changed and it no longer matches what you see.
And I think it's going to be a surpreme bit of irony that there'll be all
these Linux experts complaining about how GNOME has broken everything and they
want their old GNOME look and feel back - the same people who keep on looking
down on their friends for not wanting to move from Windows or OS X to GNOME
because "it's a different look and feel". Take it on the chin, people.
posted at: 00:01 | path: /tech | permanent link to this entry
LWN Professional Supporter
Today I subscribed to Linux Weekly News for another 11 months at the new
Professional Supporter level.
Rusty asked for a higher level
of subscription to be available a while back, and Jon (with his
characteristic gentle, wry humour)
implemented it recently.
It took me a little time to actually raise my subscription level - I had spent a bit of money on bike parts and other stuff and, though I could still have afforded it, just didn't feel like watching all my money escape in one go. (I'm still recovering from my somewhat exuberant donation to the flood relief funding at LCA 2011). But finally the stars aligned, the checksums matched and I paid for the shiny stars on my name.
Why? For two reasons. One, as Rusty says, is that Jon and the team at LWN are doing huge, exemplary, and difficult work condensing all the news that's important in the FOSS gamut into one easy-to-read site. If I had to buy a magazine for that I'd be paying at least half that. The second reason is congruent to my decision to support webcomic artists: that I love supporting anyone who is getting to do the thing they love. I love working with computers and I'm lucky enough to have found companies that employ me for my skills. If you want to be a journalist who writes about FOSS, it's much more difficult to find a company that gives you the freedom you need to write about the things you love. Being able to support them in that is a good thing.
Plus, I can write it off as an educational expense on my tax, and I get Jon owing me a beer rather than me owing him one :-). So it's good all round.
I'm not calling it maniacal. It's a perfectly sensible judgement in my opinion. There are lots of people who read LWN who are paid well and could easily afford to support them at that level. Hearing Jon's talk about running LWN for thirteen years was an insight into the trials and obstacles confronting anyone that wants to do as LWN has done. Given that there are well-known but not particularly well-respected IT news websites out there that also send their reporters to LCA - usually, it would seem, to stir up trouble - having LWN around to provide an intelligent, reasonably even-handed report on what goes on in the FOSS community is a great, unsung boon to us all.
Jon's philosophy in setting the prices for subscriptions - and allowing
mostly unrestricted access for free - has been that Linux users like things to
be free. I would argue that they like their software to be both zero-cost and
unencumbered, but I don't think that necessarily extends to them expecting a
free ride from other people. I'm sure there are lots of people that can afford
to support LWN, even in a small way, for the service it provides. It maybe not
at the professional support level, but having this option gives people like
myself to support it at an appropriate level for our income.
posted at: 00:01 | path: /tech | permanent link to this entry
A pack of improvements
I (finally) decided to make three changes to my
battery pack
calculator. One is to lift the maximum weight of the pack up to 500kg -
this allows more realistic pack sizes for large vehicles such as utes and vans.
The second is a check box to only show available cells - cells that have at
least one online store selling them. This cuts out most of the unobtainable
cells - cells (like Kokam) that are price-on-application are usually fairly
expensive anyway and this at least gives you a ball-park figure for what the
more common cells can do for you.
The final one is to allow you to sort the packs by some of the fields displayed. The critical ones are the cell type, pack weight, pack amp-hour rating, price, watt-hours stored and maximum amp delivery. After a bit of help from Khisanth in ##javascript to get the scripting working - basically, don't have a submit button named (or with an ID of) 'submit' or you override the form's natural submit() function - it works now.
I hope people find these improvements useful - I certainly am!
posted at: 10:53 | path: /tech/web | permanent link to this entry
The short term fallacy
There are a couple of things that I'm butting my head up against these days
that all seem to be aspects of the same general problem, which I mentally
label the 'short term fallacy'. This fallacy generally states that there's
no point planning for something to survive a long time because if there are
legacy problems they can be solved simply by starting again. Examples of this
are:
Yes, these problems are hard. Yes, limits have to be set - processors will use a certain number of bits for storing a register and so forth. Yes, sometimes it's impossible to predict the things that will change in your system - where your assumptions will be invalidated. But we exist in a world that moves on, changing constantly, and we must acknowledge that there is no way that the system we start with will be the same as the system we end up using. The only thing that's worse than building in limitations is to insert them in such a way that there is no way to upgrade or cope with change. Limitations exist, but preventing change is just stupid.
And the real annoyance here is that there are plenty of examples of other, equivalent systems coping with change perfectly. LVM can move the contents of one disk to another without the user even noticing (let alone having to stop the entire system). Tridge and Rusty have demonstrated several methods of replacing an old daemon with a newer version without even dropping a single packet - even if the old program wasn't designed for it in the first place. File systems that insist that it's impossible to shrink are shown up by file systems with similar performance that, again, can do so without even blocking a single IO. You don't even have to reboot for a kernel upgrade if you're using ksplice (thanks to Russell Coker for reminding me).
It's possible to do; sometimes it's even elegant. I can accept that some
things will have a tradeoff - I don't expect the performance of a file system
that's being defragmented to be the same as if it was under no extra load.
But simply saying "we can't shrink your filesystem" is begging the question
"why not", and the answer will reveal where you limited your design. The
cost, in the long run, will always be higher to support a legacy system than
to future-proof yourself.
posted at: 23:26 | path: /tech/ideas | permanent link to this entry
Edgar Wallace - The Green Rust
I've been reading ePub books
on my Samsung Galaxy S almost since I got it, and it's been a Good Thing.
The screen is large enough to read text fairly quickly - a speed reader could easily scan each line in portrait mode without moving their eyes horizontally at all. Yet it's not too large to be uncomfortable to hold. The Alkido reader supplied is adequate but I prefer FBReader - with a nice serif font (although there's little evidence at all for it being more legible, it does render the italics of some of my books correctly - something I'd originally thought had been an error in the book encoding or the reader), its 'night-time' white-on-black mode, and its better organisation of my library.
Mostly the books I've picked up have been from Project Gutenberg, which my readers probably know well. As my views on 'strong' copyright are also fairly well known it would be otiose to relate them, but I see Project Gutenberg as proof that the doomsday scenarios of the 'strong' copyright lobby paint of the time after the copyright in a work expires - that either everyone will be copying it like crazy and making money out of it, or that it will mean obscurity and lack of recognition for the author - are baseless. Project Gutenberg makes these works available for free and by doing so the authors works are preserved and gain value by their availability, but without any one company profiting from the process. In fact, the 'strong' copyright arguments basically devolve to "but we won't be making any money from it", even though often they aren't anyway.
(Message to Disney: there are children growing up now who have no idea what Mickey Mouse is. Deal with it.)
Anyway, one of my finds was The Green Rust by Edgar Wallace, based on having found that two early Agatha Christie novels - The Mysterious Affair at Styles and Secret Adversary - were available, based on having read through A Study in Scarlet and looked up the subject "Detective and mystery stories". I'd link you to that search but for several badly thought-out reasons Project Gutenberg have decided that looking up a subject or author should have no well-formed, static URL.
Now, Edgar Wallace was a name I recognised from a different context. Many years ago Severed Heads released a track called "Dead Eyes Opened", originally released in 1984 but with a new dance remix in 1994 that became their only really mainstream hit. It borrows from Edgar Lustgarten's audio recording of the crime that I later found out was incongruously called The Crumbles Murders. In it, he says:
Then — I owe a debt here to Edgar Wallace, who edited the transcript of the Mahon trial — …
Yes, it's that Edgar Wallace. Not only a famous court reporter but also an
author of many fiction novels, mostly detective and mystery stories, and as the
part inventor of King Kong. And I have to say that his writing is quite
enjoyable - not as old as Doyle's and with a touch of genre-savvy, and with a
bit less reveal-everything-at-the-end compared to Christie. It's strange how
these little synchronicities in life come about.
posted at: 17:14 | path: /tech | permanent link to this entry
CodeCave 2011 Update 1
Just a quick update to my readers to say that
CodeCave 2011 is definitely
going ahead and will be on the 3rd to 5th of June. Cost will be about $80
per person for the accommodation. I have about three or four more places,
depending on a few factors. I haven't worked out a cost or menu for the
meals for the weekend, but it will probably be fairly reasonable - $40 for
the weekend is the figure I'm aiming for. Please
email me if you'd like to come
along!
posted at: 21:27 | path: /tech/ideas | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.
You can also read this blog as a syndicated RSS feed.