Search Results: "reg"

15 October 2007

Russell Coker: Blog Copyright Infringement

I have previously written about some of my efforts to counter sploggers [1]. Since then I have had a particularly brazen splogger copy one of my posts entirely and claim to have written it. The only reason I noticed the copyright violation (my blog license is on my About Page [2]) was because the post in question linked to other posts of mine and I saw the links. I was offended by the flagrant violation of all aspects of copyright law (breaking the license and infringing my moral rights by not attributing me as the author) and by the fact that the splog in question was hosted by Dreamhost (who have offended me by refusing a DMCA take-down request). So I decided that merely issuing a DMCA take-down was not enough. I went through the splog and identified content copied from several major journals (including by a journalist I regard as a friend) as well as by one multi-national corporation - and I notified all the relevant people. The splog in question deleted all it’s old content the next day, and immediately started copying new articles from other blogs. I have informed the people who appear to be copyright holders for some of the new articles… I recommend that other people who deal with sploggers also go to the extra effort of notifying other victims. It’s usually quite easy to do you just select a random bit of text from the copied article and paste it into your favourite search engine - usually you get only a single result. Some of the splog posts are edited in small ways so the first search may fail - if so then you merely need to search for a second piece of text. If you only request that your own illegally copied material be taken down then the splogger still has a good business model. They can keep copying content in violation of the license, occasionally take a post down when they get caught, and both the splogger and the ISP continue to make money. If you notify other victims (many of which won’t have the skills to find the content themselves or the background knowledge sufficient to recognise the benefits in having it removed unless you explain it to them) then the splogger loses a lot of content at one go and the ISP will have a more difficult time claiming to be innocent of the process. Also when you notify multi-national corporations you can expect that they have some decent lawyers and a budget assigned to such work. While I would be extremely unlikely to sue an ISP that repeatedly hosts unauthorised copies of my copyright materiel the same can’t be said for a corporation. For more information on splogging see the Wikipedia entry [3].

MJ Ray: Mr Slef Goes to Westminster

This coming Thursday I will be at the Parliament and the Internet conference at Westminster. It will discuss topics including: What messages on these or other hot topics would you like to send to our lawmakers? I think I'm most likely to attend the *'d sessions, but I should have friends in others and there's often time to bend ears informally too. Discuss it on-list, off-list, in forums I read, on my web site's comments form - just let me know by Wednesday lunchtime, please.

14 October 2007

Martin F. Krafft: Converting a package to Git

Previously, I demonstrated a Debian packaging workflow using Git and I mentioned the possibility of a follow-up post; well, here it is: you want to use my workflow (or one that's related) for a package that is currently maintained with Subversion on svn.debian.org and you'd like to keep the history during the conversion. Make sure to read the previous post before this one. I am again using the example of mdadm since its Git packaging repository is in a state of shambles and I want to restart to get it right and import the history from the previous Subversion repository. What better way than to write a blog post as I do so? Well, plenty actually. This kind of post isn't really made for a blog, and I have started work on setting up ikiwiki on madduck.net, but it's not yet ready, so I'll stick with the blog for now. I will make sure that links don't break as I move content over, so feel free to bookmark this
Importing the package into Git Thanks to git-svn, the initial step of getting your package imported into Git is a breeze:
$ git-svn clone --stdlayout --no-metadata \
    svn+ssh://svn.debian.org/svn/pkg-mdadm/mdadm mdadm
Sit back and enjoy. If that command exits prematurely with an error such as the following:
Malformed network data: Malformed network data at /usr/local/bin/git-svn line 1029
then you should upgrade to a newer Git version, or have a look here. If your Git does not know --stdlayout then upgrade as well (or use -T trunk -t tags -b branches instead). Sam Vilain notes that it is important to "get the attribution right with the final SVN import - getting the authors map right. I didn't do that. If you look at the repository resulting from the above command, you'll notice strange commit authors, such as madduck@some-unique-uuid-from-svn . git-svn allows you to map these to real names with real email addresses, which ensures that the attributions are good for the whole world to see. When done, switch to the repository and run git-branch -r. As you'll see, git-svn imported all SVN branches and tags as remote branches. You need those if you want to bidirectionally track the Subversion repository, but we are converting, as you may have guessed by the --no-metadata switch above. Therefore, we resort to the Dinosaur method of converting branches to tags, which I'll simplify for mdadm. We also just delete all remote branches after tagging, since mdadm never used branches in the SVN repository. Your mileage may vary.
git branch -r   sed -rne 's, *tags/([^@]+)$,\1,p'   while read tag; do
  echo "git tag debian/$tag tags/$ tag ^; git branch -r -d tags/$tag"
done
git branch -r   while read tag; do
  echo "git branch -r -d $tag"
done
If that seems to work alright, then you can execute the commands. Sam Vilain (again) hints me at git-pack-refs and then to edit .git/packed-refs with an editor. This certainly leaves more room for errors but might be significantly faster.
Cleaning up the SVN references Even though we passed --no-metadata to git-svn, it did leave some traces in .git/, which we can now safely remove:
$ git config --remove-section svn-remote.svn
$ rm -r .git/svn
Setting things straight You can skip this section unless you want to know a bit about how to fix up stuff with Git. There was actually some nasty tagging errors leading up to the 2.5.6-9 release for etch and I could never be bothered to fix those in SVN, but now I can (I love Git!):
$ git tag -d debian/2.5.6-10            # never existed
$ git tag -f debian/2.5.6-8 2.5.6-8~2   # mistagged
$ git checkout -b maint/etch 2.5.6-8    # this is when we diverged
$ git apply < /tmp/mdadm-2.5.6-8..2.5.6-9.diff
$ git add debian/po/gl.po debian/po/pt.po debian/changelog
$ git commit -s
$ git tag debian/2.5.6-9
Now that that's fixed, there is one other thing to worry about, namely the very last commit to SVN, which obsoletes the repository and points to the Git repository. But that's not all of it. I was also silly enough to include a fix in the same commit. Let's see what Git can do. Since the process of obsoletion involves all but adding a file, we can simply --amend the last commit and provide a new log message:
$ git checkout master
$ git rm OBSOLETE debian/OBSOLETE
$ git commit --amend
Now the repository is in an acceptable state.
Making ends meet The pkg-mdadm effort on svn.debian.org only maintained the ./debian/ directory, separate from the upstream code, and boy was that a bad idea. Just to give one example: think about what's involved in preparing a Debian-specific patch against the upstream code this has to end, and we can make it end right here; let's import upstream's code (again not using his ADSL line, but the upstream branch of the pkg-mdadm Git repository; see the previous post for details):
$ git remote add upstream-repo git://git.debian.org/git/pkg-mdadm/mdadm
$ git config remote.upstream-repo.fetch \
    +refs/heads/upstream:refs/remotes/upstream-repo/upstream
$ git fetch upstream-repo
$ git checkout -b upstream upstream-repo/master
Now we have two unconnected ancestries in our repository, and it's time to join them together. The most logical way seems to be to use the last upstream tag for which we have a Debian tag: 2.6.2. For this, we branch off the corresponding Debian tag (2.6.2-1) and merge upstream's 2.6.2 tag into the new branch. This will be a temporary branch Then, we rebase (remember, nothing has been published yet) the master branch on top of this temporary branch, before we end that branch's short life. The Debian tag stays where it is since it describes the state of the repository at time of the release of 2.6.2-1.
$ git checkout -b tmp/join debian/2.6.2-1
$ git merge mdadm-2.6.2
$ git rebase tmp/join master
$ git branch -d tmp/join
It just so happens that the head of the SVN repository, which is identical to the tip of our master branch, corresponds to Debian release 2.6.2-2, so we tag it:
$ git tag debian/2.6.2-2
We are now also "born" in the sense that maintenance in Git has started. Let's mark that point in history. There is no real reason I can foresee for this yet, but nonetheless:
$ git tag -s git-birth
Turning dpatch files into feature branches We want to turn dpatch files into feature branches and we somehow make it "proper". We could branch, apply the patch, delete the patch file, checkout master and delete the patch file there as well, but that appears "improper" to me at least; so instead, we'll cherry-pick:
$ git checkout -b deb/conffile-location
$ debian/patches/01-mdadm.conf-location.dpatch -apply
$ git rm debian/patches/01-mdadm.conf-location.dpatch
$ git commit -s
$ git commit -s $(git ls-files --others --modified)
I should quickly intervene to make sure you are following. I am making use of Git's index here. Applying the patch makes the changes in the working tree, but we did not tell Git that we want those to be part of the commit just yet. Instead, we delete the dpatch with git-rm, which automatically registers the deletion with the index. Thus, the first git-commit creates a commit which deletes the dpatch, while the second git-commit creates a commit with all the changes from the dpatch, using git-ls-files to identify new and modified files. But for now, let's move on. We have two commits in the deb/conffile-location branch, and one of those is relevant to the master branch, we cherry-pick it:
$ git cherry-pick deb/conffile-location^
If you're confused, let me explain: our goal is to have a number of feature branches, of which master is the one in which most of ./debian/ is maintained. All the branches later come together in the long-living build branch, so deb/conffile-location will never be merged back into master. However, once we applied the dpatch to the feature branch, we can delete it from there and the master branch. By cherry-picking, we "import" the deletion to the master branch. I repeat the same procedure for deb/docs, merging all the documentation-related dpatches, but I'll spare you the details.
and then Git let me down In the next step, I found I had misunderstood Git merging: I thought Git was smart, but Linus had his reasons for calling Git the "stupid content tracker" (more on that later). Read on as I am obsoleting dpatch files that upstream had merged: 99-*-FIX.dpatch. For consistency, I wanted to cherry-pick each of the appropriate upstream commits into the master branch along with deleting the corresponding dpatch file. Here is one example: 99-monitor-6+10-FIX.dpatch was obsoleted by upstream's commit 66f8bbb; the -x records the original commit ID in the log:
$ git cherry-pick -x 66f8bbb
$ git rm debian/patches/99-monitor-6+10-FIX.dpatch
$ git commit -s -m"remove dpatch obsoleted by $(git rev-parse --short HEAD)"
I repeated the procedure for the other dpatch files, removed the dpatch infrastructure, and then went on to merge it all into build to build the package. The build branch is a long-living branch off upstream, but which upstream? I'll fast-forward you past a segfault problem with mdadm, which upstream (thought to have) resolved with commit 23dc1ae after 2.6.3, but he had not yet released 2.6.4. Looking at the commits between 23dc1ae and upstream's HEAD at the time, I decided to include them all and snapshot 4450e59:
$ git fetch upstream-repo
$ git checkout upstream
$ git merge upstream-repo
$ git tag mdadm-2.6.3+200709292116+4450e59 4450e59
$ git checkout master
$ git merge --no-commit mdadm-2.6.3+200709292116+4450e59
$ dch -v mdadm-2.6.3+200709292116+4450e59-1
$ git add debian/changelog
$ git commit -s
And then I called poor-mans-gitbuild, which merges master and then deb/* into build. Here is when stuff blew up. I'll make a long story short (read my description of the problem and Linus' answer if you want to know more): I thought Git was smart to identify merges common to both branches and do the right thing, but it turn out that Git does not care at all about commits, it only worries about content and the end result. In our case, unfortunately (or fortunately), the outcome meant a conflict because the upstream branch introduced a simple change (last hunk) in the lines surrounding the patch we cherry-picked, and Git can't handle it. The solution is not to cherry-pick, to cherry-pick all commits touching the context of the dpatch, or to simply merge upstream into all out feature branches. In our case, the first is the easiest solution and since importing dpatch files is a one-time thing (thank $DEITY), I'll leave it at that. Almost. I have spent two days thinking about this more than I should have. And it was this point Linus made which made me appreciate Git even more:
Conflicts aren't bad - they're good. Trying to aggressively resolve them automatically when two branches have done slightly different things in the same area is stupid and just results in more problems. Instead, git tries to do what I don't think anybody else has done: make the conflicts easy to resolve, by allowing you to work with them in your normal working tree, and still giving you a lot of tools to help you see what's going on.
The end This concludes today's report. Importing the changes from the old Git repo, tagging and merging the branches is all covered in my previous post, or at least you'll find enough information there to complete the exercise. I would like to specifically thank Sam Vilain and Linus Torvalds for their help in preparing this post, as well as the #git/freenode inhabitants, as always. If you are interested in the topic of using version control for distro packaging, I invite you to join the vcs-pkg mailing list and/or the #vcs-pkg/irc.oftc.net IRC channel. Also, if you are interested in Git in general, you can find a list of blog posts on the Git wiki. NP: The Police: Zenyatta Mondatta

Marco d'Itri: Bug or feature? s/// and the g option

I recently discovered some perl behaviour that I cannot explain. My goal in this code was to get the matched string in $1. I see how only having a scalar for multiple possible matches (the result of g) could be a problem, but I expected to alyway get something. The effect instead is that $1 may or may not be defined, depending on apparently unrelated changes like setting the i option or changing the regexp in a way which does not alter the matched text. My test case follows.

#!/usr/bin/perl
use warnings;
use strict;
#use re 'debugcolor';
my $text = <<END;
XXWY
XXWZ
END
# $1 is defined only if I remove either of ?, g or i
my $count = $text =~ s#(XXW?Y)##gi;
print "REMOVED: <<$1>>\nCOUNT: $count\n";

Russell Coker: AUUG 2007

Today was the final day of the AUUG 2007 conference [1]. Yesterday I gave a talk about SE Linux for about an hour (not sure exactly as I forgot to make an MP3). AUUG is well known for having conferences with very technical delegates and I wasn’t expecting an easy audience. At the start of my talk I asked for a show of hands as to who has used SE Linux before, about 1/3 of the delegates raised their hand. Someone requested that I poll the audience as to who had used SE Linux involuntarily, it wasn’t what I had planned to ask but it’s best to get these things out in the open so I asked the question. More people raised their hand as being unwilling users of SE Linux than those who had firstly admitted to using it! A theme of the AUUG conference was quality, and I had planned to cover some of the ways that SE Linux improves the quality of code by making certain classes of bugs show up (EG file handle leaks) and by allowing the developers and sys-admins to know exactly what programs are doing. But I ended up explaining why you want to use SE Linux, the concepts of policy analysis tools (as compared to the absence of such tools for Unix permissions), the benefits of MAC and why SE Linux is worth using. I believe that the talk did some good and conversations with delegates afterwards revealed that some of them had done some positive things with SE Linux. Today I wore a T-shirt advertising the root password for my new SE Linux Play Machine [2] which will be online shortly (hopefully tomorrow) which got some interest (AFAIK I’m the first person to wear a root password on a T-shirt). When I have my play machine online I plan to wear the shirt whenever I visit an electronics store or any other location where geeks are likely to congregate. ;) After the conference finished about 1/3 of the delegates went to Ginza Teppanyaki [3] for dinner. Some of the guys wanted to photograph me wearing my shirt. Finally, the conference went pretty well, the delegates and speakers all seemed to enjoy themselves and learn some useful things. Congratulations to the AUUG conference organisers!

13 October 2007

Christian Perrier: RWC: One of the worst games of this World Cup

So, A completely non-existing French team lost against a....nearly completely non-existing English team. Too many bad decisions, too much bad kick play, too many lost balls....and even no luck (the English try...damn). The French team couldn't win with such poor play (even when they were leading by 9-8, we both were completely sure they would lose on a penalty kick). What's pretty sad is that England nearly showed nothing too and, therefore, both teams made this the worst match I've seen in that world cup. Hopefully, Argentina and South Africa will show some better play tomorrow. However, when I see this, I nearly regret that France eliminated New Zealand. The All Blacks could never have played as bad as France did and they would certainly have kicked out that boring English team. Definitely, I'll be South African or Argentinian next Sunday (I have a small preference for being Argentinian, indeed).

Joey Hess: more mr fun

I've hacked a lot of handy features into mr. Some more examples follow. I've ommitted noisy output from the various revision control systems. Registering existing repos:
joey@kodama:~/tmp/scratch> git clone git://git.kitenet.net/mr
joey@kodama:~/tmp/scratch> svn co svn://svn.kitenet.net/joey/trunk/src/packages/alien
joey@kodama:~/tmp/scratch> mr register mr
Registering git url: git://git.kitenet.net/mr
joey@kodama:~/tmp/scratch> mr register alien
Registering svn url: svn://svn.kitenet.net/joey/trunk/src/packages/alien
joey@kodama:~/tmp/scratch> mr up
mr update: /home/joey/tmp/scratch/alien
At revision 13492.
mr update: /home/joey/tmp/scratch/mr
Already up-to-date.
mr update: finished (2 successful)
Command-line modification of the ~/.mrconfig file, and the ability to skip a repo based on an arbitrary shell test:
joey@kodama:~/tmp/scratch> mr config tmp/scratch/alien skip='[ $(hostname) != foo]'
joey@kodama:~/tmp/scratch> mr up
mr update: /home/joey/tmp/scratch/mr
Already up-to-date.
mr update: finished (1 successful; 1 skipped)
Tracking and warning about deleted repositories. Useful if, like me, you have dozens of repos checked out on dozens of machines:
joey@kodama:~/tmp/scratch> mr config tmp/scratch/mr deleted=true 
joey@kodama:~/tmp/scratch> mr up
mr error: /home/joey/tmp/scratch/mr/ should be deleted yet still exists
mr update: finished (1 failed; 1 skipped)
joey@kodama:~/tmp/scratch> rm -rf mr
joey@kodama:~/tmp/scratch> mr up
mr update: finished (1 skipped)
(Tracking of repo moving is still TODO.) Running mr from inside a repo operates on only that repo. Useful when you can't be bothered to remember what revision control system a particular repo uses. ;-)
joey@kodama:~/src/mr/debian> mr commit -m "bugfixes developed while writing blog post"
mr commit: /home/joey/src/mr (in subdir /home/joey/src/mr/debian)
Created commit 2f861a4: bugfixes developed while writing blog post
It also supports cvs and bzr now.

12 October 2007

Rapha&#235;l Hertzog: The DSA dilemma

For once, Clint blogged on something that I can understand. :-) I don’t buy everything he says, but in the case of DSA, the part where he says “you cannot have a functional and respectable subgroup if it maintains autonomy like that” is a real problem. The leadership problem I mentioned is real. And it can theoretically be solved by undelegating one of the problematic side of this DSA-internal dispute. But which one? Given the unwillingness of Joey to discuss the problems, he makes an easy target… which would leave DSA up to Ryan, James and Phil. But is that a desirable thing? If DSA is perceived as being an “autonomous” group which is not involved in Debian’s main discussions and which is somewhat disconnected from Debian’s day-to-day life, it’s largely due to the behavior of James and Ryan. E-mail communication with them is very difficult as they’ll respond only if they really care about something. And despite the setup of the request tracker, they have barely been able to make proper usage of it… the idea was to use RT tickets to track everything that DSA does but they don’t use it as such. For example, James setup a “wikiadm” group and he never reported anything to the related ticket (#194) (I did it myself once I found out). Also there’s an internal ticket about the replacement of ftp.debian.org (that I created because ftp.d.o ran out of space regularly) and AFAIK Jeroen has been in touch with James to setup that replacement, but nothing got reported to the tracker. Ryan promised me once to put his DSA TODO list in the tracker so that other people can jump in and help out. He never did. So while Joey is definitely a pain for DSA, at least he’s a visible participant of the team and he interacts with the community. James and Ryan are not, they interact only through private channels and do not share their opinions or their vision of Debian.
I believe this is a real problem. On the other hand, most of the interesting changes in the last months are the results of James’s work. But he’s also implicitly blocking addition of new members as long as the leadership problem is not solved. I tried to fill the communication void of the DSA team by various means. I follow everything as closely as I can so that I can report changes on other channels, mailing lists when needed. I made efforts to document stuff on the wiki page, etc. But this is not a long term solution, the communication issue must be fixed within the team. The path ouf of this mess is still not very clear, but something is going to change soon. Not quite sure what though. What would you suggest? And if you were DPL, what would you do? Since private discussions and negotiations lead nowhere, it’s tempting to bring the issue in the public area. In theory, they have no way to escape discussions and they’ll have to communicate their grudges against the other side if they want to have some fair judgment between both parties. Unfortunately, given the habits of James and Ryan, they probably won’t participate in any public discussion and either resign or stay where they are waiting for any decision… Comments welcome. Partagez cet article / Share This

11 October 2007

Lars Wirzenius: Debian: In the interest of full disclosure

<liw> Guest1482, iirc fakeroot doesn't work on all architectures, and there may be situations where it doesn't work on any, but it should certainly be used when possible <Clint> liw: it should always work the same on all the linux ones <liw> Clint, I have a vague recollection of libc making life difficult for fakeroot on... sh? hppa? but I may be utterly wrong here, and I hope I am <Clint> liw: there was a crackheaded struct change on alpha, but vorlon and i fixed that <Clint> "fixed" <liw> Clint, ok, so I'm utterly wrong, and the world is a better place for it <Clint> that's right, so stop spreading fakeroot fud <Clint> OR ELSE
I take it back, I offer a complete and utter retraction. The imputation was totally without basis in fact, and was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my comments may have caused fakeroot, or its family, and I hereby undertake not to repeat any such slander at any time in the future.

Russell Coker: Getting People into IT

Pia writes about the difficulty in getting young women and young people in general into the computer industry [1]. While I agree that having more women in the computer industry would be a good thing, I have difficulty believing some of the claims that Pia makes. For example the claim that “[girls] are more career focused earlier in their school life“. I chose my career when I was about 11 years old [2] and several of my friends made similar decisions at similar ages. I would be interested to read anecdotal evidence from women in the computer industry about how old they were when they decided on their career and if their friends did the same, a reference to any research on this topic would also be useful. I tend to believe that boys are more career focussed at all stages of their life but have little evidence to support this idea. One fact that seems obvious is that the idea that “if you don’t succeed in your career then you can always marry someone who does” is almost non-existent among boys. It seems likely that such ideas have a statistically relevant affect on the focus on career of boys vs girls. Also the Australian Bureau of Statistics reports that the MEDIAN income for women is significantly lower than for men [4], I find it difficult to imagine that girls could be more career focussed from a younger age and yet get significantly lower pay (note the fact that it’s median not mean income is very significant as it removes the “glass ceiling” effect). Phillip Greenspun writes about why there are so few women doing scientific research [6] and makes some good points about why scientific research is generally not well paid and therefore a university student would choose a career in some other area and suggests that it’s a macho thing that guys enter such competitive fields for relatively low wages. Maybe some women correctly assess the costs and benefits of a career in scientific research and then make the mistake of equating Computer Science to other branches of science. But the median income suggests that although there may be some valid reasons for avoiding science that would only cover a small portion of the problem (the difference in median income can not be explained by misplaced attempts to maximise income). One problem that is significant is the quality of school education for girls. Not only is there the issue that boys may crowd-out girls for some subjects that are supposedly traditionally for boys (such as all science) but even girls schools aren’t as good as they should be. Some time ago I was talking to a teacher at an all-girls school, the school was moderately expensive and parents were paying the extra money presumably to give their daughters educational opportunities that they might miss in a co-ed school. However the school did not teach hard maths (”Maths B” was the official name at the time) and only taught the easy maths (official name “Maths A” and unofficial name “Vegie Maths“) because they didn’t have many girls demanding it (which is probably difficult to measure if you don’t offer it as a reasonable option) and the girls who wanted to study it could always move to a different school. So the choice facing girls at the exclusive school in question was “skip the subject that is most useful for further studies in most science subjects” or “go to a different school and miss most of your friends“, this sort of decision would surely discourage some potential female computer programemers. Also I think that the difference between boys and girls in regard to studying computer science has a lot to do with the fact that given a choice between missing most of their friends and missing out on something related to computers would be a no-brainer for most boys. Paul Graham’s article about Nerds has some interesting points to make in this regard - maybe the problem is that girls aren’t Nerdish enough [5]. Pia also writes about parents and teachers advising children not do study IT because of a perceived lack of jobs. I think that the problem here is not just bad advice, but also a bad tendency to take advice. Someone who wants to study in an established field which changes little over time (law and accounting spring to mind) probably should take careful note of the advice that they are given - things haven’t changed much in the last few decades. But someone who wants to study in a field that changes rapidly and where every year has new and significant developments (of which the best example is the computer industry) should probably be quite skeptical of all advice - most advice about the computer industry concerns how things used to be not how things are. Finally when considering whether to accept advice you should consider who is offering it. For example advice from a hiring manager should be carefully noted (as the manager will tell you precisely what factors influence their own decisions on hiring). Advice from people who are successful in the industry should also be noted. Advice from a school career advisor who gets paid about 1/3 what any 25yo can earn in the computer industry should be entirely ignored. I wonder whether being hesitant to ignore advice is a problem for girls in this regard. When I was in year 11 I had to take a subject related to career planning. It covered some things that were of minor use (such as writing CVs) and had an assignment of writing a fictional CV for yourself a few years after leaving university. I received bad marks for preparing a CV that involved changing jobs as companies went bankrupt or projects failed due to bad management, I was told that if your employer fails in the market it makes you look bad! However my fictional CV did bear some resemblance to what really happened… In terms of what industries have jobs available, the best advice I can give students is to actively do some research of their own. It’s not difficult to get the jobs sections of some newspapers and do a quick scan to see how many positions are open in a field, and it’s even easier to do some searches on online jobs sites (which usually tell you how many positions posted in the last X days match your criteria). For example I just visited jobserve.com.au and found 1724 Engineering jobs and 5622 IT jobs advertised. If you compare this to the university intake (I visited the Swinburne university courses list [3] and found 25 IT courses vs 29 Engineering course) it seems that the ratio of Engineering graduates to jobs is not likely to be as good as that for CS graduates. Of course it may be that all the other universities have hardly any Engineering courses and balance the ratio out (but I doubt it). In any case this would be a good way of injecting some facts into a discussion of the relative merits of different career choices and avoiding it being an issue of parents/teachers not liking computers vs children liking them. Determining the relative pay rates of different industries is a lot more difficult (and requires a significant amount of work), some recruiting agencies publish statistics - but those stats only apply to the positions that they fill (which is a sub-set of the actual positions). Finally as a piece of advice for children, try and find a job that you enjoy. If you earn $30K doing something you enjoy then you’ll probably be happier than if you earn $100K doing something you hate. Also if you enjoy your work then you will probably be able to take the extra steps needed to become successful - often it’s not a choice between having fun or making good money but a choice between fun and good money or the absence of both. If someone tells you to avoid doing what you love and instead do something boring for some unsubstantiated belief that there would be more money in it then be a nerd and tell them that their opinion is not relevant (it does tend to make teachers angry though).

Andrew Pollock: [life] A c-section from a bloke's perspective

I've been meaning to write this for weeks. Hopefully I can still remember everything. So Sarah had a c-section the day before we were scheduled to have our c-section class. We'd both read a bit though, so it wasn't like we were going in totally uninformed and unprepared.. Firstly, Stanford Hospital's operating room area is rather mind-blowing. Sarah was transferred from Lucille Packard Children's Hospital to Stanford because they could get an operating room there sooner. The transfer was trivial, just roll the whole bed down the corridor, through the magic double doors into the operating rooms. The doors in question have a whole heap of video cameras pointing straight down, so they see everyone that gets wheeled in and out, which I found interesting. Good for records of patient movements I guess. Anyway, through those doors is a maze of corridors. There was a light-up board hanging from the ceiling in the middle of the main corridor with lights for all of the ORs. I think there were about 20. The illuminated ones were available. We went down a corridor, and past a few ORs. Outside of each one is a big stainless-steel scrub area. We got to "our" OR, and they transferred Sarah onto the operating table. Because of her heart condition, they wanted to have an arterial line in her for the duration of the procedure. This is some sort of gadget that goes into an artery and monitors your blood pressure beat by beat. The "interesting" thing with the anaesthesiologist was the New Zealand woman that we'd seen when we had an anaesthesiologist months prior, but the appointment was with a different anaesthesiologist, and this New Zealand woman was "observing". At the time, the anaesthesiologist we had the appointment with told us that she was going to be on vacation at the time of the delivery, so she wouldn't be attending. So I don't know if the Kiwi woman got promoted out of "observing" to "doing" in that period, or what, but she reintroduced herself to us in LPCH prior to moving to Stanford as being our anaesthesiologist for the delivery. Anyway, in the OR, they handed her the arterial line, in it's plastic packaging, and the first thing she asked was whether it came with anything else to put it in. At this point I figured she hadn't put one of these in before. (The answer to her question, by the way, was "no") She then proceeded to have a terrible time getting the line into Sarah's arm. Normally intravenous lines go into a vein, but this has to go into an artery. Apparently when you go poking an artery, it spasms. It then becomes very hard to get it into a moving target. She had a few goes on one arm, then gave up, and had to move over to the other arm. Sarah doesn't like needles at the best of times, and getting this honking great big thing in was no picnic. The bruising on both her wrists afterwards was phenomenal. She tends to bruise fairly spectacularly whenever they stick a needle in her. I almost stepped in and asked if it was really necessary that she have it, because they were having so much trouble getting it in, and it was clearly hurting Sarah. I think someone else ended up getting it in, not the anaesthesiologist. Not "that" one anyway. There were heaps of people in the OR. Next, came the epidural. Again, we had the inexperienced anaesthesiologist. This time she said to someone else how she was so nervous because there were "too many eyes". Not really reassuring. They gave Sarah a numbing injection first, and then proceeded to poke her in back with the epidural catheter needle thing. Sarah was flinching when they did it, and they kept yelling at her not to move. Apparently it didn't hurt, but it caused discomfort every time they tried to get it in. Eventually the associate professor of anaesthesiology stepped in and got it in. Later, they said that Sarah had a slightly curved spine or something, and that had made it a bit more complicated. I'm not begrudging the obviously inexperienced anaesthesiologist for anything. Stanford is a teaching hospital, and doctors have to get their experience somehow, but I think that when the patient is conscious, it's important to come across a little more confident. So once they got all of that sorted out, they could get her lying down on the table and get down to business. Apparently one of the side-effects of the epidural is that it can cause your body to think it's got hypothermia. Part way through the procedure, Sarah started shaking uncontrollably. I can't remember whether she complained about feeling cold or not. She also got a really itchy face. Apparently that's a side-effect of morphine. Sarah also doesn't tolerate anaesthetics very well, and started feeling nauseous part way through the procedure. Sure enough, as has happened countless times previously post-operatively, she threw up. At least we had warning and I got a kidney dish in place in time. That was about all the eventful surgical stuff. They had the usual screen up from about her neck area, so I couldn't see what they were doing. After Joshua was delivered, one of the nurses asked me if I wanted to see him, and took me around from her left shoulder where I'd been sitting to around below her right foot, to where they had him in one of those perspex portable crib things. I could see a lot of red out of the corner of my eye, and I could have seen a lot more if I'd bothered to look, but I was more interested in seeing my son at that stage. They let me bring him back around to where I'd been sitting previously, to show Sarah, but it was hard getting him up to a point where she could see him properly, and she was partially out of it by this stage. I think she dozed off for a little bit not long after that. I forget what time we got into the OR, but they started the operation in earnest at about 10:00am, and we were out of there by 10:45am if memory serves. The nurse in charge of the recovery room really didn't want me there, so I went back to LPCH with one of the nurses to spend some time with him while he was weighed and measured, and I took some photos, and held him. This was good, because I got to have a good cry on my own with him. So overall, in my "I'll never be squeezing a watermelon out of my nether regions" blokey perspective, having seen what Sarah went through, and how much discomfort that it looked like she was going through, both in the OR and afterwards, I'm not convinced c-sections are any less painful than a vaginal birth (taking the average case of both). I think you're trading some "short term" (depends on how long your labour is I guess) pain for some "long term" pain while you recover from your incision. Granted, Sarah wasn't really laid up all that badly for all that long, but it still didn't look all that pleasant. I guess really only the women who have done both delivery methods can really comment. All I know is I found it very difficult watching Sarah go through so much pain. So much so that I'm not really looking forward to that again. Maybe, hopefully, after her aorta is repaired, they'll let her delivery vaginally next time. I'm not holding much hope though. The high-risk obstetricians are fairly paranoid. There's also the possibility the baby will make the decision very easy for everyone by being breech. Sarah raised an interesting point today. Why didn't they just knock her out with a general anaesthetic? There was no need for her to be conscious for the delivery. That would have spared her the pain and suffering of getting the arterial line in, and they wouldn't have needed to bother with an epidural. One for her to ask the obstetrician at her follow-up appointment.

Andrew Pollock: [life] The fun doesn't stop

We went to see Sarah's cardiologist the week after she was discharged from hospital, and he said that looking back over all of the echocardiograms that have been taken in the 18 months or so that he's been following her, it looks like her aortic aneurysm has gotten a little bit bigger. It's still below the size that they'd normally operate at, but he said that in his opinion it should be repaired before attempting another pregnancy, to play it safe. He even said that afterwards, Sarah could go back to doing triathlons, which is a big step back towards a normal life. So on Monday, we had an appointment with Dr Craig Miller, who is apparently the best cardiac surgeon in the US, and one of the top three in the world, when it comes to aortic aneurysm repair whilst being able to save the heart valve. We'd done a heap of reading up on Dr Miller before the appointment, and the cardiologist's clinic administrator had told us about him as well. Apparently he's a real character. He certainly looked it from the staff photo (linked above). In reality he looked much more like this. But he's certainly a real cowboy type. We saw his nurse practitioner on Monday before we saw him, and his nurse practitioner was this moderately pierced, cowboy boot wearing, "y'all" speaking kinda guy, who really knew his stuff. In fact we exhausted all of our questions that we had for Dr Miller on him before we even saw Dr Miller, because he was running a bit late with the previous patient. This is where Sarah's got a pretty detailed write-up of what they're planning on doing. They're going to replace more of the aorta than they would otherwise (because the enlargement seems to be continuing further up the aorta), which makes the surgery a little more involved, in that they're messing with the arteries that lead up to the brain, so they've got to some more funky bypass work, and lower her core temperature so her brain copes with the blood flow being monkeyed with. Dr Miller was very softly spoken, and a lot older looking than I'd expected, given the whole cowboy hat thing. He seemed really nice and thorough, and explained everything. He also showed us what a mechanical valve looked like. The reason sparing the valve is so important is that the alternatives if they can't are either a pig's heart valve or a mechanical one. Both have their drawbacks. A pig's valve won't last the rest of Sarah's life. She'd need to have valve replacement surgery at some point down the track (I think they said about 8 years, although they wear out faster in younger people). A mechanical valve requires you to take blood thinning drugs for the rest of your life. One of the side effects of these drugs are birth defects. It's also audible from outside the body. We got to see (and keep) a sample of the Dacron tubing that they use to replace the part of the aorta they're removing. I was totally taken aback by the diameter of it. I hadn't sat down and really thought about what 4.4cm (which is about what her aneurysm is currently at) really looked like. The operation is likely to take 8 to 10 hours. I'm not looking forward to that waiting game. Dr Miller said the procedure, whilst sounding pretty bloody scary has about a 1% risk. I'm not exactly sure what that is a risk of though. Sarah's booked in for January 3 next year. The road ahead is still long.

10 October 2007

Russell Coker: Dreamhost and the DMCA

Dreamhost have refused my request (under the DMCA) to be correctly identified as the author of content copied from my blog. I am publishing this so that anyone else who deals with them will know what to expect. Also if someone wishes to sue Dreamhost in regard to content that they host this may help demonstrate a pattern of behaviour. The situation is quite obviously the result of a broken script used by a splogger that doesn’t correctly match author names with articles. The fact that the official Dreamhost policy is to disregard the requirement that the author(s) of copyright material be correctly identified is reprehensible. It also seems likely to open them to the risk of legal action. If you know how to contact a director of Dreamhost then please give them a link to this post and explain the risks to them. For anyone who wants the detail the messages are below.
(more…)

Adam Rosi-Kessel: MBTA Responds

To follow up on yesterday’s MBTA philippic, I received a response from the T’s customer service regarding my complaints. Although it doesn’t give me hope that things will improve, it’s nice that they have at least hired someone to write personalized, polished replies. At least they can do that right:
Dear Mr. Kessel, Thank you for your email concerning service on the Needham Line. The past couple of months have been difficult for our passengers, and I want you to know we are very sorry for the inconveniences this has been causing. The causes of these delays have ranged from signal and mechanical issues to long stops boarding passengers at stations, and even track work on other lines. I know that it may seem odd that trains on other lines can impact your trains, but I assure you that is true. The Franklin, Needham, Providence, and Stoughton lines, as well as Amtrak all share the rail between Hyde Park and Boston. All it takes is one delayed train in this area to cause a cascading effect that delays other lines. There’s also the fact that trains may come in from one line to go out as another. For example, a train on the Worcester Line comes to Boston, and either the train set, or the crew (sometimes both) head out as an outbound Needham train. If the inbound is late from Worcester, then the outbound Needham will be late, which also means that its “turn,” the next inbound, will be delayed. In response to your comment about the doors not all being opened, even with a full compliment of conductors, crews are not able to staff every door, and especially at ground level stations we want to ensure that all customers are able to board and detrain safely. This is why conductors do not open all doors to the train. I contacted our Mechanical Department, asking that the PA system on train 625 be checked out to make sure everything is working properly. Please know that delays in service are not something that we take lightly, and all departments are committed to working together to ensure that our customers receive timely, safe, and reliable service. Once again, I am sorry for the inconvenience this has caused you. Thank you for writing. Sincerely, Linda Dillon
MBCR Customer Service Manager

Antti-Juhani Kaijanaho: It s time to fix the ABI

SELinux is entirely correct about disallowing dynamic code generation, as it is a major security risk. Disregarding Just-In-Time compilation, the main legitimate need for dynamic code generation is to support (downward) closures that are ABI-compatible with normal C functions. GCC’s local functions extension of C is one example, and many non-C languages need them badly in their foreign-function interfaces (Haskell is one, Ada I’m told is another). A closure is a function pointer that refers to a function that is local to another function. That function has access to the local variables of the parent function, and this access is provided by having the caller give the callee a static link (a pointer to the parent function’s stack frame) as a hidden parameter. If the call is direct (that is, not through a function pointer), the caller knows the appropriate static link and can just pass it. The trouble comes with function pointers, as we need some way of including the static link in the function pointer. The simplest way is to have function pointers be two words long; one of the words contains the classical function pointer (that is, the entry point address), and the other contains the static link. Unfortunately, the prevalent C ABIs, including the SYSV ABI used by GNU/Linux, mandate that function pointers are one word long. The only way I know to work around this is to dynamically generate, when the function pointer is created, a small snippet of code that loads the correct static link to the appropriate place and jumps to the actual code of the function, and use the address of this snippet (usually called a trampoline) as the function pointer. The snippet is generated on the stack or in the heap, and thus requires an executable stack or executable dynamic memory. It’s time to fix the ABI to allow for proper two-word function pointers.

Andreas Schuldei: video survailance

Concerning Russels post about the pros and cons of video survailance i saw an interesting article about the evaluation of the berlin subway surveilance. According to that the system did not help to prevent crime, instead people seemed to have considered it when they e.g. created new graffity.

Aparently those results of the evaluation were not very welcome and there were effords to suppress them. This gives me the feeling that there is yet an other agenda to the growing and more and more pervasive survailance. I just wonder what it might be.

In unrelated news blogger.com seems to regard this text as written in swedish despite my selection in the preferences.

Russell Coker: Execmem and SE Linux

Eddy writes about problems getting the game oolite to run under SE Linux [1]. Strangely after I fixed the shared object issue with libffcall1 (as described in my previous post [2]) it appeared to work for me. Eddy asked how to allow one application to create write and executable memory regions without allowing such access for all programs. This can be done, in the targeted policy the type unconfined_execmem_exec_t triggers a transtion to the domain unconfined_execmem_t which permits the execstack and execmem operations. For example if the program /usr/bin/foo needs such access then the command chcon -t unconfined_execmem_exec_t /usr/bin/foo will change the type and the next time the program is launched from an unconfined session (a user login session, cron job, or daemon which is not constrained) then the change will apply.

Dirk Eddelbuettel: Chicago Marathon 2007

Last Sunday, the 30th Chicago Marathon took place. This was meant to be the year to make this marathon even bigger: the field had increased substantially to 45,000 registrations yet it still sold out way earlier than in previous years. As it turns out, the weather did have its own surprises in store. Earlier in the preceding week, the forecast changed from overcast and rainy to sunny. And sunny it was. While we had a bit of cloud cover at the start at 8:00am, temperatures were already in the 70s and keep increasing. This year's marathon is now on the books as the hottest ever: the clouds dissipated and it was a scorcher. Needless to say, it was a rather challenging race. I finished in 3:41:39, which is my slowest time by some margin for the by now seven marathons I've ran. It was not the day for running fast. Of course, I didn't quite grok that at the start and ran ten miles reasonably hard in a quick pace, but then paid for it, and then paid some more. That said, apparently around 10,000 registered entrants didn't even start, and another 10,000 did not make it to the finish. With the heat, several hundred were treated by the medical teams. Worse still, one 35-year old runner from Michigan died (though the autopsy claims he had a heart condition; other reports say that alone cannot have been lethal). The race itself was aborted, and those who had not reached the half-way point by 12:00am were diverted to the finish and urged to walk rather than run. According to the (by now fairly extensive) news coverage, this whole experience left quite a few people mad and bewildered. As of today, a good 48 hours after the race, the City seems to be in some sort of crisis management mode to prevent damage for the oh-so-important bid for the 2016 Olympics. For some flavour of the news coverage, see an early report, some stunning pictures and some suggestions to prevent another one like this, all from the Chicagoist blog.

Adam Rosi-Kessel: MBTA Out of Order

Steve points out that the T has been falling apart lately. My own experience gives it a solid D minus as well. Over the three years I’ve lived in Roslindale, I’ve been quite satisfied with the commuter rail. Unlike other lines (e.g., Worcester), the Needham Heights line does not share tracks with other carriers, and thus does not regularly get tens of minutes off schedule waiting for freight or other traffic to pass. (Why freight gets priority over passengers is a question for another day.) I live about 90 seconds walk from the commuter rail station, and I could calibrate my departure to be within one minute of the train every time. Over the past few months, however, it has been a steady downhill slide. None of these complaints are novel, but I’ll enumerate them anyway: Trains have been canceled without notice (you didn’t really need to be at work by 9am, did you?). Nearly every train is late — I’ve started thinking of the 8:23am as the “8:30″ because it hasn’t arrived before that time since early in the summer. Many trains are missing cars, so the remaining cars end up being standing-room only. Almost every day the train needs to wait for a free track at South Station, no matter which train I’m on. (I’ve never understood why this happens with 12 tracks, many of them empty.) Trains are often short conductors, which means not all the doors open at stops, which further exacerbates delay. And my personal favorite complaint: the PA system is often so loud that passengers have to cover their ears. Except when it’s broken and you can’t hear any announcements. I hate to kvetch, but there must be something wrong here beyond technical glitches. Perhaps the most frustrating part is having no clue about the inner machinations that provide this result. Other complaints from today (about different parts of the system).

9 October 2007

Chris Lamb: Top 10 interactive shell anti-patterns

In general, if you’re doing a repetitive task by hitting lots of keys, you’re doing it wrong. Not only are you wasting time, you’re wearing out your keyboard and damaging your wrists and fingers. Here are the ten most common anti-patterns (actually amelioration patterns) that I commonly see in other people’s line editing:
  1. Repeating a command by retyping it
    Press Ctrl-p and Enter, or “!!“. Zsh users get “r” as well. You can even get the command n times before, use “!-1“. Using the arrow keys is obviously flawed - find out how to unmap them in your shell.
  2. Manually changing back to your previous directory
    Give “cd -” a whirl.
  3. Typing a long command (or sequence of commands) excessively often
    Obviously wrong, but I see it so often it’s worth mentioning. Try using an alias and put it in your shell’s startup file. If the command is parameterised, you could construct a simple function. If you are writing software, look into the build systems available for your language - the basics of GNU Make can be mastered within 20 minutes or so, and have many other benefits too.
  4. Opening another shell when the current process blocks
    (e.g. You realise the command you started is going to take a lot longer than you thought) Pause the current process with Ctrl+z and then put the job in the background with bg. fg will bring it to the foreground again. Fewer shells mean you stay focused on what you were trying to achieve.
  5. Searching history by grep’ing ~/.bash_history, or Up Up Up … etc.
    Use CTRL+r (or “/” in vi-mode) for search-as-you type. You can immediately run the command by pressing Enter.
  6. Adding a prefix to a command with Up Home $command Space
    (e.g. You ran a command that really needed sudo). Try: $prefix !!
  7. Changing a command with Home Right Right Right Right … BkSpace BkSpace … etc.
    (e.g you accidentally ran chown instead of chmod) Try: $new_command !*
  8. Retyping significant parts of the previous line
    $ command arg1 /long/path/to/file
    $ command2 arg2 /long/path/to/file
    $ command3 arg1 arg3 /long/path/to/file
    Try using !$ to get the right-most argument on the previous line (you can also use !:2 to get the second argument, etc.):
    $ command arg1 /long/path/to/file
    $ command2 arg2 !$
    $ command3 arg1 arg3 !$
  9. Using Home/End to move to the beginning/end of the line
    This is how you completely ruin your wrists. Use Ctrl+a and Ctrl+e.
  10. Hitting tens of keys to make a substitition
    (e.g. you made a trivial mistake in the middle of your previous command). Use ^foo^bar. If you forget the other nine, try this one - stop punishing yourself for making mistakes! :)

Next.

Previous.