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

так как вообще узнать об их существовании? :)

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

> im.global.14 Неплохое название, да?

мне больше pipe.ГОД нравится. типа, попадаешь в трубу, и там или 1380-й, или 2922, и соответствующая стилизация :)

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

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

например, когда я делал nz на sqlite, и дёргал там опции по одному - у меня страница, где штук 60 записей, открывалась секунд 10 :) приходилось обходить через статик-кеши. в лоб - мгнновенно. :)

> так как вообще узнать об их существовании? :)
Кого? Пользователей? У меня даже счётчиков не стоит на сайте =)

> я и так думаю, как на юзера больше хорошо подаваемой информации сразу выплюнуть, чтобы знал, что тут есть... постоянно кручу перекручиваю... а вы всё попрятали :)
То, что есть у меня, ты уже знаешь (ну список эх). У Андрея, кстати, свои локалки есть, например, spline.bash.rss и spline.creepy. Но это уже у него надо узнавать.

Конкретно про свою станцию (да и не только) я считаю, что простым юзерам интересно будет почитать younglinux.info.14. Тем более, все статьи из раздела python я туда уже запостил. В эхе vk-news.14 идёт перепост со страницы Реактос в ВК. Но это не надо, наверное.

> мне больше pipe.ГОД нравится. типа, попадаешь в трубу, и там или 1380-й, или 2922, и соответствующая стилизация :)
Такое тоже можно. Но тогда это получается просто тематическая болталка, а не глобальная.

> Кого? Пользователей? У меня даже счётчиков не стоит на сайте =)

о существовании эх?

> То, что есть у меня, ты уже знаешь (ну список эх).

угу... теперь оно всё есть на глобальном хабе http://r.51t.ru, надо будет и свои эхи туда сваливать...

> Конкретно про свою станцию (да и не только) я считаю, что простым юзерам интересно будет почитать younglinux.info.14. Тем более, все статьи из раздела python я туда уже запостил. В эхе vk-news.14 идёт перепост со страницы Реактос в ВК. Но это не надо, наверное.

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

Про sql думаю, что надо будет оно всё-таки. Когда лимит инодов будет подходить к концу. Просто у меня на хостинге такой лимит есть, и превышать его не разрешается. Из-за этого пару дней назад был no message, если помнишь.

> Такое тоже можно. Но тогда это получается просто тематическая болталка, а не глобальная.

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

> о существовании эх?
Когда мы перейдём на новый вариант php ноды, где имеется эхолист, я всё туда запишу, и с описаниями. Андрей обещает протестировать.

> я сейчас граблю компьютерру, allhockey, f1news и юморный сайт-опять-забыл-название...
Юмор с тебя гейтуется, а остальное что-то не хочу =) хотя видел, что есть. Будет нужно мне и/или поинтам - загейтую.
Кстати, у меня есть идея кое-что загейтовать... Тоже для себя пока сделаю.

> я ж не хожу никуда :)
Сейчас что-то меньше опять ходить стал. Всё, что нужно, теперь есть в ii, поэтому теперь ходить мало куда нужно. Но на примете пара мест есть... потом сообщу.

fetch http://51t.ru/u/e/gazeta.14
fetch http://51t.ru/u/e/think.aloud.14
fetch http://51t.ru/u/e/od.ii.dev.14

это убрать - у меня нет таких эх

а добавить:

younglinux.info.14
obsd.bug.14
game.rogue.14
music.14
vk-news.14

в последнем, кстати, я уже успел ответить :)

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

Matthieu Herrb (matthieu@), who is the mad Frenchman who maintains Xenocara, writes in to share his g2k14 experience:

My main projects (multitouch, dhcpv6) didn't make any progress as I was distracted into X sets tweaks at the request of a few other hackers.

After much discussion this only led to the addition of ucpp in base (after a short detour by /usr/xenocara/app/xrdb-cpp) as /usr/libexec/auxcpp.

The reason is that xdrb (part of xbase which is required by many ports) needs a C pre-processor to run. But since gcc 4, /usr/bin/cpp is in the comp set because it's just another invocation of the full gcc. So xbase required the comp set to be installed.

This annoys 2 kind of people: those with appliances with small disks and the paranoid ones who don't want to provide a C compiler to attackers (which may be a good idea, when looking at components of the windigo operation).

So auxcpp is now part of the base set, and the depency of xbase on comp is gone. The X sets will stay in their current state for 5.6.

Otherwise, I've done a few updates on xenocara components. The xenocara tree is now mostly ready for 5.6.

I've nevertheless enjoyed the hackathon. Thanks to Mitja and his team for the organisation and to all foundation donors for the funding!

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

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

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

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

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

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

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

оригинал: http://51t.ru/JCIPNA

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

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

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

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

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

I also did some minor wip update to the www/nginx port, adding the ldap auth patch, polished ports for a pair of GIS caching servers i plan to use at work (mapcache, and mapproxy) but that work is still awaiting feedback and review.

As Vadim said, i spent quite a bunch of time proofreading lots of new ports needed for kde4 updates, fixing nits around and commenting on style issues - but since he's now an experienced porter, i didnt have much to add... and finally, i reviewed the work of our GSOC student about systemd-like daemons, to allow us to have equivalent features provided via D-BUS (those are more and more needed by gnome), and the architecture is shaping up quite nicely - we had quite some interesting exchange with him and ajacoutot@. I think that's material for a standalone undeadly issue, i'll let ian talk about it :)

Thanks again to mitja and his crew, again a perfect event in a really nice city!

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

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

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

Затем пришло время конкретно разобраться с одним вопросом касаемо безопасности, о котором я узнал. Истощение дескрипторов может использоваться для сокрытия отчётов о переполнении буфера через stack protector. Охрана stack protector требует файловый дескриптор для того, чтобы сообщить об ошибке. Кто-то из тех, кто подписан на блоги по arc4random и getentropy понимают, в чём проблема. *

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

Проблема была решена созданием нового системного вызова, который может отправлять сообщения для syslogd, вообще не используя никаких дополнительных ресурсов: syslog_r(3) может это делать напрямую, как по взмаху волшебной палочки. Системный вызов довольно узкоцелевой, поэтому назван sendsyslog(2), but this also fits the narrow use case it will have such as sandboxing.

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

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

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


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

g2k14: Jonathan Gray on driver improvements for X

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

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

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

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

Другая проблема со сборками Mesa заключалась в том, что sys.mk, автоматически включаемый через make в Makefile, добавляет CFLAGS к CXXFLAGS. Поскольку Mesa является смесью C, которая включает и код C99, с C++, g++ ругался на то, что к нему попадал C-специфичный флаг -std=c99. diff, который исправляет это в системных Make-файлах и некоторых других местах, будет потом отправлен по почте.

Я также проконтролировал, чтобы дерево исходников собиралось с OPENSSL_NO_DEPRECATED, который в большинстве случаев добавлял инклюды, которые больше автоматически не брались из других инклюдов. Для некоторых вещей, таких как nginx, которые поддерживаются извне, есть патчи, которые уже доступны в следующих версиях. Мы их потом возьмём, но пока что ещё не так уж и стоит патчить нашу версию, когда есть другие места в дереве (libkeynote/bind/sendmail и.т.д.), где требуется сделать изменения. Я также вскользь посмотрел на компиляцию с OPENSSL_NO_SSL_INTERN, но после того, как увидел, что dc и gzsig поломались во время сборки, я решил посмотреть в другие места.

Я посмотрел на обновление некоторых патчей clang, которые искал пару лет, и коммитил некоторые вещи, касающиеся этого.

Xorg теперь может работать без необходимости предоставлять прямой доступ из пространства пользователя к памяти ядра/устройства, если режим modesetting (KMS) ядра поддерживается. Проблема ещё заставляет некоторые устройства требовать доступ к этому окну памяти, чтобы запустился Xorg. Установщик задаёт вопрос, если находит vga устройство, которое включает окно через machdep.allowaperture sysctl. После обсуждения с парой людей на g2k14 я написал небольшие скрипты, чтобы забирать номера поставщика/продукта PCI из драйверов radeondrm и inteldrm, которые используются pci вложением в vga драйвер, чтобы написать строчку в dmesg, если это окно памяти требуется для запуска Xorg. Установщик был изменён halex@ и rpe@, чтобы проверить эту строку и теперь будет только спрашивать, нужно ли человеку запускать X11 (который включает окно), если оно найдено. Вопрос X11 не будет задан теперь на многих серверах, так как есть чёрный список серверных графических устройств в коде, решающем, нужен ли aperture.

Проблема, с которой я столкнулся теперь несколько раз, - это недостаток заголовка cpuid.h, который идёт из gcc >= 4.3 и clang, чтобы обеспечить интерфейс, запрашивающий cpuid на i386 и amd64. Mesa из git теперь требует cpuid.h для сборки. Intel-овский драйвер Xorg отключает код, включённый в решение, если SSE присутствует, и делает решения, основанные на размерах кэша, если его нет. И, по крайней мере, некоторые порты (т.е. OpenXCOM), кажется, теперь его ждут. Таким образом, я взял cpuid.h из clang, чтобы включить его в нашу версию GCC 4.2.1. Сначала я изменил определения SSE_4_1 и SSE_4_2 на SSE_41 и SSE42, чтобы соответствовать именам, используемым в GCC, но, вероятно, они оба будут включены, когда это закоммитят.

Большое спасибо OpenBSD Foundation и Мите за g2k14!

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

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

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

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

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

I made two changes to the kernel malloc(). The first was an idea deraadt@ had suggested some time ago. The current poison values (designed to detect use after free and other corruption) are rather limited, meaning that if a particular flag bit is set or unset, the incorrect code may continue to function. I change the poison values to inverted patterns, reversing all the bits. This proved to be very successful, finding many more bugs. Too successful, in fact, because there's not enough time to chase down and fix all the fallout before release, so that change has since been reverted.

The second change was to add a size argument to free(9). This is currently not used, as most callers pass 0 to indicate unknown, but will allow us to simplify some code on the free side and make some other fun changes as well.

For userland malloc(3), I did some work to accelerate threaded applications. I now have a stable first version of this ready, but it will wait for the next release as well.

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

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

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

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

Eventually, there was discussion about why there are adduser, useradd, and "user add" commands and how terrible they were. There was a suggestion to get rid of the perl based adduser, but many people prefer the interactive interface because they add users so infrequently that the additional prompting is super helpful. Unfortunately, I fell for their trick and looked inside the file. I am now working on rewriting adduser with some more modern perl style, I got started on that on Friday evening and got about half way through an initial rewrite by Sunday night. The current design I am looking at is providing a module to do the heavy lifting so that people scripting system management tools (in perl) can talk to a better API than forking out and driving one of the existing scripts. I hope to make it easy to write your own tools to manage users safely and programmatically, while also providing a tool with a friendly, interactive frontend that is also easy to drive from a shell script.

Ljubljana is beautiful, the people were amazing and so much good, vegan food. Plus the weather was overcast, all of which kept me from getting too homesick for Portland, OR. I really enjoyed how friendly and welcoming all of the people we met there were and how well we worked around the surprisingly few language barriers.

As this was my first time in Europe, I left the hackathon on Monday morning and took a shuttle to Venice as recommended. The recommendations were always "Venice? Don't go there, it's so touristy! Oh, you've never been? You should go and see it at least once." So Lisa and I went and added to the number of tourists. We have learned that we really enjoy traveling the world and I am greatly looking forward to the next hackathon for an excuse to finally see more of the world. It did make me want to improve the number of human languages I can do basic things in.

I too need to be sure to mention what a good job Mitja did organizing the hackathon, many, many thanks to him and to Dijaski dom Tabor.

(всё-таки вики для такой работы удобнее - не в обиду; и ещё нужно словарик составить терминов для единого стиля... Да, я не помню свой новый пароль от почты и поэтому не помню и auth-ключ - zhuk)

Ещё один отчёт с завершившегося недавно хакатона g2k14, от Марка Эспи:

В Словении я был в первый раз. За несколько часов - к счастью, удалось избежать гроз - осмотрел столицу. Очень интересное соединение никогда не видел подобного сочетания восточной Европы, южной Европы и туристических мест (КОРЯВО).

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

После продолжительного подпинывания, Вадим Жуков таки закоммитил digikam-kde4 [порт Digikam для KDE4, - В.Ж.]. Я провёл креш-сборку и информировал его о найденных проблемах, которые он быстро исправил.

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

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

... а ещё пакет "quirks" содержит в себе список уязвимых версий пакетов, благодаря чему вы получите сигнал опасности, если вам требуется обновиться из-за уязвимости в старой версии и при этом новой версии пакета на зеркале нет.

Всё это лишь уведомляет пользователя, так как срезы пакетов требуют определённого времени для расползания по зеркалам... У нас есть идеи, как побороть ЭТУ проблему, но после обсуждения с вовлечёнными сторонами было принято решение отложить внедрение до следующего релиза в связи с необходимостью чересчур серьёзных переделок.

Я также пытался решить проблему с необходимостью наличия исходных текстовой базовой ОС для сборки пакета "pkglocatedb". К моему большому удивлению, Тео согласился, и мы зашли даже дальше, чем изначально планировалось, благодаря чему снапшоты теперь будут включать locate-базы как для базовой системы, так И для иксов.

Я провёл немало времени, играя с этими базами: теперь и pkg_check использует их, позволяя проверить систему полностью. По-прежнему слишком много лишних сообщений, но прогресс налицо.

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

Ещё я должен упомянуть о отдельном cpp [препроцессоре C - прим. ред.] для calendar и xrdb, теперь иксы не потребуют для своей работы установки базового набора comp.

Как обычно, встречаться лицом к лицу собратьев по разработке очень помогло некоторым проектам продвинуться вперёд.

Спасибо [OpenBSD] Foundation за спонсирование этого мероприятия, а также Мите за место, всё было организовано настолько хорошо, что нам даже не приходилось о чём-то задумываться.

> всё-таки вики для такой работы удобнее - не в обиду; и ещё нужно словарик составить терминов для единого стиля...

не вижу особой разницы с вики. в вики они обычно лежат мёртвым грузом и никто не шевелится. :)

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

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

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

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

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

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

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

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

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

Будем надеяться, что этот энтузиазм насчёт файловой системы сохранится, потому что теперь я должен переключиться назад на GSoC (Google Summer of Code) - в задачи, которые мне знакомы. Надеюсь, что файловая система, сломанная у меня сейчас, когда-нибудь поможет починить вашу... [эти слова оказались пророческими, и после этого мы с Мартином вели обширную переписку о поломках. прим. ред.]

> не вижу особой разницы с вики. в вики они обычно лежат мёртвым грузом и никто не шевелится. :)

В вики есть средства организации одновременной работы, тот же MediaWiki умеет предупреждать об одновременном редактировании. Плюс рядом можно класть тот же словарик - который в вики может пополняться не одним человеком (который может уехать, заболеть, помереть или просто не иметь времени). Вот обсуждения и новости в вики выглядят по-идиотски, согласен.

> меня вот больше Тео беспокоит - там три предложения, которые уже неделю не переведены, потому что не могу их сути постичь :(

... и никто не шевелится. ;) Сейчас гляну.

я тебе и в веб-интерфейсе эхи могу выложить сбоку отдельный словарик. :)

и любые записи вести :)

> я тебе и в веб-интерфейсе эхи могу выложить сбоку отдельный словарик. :)

А как _я_ в него что-то добавлю? Вот встретил я какой-то неоднозначный термин, хочу добавить свой перевод - а как? Неудобняк-с.

> и любые записи вести :)

А править их? В вики можно хоть по абзацу переводить, без лишних движений: открыл текст, поправил, сохранил. Перечитал, захотел исправить косяк - снова то же самое (скажем, в только что отправленном переводе отчёта Марка Эспи я у себя же насчитал как минимум крупных косяка). Ну и история тоже лишней не бывает, особенно при массовых правках (заменах терминов, скажем).

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

> А как _я_ в него что-то добавлю? Вот встретил я какой-то неоднозначный термин, хочу добавить свой перевод - а как? Неудобняк-с.

ща на примере офлайнизатора покажу, только руки до него не дошли... там просто отдельная эха в боковой панели транслируется :)

http://off.51t.ru

> Просто берите свой любимый ii-клиент, прописывайте адрес http://off.51t.ru/u/, выбирайте интересные эхи, загружайте и читайте.

http://off.51t.ru/u/ выдаёт 404. :((

логично, ведь это точка для клиента, а не для юзера :)

http://off.51t.ru/u/e/off.gatter.14

http://off.51t.ru/u/m/WkifCDi5oOs5zwmzybAL

http://off.51t.ru/m/WkifCDi5oOs5zwmzybAL

> ну, сделай вики, если тебе так удобнее

Ты знал, ты знал! Пошёл я искать вики-систему, написанную по-человечески... и не нашёл. :( Избаловался, что ли... Хоть сам пиши. Ну или идти к ii прикручивать функционал. :)

в ii когда-то была вики :) http://r.51t.ru/wiki.14

ещё у меня было две самописных. но вики, это ссылки, которые надо прокликивать. а никто не прокликивает :) а если ещё и два уровня иерархи...

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

а так... вики, которая позволяет экспортировать сообщение из ii, затем издеваться над ним, а затем обратно импортировать - это было бы интересно :)


ps. ты можешь сделать DNS, чтобы на любой адрес ipv6.51t.ru отдавала ipv6-адрес и только его? я ns пропишу.

ps2. допереведи два предложения от тео :) остальные статьи я тисну так :)

> ты можешь сделать DNS, чтобы на любой адрес ipv6.51t.ru отдавала ipv6-адрес и только его? я ns пропишу.

Эм. Пока у тебя есть запись вида "*.51t.ru. IN A 149.210.140.35", я ничего не смогу сделать... Если только я не тупой, и трюк вида "ipv6.51t.ru является отдельной зоной" каким-то волшебным образом не сработает.

> допереведи два предложения от тео

Ой, а я так и не отправил, значит... Ща.

> Эм. Пока у тебя есть запись вида "*.51t.ru. IN A 149.210.140.35", я ничего не смогу сделать... Если только я не тупой, и трюк вида "ipv6.51t.ru является отдельной зоной" каким-то волшебным образом не сработает.

ну сделай сейчас ресолв ipv6.51t.ru :) я прописал туда левые NS-записи, и A-запись уже не срабатывает :)

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

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

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

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

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

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

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

В этом плане, ситуация схожа с тем, как getentropy(2) была вынесена из sysctl. Забавно, как одно приводит к другому.

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

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

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

Ну вот как-то так уже работает:

$ host -t ANY ipv6.51t.ru 127.0.0.1  
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

ipv6.51t.ru has SOA record ns1.ohvost.ru. mail.51t.ru. 2014080402 28800 7200 864000 86400
ipv6.51t.ru name server ns1.ohvost.ru.
ipv6.51t.ru has IPv6 address 2a01:7c8:aab0:4af::5

а чтобы любой адрес *.ipv6.51t.ru работал? чтобы я мог все сервисы и на 51t.ru и на ipv6.51t.ru вешать, одни для ipv4, другие для ipv6 (кстать, уже нашёл и исправил косяк регистрации при работе ipv6).