Hyperlink[0] are fun.

• [0] http://en.wikipedia.org/wiki/Hyperlink [0:1]
  • [0:1] http://en.wikipedia.org/wiki/Hyperlink [0:2]
    • [0:2] http://en.wikipedia.org/wiki/Hyperlink [0:3]
      • [0:3] http://en.wikipedia.org/wiki/Hyperlink [0:4]
        • ...

We got home from our week in Arizona late last night. We decided to drive non-stop yesterday, and get home in a day, rather than split it over two days like we did getting there. It ended up taking around 15 hours (we had an unexpected delay at Lost Hills because we found a stray dog (we initially thought it to be injured to boot) and Sarah was trying to get hold of some local animal control people to do something about it), otherwise it'd have taken closer to 14 hours. The drive to Phoenix was pretty uneventful. We took our time leaving Mountain View on Sunday (we had an early Thanksgiving dinner with all of our neighbours on Saturday night), and decided to call it a night at Cabazon. For about the same price that we stayed in a crappy motel last time we went this way, we stayed at the Morongo Casino, which was really nice. We were in a "Canyon View" room, and, well this is what the view looked like... We arrived at Craig and Sarah's place at about 5pm on Monday afternoon. Their new place is really nice. It's huge, with a huge yard, and a nice view of the hills. I've found suburban Phoenix (well Peoria to be precise) to be the closest looking thing to what I consider "normal Australian suburbia" that I've seen so far in the US. Granted, Peoria's a bit upmarket (at least the part that Craig and Sarah live in). So we spent a day and a half vegging out at Craig and Sarah's place, then on Wednesday afternoon, we headed off to Woods Canyon Lake, in the Sitgreaves National Forests. I rode most of the way with Craig in their new motor home, and then swapped to drive our car after we got close to our destination. It turns out that the headlights in RVs are universally crap, so it was better for the Prius to be out front lighting the way on the gravel road. I'd always associated Arizona with cacti and sand, but as it turns out, the majority of the state is forest. We arrived at the campsite after nightfall, and set up shop. We met some of Craig and Sarah's friends that night, who were all very friendly towards us. It was ridiculously cold that night. We went to bed rather under-dressed for the temperature, and absolutely froze. The next day (Thursday), we all drove from the campsite (Craig towed their Jeep behind the RV) to Woods Canyon Lake itself, and went fishing. Arizona fishing licences for non-Arizona residents were a bit on the expensive side, so Sarah and I just hung out on the rocks and chatted to people and took photos. The collective haul of trout from about 5 hours fishing was pretty impressive. I'm not quite sure why, but Friday was the group Thanksgiving dinner. Everyone pitched in, and cooked up a storm. They deep-fried three turkeys (which came out very nice and looking much less like KFC than I expected), and we had way more food than we needed. We all ate outdoors at around 3:30pm, and it was about 33°F (0.55°C). The only downside of this (aside from it being bloody cold) was the leftovers went cold almost instantly, so going back for seconds was a bit of a disappointment. Everyone gravitated back to the fire pretty quickly afterwards. It got pretty cold that night. I think it was down around -4°C when we went to bed that night. We left a bit before 8am the next morning, and the car thought it was -7°C outside. One of the other campers told Sarah his thermometer was reading something closer to -14°C. I'm not sure how cold it was when we were in New York in January, but I didn't think it was that cold. It was a good week away. The mix of camping and not camping was about just right. Now it's back to work for two weeks before we head off to Australia. Photos from the trip are here.

Now as anyone who knows me knows, I love Git. I find it gives a very productive and comfortable workflow. One of my favourite new(ish) features is git rebase --interactive, which along with cheap’n'fast branching gives a great way to hack and commit as you go and then later on refactor your work into sets of nice orthogonal patches. However, there I do still find a good few things wrong with git, so I’d like to discuss these problems and possible solutions:

1. Error Messages In general git has some terrible cryptic error messages. My favourite example is if you modify a file and then pull a change that modifies that file before you commit it: Updating beb8c37..b953e6f
test: needs update
fatal: Entry 'test' not uptodate. Cannot merge. WTF? what does uptodate mean? why isn’t it up to date? whats gone wrong? what should i do?
   Surely something like: Cancelling pull as 'test' has changes that would be overwritten by this pull. Please commit your changes or force an overwrite using the '--force' flag would be a lot better? I leave it as a reader excercise to repeat this process for most error messages…
2. The index Why oh why oh why is it called the index? It does no indexing as far as the user is concerned. Its name gives you no clue to what it is, you don’t know when or how you’re supposed to use it. git add and git rm modify it and it’s used all over the place by the obscure low-level git helpers that you stumble over. How about commit staging area, that being what it actually is. You could have nice commands like git stage and git unstage and git stage --interactive. That’d make more sense, right? Then git add and git rm would be a lot more meaningful, being only used when you actually want add or remove a file.
3. Remotes With git remote this is a lot better than it used to be - having to use cryptic refspecs (see git-pull manpage for the gory details). Unfortunately refspecs are still scattered all over the documentation just to confuse you… That should almost certainly be moved out to less user-visible documentation. The main issues I have now are:
   • Remote branches don’t always behave like local branches when they should. In particular git pull . <remote branch name> doesn’t work (and gives an obscure error) but git merge <remote branch name> does. remote branches should act just like local branches you can’t modify.
   • I’m not sure I like git branch -r to list remote branches, maybe git remote branches would be nicer and more obvious, or even git branch --remote
4. Lots of git-* commands that confuse people This is a common complaint, and I have to say that I agree. Why not put all the low-level commands in libexec? People who really use them often (which can’t be many!) can always add it to their path.
5. No bug tracker! For such a user-facing tool, a bug tracker would be very useful for users who lack the experience or time to get their hands dirty in the codebase. It certainly seems that just taking bugs to the mailinglist without a patch isn’t generally useful.

So, what do people think? What other bugbears do beginners and experienced git users see? Are these useful ideas? After some discussion, I’ll happily take these to the git mailing list and come up with some patches! Update:
Looks like people had some problems with my OpenID based login. Comments are now open.

The German language has an expression that is "Zeichen der Zeit". Literally translated this means "Signs of the time", the idea behind that expression is that sometimes there are certains things or events that are symptopmatic for a current development or a general change of times. One of these "Zeichen der Zeit" can currently be observed very nicely in our neighbourhood. In the last half year three shops in our direct vicinity closed down. One was a quite cute 60s cafe that was later rented out to a citizens' action committee, the second was a shop that sold wooden toys, the third was a health food shop. I don't know how long these shops where around, but all of them had lasted for at least a couple years if not longer. Now all three shops are rented out again, two are now temp work agencies, the third is a "consumer bank" that specialises on small consumer credits for things like cars, washing machines or entertainment electronics. Apparently they also cooperate with some mail order firms. Is this really where we want to go?

Update: Due to the popularity of this post I have created a T-Shirt and put it on sale at http://www.cafepress.com/email_eula . Update: Unlike most of my blog content I permit anyone to copy most or all of this post for commercial use (this includes blogs with google advertising) as long as they correctly identify me as the author. Usually I only allow such mirroring for non-commercial sites. Update: I now have a copy of this post at http://doc.coker.com.au/legal/conditions-email/ which I will modify if necessary. I have previously written about using a SMTP protocol level disclaimer to trump any legalistic sigs [1]. The conditions of sending mail to my server are now as follows:

1. A signature will in no way restrict my use of your message. You sent the message to me because you want me to read it (it was not mis-sent, my mail server does not accept mis-addressed mail). I will keep the message as long as I like either deliberately or because I forgot to delete it.


2. I reserve the right to publish any email that is threatening (including any threats of legal action). I don’t like being threatened and part of my defence is to publish such threats at an appropriate time. Anyone who is considering the possibility of threatening me should consider when their threat may re-appear.


3. I reserve the right to publish any email that is abusive/profane, is a confession of criminal or unethical behaviour, or is evidence that the sender is a liar or insane.


4. I reserve the right to forward all amusing email to my friends for their enjoyment.

My mail server will now provide the URL of this page to everyone who connects at the first stage of the SMTP protocol. When a mail server continues the connection that indicates acceptance of these conditions. This doesn’t mean that I wildly forward email and business discussions are kept confidential of course. I expect that most people don’t keep mail secret when it matches the conditions in my list above, unlike most people I’m publishing the list of reasons.

• [1] http://etbe.coker.com.au/2006/12/29/email-disclaimers/

Share This

This is a nice little bit of shell magic I discovered today:

trap true TERM
kill -- -$$

The first line means that when the shell receives a TERM signal, it executes true. The normal behaviour would be to kill the process, so this means that the shell is immune to people sending a TERM signal to it. The second line sends a TERM signal to the process group (- is the modifier to indicate a the process group of the PID, not just the PID) of the current process ($$). The end result? Everything spawned by this script which hasn't gone and re-parented itself is killed: the ultimate in cleanup. NP: Dedications, Klimek

There is an interesting web site WorseThanFailure.com (with the slogan “Curious Perversions in Information Technology”) that documents amusingly failed projects. The name used to be TheDailyWTF.com but changed due to the idea that for some projects success (interpreted to mean limping along in production) is worse than failure (being scrapped and re-written). I’ve created a new category WTF [1] on my blog to document such projects, both ones that I have personally witnessed and ones that friends and colleagues have seen. In the 90’s I spent some time working on an OS/2 GUI program to be the front-end for a mainframe backed system used by call-center workers. The first thing that they did was to develop a file naming scheme, they decided that all source files should be in the same directory (not unreasonable), but that 8.3 should be the limit of file name lengths in case there was a need to port the system to Windows 95. The fact that porting a program which did little other than display a GUI and talk to a S/390 server to a different OS was difficult (given the large amount of platform specific GUI code) was lost on them. Then they decided that the first two letters would be “FE” in case the source was merged with another bank project (of course the bank had many “Front End” systems talking to mainframes - so even this didn’t guarantee that they would be free of name clashes). Characters 3 and 4 were to represent the section of the program, and as the 3 character extension was one of “.h” or “.cpp” that left exactly 4 characters to name the file - we may as well have numbered the source files. Eventually one of the guys started making jokes about the file names by trying to pronounce them as words and that convinced a majority of the developers that the files should have long human-readable names. As the NMAKE expert (they insisted on not using unsupported software such as GNU make) it was my job to fix all the file names. The bank had an internal users’ group for the C++ development environment, but the contractors were not invited to attend. You might think that it would make sense to have the most skillful C++ programmers attend the meetings and share their knowledge, but apparently attending such meetings was a perk of being a permanent employee. What do you do when you have a C++ development project running behind schedule and a permanent employee who has had no prior exposure to C++ and wants to learn? One manager believed that assigning the junior programmer to the project is a solution to both problems - it was good for teaching the programmer C++ in a hurry but not so good for the deadline. There was a lot of excitement related to the back-end development. The mainframe guys assured me that CICS could never handle bad data and it totally wasn’t their fault if my program sent bad data to them and the region crashed. The first CICS region crash occurred when the mainframe guys told me to make the unused space in text fields “empty” - to a C programmer this means filling them with the 0 character but it killed the CICS region (apparently “empty” means filled with spaces to CICS programmers). A later region crash came when they told me to change the field length for the account name everywhere that it occurred - they told me that they wanted the change immediately - so I changed a macro definition, ran “make”, and sent a transaction with the changed size. Apparently “immediately” really meant “after we have spent an hour of software development changing magic numbers throughout our system”. I’m assuming that COBOL has some facility that roughly compares to C macros for defining field lengths and that it was the programmers not the language that was at fault. When the project became seriously behind schedule they hired some expert programmers from another country to help with the development. The experts decided that we needed to redesign the system (not that it had been designed in the first place) to use a “model view controller” architecture. When the real business logic is all on a S/390 and the only logic in the front end is to combine the contents of some screen-scrapes from a virtual 3270 terminal into a single GUI dialogue (with the first screen occasionally getting data from the IVR system) the benefits of MVC seem rather small. The new MVC version of the system was dubbed “phase 2″ and there were a series of deadlines for changing over from “phase 1″ which were missed. So the original team of developers continued on their project without any help from the “experts”. The last report I heard (some time after leaving the project) was that Phase 1 had gone live in production while Phase 2 was still being developed (at that time Phase 2 had a year of development and Phase 1 had about 15 months). The lesson to be learned from this is that management should only hire people that they can control. If you hire a consulting company and then let them do whatever they want (as opposed to solving the problem that they were hired to solve) then at best they will do no good and they may just slow things down. One of the more memorable incidents was when the project manager was talking to his 2IC, he said “I think we’re really breaking ground, [pause] I’m breaking wind and we’re breaking ground”. My desk was a few meters from where the wind (and ground) were being broken, I unfortunately was able to verify that wind was being broken but was not as certain about the ground. I did learn some useful things during this project, one was the fact that sample code from library vendors should not be trusted and ideally should be read from a print-out not pasted into the project source tree. The CTI library vendor had buffer overflows in their sample code. Another useful thing was the coin-tossing method of dispute resolution. If two good programmers have a disagreement about how to implement something tossing a coin is a quick way of resolving the dispute - this only works with two good programmers (in which case either idea will work). The project in question was messed up in many ways. I may write another post in the WTF category about it.

• [1] http://etbe.coker.com.au/category/wtf/

Share This

So, I've been off blogging for almost three months now -- from about mid-August to now. It's been kind of guilt-ridden, and it's also been kind of a relief. Being a B-list blogebrity is a direful burden, and having some time away was restful and relaxing and energizing. But now I'm ready to come back! One of the reasons that I haven't been blogging is that once you fall behind, it's really hard to catch up. So I've decided to not do the entire task at once. Instead, I'm just going to start a page on my 2007 Hiatus and fill that up as time permits. For those of you who care greatly about exactly what I did each and every day for the last three months, you've got a spot to read it. And, truthfully, I dropped out of the B-list ranks on Technorati during my time away. I'm back to my natural position as a C-list blogger, and baby, it feels good. Get ready for some photos of my cats, coming up soon! tags: blogging blogs me c-list hiatus

Feelings of loss One of the other main reasons I haven't been blogging in the last few months is that I've been losing weight. A lot of weight. I've dropped from a high body mass index (BMI) of about 43 -- dangerously high -- to my current sane but still high 33.6. I'd like to get down to a more reasonable BMI of 30 ("overweight") by the end of the year, and be somewhere around 25 ("normal") by next summer. I can lose weight pretty easily when I put my mind to it. Well, actually, it's still insanely hard, but I'm so damn stubborn and obsessive about things, when I actually sink my teeth into them, that it seems easy to the casual observer. My recipe is simple: reduce the amount of food I eat, do low-intensity exercise about an hour a day, and measure everything as well as possible. I eat 3 good meals a day -- about 50% fruits and vegetables, 25% complex carbs like rice or bread, and 25% protein like beans, tofu, fish or cheese. I steer clear of sweets and I drink alcohol only on occasion, and seldom more than a glass or two of wine. For exercise, I've been running around Parc Lafontaine or on a treadmill three days in a row, then on the fourth day lifting weights at a local gym on rue Gilford. I still have a ways to go, but the results have been good so far, and I'm feeling like I'm getting close to the neighbourhood of what I "should" weigh. I've been getting a lot of compliments from friends and family, which is a great motivator. Most of all, I feel good running, jumping, and playing with my daughter, which is the biggest reward of all. All that said, the exercise is taking an extra 1-2 hours out of my day, and blogging has been the main thing cut out to make room. But I think I can work around that now. tags: weight loss BMI diet exercise

Road trip We're leaving Tuesday for a trip to New Jersey to visit my dad's family for American Thanksgiving. (Yeah, they're my family, too.) We're all looking forward to seeing aunts and uncles and cousins and other extended family, but we're also looking forward to spending our powerful Canadian loonies in the US. The Canadian dollar's gone up and up this last few months, and though it's no longer trading at its ridiculous high of US$1.10 (!), it's still above parity, which means our money stretches pretty well. Coupled with this is the fact that most products here in Canada are still priced as if the loonie were still worth US$0.62. It's not atypical to see a book priced for $7.99 US, $10.99 Canadian. So we're going to do some shopping for clothes, books, music and other goods while we're stateside. I plan on bringing an empty suitcase with me and bringing it back full. (The fact that I've lost a lot of weight makes shopping for clothes particularly enticing.) All within our legal limits for customs returning to Canada, of course! Not to worry, random customs official who's reading this blog for who knows what reason. I'm also looking forward to this trip because we haven't done a driving trip together in a while. Going to Thanksgiving in 2005 was Amita June's second long trip (our overnighter to Ottawa for our anniversary in Oct 2005 was her first), and I think she's going to enjoy it again this time. tags: road trip thanksgiving loonie parity shopping

Painful upgrade I just upgraded my main server, Antipater, from Debian "sarge" to Ubuntu "gutsy". I was getting pretty frustrated by being 3+ versions back from a lot of the important software running on the system. I wanted to get on Ubuntu for my server platform to have more frequent upgrades (about every 6 months). The upgrade went well, mostly. I updated /etc/apt/sources.list to use the Ubuntu archives, then got all the packages. The installation was pretty quick, even for something like 700 packages. However, when I rebooted to use the new 2.6.22 kernel (up from 2.6.8 or so), the server's responsiveness went way down. My guess is that somewhere in the 2.6.x series, one of the new schedulers is causing my particular configuration some grief. I've trimmed my cron jobs and background processes down to a minimum, but the server is still running a little too loaded. The great folks at iWeb have been really helpful, but they don't support Ubuntu, so I've got to brainstorm for myself. I'm going to have to go in over the next few days to reboot the server and experiment with other kernels -- not fun. tags: iweb ubuntu antipater

One-liners Some other odds and ends:

• It's getting cold! We had our first snow flurries a few days ago, and it's been regularly under freezing around here. Time to get winter coats out of the closet -- or, better, buy new ones in the US.
• My friends at Kokoromi are organizing an excellent games+art event called GAMMA 256 on November 28 at the SAT. Should be a lot of fun.
• One such friend, Heather Kelley is going to be talking at the Montreal Geek Girl Dinner on Tuesday. Good for her!

tags: gamma kokoromi weather heatherkelley montrealgirlgeekdinner

On Self-Reflection I have a need to write some things down recently, I don’t really know why or so. I have acquired a few new (and great) friends recently, mostly here in Brno. Also, I have more motivation than ever to try hard to live a good life. It has always been a hard way to follow for me, to be all those things that I find great in other people. How they can handle situations smoothly, what they know and what they can do. And it is great to see such people, and yet it is hard to not envy them. But envy not, since it is a great evil. One never knows what the other people have to go through, and it is just plain unfair to envy them. But I am drifting away from the subject at hand. What I have noticed as well, that I have changed in subtle ways, patterns of thinking. Self-reflection is somewhat cautiously sneaking into my mind. Two independent events have reminded me of that today. Recently, I have been participating in online discussion more than I have used to, especially with people I do not know, and with which I often tend to disagree, and this is putting me in a new kind of situation. And to be honest, I am not really handling it all that well. What has made me think about this was Boudewijn Rempt’s comment on the dot. He handled the task at hand so much better than myself, even if it was his ego that was in the line, that has made me actually stop and think about it. And as I have written in that thread, I admire Boudewijn greatly for that calm reaction, of which I would be almost surely not capable. So here I am, trying to learn from that. My memory is indeed very short, but I also take this writing as a way to train that. The second event was that a friend of mine (I do not know him long, but I call him a friend nevertheless, although I know not whether I actually deserve that) has told us something to the effect that one should learn. Meaning that one should learn from own mistakes, and no, I no more see the empty phrase behind those words. There is something in that, and it is a very interesting experience. Going through situations you have encountered and realize where you have made mistakes and what you could have done better. Actually admit, that even though the outcome was fairly good, that you have made some silly things. It is indeed a very interesting experience, to admit a failure when you are not pressed to by any external means. Liberating, maybe. Same goes for things long forgotten. Where you have made mistakes, even though you have been always righteous and positively convinced about always doing the right things. You may be wondering whether I have been on crack all the time, but, well, that is not the case. I cannot tell how this came about, and yes, I have realized those mistakes and again forgotten them and so on and so forth. But hey, I think it may be better this time. If only a little…

I wonder why Russel doesn't touch on system bus usage in his excellent article. AFAIK there are three main scenarios: SW-RAID, “classical HW-RAID” (RAID controller which is on the system bus as a complete unit, discs behind it) and “Add-On HW-RAID” (RAID controller is a device on the system bus which controls the non-RAID disc controllers which are also on the system bus.) SW-RAID is clearly worse than classical HW-RAID in terms of system bus usage, but I'm not sure how the Add-On HW-RAID chips compare to that - If CPU to memory bandwidth is much higher than memory to bus bandwidth they might be even worse than SW-RAID (RAID 5/6: transfer data to RAID chip for checksumming and from there to the disc controllers compared to checksumming on the CPU which gives higher CPU usage but less bus load.) But this is guesswork, I don't have much experience in this field, so corrections welcome!

Update: problem fixed, thanks for the comments; it was MTU related issues.

Note: This is a long post, but I expect it to bring in some questions for many Linux people; I advise you to read this when you have enough time.


After the last events related to connectivity at home which have been lasting since Thursday evening and the weird fact that it seems that NAT doesn't work at home, but does at work for the same setup, I called the ISP's support and wasted 15 minutes trying to convince them at least to send a technical team with another modem just to test if that is the reason for the breakage.

Of course, talking to the ISP support and trying to convince them that there might be a problem on their side since NAT works with another provider but doesn't with them, was fruitless.

Tonight I was stuck and tried another approach, convinced I would confirm my suspicion that there is something wrong on ISP's side. Still I am not yet sure what to conclude from what happened.


So, to get a better view of what is going on, I'll describe the setup I have and what are its limitations and characteristics. People in a hurry can skip to the paragraph starting with "I tested" and stare in wonder at will.


So the connection I have is done through a DSL modem which gets the MAC of the network card connected to it and exposes that as its own to the ISP's network. This MAC seems to be quite persistent and special measures must be taken in order to be able to use another NIC to connect. The modem (or probably some machine in ISP's; the IP is 10.10.0.1) offers a DHCP address and everything should work fine.

Because of this "your MAC is my MAC" issue, when I connected the first time, I used an USB NIC since a broken router or some temporary failure would have allowed me to use the Internet connection directly from my laptop. I can say this decision has proven in time to be wise.

The router I used until now is a NSLU2 with Debian installed on it. The built in network interface always faced the internal network.

The router (which I call ritter) served as a NAT router for two machines inside the network, my laptop and my apartment mate's laptop. All until last Thursday, after which it never got back properly.



I tested (doing NAT on my laptop; the laptop shouldn't have been affected by the power problems):

• with ritter behind the laptop NAT, at home
  
• with two different virtual machines as NAT "clients", at home
  
• with ritter behind the laptop NAT, at work
• with a virtual machine as NAT client, at home
• directly from the laptop
• NAT made through a SNAT rule
• NAT made through a MASQUERADING rule
• with TTL mangled (increased by one, although is was never in the ballpark of a low TTL)

Of course, I have n-checked that /proc/sys/net/ipv4/ip_forward was set to 1, the tables had policy ACCEPT and there were no extra rules, except the basic NAT-ting stuff, the routes were correctly set on both the clients and the machine doing the NAT.


All I could see is that:

1. the machine doing the NAT was always working fine
2. at work all NAT clients worked fine
   
3. at home any of the NAT "clients" were
1. able to resolve addresses while the DNS server was in ISP territory and another LAN
2. ping the outside world (if ping was available - in D-I is not)
3. hanging when trying to get a http page
4. telnet-ting directly to the port 80 was ok (but I didn't try to "GET / HTTP/1.0")

So after all of this, I was thinking of trying to see if a new client (the laptop of my apartment mate, a Windows XP machine) would work using the connection at home. It didn't work.

Then I thought of trying to do "Internet Connection Sharing" as is called in Windows. Of course, there was some pain to find Windows XP drivers for the ASIX AX88172 network card (remember, the modem needed to see the MAC of that NIC), but I managed to find the proper one.


And, almost sure the NAT wouldn't work for this case either, I configured the new connection as a shared one. I didn't even disabled the firewall, as I was thinking I could take those down gradually.

I wasn't expecting this, not even by pure chance, but my laptop which was a NAT "client" now was able to browse, ping and do whatever was normal through NAT, while the Windows machine was doing the "Connection sharing".

I was utterly flabbergasted. And that was just the beginning.

I was expecting that the problem coincidentally went away, but after a minute I was proven otherwise. It still didn't work with Linux as the NAT-ting machine. I connected back the USB NIC to the Windows machine and I saw the same thing. NAT was just working.


At that point I was to observe an even more shocking fact: the IP that the Windows machine got was different from the one the Linux machine received, in spite of the fact that the network card was the same, so it would have made sense to get the same one. More than that, the IP that the Windows machine got was from an entirely different network, although it was a valid IP belonging to my ISP.

I was thinking that one reason why it works with Windows might be that there could be some TCP protocol twist that is differently implemented in Windows and the equipment from my ISP gets along better with the Windows network stack.


As a way to test that, I am thinking of forcing somehow the IP on the Linux machine to see if anything changes. But before doing that, I felt the urge to post these, maybe some kind soul will shed some light on this issue for me or drop a hint.

Another reason might be different DHCP servers answering, but I don't know how I can see in Windows who offered the lease.


If anyone has any clue why these weird things happen, please drop a line. I would greatly appreciate it. TIA.

My relearned lesson for the day: when Linux networking weirdness occurs in a NAT environment, remember to try MTU clamping.

Thanks to the comments by Justin and Sesse, I was fast-tracked to the core of the problems I have been experiencing since Thursday, MTU issues. What's worse (from my pov) is that I have encountered this issue before with the provider I had in Timi oara, but, since that ISP was using PPPoE and my current ISP in Bucharest doesn't, I never really made the connection. I even had a commented out iptables rule for MTU clamping in my firewall script.

The rule I am talking about looks like this:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $EXT_IF -j TCPMSS --clamp-mss-to-pmtu

or like the one I have been using (seems more logical to me):

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu


Note that this is not a fix, but a workaround and the real problem is over-zealous admins or weird setups[1] which think that banning TCP fragmentation (or the entire ICMP traffic) is a way to secure networks.


Once again, thanks to everybody who read and/or commented about my issue.

[1] Sesse told me that in his case there was a transparent proxy involved when he exeprienced MTU weirdness.

For a while I’ve been trying to find some easy way to keep a few machines I admin behaving the way I want them too with minimal effort. They don’t really need much maintenance – but I would like something to help keep them all in sync. Basically, something like FAI, but much, much simpler – ideally something that takes five minutes to understand, and another five minutes to deploy; and leave the more complicated and powerful tools for when they’re actually needed. I figured what I really want was just a simple way to make a meta-package – one that doesn’t really provide any functionality, just tells apt/dpkg what I want installed (via Depends), and what I don’t want installed (via Conflicts) and adds any extra configuration stuff or local scripts that I decide I want. But doing that with a real Debian package is harder than I’m really comfortable with – I don’t want to have to worry about potential lintian errors, or rules files and debhelper commands, or writing a Makefile to get my files installed or whatever, I want something more trivial than that. Looking for meta-package creators, the only one I spotted that I thought looked likely was cdd-dev, described as “Custom Debian Distributions common files for developing meta packages”. Unfortunately it seems to just provide templates, which makes things quicker, but no less complex. Fortunately equivs (“Circumvent Debian package dependencies”) is actually used for metapackages these days, according to its maintainer on IRC and its long description:

This package provides a tool to create Debian packages that only contain dependency information. One use for this is to create a metapackage: a package whose sole purpose is to declare dependencies and conflicts on other packages so that these will be automatically installed, upgraded, or removed. Another use is to circumvent dependency checking. […]

That turned out to work much better than I remembered (from whenever I last tried it – back in ‘99 I guess?), with the only drawback being that I couldn’t add files easily. But that’s just a matter of creating a patch to equivs, which I then won’t have to worry about again. So having done that, I can now create a metapackage to do whatever I want by creating a file like:

Suite: client
Section: misc
Priority: standard
Package: ajs-client-stuff
Version: 20071114.1
Maintainer: Anthony Towns <aj@erisian.com.au>
Description: Metapackage for aj's client computers
 Depends on necessary packages, etc.
File: /etc/apt/sources.list.d/client.list
 deb http://mirror.localnet/debian etch main contrib non-free
 deb http://mirror.localnet/debian etch-proposed-updates main contrib non-free
 .
 deb http://security.debian.org/ etch/updates main contrib non-free
File: postinst
 #!/bin/sh -e
 .
 apt-key add - <<EOF
 [output of gpg --armour --export $KEY]
 EOF
 .
 ##DEBHELPER##

debhelper kindly takes care of getting the permissions right for me, and equivs will generate a full source package if I tell it to, which I can just upload to mini-dinstall and have a regular Debian repository just by writing a text file and running equivs-build. And my metapackage can add dependencies, conflicts, apt sources, cronjobs, scripts, configuration files, documentation, or whatever I happen to want – which means I can make it automatically update itself, and thus install any dependencies or remove any conflicts, which then means that modifying the config on all the machines is just a matter of updating the metapackage. And new installs is (hopefully) just a matter of doing a standard install and then adding the metapackage. Perfect. …even if it is really little more than a reinvention of rpm’s .spec files. :)

Today, when walking through some Wammu/Gammu bugs, I came to conclusion that the spam changed some people to behave insane. The email field in bug tracker is there to allow developer to contact you, for example when he makes a fix for issue you reported and wants you to test it. Entering addresses as ones at TrashMail which will vanish soon (the bug I'm talking about is two days old, what I feel is good enough reaction time from my side), will not help anybody. Thank you firebird76 (whatever your real name is) for realizing how people are stupid. PS: I use Mantis bug tracker, which I believe does not expose email addresses to anyone besides privileged users.

Kicking ass in an unflat world is The Economist's take on recent efforts in the world of business books. As the creator of Squeezed Books, their opinion was of interest to me. As is often the case, they don't disappoint, with lines like

Things to bear in mind as you do, he says, include the need for your company to have purpose, to seek out ideas from the fringes, and to embrace the democratising power of the internet none of which will be news to anyone who has been in business for more than a few minutes.

What really caught me eye, though, was this:

There is also growing demand from overloaded executives for shorter books. So in January Harvard will launch a new hardback series, Memo to the CEO , covering subjects such as lessons from private equity and the future of strategy. Each book will be about 100 pages long and will cost $20. In a similar vein, Harvard has adopted the approach taken by iTunes to pop albums, and has started to sell individual chapters of books online an idea that has been a hit with academics in particular.

A lot of good business books take a sensible central idea, and then proceed to fluff it up to a length where it can be published as a book. Often, this makes for a good read, as the anecdotes and case studies and whatnot are interesting, but for those in a hurry, or simply wanting to know what the basic point of the book is about, it's just padding. So, it looks as if the idea behind Squeezed Books is a good one, now I just need to get better at attracting more people to contribute summaries, and discuss the books on the site. One thing I've done to that end is stipulate that the summaries are available, unless otherwise noted, under a creative commons license.

Ian Lance Tailor started a discussion that has in the meantime reached Planet Debian via Miry and Giacomo. The single-threaded memory model is the only sane choice for languages that are as close to the "metal" as C and C++ are. For a multi-threaded model to work, the compiler needs to have intrinsic knowledge of "locking", and it needs to emit the appropriate code around all accesses to variables that cannot be accessed atomically (which also means that signal handling does not work — the signal might arrive in a critical section). Java uses such a model. In the language, there is the "synchronized" keyword, which can be used either as a modifier on a method definition (locking the object the method is called on), or before a block (locking an explicitly specified object). The lock is recursive, so calling another "synchronized" method on the same object works fine, leaving the last one finally unlocks the object. Memory consistency is achieved by flushing the object before unlocking (so accessing an object that another thread may use without locking it is still undefined behaviour — but class authors can avoid that by allowing access only through "synchronized" methods). I doubt we want the same in C/C++. For one, it adds a recursive lock to each instance of a class or struct, whether needed or not, since the compiler cannot rule out that some code might want to use this object as a lock. Also, the object inclusion and inheritance rules are quite different, as Java does not have inclusion, and only allows simple inheritance. Basically, if I were to emulate Java's rules, I'd need a "virtual" base class to provide the lock, which is a lot of extra overhead since every derived class now needs to keep the offset to the most derived class. The other two big show stoppers are the "intrinsic" knowledge of locking that the compiler must have (it needs to know how to embed a recursive lock into an object, which is an operating-system dependent structure as it stores some thread identifier for the current holder of the lock) and that it becomes a lot more difficult to write signal handlers, as you need to avoid any code that might implicitly lock some object (which is true already, but there is no implicit locking). Java can do that, as they have a virtual machine that provides locking primitives and object lookup (so they can keep the lock separate). There is a change to the memory model I'd like to see though: the concept of an I/O buffer that behaves like regular memory (so load/store coalescing/reordering is allowed), but will be flushed before volatile accesses and re-read afterwards (optionally, with finer grained control). This would work for both hardware accesses (where the volatile access triggers some hardware) and for "hosted" environments (where the compiler assumes that system calls perform volatile accesses), and still allow most optimisations like writing in the hardware's natural bus width. If you want to write reliable multi-threaded code with current compilers, there are two simple rules:

1. any data structure shared by multiple threads needs to be marked volatile
2. any access to a shared data structure needs to be guarded by a lock

The accesses to the shared data structure are ordered with regard to the locking functions and cannot be optimized out, which is exactly what you want. The appropriate mental model is that anything that is not declared volatile (or handled by a platform locking primitive) cannot be seen by the other threads.

Reading mig21’s weblog, in which I often find really interesting stuff, I found Ian Lance Taylor’s article “Single Threaded Memory Model“, which kind of bothers me a bit. It reports a recent discussion on the gcc and LKML mailing lists about how C compilers, gcc in this case, optimize for single threaded code, sometimes leading to counter-intuitive results which won’t work properly in multi-threaded software (leading, for example, to race conditions). The interesting part is that the C language standard, which in general describes a single threaded model, apparently says nothing about when values have to be written to memory. Thus, this kind of optimization seem to be perfectly valid. Linus Torvalds complains about gcc developers taking more care about “what the spec says” than about real problems, but the fact is that if those kind of optimizations are valid according to the specs, there’s no guarantee at all that it won’t happen with whatever C compiler you might be using. To prevent this kind of behaviour in standard C, according to Ian, the variable needs to be marked as volatile, or it needs to use an explicit memory barrier. The moral in this case is that multithreading might not be as easy as it seems and should be handled with caution.

xen-tools has just got a new command:

xen-resize-guest --hostname=foo.my.flat --increase=5Gb

That will take the existing guest foo.my.flat and magically resize the main disk image to be 5Gb larger. This works for LVM & loopback images, but not yet for users of EVMS. Whilst doing this job manually isn't terribly difficult it can be troublesome to perform all the steps in order without screwing up. Hence the new command. In other news I've managed to fix my broken greylisting implementation - so all the mails which were previously being queued upon klecker.debian.org should now be delivered/bounced. I believe the blame here was 50/50 me and exim's back-off behaviour, but I'll know better in the future. Remember me when you come to choose your next anti-spam service. It copes beautifully with a sustained delivery rate of 300-700 messages a minute when queues suddenly restart delivery ;) TODO: Catchup on mail. Implement message tagging for mutt to better keep track of items which are pending/claimed by me. Until we get RT.

Hmmm, dear LWN, Anthony Towns is not alone when claiming that the reaction of the Debian community towards Nexenta after they announced their work was probably overflated and certainly too much aggressive. I remember having done so already and I did it again later. I usually avoid debian-devel flamewars but here, this is not really a flamewar. This was a rude action against people who may have done mistakes, errors and certainly need to talk deeper with the Debian community. Even if the contributors in this thread do not think they have been rude, I'm pretty much sure they have been "perceived" as being rude by outsiders. I'm afraid that such behaviour is very likely to enforce a very commonly feeling among the free software community of Debian being a kindergarten of free software bigots completely disconnected from real life. We know we are not this so we should try to avoid people thinking we are. This is not why I work in this project. When it comes at Free Software, I'm a kind of "bigot" too, but I usually try to not enforce my bigotry to other people by being uselessly aggressive. This also is a key point for Free Software and we should more often think about it. (don't take the word "bigot" as first degree, please...) We (as a community) have been aggressive with Nexenta about this issue, just like we have been in the past with, say, Ubuntu. So, I wish that we'll sing along with Erast Benson at next Debconf just like some did at Debconf 5 with the Shuttleworth gang. I wish I would see more Debian contributors bringing this feeling in -devel, especially our "historical" contributors, just like Ian Murdock did. Don't be shy, people..:-)

Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas. Here's a random collection of stuff that happened in the last few months. New chipsets:

• AMD K8 / NVIDIA MCP55, contributed by Yinghai Lu of AMD
• VIA VT82C686A/B southbridge, contributed by Corey Osgood
• AMD Geode LX / CS5536, contributed by Marc Jones and Jordan Crouse of AMD
• Intel 810 northbridge, contributed by Corey Osgood
• AMD K8 / VIA K8T890 / VT8237R, contributed by Rudolf Marek / Corey Osgood
• AMD K8 / SiS761GX / SiS966(L), contributed by Morgan Tsai of SiS

New mainboards:

• Sun Ultra40, contributed by Ronald G. Minnich (LinuxBIOS project founder)
• K9SD Master-S2R (MS-9185), contributed by Bingxun Shi of MSI
• K9SD Master Series (MS-9282), contributed by Bingxun Shi of MSI
• GIGABYTE GA-M57SLI-S4, contributed by Yinghai Lu of AMD
• NVIDIA l1_2pvv, contributed by Yinghai Lu of AMD
• Supermicro H8DMR, contributed by Yinghai Lu of AMD
• Tyan S2912, contributed by Yinghai Lu of AMD
• Tyan S1846, contributed by myself
• AMD Norwich (AMD Geode LX reference platform), contributed by Marc Jones and Jordan Crouse of AMD
• IGEL Winnet III thin client, contributed by myself
• ASUS A8N-E, contributed by Phillip Degler
• IEI JUKI-511P, contributed by Nikolay Petukhov
• IEI ROCKY-512, contributed by Nikolay Petukhov
• AMD DB800 (a.k.a. Salsa), contributed by Marc Jones and Jordan Crouse of AMD
• ASUS MEW-VM, contributed by Corey Osgood
• Artec Group DBE61, contributed by Marc Jones and Jordan Crouse of AMD
• PC Engines ALIX.1C, contributed by Ronald G. Minnich
• MSI MS-6178, contributed by myself
• MSI MS-7260 (K9N Neo), contributed by myself
• IGEL-316 thin client, contributed by J rgen Beisert
• AXUS TC320 thin client, contributed by J rgen Beisert
• GIGABYTE GA-2761GXDK (Churchill), contributed by Morgan Tsai of SiS
• And a bunch of older Intel 440BX based boards, contributed by myself with some help by testers via IRC: ASUS P2B/P2B-F/P3B-F, A-Trend ATC-6220, AZZA PT-6IBD, Biostar M6TBA, Compaq Deskpro EN SFF P600, GIGABYTE GA-6BXC
• ASUS A8V-E SE, contributed by Rudolf Marek

Note that not all of these may be 100% supported, some may still be work in progress with some TODO items left... Check the LinuxBIOS wiki or ask on the mailing list for details. The future Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about. Call for board testers If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you. Please contact us on IRC or preferrably on the mailing list if you want to help get your board supported! An (incomplete) list of good candidate boards for future support is available in the wiki. Thanks! We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot! Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!