This week (22 - 28 April) is the week that really matters most for those students who want to participate in Google Summer of Code. The deadline for student applications is next Friday (3 May), but if you don't spend time exploring project ideas this week, you won't be able to make a strong enough application.
Here are the key things I need to see for potential students for the project areas I have offered to co-mentor in:
- Register on the Google site, Click here to register yourself (registration opens 22 April and closes 3 May).
- Create a page about yourself on the Debian wiki, you must copy the template used by the other students. Make sure you create a link from the student list to your own page. Think carefully about your project: what will be the final result of your work this summer? Describe what it will look like, how Debian people will use it, and explain these things on your wiki page, this will be critical to having Debian accept you.
Those are the essential things you must do before the deadline on 3 May. There are other things you should do as well:
- Join the Summer of Code co-ordination mailing list
- Join the mailing lists for whichever open source project and/or Debian packaging team is relevant to your proposed GSoC project
- On the mailing list, send an email introducing yourself, giving us the link to your wiki page.
To maximize the chance that the Debian project will accept you, it is very important that you interact with us and show us that you understand software development.
I am going to try and make this easier: for each of my projects, I've put some wishlist items in the Debian bug tracker. These are all easy tasks that a student can potentially complete. Just do the following:
- Pick a task from the bug tracker
- Send an email to the bug tracker (e.g. <bug-number>@bugs.debian.org>) explaining that you will work on the task (and make sure nobody else is already working on it, just look to see if any other emails are attached to the bug report)
- Write the patch, test it and email the patch to the bug report
Here are the links to the bug lists for each of the packages. You can also pick any other wishlist bug in any related package, but if you are not sure, just pick one of these:
- For real-time communications and VoIP, look at wish-list bugs against the reSIProcate package
- For one-time password authentication, look at wish-list bugs against the dynalogin package
- For Improving PKI on Debian, look at wish-list bugs against the openssl package
If you already have a history of contributing to free software, it is essential that you tell us about it. This will increase the chances that your application is successful. Specifically, on your Debian wiki page, you should include links to any of the following:
- Emails you sent to open source communities contributing patches or analysis of bugs (give a link to your message in the email archive for the list)
- Your github account profile page, if you have one
- Your Sourceforge account profile page, if you have one
- Any other similar links
Debian receives many applications every year. To help you succeed, you need to think about how Debian will benefit from your work. Use Google to search the Debian site for previous discussions about your idea. Find out the names of Debian Developers who are interested in the same subjects, and email us or email the public mailing lists of the Debian project, for example, debian-devel. Make sure your email includes links to previous discussions or wiki pages about the idea, explain how you can help and ask the community for suggestions and guidance to refine your project proposal. Debian is an open community and we are all very keen to discuss your ideas and help you get involved.DebConf
For all students, attending free software events is a great opportunity to meet the community. Of particular relevance for those in Europe, attending DebConf13 in Switzerland is a great way to meet GSoC mentors and other developers. Switzerland's central location is extremely convenient for anybody in Western Europe and it is also Debian's 20th birthday, so it is anticipated DebConf could be more special than usual this year. Please put it in your calendar and subscribe to the debconf-discuss mailing list so you will know when registration opens and other practical details are announced.
abi-compliance-checker is an amazing tool for tracking API/ABI.
Wouldn't it be great to glue abi-compliance-checker into dh / cdbs packaging?!
abi-compliance-checker (1.98.8-1~exp1) experimental; urgency=low
* New upstream release
* Add dh_acc to generate and compare library dumps at build time,
together with addons for dh(7) and cdbs.
* Bump standards version, bump debhelper to 9, use 3.0 (quilt) format,
update Vcs-Svn field to canonical form, remove obsolete
* Apply a patch to allow suffixes on a-c-c abi dumps.Horay! So how does one use it?
- build-depend on dh-acc
- In your debian/rules
- call dh_acc somewhere appropriate
- dh $@ --with acc
- include /usr/share/cdbs/1/rules/acc.mk
- In your debian/libpackage-dev.acc
- Write a abi-compliance-checker descriptor (no need to include version)
- Build your package
- Copy the generated /usr/lib/$(multiarch)/dh-acc/*.abi.tar.gz as ./debian/lib-package-dev.abi.tar.gz.ARCH
- Now at each build ABI/API checks will be executed and compat reports will be generated
</descriptor>I wonder if things can be improved, for example:
- For trivial packages, don't require .acc at all & simply point abi-compiance-checker at ./debian/tmp/
- I think logs currently pollute the unpacked source package
- Multiple "base" ABI need checking. E.g. given versions A, B, C one can introduce a new symbol in B and drop it in C. Both B & C are compatible with A, but C is not compatible with B, thus an API/ABI break got introduced into the distribution if all A,B,C were ever published in the archive.
- Maybe run these as DEP-8 autopkgtests as well?
Please, play around with dh-acc and let me know what you think =)
Lisandro Damián Nicanor Pérez Meyer: On the road to Qt 5: Qt 5 base, tools, jsbackend and xmlpatterns in experimental
- qtbase-opensource-src: lib[concurrent core dbus gui network opengl printsupport sql test widgets xml], examples, development packages and debug symbols.
- qttools-opensource-src: lib[qtlucene designer help], qdbus, development headers and debugging symbols.
- qtjsbackend-opensource-src: libqt5v8-5
- qtchooser, which allows to select between Qt4 or Qt5 at build time.
What's not thereArchitecturesAMD64 is already there because it's the arch used by maintainers to build the packages. i386 should be following as soon as buildds catch up. Most surely ARM-based archs will be there at some point too.
Other archs will need some love. Not strange, the Qt project supports amd64, i386 and ARM, but we Debian have normally prepared patches to make it build in other archs. And yes, we try to push them upstream for everyone's benefit. So, if you are missing it in your arch, take a look. You may be the one who enables Qt 5 in it :-)
GLES2 and WaylandWe don't have GLES2 or Wayland support yet. Building it will most probably break the desktop for people using proprietary video drivers (or at least I was told so). I'll surely provide non-official packages with GLES2/Wayland enabled to allow people testing it, but not soon.
This also means that we are not currently able to split X11 and framebuffer support. But we have time to work on it :-)
Non DFSGs compliant files
If you get the original source code tarball from Debian you will notice that it has dfsg in it's name. That means that we had to remove some non DFSG compliant stuff from the original tarball, namely:
- Every RFC.
- Three files used for testing the build, which are made of RFCs.
- Some fonts.
Other parts of Qt 5 are on the way. And remember, this packages would not have been possible if it weren't for the great Debian's pkg-kde team. My kudos to them.
In October I announced that starting with 3.6 kernel it was eventually safe to unplug Zenbook.
Then in bugreport I was told that Sentelic touchpad driver was included in 3.8 kernel.
And guess what… I don’t have to patch kernel to have working touchpad using 3.8 kernels but I have to worry about unplugging laptop cause with 3.8.x kernel it’s quite common that it turns laptop off again.
So the question is… do we have any regression tests in kernel?
Should I test every kernel release between 3.8.5 and 3.6.0 to find the one that incorporated that bug again?
The Debian project distributes software packages via its archive, propagated through a network of mirrors. This archive is organised in three areas, main, that contains the Debian system, and contrib and non-free, that contain accessory packages that are not Free. The packages in non-free contain files that have a proprietary license. The source packages in contrib contain only Free files, but produce binary packages that are either useless without the access to remote services, or contain non-Free files, or cause the installation of non-Free materials.
The contrib area is an endless source of discussions, as it is not always easy to draw the line between what is usable and what is useless without remote services. I wonder if it would be better to replace the contrib area by a new priority level, “remote”, lower than extra. Packages that are entirely Free (source and binary) and that do not cause the installation of proprietary software would be fit for main. For the packages that can not function without non-Free software, given that the work to be done to free them is the same regardless whether the proprietary code is included in the source package (in non-free) or not (in contrib), I think that in both cases the package should be in non-free as it is not Free in practice.
This would allow for a simple criterion: does the selection of a binary package trigger the installation of non-Free files? If yes, the package and its source belong to non-free. If not, they belong to main. Then, if they need to access a remote service that would not be possible to set up on a network where only Debian is available, their priority would be remote.
Michael Stapelberg recently posted a blog post about looking into the number of Debian Developers actively working on RC bugs for the upcoming wheezy release.
In this blog post I analyze the data shared by Michael and provide the R commands used to generate the plots & findings. If you are interested into looking into the data yourself, but don’t like R, I suggest using ipython notebook + numpy instead.Analysis
After parsing the data file we typically want to get an understanding of the data, by using summary(bugs) we get the minimum(1), median(5), mean(15.4), max(716) and quantiles of the data. This shows that the number of messages is wide-spread and a few people contribute a lot. To visualize the dispersion of the data we can create a box plot showing the range of messages:
As the first and third quantile are close together we can assume that the majority of the work is done by a few, especially since the second quantile is 5. This is supported by the histogram below, where the x axis is the number of recorded messages and y is the number of developers.Top 10 contributors
The TOP 10 contributors, according to the dataset, are:
- Lucas Nussbaum - 716 messages
- Gregor Herrmann - 270 messages
- Jakub Wilk - 270 messages
- Andreas Beckmann - 225 messages
- Julien Cristau - 205 messages
- Cyril Brulebois - 169 messages
- Moritz Muehlenhoff - 162 messages
- Michael Biebl - 159 messages
- Salvatore Bonaccorso - 158 messages
- Christoph Egger - 142 messages
These are the commands used to generate the plots and information in this plot:
bugs <- read.csv("by-msg.csv") summary(bugs) boxplot(bugs$rcbugmsg, log='y', range=0, ylab="# bugs") quantile(bugs$rcbugmsg) 0% 25% 50% 75% 100% 1 2 5 12 716 # create histogram llibrary('ggplot2') ggplot(bugs, aes(x=rcbugmsg)) + geom_histogram(binwidth=.5, colour="black", fill="black") + scale_x_sqrt() top10 <- tail(bugs[order(bugs$rcbugmsg),], 10) top10
Over the past cycle in Ubuntu, many packages where synced from experimental, many fixes were applied and many packages were upgraded ahead of debian version strings.
If one goes to your package PTS page at:
One can find the following box titled "ubuntu" in it:
Please click on "patches for VERSION STRING" to find:
- Useless irrelevant changes =) oh well, it happens
- FTBFS fixes due to GCC 4.8 (*)
- FTBFS fixes due to new GlibC
- FTBFS fixes due to multiarched Python2.7 and Python3.3
- FTBFS fixes due to multiarched Tcl/Tk
- FTBFS fixes due to Python hash randomisation enabled
- FTBFS fixes due to Boost 1.53 (*)
- Fixes to minimise dependencies when bootstrapping packages
- Fixes to multiarch more and more libraries
- Fixes to enable package cross-building
- Updates to new upstream releases
- Usage of pybuild
- Completed migration away from guile1.6
Some of the above patches were submitted to debian, with majority of submitted patches have not been applied, simply because none of them were appropriate during freeze and could have been disruptive to Wheezy release.
Please check useful patches available on your PTS!
Please take those patches!
Not taking Ubuntu patches results in more duplicate work in Ubuntu (i.e. rebasing those patches), thus reducing total dev-time available to work to fix other issues.
I myself uploaded a few of those patches into Ubuntu. And in the beginning I was filing BTS bugs with a patch against relevant packages in Debian. Very quickly I realised that since Debian is frozen a lot of those patches would just bitrot in BTS. I of course wished that they would all be instantly applied and uploaded into Experimental, but that did not happen. At the moment there are still 8 bugs open with patches I submitted, with oldest one opened on 6th of July 2012. So that's the reason why I stopped pushing patches to BTS, because well they are not reviewed nor applied in a timely manner =) where my expectation of timely manner is less than 6 months to be uploaded into Experimental or reviewed/rejected/commented on. Not uploading patches because they don't apply to Debian yet, is silly as they will apply to Debian eventually. Unapplied patches continue to generate more work on a more universal scope (e.g. requiring those patches to be rebased in ubuntu, thus many developers spending their time doing that, instead of writting fixes for new issues).
The summary of the main changes follows:Changes in RcppArmadillo version 0.3.810.0 (2013-04-19)
Upgraded to Armadillo release Version 3.810.0 (Newell Highway)
added fast Fourier transform: fft()
added handling of .imbue() and .transform() by submatrices and subcubes
added batch insertion constructors for sparse matrices
minor fix for multiplication of complex sparse matrices
Updated sample() function and test again contributed by Christian Gunning
As many of you know, I fell into helping get the artwork for Wheezy into place. While I don’t want to do this (in the long run), I feel the urge to get it into shape for Jessie.
I’d like to do a small request for methods to improve the theme packaging. I’ve posted a suggestion, but I never really got happy with it.
The problem is basically the deb makes no sense because making thee deb make sense would result in insanity ;) — stuff like proper dependencies to allow the Plymouth theme to work can’t be done, since it’d require a dep on Plymouth, which means it requires all installs with desktop-base to have it installed.
I posted the following on Google+, but it is important enough to be reproduced on Planet. I'm editing it a bit, as it is a followup to my previous post.
While improving the packaging of MongoDB, there was one thing that caught my attention: that Ubuntu had already done some of the embedded/convenience libraries work, but they had not pushed that work to Debian.
Of course, discovered this only after I started working on the improvements of the package.
What gives, Ubuntu people?
Another thing that I saw is that they have patches enabling mongodb working on armhf. Again, they did not push those to Debian.
Why this lack of cooperation?
Why not push this work and avoid duplication of work?
By being a good downstream, I intend to push some of the patches to MongoDB upstream (if they want it), so that we (Debian) have a smaller delta. This will benefit you Ubuntu guys. Why not join forces and help have a world-class set of packages?
Please, be good netizens and share the work that you have. I firmly believe that the armhf people will be happy to have one of the fancy "cloud" software available on ARM, especially since the prospects of having ARM machines on datacenters.
Oh, just for the record, the kFreeBSD people have sent their contribution and I would love to see (if possible) this running on the HURD.
Seems I was off by two weeks. Week 18, it is/should be. Yay.
The UDD bugs interface currently knows about the following release critical bugs:
- In Total:
- Affecting wheezy:
20 That's the number we need to get down to zero
before the release. They can be split in two big categories:
- Affecting wheezy and unstable:
12 Those need someone to find a fix, or to finish the
work to upload a fix to unstable:
- 4 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
- 2 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
- 6 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
- Affecting wheezy only: 8 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
- Affecting wheezy and unstable: 12 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
- Affecting wheezy: 20 That's the number we need to get down to zero before the release. They can be split in two big categories:
How do we compare to the Squeeze release cycle?Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 18 release+12
Graphical overview of bug stats thanks to azhag:
Eugene V. Lyubimkin: Cupt: reason chains, functional selectors and crowdfunding experiment via catincan.com
A couple of particularly interesting features -- showing full reason chains and functional selectors -- may be summarized by this screenshot.
And, as a fresh experiment, I placed a feature to widen functional selecting capabilities to Catincan, a (new?) crowdfunding platform for open source projects. Let's see how it goes.
<video controls="" height="340" poster="http://upload.wikimedia.org/wikipedia/commons/thumb/0/03/Schilthorn_with_Bernese_Alps%2C_2012_August.jpg/800px-Schilthorn_with_Bernese_Alps%2C_2012_August.jpg" width="560">
<source src="http://video.danielpocock.com/VID_20121025_123951.m4v" type="video/mp4"></source>
<source src="http://video.danielpocock.com/VID_20121025_123951.webm" type="video/webm"></source>
Video not appearing? Click here to access the page directly
Unfortunately, the gangsters, guns and girls from On Her Majesty's Secret Service won't be waiting to greet you at the top, but there is a spectacular view. On a clear day, you can see all the way across to the venue of DebConf13 in Vaumarcus, Switzerland and also the Black Forest in Germany.
I have been occasionally working on some Debian-related tasks.Chrony
One of those was to get chrony is a slightly better shape, by using, at least, a patch system (indeed, I "modernized" its packaging with the format "3.0 (quilt)"), put it in a git repository and would like to receive some comments on what I have so far.
The bug Debian bug #694690 contains a very brief description of my intentions and of the problems that I see in the current package. IMVHO, it is a very nice NTP client and server and it could even be used as the default for Debian, once it gets in shape. There is at least another high-profile distribution, namely Fedora, that switched to chrony as its default NTP software. We can certainly take a look at what they are doing and join forces here.MongoDB
Another package where I spent some time was with mongodb: MongoDB is a tricky package that is only built for 2 arches: amd64 and i386. The version in unstable for i386 was 2.0.x (roughly the same as for wheezy), which the version in unstable for amd64 was 2.4.1, which has many features that 2.0 lacks.
The packaging of it is a bit tricky, since the source tree has bazillion embedded/convenience libraries (e.g., Google's v8, Mozilla's spidermonkey, BOOST, Google's Snappy, PCRE 3 etc.). Up to version 2.4.1-2, it used all these convenience copies, which is of course, a problem for a distribution like Debian.
I changed part of the build process to use the libraries that we already have in Debian and, as Antonin Kral uploaded this newer version, unsurprisingly the binary packages are smaller (especially if you take into account that a handful of the libraries may already be installed on the system).
A few hours later, Antonin uploaded a new upstream version, which means that we now have better MongoDB packages to play with. I am, in fact, really playing with MongoDB as my first NoSQL database, since [10gen is giving an introductory course][2.5] on how it works and my motivation was to get what we have in Debian in shape for the course.
You can say that I am a firm believer of the "eat your own dogfood" principle.
Regarding MongoDB only being built for i386 and amd64, the BTS has a patch to enable building for kFreeBSD, but the patch is for the 2.0 series and the code has changed so drastically in relation to the 2.4 series that there is no hope of it applying. It would be super nice to have MongoDB working on kFreeBSD and on HURD also, though.nocache
There is a very nice command line program called nocache that was packaged by Dmitry Smirnov (and just approved by the FTP masters!) whose packaging I briefly reviewed per Dmitry's request and this is an amazing utility whose purpose is to bypass/minimize file system caching for a program.
This is especially useful when you are making backups (reading lots of files that would, otherwise, fill the filesystem cache, even if they are not used frequently) or if you are just streaming one file (possibly larger than the system's RAM) to another computer and you have no need to use the file immediately after that.
It performs its job by using the LD_PRELOAD mechanism and using posix_fadvise's flag POSIX_FADV_DONTNEED for the files that will be touched.Post note
Oh, just one aside: for the readers of Debian Planet and other aggregation services which are not Debian Developers/Maintainers, I contributed to these packages without being the maintainer of them, just scratching some itches and contributing back what I produced.
(actually, please set your calendars to the day before yesterday — I had a mental tab on this, but it seems watching mental tabs is a low-priority task for brain.sched)
Ten years ago today, I got that long awaited mail telling me I had passed all of the needed hurdles and was accepted as a Debian Developer. We were at the first third of a very long release cycle, and the general spirit of the project was clearly younger — both as in "things moved easier" and "we were much more immature" — Try to follow the mailing list discussions we had back then, and even with all the vitriol that's every now and then spilled on firstname.lastname@example.org, it's clear we have more experience working together.
And yes, the main change that ten years bring to a group of people is social. I was at DebConf in Oslo when the now-historic presentation that prompted the birth of the Debian-Women group was given — Surely, Debian (and Free Software) still is by far predominantly male and white — But I fel it's no longer a hostile group, much to the contrary.
Over the years, I was first active (as was the norm by then) as a "solo" maintainer. When Joachim Breitner started the pkg-perl group in 2004, I joined, and was part of the group while an important part of my work was based in Perl. I joined pkg-ruby-extras, and slowly migrated my technical work from one to the other. For several years, I also maintained the Cherokee webserver. I started getting involved in DebConf organization in 2005, and (except for 2008, as I took a vacation from many topics due to personal issues). Back in 2009, I became an official delegate! I joined Jonathan McDowell handling keyring maintenance. One year later, another delegation: With Moray Allan and Holger Levsen, the three of us became the DebConf chairs.
This last couple of months, I have been quite inactive in most of my Debian work. I took up teaching at the univerity, and have been devoting what amounts to basically a full time job to prepare material. I expect (hope!) this craze to reach back a "workable" level by late May, when the course finishes, and I can retake some of my usual Debian tasks.
Anyway — 10 years. Wow. This project is one of the longest commitments in my life. I am still very happy I joined, it still thrills me to say I am part fo this great project, it still makes me proud to be accepted as a peer by so many highly skilled and intelligent people — But, as I have repeatedly stated, I see Debian more as a social project (with a technological product) than as a technical one. And as such, I am really happy to have made so many good, close friends in this project, to have the opportunity to work and exchange points of view about anything, and have this large, highly disfunctional but very closely regarded family of friends.
So, guys, see you this August in Switzerland. I will be among the group celebrating we have been there for half of the project's history!
A colleague of mine at Facultad de Ingeniería pointed me to a note published in the Faculty's gazette about a short cycle of talks we had on April 4th, trying to get life and interest back in the once-active LIDSOL (Laboratorio de Investigación y Desarrollo en Software Libre, Free Software Research and Development Laboratory), which nowadays lies mostly dormant.
Good thing the official communication channels got notice of this! Only I am not sure if they can properly produce Spanish (as this feels more like an English redaction). Quoting only the first lines of the paragraph that referes to me:
La última conferencia fue presentada por Gunnar Wolf, que aunque su nombre nos hiciera pensar en una nacionalidad europea, él es nacido en tierras mexicanas pero con descendencias húngaras, austriacas y polacas.
Which translates to:
The last talk was presented by Gunnar Wolf, that although he has a name that makes us think about an European nationality, he was born in Mexican soil, but with Hungarian, Austriac and Polish descent.
As far as I can tell (and I am almost sure I know all of the story — At least on that regard), I have no descent yet. Not Hungarian, Austriac, Polish, nor of any nationality.
(nitpickers: Yes, similar words are often used. In Spanish, it would be correct to say de ascendencia húngara, austriaca y polaca, and in my attempt towards English translation, it would be of Hungarian, Austriac and Polish descent).
This next Tuesday, April 23rd, 2013, a few of us Debian people in the Netherlands will get together for beer and keysigning in Belgisch Bier Café Olivier in Utrecht. If you are in the area, feel free to come, have a beer or two and mingle!
Find the exact details in this debian-events-nl mail.
See you there!
With so many people contemplating the cost of travel to Switzerland this summer, I thought I would share some eye-opening insights into how to get a better deal.
Let's look at some costs for a hypothetical DebConf13 visitor coming from New York. Flight prices taken today from a comparison site for 8 - 18 August, car hire prices from Europcar and rail prices from SBB (regular tickets) and Swiss Travel System (tourist rail passes):Departure airport Arrival airport Flight cost Bus to Swiss border Rail pass Total (Flight+bus/train) Airport car hire, 10 days Total (Flight+car)New York Geneva $1,153 n/a CHF 82
Return ticket $1,235 CHF 668 $1,823 New York Milan $990 $20 CHF 315
Flexi pass $1,350 EUR 413
CHF 496 $1,490
Warning: car rental prices based on advance booking - if you just arrive at a Swiss airport and hire a car on the spot, it is likely to be much more expensive, maybe CHF 200 per day
For a single traveler, it is slightly cheaper to fly into Geneva (closest airport) and buy a return train ticket, as long as no other travel in Switzerland is desired and sleeping on-site at Vaumarcus, not using a bus every day.
If traveling in Switzerland to see the mountains, then it works out cheaper to fly into Milan, Italy, which is very close to the Swiss border. Most of the journey from Milan to Vaumarcus can be covered using one of the Swiss railway travel passes, with stops for sight-seeing on the way, and the other days on the pass used for sight-seeing.
Now imagine people arriving in a group: the rail ticket prices quickly add up. For a family of four, 4 * 315 = CHF 1,260. Car rental may be a better option. Hiring a car in Switzerland is expensive, hiring in Italy is much cheaper, the plane tickets to Italy are cheaper too, so there is a lot of money to be saved.
But who wants the hassle of travelling to Switzerland via Italy?
Of course that is the silliest rhetorical question you are going to see this week: visiting Italy is not a hassle at all. Even the Swiss enjoy going there so much that they just built the world's longest rail tunnel under the Alps to bring Como and Milan that little bit closer, the Gotthard Base Tunnel.
The Italian connection could involve a few days in Como or Brunate. If designer fashion labels are appealing to you (or as a gift), Vertemate has one well known outlet for a major brand and the prices really are much cheaper than any of the cities. If you want a laugh, it's worth comparing the hotel prices in Lugano on the Swiss side of the border against prices in nearby Como.
Traveling north from Como, taking a train to Luzern (and a connection to Vaumarcus), it is possible to stop in Goschenen and go up into the mountains to experience the Glacier Express featured in my earlier video or get off the train at Arth-Goldau to cross Rigi on the Rigi Bahn (from my other video), take a boat across the lake to Luzern and then continue to Vaumarcus.
The Italian entry point isn't just an option for those coming from the US. Even a traveler from London will find that the budget airlines have largely snubbed the Swiss airports with their high operating costs. Easyjet offers a limited number of flights to Geneva and Zurich, but the prices are always higher than their other destinations. Ryanair offers flight's to Milan's Bergamo airport and Easyjet flies to Milan Malpensa.
And we're in CfP and negotiating with potential sponsors now, and some companies and media have already ACKed as below.
- WindowsAzure (Platinum sponsor, yes "Microsoft supports Debian event" :-)
- Plathome (Gold sponsor, they're also DebConf13 sponsor!)
- TOP STUDIO (Gold sponsor, thanks to Kenshi Muto :)
- Serverworks (Gold sponsor, AWS vendor)
One of the benefits of working from home is that I have a great view of Kansas from my desk. While I work, I have seen sunrises, snowfall, birds, rain, ice, and all sorts of wildlife. I heard this verse of Home on the Range the other day, which reminded me of this:
“How often at night when the heavens are bright
With the light from the glittering stars
Have I stood here amazed and asked as I gazed
If their glory exceeds that of ours.”
One time, I asked Jacob if I should wake him up at night to see the stars. He said an excited yes! So when it was dark outside, I woke him up, carried him outside, and held him while he looked up. He said a long, breathy “Wooooow!” Then he went back to bed, curled up with his butterfly, and fell asleep smiling. Every so often, we repeat this little routine.
There are many opportunities in life to just stand somewhere and be amazed. You don’t have to be in Kansas. Children know this. The rest of us just have to notice.