Search Results: "ag"

11 July 2011

Vincent Bernat: Rewriting my .zshrc

Ten years ago, I started to use ZSH, a shell designed for interactive use but which is also powerful for scripting usage. I had a fairly comprehensive .zshrc file splitted in several parts. I have decided to rewrite it for several reasons:
  1. I did not take advantage of several features of ZSH, like some advanced parameter expansion, arrays, arithmetic expressions and other built-in features. There were a lot of head, awk, sed that could be replaced by some ZSH machinery (something easier to read like $ $ (f)~~"$(</etc/hosts)" %%\#* ).
  2. It contained a lot of hacks to make things work on some odd/old setups. I was not really sure that those hacks are useful anymore. It also contained a lot of conditionals where some parts of the code were executed depending on the hostname.
I have discovered oh-my-zsh, a nice project trying to provide a generic and flexible ZSH configuration:
A community-driven framework for managing your zsh configuration. Includes 40+ optional plugins (rails, git, OSX, hub, capistrano, brew, ant, macports, etc), over 80 terminal themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community.
The idea of such a project is to fork it and make the changes that you need. I was previously hacking around Phil! s ZSH Prompt for my prompt. oh-my-zsh contains a close theme (jonathan). Neat. However, I decided to write my .zshrc from scratch (but with some snippets stolen from oh-my-zsh). Why? Mostly because I want to precisely configure ZSH. Even with its plugin architecture and its override mechanism, oh-my-zsh provides some features (options, aliases, functions) that I do not want. Of course, thanks to git, you can fork and make any local changes you want but since I would have modified most of the files, it seemed easier to just start from scratch. I have published the result on GitHub. You can use it as is, fork it or (better) steal and adapt some snippets for your own usage. Here is the mandatory screenshot for the prompt (no much space left for the commands): My ZSH prompt Here is a short snippet used to select a sensible EDITOR depending on what is available. It uses anonymous functions (to restrict the scope of local variables), arrays and flags in parameter expansion. For another example, take a look on how I select a valid locale.
()  
    local -a editors
    local editor
    editors=(
        "emacs23 -Q -D -nw" # Fast emacs
        "jove" "mg" "jed"   # Emacs clone
        "vim" "vi"          # vi
        "editor")           # fallback
    for editor in $editors; do
        (( $+commands[$editor[(w)1]] )) &&  
            export EDITOR=$editor
            break
         
    done
 
Enjoy! UPDATED: Anonymous functions were introduced in ZSH 4.3.7. Older versions do not support them. A workaround is to use a classic function instead:
__()  
    local -a editors
    local editor
    ...
  && __

10 July 2011

NeuroDebian: NeuroDebian@HBM2011.ca

NeuroDebian@HBM2011.ca On June 26-30 the annual meeting of the Organization for Human Brain Mapping (HBM2011) took place in Quebec City, Canada. Encouraged by our positive experience at last year s SfN in San Diego and enthusiasm of our scientific adviser, James V. Haxby, we hosted another NeuroDebian booth. The setup was pretty much the same as last year: Some chairs and tables, lots of people, our tri-fold flyers, a Debian mirror and some virtual machine images to show Debian in action. This time we also had an LCD display attracting visitors with the package swarm, some demos, and our recent paper. We had many curious people have their first exposure to Debian, long-time users expressing their gratitude to Debian, and our upstream developers getting together to discuss various topics. Having registered the booth as NeuroDebian , we had the additional pleasure of explaining visitors the concept of a project inside Debian, in contrast to a derived distribution. But that is nothing new really, so let s talk about the differences from last year s booth. First of all, we had more people at the booth. Dominique Belhachemi volunteered to help us out and that was very much appreciated. Although HBM has only about a tenth of the attendees that SfN has, we had significantly more traffic. While last year people were primarily interested in knowing about the project, this time many of them wanted to give it a try immediately. People came with their laptops, got the VM images and started playing with Debian. After a day or so, some came back and asked for recommendations on particular software after having been exposed to the wealth of the Debian archive. What also had increased was the number of developers, or rather research labs developing neuroimaging software that came to the booth to discuss how to get their software into Debian and how to arrange ongoing maintenance of these future Debian packages. As we have our plates already quite full, we have been spending some time on mentoring interested developers to learn the art of Debian packaging and making them familiar with Debian s procedures and standards (e.g. working on #609820 with Yannick Schwartz, upstream, at the booth). ../../_images/BusyBooth216.jpg Two promising new developments need to be mentioned. First, we were approached by companies that develop hardware for brain-imaging and psychophysics research. They were curious to learn about Debian as an integrated platform that offers free software solutions that an increasing amount of their customers demands (e.g. PsychoPy). Apparently, the movement towards open research software has finally made it into the business plans of companies, as they seem to start perceiving compatibility with free software systems as a competitive advantage. We explained how software gets into Debian, and how its release cycle is managed. To foster their motivation we also pointed them to the existing open-source software that is already available or even present in Debian. Let s see whether we see more Debian-certified research products in the future. Lastly, we started talking with folks from the INCF to explore possibilities of collaborating on INCF projects using Debian as the integration and development platform. The INCF is an OECD-funded organization that develops collaborative neuroinformatics infrastructure and promotes the sharing of data and computing resources to the international research community. At least one INCF project is already relying on the efforts of the NeuroDebian project. We are going to continue this discussion during a workshop in September. A report will follow...
../../_images/DDs13.jpg

Debian people at the booth (f.l.t.r): Michael Hanke, Yaroslav Halchenko, Stephan Gerhard, Dominique Belhachemi. Not shown: Swaroop Guntupalli.

Acknowledgments This booth has been made possible by the generous support of Prof. James V. Haxby (Dartmouth College, New Hampshire, USA).

Kenshi Muto: Squeeze amd64/i386 d-i images with Linux kernel 2.6.38.bpo (update#2)

I updated the bpo Debian-installer for Debian GNU/Linux 6.0, Squeeze. You can download it from the place. Enjoy!

Christian Perrier: 33094 spam posts removed from Debian mailing lists in two years

Debian mailing lists' standard policy is to allow posts from unsubscribed users. That of course fits our standards for opened development but has the drawback of allowing a lot of spam to reach our mailing lists. This spam also clutters the mailing lists archives. Since 2009, a working system allows removing spam from the mailing list archives. Today, I would like to put some light on the results of this system : Results are impressive for mailing lists where a coordinated effort is done over time: the debian-boot mailing list (first coorindated effort, initiated by regretted Frans Pop), the Italian and French mailing lists. You want to help? You can. Reporting spam is as easy as reading Debian mailing lists. When you see a mail that you consider being a spam mail, just bounce it to report-listspam at lists dot debian dotte org. Don't forward it, you need to bounce it ("b" keyboard shortcut in mutt). Alternatively, you can check for this message on Debian mailing lists archives and hit the "Report as spam" button. If you're a Debian developer, you can help in reviewing nominated spam. It takes me about 20 minutes every week. Go to the spam review home page and register for an account there. Then, you'll be able to process through nominated posts. Once a given post is confirmed as spam by at least 3 reviewers with nobody else reporting it as "ham", it is removed the next week from the archive. Feel free to join the game and be part of the Debian moppers team!

Christian Perrier: Cheese and Wine party for DebConf 11, aka C&W7

Do I need to explain what is the Cheese and Wine (C&W) party? Still, if some of you need more information, please feel free to ask. The C&W7 wiki page now exists on DebConf wiki. Information will come there until the day of the C&W, which is scheduled for Tuesday July 26th, so the day before the planned daytrip, if I'm correct. C&W orga details are currently very vague, but the most important point is: start planning what YOU will be bringing for the event. Remember that the event is only successful when many of us manage to bring good stuff to share (preferrably cheese, wine...or other ethanol-improved beverages). If you think about something *else* than cheese, please feel free to bring it: just try to have it representative of your part of the world...or a part of the world you love. Any further questions can be asked in the debconf-discuss mailing list or in #debconf channel on irc.debian.org

James Morrison: Code reviews

I'm reading through http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/. So, I'll make my comments here since I expect they will be long. As a caveat, I still work at Google and have done a lot of code reviews. I've made a lot of mistakes while code reviewing, I've had difficult code reviews, but my biggest problems were non-code reviews. The caveat is for most of the code reviews, I know the code being changed better than the person changing the code.

I'll reply to sections as I come across them: "Given a problem, there are usually a dozen different ways to solve it. Andgiven a solution, there's a million ways to render it as code. As a reviewer, your job isn't to make sure that the code is what you would have written - because it won't be.". I disagree with this. There are many times where code is first written in a (1) Ignorant way (2) Sloppy way (to try to save trivial amounts of work). I agree that the code probably won't be the way the reviewer wrote it, but it is good to comment on how it could have been written. Many times the reviewee isn't familiar (or ignores) with the idiomatic style of a larger bit of code.

"The second major pitfall of review is that people feel obligated to say something.". It's fine to say something, but if that's what you say most of the time then you are wasting the reviewee's time. If you do a first pass and don't find anything, you should go back and read the code and be sure that you understand it. Most times I've seen people say nothing is that they don't want to know what the new (or changed) code does.

The last section is about speed. For speed there are two types of code reviews, one which is quick, small and fixes something important. Those should only take one round and typically only need the reviewer to ask for tests. Then there is everything else, which includes small and unimportant. For those, it's ok to take more time to start the review, but each iteration should get smaller and faster.

For anyone that's gotten this far, I guess I can say my comments about Mark's blog post are purely bike shedding, but that's something with code reviews, it's ok to say you think the bike shed should be neon pink as long as you don't force the reviewee to paint the bike shed neon pink.

9 July 2011

Stefano Zacchiroli: debconf11 video hardware

And Now For Something Completely Different There are those weird coincidences that flock together and have the power of subverting initial expectations. Something like that has happened to me this week, when I've ended up spending a considerable amount of my IRILL work time (you know, something like 1000% of it) as a Debian Video Team volunteer. Mean as I am, I'm not going to explain the concatenation of coincidences. Suffices to say that most of the video hardware meant to be used at DebConf11 ended up being in my IRILL office. Of course all of it for about 200 kg and 2000 liters was in need of some inventory, packing, and shipment love. Together with Holger, Mehdi, and Etci we have tamed all of it. The following box miscellanea will therefore soon be on its way to Banja Luka:
DebConf11 video hardware
DebConf11 video hardware
As an undesirable side effect, I had to join Bdale's knows more about ATA than he'd like to -club.
Holger opted not to join the club and I really can't blame him.

Wouter Verhelst: Freedom, continued

Okay, so the story continues: Joe Brockmeier has posted a rebuttal to Nina Paley's post that I commented on earlier today. Basically, Joe says that Culture is not the same things as Software, and gives a lot of arguments as to why this would be true. But I can't agree with him. Let's see why. His first argument is "One of these things is not like the other". As in,
But it's far more reasonable and sensible to discuss Perl scripts and software written in assembler embedded on a chip together, and the rights that they come with, than to try to talk about rights to modify sculpture and essays.
I don't see how one could combine a perl script with an embedded assembler program, except perhaps over a network, or by using exec() two cases in which the FSF would consider that they are not even derivatives anymore, they are "at arm's length", and it would be legal to do something like this if one bit was released under the GPL while the other was not. At the same time, it's possible to engrave (part of) an essay into a statue, for example. Or make a technical apparatus which looks like a statue but which will play music if you come near it. Both would be valid cases of some artist combining two separate and (at first sight) distinct things into one work.
Sure, you could crowdsource sculpture, but I doubt it will have much practical application. (And certainly difficult over the Internet, but I digress...)
It's called RepRap, and it's very much possible over the Internet. Joe moves on, with 'Unintended consequences of forkable prose'.
Take the GNU Manifesto, for example. If you could "fork" the manifesto, I could easily see variant versions modified to justify open source instead of free software.
This argument had been brought forward during the discussions which Debian had on the GFDL vote, and has been seriously debunked there. In short: the ability and right to fork someone's prose does not, in any way, give you the right to misrepresent them. While I believe it should be okay for someone to base a theoretical Open Source Manifesto on the GNU Manifesto, I do not believe it should be okay for them to still keep calling it the GNU Manifesto. It's not the same thing anymore, so that should be clear. This is true within Free Software as well: if you fork, you give it a new name, so it becomes clear that you're not the original anymore. Moreover, I doubt the kind of prose found in the GNU Manifesto is the same kind of prose that Nina would like to see in a free culture movement. Not because the GNU Manifesto is a bad piece of writing it isn't but because Free Culture likely focuses on other things than manifestos. Next, we get "Solving a problem that doesn't exist"
The spark that fired off the GNU revolution was a legitimate problem because of non-free code, a user was unable to make use of hardware they (or their university) legitimately owned.
(...)
While Paley and others may want the same freedoms to go with cultural works, it is not a real problem in the same sense.
Pardon ye me? I am a musician. Not a very brilliant one, mind you, but I play the flute with much enthusiasm, and have done so in a number of places. If you've been to any debconf since 2007, surely you must've heard me play. Also, I've been singing in choirs since I was sixteen which, I just realized, means I've now been singing for more than half my lifetime. Time flies, it must be said. One of the orchestra that I've been playing in was an extended flute choir with a rather unusual instrumentarium: apart from 30-something flautists, the orchestra also had a piano and drummer, a number of guitar players, and a bass guitar. Such an unusual set of music means you have three options: you play original music, written specifically for your group; you play something written for a different set of instruments, without changing anything, and hope nobody notices that it doesn't actually sound very well; or you make modifications. You make a derivative work of the music, so you can actually play it. There, I've said the word. This isn't just true for music; I've yet to see the first theatre performance that is true, word-for-word, to the original script. Also, movies use music all the time. When they do, there are usually two options: either they have original pieces of music written specifically for their movie (as is the case for most Hollywood blockbusters), or they take a piece of existing music, and adapt it so it fits the events in the movie better. By, say, shortening it, so it doesn't run into the next scene. Or by repeating the refrain an extra time, so the words line up nicely with the action. Or by having a group of musicians record a version of that piece specifically for your movie, which is the same thing in everything except the speed so that the feet of the actor walking on the big screen hit the ground in sync with the music. Or... well. You get the idea. By claiming that artists have no need to modify and derive from others, the only thing Joe accomplishes is to show that he really, really, really doesn't know what the fuck he's talking about. Artists have a need to modify other artists' works all the time. The only difference with free software is that they either need to invoke the fair use clause, or need to pay big bucks to the original rightsholder. Sound familiar? Joe finishes up with stating that despite all of that, Free Culture is still possible. And:
That doesn't mean that free culture is impossible. It simply means that different standards apply.
Exactly: different standards apply. And why? There is no good reason for that. Because people make money from cultural works? Well, money is made from software, too, that has never been a good enough reason. Because Culture is not functional? How many in the Free Software movement would even be willing to only be doing software all the time, and not ever do anything remotely related to Culture? None, I would say. Culture is just as functional as Software, it just serves different functions. In the comments, Joe clarifies that he isn't against people preferring not to use the ND clause in the CC licenses they select, he's just against demanding that others do the same. That argument would make sense if not for the fact that the FSF demands, mostly, that Software Should Be Free!!1!. By not complaining about the GNU Manifesto, but complaining about Paley's "Rantifesto", which basically complains about the lack of such an environment in the free culture movement, Joe just makes a fool of himself. Anyway, 'nuff said.

Wouter Verhelst: On Software (and Cultural) Freedom

Nina Paley, author/actor/director/animatrist of the excellent sita sings the blues, blogs about the FSF's double standards when it comes to freedom. To the FSF, Software Should Be Free!!1!, and it is willing to go to great lengths to accomplish that. For example, the FSF will create dracionian requirements on their Hardware endorsement criteria, that will most likely render it unusable, just for the remote possibility that they might convert a single soul to their religion. They will add propaganda to their documentation, and slap on a license that makes it illegal for anyone to modify or remove that propaganda. They will claim to make an update to that license, just to make their friends happy, but then do not make any effort to finish the job. Most of all, the FSF is led by a person who deserves our respect for jumpstarting a movement that has made all this free software even possible, but whose atypical behaviour might be interfering with his message these days. I have stated before that I'm not a member of the FSF, and that 'I have my reasons'. In case you were wondering: the above are my reasons. I can't be a member of, or be supporting of, any organization that uses such double standards in anything. In the case of Debian, it took us a long time to come to the conclusion that the GNU FDL is a non-free license. And though we came to that conclusion through other arguments than "Culture should be free, too" (specifically, the arguments boiled down to "if it's digital, it's software, and software should be free"), I have since come to the conclusion that there is nothing special about 'digital stuff' that should mean it should be more free than 'non-digital stuff'. If I hand you a piece of music on a sheet of paper, why should you not have the right to redistribute and/or modify that, while you should have the exact same right if I were to hand you the exact same paper on a digital medium? That makes no sense. So, in short, I agree with you, Nina: there is no Free Culture movement, and that's a shame; and while it would be nice if the FSF were to take a lead role in guiding such a movement, I find it highly unlikely that they will. The FSF may claim they care about Freedom, that doesn't mean they do; they care about Software Freedom. And while that certainly was an issue thirty years ago, when the FSF was formed, it isn't so much anymore today. There can only be one conclusion: the FSF is obsolete.

Wouter Verhelst: CUPS: ghaaah!

So I have a postscript color printer. This is nice, because I can just throw postscript at it, and it will provide me with a hardcopy of whatever that postscript describes. Since postscript is what Unix-like systems like most, that's great. Today, I needed to print something. It had been a while, and apparently some things in sid that are related to printing had changed, because it did not work anymore. I don't print every day (I absolutely don't print every day), so it had been, well, "a fair while" since I last used it. Of course it didn't work. Of course, it is not the first time this happens. Every so often, my printer loses track with the cups installation on my server, and then I have to prod it a bit usually by restarting the printer or the CUPS server, or both and then it works again. The usual CUPS failure mode is that the printer was not available when I tried to print something, which causes CUPS to mark the printer as 'offline' or something, resulting in it being 'disabled'. The 'cupsenable' command is supposed to fix this, except that once in a blue moon it doesn't. I've learned to live with it. But today was different. Rather than the printer being disabled, something in the printer stack would just discard print jobs. That is, they would show up in the cups queue for a moment, and then disappear. I wouldn't get a piece of paper with something useful on it. I would just get nothing at all. This featureful printer supports syslog, and so I told it to send syslog messages to a useful system somewhere on the network. But that didn't produce anything interesting. It would tell me when the system had been powercycled, sure, but not why something would fail. After trying many things for about an hour, sick of it all, I purged CUPS off my system and reinstalled it, then had it search for a printer again. It did find the printer through zeroconf messages, and I allowed the autoconfiguration stuff do things as it saw fit. When I asked it to print the exact same postscript file again, something came out of the printer. Finally, I thought, "success"! Except it wasn't. Instead, the printer just produced gibberish. It turned out that cups had decided that my HP 2550n network-enabled postscript laserprinter was instead a HP 9xx-something USB-only PCL printer. Going back to the configuration interface and telling it to use the 2550n ppd file instead got me back to square one: the print job would appear in the print queue for a few seconds, then magically disappear. At this point I was using 'tail -F' to monitor any logfile that might remotely be related. /var/log/cups/*, /var/log/syslog, /var/log/daemon.log, you name it. But nothing gave me any remote clue what was happening with the postscript that I'd been throwing at cups. So I used netcat. This printer supports LPR, but will also accept postscript on port 9100 (I forgot what HP calls it), so a simple 'nc printer 9100 < foo.ps' should in theory just produce a printed page. And since someone told me that a "modern" (yeah, right) Linux printing system uses pdf throughout rather than postscript (for what, I don't know), I thought it might've been possible that something somewhere was just mangling the postscript in a way that things would not work anymore. I was right, ut I never expected to e right in this manner.

Did you think this would be listed in the cups logs somewhere? Of
course not! That would be too easy!
But then of course fixing this was fairly easy: just throw the
original file from which this postscript was generated through a
different postscript-generating program, and try again. Magic: suddenly
the printer prints what I want! And it only took me 90 minutes.
Sometimes I wonder what the "userfriendly" police is smoking. Oh
well. 
 

8 July 2011

Joey Hess: thoughts on the last shuttle launch

I watched the final shuttle launch this morning; for several years I've tried to catch shuttle events, knowing it would soon be over, but before that the shuttle had faded into the background for me as it did for so many of us. It was an impractical rocket to nowhere that we mostly only paid attention to when it blew up. Fourteen years ago today, Debian was flying in space aboard Columbia. According to the press release, it ran on an SSD on an embedded 486 in the lab module, and controlled plant watering, telemetry, and video. At the time, I had just become a Debian developer, and was very impressed to be part of a project that was involved in that. It was early days for Debian, and near the midpoint of the shuttle's thirty years. Now it seems likely that Debian, or its derivatives (or at least Free Software) will easily outlast that thirty year run, but I do wonder to what extent our work will fade into the background (and what interesting ways it will find to explode) over that time span and beyond. We'd say we have better methods than the centralized, committee-driven, top-down, PR-conscious NASA... impressive though it can be at its best. We have dreams just as noble as the ones behind the space program, but also goals that are more adaptable, equally at home flying in space, or emebdded in some pocket-lint laden artifact of a perhaps more contemporary inward turn.

Steve McIntyre: Farewell to the Space Shuttle

I agree with Julien - it's a crying shame to see the Space Shuttle finished. There's a lot of people bemoaning lack of progress elsewhere too, for example at http://abstrusegoose.com/377.

DebConf team: DebConf11 preliminary schedule available (Posted by Talks team)

We are happy to announce that the preliminary schedule for the upcoming DebConf11 is available! As usual, it is still possible that more changes will occur, though we don t expect anything major. DebConf11 talks will mostly happen in two rooms simultaneously, except for a few plenaries which will be presented in the main room with no parallel event. We ve tried to cluster related talks/BoFs in sequence, even though it was not always possible. Besides that there will be tracks covering specific topics, which are: As in previous years, we provide many ways to access the schedule: the DebConf team

Julien Blache: Farewell, Space Shuttle Program

Well, today was the day and I ve just watched the last ever Space Shuttle launch. Let s just say there s something very, very wrong with this world and leave it at that. Hats off to all the men and women who dedicated their lives or part thereof to these magnificent birds over the past 30+ years, from the original design studies back in the days to the transition & retirement operations that will last for a year still. We ll most probably never get to see any other machine pushing boundaries like the Shuttle has done, and this is a gigantic loss for us all. One day people will realize If you aren t familiar with the challenges faced by the Shuttle, with the advances in science and countless engineering disciplines brought by Shuttle and more generally with Shuttle and facts about the Shuttle, go read Wings in Orbit; a book by the people who built and operated the Space Shuttle, available freely in PDF format from NASA. Did you know that the Space Shuttle Main Engines (SSME, RS-25) are the most powerful, most efficient engines ever built? They were designed 40 years ago. I won t make a list, but this is true of a number of other components. What the hell have we been doing all these years?

Russell Coker: Multiple Filesystems for Security

There is always been an ongoing debate about how to assign disk space into multiple partitions. I think that nowadays the best thing to do is to assign about 10G for the root filesystem for every desktop and server system because 10G is a small fraction of the disk space available (even the smallest laptops seem to all have disks larger than 100G nowadays). Even if 10G turns out not to be enough using separate filesystems for /var or /usr provides little benefit now that it s easy to resize the root filesystem with LVM and a separate /usr is known to be broken [1]. In a discussion on a private mailing list there was a suggestion that multiple filesystems should be used for security. DoS Attacks There are some minor security benefits in having multiple filesystems. If a critical program will fail when there is no free disk space then allowing an unprivileged process to use up all the space on that filesystem is a minor security issue, so having unprivileged processes not being permitted to write to important filesystems is a benefit. But most failures of this type are merely DoS attacks which usually aren t a big deal if you can control a local process there are usually lots of other ways of DoSing a system. Links Links have been the cause of many security issues in Unix over the years. Using different filesystems for different tasks can prevent the use of hard links in attacks aimed at exploiting race conditions. But even if you prevent hard links there are similar issues with symbolic links. SE Linux is one of many security improvements for Linux which allow restrictions on the creation of hard links. SE Linux also allows restricting the ability of processes to follow symbolic links, so a privileged process can be denied access to follow a sym-link that was created by an unprivileged process. NFS The subtree_check option in /etc/exports causes the NFS server to verify that file access is in the correct subtree. So if you export only one subdirectory of a filesystem to a given server then hostile code on that server (or on a network device which impersonates that server) can t access other subdirectories. This option is documented as having performance implications and working best for filesystems that are mostly read-only, for this reason it s turned off by default in recent versions of the NFS utilities. So if you want to NFS export /home then it s probably a good idea to have /home be on a separate filesystem to prevent attacks on the root filesystem. But of the systems with significant use of /home (IE anything other than accounts used solely for su - ) most of them have a separate filesystem for /home anyway so this shouldn t be an issue. SE Linux When mounting filesystems with SE Linux there is a context= mount option that allows specifying the context for all files on the filesystem. This can save a small amount of storage space for XATTRs and theoretically improve performance (although the difference is unlikely to show up on benchmarks for anything other than fsck). Generally the context mount option is only used for a filesystem that has a huge number of files with the same context, such as a mail spool that uses Maildir, Cyrus, or any of the other formats that involve one file per message. But again such data is generally stored on a separate filesystem for other reasons anyway. I found one interesting corner case in regard to SE Linux systems mounting files from an NFS server. When an NFS server exports multiple subdirectories of a filesystem mounted on /foo then if one NFS client running SE Linux is to mount two subdirectories of /foo with different contexts then the second mount attempt will give the error an incorrect mount option was specified . This is because as of kernel 2.6.18 by default it s not permitted to mount parts of the same filesystem with different mount options. The option nosharecache allows you to use different mount options, but does apparently permit some undesirable behavior in the case of hard links that cross between the subtrees. Thanks to Eric Paris for the tip about nosharecache. The best example I can think of for which you might want context mount options that differ among files that are used for the same purpose on an NFS mount is a web server which has data files and CGI-BIN scripts. So it seems that a SE Linux web server that mounts it s data over NFS and is at risk of having hard links between the CGI-BIN directory and the data directory is a corner case in which multiple filesystems is required for security. This seems to be a very unlikely case. Conclusion Servers that are deployed in the real world are complex enough that there are always systems with some unusual corner cases demanding configuration choices that aren t expected. There are some real corner cases for SE Linux where multiple filesystems are compelled for security or for a combination of security and best performance. But I wouldn t make a generic recommendation of using lots of filesystems for security. I think that the people who encounter the strange corner cases can usually work out that they need to do something different. So a small number of filesystems seems like a good general aim that doesn t conflict with security.

7 July 2011

Joerg Jaspert: Life is like chocolate - if you don't try it, you don't know it

So lets try this: DSC02384.JPG DSC02385.JPG

Lars Wirzenius: Instapaper versus MAFF

I recently heard about Instapaper on the Stack Exchange podcast. It's a service that makes it easy (they say) to save web pages for reading later, possibly on another machine or device. I've been doing that for some years now, using the "File/Save" feature in my browser. Last year, this became lots better, when I found the MAFF add-on to Firefox. MAFF saves the page, and any images it includes, in a zipped file, which can later be viewed directly in Firefox. Or Iceweasel, in my case. It's much handier to have everything in one file, rather than a foo.html file plus a foo_files/ directory, which is what Firefox usually saves as. This does not make it possible to, for example, read the page on my phone, since I've saved the file on my laptop, but I can live with that. However, the complete autonomy of this solution is much to my liking. I have a "read and review" folder for things I need to read. After I'm done with something, I can easily delete it. If I want to keep it permanently, I can move it to an archive folder. I haven't got a solution for full text searching through my growing archive of MAFF files, but I'll figure that out some day, too, I'm sure.

Matthew Palmer: Honest Achmed is my CA of Choice

It s not often that you get clarity and transparency from a Certificate Authority, so it s good to see that Honest Achmed has requested his CA root certificate be included in Firefox. Really, how can you not trust a guy whose name is Honest Achmed , and who has such a strong and clear-cut verification statement:
Honest Achmed promises to studiously verify that payment from anyone requesting a certificate clears before issuing it (except for his uncles, who are good for credit). Achmed guarantees that no certificate will be issued without payment having been received, as per the old latin proverb nil certificati sine lucre .
His response to Mozilla s CA Recommended Practices is forthright and trustworthy, too:
Honest Achmed promises to abide by these practices. If he s found not to abide by them, he ll claim it was a one-off slip-up in procedures and that policies have been changed to ensure that it doesn t happen again. If it does happen again, he ll blame it on one of his uncles or maybe his cousin, who still owes him some money for getting the car fixed.
I m getting all my SSL certificates from Honest Achmed. He can t be any worse than Comodo

Dirk Eddelbuettel: Rcpp 0.9.5

A maintenance release version 0.9.5 of Rcpp is now on CRAN and in Debian. This release comprises a number of minor fixes, extensions as well as small additions to the documentation and examples which have accumulated since the last release in April. The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.
0.9.5   2011-07-05
    o   New Rcpp-FAQ examples on using the plugin maker for inline's
        cxxfunction(), and on setting row and column names for matrices
        
    o   New sugar functions: mean, var, sd
    o   Minor correction and extension to STL documentation in Rcpp-quickref
    o   wrap() is now resilient to NULL pointers passed as in const char *
    
    o   loadRcppModules() gains a "direct" argument to expose the module instead
        of exposing what is inside it
    o   Suppress a spurious warning from R CMD check on packages created with
        Rcpp.package.skeleton(..., module=TRUE)
    o   Some fixes and improvements for Rcpp sugar function 'rlnorm()'
    o   Beginnings of new example using OpenMP and recognising user interrupts
Thanks to CRANberries, there is also a diff to the previous release 0.9.4:
 ChangeLog                                                 74
 DESCRIPTION                                               10
 R/00_classes.R                                             3
 R/Module.R                                                16
 R/loadRcppModules.R                                       10
 R/populate.R                                              10
 R/tools.R                                                 13
 R/zzz.R                                                    3
 cleanup                                                    2
 inst/NEWS                                                 21
 inst/doc/Rcpp-FAQ.pdf                                  binary
 inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                            62
 inst/doc/Rcpp-extending.pdf                            binary
 inst/doc/Rcpp-introduction.pdf                         binary
 inst/doc/Rcpp-modules.pdf                              binary
 inst/doc/Rcpp-modules/Rcpp-modules.Rnw                     7
 inst/doc/Rcpp-package.pdf                              binary
 inst/doc/Rcpp-quickref.pdf                             binary
 inst/doc/Rcpp-quickref/Rcpp-quickref.Rnw                  59
 inst/doc/Rcpp-sugar.pdf                                binary
 inst/doc/Rcpp-unitTests.pdf                            binary
 inst/doc/Rcpp.bib                                          4
 inst/doc/unitTests-results/Rcpp-unitTests.html            18
 inst/doc/unitTests-results/Rcpp-unitTests.txt             49
 inst/examples/OpenMP                                   only
 inst/include/Rcpp/Module.h                                33
 inst/include/Rcpp/config.h                                 2
 inst/include/Rcpp/internal/wrap.h                          5
 inst/include/Rcpp/module/Module_generated_CppMethod.h   2902  +++++++++++++++++-
 inst/include/Rcpp/stats/random/rlnorm.h                   14
 inst/include/Rcpp/stats/random/rnorm.h                     4
 inst/include/Rcpp/sugar/functions/functions.h              3
 inst/include/Rcpp/sugar/functions/mean.h               only
 inst/include/Rcpp/sugar/functions/sd.h                 only
 inst/include/Rcpp/sugar/functions/sum.h                    4
 inst/include/Rcpp/sugar/functions/var.h                only
 inst/include/Rcpp/vector/Vector.h                          4
 inst/skeleton/zzz.R                                        1
 inst/unitTests/runit.wrap.R                               25
 man/CppClass-class.Rd                                      2
 man/loadRcppModules.Rd                                     6
 src/Module.cpp                                             1
 42 files changed, 3252 insertions(+), 115 deletions(-)
As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

6 July 2011

Lars Wirzenius: My first t-shirt design

My partner opened up a Cafepress shop, for her Bully Factory movie (in progress). I made a design myself, also available as a white t-shirt. This might be fun to do more of, even if Cafepress's prices seem high. (Haven't got my hoodie yet, so can't say anything about the quality so far, but the bag we got seems good.)

Next.

Previous.