g2k14: World of KDE4, Vadim Zhukov (zhuk@)
Contributed by pitrh on Tue Jul 15 09:43:45 2014 (GMT)
from the dragons or cogwheels dept.

Hot on the heels of a successful hackathon, Vadim Zhukov (zhuk@) wrote in with this report on his efforts:

I came to hackathon with a short but heavy TODO list:

1. Finish KDE 4.13.2 and prepare 4.13.3 (official announce to be done Jul 15);
2. Import at least some stuff from semi-official openbsd-wip ports repository to official CVS;
3. Fix the long-standing issue with kded4 constantly eating CPU;
4. Continue hacking on Samba 4.x;
5. Enable ext2fs in RAMDISK_CD for amd64.
6. Put in CVS some stuff under ports/infrastructure/ I've developed for last months.
7. Put in CVS the man-pages-posix port.

But in fact hackathon starts from meeting people you didn't met before. Given that the only OpenBSD event I was before was EuroBSDCon 2013, there were many new faces. I'm afraid that I didn't remembered everyone at once, but that's not because I don't respect them or their work and just due to my shortcoming. :)

So the hackathon started. Both me and kirby@ - another OpenBSD porter from Russia - sat in front of each other. And this was very helpful - he helped me with testing ext2fs kernel build and gave an idea about libinotify (see below), and I helped him in updating rawtherapee port.

My first hackathon commit was importing books/man-pages-posix port. This is a handy tool for developers, I received some positive feedback even before the port was imported. But this was not my work - a lot of invaluable input was given by schwarze@ and others. I learned many new things about mandoc, groff and pkg_create magic while working on this port. But, again, this was just for starting.

Most of the time I was sitting and doing four things, though: running make, tweaking patches, pushing them upstream and spamming landry@ with new ports. I should thank him again for his patience in this process. Thanks to his reviews we now have the following KDE4 software: Calligra suite, Digikam, K3b, Kdenlive, KDevelop, KMyMoney, KTorrent, Tellico and Yakuake (together with a couple of their dependencies like Eigen 3.x).

The only KDE4 ports left in WIP repository is audio/cantata: it has somewhat wry KDE4 integration layer, so I quickly loose interest in spending time on it, given number of audio players out there, including KDE ones. I hope Rafael Sadowski, who assisted me many times, don't feel offended. :)

The KDE 4.13.2 update part is boring and uninteresting. You have 200+ ports, you type 200+ times "make configure update-plist port-lib-depends-check package clean", you push some patches upstream, you're done. That's all. Really. Hard parts were initial work and making KDE3 and KDE4 co-exist; maintaining KDE4 is not that hard.

And then came a really interesting part related to kded4. If you're not aware of details, here they are. kded4, which stands for "KDE 4 Daemon", is an app started (usually) by kdeinit - i.e., either at the beginning of KDE session or together with first KDE app you run during any X session. This daemon hosts so-called KDE modules - if you seen services.exe on Windows, you'll get the idea, it's almost the same. Also, another function of kded4 is monitoring of system configuration files, especially MIME-related .desktop ones. When you install/configure/deinstall application, .desktop files are tweaked, either system ones (under /usr/local) or your personal (under $KDEHOME). Many programs, especially different desktop widgets (read: KDE menu and similar), are interested in notifications about such changes. Thus, kded4 monitors a couple of directories for addition/modification/removal of .desktop files.

This process was very ineffective on OpenBSD. And the reason is that kded4 internally uses KDirWatch, which defaults to inotify-based mechanism on Linux and to QFSWatch-based mechanism on other systems. It also supports FAM, but I already tried to use the latter once and I was unsatisfied. I started to think about implementing kqueue backend, and at this time I remembered kirby@'s work on getting in libinotify. Which is actually what I wanted - an inotify API based on kqueue. So I wrote a FindInotify.cmake which should work on both Linux and non-Linux OSes, tweaked a few #ifdef's in the code, rebuilt kdelibs... and here we are! kded4 checks files at startup and the remains totally silent!

Even more, this also helped to stop akonadi_maildir_resource eating CPU as well - it looks like, they suffered from the same problem. Two problems gone for the price of one! So libinotify was a really good deal. :)

Other things I finished at hackathon, were:
* New portbump(1) utility for port developers, in conjuction with sqlports it could save a lot of time on massive updates.
* Addition of TEST_ENV and ALL_TEST_ENV variables to bsd.port.mk: TEST_FLAGS was not enough because some ports, like CMake-based (read: using Ninja) ones won't understand TEST_FLAGS at all
* Documentation for devel/cmake and x11/kde4 modules. I don't plan to document x11/kde module because noone is developing for it anyway, and there are enough people already knowing it well to maintain existing KDE3 ports.

Unfortunately, I didn't got time to hack on Samba4. There are tricky problems involving ld.so and compiler internals which I hoped to manage at hackathon, but you can't have it all at once. And KDE was my priority anyway.

On the bright side, I was involved in some discussions and tested a few patches flying around. And even in case of errors it made me happy that I can help other OpenBSD developers directly, which is usually problematic in my day life.

In conclusion, I want (need, should) thank Mitja Muženič & and Dijaski dom Tabor for hosting this wonderful event. It was my first hackathon and it's amazing how much stuff happened in a few days. And Ljubljana is such a lovely place... But I hope someone who knows English better than me would portray this cozy city and people there. Everything were excellent - thanks, thanks and thanks again!

g2k14: World of KDE4, Vadim Zhukov (zhuk@)

По горячим следам успешного хакафона, Вадим Жуков (zhuk@) отчитался о своих успехах:

Я прибыл на хакафон с коротким, но суровым списком задач:

1. Закончить KDE 4.13.2 и приготовить 4.13.3 (официальный анонс (чего?) - 15 июля)

2. Наконец-то портировать несколько приложений из openbsd-wip в официальный cvs?

3. Исправить давнюю проблему с усиленным поеданием процессора в kded4

4. Продолжить работу над Samba 4.x

5. Исправить проблему с отсутствием ext2fs в установщике для amd64 (RAMDISK_CD)

6 и 7. что-то про политику, про Путина :)

6. Занести в CVS некоторые вещи для ports/infrastructure, которые я разбабатывал последние месяцы (ничё не понял, потом разберусь)
\
7. Занести в CVS порт man-pages-posix

OpenBSD project leader Theo de Raadt (deraadt@) writes in from g2k14:

In the two weeks leading up to Slovenia I worked with Bob Beck on the replacement functions that would be needed to emulate getentropy(2). During the start of the hackathon there was a final bit of work to ensure Bob and Brent Cook were on their way with that.

Then it was time to attack a new security issue I have become aware of. Apparently file descriptor exhaustion can be used to hide reporting of buffer overflows by the stack protector. The stack protector guard function needs a file descriptor to report failure. Some of you who have been following blogs about arc4random and getentropy will recognize this issue.

This issue was first made apparent due to the systrace sandbox technique now used in the ssh tools, which prevents syslog_r from doing socket, connect, sendto.. all the good system calls necessary to report failure, but dangerous -- and precisely what the sandbox is trying to prevent.

This has been solved by creating a new system call that can send a message to syslogd without needing any additional resources; syslog_r(3) then uses this directly, one shot, fire and forget. The system call is rather narrow in purpose, and thus named sendsyslog(2), but this also fits the narrow use case it will have such as sandboxing.

In that regard, it is quite similar to the way getentropy(2) was carved off sysctl. Funny how one thing leads to another.

Taking a break from the kernel space, it was time for some cleanup and hopeful improvement for /etc, sysmerge, and the installation tools. Robert and Antoine helped out with a plan to mostly empty /etc/rc, this work is not yet finished but will lead to an improved sysmerge. On other fronts, I worked with the install script guys and the DRM guys to make sure that our next release can automatically know to leave the X aperture closed for capable chipsets.

Remainder of the hackathon I flitted here and there, as usual, participating in projects of other developers. A very enjoyable and productive week!

6. Некоторые вещи, которые я разбабатывал последние месяцы для ports/infrastructure, занести в CVS

Но, по факту, хакафон для вас начинается со знакомства с людьми, с которыми вы не были прежде знакомы. Учитывая, что до этого единственным мероприятием по openbsd, где я был, было EuroBSDCon 2013, было много новых лиц. Я боюсь, что я не запомнил их всех, но не потому, что я не уважаю их илиих работа, это просто мой недостаток :)

Итак, хакафон начался. Мы с kirby@ - другим портером OpenBSD из России - сели друг напротив друга. И это нам очень помогло - он помог мне тестить сборку ядра с ext2fs и дал мне идею насчёт libinotify (см. ниже), а я помог ему обновить порт rawtherapee.

Мой первый коммит на этом хакафоне был импортированием books/man-pages-posix. Это полезная вещь для разработчиков, и я получил положительные отзывы ещё до того, как начал импортирование [мне не нравится вообще слово импортирование, надо как-то заменить в обоих случаях].

Но это не моя работа - неоценимый вклад внёс schwarze@ и другие. Я узнал много нового о mandoc, groff и pkg_create [узнал много нового о магии mandoc, groff и pkg_create, или только о pkg_create? ох уж этот английский язык] во время работы над этим портом. Но, опять же, это было только для начала.

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

В двух неделях до Словении я работал с Бобом Беком над заменяемыми функциями, которые будут необходимы для эмуляции getentropy(2). Во время начала хакатона шёл окончательный этап работы, чтобы гарантировать, что Боб и Брент Кук были на их пути с этим.

Потом пришло время напасть на новый вопрос безопасности, который я узнал. Очевидно, дескрипторное истощение файла может использоваться, чтобы скрыть сообщение о буферных переполнениях защитника стека. Функция охраны защитника стека требует файловый дескриптор, чтобы сообщить о неудаче. Некоторые из вас, кто был подписан на блоги arc4random и getentropy, признают эту проблему.

Эта проблема была сделана очевидной из-за метода песочницы systrace, теперь используемого в ssh инструментах, который препятствует тому, чтобы syslog_r открывал сокет, соединялся, отправлял.. все хорошие системные вызовы, необходимые, чтобы сообщить о неудачах, но опасные - и точно те, что песочница пытается предотвратить.

Это было решено созданием нового системного вызова, который может отправлять сообщение syslogd, вообще не нуждаясь в дополнительных ресурсах; syslog_r(3) тогда использует его непосредственно - один выстрел, огонь, и забыли. Системный вызов довольно узок в цели, поэтому назван sendsyslog(2), но это также соответствует его узкому случаю использования, который он будет иметь как в песочнице.

В том отношении, это подобно пути getentropy(2), который вырезали из sysctl. Забавно, как одна вещь приводит к другой.

Делая перерыв от пространства ядра, это было время для некоторой очистки и обнадёживающего улучшения для /etc, sysmerge, и для средств установки. Роберт и Антуан, который помог нам с планом для почти пустого /etc/rc, эта работа ещё не закончена, но приведёт к улучшенному sysmerge. На других фронтах я работал с парнями, что занимались установочными скриптами и с теми, что работали с DRM, чтобы удостовериться, что наш следующий релиз сможет автоматически знать, как оставлять апертуру X закрытой для совместимых чипсетов.

В остаток хакатона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!

Большую часть времени я сидел и делал четыре вещи: запускал make, твикал патчи, пушил их в апстрим и спамил landry@ о новых портах. Я благодарен ему за терпение. Благодаря его замечаниям, у нас теперь есть следующие приложения из KDE4: Calligra suite, Digikam, K3b, Kdenlive, KDevelop, KMyMoney, KTorrent, Tellico и Yakuake (вместе с зависимостями, типа Eigen 3.x и другими).

Из kde4 в openbsd-wip осталась только audio/cantata: она имеет несколько кривую интеграцию с KDE4, так что мне быстро это надоело - плееров, в том числе для kde4, и так хватает. Надеюсь, что Рафаэль Садовский, который постоянно мне помогал, не обидится. :)

Обновление KDE 4.13.2 скучно и неинтересно. Есть 200 + портов, 200+ раз написать "make configure update-plist port-lib-depends-check package clean", запушить несколько патчей в апстрим, закончили упражнение. Вот и все. Реально всё. Проблемой было создание порта и задача совместного существования kde3 и kde4, а сама поддержка порта kde4 не так сложна.

Martin Pelikan writes in with this report from g2k14:

My initial plan was to bring our base to a state where LLVM's libcpp could be compiled, giving us C++11 support. After I read up on the latest POSIX locale additions, other developers made it clear that more library version cranks will be necessary in order not to break ports. After the first diff was ready, I set up a base system build to check if it breaks. And then my life has changed...

Few days before the hackathon I decided to reinstall my laptop and put Linux, Windows and OpenBSD next to each other. One of the locale-related articles was left on the Linux partition and I wanted to open it in Austria, which is just full of tunnels without the internet. Our kernel didn't like the ext4; being too lazy to reboot, I decided to take a look at it "if I have a spare moment", which base builds certainly are.

No wonder -- ext4 uses extents, which weren't supported at that time. Quick look at FreeBSD showed they already have read-only support which became more or less functional on my OpenBSD kernel on Wednesday evening. No HTree directory indexes, no 64-bit block numbers, no journal or snapshots or multi-mount protection. But I could finally read the PDF without rebooting, and then also copy a file bigger than 4 GB or open a directory with 50,000 subdirectories in it. Never even looked at filesystem code before, and now a working port in a few hours? Life was great!

The question now was how to integrate it. OpenBSD developers don't like huge diffs for a very good reason. After fixing the inode format and adding new flags, Ted pointed out the ancient rule "whoever touched it last now becomes the maintainer" was valid even here. It was obvious I had to gain more knowledge by reading design papers and other systems' code before I can do valuable and correct commits. Legacy remnants like hard-coded (and wrong) limit on file sizes went first. Parts of the code were pretty badly comprehensible but FreeBSD has managed to split them up somehow. After our code paths looked similar enough, the ext4 extent support hit the tree.

Despite the fact that hackathons' purpose should be to write code, I had to literally learn to work with a subsystem I've only seen very vaguely once before (with FUSE). Because FreeBSD has already had these bits and getting them to work was so easy, this was a very good place to learn how to write filesystem code myself. During the next days I wrote code parsing and following the journal and ended up deliberately breaking my filesystem to observe what should we do about recovering it in seconds and how to order writes to support them in the future. Let's try to continue going down this road.

All this wouldn't have been possible without Phillip Guenther who reviewed my diffs after I kept distracting him from way more important things to do. Ted, Theo, Ken and Bob gave me lots of valuable input and explained how are things supposed to really work. Stephan Sperling gave me access to one of his sparc64 machines and gladly kept the tree up-to-date, so my breakages were relatively few and minor. Discussions about the network stack helped narrowing our focus to a direction and explaining our concerns about other solutions. Mitja must have been very busy with organizing the event so that things would go as well as they did. Well done everyone, thanks!

Now let's hope this filesystem enthusiasm will last longer, because now I need to switch back to GSoC in an area I'm already familiar with. Breaking my filesystem now will hopefully help repairing yours one day...

И вот пришло время для действительно интересненького. kded4. Если вы не в курсе подробностей: kded4 (что означает "KDE 4 Daemon") обычно запускается с kdeinit... то есть, либо в самом начале сессии kde, либо когда вы запускаете первое приложение KDE. Этот демон hosts[содержит???] так называемые модули KDE - Если вы видели services.exe по Windows, то вы понимаете, о чём я, это почти то же самое. Другая задача kded4 - мониторить файлы конфигурации, особенно MIME .desktop файлы. При установке/настройке/удалении приложения, .destkop-файлы могут изменяться, как системные (в /usr/local), так и ваши личные (в $KDEHOME). Многие программы, особенно различные виджеты рабочего стола (читай: KDE-меню и подобное), заинтересованы в уведомлениях о таких изменениях. Таким образом, kded4 контролирует некоторые директории на предмет добавления/изменения/удаления .desktop-файлов.

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

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

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

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

Теперь вопрос состоял в том, как его интегрировать. Разработчики OpenBSD не любят гигантские diffы, и на это есть серьёзное основание. После починки формата inode и добавления новых флагов, Тед указал на древнее правило "кто бы ни коснулся его теперь становится мейнтейнером", оно было действительно даже здесь. Это было очевидно, что я должен был получить больше знания, читая тексты дизайна и код других систем, прежде чем смогу делать ценные и правильные коммиты. Сначала пошли устаревшие остатки, похожие на трудно (и неправильно) закодированный лимит размеров файлов. Части кода понимались с трудом, но FreeBSD удалось их разделить, так или иначе. После этого наши пути кода выглядели достаточно похожими, поддержка ext4 поразила дерево.

Несмотря на то, что цель хакатона была в написании кода, я должен был буквально учиться работать с подсистемой, которую я видел очень неопределённо до этого однажды (c FUSE). Поскольку, у FreeBSD уже были эти биты, и заставить их работать было так просто, это было очень хорошее место, чтобы научиться писать код файловой системы самому. В течение следующих дней я написал парсинг кода, и, следуя журналу, закончил тем сознательно, ломая мою файловую систему, чтобы наблюдать то, что должны мы делать, восстанавливая её в секунды, и как сделать поддержку записи в будущем. Давайте попытаемся продолжить идти по этой дороге.

Всё это не было бы возможно без Филипа Гуентэра, который рассмотрел мои diffы после того, как я продолжал отвлекать его от более важных дел. Тед, Тео, Кен и Боб дали мне много ценного и объяснили, как вещи должны работать. Стефан Сперлинг дал мне доступ к одной из его sparc64 машин и с удовольствием держал дерево актуальным, таким образом, мои поломки были относительно небольшими и незначительными. Обсуждения о сетевом стеке помогли сузить наш фокус в направление и по поводу других решений. Митжа, должно быть, был очень занят организацией встречи, чтобы дела шли так, как им положено. Каждый всё сделал отлично, спасибо!

Теперь давайте надеяться, что этот энтузиазм насчёт файловой системы продолжится дольше, потому что я теперь должен переключиться назад на GSoC - в область, с которой я уже знаком. Порча моей файловой системы сейчас, надо надеяться, будет когда-нибудь помогать чинить вашу...

Yet another report from the recently completed g2k14 hackathon, this time from Marc Espie (espie@) who writes

First time in Slovenia. Took a few hours off to see the city, managing to escape the thunderstorms. Somewhat interesting mix, never seen that mixture of eastern european, southern europe, and tourist places.

As for the hackathon, I came in right after a big change (reordered packages), and I was mostly ready to fix things if necessary. To my surprise, it worked like a charm... If I broke something, nobody noticed a thing (and you guys are going to enjoy faster updates).

After much nagging, Vadim Zhukov finally committed a digikam-kde4. I did crash-test the build, and inundated him with bug-reports that he fixed quickly.

I worked on a few small things... noticed a lot and fixed a wee little bit of the usual ports tree breakage related to those fearless source hackers (mostly libressl, endian.h and mesa updates fallout).

I worked on a new mechanism to ensure package snapshots consistency. Quirks now reports its signature date (which is itself checked, so you can't tamper with it), so you can know whether the snap is recent or whether someone has been hampering it to come to your favorite mirror...

... and quirks itself contains a list of vulnerable packages, which will raise a red flag if you need them, and they're NOT on your favorite mirror.

All of this is just indicative for the user, as the snaps still take a long time to fan out... we have ideas to help with THAT specific problems, but after discussion with the interested parties, it won't be deployed before the next release is out, as it would be too disruptive.

I also tried to fix a problem with ports build requiring src to be present for pkglocatedb. Much to my surprise, theo agreed, and we went further than anticipated, so the snaps now ship with locate dbs for src AND X.

I spent a lot of time playing with that: pkg_check now uses it, and actually will check your full file system. It's a bit too verbose still, but getting there.

Accordingly, I spent some time killing some old code. It's not as sexy, but it's possibly the most important part of the process, ensuring we don't run stuff that's no longer needed/maintained...

I should also mention importing a stand-alone cpp to deal with calendar and xrdb, eventually, so that X will no longer require you to install comp.

As usual, seeing fellow developers face-to-face was a great help in getting some things to move forward.

Thanks to the foundation for paying for the event, and to Mitja for hosting us, doing such a perfect job that we barely noticed it.

Ещё один отчёт с недавно завершённого хакатона g2k14, на этот раз от Марка Эспи (espie@), который пишет:

В первый раз в Словении. Заняло несколько часов, чтобы увидеть город, удалось избежать гроз. Несколько интересное соединение, никогда не видел такую смесь восточноевропейской, южной Европы и туристические места.

Что касается хакатона, я приехал туда прямо после большого изменения (переупорядоченные пакеты), и я был почти готов починить что-либо в случае необходимости. К моему удивлению, это работало как очарование... Если я сломал что-то, никто этого не заметил (и вы, парни, собирающиеся насладиться более быстрыми обновлениями).

После большого нытья Вадим Жуков наконец закоммитил digicam-kde4. Я сделал краш-тест сборки и закидал его отчётами об ошибках, которые он быстро чинил.

Я работал над несколькими мелочами... заметил много и чинил крошечно-маленький сломанный кусок дерева портов, связанный с теми бесстрашными хакерами исходников (главным образом, libressl, endian.h и обновлениями mesa).

Я работал над новым механизмом, чтобы гарантировать последовательность снапшотов пакета. Quirks теперь сообщает о своей дате подписи (которая самостоятельно проверяется, то есть вы не можете в это вмешаться), таким образом, вы можете знать, или снапшот недавний, или кто-то воспрепятствовал, чтобы он пришёл в ваше любимое зеркало...

... и quirks сам содержит список уязвимых пакетов, которые поднимут красный флаг, если вы нуждаетесь в них, и их НЕТ на вашем любимом зеркале.

Всё это просто показательно для пользователя, поскольку снапшотам нужно большое время для того чтобы разойтись (по зеркалам)..., у нас есть идеи, как помочь с ЭТИМИ специфичными проблемами, но после обсуждения с заинтересованными сторонами он не будет развёрнут до следующего релиза, поскольку это было бы слишком подрывным.

Я также попытался решить проблему со сборкой портов, требующих src, чтобы присутствовать в pkglocatedb. К моему большому удивлению, Тео согласился, и мы пошли дальше, чем ожидалось, поэтому теперь снапшоты определяют местонахождение dbs для src И X.

Я провёл много времени, играя с этим: pkg_check теперь использует его, и фактически будет проверять вашу полную файловую систему. Это всё ещё немного более многословно.

Соответственно, я провёл немного времени, убивая кое-какой старый код. Это не столь сексуально (что?), но эта, возможно, самая важная часть процесса, гарантирует, что мы не будем запускать то, что более не нужно/не поддерживается...

Мне следует также упомянуть, что импортировал автономный cpp, чтобы иметь дело с календарём и xrdb, в конечном счёте, так чтобы X больше не требовал от вас установки comp.

Как обычно, встреча с поддерживающими разработчиками лицом к лицу было большой помощью в продвижении некоторых вещей.

Спасибо фонду за оплату события и к Mitja за гостеприимство, делая такую прекрасную работу, что мы только это заметили.

> текст получается чисто механический, чисто анлицированный, не по-русски звучит :(
Знаю, переводил почти дословно, сохраняя все детали. Надо будет исправить до хорошо читабельного варианта

> если это где-то проанонсировать - будут справедливо ругаться, что механический переводчик так же переводит :) а если не анонсировать - то кому вообще этот текст писать...
Механический переводчик вообще статьи отвратительно переводил - совсем непонятно было, о чём там говорится =) Поэтому пришлось где-то 60-70% переделывать самому. Опять же, сначала лучше всё перевести, потом исправить стиль, а публиковать в последнюю очередь.

Слова Тэо, конечно, нужно переводить максимально дословно, как ПСС :) Партийная линия, как никак :)

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

ну, свою статью я добью... те, которые я хотел переводить, которые больше понятно - уже перевели, причесать надо... :)

Ага, живые. Может, ещё какие перевести, а потом и "причесать"?

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

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

Страшное ругательство идэдэкудэ пришло к нам из:
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%
Сто. Один держит лампочку, а 99 навинчивают дом: 12.1%
Два. Один завинчивает, а другой следит, чтобы не пришел ток: 6.1%

Скромные компьютерщики говорят:
HAHA: 0.0%
HOHO: 0.0%
IMHO: 100.0%
CHMO: 0.0%

Справка обычно вызывается...
По кнопке F1: 100.0%
По телефону 02: 0.0%
При произнесении заклинания: 0.0%
После того, как ничто другое не помогло: 0.0%

В компьютере есть:
Мать: 100.0%
Отец: 0.0%
Брат: 0.0%
... и пить!: 0.0%

Мыши бывают -
С лазерным оптическим прицелом: 28.1%
С колесами: 71.9%
Со встроенной ракетницей: 0.0%
На гусеничном ходу: 0.0%

Прокладка между креслом и клавиатурой называется ...
Коврик: 3.2%
Диэлектрик: 0.0%
Антистатик: 3.2%
Пользователь: 93.5%

Частоту развертки монитора измеряют в ...
Пикселях: 3.3%
Вольтах: 0.0%
Герцах: 96.7%
Поставленных вокруг кактусах: 0.0%

E-mail - это сервис ...
Электронной почты: 100.0%
Услуг по телефону: 0.0%
Интима по пейджеру: 0.0%
...пак для чикаги: 0.0%

Как звали ученого Паскаля?
Борланд: 31.0%
Блез: 69.0%
Архимед: 0.0%
Билл: 0.0%

Клавиатура - как ...
Капуччино: 0.0%
Пианино: 100.0%
Челентано: 0.0%
Тарантино: 0.0%

Что принимают при установке программы?
100 грамм для храбрости: 0.0%
500 грамм для наглости: 0.0%
Лицензионное соглашение: 100.0%
Декларацию независимости: 0.0%

IDK расшифровывается как:
Принято к сведению: 25.9%
Обсуждению не подлежит: 7.4%
ID - каазлы: 0.0%
Я не знаю: 66.7%

CUL расшифровывается как:
Типа крута: 37.0%
Внатуре: 0.0%
Рад тебя видеть: 11.1%
Увидимся: 51.9%

Сколько клавиш на клавиатуре XT?
40: 7.7%
83: 26.9%
100: 11.5%
101: 53.8%

4х-листный клевер, неразменный пятак и кроличья лапка -
Убивают в Doom: 4.0%
Собирают в Heroes: 84.0%
Изобретают в Civilization: 8.0%
Это эмблема Microsoft: 4.0%

BFG9000 - из арсенала...
Думера: 58.3%
Дюкера: 8.3%
Квакера: 33.3%
Войск ПВО: 0.0%

amd5x86-133 -
Круче P100: 66.7%
Такой, как P75: 33.3%
Прозрачный и зеленый: 0.0%
Пили в детстве: 0.0%

Вес измеряется в ...
Мегабайтах: 12.5%
Метрах: 16.7%
Килограммах: 29.2%
(все вышеперечисленное): 41.7%

Netscape Navigator - это ...
Когда то было очень актуально: 81.0%
Название IE в детстве: 19.0%
Игра про пиратов: 0.0%
Полка в шкафу: 0.0%

Сколько бит в килобайте
1000: 0.0%
1024: 33.3%
8 тысяч или около того: 66.7%
В обычном - 8, в високосном - 9: 0.0%

Чей скл?
Мой!: 52.4%
Немой!: 14.3%
А че сразу я?: 23.8%
А у вас нет такого же, но с перламутровыми пуговицами?: 9.5%

WinPopup - это ...
Программа для блокировки баннеров: 28.6%
Программа для обмена сообщениями: 61.9%
Церковная надстройка для Windows: 4.8%
Windows без цензуры: 4.8%

Последней самостоятельной распространяемой версией MS-DOS была версия.
6.0: 4.8%
6.22: 71.4%
7.0: 14.3%
7.10: 9.5%

Cообщник БГ по основанию Microsoft?
Лу Гестнер: 0.0%
Марк Збриковски: 0.0%
Стив Балмор: 57.1%
Пол Аллен: 42.9%

Сколько пробелов вместится в стандартном текстововом разрешении?
1000: 23.8%
1600: 38.1%
2000: 19.0%
307200: 19.0%

В честь кого назван хедер .exe файла?
Билла Гейтса: 19.0%
Луи Гестнера: 9.5%
Пола Аллена: 14.3%
Марка Збриковски: 57.1%

EMM386.EXE предназначен для доступа к ... памяти.
Основной: 14.3%
Extended: 57.1%
Expanded: 28.6%
Видео: 0.0%

HIMEM.SYS предназначен для доступа к ... памяти.
Основной: 10.0%
Extended: 70.0%
Expanded: 20.0%
Видео: 0.0%

Как расшифровывается SCSI?
Small Computer System Interface: 40.0%
System Contoller Slave Interface: 60.0%
Setup Computer Super Interface: 0.0%
Sovetskie Computery Samye Interesnye: 0.0%

Какая команда типична для файла config.sys?
LOAD HIMEM.SYS: 25.0%
HIMEM.SYS: 5.0%
DEVICE=HIMEM.SYS: 30.0%
LOAD=HIMEM.SYS: 40.0%

Для какой из ОС родной является файловая система HPFS
DOS: 0.0%
Windows: 0.0%
OS/2: 90.0%
Linux: 10.0%

Сколько уровней в модели OSI?
6: 10.0%
7: 75.0%
12: 5.0%
30 + 2 бонус-уровня: 10.0%

NT3,NT4,XP и
95: 10.0%
98: 0.0%
ME: 5.0%
2000: 85.0%

GUI - это:
Графический интерфейс: 100.0%
Графический универсальный инструмент: 0.0%
Производитель видеокарт: 0.0%
Что-то неприличное: 0.0%

Известный антивирус, созданный Дмитрием Лозинским, назывался?
DRWEB: 45.0%
Aidstest: 40.0%
KAV: 0.0%
AVP: 15.0%

Файл для поддержки тем XP для старых программ?
Билль: 15.0%
Декларация: 5.0%
Манифест: 80.0%
Договор согласия: 0.0%

Что было раньше?
DOS: 15.0%
CP/M: 80.0%
Windows 1.0: 0.0%
Linux: 5.0%

Известный анекдот гласит - В свои 20 он знал 9 операционных систем ...
... и помнил 237 рутовых паролей: 10.0%
... из них 6 написал сам: 40.0%
... и ништяк: 0.0%
... и ни одной женщины: 50.0%

Какая игра была первой, где вместо компьютерной графики применялось цифровое видео?
Phantasmagoria: 40.0%
Mad Dog McCree: 10.0%
NeverHood: 40.0%
Doom: 10.0%

В OpenBSD этот процесс очень неэффективен. А причина в том, что kded4 внутри использует KDirWatch, который по умолчанию ориентирован на inotify в Linux в QFSWatch в других системах. Он также поддерживает FAM, но я уже пытался его использовать, и мне не понравилось. Я уже начал было думать о реализации бэкэнда kqueue, и тут я вспомнил, что kirby@ работает над libinofity. Это то, что нужно - inotify API на базе kqueue. Так что я написал FindInotify.cmake который должен работать и в Linux и вне Linux, сделал несколько #ifdef в коде, пересобрал kdelibs ... и вот оно! Теперь kded4 проверяет файлы при запуске, и дальше живёт абсолютно не напрягаясь!

Ещё после этого 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 за организацию этого чудесного мероприятия. Это был мой первый хакафон, и было удивительно, сколько всего произошло за несколько дней. И Любляна - прекрасный город... Я надеюсь что кто-то, кто знает английский язык лучше меня, мог бы лучше в красках живоописать этот уютное место и его жителей. Всё было просто классно - спасибо, спасибо и еще раз спасибо!

g2k14: World of KDE4, Vadim Zhukov (zhuk@)

По горячим следам успешного хакафона, Вадим Жуков (zhuk@) отчитался о своих успехах:

Я прибыл на хакафон с коротким, но суровым списком задач:

1. Закончить KDE 4.13.2 и приготовить 4.13.3 (официальный анонс (чего?) - 15 июля)

2. Наконец-то портировать несколько приложений из openbsd-wip в официальный cvs?

3. Исправить давнюю проблему с усиленным поеданием процессора в kded4

4. Продолжить работу над Samba 4.x

5. Исправить проблему с отсутствием ext2fs в установщике для amd64 (RAMDISK_CD)

6. Некоторые вещи, которые я разбабатывал последние месяцы для ports/infrastructure, занести в CVS

7. Занести в CVS порт man-pages-posix

Но, по факту, хакафон для вас начинается со знакомства с людьми, с которыми вы не были прежде знакомы. Учитывая, что до этого единственным мероприятием по openbsd, где я был, было EuroBSDCon 2013, было много новых лиц. Я боюсь, что я не запомнил их всех, но не потому, что я не уважаю их илиих работа, это просто мой недостаток :)

Итак, хакафон начался. Мы с kirby@ - другим портером OpenBSD из России - сели друг напротив друга. И это нам очень помогло - он помог мне тестить сборку ядра с ext2fs и дал мне идею насчёт libinotify (см. ниже), а я помог ему обновить порт rawtherapee.

Мой первый коммит на этом хакафоне был импортированием books/man-pages-posix. Это полезная вещь для разработчиков, и я получил положительные отзывы ещё до того, как начал импортирование [мне не нравится вообще слово импортирование, надо как-то заменить в обоих случаях].

Но это не моя работа - неоценимый вклад внёс schwarze@ и другие. Я узнал много нового о mandoc, groff и pkg_create [узнал много нового о магии mandoc, groff и pkg_create, или только о pkg_create? ох уж этот английский язык] во время работы над этим портом. Но, опять же, это было только для начала.

Большую часть времени я сидел и делал четыре вещи: запускал make, твикал патчи, пушил их в апстрим и спамил landry@ о новых портах. Я благодарен ему за терпение. Благодаря его замечаниям, у нас теперь есть следующие приложения из KDE4: Calligra suite, Digikam, K3b, Kdenlive, KDevelop, KMyMoney, KTorrent, Tellico и Yakuake (вместе с зависимостями, типа Eigen 3.x и другими).

Из kde4 в openbsd-wip осталась только audio/cantata: она имеет несколько кривую интеграцию с KDE4, так что мне быстро это надоело - плееров, в том числе для kde4, и так хватает. Надеюсь, что Рафаэль Садовский, который постоянно мне помогал, не обидится. :)

Обновление KDE 4.13.2 скучно и неинтересно. Есть 200 + портов, 200+ раз написать "make configure update-plist port-lib-depends-check package clean", запушить несколько патчей в апстрим, закончили упражнение. Вот и все. Реально всё. Проблемой было создание порта и задача совместного существования kde3 и kde4, а сама поддержка порта kde4 не так сложна.

И вот пришло время для действительно интересненького. kded4. Если вы не в курсе подробностей: kded4 (что означает "KDE 4 Daemon") обычно запускается с kdeinit... то есть, либо в самом начале сессии kde, либо когда вы запускаете первое приложение KDE. Этот демон hosts[содержит???] так называемые модули KDE - Если вы видели services.exe по Windows, то вы понимаете, о чём я, это почти то же самое. Другая задача kded4 - мониторить файлы конфигурации, особенно MIME .desktop файлы. При установке/настройке/удалении приложения, .destkop-файлы могут изменяться, как системные (в /usr/local), так и ваши личные (в $KDEHOME). Многие программы, особенно различные виджеты рабочего стола (читай: KDE-меню и подобное), заинтересованы в уведомлениях о таких изменениях. Таким образом, kded4 контролирует некоторые директории на предмет добавления/изменения/удаления .desktop-файлов.

В OpenBSD этот процесс очень неэффективен. А причина в том, что kded4 внутри использует KDirWatch, который по умолчанию ориентирован на inotify в Linux в QFSWatch в других системах. Он также поддерживает FAM, но я уже пытался его использовать, и мне не понравилось. Я уже начал было думать о реализации бэкэнда kqueue, и тут я вспомнил, что kirby@ работает над libinofity. Это то, что нужно - inotify API на базе kqueue. Так что я написал FindInotify.cmake который должен работать и в Linux и вне Linux, сделал несколько #ifdef в коде, пересобрал kdelibs ... и вот оно! Теперь kded4 проверяет файлы при запуске, и дальше живёт абсолютно не напрягаясь!

Ещё после этого 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 за организацию этого чудесного мероприятия. Это был мой первый хакафон, и было удивительно, сколько всего произошло за несколько дней. И Любляна - прекрасный город... Я надеюсь что кто-то, кто знает английский язык лучше меня, мог бы лучше в красках живоописать этот уютное место и его жителей. Всё было просто классно - спасибо, спасибо и еще раз спасибо!

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

Общее замечание: написание названий. "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", а ещё лучше - пока
не придумал.

"... где я был, было EuroBSDCon 2013..." - во-первых, "была EuroBSCon
2013", т.к. это конференция (женский род); а во-вторых, "был, было" -
довольно коряво звучит.

"Я боюсь, что я не..." - в русской версии вырезай лишние "я", с точки
зрения грамматики они зачастую не нужны: "Боюсь, что не".

"... их илиих работа..." - я твой эр два дэ два колёс шатал...

"мне не нравится вообще слово импортирование..." - отчасти согласен. С
другой стороны, это устоявшийся термин... "Внести в CVS", может? Или
"занести", как ты писал выше; звучит оригинально, свежо.

"Но это не моя работа..." - в русском языке фраза звучит двусмысленно.
:)) Лучше "Это был не столько мой труд, сколько...".

"... нового о mandoc, groff и pkg_create" - да, это, наверное, лучший вариант.

"это было только для начала" - тогда уж или "это было только начало,
или что-то в духе "это было только для разгона".

"пушил их в апстрим" - возможно, я слишком мало работаю с DVCS (на
последних работах тоже всё как-то больше Subversion попадался), но...
"пушить" ассоциируется больше с пушным промыслом, или, на худой конец,
с распушиванием хвоста. :) Но это уже опциональное замечание.

"спамил landry@ о новых портах" - скорее, "засыпал landry@ новыми портами". :)

"благодаря его замечаниям" - скорее, "благодаря его отзывам". Отзывы
(ревью) могут быть и без замечаний, но без ревью импорт не делается.
:) Разве что я себе позволяю без ревью импортировать новые порты
внутри x11/kde4. ;)

"... зависимостями, типа Eigen 3.x и другими" - "и другими" в данном
случае избыточно.

"Из kde4 в openbsd-wip" - некорректно. Имелось в виду именно что "из
портов, связанных на KDE4", или что-то в этом роде. Cantata, Yakuake,
Calligra и т.д. не являются часть KDE4.

"Рафаэль Садовский" - он, скорее, Садовски. Но я бы лучше написал ему
и уточнил. ;)

Далее, мне было проще переписать абзац. :) "закончили упражнение" - это отлично!

"Обновление KDE 4.13.2 само по себе скучно и неинтересно. Имеем 200+
портов, значит, 200+ раз пишем "make configure update-plist
port-lib-depends-check package clean", отправляем несколько патчей в
апстрим, закончили упражнение. Вот и всё. Реально всё. Трудными были
задачи собственно портирования KDE4, а также совместного существования
KDE3 и KDE4, а поддержка портов KDE4 не так сложна."

"hosts[содержит?]" - именно хостит, то есть, размещает на себе (или в себе).

"Если вы видели services.exe по Windows" - "если вы видели
services.exe в Windows"

"особенно MIME .desktop файлы" - лучше, наверное, написать "связанные
с MIME файлы .desktop"

"приложения, .destkop-файлы" - запятая лишняя

"kded4 контролирует некоторые директории" - скорее, "мониторит".
Контроль подразумевает какую-то обратную связь, которой здесь нет.

"этот процесс очень неэффективен" - скорее, "этот процесс был очень
неэффективен"... Возможно, я слишком коряво выразился в английском
варианте - увы, проверять его пришлось самому, редакторы undeadly,
похоже, знают английский не лучше моего.

"по умолчанию ориентирован на inotify в Linux в QFSWatch в других
системах" - "по умолчанию использует inotify в Linux и QFSWatch в
других операционных системах".

"и мне не понравилось" - более корректно будет "но результаты меня не
удовлетворили".

"бэкэнда kqueue" - лучше "бэкэнда на базе kqueue(2)"

"Это то, что нужно" - "Это ведь то, что нужно"

"Две проблемы по цене одной! Покупайте наши libinotify!". :) К
сожалению, редакторы Undeadly поленились или не захотели дополнить
абзац важным предупреждением: все пользователи KDirWatch теперь едят
намного больше файловых дескрипторов (до нескольких тысяч - по сути,
по дескриптору на каждый отслеживаемый каталог и файл). На Linux эта
проблема не так заметна, так как там обычно банально не стоит никаких
лимитов, или они задраны очень высоко. Я добавил предупреждение в
MESSAGE, выводимый при установке/обновлении kde-runtime, но всё же
лишним предупредить не будет.

"в этом хакафоне, я успел доделать" - "за время этого хакафона я успел
закончить".

"в связке с sqlports это поможет сэкономить" - "в связке с sqlports
она позволяет сэкономить"

"некоторые порты, на CMake" - лишняя запятая

"потому что больше никто не развивает его, а те, кто знают, как его
поддерживать - и так всё знают." - всех лучше язык русский знает Йода
мастер. ;) "потому что его больше никто не собирается поддерживать, а
кто поддерживает сейчас, и так всё знает".

"С другой стороны, я был вовлечён в несколько дискуссий" - "Также я не
раз участвовал в дискуссиях"

"И, в заключении" - однажды, в студёную зимнюю пору, сижу за решёткой,
в темнице сырой... Гм. "В заключение", и всё. :)

"хочу (точнее, обязан)" - там было просто перечисление глаголов. :)
Должно было получиться что-то вроде: "хочу (чувствую необходимость,
обязан)"

"Mitja Muženič и Dijaski dom Tabor" - если уж переводить, то
полностью: "Мите Муженичу и гостевому дому "Табор"

"мог бы лучше в красках" - "сможет ярче"

... с оригинальным текстом я напрямую не сверял, пользуясь только
памятью, - думаю, в данном случае точность не так критична. :)

g2k14: Jonathan Gray on driver improvements for X
Contributed by tbert on Sat Jul 19 08:24:01 2014 (GMT)
from the closing-holes-by-closing-apertures dept.

Jonathan Gray (jsg@) writes in to let us know why he spent 30 hours in coach to be with us:

One of the first things I did at g2k14 was import the Mesa update I've been working on for some time now. I've been tracking the Mesa git for a few months and submitting patches to reduce the amount of pain involved and given the local diff isn't too large anymore it seemed like a decent time to update. Shortly before the hackathon I ran into a problem getting Mesa to build on i386 however. It turns out there is an i386 only codepath that does a sysctl to check if SSE is enabled. This turned out to be a problem because sysctl.h pulls in uvm_extern.h which then pulls in a bunch of kernel headers including mutex.h which meant that Mesa's mtx_init() collided with the kernel's mtx_init(). Theo spent some time cleaning up the sysctl and uvm headers so they wouldn't include anywhere near as many definitions, and that work had already been committed when I arrived at the hackathon.

The following day I did some xenocara builds to try and catch any additional problems. The problem I found was due to a symlink in the Mesa dist file that cvs import ignores, which was fixed by pointing the Makefiles to a different directory. I also double checked that LLVM enabled Mesa builds worked still worked via the LLVMpipe software renderer. Another problem the Mesa builds showed is that sys.mk the Makefile that gets automatically included by make adds CFLAGS to CXXFLAGS. As Mesa is a mixture of C that assumes C99 and C++ code, g++ ends up complaining that it gets the C specific -std=c99 flag passed to it. A diff to correct this in the system Makefiles and a few other places will be mailed out in future.

I also looked into getting the src tree to build with OPENSSL_NO_DEPRECATED defined which in most cases involved adding includes that are not automatically pulled in by other includes anymore. For some things like nginx that are externally maintained there are patches already available in future versions that we'll eventually pick up so it doesn't seem worthwhile patching our version just yet when there are still other places in the tree (libkeynote/bind/sendmail etc) that need changes made. I also had a quick look at compiling with OPENSSL_NO_SSL_INTERN but after seeing how dc and gzsig broke when building I decided to look elsewhere.

I looked into updating some clang patches I've had lurking around for a few years and committed some things relating to that.

Xorg can now run without having to grant userland direct access to a window of kernel/device memory if kernel modesetting (KMS) is supported. The problem being other devices still need access to this window to run Xorg. The installer asks a question if it finds a vga device that enables the window via the machdep.allowaperture sysctl. After a discussion with a few people at g2k14 I created some small scripts to extract PCI vendor/product numbers from the radeondrm and inteldrm drivers which are used by the pci attachment of the vga driver to print a line to dmesg if the window will be needed to run Xorg. The installer has been modified by halex@ and rpe@ to check for this line and will only ask if the person installing intends to run X11 (which enables the window) if it is found. The X11 question will not be asked on many servers now as there is a blacklist of graphics devices commonly found in servers in the code that decides whether the aperture is needed.

A problem I've run into a few times now is the lack of a cpuid.h header which is provided by gcc >= 4.3 and clang to provide an interface to calling cpuid on i386 and amd64. Mesa git now requires cpuid.h to build. The Intel Xorg driver disables codepaths involved in deciding if SSE is present and making decisions based on cache sizes if it missing. And at least some ports (ie OpenXCOM) seem to expect it now. So I've taken the cpuid.h from clang to include in our version of GCC 4.2.1. Initially I changed the SSE_4_1 and SSE_4_2 definitions to SSE_41 and SSE42 to match the names used by GCC but likely both definitions will be included when this gets committed.

Many thanks to the OpenBSD Foundation and Mitja for making g2k14 possible.

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.Третья бета Чикаги звалась?
Редмонд
Балтимор
>Мемфис
Лонгхорн
* Memphis - это была сырая, но трогабельная версия Чикаги, распространенная по xUSSR

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

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.

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.

I also looked into a problem with bwi(4) which I diagnosed**** about a month ago. The device cannot do DMA to address ranges above 1GB of memory, so it is quite unhappy in my powerbook G4 with 1.5GB of RAM. claudio@ who had fixed a similar problem in bce(4) years ago helped and tedu@ and miod@ very convincingly made clear that all kernel panics and crashes I was experiencing were due to my local bwi(4) changes alone. I could not get this done at the hackathon and ended up doing some more work on it at home. I now have bwi(4) working on my machine and posted a call for testing***** and is now committed.

I also helped florian@ and henning@ with IPv6-related things and reviewed/tested workq->taskq conversion diffs from blambert@ who finally fixed that nasty duplicate-address prevention hack in nd6_addr_add() I had added some time ago.

The week was very enjoyable and flew by way too fast. I really didn't feel like leaving when the hackathon was over. Many thanks to Mitja for making this event happen!


* http://marc.info/?l=openbsd-misc&m=140083635708140&w=2
** http://marc.info/?l=openbsd-misc&m=132969397110211&w=2
*** http://marc.info/?l=openbsd-tech&m=126437914024661&w=2
**** http://marc.info/?l=openbsd-misc&m=140267041817160&w=2
***** http://marc.info/?l=openbsd-tech&m=140570091624436&w=2

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.)

A bit of a ruckus ensued in the hackroom and benno@ first changed the default for net.inet6.icmp6.nodeinfo from 1 to 0 to have it off by default and worked on a diff to completely remove it from the kernel, and committed it a day later.

Tedu@ dug up the very nice -Werror-implicit-function-declaration gcc flag and I cleaned up /sbin and /usr/sbin. Two quick fixes in disklabel(8) and mrouted(8) for missing prototypes and I thought I'm done there.

Well, turns out not quite. COPTS from usr.sbin/Makefile.inc don't get propagated to programs in usr.sbin using Makefile.bsd-wrapper and configure. Those are bind(8), nginx(8), nsd(8) and unbound(8).

I looked around in the build system and asked espie@ for help but was not not quite clear what the right fix might be.

So I focused on making sure those 4 programs are clean once the right solution presents itself. Well turns out, you need to be careful here. Suddenly conftests of configure are failing. For bind(8) this meant that it can no longer find openssl^Wlibressl. For nsd(8) and unbound(8) this meant that it suddenly couldn't figure out that OpenBSD is indeed providing certain string functions in libc and tried to use portability functions shipped with the nsd(8) / unbound(8) distribution. So some careful analysis was needed to make sure that both build the same way as before. Since wouter@ was in the room this could be quickly fixed upstream, too.

And now, off to IPv6 land...

I was sitting next to henning@ during the hackathon. I had just finished sweeping /usr/sbin for -Werror-implicit-function-declaration and was listening to music on my headphones. When there was silence because the song reached the end I heard that stsp@ had walked over to our table and was discussing something SLAAC (stateless address auto configuration) related with henning@. A big imaginary question mark formed over my head. Curious about what was going on I listened a bit, quickly read a diff they were apparently arguing about to get up to speed and then joined an half hour long discussion about the merits of one particular continue in a for loop. We also asked bluhm@ for input and I think in the end we found the right solution.

Turns out the diff they were arguing about was the ifconfig(8) autoconf flag diff. Now we have a per interface flag if we want to do SLAAC or not. The old net.inet6.ip6.accept_rtadv was for all interfaces.

With that we can move sending of router solicitation messages - something currently rtsol{,d}(8) is doing - to the kernel.

The kernel already does all the other stuff needed for SLAAC so just sending one packet at the right time is not so much more code for the kernel.

First of I wrote a userland implementation in ifconfig(8) to get a feel for the packets being send. The code in rtsold(8) is a bit all over the place and hard to follow. Also the turnaround times in userland are much faster then debugging something in the kernel.

Having this running after a few minutes it was now time to move this into the kernel. Turns out there are similar functions in sys/netinet6/nd6_nbr.c doing more or less the same stuff I need (btw. mpi@ send me off an a side quest to clean that up by factoring out common functionality).

So that was pretty easy, quickly hooked the function up at the point when DAD (duplicate address detection) finishes for the link local address and the proof of concept worked on the first try. No kernel panic! That's a new one! Yay!

With that working I solicited (pun intended) some help from stsp@ on brain storming in which situations we need to send solicitations.

After a few iterations of diff review by mpi@ and him explaining to me the finer details of the network stack I think the diff is now more or less ready but won't make 5.6. With this we will be able to send rtsol{,d}(8) to the attic.

Thank you very much Mitja and everybody else involved in making this hackathon happen. Also thank you to all the other OpenBSD developers who took the time and came to Ljubljana to make this an enjoyable and productive week.

p.s.: We need the same amount of beer/h to write code as Mitja's car needs gasoline while idleing. So I guess we are more energy efficient than Mitja's car.

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:

A full rewrite of the man.cgi(8) manual that is now also used online; a cleanup of error reporting; a reasonable default for .Os; getting rid of pointless run-time configuration, using minimal compile-time configuration instead; getting back closer to the classical URI scheme; always including manpath= when printing queries, and omitting empty parameters; and a compatibility hack for the old OpenBSD "manpath=OpenBSD<blank>" query parameter format. Thanks also to Ted Unangst (tedu@) for finding the time to send two bugfix patches for man.cgi(8) among all his other work.

There is an old saying that hackathons are ideal for either starting work on a new task, to be polished afterwards, or getting an old one finished that was started long before. The man.cgi(8) replacement is one of the rare examples where a task was started right on the voyage to the hackathon *and* finished before the end of it, including deployment of the less-than-five-days-old software in production on http://mdocml.bsd.lv/cgi-bin/man.cgi and even on http://www.openbsd.org/cgi-bin/man.cgi.
And by the way, using queries like
http://mdocml.bsd.lv/cgi-bin/man.cgi?manpath=4.4BSD-Lite2&apropos=1&query=Xr%3Dinet
you can now run semantic searches on the original CSRG 4.4BSD-Lite2 manual pages!

Partly in parallel to that, but mostly after man.cgi(8) was in production, I picked up the pod2mdoc(1) utility http://mdocml.bsd.lv/pod2mdoc/ that Kristaps@ Dzonsons recently wrote in one of his characteristic flurries of extraordinary creativity. To help Anthony J. Bentley@ getting started with the LibReSSL manual conversion form perlpod(1) to mdoc(7), i pushed a pod2mdoc-0.0.12 release out of the door, and he promptly updated his port in the OpenBSD tree. He then started using the tool in practice, converting many manual pages, doing considerable manual postprocessing on each of them, and reporting lots of bugs and feature requests with respect to the tool.

I couldn't quite keep up with his pace, but some stuff got done by now: during the hackathon, correct handling of filename extensions and better rendering of B<NULL>, and right after the hackthon multiple fixes regarding the handling of POD commands and formatting codes and the spacing around them in general, substantially redesigning some of the internal interfaces in pod2mdoc.c. During the hackathon, I also started a regression suite for pod2mdoc(1). That work led to the pod2mdoc-0.0.13 release today, on July 19.

The low version number still makes sense, there is much to do still to polish this tool and add missing functionality, in particular heuristics for guessing how various kinds of text ought to be marked up, to make manual postprocessing less painful.

As usual, various other bits and pieces got addressed during the
hackathon:

The whatis(1) utility now correctly matches words instead of any
substrings. This helps man.cgi(8), but is also nice for the
stand-alone command line version.
The security(8) utility no longer complains when /etc/exports
does not exist - it is now optional. Thanks to Antoine
Jacoutot (ajacoutot@) for the bug report.
Together with Theo (deraadt@), i have cleaned up the format
of the file /etc/mtree/4.4BSD.dist to make it more readable.

All in all, g2k14 was an exceptionally focused and productive hackathon for me. Having a familiar and very well-organised venue helped a lot (thanks Mitja!). I didn't spend a lot of time in the city this year, but that doesn't matter much because I have seen and enjoyed some of it during s2k11. Well, I did find the time to have a stroll to the Golovec Hill http://sl.wikipedia.org/wiki/Golovec with Rapha@el Graf, which was a very nice conclusion of a great event.

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.

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.

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...

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.

Look forward to many more interesting LibreSSL releases in the future! I certainly am looking forward to when I can replace OpenSSL with LibreSSL in my own projects. I will certainly be using OpenBSD a lot more from now on as well.

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
uhub0 at usb0 " octHCI root hub" rev 2.00/1.00 addr 1

I made further progress by slowly filling in the controller-specific bits from the hub routines. That meant providing proper hub descriptors, getting and setting port features and clearing USB requests.

This lead to a build-up of immense confidence that in turn allowed me to convince myself that the time for a new device connection test was in-place.

The excitement was high. mpi@ joined my table and provided me with a YubiKey device to test with. But that didn't actually happen as he quickly changed his mind in fear of the Great USB Frying God and so brought over in exchange some old .vantronix USB sticks that he was more willing to see destroyed than the former YubiKey.

With trembling hands I connect the device and... the machine froze! I pulled it out and quickly connected it to my laptop to see if it still worked. It did! I was so happy!

I quickly found the cause of the freeze and fixed it: the host port interrupt flag was not cleared by the HCI interrupt routine so that lead to an interrupt storm.

Clearing the interrupt put the machine in the same state as before I started hacking on this driver: USB device connections had no effect (-:

Well that's not entirely true because now the kernel was becoming aware of USB events and knew how to properly treat some of them. This also meant that I could plug and unplug devices at will and test without fear of loss!

Following that, I started relaxing some overly-paranoid checks that I treated with immediate panics when true. They were put there since the dark-ages of the frying sticks and were actually wrong.

I added more event handling in the interrupt routines along with proper acknowledgment. I also started keeping track of port connections and port resets so that I can notify the upstream USB layer when connection status changed and when port resets were done.

I'm currently working on getting device control and transfer pipes rolling that will hopefully lead to a successful device attach.

Developments really sped up once device connections started working but unfortunately the hackathon came to and end.

The Ljulbjana hackathon was a great event that allowed me to accomplish and learn a lot for which I would like to thank Mitja (our awesome organizer), the OpenBSD Foundation and Theo de Raadt for their efforts of putting all of this together!

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

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.

Did inet6 off by default by setting IFXF_NOINET6 in if_attach(), every interface showing up goes through that. But in a "inet6 only turned on when actually used" world, the NOINET6 semantic is backwards, and all those calls to inet6 attach functions guarded by checking that flag were useless. I wanted to clean that up, get rid of the flag and just not call the inet6 setup stuff (mostly adding the link-local addr) unless really needed. But that left a problem, we really really really want to make sure we don't accept router advertisements unless root clearly indicated he wants to do so. And the v6 autoconf semantics were a little weird to begin with. So here comes a new flag, IFXF_AUTOCONF6, set by doing "ifconfig <if> inet6 autoconf" or - for the moment - running rtsol. Very soon that ifconfig invocation will make the kernel send the router solicitation itself, i. e. no more need for rtsol and rtsold. That was part of the idea from the beginning, florian@ did the implementation, and as usual the entire thing is a big group effort, this time foremost between him, stsp, bluhm, mpi, naddy, benno and, well, me. I then could clean up the NOINET6 flag thing, get rid of it, add explicit IFAFATTACH/DETACH ioctls (which are not limited to inet6, even tho that's the implemented bits for now) and made the section at least nicer than it used to be. The semantics don't change, this is supposed to be user-invisible.

Also spent some time with Wouter reviewing the privilege handling and general early (potentially dangerous) code paths in nsd and unbound. Much to my surprise I didn't find a single real omission or error, but gave him some input how things can be nicer and easier to audit without giving up portability.

Mitja again did an awesome job organizing this hackathon (thank you!), the city of Ljubljana is really really beautiful, the people here are cool and nice. Definitely a recommended destination. Unfortunately didn't really have spare cycles to enjoy it over hacking and a LOT of time in (productive!) discussions.

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 :)

When I was not strictly hacking I had a lot of interesting chats with various other developers. Among these, I was really happy to discuss with yuo@, pirofti@ and stsp@ about USB because that's an area were I mostly work alone. But the most important discussion of this hackathon was the brain storming we had with claudio@, bluhm@, henning@ and others about the network stack: don't worry, we have a plan.

Thanks a lot to Mitja for this great hackathon!

прокинь обратно с меня linux.14

ps. чё с переводами?

какие вообще активные эхи есть?

> прокинь обратно с меня linux.14
загейтовал, см. im.100.

> ps. чё с переводами?
Чё-то лень на меня такая напала :( ужас
Буду искоренять. Наверное, лучше тебе будет мне просто todo написать, даже в виде msgid, чтобы я это перевёл. todo дисциплинирует =)

> какие вообще активные эхи есть?
Какие в фетчере ходят, такие и активные. http://irk38.tk/ii/ содержит все мои скрипты. Фетчеры и боты найдёшь по названию.

я у себя на сайте в шапке записываю id-шники:

http://51t.ru/txt.drafts.14

> я у себя на сайте в шапке записываю id-шники:
Ок, вижу, спасибо.

мне это вообще ничего не говорит... какие-то vk-скрипты...

есть просто список эх, где постоянно сообщения добавляются...

или дай полный список эх, я все зафетчу, и через ленту на r.51t.ru буду смотреть :) я и так вашу станцию через неё читаю :)

> мне это вообще ничего не говорит... какие-то vk-скрипты...
Это же гейты. Они в эху постят, чтобы мне лишний раз не заходить...

> есть просто список эх, где постоянно сообщения добавляются...
Сообщения добавляются рандомно...

> или дай полный список эх, я все зафетчу
"game.rogue.14",
"obsd.talk.14",
"bone.14",
"ii.dev.14",
"obsd.rss.14",
"ru.humor.14",
"gazeta.14",
"lor-opennet.2014",
"im.100",
"todo.14",
"to.doc.14",
"sysop.14",
"linux.14",
"ii.test.14",
"ii.soft.14",
"ii.echo.vote.14",
"music.14",
"younglinux.info.14"

Это был конфиг spline-fetch.php, свои эхи ты уже знаешь.

подписался на все... чего там только нет... даже какие-то янглинаксы, вк-нюсы

а я даже не знаю, как главную страницу оформить так, чтобы туда можно было МНОГО информации вылить, причём вместе с текстом, чтобы человек мог не тыкая по ссылкам впечатление о том, куда попал, получить... :) сижу, экспериментирую, а потом выкину на него ВСЕ эхи, которые создают информационный фон...

наверное, и game.rogue.14 я загейтую и younglinux и вк-нюс, сделай бекфетчинг...


и ещё надо какую-нибудь эху сделать, типа pipe.1380, чтобы можно было между двумя сетями сообщения кидать - иной раз хочется что-то в другую сеть написать, а это надо искать клиент, запускать, то, сё... а так пайпнул, и порядок... можно, чтобы не была просто болталка, стилизовать её под что-нибудь, хоть под клуб джентльменов, хоть под хоббитов, хоть под рыцарей, хоть под звёздные войны - просто для забавы, чтобы не просто болталка была :)

> Это же гейты. Они в эху постят, чтобы мне лишний раз не заходить...

они не говорят мне, КАК ЭХА НАЗЫВАЕТСЯ :) мне вот что было интересно :)

надо будет у себя на r сделать сортировку по эхам именно в порядке последней активности - всё руки не доходят, хотя уже давно хочу сделать...

в общем, я нашёл в echo/ список, и подписался НА ВСЁ :)

кстати, ещё тыщ 5 сообщений, и надо будет уже пробовать базу данных или хотя бы раздельное хранение по подкаталогам, на r.51t.ru сейчас почти 11000 сообщений, и ещё 501 сообщение, которого нет на r, есть на самом 51t.ru (там суммарно менее 3000 сообщений)

> они не говорят мне, КАК ЭХА НАЗЫВАЕТСЯ :) мне вот что было интересно :)
vk-news.14. Завёл её исключительно для себя, больше никто не читает. Была ещё niksor-vk.14 (филиал ru.humor), но владелец потерял к ней интерес, да и удалилась эха при чистке =)

> кстати, ещё тыщ 5 сообщений, и надо будет уже пробовать базу данных или хотя бы раздельное хранение по подкаталогам
Думал про идею хранения в одном файле нескольких сообщений, но что-то не сложилось

> подписался на все... чего там только нет... даже какие-то янглинаксы, вк-нюсы
Контент у нас всё-таки есть, какой-никакой =) Только не читает никто. Кроме меня, наверное.

> наверное, и game.rogue.14 я загейтую и younglinux и вк-нюс, сделай бекфетчинг...
Ок, сделаю

> и ещё надо какую-нибудь эху сделать, типа pipe.1380, чтобы можно было между двумя сетями сообщения кидать - иной раз хочется что-то в другую сеть написать, а это надо искать клиент, запускать, то, сё... а так пайпнул, и порядок... можно, чтобы не была просто болталка, стилизовать её под что-нибудь, хоть под клуб джентльменов, хоть под хоббитов, хоть под рыцарей, хоть под звёздные войны - просто для забавы, чтобы не просто болталка была :)
im.global.14
Неплохое название, да?