Just some small thoughts about cyclic lists in Haskell. Every Haskell beginner knows that you can use infinite lists, as long as you don t fully evalute them. So, this is perfectly valid

endless = [0..] -- All natural numbers!
main = print (endless !! 10)

It will not crash, but print "10" as the list has not been fully used.What happens if we take a piece of the list further down, let s say at position 1000000000:

endles = [0..]
main = print (endless !! (10^9) )

If you try this at home, better run "ulimit -S -v 1000000" before, because then you ll get "test: out of memory (requested 1048576 bytes)" instead of a sluggishly swapping machine. What happened? The long list will be evaluated, and fills the memory. Does this mean that we can not use arbitrary long lists? Let s try a special case: A list that is infinitely long, but repeating the same values all over again:

list = "Oh, happy day! Oh, happy day. "
cycle' list = list ++ cycle' list
main = do let rlist = cycle' list
  print ( rlist !! (10^9), rlist !! 0 )

We repeat the (finite) list endlessly, and then try to pick the 1000000000th element. We also pick the first element again, to make sure the compiler does not cheat by forgetting the first 999999999 elements (It s actually pretty nice that the compiler will forget these elements, but not what I want to demonstrate here). Running that code, sure enough, fills up the memory.But maybe I was coding badly. At least I have re-implemented a function that already exists, which is bad practice. Let s try with Haskell s own cycle:

list = "Oh, happy day! Oh, happy day. "
main = do let rlist = cycle list
  print ( rlist !! (10^9), rlist !! 0 )

Now it takes a while, but surprisingly, the memory gauge does not skyrocket, and in the end I m told that the 1000000000th character in my infinite character string is 'd'. This leads me to the conclusion that the Haskell library uses black magic. Or does it? Here is the definition of cycle:

cycle xs = xs' where xs' = xs ++ xs'

What is the difference to our cycle'? Here, the result is given a name (xs'), which is used again inside the function. So while our cycle' appends the list over and over again, filling up the RAM, their cycle ties a loop and makes the end of the list refer to it s beginning. And my list lookup will no longer evaluate the list up to infinity, but just run around in, well, cycles until it has counted down from 1000000000. I could even ask for the last element of this list, and it will not use any more RAM than a small, finite list, while endlessly searching for the end of the list.Despite Haskell being a very high level language, I sometimes wonder how my data will look like on the physical memory. And as you can see, it can make a difference. Some more thoughts on this were written down by Duncan Coutts.

Christmas came early for me this year: after receiving a Conceptronic CH3SNAS yesterday, a QNAP TS-409U showed up today. QNAP sent it to me a week ago to ensure that Debian works on it but it was stuck in customs for a few days. The QNAP TS-409U is similar to the TS-409 but comes in a rack case (and with more RAM). It seems that QNAP have also changed the layout of the mainboard but essentially it's still a TS-409. This means that the installer works just fine. Another difference to the TS-409 is that the TS-409U has two fans but qcontrol works without any problems on both machines.

We re all aware of the financial crisis due to credit default swaps shaking up the markets, media, politics, and what not. Some of us are feeling the pain, most of us aren t yet. A few days ago, politicians of the big, capitalist nations convened to agree on a way forward to stablise the financial market and set an end to the crisis. They are planning on doing this by throwing hundreds of billions at the market, buying all the subprime loan packages with the intention to create a new market for them, thus taking the weight off the shoulders of the countless barely-surviving banks and investors, who have written off billions in losses without an end in sight. Where does this money come from? Taxes and newly printed money. You may not yet feel the effects of this, but you will: taxes will rise, and inflation soar to even higher levels. Today is Blog Action Day with poverty as the focus, and it s a good occasion for me to state what s long been on my mind. The strategy by our political leaders to combat the credit crunch is short-sighted, and it fights symptoms, not causes. In fact, it s Robin Hood played in reverse: tax increases and inflation will hurt those most who cannot do anything against it: the poor. On the other side of things, those active in the financial markets will have their damages limited, and new CDS markets might even create more opportunities for those who can. I strongly oppose the way our politicians are handling the issue, even though I do have small amounts of funds invested in financial products myself, and have already seen the positive effects of their actions. Rather than throwing money at the markets, we really ought to put those away who have caused all this, those ruthless, greedy ones who have speculated way over their heads, underestimated the risks, and caused this crisis that killed many businesses, threatens to endanger entire countries, and hurts individuals who hardly ever had a choice. Think of it as a driver s licence, and that should be revoked for those who screwed up so royally bad and got us into this situation in the first place. Don t let them speculate again! Update: Andreas Metzeler notes that he is (rightfully) missing a what is to be done instead section in my blog post. I don t have anything to offer on that front, sadly. I also realise I should have phrased my opposition differently. Reading this interesting interview with Deutsche Bank ex-CEO Hilmar Kopper (German only) (thanks, Andreas!) helped me understand more that the politicians aren t saving banks, they are saving the system, and that they have little other choice. Another aspect I haven t previously seen as clearly as now is that the governments are purchasing (and willing to carry) risk for others, to relieve the markets. Risk by itself doesn t cost anything, so it might turn out that the billions they made available won t actually be spent though I always new that the governments might well come out of this with a profit even. The whole affair still stinks, and what I truly miss are the actions to prevent those responsible for getting us into this mess in the first place from doing so again. NP: This Will Destroy You: Young Mountain

My wife has a laptop running Vista because she wanted to try out the operating system before having to decide on using it at work.

I called her various names because of it, but that didn't help :-).

So we have this setup with an SMC wireless router/AP talking to a Cisco 837 router that does the internet part. Upstairs we have a 'server' that is connected via Powerline IP-over-power, downstairs we have the Dreambox that is connected via a normal Cat5 connection.

In the last few days my wife complained that it was very slow to download media from Frost. Working at TAC having a network problem at home is almost a personal offence :-) so I decide to take a look and I find using iperf the following speeds:

frost (debian) --cat5--> sharrow (debian): 35 Mbit/sec
frost (debian) ---WL-cat5-> sharrow (debian): 18 Mbit/sec
sharrow (debian) ---WL-cat5-> frost (debian): 18 Mbit/sec
sharrow (debian) --cat5---> frost (debian): 35 Mbit/sec
frost (debian) ---WL---> martha-jones (vista): 0.2 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 12 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 6 Mbit/sec
martha-jones (vista) --WL-cat5-> frost (debian): 18 Mbit/sec
martha-jones (vista) --WL--> sharrow (debian): 18 Mbit/sec
martha-jones (vista) --WL-cat5-> sharrow (debian): 18 Mbit/sec

This made no sense at all. The speed halved going from a WL->WL to a WL->cat5 connection but only in one direction!

So having isolated the problem to the Vista machine I started looking round and I found a note saying that running netsh interface tcp set global autotuninglevel=disabled in an 'Administrator' cmd window will fix the problem.

Now I'm very weary of changing the TCP/IP options of the operating system. In most cases the 'tips' you see flying round the internet have no meaning at all and sometimes make the situation worse rather then better.

However I did find this on a Microsoft Technet site.... Hmm

So in the end I try it and modify the setting, disconnect and reconnect to the wireless and:

frost (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 18 Mbit/sec

Aah, finally I could tune Vista so that it has the same speed as an untuned Debian machine. I only took me 2 evenings worth of work...

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea... In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state
[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts
[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state
[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode
[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

In my previous post I drafted a rough idea how to add a feature to Debian that would bridge the gap between Debian as a Binary Distribution and any Source Distribution. The feature in question is giving users the chance to build customized Debian packages for specific feature sets. The possible use cases are simple:

Lets say Anthony User needs super-duper-tool with postgresql support. However this is a not so common use case and so the archive only has postgresql support. If he now wants to build a custom package, the process is "as simple" as:

apt-get source super-duper-tool
cd super-duper-tool-*
apt-get build-dep super-duper-tool OR sudo mk-build-deps -r -i
(possibly try out which ./configure options are supported by super-duper-tool)
vi debian/rules
edit debian/rules
dpkg-buildpackage -us -uc
sudo debi

That is, to be honest lot of work. And the biggest problem about it is that you need to know all this, which is not really user knowledge.

The basic idea is that Anthony can do something like
export DEB_BUILD_OPTIONS=nomysql,postgresql
deb-build-tool build super-duper-tool

and is done.
So the question is how could this be achieved?

1. Define a set of common options (options should be consistent through all source packages, otherwise it makes not that much sense) that every package should support, if it is a supported feature by the package in question. This includes flags like mysql, postgresql, ldap and its no-equivalents (nomysql, nopostgresql) to negate it.
2. Enable use of this common options in the package build process and that is really the hardest part. Defining a lot of ifneq..findstring constructs for 2-10 options per source package in any available source package is.... not.... a good approach. Luckily a lot of packages uses autoconf where enabling and disabling features is as easy as adding a --with-foo or --enable-foo option to the ./configure parameters. So we could write a wrapper that would handle these options. The debhelper scripts already have dh_auto_configure: Maybe this could get enhanced.
3. If it does not exist: Write a tool to auto-build packages with DEB_BUILD_OPTIONS set by the user. Should automatically get the source, (optional: setup/update a pbuilder environment) and build it and optional install/upload it (to a user repository for example) .
   

Still, the idea is only a rough draft. There are still a lot of open questions/issues, for example:

• How to handle these feature flags in packages that don't use autoconf
• How to enable these feature flags for packages that don't use debhelpers
• Shall a central place for setting DEB_BUILD_OPTIONS exist (like it does for Gentoo, FreeBSD etc.) and if so: Where?
• How should packages define new build options, if those defined Debian-wide, aren't enough?
• What about support? Do we support such custom builds of packages or will this be a support-on-good-will thing

Is anybody interested in pushing this idea forward? I'm happily interested in it and I know people who like the idea, too. But I can't push this forward on my own all alone. Certainly the work won't affect Lenny anymore, but considerable the time frame that is planned for Lenny+1 by the release team, this could be a feature for Lenny+1.

Yesterday I attended a lecture by professor D.J. Bernstein, best known for his products like qmail, owner of one of the coolest domain names in the world and for his often controversial but always interesting visions. His talk focused on why the majority of internet traffic still is not encrypted. We protect our email passwords but the 95% of other things we do is completely unprotected from a sniffer. He then narrowed it down to DNS. The problems with DNSSEC are evident and it's still a question of whether it will ever be implemented (after 15 years the design is still in flux, let alone that it's properly implemented or actually used). On a more constructive side he presented his own solution: DNSCurve: using elliptic curve cryptography to not only sign but also encrypt DNS traffic, and do so on the fly rather than the cumbersome precomputation approach of DNSSEC. Bernstein shows that the extra cost of on the fly cryptography is, even for root servers, very minor compared to the costs of the entire system, but it does significantly reduce the administrative burden compared to DNSSEC. As usual he has made an interesting case, a worthwhile read.

Today, as I was riding my bicycle home from work, I noticed that the road maintainer had been by on the dirt and sand roads near our house. Unfortunately for me, he left a few sections of road with deep sand, and I almost wiped out several times. I ride a bike with narrow road tires that doesn't deal well with that.

But I'm not the first one to have a problem with roads.

A hundred years ago, the "brethren to the south" were having trouble getting to the community's main church, Alexanderwohl. Back in the days before paved roads, or heavy road-maintaining machinery, it took time and endurance to travel the distance even on good roads. A group of them started holding weekly Sunday Schools in local schoolhouses. Eventually, after much discussion, they decided to build a church, and it was completed in 1908 -- Tabor Mennonite, more than 4 miles from Alexanderwohl!

Tabor thrived over the years, though not without difficulty. Everything from how to shelter members' horses during services to what do to about the weighty social and political issues of the day were discussed and documented in church minutes. The church sent people out as missionaries, planted new churches, and supported several young pastors just starting out. In 1938, they expanded their building, and in 1965, replaced it entirely.

Tonight our weekend of centennial festivities began. It started with a prelude played on the church's first organ -- now about 90 years old if memory serves. Its current owner was tracked down, it was brought to the church, and still sounds wonderful. Tomorrow we will have music and activities outdoors under a tent, and all our living former pastors will be around, with a drama and meal in the evening. Then on Sunday, the big day with singing choirs (and a work commissioned for this occasion), each former pastor giving a short (we hope) message, a potluck (of course!), and the opening of the cornerstone.

It's been 6 years in the planning. I've spent the last couple of years collecting photos and other material for the archives and for the coffee table-style book we published for the centennial, and others have put in lots of hours too.

Sunday's worship service will conclude with singing the "Mennonite Anthem", also known as "606" from its number in an old hymnal. It will be a capella as is tradition for this piece. (Click for MP3 of a small choir singing it) It will be loud and beautiful, hundreds of voices joining in, a fitting way to mark this occasion.

What a wonderful thing we have been left by those that came before. And still, a responsibility for us as we look to the future. Rural churches are disappearing, and while Tabor is the rare rural church that is growing, still we hope that its location at the corner of two mostly dirt roads 4 miles from the nearest town (population 600) will not get in the way in years to come.

At the end of the events tonight, we were reminded of the favorite Bible verse of Rev. P. H. Richert, first pastor of Tabor, who served as pastor for almost 40 years:

the mountain of the LORD's temple will be established as chief among the mountains; it will be raised above the hills, and all nations will stream to it.

(Isaiah 2:2)

Somehow it seems improbable that dirt roads led to all this.

I’ve updated my package of the Amazon EC2 API Tools for Debian [1]. Now it uses the Sun JDK. Kaffe doesn’t work due to not supporting annotations, I haven’t filed a bug because Kaffe is known to be incomplete. OpenJDK doesn’t work - apparently because it doesn’t include trusted root certificates (see Debian bug #501643) [2]. GCJ doesn’t work, not sure why so I filed Debian bug #501743 [3]. I don’t think that Java is an ideal language choice for utility programs. It seems that Perl might be a better option as it’s supported everywhere and has always been free (the Sun JVM has only just started to become free). The lack of freeness of Java results in a lower quality, and in this case several hours of my time wasted.

• [1] http://www.coker.com.au/ec2/


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501643


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501743

Share This

Ran into a freakish epiphany/gmail bug yesterday where gmails's "new" interface somehow ate the 's' key, preventing it from working in epiphany at all. Even after logging out of gmail. If any readers of this blog have contacts inside the gmail team, I've filed bug #501691 on epiphany with details about this scary situation. Personally, a web that can eat 's' keys is not the web I want.

Anand Kumria wrote:

If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?

I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company. Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank. However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. - over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen. All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place. In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates - it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.

You probably noticed by now, that Debian GNU/Linux 5.0 aka Lenny hasn't been released in September. Well, that's a shame, but very easy to explain: Too many release critical bugs. Well, it's pretty hard to estimate, how fast RC bugs will be fixed, and apparently our release team was a bit too optimistic :( The big question is: What can you do, to help release Lenny at least in this quarter? That's pretty easy: Fix rc-bugs, take care, that the fixed packages are migrated to Lenny, do upgrade tests, document problems in the release-notes. Pretty simple, isn't it? For users Even as a simple user (aren't we all just users?) you may help getting Lenny released. Some things you can do:

• If you are running stable (aka Etch), you could consider upgrading to Lenny and see, if everything works fine. Currently there are no detailed release notes documenting the procedure, so you best way to test upgrades are to:
  1. Make backups
  2. Change your /etc/apt/sources.list
  3. Run aptitude update to get information about new packages
  4. Run aptitude install dpkg aptitude apt script to install the newest package management
  5. Run script aptitude full-upgrade
  6. Exit the environment of the script command, by typing exit
  If something goes wrong / something unexpected happens, please report it. If you already know a specific package, report a bug against that package. If you don't know, please report a bug describing the problem you experienced to the upgrade-reports package. If your problem is something, which can't be fixed properly, but should be documented (e.g. hardware support regressions, packages no longer available) please report a bug against the release-notes package (Bonus points if you not only report the bug, but also supply a paragraph to be added to the release notes).
  The command script will log the entire output of the command in the file typescript. Should something go wrong during the upgrade, please send this file along with your bug report.
  Update: If you upgraded succesfully, you should report that, too. There's a template for upgrade reports, which you can use.
• Speaking of the release notes: You can take a look at the bugs reported against the release notes and see if you can help there, e.g. by writing a paragraph describing a problem.
• Install the package devscripts (you'll need the version provided by backports.org, and run the script rc-alert --include-dists TU --include-dist-op and. You'll get a list of release critical bugs open for one of the packages you have installed. Guessing that you have them installed, because you are using them and are interested in them, you should have a very high interest to get these bugs fixed :)
  You can try to help, by trying to reproduce them and reporting that to the bug report. There are even some easy bugs, where the maintainer hasn't found the time to fix it, yet. Bug 497290 for example didn't need deep technical skills. It just needed someone with some time to collect the needed data for the copyright file.
• If you speak a language other than English, you might consider joining the translation efforts. While it is to late to translate the debian-installer or the installation guide to a new language for Lenny (perhaps for the next release then?), you could start translating the release notes to a not yet supported language. If you are willing to do so (which can be quite time consuming, especially in the final phase), please contact either your localization team or the debian doc mailing list if there's no local mailing list.

See? Even as a simple user without deeper technical knowledge you can help us getting Lenny in shape to be released. If you have technical knowledge: Very good! You might want to read the next section, too, and see what applies to you, there :) For maintainers It basically boils down to two things: If your packages have RC bugs open in Lenny fix them and take care, that the fix will propagate to Lenny. If your packages don't have RC bugs open, fix someone else's RC bug. Surely you don't think, the release team will fix the remaining rc bugs, do you? And surely you understand, that your shiny rc bug free packages are kind of useless, if they aren't released? To search for bugs to be fixed, take a look at the unofficial rc bugs thingy. The URL lists RC bugs open in both Sid and Lenny. Obviously they should be fixed ASAP. If no one takes care about these packages, they might be removed from Lenny (if possible). Again: Try to reproduce the bug, try fix it, upload an NMU (or send your patch to the bug report and search for an sponsor). You'll notice, that some of these bugs already have a patch. In that case, your job would be to test the patch, report that to the bug report and offer to sponsor an NMU. Another interesting list is the list of rc bugs open only in Lenny. These bugs have been fixed, but the fix hasn't propagated to Lenny, yet. Normally, the release team will grant freeze exceptions for these packages if possible. However, if the changes to the fixed version are quite grave or the package in Sid depends on a newer package than in Lenny that's not possible. In these cases look out for packages marked as need tpu upload or similar. Oh, and if you could refrain from upload new upstream versions of packages to Sid, you would make all our lives easier. Some reasons:

• New packages won't reach Lenny anyway.
• Upload new packages to Sid makes it harder to get a fix into Lenny should a new bug be found.
• Uploading a new package makes it harder for other packages depending on your package to be migrated to Lenny.
• You are wasting the buildd's time.

And of course you should spend your time fixing rc bugs anyway ;) Update: Rhonda pointed out, that running rc-alert -d TU -o and will limit the output to bugs open in both Sid and Lenny, which is the more interesting list of bugs.

It’s really funny to see how popular things can get, and then totally disappear. Some time ago, there was a TV show on the french TV called “Un an de +”, that talked about what was in the news one year before. It was really interesting to see how quickly everybody can forget stuff that looks so important now. For example, who remembers Second Life? Apparently, it has been on the decline for some time already, according to Google Trends:
Will Facebook be the next Second Life?

A recent news item is the “hacking” of the Yahoo mailbox used by Sarah Palin (the Republican VP candidate) [1]. It seems most likely that it was a simple social-engineering attack on the password reset process of Yahoo (although we are unlikely to learn the details unless the case comes to trial). The email address in question had been used for some time to avoid government data-retention legislation but had only been “hacked” after she was listed as the VP candidate. The reason of course is that most people don’t care much about who is the governor of one of the least populous US states. Remote attack on a mailbox (which is what we presume happened) is only one possible problem. Another of course is that of the integrity of the staff at the ISP. While I know nothing about what happens inside Yahoo, I have observed instances of unethical actions by employees at some ISPs where I have previously worked, I have no doubt that such people would have read the email of a VP candidate without any thought if they had sufficient access to do so. If an ISP stores unencrypted passwords then the way things usually work is that the helpdesk people are granted read access to the password data so that they can login to customer accounts to reproduce problems - this is a benefit for the customers in terms of convenience. But that also means that they can read the email of any customer at any time. I believe that my account on Gmail (the only webmail service I use) is relatively safe. I’m sure that there are a huge number of people who are more important than me who use Gmail. But if I was ever considered to have a reasonable chance of becoming Prime Minister then I would avoid using a Gmail account as a precaution. There is a rumoured Chinese proverb and curse in three parts:
May you live in interesting times
May you come to the attention of those in authority
May you find what you are looking for [2] In terms of your email, everyone who has root access to the machine which stores it (which includes employees of the companies that provide warranty service to all the hardware in the server room) and every help-desk person who can login to your account to diagnose problems is in a position of authority. Being merely one of thousands of customers (or millions of customers for a larger service) is a measure of safety. As for the “interesting times” issue, the Republican party is trying to keep the issue focussed on the wars instead of on the economy. The problem with basing a campaign on wars is that many people will come to the conclusion that the election is not about people merely losing some money, but people dying. This could be sufficient to convince people that the right thing to do is not to abide by the usual standards for ethical behavior when dealing with private data, but to instead try and find something that can be used to affect the result of an election. Mail that is not encrypted (most mail isn’t) and which is not transferred with TLS (so few mail servers support TLS that it hardly seems worth the effort of implementing it) can be intercepted at many locations (the sending system and routers are two options). But the receiving system is the easiest location. A big advantage for a hostile party in getting mail from the receiving system is that it can be polled quickly (an external attacker could use an open wireless access-point and move on long before anyone could catch them) and that if it is polled from inside the company that runs the mail server there is almost never any useful audit trail (if a sysadmin logs in to a server 10 times a day for real work reasons, and 11th login to copy some files will not be noticed). One of the problems with leaks of secret data is that it is often impossible to know whether they have happened. While there is public evidence of one attack on Sarah Palin’s Yahoo account, there is no evidence that it was the first attack. If someone had obtained the password (through an insider in Yahoo, or through a compromised client machine) then they could have been copying all the mail for months without being noticed. It seems to me that your choice of ISP needs to be partly determined by how many hostile parties will want to access your mail and what resources they may be prepared to devote to it. For a significant political candidate using a government email address seems like the best option, with the alternative being to use a server owned and run by the political party in question, if you can have the staff fired for leaking your mail then your email will be a lot safer!

• [1] http://gawker.com/5051193/sarah-palins-personal-email-account-hacked


• [2] http://en.wikipedia.org/wiki/May_you_live_in_interesting_times

Share This

One ongoing problem with TCP networking is the combination of RPC services and port based services on the same host. If you have an RPC service that uses a port less than 1024 then typically it will start at 1023 and try lower ports until it finds one that works. A problem that I have had in the past is that an RPC service used port 631 and I then couldn’t start CUPS (which uses that port). A similar problem can arise in a more insidious manner if you have strange networking devices such as a BMC [1] which uses the same IP address as the host and just snarfs connections for itself (as documented by pantz.org [2]), this means that according to the OS the port in question is not in use, but connections to that port will go to the hardware BMC and the OS won’t see them. Another solution is to give a SE Linux security context to the port which prevents the RPC service from binding to it. RPC applications seem to be happy to make as many bind attempts as necessary to get an available port (thousands of attempts if necessary) so reserving a few ports is not going to cause any problems. As far as I recall my problems with CUPS and RPC services was a motivating factor in some of my early work on writing SE Linux policy to restrict port access. Of course the best thing to do is to assign IP addresses for IPMI that are different from the OS IP addresses. This is easy to do and merely requires an extra IP address for each port. As a typical server will have two Ethernet ports on the baseboard (one for the front-end network and one for the private network) that means an extra two IP addresses (you want to use both interfaces for redundancy in case the problem which cripples a server is related to one of the Ethernet ports). But for people who don’t have spare IP addresses, SE Linux port labeling could really help.

• [1] http://en.wikipedia.org/wiki/Baseboard_management_controller


• [2] http://www.pantz.org/hardware/ipmi/ipmiconflictwithrpc.html

Share This

Today an discussion rised up in #debian-devel on the OFTC IRC Network. It started because someone noted the bug report #501318 which is, to summarize it, just a user mistake, because someone obviously read the man page (time(1)) for the /usr/bin/time command, while time is also a shell builtin (which does not accept the same arguments as the time command. Certainly this bug reports appears to be funny at the first sight, but on the other hand, there is a suboptimal situation that leads to this.

1. There are some builtin commands that also have binary equivalents (like time, printf, echo). Its quiet easy to tell weither the one or the other is used, by using the which command, but thats not really a realistic workflow, so its better to know this. The difference between these commands is often causing problems, which we have to cope with. For example bashs builtin echo behaves different as /bin/echo and people who use the bash as their default shell tend to use what bash provides, which in turn causes problems if other people who use a different default shell try to work with these scripts. But this is another problem, because...
   
2. ... every program, utility and function in Debian has to provide a manpage, as said by our policy: "Each program, utility, and function should have an associated manual page included in the same package." I guess that the rationale behind that is that 'man' is a very common tool in the Un*x world, which is wide-spread and which usage is much recommended to find out how specific tools behave. It is always referred to in Documentation, weither it is Debian specific or not, e.g. in books.
   
   The time package, which is of priority Standard and which includes /usr/bin/time, does conform to that policy by providing a manpage for the time command. The various shells don't do that, because they usually don't have a man page for each and every command (usually they have a more generic manpage which includes the builtins or in some seldom cases a special manpage for such and similar things (as for zsh, which has zshmisc(1)) and because its not that easy, because the man command cannot (AFAIK) distinguish between the user joey_average calling 'man time' in a bash, while the user schoenfeld calls the command 'man time' in a zsh, or if joey_foobar calls 'man read' in a shell which does not have a builtin time command and uses /usr/bin/time instead.
   

So whats wrong about this situation? Would you say that users that expect 'man time' (or similar examples) to do the right thing are making wrong assumptions? I disagree. Its what they've always been told to do. And if it does not show anything eventually run info, or look at HTML documentation or what else. But they haven't been prepared for the case where the manpages does show something, something wrong. The good thing is that the manpage for time includes a sentence:

"Users of the bash shell need to use an explicit path in order to run the external time command and not the shell builtin variant."

The bad thing about it is, that it is at approx. 70-80% of the manpage.

Clint, the maintainer of zsh, mentioned run-help which seems to be a part of the zsh, but not of any other shell, and does more or less the right thing (at least for the builtins) but not for external commands and not even for itself (it opens the code of the function instead of something user-readable like a manpage). I guess "one tool for a specific need" is a good maxime, but is it really a good maxime for finding documentation?

But how could the situation be bettered? I could think of a wrapper for man, similar to run-help but as a more generic solution. Any ideas for it? Is it the right way at all to better the users experience? Any other ideas? Other opinions?

Matthew Yglesias demonstrates innumeracy in action:

We got an interesting experiment this weekend as Bill Maher’s anti-religious screed Religulous and David Zucker’s right-wing satire An American Carol both opened. The two films were about tied in terms of total revenue but Carol was on three times as many screens, so basically Religulous was far more successful. I think this mostly reflects something I wrote about a couple of years ago — the moviegoing audience is very demographically similar to the Democratic Party voting audience. It’s disproportionately young, disproportionately childless, and tilted toward residents of big cities and away from residents of rural communities. Conversely, the audience for television news is demographically very conservative (older, white, and a bit more prosperous than average) which is one major reason TV news coverage tilts right. The big screen audience for what looks like a witless screed against God is just a lot bigger than the big screen audience for what looks like a witless screed against Michael Moore.

Actually, since total revenue for both movies was about the same, it would appear that the “big screen audience” for crappy polemical Bill Maher movies is about the same as the “big screen audience” for crappy polemical David Zucker movies. Further, since I’d guess Carol probably played in theaters with lower ticket prices on average than Religulous, the former probably did a little better in terms of the total audience. Yglesias also makes the rather faulty assumption that the per-screen average revenue would remain flat as screens increased. This result only obtains if moviegoers don’t select theaters based on what movies are playing at them or if screens are very distant from each other geographically; while surely there are some people who just go to the movies to see something without deciding beforehand which movie to see, I doubt there are enough of these people to ensure Maher’s movie would gain a substantially larger audience, except in the relatively uncommon cases where the film just isn’t on at any theater in a metropolitan area and there is a substantial number of people who want to see it. Besides, all the discerning moviegoers were at Nick and Norah’s Infinite Playlist this weekend anyway.

One thing I am known to do is complain how the public/academic discourse surrounding/around technology/computers is overwhelmingly male (Lessig, Benkler, Zittrain, Shirky and I can go on and on). But one day I realized that if I am bothered by it, I should do more than talk the (often) empty talk of complaint. So I decided to enroll in a day long training for writing OpEds, which kicks off tomorrow. I am not sure if engaging in public debate is what I want to do, mostly because of piling more work and time commitments on a very full plate but I am starting to explore what it means and what it may take to leave the Ivory Tower. Here is a little more info about the OpEd Project:

The OpEd Project - featured by The New York Times, Feministing.com and Katie Couric on CBS News - is an initiative to expand public debate, with an immediate focus on targeting and training women experts across the nation to project their voices on the op-ed pages of major newspapers, online sites and other key forums of public discourse. The lack of diversity on the op-ed pages - which are a source for all other media - deprives the public of robust, democratic debate, especially important in this space which is intended to showcase divergent opinions. It also means we are only hearing from a tiny sliver of the nation’s best thinkers. Imagine a baseball team of only pitchers - how well would it do?

While incorporating some of the podlators fixes into the Perl that will be released with lenny, Niko Tyni found more problems with the current implementation. I'd written the test suite to force the output encoding on the file handle used by Pod::Man and Pod::Text, but pod2man and pod2text weren't doing that, and hence the output wasn't properly encoded. I'm finding Perl's Unicode support very tricky, particularly if I want to support the PERL_UNICODE option that adds input and output encodings on all file handles. I can't use encode before output because PERL_UNICODE encoding layers will then double-encode. The approach taken in this release is to force the appropriate output encoding on the output file handle (possibly destroying caller state). This works, but it's ugly. Pod::Text had another problem. Its historic behavior is to copy the input encoding to the output, but doing that with properly-tagged UTF-8 POD input means printing out wide characters in the internal encoding, resulting in Perl warnings. This version now, in the absence of the utf8 option, forces the output encoding to match the input encoding if possible. This seems like the best compromise and matches its historic behavior. pod2text now supports a --utf8 option since it's now useful to force a different output encoding. I wanted to get something out to stop the bleeding, but there are a few problems with the current approach. As mentioned above, I'm forcing file handle encoding layers, which may destroy encoding layers created by the caller that were intentional. This implementation also depends on PerlIO support, which is an optional Perl feature and not always enabled. I think the right long-term approach is to probe for PerlIO support, and if present, use it to check the encoding layer on the output file handle. If PerlIO is not set, or if no encoding layer is present, I can safely use encode before output, which doesn't mess with the file handle state and is much cleaner. If PerlIO is present and an output encoding is set, just trust that output encoding (although if the utf8 option is set and the output encoding is something else, it may be a good idea to throw a warning). I'm not sure when I'll have time to implement this, though, since it will require another reworking of the code and more testing, and I'm behind on a number of other projects. In any event, the current version will work for most people in most cases. You can get it from the podlators distribution page.