Как сообщается в листе рассылки Linux-дистрибутива Gentoo, его команда разработчиков приняла решение совершить форк проекта udev и тем самым стабилизировать его развитие. В сообщении Ричарда Яо (Richard Yao) говорится:

Всем привет!

Ни для кого из нас не секрет, что текущее направление развития udev под руководством новой команды, выпустившей systemd, крайне безрадостное. Линус Торвальдс «очень подозрительно отнесся к тому факту, что поддержка udev перешла в какой-то сумасшедший режим, вносит изменения, создающие всем проблемы, и полна явного и всепоглощающего идиотизма».

Я поговорил с некоторыми разработчиками в Gentoo, и все мы разделяем озабоченность Линуса. Я принял решение собрать команду и форкнуть udev. Помимо всего прочего, мы хотим убрать ограничение отдельного раздела для /usr. Официальное объявление будет сделано немного позднее на этой неделе.

Высказанное решение еще предстоит к рассмотрению специальным советом разработчиков Gentoo Linux, заседание которого организаторы проекта просят перенести на декабрь, чтобы лучше подготовиться и все обдумать.

>>> Подробности

Очень часто приходится гуглить некоторых личностей, которые указывают в контактах только никнейм. Выработал несколько уже привычных приемов, результативность примерно процентов 60-80. Могу в принципе описать это в виде статьи на ЛОР-вики, что даст каждому возможность что-то добавить.

Вопрос - оно кому-нибудь нужно?

Добрый день! Хочу настроить правильную ротацию файлов, такого вида: 1-ый понедельник месяца делается полный бэкап, со среды по пятницу делается инкрементный, когда наступает понедельник следующего месяца бакула очищает том, и использует его по новой.

Проблема в том, что иногда в 1 первый понедельник месяца клиентский компьютер не доступен, в среду запускается инкрементный бэкап, так как полный бэкап не был сделан в понедельник, то он он копирует полностью данные, соответственно расписание сдвигается, и в итоге получается за месяц выходят 2 полных бэкапа, а нужно, чтобы выходило один полный бэкап остальные инкрементные, следующий месяц всё по новой. Есть ли в бакуле опция задавать хранение тома не по дням, а по количеству заданий?

Привожу пример конфига клиента на текущий момент:

# Client (File Services) to backup
Client {
  Name = pc-02-fd
  Address = proizv2
  FDPort = 9102
  Catalog = MyCatalog
  Password = "Pd2F6HSF/VbM6+/gevgvCXuSaQ/9Qze5g2Y07xFoXM9b"      # password for FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

Job {
Name = pc-02-job
Type = Backup
Level = Full
Client = pc-02-fd
FileSet = "pc-02-fileset"
Schedule = "pc-02-schedule"
Storage = pc-02-stor
Messages = Daemon
Pool = pc-02-pool
Priority = 10
}

FileSet {
Name = "pc-02-fileset"
Include {
Options {
compression = GZIP
signature = MD5
WildFile = "*.doc"
WildFile = "*.xls"
WildFile = "*.odt"
WildFile = "*.ods"
WildFile = "*.docx"
WildFile = "*.xlsx"
WildFile = "*.xlsm"
WildFile = "*.ppt"
WildFile = "*.pdf"
WildFile = "*.txt"
WildFile = "*.rtf"
WildFile = "*.zip"
WildFile = "*.rar"
WildFile = "*.7z"
WildFile = "*.xml"
WildFile = "*.djvu"
IgnoreCase = yes
}
Options {
Exclude = yes
RegexFile = ".*"
}
File = "c:/Documents and Settings/user/Рабочий стол"
File = "d:/ПНООЛР"
File = "d:/Документы"
File = "d:/Common"
}
}


Pool {
Name = pc-02-pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 30d
Maximum Volume Bytes = 80G
Maximum Volumes = 1
Maximum Volume Jobs = 17
Label Format = "pc-02-"
Recycle = yes
Recycle Oldest Volume = yes
}

Storage {
Name = pc-02-stor
Address = 192.168.0.149
SDPort = 9103
Password = "ko1ZSWu4QoBioHL-F4r0JDfOFnmWrById"
Device = pc-02-storage
Media Type = File
}

Schedule {
Name = "pc-02-schedule"
Run = Full 1st mon at 09:00
Run = Incremental wed-fri at 14:30
}

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

Механизм версионирования протокола аналогичен таковому для расширений Хorg. Основная идея в том, что новые версии никогда не нарушают обратной совместимости, вместо замещения старых запросов и событий происходит дополнение. Объект wl_registry уведомляет клиентские приложения о поддерживаемых версиях протокола. Если сервер использует более старый протокол, приложение не будет посылать неподдерживаемые запросы.

Впрочем, устаревшие интерфейсы могут быть удалены, но только после большого промежутка времени в статусе «deprecated» и только при наличии полноценной замены.

Описание политики версионирования:

• Стабильность протокола и сгенерированного кода, объявленных в wayland.xml, а также клиентского API, определённого в wayland-client.h, будет обеспечиваться для всех версий ветки 1.хх. В ветке 1.хх протокол может быть расширен, но все приложения, собранные с libwayland-client.so версии 1.0.0, будут работать и с версиями в пределах 1.хх.
• Серверная часть сгенерированного кода и серверный API останутся стабильными в пределах ветки 1.0.х. В главной ветке могут быть различные миграции кода между Wayland и Weston или другие ломающие API ситуации. В итоге может быть выпущен релиз 1.1.0, сохраняющий стабильность протокола и на стороне сервера, но чётких планов в этой сфере пока нет.
• Weston будет сохранять стабильность API и ABI в пределах ветки 1.0.х. Работа над новыми функциями проолжится в главной ветке.

Изменения с версий 0.95.0 и 0.99.0:

• Безусловно, самое значительное изменение - более безопасное API нитей. Удалены обратные вызовы из основного API и представлен новый механизм: wl_event_queue.
• Механизм атомарного обновления поверхностей. Ранее точного определения момента обновления поверхностей просто не существовало, что могло привести к появлению артефактов. Теперь существует запрос wl_surface.commit, который должен использоваться для применения изменений к поверхностям.
• Более точная проверка ошибок.
• Удалены неименованные ARRAY_LENGTH и container_of из API.
• Исправлено большое количество ошибок и существенно дополнена документация.

Напомним, что на данный момент вывод через Wayland поддерживается в Qt 5, GTK+ 3, Clutter и EFL. Также ведётся работа по внедрению поддержки Wayland в SDL.

Для желающих поэкпериментировать доступен git-репозиторий проекта Wayland, а так же Live-дистрибутив для тестирования.

>>> Подробности

Что нужно сделать, чтобы firefox в KDE выглядело нормально(т.е. системная тема и все такое) и можно ли сделать так, чтобы вкладки были на заголовке окна, как в винде? Kubuntu 12.10

Хочу поделиться радостью, завтра иду забирать посылку.

В связи с этим возник вопрос будет ли кому интересен обзор сего девайса? Если да, то какие тесты прогнать кроме классической компиляции опенофиса? =)

Фотки для Ъ: http://www.tekmote.nl/WebRoot/StoreNL/Shops/61504599/504E/3D7D/65C6/3C86/1466...

http://www.tekmote.nl/WebRoot/StoreNL/Shops/61504599/504E/3D7D/65C6/3C86/1466...

http://www.tekmote.nl/WebRoot/StoreNL/Shops/61504599/504E/3D7D/65C6/3C86/1466...

В гугл не пойду, так как в этом жанре куча шлака, и только истинные Ъ знают что мне посоветовать.

Собственно появилась необходимость собрать оболочку для запуска одного единственного приложения. Можно собрать генту, но это как крайний вариант. Собственно нужен дистрибутив, который занимает минимум места, в котором есть X-сервер без всяких лишних оболочек, поддержка сети. И в котором все это получается без длительного копания в настройках. Желательно, чтобы вся система влезла в 512 метров.

Если для всех имеющихся дистрибутивов надо выкидывать руками все лишнее (как в той же слаке), то тогда буду делать генту.

Здравствуй, ЛОР!

Собственно, $сабж.

учебники, хауту, и прочее — лесом, интересует именно справочник, типа мануал. в ЯП я ноль, но нужно.

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

1) Запуск двух иксов и настройка KDM.

У меня две видеокарты NVIDIA, не знаю, прокатит такой способ с ATI.
Сперва нам нужно найти адрес устройств, делается это так:

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF100 [GeForce GTX 480] (rev a3)
04:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7600 GT] (rev a1)

Соответственно нас интересует первая колонка.

Затем нам нужно запустить два экземпляра Xorg
Делается это так:

Xorg -config /etc/X11 -br -nolisten tcp -isolateDevice PCI:1:0:0 vt6 #Первый
Xorg -config ~ -br -nolisten tcp -sharevts -novtswitch -isolateDevice PCI:4:0:0 vt5 #Второй, в качестве пути к конфиге я намеренно указал неверный путь, для того, что бы конфига сгенерилась на лету.

Соответственно пример конфиги KDM:

cat /etc/kde4/kdm/kdmrc
http://pastebin.com/2CHkVa7h

2) Назначение устройств ввода:
Был в сети пример через конфиги иксов, но мне не понравилось то, что в таком случае нужно эти конфиги таки писать. Потому я сделал через xinput

Вывод списка устройств:

xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Gaming Mouse id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Dell Dell USB Keyboard id=8 [slave keyboard (3)]
∼ Logitech USB Optical Mouse id=10 [floating slave]
∼ AT Translated Set 2 keyboard id=11 [floating slave]

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

DISPLAY=:0 xinput --float 10
DISPLAY=:0 xinput --float 11
DISPLAY=:1 xinput --float 8
DISPLAY=:1 xinput --float 9

Соответственно, добавляем эти строки в /etc/kde4/kdm/Xsetup, и в /etc/kde4/kdm/Xreset. (Я на всякий случай добавил и в /etc/kde4/kdm/Xsession)

На этом этапе, у вас два икса, каждый со своим набором клава/мыш.

3) Разделение аудио.
Вариант для ленивых, с пульсаудио я не расматриваю, так как не пользуюсь им.
Как это делается в ALSA. Двух звуковух у меня нет, поэтому я делю звук по каналам. Передний канал на первого пользователя, задний на второго.
Основная идея в использовании ttable.
pcm.alc883 {
type dmix
ipc_key 2048 #Нужно для того, что бы все пользователи использовали общий dmix
ipc_perm 0777
slave {
pcm «hw:CARD=Intel,DEV=0» #Править под себя
rate 44100
period_time 0
period_size 1024
buffer_size 16384
channels 8
}
bindings { #Почему-то без этого у меня не заработало.
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
}
}
# green - «Front» in Alsa mixer
pcm.a {
type plug
slave {
pcm «alc883»
channels 8
}
ttable.0.0 1 #Тут рулим каналами
ttable.1.1 1
}
# gray - «Surround» in Alsa mixer
pcm.b {
type plug
slave {
pcm «alc883»
channels 8
}
ttable.0.2 1
ttable.1.3 1
}

Пример моей рабочей конфиги: http://pastebin.com/aZwNE4RS

Разумеется у пользователя в хомяке должен лежать файл ~/.asoundrc, с чем-то вроде этого:
pcm.!default {
type plug
slave {
pcm «d»
channels 8
}
}

Собственно на этом все. У меня все работает. (Конфига называется asound.conf.old потому как я временно отключил разделение звука, разумеется реально она должна лежать в /etc/asound/conf)

Перемещено JB из talks

Добрый день, всем.
Собственно, после крайне неприятного случая, когда из-за бракованной американки (резьба нахрен оторвалась), пришлось с матом нестись в подвал и сливать систему отопления (всего около 200 литров, но так как потекло на первом этаже из двух, спускать пришлось не все), задумался что надо бы запилить датчики протечек.
Собственно, мысль простая. Solenoid Valve внизу + датчики протечек на батареи. Система задетектила протечку - сначала сигнализируем секунд тридцать, потом запускаем аварийную последовательность: останавливаем газовый котел (благо у него нашелся интерфейс для смартхаусов, который придется раскурить еще), и сливаем всю жидкость из системы в бак в подвале. Если зима, то приемлемую температуру поддержат конвекторы, оставшиеся со времен когда газ еще не провели.
Вопрос в датчиках протечек. Раскурив готовые решения, понял что это УГ по сатанинским ценам, тянущее за собой кучу проприетарщины. Понял дешевле и проще запилить свое, благо наработок много, часть даже уже работает.
Пока думаю кастомную борду сделать на MSP430 ибо мало кушают (вариант со встроенной RF частью), заодно налеплю термодатчики, чтобы проще было узнать на какой батареи надо спустить воздух.
Вопрос в самом детекте протечки.
В голову приходит только классическая схема из Р.Графа. на двух 2N2222 транзисторах, которая детектит замыкание двух контактов водой и выдает 1 либо 0. Но проблема в том, что у батареи 4 места откуда может потечь: вход, выход, заглушка, кран Маевского. Получается ставить надо минимум 4 выносных пятака с той схемой, что не комильфо. Может есть какие более современные варианты детекта протечки?
Linux при том, что все это будет подключено к имеющемуся самописному смартхаус серверу на базе OpenWRT c вебгуем в виде плагина к Luci.

Funtoo Linux 3.6.3-pf + Awesome WM

Композитинг / тени: Compton
Шрифты: Terminus (awesome) + Droid Sans Mono / Slashed (патченный для vim-powerline)
Тема GTK2/GTK3: Zukitwo Dark + иконки Faenza

Редактор: VIM + powerline
Файловый менеджер: SpaceFM
Симулятор калькулятора HP-42S: Free42
Менеджер буфера обмена: x11-misc/qlipper

Обои интерактивные, прошу заценить: раз, два.

В крон добавлен скрипт, который каждые 2 минуты рандомно меняет картинку, т.е. через каждые две минуты - загораются другие окна, т.е. на самом деле 8 разных обоин =D

На старте система потребляет: 52 мб. RAM

Программное обеспечение для управления домашними квантовыми сетями, наподобие SEQOQC, теперь стало свободным и перелицензировано под GPL, а ряд используемых протоколов также стандартизирован IETF. Такие сети используются для шифрования передаваемых данных с помощью безусловно стойкой квантовой криптографии.

Последний стабильный релиз — R7 Де Бройль, девелоперская версия — R8 Планк. Работа с квантовой сетью осуществляется через устройство qd и библиотеку libqkd. Сеть работает через виртуальные сетевые интерфейсы q3p0, q3p1, реализующие квантовый протокол point-to-point, и настраивается стандартным образом через ifconfig. Имеется поддержка квантового роутинга через OSPF.

При отсутствии настоящего оборудования для квантовой криптографии имеется возможность работать с свободным симулятором квантовой сети. Как симулятором, так и остальным софтом поддерживаются дистрибутивы Linux, основанные на Debian и RedHat, но рекомендуемая разработчиками система — Debian «Squeeze». Доступны исходники, а также deb/rpm-пакеты для 32-битной и 64-битной версий Linux.

Проект имеет свой багтрекер и форум поддержки, имеется возможность создавать собственную среду разработки.

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

Метод работы квантовой криптографии в доступной неспециалистам форме объяснён в статье здесь. Перспективы и мотивация её использования — здесь.

>>> Подробности

Приветствую.

Имеем XEN VDS (HVM)...

root@server:~# uname -a
Linux server.ru 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Управляется сервер при помощи ISPmanager Light. На сервер по очереди устанавливались proftpd, vsftpd (обозначенная ниже проблема актуальна в обоих случаях). На сервере отключен фаервол (во всяком случае iptables -L не показывает ничего), в конфигах серверов был разрешён пассивный режим.

Проблема - из некоторых мест FTP у людей работает нормально, к нему удаётся подключиться, авторизоваться и в пассивном режиме получить список каталогов. Но у некоторых людей, удаётся только подключиться и авторизоваться, список каталогов в пассивном режиме получить не удаётся, соединение просто отваливается по тайм-ауту.

У тех кто не может нормально работать с FTP фаервол отключен точно и ничего соединение не блокирует (с другими FTP серверами в пасивном режиме они работают нормально). В активном режиме, по SFTP всё так же отлично работает у всех. Права и владелец на файлы и каталоги проверен - там всё корректно. Конфиги в случае с proftpd и vsftpd стандартные, критичных изменений не делалось (разве что в процессе поиска решений в гугле, но потом все изменения откатывались назад).

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

Вопрос - что это может быть и как вычислить, по каким причинам у кого-то FTP работает без проблем, а у кого-то в пассивном отваливается по тайм-ауту?

Буду благодарен за направление в нужную сторону, потому как у самого идеи уже закончились.

есть такой баг, да
но как его воспроизвести 100%?
у меня получается только при долгих аптаймах - от пары дней до пары недель.
тупо засранный кэш не помогает - дело не в нём.
от распараллеливания не зависит.
как?

Есть такая тема как «презентационные диски». На них много что может быть, но в моей теме это готовый виртуальный тур по объекту заказчика.

Но есть сложности: в1х не во всех ноутах (да и настольниках) есть отсек под диски в2х когда там лежит 100500 файлов (именно сто тысяч+, не метафора), то линза мечется в панике\поиске.

есть мысля сдавать тиражи на флешках. (есть компании к-е дают флешки «одноразовые» - их нельзя будет стереть или изменить файлы). гравирока, оформление.

но есть нюанс: диск - большая такая хрень, к-ю потерять сложнее. да полиграфия интереснее (на самом диске картинка, обложки разные)

а флешки то как упаковывать?

Эпичный срач на LKML, Торвальдс жырно негодует. Для Ъ, мнение патриарха обозначено в теме сообщения.

https://lkml.org/lkml/2012/10/3/484

On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers <kay@vrfy.org> wrote:
>
> Nothing really «breaks», It's «slow» and it will surely be fixed when
> we know what's the right fix, which we haven't sorted out at this
> moment.

A thirty-second pause at bootup is easily long enough that some people might think the machine is hung.

I also call bullshit on your «it will surely be fixed when we know what's the right fix» excuses.

The fact is, you've spent the last several months blaming everybody but yourself, and actively told people to stop blaming you:

https://bugzilla.redhat.com/show_bug.cgi?id=827538#c12

and have ignored patches that were sent to you:

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html

despite having clearly seen the patch (you *replied* to it, for chissake, and I even told you in that same thread why that reply was wrong at the time).

> I also have no issues at all if the kernel does load the firmware from
> the filesystem on its own; it sounds like the simplest and most robust
> solution from a general look at the problem. It would also make the
> difference between in-kernel firmware and out-of-kernel firmware less
> visible, which sounds good.

So now, after you've dismissed the patch that did the equivalent fix in udev (Ming Lei's patch basically disabled your idiotic and wrong sequence number test for firmware loading), you say it's ok to bypass udev entirely, because that is «more robust».

Kay, you are so full of sh*t that it's not funny. You're refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs, and say that we should have done so from the very beginning.

Yes, doing it in the kernel is «more robust». But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we *revert* the thing that broke.

So yes, we're clearly better off doing it in the kernel.

Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill.

Linus

Плевок в рожу Леннарта: https://lkml.org/lkml/2012/10/2/303

> I basically tried a few different approaches, including deferred probe(),
> as you suggested, and request_firmware_async(), as Kay suggested.

Stop this crazy. FIX UDEV ALREADY, DAMMIT.

Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

Lennart/Kai, fix the udev regression already. Lennart was the one who brought up kernel ABI regressions at some conference, and if you now you have the *gall* to break udev in an incompatible manner that requires basically impossible kernel changes for the kernel to «fix» the udev interface, I don't know what to say.

«Two-faced lying weasel» would be the most polite thing I could say. But it almost certainly will involve a lot of cursing.

Жира много, наслаждайтесь, вот ветка целиком: https://lkml.org/lkml/2012/10/2/194

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

Долго витала мысль поднять OpenVPN между машинами, rsync настроить и т.д. Но в итоге забил. Накатил Firefox Sync и столлманонеугодный (да и вообще какой-то корявый) Ubuntu One. Счастлив и доволен. Теперь картинки с котятами и сейвы веснота всегда со мной. Хотя за нежелание собирать дебки под (!) дебиан хочется плюнуть космонавту в рожу.

ЛОР, а синхронизируешь ли ты данные? Если да, каким инструментом и почему именно им?

Собственно, уже написал.

На данный момент он дорос до версии v0.2.2 и в нём реализовано всё, что я собирался реализовывать. Код здесь: https://github.com/i-rinat/reiserfs-defrag/archive/v0.2.2.tar.gz

В плане сохранности данных реализовано журналирование как метаданных, так и самих данных (нужно включить, указав параметр командной строки). Сама схема журналирования похожа на data=ordered в ext3/4, когда сначала пишутся данные, а только потом происходит обновление метаданных. Актуальные данные никогда не переписываются на месте, всегда происходит копирование на пустое место. Это снижает производительность, но значительно снижает вероятность повреждения. Собственно, сейчас повреждения возможны только если диск сойдёт с ума и начнёт писать куда не просили. По крайней мере, мне нравится так думать.

В составе есть краткая документация.

В далёком будущем появится версия v0.3, в которой ожидаются убавление тормозов в режиме tree-through и улучшение производительности для больших директорий.

Доброго времени суток!
Терзаюсь вопросом: а как же запилить на свой sgs2 новенький CM10?
Телефон только обновлялся, полностью стоковая прошивка.
Как я понял, для ClockWorkMod нужен рут, а инструкции по рутованию телефона я вижу только для 4.0.3 (с предложениями даунгрейдиться с 4.0.4 до 4.0.3 и рутовать телефон, после чего прошивать odin'ом 4.0.4).

Вообще, кто пользовался CM10? Как оно? Более-менее стабильно работает?

Ну и вообще, насколько безопасно прошивать телефон? Последние опыты с прошивкой были в 2005-2006 годах с Motorola E398, как «кирпич» вернуть к жизни я знал =), а с этим хз.

Ну и как вопрос с рутованием? Лишает гарантии?