Search Results: "will"

30 March 2009

Erich Schubert: Google Summer of Code 2009

Just a short reminder that the application phase for the Google Summer of Code 2009 is running.GSoC 2009 logoSo far, we have quite few applications. Deadline is April 3rd, 19:00 UTC. Usually applications arrive rather late, but still I have the impression that we have much less than the previous years. But less copy & paste, too.If you are interested in doing a GSoC project at Debian: I hope to see more applications - and good luck that we get enough slots for all of you!P.S. as far as I can tell, current Debian Developers can be eligible as well, although it has also always been a goal of the project to get new contributors involved.

Biella Coleman: Pure Data: FM Sprint in NYC and Berlin

FLOSS Manuals is proud to announce a three day book sprint for the Pure
Data FLOSS Manual. This sprint will take place simultaneously in New
York City and Berlin from Saturday 4 April to Monday 6 April. The Pure Data FLOSS Manual: http://en.flossmanuals.net/puredata There are possibilities to participate in person by coming to one of the
locations below, or remotely via the IRC interface built into the FLOSS
Manuals editing interface. Video conferencing may take place between the
venues as well. To participate, create a login at the PD FLOSS Manuals page: http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introduction&skin=floss2 Discussion may also take place in the Pure Data mailing list: http://lists.puredata.info/listinfo/pd-list If you are in New York or Berlin, please join us at these locations! NEW YORK CITY * Contact: Hans-Christoph Steiner: hans@eds.org 718 360 4872 * Location (bring ID, you ll need to sign in): ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872 * Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm (if we go later, we ll be in a different room) BERLIN * Contacts Derek Holzer: derek@umatic.nl +49 176 2812 5845
Adam Hyde: adam@flossmanuals.net +49 15 2230 54563 NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52 * Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late
SOME BASIC GUIDELINES: * This manual should address the widest possible user-base. Therefore,
objects which are cross-platform and in Pd Extended should have priority
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn t
always translate well! ;-)
* Our readers are assumed to have little to no background in either
computer programming or digital signal processing, which much of the
existing documentation takes for granted. That s why this manual is
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you
use it, and direct the reader to appropriate other chapters/manuals when
necessary.
* Please enter any new technical terms in the Glossary (we need to agree
on global format for glossary terms!).
* Screenshots:
Resolution? (Adam and I will work on this on Monday)
Please upload any complex patches, and make sure to label screenshot
with appropriate filename (see Audio Tutorials for examples)
Please keep explanatory text in the manual rather than only in the
screenshot, so that it can be text-searched by readers.
Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer & Adam Hyde. Your
contributions will only be visible in the editing section until they
meet these guidelines, and after that they can be published to the main
page. Please let us know when your chapter(s) are ready for publishing
and we ll look them over. EXISTING CHAPTERS WHICH NEED HELP: # DataflowTutorials this section needs a lot of help in terms of style and content!!!!!
Tone is very informal, which doesn t help convey the information.
give titles to screenshots so that readers can tell which patches
match which images (some do this, some don t )
Math : examples/discussion of [expr]???
Order of connecting and [trigger] : explain the patches in-line,
rather than only in comments in screenshots (so that text is searchable,
copy/pasteable..)
Luka s screencaps are very aliased, to the point where you can t read
the ~ in the object names. Should they be redone at new resolution or
with antialiasing?
Possible janitors: Derek Holzer, Adam Hyde # PureGlossary format of object names = [italics in square brackets], must be
formatted correctly
format of glossary words in general text: we don t have one yet. Bold
on first use in chapter maybe? Needs formatting all through text. # ListofObjects incomplete, please add more libs
maybe more discussion of externals needed as well
formatting of object names? # PureLinks always welcome MORE CHAPTERS/SECTIONS TO DO (+ suggestions?): * GEM (in order of importance)(Derek can provide example patches for
much of this)
Basic VJ mixer (2 x
[gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with
an alpha-crossfader)(+ platform specific codec info)
Live camera input (same as VJ mixer but with [pix_video], with
platform specific info on USB/firewire inputs what works & what doesn t)
VJ effects (using the various pix objects)
Basic 3D (that actually does something interesting, rather than just
show a sphere or a cube)
Basic movement tracking w/ [pix_blob]
GEM/video optimization/troubleshooting tips (see Troubleshooting
section of existing Pd FLOSS Manual) * MIDI tutorial
hardware:keyboards, sliders, etc,
objects: all MIDI objects
routing: input + output to/from devices or other programs * Patching strategies
Reusable abstractions ($0 etc)
GoP + other GUI creation strategies
Preset saving systems (Frank?) * Audiofile manipulation (Derek can provide examples, possibly also work
with www.pd-tutorial.com with permission?)
sfread, readsf, sfplay, etc
tables + tabplay, tabread, etc
oneshot playback without/with pitch shifting
looping without/with pitchshifting
granulation without/with pitchshifting
Extended objects ([xplay~], [xgroove~] are these stable? In my
experience, no ) * Realtime audio effects tutorial
delays: single tap, multitap, pitch-shifting, tuned comb filter, etc
filters: [hip~], [lop~], [bp~], [moog~], IEM lib filters
[vcf~]/[bp],[hp],[lp], difference between audio signal and message
controlled, building with ggee objects [bandpass],[llowpass],[highpass]
or [biquad~] (resources for coefficients?) * Sensor tutorial (HC?)
[hid]/[hidin]/[pduino]
simple circuit diagrams + photos (voltage divider examples:
potentiometer, photoresistor, etc)(hacked gamepads) * Networked data
netsend/netreceive
OSC
flash server
shell
python externals
others? * PDP/PiDiP
configuration info for OSX (+ poor performance disclaimer!)
basic VJ
networked streaming etc * Procedural Audio tutorial? (Andy?) * RJDJ tutorial? (Frank and the gang?)

Biella Coleman: Events on IP

If you are in the greater or lesser NYC area, there is a conference on IP and circulation that has a pretty nifty line-up as well as a international perspective. If you are in the Montreal area, IP reformer James Love will be giving a talk NGO efforts to reform the World Intellectual Property Organization and there is a semester long series (almost over) sponsored by the Columbia Society Fellows on IP with a fantastic line-up

Russell Coker: Links March 2009

Cory Doctorow has written a column for The Guardian titled You shouldn t have to sell your soul just to download some music [1]. One really interesting point he made was The same companies that spent decades telling lawmakers that they were explicitly not the guardians of the morality of the young that they couldn t be held accountable for sex, drugs and rock n'roll, for gangsta rap, for drug-fuelled dance-parties did a complete reversal and began to beat their chests about the corrupting influence of downloading on the poor kiddies . The pt4me2 organisation advocates that the Victorian government spend more money on public transport infrastructure [2]. Recently the congestion on Melbourne roads has been getting worse, the costs of private car parks in the central city area have been increasing, and during peak hours all public transport is over-crowded. Some significant improvements are needed, and more trains, trams, and buses are the only possible way of coping with the number of people working in the city. Also there s the issue of suburbs that lack any public transport, I wouldn t want to live near one of those areas when petrol hits $8/L (as the CSIRO predicts for 2018). Michael Tiemann writes about Microsoft s latest patent attack against Linux [3]. He doesn t pull any punches which is a very noteworthy thing. It s pretty rare to see someone in a senior position in a company blog in a way that makes any significant comment about another company. Dan Ariely gave an interesting Ted.com talk about Our Buggy Moral Code [4]. One of the points was that people who declare themselves to be atheists are less likely to cheat when asked to swear on a bible first, another was that if someone who is identified as a member of the same group cheats then others will follow, but if an outsider cheats then they won t. It seems that if you want to minimise cheating then you want to have only outsiders be seen to do it, and you want everyone to swear to follow some sort of moral code. Flame has written a good rant titled Anarchy is Dead about the lack of popular outrage against the Australian government s censorship plans [5]. Rolling Stone magazine has a good article about the US banking crisis [6]. A moderate amount of bad language, but no more than is deserved. Amazing video of rounding up sheep that are fitted with LEDs at night [7]. Here s an interesting TED talk by Saul Griffith about using kites to generate electricity [8]. Unfortunately he didn t give much engineering information, it was more of an executive summary of what he has done. He claims that if a wartime level of effort was put in place then wind could supply all the electricity needs of the US within 10 years. Adam Savage (of Mythbusters fame) gave a talk for TED about his obsession with the Dodo [9]. One thing that surprised me is how his manner in that talk differed from his appearance in Mythbusters. It seems that most of his crazy antics in Mythbusters are an act to entertain the audience. The information about the dodo was really interesting too. He then went on to talk about his recreation of the Maltese Falcon. His work can serve as inspiration for other geeks who want to try sculpting.

29 March 2009

Russell Coker: Linux Powered Battle Droids

Flame has written some ideas about building Linux Powered Battle Droids and demonstrating them [1]. It seems to me that the biggest problem with having a battle of a similar nature to Robot Wars [2] is creating a safe arena. Getting an area the size of a basketball court fenced off with bullet-proof plastic is not going to be cheap. The first solution to this problem that occurred to me was to have a battle held underwater. Water really slows down projectiles. The disadvantages of this are that it s slightly more difficult to view. The viewing options are to using a web-cam, having a port-hole in the side of the pool (impossible if you don t own the pool), and having a transparent viewing platform on the surface of the water (which would also be difficult and maybe expensive). Another disadvantage of submarine warfare is that having a droid spring a leak and quietly sink is not very dramatic. It might be a better option to use aerial warfare via helicopters and balloons. The amount of weight that such craft can carry is not particularly great so there will be no real armor and fairly weak weapons. A motorbike helmet and a heavy coat should be all the protective equipment that is needed if the usual rules prohibiting projectile weapons from such contests are implemented. A petrol powered model aeroplane could do some serious damage if it hit someone at full speed. But I don t think that an indoor basketball court or any other enclosed arena that might be available would be large enough for fighter-planes. So it would be just balloons and helicopters.

28 March 2009

Chris Lamb: Orphaning the Gnome BTS Applet

As I haven't used Gnome in over a year, I'm orphaning my Debian BTS Applet (original blog post). After the original release it was forked for Launchpad and there were even plans for OpenSUSE fork. Jon Dowland also released his debgtd tool which isn't Gnome-specific and somewhat more useful for developers, although actual development has stalled with patches pending. I would be willing to sponsor uploads if a non-Debian Developer was to adopt it.

David Welton: Software Economics - Public Goods

To look at the economics of open source software, you have to start with the economics of software as a category, both proprietary and open source. Note: it should be perfectly obvious to everyone that open source software works, and works quite well for some things. This article is more about understanding the how and they why. Just to avoid any confusion... If you look at software as a product, it has a couple of defining characteristics:
  • It's difficult to keep people from sharing it. Not impossible, but not easy, either. It was already doable in the days of floppy disks, but with the rise of the internet, it has become nearly effortless. This means, in terms of economics, that it's "non excludable" - it's difficult to keep everyone from enjoying it once you've created it and started to distribute it.
  • If you give a copy of a program to a friend, it in no way detracts from your own use of the program. Quite the contrary, it may even make your use of it better, if, say, your friend discovers how to use a cool feature, or writes a handy extension. This is different from traditional goods like bicycles. If you loan me your bicycle, you can't use it to get around. In economics, things like software (or radio or over the air TV) are called 'non rivalrous' goods - many people can take advantage of them without ruining them.
What do you get when you combine something that's "non excludable" and "non rivalrous"? In economics, these are known as "public goods": http://en.wikipedia.org/wiki/Public_good - read the whole thing if you have a few minutes, it's what I'll be talking about. As per the article, "The Problem" as it were, is the free rider problem. Let's stop and look at a contrived example: Bob is an ex-dentist and really knows what it would take to write a great program for managing a dentist's office (or pick your own example... it's contrived, don't quibble about the details). He's also a good programmer, with the skills necessary to implement the program. He talks to a few of his dentist friends, and they're enthusiastic about the whole thing. Let's look at a few scenarios of how things might play out: Bob values his time at 10 dollars an hour, and it will take him 100 hours to complete the project, meaning the whole project would cost about 1000 dollars. One way things could work is that he could find a dentist friend who needs this program, and bill him 1000$ for his time and services, bang out the code, and release it as open source software. Bob gets his money, the dentist gets his code... and all the other dentists in town get it for free, which is bound to make the dentist who shelled out the money a bit irritated, given that he's a human, not a homo-economus, and doesn't like paying and see others get the same thing for free. Let's introduce another variable: the software is only really worth 200$ to the dentist - any more than that and yeah, it's helpful, but not worth that much money (And please stay with me, I know it's contrived, but keep in mind that the situation *is* possible, even if the numbers might be different). That means that if Bob wants 1000$ for his time, but the dentist will only pay 200$, then no transaction will occur! The software won't get written, Bob won't get any money, and the dentist will be worse off because he won't have the nice program, and neither will his dentist colleagues. One way things might still work is if the dentist rounds up some friends and they all contribute a bit, however, that's kind of a pain in the neck for everyone concerned - the dentist doesn't want to get into the software business and spend a bunch of time trying to chase his friends for money, and even if 10 dentists contribute, the ideal position to be in his the 11th guy, who pays nothing, and still gets the software for free. So it's in everyone's interests to not return the dentist's calls in the hope of being the 11th guy. Also, none of them gets the software until they're all on board. So, how to resolve this problem? The wikipedia page talks about introducing an exclusion mechanism, which in this case would be a copyright system so that Bob can sell a copy of his software for 100$ and be sure that it won't be open to everyone to use. This way, the dentists get the software for 100$ less than they value it at (200$), and as soon as Bob signs up an 11th dentist, he's making more than his time/materials costs, and is therefore coming out ahead! The dentists all know that they're paying the same price, so have no reason to grumble about free riders. In short, everyone is pretty happy. Of course, in the real world, things don't play out like that all the time. There are problems with the simplified example above, some of which are very evident: the cost of enforcing copyright laws, in an age when copying is extremely easy, is very high and potentially very intrusive. However, "intellectual property" is, by and large, a compromise solution that has had positive aspects, especially when you ignore the outliers like Microsoft, and look at all kinds of niche software vendors, who make a nice living, create good products, and have happy, satisfied customers. If you look at the other solutions to the free rider problem listed on the wikipedia page, we can see how they might be applied to the world of software.
  • Dominant assurance contracts
    Assurance contracts are contracts in which participants make a binding pledge to contribute to a contract for building a public good, contingent on a quorum of a predetermined size being reached. Otherwise their money is refunded. A dominant assurance contract is a variation in which an entrepreneur creates the contract and refunds the initial pledge plus an additional sum of money if the quorum is not reached. In game theory terms this makes pledging to build the public good a dominant strategy: the best move is to pledge to the contract regardless of the actions of others.
    This means that Bob goes out and gets a number of dentists to pledge 100$ to his dentist program, and if he doesn't raise at least 1000$, he'll give them each back 110$. So it's a clever solution that works out for everyone, but is still a lot fiddlier than the copyright system - Bob has to go sell the contracts and explain how things work to a bunch of people before he can get started. This might be doable with 10 dentists, but for a more mass-market sort of program, it would not be feasible.
  • Coasian solution
    a mechanism by which potential beneficiaries of a public good band together and pool their resources based on their willingness to pay to create the public good. Coase (1960) argued that if the transaction costs between potential beneficiaries of a public good are sufficiently low, and it is therefore easy for beneficiaries to find each other and pool their money based on the public good's value to them, then an adequate level of public goods production can occur even under competitive free market conditions.
    That sounds an awful lot like open source software, especially the kind espoused by groups like the Apache Software Foundation, where making free software is not a moral imperative, but a good way of producing something that is not necessarily a key business component. This has proven to work very well for infrastructure type code, as well as lots of developer tools. It is less proven as a way to develop end-user software - in the example above, it's not like Bob needs help to develop his system, or that the dentists really want to contribute - they just want a working program and don't want to get involved in its production.
  • Government provision This would mean that the government would be responsible for funding the production of open source software. I'm no free-market zealot, but I think the idea of the government being responsible for software products is not one I am entirely comfortable with. Of course, I do think the government has a role with places like universities, where people can do "research" in the sense of hacking on cool systems just to see what can be done, without necessarily having to be thinking of how to make a profit in the short to medium term. Software like BSD, Tcl, and plenty of other great stuff has come out of universities, meaning that in part it is ultimately funded by the government and taxes. The problem, though, is the process of refining those things down into something people are willing to buy. Would Bob go to a local government official to get a grant to produce his software? Why should Bob get the contract and not some other guy? Does the government official know enough about code or dentists to determine who should write the program?
  • Subsidies Subsidies might work to encourage software production, but would probably simply be abused. It's probably not as relevant as other potential solutions. What form would it take? 1$ off your taxes per line of code written? It would be difficult to place a value on anything, and might be quite difficult to implement.
  • Privileged group This, as the wikipedia page says, is an incomplete solution, and is less generally applicable. In terms of Bob, it might mean that instead of valuing his code at 200$, his wealthy dentist friend with a large practice really needs the code - it's worth 2000$ to him, and can pay Bob the full 1000$ to develop it out of pocket and still come out ahead, and he doesn't really care that much about the free riders because he's getting what he needs and the rest doesn't matter too much.
  • Social norms If Bob and the dentists live in a small town, and are all good friends, perhaps Bob could still release the software, and even though the other dentists could copy and use it for free, they don't, because they feel an obligation to Bob to help him out for the work he's done. Even though they could take advantage of it for free, they would feel bad about doing so, and so each chip in 100$, which after enough people contribute, is enough to cover Bob's costs. It's likely that anything distributed on a larger scale, however, will see more free-riding, and "please pay!" might not work out. And it's probably fairly distressful for a developer to make that jump, knowing he's at the mercy of other people's good will.
None of these solutions is perfect, and all, including exclusion in the form of intellectual property laws, or simply doing nothing at all, have problems of their own. Due to the very nature of software, this is somewhat inevitable, and the best we can do is come up with good compromises, and continue to reevaluate them as technology and society change (this is something that needs to happen with IP laws, for instance).

Jordi Mallach: An update on GRUB2

Some time ago I wrote about the the state of GRUB2 and a milestone on getting it boot my Apple PowerBook G4 without manual intervention. More than a year later, GRUB2 has changed and improved a lot, as the community keeps growing and patches and ideas are continously being posted. Some months and commits after my previous post, GRUB broke again on Apple OpenFirmware and I'd get dropped to OF console, the amount of commits since the last known working version and the current SVN was quite big, and although I was able to narrow it to a few suspicious changes, I had no time to bisect it properly, and sadly I had to go back to yaboot for a while. But procrastinating sometimes helps, and when I should have been writing and studying, on December I gave GRUB a new try on my laptop to see if a few important changes to memory allocation would have changed anything. And it did! So after fighting quite a few problems, I was able to report partial success to grub-devel. Again, getting GRUB installed correctly was a bit challenging and needed some hackery, due to incorrectly generated device.map, and the linux module mysteriously not getting loaded. Luckily, Michel D nzer found out that this was due to a bug in sort ordering in the HFS module, which broke the lookup of files with underscores like _linux.mod, and for which he posted a possible fix by taking Linux's table of character ordering, which is a blob of hex values. GRUB developers didn't seem too happy about applying the patch: they argument that a blob like that should be well documented or written in some other more readable way, and there's a possible problem with the mix of Linux GPLv2 and GRUB GPLv3+ codebases, if a table of data like what Michel posted is actually copyrightable. The discussion ended up dying and nothing was done... until Pavel Roskin picked it up weeks later and posted a new patch, based on hfsutils GPLv2+ code, which addressed these issues. The new patch seems to have a few issues, which makes it fail as before, but hopefully it'll be fixed soon. Additionally, I wasn't able to boot using UUIDs as the search commands fails to detect the correct boot device on my system (but not on Michel's), so I had to disable that in /etc/default/grub. To workaround the linux module loading bug while the patch is fixed, I just added this ugly hack to /etc/grub.d/09_local_prelinux:
#! /bin/sh -e
# Work-around for bugs in the hfs module which makes the load of
# linux.mod fail.
cat << EOF
insmod (hd,3)/usr/lib/grub/powerpc-ieee1275/_linux.mod
insmod linux
EOF
This is enough to get the initrd and linux commands available. However, update-grub will still add search commands to your menu entries even if you disabled UUID support; I can't understand why, but I know it breaks on my PowerBook due to some OF rarety. Just removing the line from the menu entry will leave me with a working config that boots without any manual editing at GRUB prompt. The latest GRUB snapshot in Debian fixes the device.map issue, but adds one last issue: update-grub will fail due to some gfxterm detection code, a workaround is to replace an exit 1 with exit 0 when this happens in /etc/grub.d/00_header. On the weird architectures front, it's worth noting that this month Dave Miller popped up on the list and started posting patches to fix the rotten SPARC port, and I think it's safe to assume that it'll be on an usable state really soon. Impressive!

Sean Finney: quoting and escaping positional parameters, redux

after all, what could be more exciting? okay, so where we last left off, we had something like:
    # escape any single quotes in an argument
    quote() 
      echo "$1"   sed -e "s,','\\\\'',g"
     
    # save up a properly quoted/escaped version of "$@"
    for arg in "$@"; do
      saved="$ saved:+$saved  '$(quote "$arg")'"
    done

i got some really interesting feedback from a few people; Lo c Minier who has some similar code that he cuts and pastes on an as-needed basis, and Ralf Wildenhues who has overseen some similar code that exists in the autoconf system. a notable feature in Lo c's solution was to quote the string entirely within the escaping function, whereas in mine the result was a "quotable" string (i.e. the quotes were put around the output afterwards).
> escape()  
>     echo "$*"   sed "s/'/'\"'\"'/g; s/.*/'&'/"
>  

Ralf pointed out one potential problem with both of these approaches. on the topic of portability, there are some implementations of echo that will directly interpret control characters ('\n', '\t', etc) and others not. he suggested that "printf" be used instead:
- echo "$1"   sed -e "s,','\\\\'',g"
+ printf '%s\n' "$1"   sed -e "s,','\\\\'',g"

though there's no reason i can think of not to take that a bit further and use a herestring, which could save an extra fork if printf isn't a builtin:
    quote() 
      sed -e "s,','\\\\'',g" << EOF
    $1
    EOF
     

also, Ralf suggested in the interest of efficiency that some kind of case statement be used to avoid unnecessary forks when an argument doesn't contain any "'" characters. this is apparently a trick used in autoconf-generated scripts:
    case "$arg" in
    *\'*)
      saved="$ saved:+$saved  '$(quote "$arg")'"
      ;;
    *)
      saved="$ saved:+$saved  '$arg'"
      ;;
    esac

finally, a lingering problem which hasn't been solved on the autoconf side of things (nor in my previous solution) was that in the case that an argument contained trailing newlines, such whitespace would be silently discarded in the quoted version (this is due to how shell command substitution works in general). but really, this is quite the corner case... how often does one run a command line with both an escaped quote and trailing newlines in an argument? an example:
rangda[/home/sean] ./good.sh "isn't very common" "to give args" "with trailing \\n's:
"
original command line, 3 arguments: isn't very common to give args with trailing \n's:
arg: isn't very common
arg: to give args
arg: with trailing \n's:
mangled command line, 0 arguments:
restored command line, 3 arguments: isn't very common to give args with trailing \n's:
arg: isn't very common
arg: to give args
arg: with trailing \n's:
rangda[/home/sean]                                                           :)

however, i noticed that a slightly modified version of Lo c's approach might not suffer from this problem because the string would be quoted before being returned (thus any newlines would be enclosed in quotes that would preserve them). I mentioned this to Ralf who will be bringing it up on the autoconf-patches mailing list... sounds promising anyway. so i give you the combined improved version:
#!/bin/sh -e
# escape any single quotes in an argument and then quote it
quote() 
  sed -e "s,','\\\\'',g; 1s,^,',; \$s,\$,',;" << EOF
$1
EOF
 
# save up a properly quoted/escaped version of "$@"
for arg in "$@"; do
  case "$arg" in
  # when a string contains a "'" we have to escape it
  *\'*)
    saved="$ saved:+$saved  $(quote "$arg")"
    ;;
  # otherwise just quote the variable
  *)
    saved="$ saved:+$saved  '$arg'"
    ;;
  esac
done
echo original command line, $# arguments: "$@"
while test -n "$*"; do echo arg: "$1"; shift; done
echo mangled command line, $# arguments: "$@"
# restore the cmdline
eval set -- "$saved"
echo restored command line, $# arguments: "$@"
while test -n "$*"; do echo arg: "$1"; shift; done

output from the same example cmdline:
rangda[/home/sean] ./better.sh "isn't very common" "to give args" "with trailing \\n's:
"
original command line, 3 arguments: isn't very common to give args with trailing \n's:
arg: isn't very common
arg: to give args
arg: with trailing \n's:
mangled command line, 0 arguments:
restored command line, 3 arguments: isn't very common to give args with trailing \n's:
arg: isn't very common
arg: to give args
arg: with trailing \n's:
rangda[/home/sean]                                                           :)

27 March 2009

David Welton: CodingHorror and Open Source Economics

Jeff Atwood writes about the economics of open source software: http://www.codinghorror.com/blog/archives/001247.html Well, he actually doesn't say as much, but that's what it's about. Someone really ought to do a book about this subject. I have some ideas - any takers? It's always tough to write about because there's so much material. It's a topic that is near and dear to my heart - almost 10 years ago, I joined the Free Software Business mailing list, as I got curious about the intersection of free software and business, and how the whole thing worked. I've learned a lot in the meantime, including a stint at Linuxcare, which was one of the Linux companies during the dot com boom, and am still fascinated by the subject. Before we get started, let's reiterate something:
  • It's clear that open source software works. There's just no doubt about it - it's been through ups and downs, the dot com boom and bust, and it will trundle happily (well, as happy as anyone is with this economy) through the recession too.
That point bears repeating. Everything else needs to take it into consideration. Could it work better? Differently? Perhaps, but it does work, so you need to understand it very well before you fiddle with it. Jeff writes:
for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that? Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you.
Which is of course a terrible analysis of open source, and its pros and cons. I wrote the following comment on Hacker News:
Heck, how realistic is this for the average programmer? ...
"Actually, I have submitted lots of (mostly small and inconsequential) bugs and minor features over the years, to projects such as the Linux Kernel, Tcl, Erlang, Ruby, Rails, Apache, and probably lots of others I'm forgetting right now. I actually enjoy it quite a bit, come to think of it - there's something cool about diving in and studying something new and different, and a thrill that comes with nailing the bug. Sometimes, the knowledge required to actually fix it is too much, and you have to settle for sending in a good bug report, but in other cases it's very much possible to hack up quick, useful things despite not knowing much about the system in question. And, no, I'm not really that great a programmer... I'd consider myself fairly average." And I know I'm not alone, as I see similar sorts of people in Debian and the Apache Software Foundation. Debian, infact, is all about those kinds of tweaks to improve the operating system as a whole. And this sort of exchange goes on all the time, as evidenced by the huge success of a large number of open source projects. Now, granted, most projects are really driven by one or a few really committed hackers, who do the lion's share of the work. However, that large network of people who contribute, test, document, and suggest is certainly important to any open source project. As long as we're looking at my anecdote, let's look at it in a bit more depth - most of those projects are developer tools or closely related. A cynic might note that Jeff comes from the world of Microsoft, where the core developer tools are provided by a company and 'giving back' is limited to payments and bug reports. But leaving that be, I think the enormous success of stuff like Ruby, Perl, PHP, Python, Tcl, Apache, Linux, GCC, and on and on and on indicates that, at least in terms of stuff that developers share between one another, open source works. However, there are problems, one of which is that he (or, in unfortunately rather rarer cases, she) who writes the code does not necessarily get the money. And without money, he or she who writes the code must dedicate themselves to some means to actually accumulate a bit of money in order to pay for living expenses. Most likely, this is time taken away from the open source project, which is a loss for all the people who benefit from it. Proprietary software solves this feedback loop in a neater way (generally) - companies that create good products get money for their efforts, which can then be reinvested in development. Jeff suggests that "sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project.", which is ok as far as it goes, and more or less works here and there, but hopefully he's not thinking about trying it on a larger scale. This sort of thing has been tried before, and never really seems to take off. Part of the problem is that it can work on a person-to-person basis, but is almost impossible to standardize in a way that it makes sense to have some kind of clearinghouse that operates as a business. There are simply too many factors - what kind of open source project it is, what motivates the people behind it, how the transaction costs of defining a specification, monitoring the results, sending money and so on compare to the actual value of a fix... the list goes on. Ultimately, it's a nice idea, but it doesn't seem to work out too well in practice. Anyway, while it's a good thought on Jeff's part, at the end of the day, it is fairly evident that he doesn't have a lot of first hand knowledge of open source business and economics. That said, to some degree, open source took everyone by surprise, and, lacking the nice, simple feedback loop that proprietary software has, can be a lot more difficult to get a handle on. I find it quite pleasant that way - it attracts both hard-headed business types and social-experiment idealist visionaries; both huge corporations (IBM!) and a huge number of individuals; both people who have gotten quite wealthy from open source as well as most of the rest of us who manage to make ends meet but still love it. It's not something that's easy to pigeonhole, and as such it's hard enough to figure out the many ways in which it does work, let alone figure out how to improve on it. Stay tuned for further installments: Software Economics - Public Goods

David Welton: CodingHorror and Open Source Economics

Jeff Atwood writes about the economics of open source software: http://www.codinghorror.com/blog/archives/001247.html Well, he actually doesn't say as much, but that's what it's about. Someone really ought to do a book about this subject. I have some ideas - any takers? It's always tough to write about because there's so much material. It's a topic that is near and dear to my heart - almost 10 years ago, I joined the Free Software Business mailing list, as I got curious about the intersection of free software and business, and how the whole thing worked. I've learned a lot in the meantime, including a stint at Linuxcare, which was one of the Linux companies during the dot com boom, and am still fascinated by the subject. Before we get started, let's reiterate something:
  • It's clear that open source software works. There's just no doubt about it - it's been through ups and downs, the dot com boom and bust, and it will trundle happily (well, as happy as anyone is with this economy) through the recession too.
That point bears repeating. Everything else needs to take it into consideration. Could it work better? Differently? Perhaps, but it does work, so you need to understand it very well before you fiddle with it. Jeff writes:
for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that? Sometimes, when people say this:
The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?
They're really saying this:
F**k you.
Which is of course a terrible analysis of open source, and its pros and cons. I wrote the following comment on Hacker News:
Heck, how realistic is this for the average programmer? ...
"Actually, I have submitted lots of (mostly small and inconsequential) bugs and minor features over the years, to projects such as the Linux Kernel, Tcl, Erlang, Ruby, Rails, Apache, and probably lots of others I'm forgetting right now. I actually enjoy it quite a bit, come to think of it - there's something cool about diving in and studying something new and different, and a thrill that comes with nailing the bug. Sometimes, the knowledge required to actually fix it is too much, and you have to settle for sending in a good bug report, but in other cases it's very much possible to hack up quick, useful things despite not knowing much about the system in question. And, no, I'm not really that great a programmer... I'd consider myself fairly average." And I know I'm not alone, as I see similar sorts of people in Debian and the Apache Software Foundation. Debian, infact, is all about those kinds of tweaks to improve the operating system as a whole. And this sort of exchange goes on all the time, as evidenced by the huge success of a large number of open source projects. Now, granted, most projects are really driven by one or a few really committed hackers, who do the lion's share of the work. However, that large network of people who contribute, test, document, and suggest is certainly important to any open source project. As long as we're looking at my anecdote, let's look at it in a bit more depth - most of those projects are developer tools or closely related. A cynic might note that Jeff comes from the world of Microsoft, where the core developer tools are provided by a company and 'giving back' is limited to payments and bug reports. But leaving that be, I think the enormous success of stuff like Ruby, Perl, PHP, Python, Tcl, Apache, Linux, GCC, and on and on and on indicates that, at least in terms of stuff that developers share between one another, open source works. However, there are problems, one of which is that he (or, in unfortunately rather rarer cases, she) who writes the code does not necessarily get the money. And without money, he or she who writes the code must dedicate themselves to some means to actually accumulate a bit of money in order to pay for living expenses. Most likely, this is time taken away from the open source project, which is a loss for all the people who benefit from it. Proprietary software solves this feedback loop in a neater way (generally) - companies that create good products get money for their efforts, which can then be reinvested in development. Jeff suggests that "sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project.", which is ok as far as it goes, and more or less works here and there, but hopefully he's not thinking about trying it on a larger scale. This sort of thing has been tried before, and never really seems to take off. Part of the problem is that it can work on a person-to-person basis, but is almost impossible to standardize in a way that it makes sense to have some kind of clearinghouse that operates as a business. There are simply too many factors - what kind of open source project it is, what motivates the people behind it, how the transaction costs of defining a specification, monitoring the results, sending money and so on compare to the actual value of a fix... the list goes on. Ultimately, it's a nice idea, but it doesn't seem to work out too well in practice. Anyway, while it's a good thought on Jeff's part, at the end of the day, it is fairly evident that he doesn't have a lot of first hand knowledge of open source business and economics. That said, to some degree, open source took everyone by surprise, and, lacking the nice, simple feedback loop that proprietary software has, can be a lot more difficult to get a handle on. I find it quite pleasant that way - it attracts both hard-headed business types and social-experiment idealist visionaries; both huge corporations (IBM!) and a huge number of individuals; both people who have gotten quite wealthy from open source as well as most of the rest of us who manage to make ends meet but still love it. It's not something that's easy to pigeonhole, and as such it's hard enough to figure out the many ways in which it does work, let alone figure out how to improve on it. Stay tuned for further installments: Software Economics - Public Goods

David Welton: Software Economics - Public Goods

To look at the economics of open source software, you have to start with the economics of software as a category, both proprietary and open source. Note: it should be perfectly obvious to everyone that open source software works, and works quite well for some things. This article is more about understanding the how and they why. Just to avoid any confusion... If you look at software as a product, it has a couple of defining characteristics: What do you get when you combine something that's "non excludable" and "non rivalrous"? In economics, these are known as "public goods": http://en.wikipedia.org/wiki/Public_good - read the whole thing if you have a few minutes, it's what I'll be talking about. As per the article, "The Problem" as it were, is the free rider problem. Let's stop and look at a contrived example: Bob is an ex-dentist and really knows what it would take to write a great program for managing a dentist's office (or pick your own example... it's contrived, don't quibble about the details). He's also a good programmer, with the skills necessary to implement the program. He talks to a few of his dentist friends, and they're enthusiastic about the whole thing. Let's look at a few scenarios of how things might play out: Bob values his time at 10 dollars an hour, and it will take him 100 hours to complete the project, meaning the whole project would cost about 1000 dollars. One way things could work is that he could find a dentist friend who needs this program, and bill him 1000$ for his time and services, bang out the code, and release it as open source software. Bob gets his money, the dentist gets his code... and all the other dentists in town get it for free, which is bound to make the dentist who shelled out the money a bit irritated, given that he's a human, not a homo-economus, and doesn't like paying and see others get the same thing for free. Let's introduce another variable: the software is only really worth 200$ to the dentist - any more than that and yeah, it's helpful, but not worth that much money (And please stay with me, I know it's contrived, but keep in mind that the situation *is* possible, even if the numbers might be different). That means that if Bob wants 1000$ for his time, but the dentist will only pay 200$, then no transaction will occur! The software won't get written, Bob won't get any money, and the dentist will be worse off because he won't have the nice program, and neither will his dentist colleagues. One way things might still work is if the dentist rounds up some friends and they all contribute a bit, however, that's kind of a pain in the neck for everyone concerned - the dentist doesn't want to get into the software business and spend a bunch of time trying to chase his friends for money, and even if 10 dentists contribute, the ideal position to be in his the 11th guy, who pays nothing, and still gets the software for free. So it's in everyone's interests to not return the dentist's calls in the hope of being the 11th guy. Also, none of them gets the software until they're all on board. So, how to resolve this problem? The wikipedia page talks about introducing an exclusion mechanism, which in this case would be a copyright system so that Bob can sell a copy of his software for 100$ and be sure that it won't be open to everyone to use. This way, the dentists get the software for 100$ less than they value it at (200$), and as soon as Bob signs up an 11th dentist, he's making more than his time/materials costs, and is therefore coming out ahead! The dentists all know that they're paying the same price, so have no reason to grumble about free riders. In short, everyone is pretty happy. Of course, in the real world, things don't play out like that all the time. There are problems with the simplified example above, some of which are very evident: the cost of enforcing copyright laws, in an age when copying is extremely easy, is very high and potentially very intrusive. However, "intellectual property" is, by and large, a compromise solution that has had positive aspects, especially when you ignore the outliers like Microsoft, and look at all kinds of niche software vendors, who make a nice living, create good products, and have happy, satisfied customers. If you look at the other solutions to the free rider problem listed on the wikipedia page, we can see how they might be applied to the world of software. None of these solutions is perfect, and all, including exclusion in the form of intellectual property laws, or simply doing nothing at all, have problems of their own. Due to the very nature of software, this is somewhat inevitable, and the best we can do is come up with good compromises, and continue to reevaluate them as technology and society change (this is something that needs to happen with IP laws, for instance).

John Goerzen: Peace

Today over lunch, I and 6 others went to visit Grandma. She was in her room, looking better physically today than yesterday. When I walked in, I said brightly, Hi Grandma! She took my hand warmly, and said to me, Now I don t think we ve met. Who are you? I knew that moment would happen someday, but still was surprised when it happened. Mom told her that we were there to tell her we love her. Grandma counted out the seven of us, and said, All these wonderful people here to tell that to ME? That s Grandma still there! It was a difficult moment. Many of us were tearful, and Grandma was sick enough that she sometimes lost the battle to stay awake. But we were all glad it was happening. Mom thought it right (me too) that she should tell Grandma about the latest word from the doctors. The conversation went, in part, something like this, with my mom addressing her mother: My Mom: Mom, the doctors say your heart is probably wearing out. My Grandma: *shrug* Yeah. My Mom: And your body is probably tiring out too. My Gramdma: Yes it is. I m 94. It s not that Grandma was depressed or anything. Just that she had long ago been at peace with the idea of death, and actually told us more than once that the was rather surprised that she has lived to be as old as she has. So it wasn t frightening or surprising to her to confront her own mortality. To her, it was a fact, and an obvious one at that. My brother brought along Grandma s old Bible. She had given it to him a few years ago. It was filled with highlights and handwritten notes from cover to cover. She had carefully analyzed it, and when she bought a new Bible, had carefully copied the notes to it. My brother read to her two passages that she had highlighted:Psalm 23: (which she has noted as a favorite of many Christians ) and Numbers 6:24-26. He then held her hand and said a prayer with her. Then he said a blessing for her, and as he was getting to the end, she interrupted, saying the last word for him: forever! She still had her sense of humor, and made us all laugh several times. She said, as she always has when any of us stop by to visit, how happy she is that we came by, and what a wonderful family she has. She said several times Danke sch n, Danke sch n, Danke sch n! (Thank you, thank you, thank you! she had made sure to teach a few German words to all of us as kids.) When it was time to go, she got lots of hugs from us, and made a point to tell each of us individually thank you for coming! As we walked down the hall, I was reminded of her old tradition going back many years. Whenever we would leave her house, she d wave to us from the porch. And, if it was dark, we d turn on the car light and wave back. Since she s been in the nursing home, she ll wave to us from her doorway as we walk down the hall. And, sure enough, today s visit ended with her waving to us from her doorway with both hands (as she always does) and a big smile. We all waved back with a smile as we walked away, too. I don t know if this will be the last goodbye with her, but if it is, I can t think of a better one.

Matthew Garrett: Reducing disk use

UNIX filesystems generally store three pieces of timing information about files - ctime (when the file was changed in any way), mtime (when the file contents, as opposed to its metadata, was last changed) and atime (when the file was last accessed by any process). This is a usefully flexible system, but the semantics of atime can be troublesome. atime must be updated every time a file is read, causing a read operation to instead become a read/write operation. This results in a surprising amount of io being generated in normal filesystem use, slowing the more relevant io and causing disks to spin up due to atime updates being required even if the file was read out of cache. It also results in a lot of unnecessary activity on flash media which may reduce their lifetime.

One option is to disable atime updates entirely. The problem with this approach is that certain applications depend on atime. This is especially common in mail clients which compare atime to mtime in order to determine whether a mailbox has been read since it was last modified. So, unfortunately, disabling atime entirely is impractical as a default. Back in 2006, Valerie Aurora submitted a patch that worked around this issue. The new relatime option meant that atime would only be updated if it would otherwise be older than ctime or mtime. Mail clients became happy and the world rejoiced.

Unfortunately, it turned out that there was one other common case of atime being used. Applications like tmpwatch monitor files in /tmp and delete them if they appear unused. In this case, "unused" means "has an atime older than a certain date". Since merely reading files doesn't update the ctime or mtime, relatime wouldn't cause the atime on these files to be updated and tmpwatch would happily delete them - even if users were reading them on a daily basis.

Ingo Molnar submitted a patch to add a further heuristic to the relatime behaviour. With it, the atime of a file will be updated if it's older than mtime, older than ctime or (and this is the important one) more than 24 hours in the past. This deals with the tmpwatch case nicely, while still providing a significant reduction in the quantity of atime updates.

Fedora shipped this patch for several releases, and Ubuntu have used it by default since 8.04. Unfortunately there were some concerns over certain aspects of its behaviour (in respect to its interface as opposed to the relatime functionality itself) and it never got merged. I pushed a trimmed down version that purely implements the change to the relatime behaviour, and earlier today Linus merged it and a further patch that makes relatime the default behaviour on Linux.

Most users won't notice this change in behaviour at all, other than as a small improvement in io performance and a reduction in the number of drive spinups. For users that do have issues, a new strictatime mount option has been added - using this will require an updated mount command, but it's a trivial patch. I'd be surprised if there are any real world use cases that are negatively affected by this, especially since it's been default behaviour in several distributions for a while, but there's always the potential that someone will be tripped up by it. We'll see.

26 March 2009

Holger Levsen: Ada Lovelace naming scheme

Two days ago I read about the Ada Lovelace day, which was an event were men and women were asked to blog about the women in technology which made an impact on them, in an effort to present girls (and women) all over the world with female role models in technology.

In similar though more personal motivation I choose my machine naming scheme at home two years ago: my (virtual) machines at home are named after women who made a difference, mostly in IT, but also some in more general science. Even though this list is not 100% in the spirit of pointing out the one woman who made a personal difference to one self, I thought I share my list, as I found it very interesting to learn about these great women myself.

goldberg is named after Adele Goldberg, who pioneered the smalltalk programming language in the 70s. According to a sympathetic annecdote she refused to show the system to Steve Jobs and only did so after her superiors ordered her to do so. Thats were Apple got many ideas which made them famous for being innovative...

goldwasser is named after Shafi Goldwasser, who is a RSA professor at MIT, doing research in complexity theory, cryptography and computational number theory. She is the co-inventor of zero-knowledge proofs.

lovelace is named after Ada Lovelace, and is widely recognized as the first programmer, who wrote a program (something that manipulated symbols according to rules) for a machine which has not even been build at that time. Of course, some men on this planet object to her being the first programmer, as work by women is always insignificant... </irony or maybe sarcasm>

bunten is named afer Danielle Bunten Berry, who was a game designer and programmer best known for the games M.U.L.E. and Seven Cities of Gold.

holberton is named after Betty Holberton, who was one of the six original programmers of ENIAC, the first general-purpose electronic digital computer, during and after World War II.

hopper is named after Grace Hopper who wrote the first compiler ever, the A compiler. She was also heavily involved in creating COBOL and standardizing COBOL and FORTRAN.

koller is named after Daphne Koller who does AI research at MIT and who seems to behind the idea of bayesian machine learning, which you might know from your spam filters... (I can only state her involvement in bayesian learning so vaguely as I'm basically clueless about the topic :)

leveson is named after Nancy Leveson who is also an MIT professior and is an expert in systems and software safety.

Last but not least I like to remark that none of the women above is even nearly covered with what I wrote here or what is written in wikipedia, which I used as my main source for this blog post. It's simple impossible to sum up one life that brief and be close to accurate.

And then there is another group of women whose achievements are noteworthy as well and who choose to present themselves on that webpage to show others that Debian is not a mens club. Thank you (a lot) for that and for your other contributions to Debian! If you want to learn more about these giants, I recommend this talk. Guess who's achievements I admire most in this group ;-)

Somewhat unrelated I wish to shout cheers to Yvonne, who tought me many things and who died six years ago today. You will also not be forgotten, though the pain is mostly gone now (well, it's gone, except for days like today). Thank you, among other stuff, for teaching me to celebrate and cheer every day, even if not everything is cheerful. Wenn die Nacht am tiefsten, ist der Tag am n chsten! :-)

Rapha&#235;l Hertzog: Flights for Debconf

I have booked my flights for Debconf9 in July. I will arrive in Madrid on July 23th at 10:30 from Lyon Saint-Exup ry (LYS-MAD, flight AF5891) and I will leave on July 31th at 17:40 (MAD-LYS, flight AF5892). I plan to use the train to go to C ceres but it s too early to buy tickets on renfe.es. I also have no idea how far the train station is (from the airport) but it looks like I will have several hours transit time anyway. There aren t so many trains for C ceres. The train tickets will likely cost around 30 EUR each. I m glad that I can attend again this year. I m sure it will be very productive. At least concerning dpkg it will be good to meet Guillem Jover IRL. Partagez cet article / Share This

Ben Hutchings: Busy at PyCon

This week I'm at PyCon in Chicago, helping to train and supervise the A/V team in recording the tutorials and talks. We have a lot of inexperienced volunteers but they're learning quickly. Carl Karsten (in charge of A/V) and Ryan Verner (another outsider with long experience from LCA) are organising things. Ryan, Dave Noble and I provide technical assistance to the rest of the team. I'm also working on my first Django app, which will be used for reviewing files. This is essentially a clone of the excellent work done by Gunnar Wolf and Damian Viano in Pentabarf. PyCon doesn't have a centralised database so this is a standalone application. Ryan is now applying styles to my horribly bare HTML, and I have a short list of bugs to fix before we ask the video team to start reviewing. The tutorials started yesterday and talks wil start tomorrow in different rooms, so we have to set up all the equipment again and reconfigure for multiple cameras. Hopefully by Saturday things will be running smoothly and I can spend some time in the city. It would be a shame to come all this way and stay by the airport for the entire time!

Sven Mueller: Apache SSL oddity

If you ever have the problem described below, you have to realize that Apache HTTPD is selecting the SSL certificate (and/or key) not based on you VirtualHost definition, but based on the ServerName in the current context. This means that you have two virtual hosts with the same ServerName, but on two different IPs, and are wondering why the wrong key (and/or certificate) is used, it might be because of this. Assume we have the following (simplified) configuration:
<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>

(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA) Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL). This might as well be a bug or a design decision (AKA feature), I don t know. However the workaround that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won t do for the reverse/application proxy part). Update: Fixed formatting on configuration sample to make it clear this is not about namebased virtual hosts.

Ingo Juergensmann: Linksys WET-54G not IPv6 capable

Today I learnt that my Linksys WET-54G wireless Ethernet Bridge is not IPv6 ready. And I learnt that Linksys has a "we don't support Linux networks" company policy for its support channels.

Both is bad. The former, because IPv6 operates mainly on OSI layer 3 and above, whereas a bridge operates on OSI layer 2 (Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND) are used to make an association between IPv6 and layer 2).
The latter, because the operating system doesn't matter at all for this specific problem and Linksys is as well using Linux itself as is quite well known for its WRT-54GS/L wireless router series.

Anyway, currently the state is as following: the WET-54G is not being able to forward IPv6 router adverts via its bridge. So, if you intend to use some Linksys products and want to deploy IPv6 in your network, think twice! Currently I can't recommend Linksys products for IPv6 connectivity in SOHO places.
I doubt that there will be a firmware-update soonish.

(More information about the Linksys Support Chat can be found in my German section of my blog.)

25 March 2009

Pablo Lorenzzoni: FISL10 Subscriptions and Call for Papers Opened

One of the largest FLOSS events in the world, FISL (International Free Software Forum in english) subscriptions are already being accepted. They also already called for papers! They re calling this year s a special edition since they expect to reach 10-thousand attendees (last year exceeded 7-thousand)... this is pretty big if you ask me. As usual, it will take place at Porto Alegre, and is scheduled from June 24th to 27th. I think we can expect the usual activities (Programming Arena, Interesting Workshops, FLOSS shows, Great Speakers, Brazilian Government), but I think the special edition is not just due to the number of attendees. What surprises are being cooked by the Organization Committee is just something we ll have to wait and see :-) See you there!

Next.

Previous.