Day 48
Apples to be
IPv6 and the Internet of Things
Posted by erwin
on May 6, 2016
No comments
Usually, I post these small titbits of information on the modern “Social” media, but since Twitter is failing yet again, it might be a good time to dust of this good ol’ blog.
Geoff Huston of APNIC wrote yet another great article, this time about the adagio that the Internet of Things needs IPv6, and viceversa, that IoT is the killer App of IPv6. Do they really? Do read the whole article.
I do want to highlight one quote about NAT as a security feature:
All devices need to be paranoid. Trust is the outcome of negotiation, and obscurity is a lousy substitute for an effective security framework.
Indeed. NAT is not security, and security by obscurity has never helped anyone. Be paranoid. Assume the worst. It will only get better from there.
Stepping down from portmgr
Posted by erwin
on April 19, 2016
No comments
Almost to the day, 13 years ago I was elected as a voting member of portmgr, after several years as portmgr secretary. Time has come to take a break, knowing that I leave the ports infrastructure in good hands of the current team. Over the years, many things have changed. I’m especially glad to see how easy it has become to maintain a FreeBSD system without compiling anything, with the new pkg(8) frontend and poudriere(8) backend, which is also used in the build cluster. There are still a lot of ideas for improvements, and I’m looking forward to see what the team will come up with.
For me, it’s time to focus on other areas. While you won’t see me as much in FreeBSD channels and conferences, you’ll meet me more often in DNS related fora within ICANN, CENTR, DNS-OARC, and IETF.
It’s been, and still is, a great pleasure to be part of the FreeSBD community of portmgr, committers, and contributors, and I promise to no be a stranger. Safe winds!
Iguanas on a Curaçao beach
Posted by erwin
on December 21, 2014
No comments
httpvh://youtu.be/B45CQQTGJUc
MOOC: the next hyped bubble?
Posted by erwin
on November 17, 2014
No comments
There’s been a lot of talk in the (tech) media about the future of education being online, especially in the form of Massive Open Online Courses (MOOC). So far, I haven’t looked closely due to not enough interest and/or time, but I did fall over an interesting one on edX today and looked a bit closer. edX has an impressive list of schools and partners listed, so it much be good, right? The course description pages have a nice summary sidebar, with school, start date, course length, estimated effort in hours per week, and prerequisites, but does not mention the price. While the price actually is well-hidden half-way through the page, I at this point assumed I had to sign up before seeing the price. During this process, there is not only a Terms and Conditions, but also a Privacy Policy and an Honor Code, as the usual click-through bullets in any webpage these days. I did wonder about the Honor Code though and had a click glance. It includes wonderful titbits like this:
EdX reserves the right to modify these TOS at any time without advance notice
My interest was spiked. It continues:
Any changes to these TOS will be effective immediately upon posting on this page, with an updated effective date. By accessing the Site after any changes have been made, you signify your agreement on a prospective basis to the modified TOS and all of the changes
Aha! Not only do I have to give a carte blanche to whatever they feel like to write in there in the future without telling me, but also after reading the new terms, I already accepted them as I had to access the site to find out about them. Catch 22.
Another glance a bit further down the page, I noticed I had to grant edX a license. Interesting I thought, let’s find out. Anyone remember the hot water Facebook found itself in a while back?
License Grant to edX. By submitting or distributing your User Postings, you hereby grant to edX a worldwide, non-exclusive, transferable, assignable, sub licensable, fully paid-up, royalty-free, perpetual, irrevocable right and license to host, transfer, display, perform, reproduce, modify, distribute, re-distribute, relicense and otherwise use, make available and exploit your User Postings, in whole or in part, in any form and in any media formats and through any media channels (now known or hereafter developed).
Clearly, that’s a lot broader than what’s needed for the operation of the site where users’ comments are shared between other users and instructors.
Needless to say, I stopped reading here, not even bothering with the TOC or Privacy Policy. Next time a reporter goes raving that MOOCs are the greatest thing invented since sliced bread, solving everything from the bored life of university professors to literacy and poverty in the 3rd world, point them to the small print. At a $250 fee and those kinds of legalese, it seems the nice people behind these MOOCs are not just doing it for the good of society.
FreeBSD Developer Summit – BSDCan 2014 – Ports and Packages WG
Posted by erwin
on July 16, 2014
No comments
Baptiste Daroussin started the session with a status update on package building. All packages are now built with poudriere. The FreeBSD Foundation sponsored some large machines on which it takes around 16 hours to build a full tree. Each Wednesday at 01:00UTC the tree is snapshot and an incremental build is started for all supported released, the 2 stable branches (9 and 10) and quarterly branches for 9.x-RELEASE and 10.x-RELEASE. The catalogue is signed on a dedicated signing machine before upload. Packages can be downloaded from 4 mirrors (us-west, us-east, UK, and Russia) and feedback so far has been very positive.
He went on to note that ports people need better coordination with src people on ABI breakage. We currently only support i386 and amd64, with future plans for ARM and a MIPS variant. Distfiles are not currently mirrored (since fixed), and while it has seen no progress, it’s still a good idea to build a pkg of the ports tree itself.
pkg 1.3 will include a new solver, which will help 'pkg upgrade' understand that an old packages needs to be replaced with a newer one, with no more need for 'pkg set' and other chicanery. Cross building ports has been added to the ports tree, but is waiting for pkg-1.3. All the dangerous operations in pkg have now been sandboxed as well.
EOL for pkg_tools has been set for September 1st. An errata notice has gone out that adds a default pkg.conf and keys to all supported branches, and nagging delays have been added to ports.
Quarterly branches based on 3 month support cycle has been started on an evaluation basis. We’re still unsure about the manpower needed to maintain those. Every quarter a snapshot of the tree is created and only security fixed, build and runtime fixed, and upgrades to pkg are allowed to be committed to it. Using the MFH tag in a commit message will automatically send an approval request to portmgr and an mfh script on Tools/ makes it easy to do the merge.
Experience so far has been good, some minor issues to the insufficient testing. MFHs should only contain the above mentioned fixes; cleanups and other improvements should be done in separate commits only to HEAD. A policy needs to be written and announced about this. Do we want to automatically merge VuXML commits, or just remove VuXML from the branch and only use the one in HEAD?
A large number of new infrastructure changes have been introduces over the past few months, some of which require a huge migration of all ports. To speed these changes up, a new policy was set to allow some specific fixes to be committed without maintainer approval. Experience so far has been good, things actually are being fixed faster than before and not many maintainers have complained. There was agreement that the list of fixes allowed to be committed without explicit approval should be a specific whitelist published by portmgr, and not made too broad in scope.
Erwin Lansing quickly measured the temperature of the room on changing the default protocol for fetching distils from MASTER_SITE_BACKUP from ftp to http. Agreement all around and erwin committed the change.
Ben Kaduk gave an introduction and update on MIT’s Athena Environment with some food for thought. While currently not FreeBSD based, he would like to see it become so. Based on debian/ubuntu and rolled out on hundreds of machines, it now has it’s software split into about 150 different packages and metapackages.
Dag-Erling Smørgrav discussed changes to how dependencies are handled, especially splitting dependencies that are needed at install time (or staging time) and those needed at run time. This may break several things, but pkg-1.3 will come with better dependency tracking solving part of the problem.
Ed Maste presented the idea of “package transparency”, loosely based on Google’s Certificate Transparency. By logging certificate issuance to a log server, which can be publicly checked, domain owners can search for certificates issued for their domains, and notice when a certificate is issued without their authority. Can this model be extended to packages? Mostly useful for individually signed packages, while we currently only sign the catalogue. Can we do this with the current infrastructure?
Stacy Son gave an update on Qemu user mode, which is now working with Qemu 2.0.0. Both static and dynamic binaries are supported, though only a handful of system call are supported.
Baptiste introduced the idea of having pre-/post-install scripts be a library of services, like Casper, for common actions. This reduces the ability of maintainers to perform arbitrary actions and can be sandboxed easily. This would be a huge security improvement and could also enhance performance.
Cross building is coming along quite well and most of the tree should be able to be build by a simple 'make package'. Major blockers include perl and python.
Bryan Drewery talked about a design for a PortsCI system. The idea is that committer easily can schedule a build, be it an exp-run, reference, QAT, or other, either via a web interface or something similar to a pull request, which can fire off a build.
Steve Wills talked about using Jenkins for ports. The current system polls SVN for commits and batches several changes together for a build. It uses 8 bhyve VMs instances, but is slow. Sean Bruno commented that there are several package building clusters right now, can they be unified? Also how much hardware would be needed to speed up Jenkins? We could duse Jenkins as a fronted for the system Bryan just talked about. Also, it should be able to integrate with phabricator.
Erwin opened up the floor to talk about freebsd-version(1) once more. It was introduced as a mechanism to find out the version of user land currently running as uname -r only represents the kernel version, and would thus miss updates of the base system that do no touch the kernel. Unfortunately, freebsd-version(1) cannot really be used like this in all cases, it may work for freebsd-update, but not in general. No real solution was found this time either.
The session ended with a discussion about packaging the base system. It’s a target for FreeBSD 11, but lots of questions are still to be answered. What granularity to use? What should be packages into how many packages? How to handle options? Where do we put the metadata for this? How do upgrades work? How to replace shared libraries in multiuser mode? This part also included the quote of the day: “Our buildsystem is not a paragon of configurability, but a bunch of hacks that annoyed people the most.”
Thanks to all who participated in the working group, and thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the Ports and Packages WG meet up at EuroBSDCon in Sofia in September.