#  Re: g2k14: Marc Espie on ports and packages
51t (lenina,1) → zhuk@  –  02:04:36 2014-08-04

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

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

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

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


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

ps2. допереведи два предложения от тео :) остальные статьи я тисну так :)
#  Re: g2k14: Marc Espie on ports and packages
zhuk@ (lenina,131) → 51t  –  20:49:08 2014-08-03

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

Ты знал, ты знал! Пошёл я искать вики-систему, написанную по-человечески... и не нашёл. :( Избаловался, что ли... Хоть сам пиши. Ну или идти к ii прикручивать функционал. :)
#  Re: дошли
51t (lenina,1) → zhuk@  –  16:40:02 2014-08-03

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

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

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

http://off.51t.ru/m/WkifCDi5oOs5zwmzybAL
#  Re: дошли
zhuk@ (lenina,131) → 51t  –  16:35:40 2014-08-03

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

http://off.51t.ru/u/ выдаёт 404. :((
#  дошли
51t (lenina,1) → 51t  –  15:50:26 2014-08-03

http://off.51t.ru
#  Re: g2k14: Marc Espie on ports and packages
51t (lenina,1) → zhuk@  –  15:26:41 2014-08-03

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

ща на примере офлайнизатора покажу, только руки до него не дошли... там просто отдельная эха в боковой панели транслируется :)
#  Re: g2k14: Marc Espie on ports and packages
51t (lenina,1) → zhuk@  –  15:25:43 2014-08-03

ну, сделай вики, если тебе так удобнее... :) мне удобнее лента, когда тут всё потоком идёт, и не надо по страницам скакать туда-сюда. главное, чтобы тексты перевести, а кому как удобно - это дело десятое :)
#  Re: g2k14: Marc Espie on ports and packages
zhuk@ (lenina,131) → 51t  –  15:23:19 2014-08-03

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

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

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

А править их? В вики можно хоть по абзацу переводить, без лишних движений: открыл текст, поправил, сохранил. Перечитал, захотел исправить косяк - снова то же самое (скажем, в только что отправленном переводе отчёта Марка Эспи я у себя же насчитал как минимум крупных косяка). Ну и история тоже лишней не бывает, особенно при массовых правках (заменах терминов, скажем).
#  Re: g2k14: Marc Espie on ports and packages
51t (lenina,1) → guest  –  15:03:11 2014-08-03

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

и любые записи вести :)
#  Re: g2k14: Marc Espie on ports and packages
guest (lenina,2) → 51t  –  14:59:41 2014-08-03

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

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

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

... и никто не шевелится. ;) Сейчас гляну.
#  Re: g2k14: Martin Pelikan on ext4, filesystems in general
51t (lenina,1) → vit01  –  13:44:30 2014-08-03

Мартин Пеликан пишет в отчёте с 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) - в задачи, которые мне знакомы. Надеюсь, что файловая система, сломанная у меня сейчас, когда-нибудь поможет починить вашу... [эти слова оказались пророческими, и после этого мы с Мартином вели обширную переписку о поломках. прим. ред.]
#  Re: g2k14: Marc Espie on ports and packages
51t (lenina,1) → guest  –  13:27:21 2014-08-03

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

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

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

меня вот больше Тео беспокоит - там три предложения, которые уже неделю не переведены, потому что не могу их сути постичь :(
#  Re: g2k14: Marc Espie on ports and packages
guest (lenina,2) → vit01  –  13:15:59 2014-08-03

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

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

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

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

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

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

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

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

>> Читать далее
#  ORIG: g2k14: Andrew Fresh on Programming Perl
51t (lenina,1) → All  –  04:01:07 2014-07-31



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.

>> Читать далее
#  ORIG: Ted Unangst on the Art of the Tedu
51t (lenina,1) → All  –  04:00:28 2014-07-31

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.
#  Re: он сказал openxcom!! :)
vit01 (lenina,50) → 51t  –  05:36:16 2014-07-28

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, которые искал пару лет, и коммитил некоторые вещи, касающиеся этого.

>> Читать далее
#  черновик от тэо
51t (lenina,1) → All  –  10:30:23 2014-07-26

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.

>> Читать далее
#  ORIG: g2k14: Landry Breuil on Taming Mozilla
51t (lenina,1) → All  –  16:59:46 2014-07-25

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!
#  черновик от матфея
51t (lenina,1) → All  –  16:51:25 2014-07-25

Матье "бешеный француз" Херб (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
#  Re: ORIG: g2k14: Matthieu Herrb on Bringing X Forward
51t (lenina,1) → 51t  –  18:12:33 2014-07-23

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