> а чтобы любой адрес *.ipv6.51t.ru работал? чтобы я мог все сервисы и на 51t.ru и на ipv6.51t.ru вешать

done

(попробовал перевести сам... вроде, терпимо, но надо будет ещё раз вычитать)

g2k14: Theo de Raadt: безопасность и конфигурашность

Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:

Две недели перед Словенией я работал с Бобом Беком (Bob Beck) над заменяющими getentropy(2) функциями. В начале хакафона были внесены последние штрихи, нужные Бобу и Бренту Куку (Brent Cook) для дальнейшей работы.

Затем пришло время разбираться с очередной проблемой безопасности, о которой мне стало известно. К нашему прискорбию выяснилось, что исчерпание ограничения на количество одновременно открытых файлов может быть использовано для сокрытия уведомлений о переполнении стека от соответствующего механизма защиты. Защитнику стека требуется файловый дескриптор, чтобы сообщить об ошибке. Те, кто уже читал заметки об arc4random и getentropy, уже в курсе данной ситуации.(*)

Проблема стала очевидной из-за технологии "песочницы", используемой ныне в SSH-утилитах, которая закрыла syslog_r() доступ к socket(), connect(), sendto()... всем системным вызовам, необходимым для сообщения об ошибке, но потенциально опасным - что как раз "песочница" и должна предотвращать.
... [>>>]

Мартин Пеликан пишет в отчёте с g2k14:

Мой первоначальный план состоял в том, чтобы в нашей base мог собираться libcpp из LLVM, дав нам поддержку C++11. После того, как я читал о последних дополнениях локалей POSIX, другие разработчики прояснили, что будет нужно больше вариантов версии библиотеки, чтобы не сломать порты. После того, как первый diff был готов, я поднял сборку базовой системы, чтобы проверить, сломается ли она. И затем моя жизнь изменилась...

За несколько дней до хакатона я решил поставить на свой ноутбук Linux, Windows и OpenBSD рядом друг за другом. Одна из связанных с локалями статей была оставлена на разделе с Линуксом, и я хотел открыть её в Австрии, которая просто полна тоннелей без интернета. Наше ядро не любит ext4; будучи слишком ленивым для перезагрузки, я решил "пришло то самое время", чтобы выяснить, почему.

Неудивительно. ext4 использует extents, которые в былые времена не поддерживались. Беглый взгляд на FreeBSD показал, что у них уже есть read-only поддержка, которая стала более-менее функциональной на моём ядре OpenBSD в среду вечером. Нет индексов каталога HTree, нет 64-битных номеров блоков, нет журналов или снапшотов, или защиты от мульти-монтирования. Но я мог наконец прочитать PDF без перезагрузки и затем даже скопировать файл, больше, чем 4 ГБ, или открыть каталог с 50 000 подкаталогов в нём. Никогда прежде не видя исходников файловой системы, я смог сделать рабочий порт за несколько часов? Жизнь прекрасна! ... [>>>]

This was my first hackathon so I wasn't really sure what to do. I had some plans to possibly import perl 5.20, but I was hoping to include 5.20.1 which isn't out for at least a month and espie@ says that it is too close to lock. I will continue to push local patches upstream to get everyone using perl on OpenBSD to be using the same improvements that are in our base perl.

I was sure some project would present itself that I really wanted to work on, so I started out by slacking and working on the tool I've been playing with to make generating ports for things that keep track of their dependencies and have automated installers, such as things from perl's CPAN or Node's NPM Perl support is pretty good, but both Python and Nodejs, while started have run into roadblocks due to the different ways they handle dependencies. Talked some to abeiber@ about how to solve the nodejs problem and it sounds like someone will have to end up patching npm to add support for features we need, mostly the ability to install dependencies offline. Still not sure how to ask python packages for a list of their dependencies so automating that has ground to a halt.

During the time I was avoiding reading npm source or better understanding Python's different package systems, I got the last few dependencies updated so that I can update DBIx::Class to the current version. I actually submitted that update, but zhuk@ mentioned that he has examples of how to start up local database instances with their datafiles inside of the port's ${WRKDIR} so that I can run "live" tests automatically. That sounds like a great feature so I will figure out how to accomplish that and update the port before re-submitting.

I did submit a few bugs to perl upstream while at the hackathon, reporting an issue that ended up being unsolvable due to the way perl buffers output and also adding configure glue and other things for pelikan@'s POSIX international currency formatting additions. I need to do a little cleanup on it, but that should go in soon. ... [>>>]

Ted Unangst (tedu@) talks about teduing a goodly amount of code, among other things:

Despite being in the same room as many other LibreSSL developers for the first time (since the beginning of LibreSSL at least), I didn't do too much work on that front. I did remove the compression feature (as made famous by the CRIME attack; not all protocols or deployments are vulnerable, but we're also aiming for a simpler feature set overall) and made a few other cleanups. While it's very helpful to be in the same room as other hackers to exchange ideas, having everyone pounding on the source at the same time is a little troublesome so I elected to stay out of the way.

I did, however, take the chance to bounce some ideas for a ressl API off the other developers. Instead of continuing to use the OpenSSL API, the ressl API is entirely separate. Internally, ressl itself uses the OpenSSL API, but the interface presented to the user is quite different. Our particular focus is on absolving the user of the need to know about X.509 and ASN.1 internals; instead you simply ask ressl to verify the remote peer's hostame. And actually, you don't even need to do that because that's the default behavior. (Un)fortunately, jsing@ liked the idea so much he ran ahead and implemented it before I got the chance. One of the dangers of being at a hackathon, I guess.

Besides that, I continued my hackathon tradition of deleting a lot code that most people probably never even knew existed. Say goodbye to asa, fpr, mkstr, xstr, oldrdist, fsplit, uyap, and bluetooth. Of these, you may possibly miss bluetooth support. Unfortunately, the current code doesn't work and isn't structured properly to encourage much future development.

I reviewed a few filesystem diffs from pelikan@ for ext2fs and tobias@ for msdosfs. At the beginning of the hackathon I showed some developers a diff that changes the buffer cache to using a 2Q like strategy. That's gone through a few iterations, but won't make 5.6. Expect to see it soon, though. ... [>>>]

g2k14: Jonathan Gray on driver improvements for X

Джонатан Грэй (jsg@) сообщил нам, почему он провёл 30 часов в автобусе, чтобы быть с нами:

Одной из первых вещей, которые я сделал в g2k14, был импорт обновления Mesa, над которым я теперь работал в течении некоторого времени. Я следил за git репозиторием Mesa несколько месяцев и отправлял патчи, чтобы уменьшить всю ту боль, причинённую локальным diffом, который не был таким большим, но приходилось тратить много времени на обновления.

Незадолго до хакатона я столкнулся с проблемой, заставляя Mesa собираться на i386, как бы то ни было. Это происходит только в том куске кода, который с помощью sysctl проверяет, включен ли SSE. Это, как оказалось, было проблемой, потому что sysctl.h включает в себя utm_extern.h, который, в свою очередь, берёт заголовочные файлы ядра, включая mutex.h, это означает, что mtx_init() из Mesa конфликтует с mtx_init() ядра. Тео потратил немного времени, вычищая sysctl и заголовки utm, таким образом, они не будут включать где-либо много определений. Эту работу уже закоммитили, когда я пришёл на хакатон.

На следующий день я сделал немного сборок xenocara, чтобы найти любые дополнительные проблемы. Проблема, которую я нашёл, происходила из-за симлинка в файл дистрибутива Mesa, который игнорировался cvs import, что починили ссылками из Make-файлов в другую директорию. Я также проверил дважды работоспособность сборок Mesa со включенным LLVM, который всё ещё работал через программный рендеринг LLVMpipe. ... [>>>]

As is now an habit, i had made zero plans for this hackathon, i had some unfinished stuff lying around, and no real big task ahead. Firefox 31 betas were already working for me, and only needed actual testing.

In the end, i spent quite a bunch of time doing some sysadmin stuff with ansible, with which i've really felt in love. Thanks to rpe@, we have a really up-to-date port, and it was the perfect occasion for me to reconfigure some of my infrastructure servers, starting by our test bulk cluster OPI - which can be now fully upgraded/reconfigured in a single ansible playbook task, taking care of all the steps to be able to run a bulk build. This will soon be featured in an article in a french newspaper issue about BSD systems. I'll really stress that ansible can be the perfect tool to remotely administer OpenBSD systems, only needing ssh and python on the remote machine, and the learning curve of the tool is really smooth.

I also spent some time digging in various pkg_tools/pkg_locatedb/pkg_check/sqlports/pkg_sign usecases, more material for another article in the same newspaper - along this, i had lots of questions for espie@, who still thinks his code is easy to understand to outsiders.. unfortunately, not everyone is as smart as him.

A hackathon wouldnt be one without some activity in mozilla's bugzilla, so i resumed pushing some patches that were still local and pending to reduce our count of local modifications - unfortunately, some last minute changes to our headers (read: endian.h) brought more patches to all our mozilla ports, and ruined my efforts :)

I tried porting the new mozilla sync server, since the one we have in-tree will stop working with gecko 31. Unfortunately, after 15 new ports of some python libs, and realizing i'd also need to port around a bazillions of node js modules, i totally gave up on this. I doubt this'll improve in the future, the new sync server is not really designed to be properly packaged, rather ran directly from a one-shot checkout of its sources. ... [>>>]

Матье "бешеный француз" Херб (matthieu@), поддерживающий Xenocara, хочет поделиться своими впечатлениями о g2k14:

Я так и ничего и не сделал по моим остальным проектам (мультитач, DHCPv6), поскольку был отвлечен на твики наборов для X, по просьбе нескольких других участников. After much discussion this only led to the addition of ucpp in base (after a short detour by /usr/xenocara/app/xrdb-cpp) as /usr/libexec/auxcpp.

Причина в том, что xdrb (часть необходимой многим портам xbase) требует препроцессор C для запуска. Но, начиная с gcc4, /usr/bin/cpp находится в наборе comp, потому что это просто часть gcc. Получается, набор xbase требует установленного набора comp.

Есть два типа людей, которых это раздражает: люди с маленькими дисками, и люди с фобией "компилятор на сервере? непостижимо!" (хотя эти люди правы: http://www.welivesecurity.com/2014/03/18/operation-windigo-the-vivisection-of-a-large-linux-server-side-credential-stealing-malware-campaign/)

Поэтому теперь auxcpp стал частю набора base. Прощай, зависимость xbase от comp. The X sets will stay in their current state for 5.6. Otherwise, I've done a few updates on xenocara components. Дерево xenocara практически готово для 5.6.

Но всё равно, мне понравился хакафон. Спасибо Мите и его команде за организацию, и всем благодетелям за пожертвования! ... [>>>]

http://www.welivesecurity.com/2014/03/18/operation-windigo-the-vivisection-of-a-large-linux-server-side-credential-stealing-malware-campaign/

Фетчится и убрано

This time around, we get to hear a g2k14 developer report from the one and only Martin Pieuchot (mpi@)

Since I never managed to do what I had planned during a hackathon, I came to g2k14 with a small guitar and an easy plan: play music and drink wine. As expected I didn't respect my plan at all, instead of wine I had beer and instead of playing music I hacked the kernel 8)

I started by fixing one of the two issues from our USB stack that prevent us from enabling xhci(4) in GENERIC (bug apart). This was mostly a plumbing task in order to handle the way xHCI assign device addresses.

Then I looked at the radix tree corruption reported by guenther@ that was caused by the addition of a local route for every configured IPv4 address. It turns out that there is a problem with nodes with a destination of 0.0.0.0, used by the default routes. claudio@ is still hunting in this area, and for the moment I committed a version of the diff ignoring such addresses.

In the meantime I did more plumbing and replaced the last offending shutdown hook, used by softraid(4), by a function called before tearing down the devices. This was a bit more complicated than expected because softraid has its own subtree of devices that do not see the DVACT_POWERDOWN event sent by mainbus at shutdown.

As a result of this work I could unify a bit more of the shutdown sequence with the hibernate one and fix a uhci(4) panic by preventing the thread doing the shutdown to sleep.

The next issues on my list were two HC transfer descriptors allocation problems reported by various users. With the help of kettenis@ I addressed the first one by making sure bus_dmamem_map(9) honors the BUS_DMA_NOWAIT flag, then the second one was fixed by performing a famous spl dance.

I also did some more plumbing in the autoconf(9) framework in order to kill the DVACT_DEACTIVATE event. Then I removed some old network types from our kernel.

Finally I spent my last days trying to find the simplest way to change some tty(4) line disciplines to not be re-entrant in order to make the com(4) interrupt handler MP safe. After various attempts, I found something :) ... [>>>]

Our second g2k14 report comes from Henning Brauer (henning@), who writes:

g2k14 has been weird: I, for the most part, wrote IPv6 code. No, that doesn't mean I'd suddenly think inet6 is any good. But let's start from the beginning.

I once again managed to miss arranging travel in time over way too much $work - but luckily found suitable (actually, even close-to-perfect) flights last week. Even affordable.

So I arrived monday evening. First I had a fix to vlan bpf on the radar - with the vlan changes I did in Morocco, the packets showing up via the bpf tap in vlan had the vlan ethernet header instead of the plain ethernet header that most consumers expect. Missed side effect of us prepending the vlan ethernet header right away instead of first preprending a regular ethernet header to only throw it away later and prepending a new vlan ether one. Now of course we don't want to throw away our shiny vlan ether header and again construct a new (real or very embryonic) ether header just to make bpf happy. The solution to that is a custom bpf copy function that just gets rid of the extra 4 bytes the ether vlan header has over the regular ether one. Before actually doing that I ended up cleaning up bpf.c quite a bit and cut a lot of duplicated code. Eventually got bpf_mcopy_stripvlan done without duplicating oh so much code again, it works as expected, the bug is fixed and bpf.c is much nicer than it used to be.

Then I mysteriously got sucked into netinet6. Years ago I added an interface flag, IFXF_NOINET6, to turn off inet6 per interface. Automagically adding an inet6 address just because an interface comes up is ridiculous and actually a security risk, since your machine is suddenly reachable over it (to some extent), which might not even be clear to the person taking the interface up. And it goes further, that automagic inet6 address even causes problems in some setups, e. g. with bridges. So we eventually decided to turn off v6 by default, which is how it should have been from the beginning - actively adding an inet6 address, manually or by running rtsol for autoconfig, turned it on and everything magically worked right. Without the implicit attack vector. So that is actually invisible to almost all that use inet6 - only those just using link-local, without any "real" inet6 address, had to adapt slightly. Pleasantly even the die-hard inet6 lovers in our group agreed with that move. ... [>>>]

Bob Beck (beck@) was the first developer to submit a report from the just concluded g2k14 hackathon:

Well, this was certainly not the hackathon I would have predicted several months ago for me. Had you asked me in January what I'd be doing here it would have been wading into uvm, kernel lock, buffer cache, and other such things in the kernel.

Then LibreSSL happened.

I've spent a bunch of time before the hackathon with Theo working out the details of entropy, and entropy devices on non-OpenBSD operating systems, in preparation for a LibreSSL portable port. I've spent my hackathon continuing some of the flensing of libressl, helping out jsing@ and miod@ to some extent. I've had a number of conversations on kernel issues, but by far, my time here has been spent with a bunch of different unixes in vm's, (I even booted Linux native on my laptops several times...) learning about automake and fun things that I thought only ports people used, and working with Brent Cook on LibreSSL portable. Brent has been a great guy to get to know, and has done a fantastic job of getting LibreSSL portable off the ground - and the result you see is two initial portable LibreSSL releases for people to start working with on other operating systems.

I'm spending my last little while going back to chasing more bad code out of LibreSSL, and working with Joel and Brent on things - Even though portable has been started and is available, that work is still far from "done", and the cleaning will continue

-Bob

I came to the hackathon with a single goal: working on the driver for the USB host controller interface found on the octeon machines.

I knew mpi@ would attend the event so that was a big plus. That meant that I could always reach him and bug him about how the OpenBSD USB infrastructure works and what's expected of the octhci(4) driver in different scenarios. Which, as I expected, ended-up being quite often.

I was pleasantly surprised when jasper@ asked me to share the serial to my DSR500 machine so that he could work on improving the boot(8) program that he started at t2k13. We had a lot of fun poking and discussing the different octeon issues that we ran into during the entire hackathon and people started referring to us as the octeon-team which was nice.

Things started moving once I managed to put together and understand the different logic and taxonomy between the OpenBSD's USB layer, the Cavium SDK and the actual USB 2.0 specification.

And so, I was confident enough to ask miod@ for permission to commit a work in progress driver. Now this stub of a driver was very powerful in that it managed to fry umass(4) devices immediately! So I made sure that it wasn't enabled by default and that the interrupt routine was disabled.

The next step was to add proper bus and hub routines that allowed the root hub to attach without a panic. Which was kind of nice as the dmesg(8) grew a bit:

octhci0 at iobus0 irq 56: core version 2 pass 3.5
usb0 at octhci0: USB revision 2.0
uhub0 at usb0 " octHCI root hub" rev 2.00/1.00 addr 1
uhub0: cannot open interrupt pipe
usb0: root device is not a hub

Afterwards I moved on to fixing the attach errors by adding proper root hub interrupt routines and filling in more bits and pieces in the HCI interrupt. That allowed me to enable the HCI interrupt which improved things a bit:

cthci0 at iobus0 irq 56: core version 2 pass 3.5
usb0 at octhci0: USB revision 2.0 ... [>>>]

A new developer with the OpenBSD project, Brent Cook (bcook@) writes in:

As unusual as it sounds for someone working with the OpenBSD project, I'm not primarily an OpenBSD user. I actually use a Mac and Linux equally, and even do fair amount of Windows development. Some might say my involvement was more of a survival of the fittest.

After Heartbleed, licking the fresh wounds at my work of updating all-the-things, and being continually annoyed at the build process of OpenSSL, I decided to take a stab (apparently, among many others) at porting LibreSSL, posting the early results to GitHub.

A few weeks go by and I suddenly see a lot of hits and referrals from the Insane Coding blog (after all, GitHub is great at helping you find your coding social network . What followed was a humbling experience, as I quickly learned to be suspicious of any and all portability code for other OSes.

I continued developing the port, occasionally pushing fixes upstream to the OpenBSD project that removed some BSDisms that were creeping in. Some patches were easily accepted, others were summarily rejected, but nothing that I wasn’t used to. My first Linux kernel patch fixing duplicate file handling in procfs was rejected with 'Doctor it hurts when I do this'

Fast forward to month ago while on vacation, and Theo starts emailing me suggestions about things to try in my port. Armed with just a pokey ARM Chromebook and third-world internet connectivity, I managed to start integrating what would become the getentropy(2) emulations and other improvements from the OpenBSD source tree, while my family was asleep. A short time after, I was invited to help work on the official port.

Apparently, I was the only 'unofficial port' maintainer that had actually continued maintaining his port and had actually done an OK job with it.

The hackathon was a whirlwind that accelerated throughout the week, as Bob and I went from nothing to an almost fully scripted integration and release system. We still have a lot of work to do, but it was rewarding getting the first couple of builds out the door and getting so much feedback. ... [>>>]

Long time listener, many time caller, Miod Vallat (miod@) writes in:

There are two kinds of hackathons.

Those were you pack your headphones, and don't use them. And those where you forget to pack them, and wish you hadn't.

As a veteran hackathon attendee, I packed my headphones, of course. And I was more than happy to keep them packed, as the pace of the hackathon was so hectic it was better to relax by talking to people than to relax by listening to music.

Although I had prepared a list of things to work on, it was not a surprise to me, that I ended up working on LibreSSL.

After all, it was the first time that the whole LibreSSL team (Bob Beck, Brent Cook, Joel Sing, Ted Unangst and I) could meet in person, and we rushed to get a portable release out of the floor (which, as far as I was concerned, mostly meant commiting a lot of bugfixes as well as merging changes in OpenSSL having happened now that the Core Infrastructure Initiative is funding them, and also merging a few BoringSSL changes to help sharing code between LibreSSL and BoringSSL in the long term).

Aside from this, I did a few commits to keep the kernel building (especially after one commit to kern_fork.c broke all our gcc 3 platforms).

As usual, kudos to Mitja and his helpers to make things run smoothly. The s2k11 hackathon, 3 years ago, was a success, and this one was on par with it, despite having twice as many developers attending.

I'm looking forward to the next hackathon in this place. In the meantime, I have bugs in LibreSSL to fix...

Sebastian Benoit (benno@) lets us know what he did to make his life easier at g2k14:

For me the hackathon started before arriving in Ljubljana. On my trip I noticed that there was something wrong with my ssh connections: some did not work. So I started debugging in Munich Airport and the result was a quick fix for a recent bug in ssh-add.

Very early on I asked reyk@ if we should try to get his long awaited filter rewrite for relayd commited. I had a list of problems i had noticed with it and when i got my hands on his most recent version I started to go through them. Some where already fixed and others were quickly corected. So after a day he was able to commit his big diff and further work on it commenced in the tree. I also added a port for relayd-updateconf, a tool written by Andre de Oliveira (andre@) that helps migrating to the new relayd.conf syntax.

florian@ was sitting nearby and worked on merging ping and ping6, sending some diffs to me. He noticed the ping6 options for ipv6 node information queries and our support inside the kernel for answering them. We both thought that we didn't like that kind of information leakage and others agreed. As a result, rfc4620 support was removed from the kernel.

I also worked on some other things and ideas that had been bugging me for some time, for example that conserver was running as the root without any need for it. With some feedback from sthen I updated the port. And I still have two other diffs waiting for oks.

g2k14 was an awesome hackathon, and I really got to do some hacking without the distractions of normal life.

This hackathon started out for me with my usual routine of fixing some bugs in Puppet, add more facts to Facter and dig into pkg-config.

So started out in fixing an issue in Puppet where multi-flavored packages couldn't be updated and along the way I added support for the structured 'partitions' fact in Facter.

A few weeks ago Stuart Henderson (sthen@) found several issues in pkg-config when it had to compare OpenSSL-like versions (1.0.1g > 1.0.1e). After I added the regress tests the issue was quickly fixed, a hackathon isn't complete for me without fixing at least one pkg-config issue..

Most of the hackathon I've spent tidying the bootloaders MD parts and make certain functions MI which can be shared between bootloaders. This started out as a distraction from my work on the OpenBSD/octeon bootloader.

Last year in Toronto I committed a collection of stubs for the bootloader, but I quickly ran into a misbehaving bootprompt. Both Paul Irofti (pirofti@) and myself couldn't quite figure out what was going on with the UART until Miod Vallat (miod@) helped to debug the issue; with that the bootprompt works reliably. We still cannot load a kernel yet, but most other parts (timeout, boot_info/boot_desc passing, root device decoding) are implemented. Next step would be to add support for loading a kernel off an internal CF card. One thing that Miod said about writing a bootloader quite stuck with me, it was along the lines of: "There's no beauty prize at the end and you only know what needs to be done when you're finished."

Thanks again to Mitja for the great organization and setup.

In the week right before the hackathon, I have done quite a bit of work cleaning up mandoc(1) warning and error messages. The goal is to provide more, more precise, and more readily understandable information to the user, in particular mentioning in the messages which section titles, macro names, and arguments each individual message is related to, and which workaround or fallback mandoc(1) has chosen, if any.

Also, I'm trying to use descriptive rather than imperative style wherever possible and unify the wording for similar issues. Some messages clobbering together unrelated kinds of issues were split, some bogus messages deleted, some overblown ones downgraded, in some cases from FATAL to a mere WARNING. In the process of looking at almost all messages, I fixed more than a dozen parsing and formatting bugs along the way, and i started providing regression tests for messages, cleanly integrated into the well-known OpenBSD /usr/src/regress/usr.bin/mandoc/ regression suite. This cleanup is not quite complete yet, but the bulk of the work has been done, maybe about 75% so far.

On the OeBB Eurocity train to Ljubljana, I already started working on man.cgi(8), the CGI interface to search and display manual pages on the web, upgrading the old Berkeley DB version rotting in the mdocml.bsd.lv tree to use the new mandoc 1.13 SQLite backend we have in OpenBSD, so I could commit a first working version to bsd.lv on the first morning in Ljubljana.

After simplifying the server directory structure, the manpath.conf configuration file format, and the URI scheme, I imported the source code into the OpenBSD tree and continued development there. The main user-visible progress this week is to cleanly distinguish between man(1) and apropos(1) mode. In man(1) mode, which is the default, we now always show an actual manual page, in addition to links to other pages of the same name, if any. The search form was polished using feedback from Bob Beck@ and others. Besides, there were lots of small improvements behind the scenes: ... [>>>]

I arrived in Ljubljana somewhat tired so I started the first day off with some light ping(8) and ping6(8) hacking. Some unifdef(1) application for
#ifdef FEATURE_THAT_EXISTS_SINCE_FOREVER_BUT_MAYBE_WE_DONT_HAVE_IT and some cleanup by hand. The idea is to have ping(8) and ping6(8) be the same binary like traceroute(8) and traceroute6(8).

It has been clear for some time that the ping(8) merge would be harder than the traceroute(8) merge so I stared at the command line flags matrix I prepared some time ago (http://sha256.net/dump/ping_vs_ping6.txt) to figure out what to do about the colliding flags, i.e. '-I'.

On the second day I still had no clear idea what to do about the colliding flags besides that ping6(8) needed to change and not ping(8). It's used in scripts which must not break while ping6(8) is probably used far less, especially the obscure flags which I need to move around.

So to not get stuck I switched to my PowerDNS 3 port I have been working on and off for a year now - you can guess that it's always at the bottom of my todo pile. After finding some bugs earlier this year in PowerDNS itself the port was ready and I mailed it around - but then I noticed that the rundeps were missing for somewhat important dependencies like boost and botan. Having received no feedback for my mail on ports@ it dropped back to the bottom of my todo pile.

So now I'm at a hackathon and there are ports people around. I went and bothered naddy@. He had a quick look, "Oh yeah, you need to do this and that" and lo and behold it works. Boy, it's a lot easier when you know what you are doing...

With that sorted out, back to ping6(8) for me. I (re-)discovered the Node Information queries (RFC 4620 http://tools.ietf.org/html/rfc4620, ping6 -w). I played with them before, but couldn't get an answer from an OpenBSD machine, so I figured that feature doesn't exist in OpenBSD's kernel. I tried again at the hackathon and suddenly I got answers. Uh oh. (There was probably a firewall in the way or something like that when I tested it before.) ... [>>>]

I spent most of this hackathon looking at problems in wifi drivers.

I wasn't exactly sure in advance which problems I wanted to work on. So I packed a bunch of hardware, including several USB wifi adapters, (rsu(4), 2x run(4), rum(4), urtwn(4), zyd(4)), some miniPCIe cards (an unsupported cousin of urtwn(4) named Realtek 8188CE, unsupported athn(4) AR9485, bwi(4)), two laptops, and an access point. This left me with more than enough toys for a week.

I also brought a pcengines APU board which was given to me by Remi Locherer and mijenix (thanks!). It had arrived in the mail just a day or two before I started travelling. At the hackathon, kirby@ added some miniPCIe cards to my collection, ath(4) AR5424 and ral(4) RT3090.
I assembled the APU together with florian@ and ended up plugging the ath(4) and ral(4) cards into it first.

AR5424 turned out to be a problematic card ("ath0: unable to reset hardware; hal status ..."). This card has never been working, and searching mailing list archives turns up various reports* and** attempts*** of fixing the driver. I ended up hacking the driver for about two days, trying out changes based on information found in Linux and FreeBSD, with hints from reyk@. It turns out this is an 11g only card and should start working once ath(4) 11g mode is fixed (another known issue).

I put ath(4) aside for something more fun. Theo told me of a rather frustrating experience at a conference which had two wifi networks, both using the same SSID and the same encryption key, with one using WEP and the other using WPA. As a small step towards better usability, I made information about wifi encryption ciphers available to userland, and based on this changed ifconfig(8) scan to display the type of encryption used by wireless networks.

While testing my scanning changes I managed to make all USB ports on my laptop unusable by plugging in the zyd(4) device. mpi@ helped me track this down to race conditions in zyd(4)'s register i/o implementation which could end up dead-locking USB kernel threads. This took some time since the device occasionally stopped working entirely for mysterious reasons which we ended up blaming on broken hardware. Quite possibly the bug would not have triggered with a properly working device, though. ... [>>>]

Having missed Ljubljana 1, I looked forward to Ljubljana 2 with great expectations. I was not disappointed! Mitja ran a great hackathon with a nice site and an excellent city around it.

I arrived with a bunch of M's in my tree that had been making no headway against the LibreSSL gale. Mostly to do with fixing daemons using IMSG, and in particular msgbuf_write(). I found that standing next to the relevant developers and looking sad was very effective and got all the M's resolved. At which point claudio@ pointed out they could all be improved futher. Sigh.

In addition, I noticed that dhclient(8) was writing out resolv.conf(5) a few more times than necessary (twice when binding and once when going away) and I got that down to once. Unfortunately killing several developers' machines by inducing hard renew loops for a while. But it was a hackathon, so that was ok.

I worked with yasuoka@ to get some of his dhcpd fixes and enhancements in, and adapted a fix he had received for dhclient handling of classless routes.

I also committed the dump(8) fixes for 4K sector devices. A bunch of msdos and ffs fixes from tobias@ also got my oks, as did some initial GPT support from Markus Mueller, one of our GSOC students.

Речь об исчерпании лимита на количество открытых файлов, которое в
случае использования syslog(3) могло привести к тому, что сообщения об
ошибках не попадут в системный журнал. Дело в том, что syslog(3)
оперировал через открытие файла /dev/log, которое, в случае исчерпания
оных лимитов, становится невозможным.

24.Вес измеряется в ...
Мегабайтах
Метрах
Килограммах
>(все вышеперечисленное)
* В магазине - в килограммах, в компьютерах - в мегабайтах (они же метры)

30.Чей скл?
>Мой!
Немой!
А че сразу я?
А у вас нет такого же, но с перламутровыми пуговицами?
* Популярная СУБД для Internet зовется MySQL - (МойСКЛ)

31.NT3,NT4,XP и
95
98
ME
>2000
* Windows NT3, NT4, XP и 2000 принадлежат к семейству NT. 95/98/ME принадлежат к семейству 'маздай однодневный висючий'

44.WinPopup - это ...
Программа для блокировки баннеров
>Программа для обмена сообщениями
Церковная надстройка для Windows
Windows без цензуры
* Winpopup - входящая во все версии, начиная с 3.11, программа для обмена коротенькими сообщеницами по сети.

101.Сколько пробелов вместится в стандартном текстововом разрешении?
1000
1600
>2000
307200
* Стандартное текстовое разрешение - 80x25. 80*25 = 2000

116.В честь кого назван хедер .exe файла?
Билла Гейтса
Луи Гестнера
Пола Аллена
>Марка Збриковски
* И по сей день мы можем наслаждаться инициалами MZ в начале каждого EXE-файла

123.Третья бета Чикаги звалась? ... [>>>]

Буду занудствовать, боюсь, в основном по части языка - гены пальцами
не задавишь... Поехали:

Общее замечание: написание названий. "kde4" - только если говорим о
каталоге в дереве портов, или о "kde4.port.mk". Когда речь идёт именно
о релизах KDE, то пишется "KDE4": "портирование KDE4", "выпуск KDE4",
"входит в состав KDE4"; но: "импортирован в каталог
x11/kde4/artikulate". Аналогично с "openbsd" - ОС пишется "OpenBSD".

"официальный анонс (чего?)" - KDE 4.13.3. Разработчики KDE дают
возможность мейнтейнерам пакетов с KDE в той или иной ОС иметь т.н.
предварительный доступ, где-то дней за 3-5 до официального релиза. Это
позволяет выпускать "родные" пакеты с KDE для ОС одновременно с
официальным анонсом релиза. К сожалению, в этот раз совсем
одновременно не получилось, из-за накладывания сего момента с
процессом перемещения тушки в направлении Любляна-Хельсинки-Москва, а
так же с необходимостью быстро влиться обратно в рабочий процесс. :)

"Но, по факту,.." - лучше "Но прежде всего" (запятые вокруг "прежде
всего" можно опустить в данном случае, так как они фразу больше
портят).

"... по openbsd..." - лучше "связанным с OpenBSD", а ещё лучше - пока
не придумал. ... [>>>]

Ещё после этого akonadi_maildir_resource перестал жрать ресурсы: похоже, он страдал той же проблемой. Две проблемы по цене одной! Покупайте наши libinotify!

Кроме того, в этом хакафоне я успел доделать:
* новую утилиту portbump(1), в связке с sqlports это поможет сэкономить много времени на масштабных обновлениях
* добавил переменные TEST_ENV и ALL_TEST_ENV в bsd.port.mk: одного TEST_FLAGS было явно недостаточно, поскольку некоторые порты, на CMake (читай: использующие Ninja) не понимают TEST_FLAGS вообще
* документацию для devel/cmake и x11/kde4. Не имею намерения документировать x11/kde, потому что больше никто не развивает его, а те, кто знают, как его поддерживать - и так всё знают.

К сожалению, не хватило времени на samba4. Есть хитрые проблемы, связанные с ld.so и компилятором, которые я надеялся исправить на хакафоне... но не всё сразу. Так или иначе, KDE был приоритетной задачей.

С другой стороны, я был вовлечён в несколько дискуссий и протестировал несколько патчей, летающих повсюду. И, даже в случае ошибок, мне доставлял радость тот факт, что я могу помочь другим разработчикам OpenBSD напрямую, что, как правило, проблематично в обычной жизни.

И, в заключении, я хочу (точнее, обязан) сказать спасибо Mitja Muženič и Dijaski dom Tabor за организацию этого чудесного мероприятия. Это был мой первый хакафон, и было удивительно, сколько всего произошло за несколько дней. И Любляна - прекрасный город... Я надеюсь что кто-то, кто знает английский язык лучше меня, мог бы лучше в красках живоописать этот уютное место и его жителей. Всё было просто классно - спасибо, спасибо и еще раз спасибо! ... [>>>]

по второму кругу голосования, на очень малом количестве участников, статистика такова:

Страшное ругательство идэдэкудэ пришло к нам из:
Wolf: 2.4%
DOOM: 81.0%
Duke: 11.9%
Quake: 4.8%

Билл Гейтс сказал ...
Windows - наш путь к коммунизму!: 2.4%
Бесплатный софт - маздай!: 2.4%
640 кб хватит всем!: 95.1%
Товарищи! Мы пойдем другим путем!: 0.0%

Процессоры K5 и K6 выпускала компания...
Intel: 12.8%
Cyrix: 20.5%
AMD: 64.1%
Кировский тракторный завод: 2.6%

ИБМ означает (l)
Интернал Бэйсик Мэньюал: 2.7%
Интернешнл Бизнес Машинз: 97.3%
Итальянская База Мафии: 0.0%
Иранская Банда Минеров: 0.0%

Третья версия Нортона занимает в памяти (l)
3 бита: 5.6%
0,554 гигабайт: 2.8%
12896 байт: 91.7%
9995 сантиграммов: 0.0%

1+1= (l)
3: 8.3%
0: 13.9%
1,99: 2.8%
10: 75.0%

Тарапунька и Штепсель - это (l)
маньяки: 2.8%
хомяки: 8.3%
комики: 72.2%
элементы процессора Пентиум: 16.7%

Жесткий диск (l)
лучше, чем мягкий: 3.0%
лучше, чем гибкий: 93.9%
это старое название граммпластинок: 0.0%
это то, во что превращается пачка гибких, если ее оставить на солнце: 3.0%

Сколько нужно программистов для замены лампочки? (l)
Ни одного, это задача электронщиков: 78.8%
Ни одного, программисты не умеют этого делать: 3.0% ... [>>>]

ну, по хорошему, надо все и перевести и причесать... я, как доперевожу свою (кстати, что значит этот host в kded?), попробую и эти литературно обработать, чтобы повеселее стали :)

откуда дубли? за повтор - уберу гейт