Re: Прошу помощи в bash-скрипт - кавычки
On Wed, 11 Mar 2020 15:10:36 +0300 Sergey Matveev wrote: > *** Victor Wagner [2020-03-11 14:50]: > >Просто перл надо ВЫУЧИТЬ. В нем есть все, что есть в awk, sed и tr, и > >многое-многое другое. А то приходят люди с визуалбейсковским > >бэкграундом и начинают текст обрабатывать на perl с помощью функций > >substr и index. > > Полностью поддерживаю! Плюс это всё зачастую в Perl ещё можно и в > one-liner писать, заменяя sed/tr/whatever. Плюс Perl везде одинаков Особенно с тех пор, как отказались от идеи выпуска Perl 6, который должен был отличаться от Perl 5 сильнее, чем Python2 от Python 3 и решили что то, что разрабатывалось под именем perl 6 это все же отдельный язык. > (+-) и его скрипты будут одинаково работать как под BSD, так и под GNU > системами, в отличии от sed/grep/awk, GNU версии которых отличаются от > BSD ощутимо. Плюс из коробки, без дополнительных модулей, в нём и с Это вы еще Solaris не видели с его /usr/bin, /usr/xpg4/bin, /usr/ucb, /usr/ccs/bin и /opt/csw и /usr/sfw, в каждом из которых свой sed/grep/awk. Да еще awk бывает mawk, gawk, nawk. Первый для котов, второй для собак, а третий вообще для русалок. В этом плане, конечно Ларри, сумевший, в отличие от Гвидо, избежать альтернативных реализаций - велик. > попадались), да и зачастую он в любом дистрибутиве идёт из коробки, в > отличии от Python/Lua/Ruby/whatever. А нежелание людей изучить ровно Ну как сказать. Вот в каких-то андроидах мне как раз попадался python (правда допотопный и без стандартной библиотеки), а perl не было. > этот один инструмент мне не понятны, тем более, когда при этом > выбирают кучу других, зачастую тоже их не зная, да ещё и страдая от > несовместимости реализаций (bsd vs gnu). Но вообще, по опыту как собственной разработки, так и использования чужих больших проектов на perl, могу сказать, что у него, как и у shell есть свой предел. Но если предел разумного размера шелловского скрипта - это порядка экрана, то предел разумного размера перлового скрипта, это порядка тысячи-двух строк не считая pod-документации. Если проект разрастается сильнее, значит perl в качестве инструмента выбран неправильно. А вот у питона предел значительно больше. Особенно если слушаться pylint и аккуратно делить проект на модули. Проектов на Lua я видел гораздо меньше, но те, которые видел заставляют задуматься. --
Re: Прошу помощи в bash-скрипт - кавычки
On Wed, 11 Mar 2020 14:38:13 +0300 Dmitry Semyonov wrote: > On Wed, 11 Mar 2020 at 11:59, Victor Wagner wrote: > > > А вообще крайне рекомендую, если вдруг выясняется, что для > > формированмия команды в шелловском скрипте используется более двух > > уровней подстановок, плюнуть и переписать его на perl, python, > > ruby, lua - любом другом скриптовом языке. > > После буквального следования таким советам кому-то потом придётся > ломать голову над сотней-другой строк питоновской лапши вместо десятка > строк понятных шелловских команд. Часто лучше один раз разобраться и Так не надо писать лапшу. На любом языке можно написать плохой код. Да, скорее всего код на более низкоуровневом языке (а perl и python - более низкоуровневые языки, чем shell), окажется более объемным. Но от от этого он не обязательно станет менее читаемым. > > Как пример ложного понимания универсальности "любых других скриптовых > языков" можно привести обработку структурированного текста. То, что на > awk делается максимум парой десятков строк понятного кода, часто > превращают в неудобоваримый алгоритм на 100+ строк универсального > языка. Если это делается парой десятков строк на awk, то примерно в то же количество строк это делается и на perl. Более того, специально для для решения этой задачи автор перла написал a2p. Просто перл надо ВЫУЧИТЬ. В нем есть все, что есть в awk, sed и tr, и многое-многое другое. А то приходят люди с визуалбейсковским бэкграундом и начинают текст обрабатывать на perl с помощью функций substr и index. Плюс к этому есть стандартные библиотечные модули для обработки основных структорированных форматов, авторы которых предусмотрели разные странные случаи, о которых у большинства писателей наколеночных скриптов даже мысли не возникает, пока они лбом об эти грабли не стукнутся. --
Re: Прошу помощи в bash-скрипт - кавычки
On Wed, 11 Mar 2020 10:03:29 +0100 Nikolai Kondratiev wrote: > Спасибо, действительно - воспользуюсь perl. > Кстати, вот еще рекомендую недавний пост Эрика Раймонда на эту тему http://esr.ibiblio.org/?p=8622 --
Re: Прошу помощи в bash-скрипт - кавычки
On Wed, 11 Mar 2020 09:42:33 +0100 Nikolai Kondratiev wrote: > Привет всем! > > Мне нужно сформировать и выполнить в скрипте команду вида > > ccc 'xxx yyy' > > т.е команду с одним аргументом, в котором есть пробел. Нужно представить себе, как работает интерпретатор - он берет строку, и начинает ее разбирать. Сколько проходов по строке сделает интерпретатор, столько нужно и пар кавычек ставить, поскольку каждый проход одну снимет. А вообще крайне рекомендую, если вдруг выясняется, что для формированмия команды в шелловском скрипте используется более двух уровней подстановок, плюнуть и переписать его на perl, python, ruby, lua - любом другом скриптовом языке. --
Re: Virtualbox
On Tue, 14 Jan 2020 14:17:11 +0300 "Dmitry I. Kulagin" wrote: > > Мне как-то libvirt не показался. Его концепция разграничения доступа > > в корне противоречит тому, что мне кажется правильным unix-way. > > (и вполне поддерживается qemu), он зачем-то использует постоянный > > процесс-демон, отличный от собственно qemu-system. Ну и XML, да. > > "Ну и XML, да." С этим полностью согласен, редактировать неудобно. > Но некая абстракция от qemu-system и ручного управления и сетью > (linux-brigde или openvswitch), и дисковой подсистемой и, > непосредственно, настройками виртуалок нужна. Нужен демон для > асинхронного запуска и остановки виртуалок и сбора статистики. > Можно, конечно, OpenNebula забабахать (одна из самых простых облачных > платформ), но для одной машинки это перебор. Вот по-моему, для одной машинки демон для сбора статистики это перебор. Поэтому я написал свой собственный уровень абстракции над qemu-system, старательно добиваясь, чтобы он был прозрачным. То есть если он чего не умеет, то не мешал бы делать это через опции командной строки qemu или его монитор. На данный момент это питоновский скрипт из чуть более чем тысячи строк. (а man-страница к нему - более 500 строк). Живет здесь: https://www.wagner.pp.ru/fossil/vws или https://github.com/vbwagner/vws Название - Virtual WorkStation напоминает что это решение скорее для интерактивной работы, чем для серверов. Хотя... --
Re: Virtualbox
On Tue, 14 Jan 2020 12:49:43 +0300 "Dmitry I. Kulagin" wrote: > > Да, смотрю уже, как на KVM по-человечески ставить. > > У меня гуишный AQEMU стоит, как-то им пользовался. > > Но это гостевой Linux, а вопросы с виндой остаются... > libvirt и virt-manager - достаточно удобный инструмент, более > тонкая настройка делается прямым редактированием xml > виртуальной машины, кстати, libvirt умеет хранить образы Мне как-то libvirt не показался. Его концепция разграничения доступа в корне противоречит тому, что мне кажется правильным unix-way. (и вполне поддерживается qemu), он зачем-то использует постоянный процесс-демон, отличный от собственно qemu-system. Ну и XML, да. Но вообще в разозлился на libvirt и решил написать свою альтернативу я из-за работы с USB-устройствами. Когда подключаешь к VM ну допустим eToken, потом VM останавливаешь, eToken из машины выдергиваешь, а в следующий раз у тебя эта VM не запускается, потому что в её конфигурации написано "здесь был eToken". Вообще это поттеринговщина какая-то этот ваш libvirt. Имеется вполне нормальная юниксовая программа qemu-system, которая управляется из командной строки, из удобочитаемого .ini-style конфигурационного файла, qemu-qa.conf, или простым текстовым протоколом через мониторный сокет. Нет же надо было нагородить библиотеку с развесистым API, демонов каких-то, xml-ную конфигурацию. --
Re: Virtualbox
On Mon, 13 Jan 2020 00:00:24 +0300 artiom wrote: > Виктор, это всё замечательно, но машины-то изначально были в VBox, и > мне не переводить всё на QEMU хочется, а просто запустить, чтобы > выполнить свою прикладную задачу, не переделывая окружение. А вот Oracle вам такого шанса не предоставит. Только переделывать. И раз уж переделывать - то так, чтобы следующие 5-10 лет не пришлось с этим связываться. Для этого по крайней мере надо чтобы не требовались out of tree ядерные модули (именно из-за этого я в свое время отказался от vmware), да и чтобы интерфейс не менялся. Конвертация образа диска из форматов VMWare и VirtualBox для qemu - операция совешенно штатная. > > > Касательно QEMU/KVM: я давно не пользовал его. > Для серверов, без сомнения, - штука отличная, предпочтительный > вариант. Для пользовательских ОС, я не знаю. > Просветите, как у него с графикой сейчас? Хорошо у него с графикой. Ну то есть насчет 3d года, три не смотрел, а там вроде активная работа шла. Но с нормальной офисного класса 2d там все очень давно хорошо. Поддерживаются три способа доступа к графике - встроенной SDL-based, VNC и SPICE. Пользоваться надо, естественно Spice, поскольку только она поддерживает seamless desktop integration, clipboard sharing, и прочие полезности. Заодно и USB redirection можно не с хоста делать, а с той машины, где spice client запущен. Ну и аудио само собой тоже через SPICE. > Насколько хороша поддержка того же Windows? Мне хватает. > Т.е., могу я поставить гостевую винду и получить (без извращений, > штатно): > > - Графическое ускорение (что мне совершенно необходимо). Тут я не копал, признаюсь честно. Что-то там активно делается, а вот до какого уровня дошло - не знаю. Когда я этим вопросом интересовался, полноценный OpenGL в виртуалке был только у VMWare, т.е. VirtualBox и QEMU/Spice были в этом плане одинаково плохи. Да и то, запустить мне в VMWare его толком не удалось, от был слишком требователен к видеокарте на хосте. > - Расшаренные каталоги между гостем и хостом. В принципе - умеет. Но лучше либо на хост поставить полноценную самбу, если нужно каталоги с хоста пробрасывать, либо ходить по RDP, если надо с той машины. где ты сидишь и она не совпадает с хостом. > - Интеграцию с хостовым UI хотя бы на уровне автоматического > определения принадлежности мыши и d Ставишь spice vdagent в виртуальную машину и все ОК. > - Проброс оборудования? Оборудование разное бывает. Вот с пробросом PCI-устройств не развлекался. А если речь идет об USB, то я уже выше писал - на выбор. Хочешь с хоста пробрасывай, (с машины где оно запущено), хочешь с клиента (машины где у тебя спайсовый вьюер запущен). Проброс аудио - совершенно замечательно. Интерфейс чуточку кривой, т.е. оно делается не через параметры, а почему-то через переменную окружения, но если правильно включить, работает из коробки.
Re: Virtualbox
В Sun, 12 Jan 2020 22:39:47 +0300
artiom пишет:
> Общие виртуальные машины и настройки Virtualbox у меня хранятся в
> отдельном каталоге отдельного пользователя.
> Для этого в его домашнем каталоге есть подкаталог с настройками Vbox.
>
> Раньше, чтобы указать путь к настройкам, использовался
> `/etc/vbox/vbox.cfg`.
>
> Я давно не запускал VBox, он потребовался, я увидел, что машин нет.
> `vbox.cfg` стал obsolete, да я и не помню, что там писать.
>
> Подскажите, как сказать VBox, чтобы настройки он искал в указанном
> месте?
>
VirtualBox это разработка Oracle (исходно Sun, но скуплена с потрохами
Oracle). Надо прочитать что тут недавно Линус Торвальдс писал про
другую разработку с той же историей - ZFS, после чего выкинуть нахрен
эту проприетарную поделку и пользоваться нормальынм QEMU с
KVM-акселерацией.
https://www.realworldtech.com/forum/?threadid=189711=189841
--
Victor Wagner
Re: сообщения в freshclam.log
On Mon, 23 Dec 2019 12:17:00 +0200 Sohin Vyacheslav wrote: > Приветствую, > > Недавно заметил в freshclam.log периодически повторяющиеся сообщения > наподобие такого: > > Can't query daily.25671.105.1.0.6810DA54.ping.clamav.net > > Причем они появляются ежедневно около 11:30 утра. > Ранее и позже обновление ClamAV проходит успешно. > > Это из-за невозможности соединиться с *юping.clamav.net? Есть у меня подозрение, что хоста *.ping.clamav.net не существует и никогда не существовало. А есть DNS-запись с типом TXT daily..ping.clamav.net, проверяя которую clamav узнает, появились ли новые обновления базы. И скорее всего проблемы с резолвингом этой записи связаны с тем, что ваш роутер некорретктно работает с TXT-записями. --
Re: Suspend to ram на debian buster и lenovo thnkpad e330
В Mon, 23 Dec 2019 00:29:28 +0200 Vitaly Polyakov пишет: > Всем привет. > > Установил на Lenovo ThinkPad E330 последний Debian 10. > > При запуске Suspend-to-ram (через меню Mate - ждущий режим) - ноутбук > успешно уходит в режим энергосбережения (единственный светодиод > индикатор начинает моргать и вентилятор затихает). При нажатии на > кнопку питания - вентилятор запускается, светодиод тоже загорается. > Но больше ничего не происходит. Ноутбук ни на что не реагирует. "Ни на что" это включает попытки зайти по ssh с соеднего компьютера или нет? У меня тут есть несколько машинок (как ноутбуков, так и десктопов) у которых в аналогичнйо ситуаии не просыпается видеокарта. То есть не включается экран а все остальное работает. > Как провести диагностику, куда глядеть? Мне помогает переключиться на текстовую консоль и обратно. Т.е. На черном экране нажимаешь Ctrl-Alt-F1 - и вдруг на экране появляется текстовый лог загрузки Ctrl-F7- большшое сообщение "эта сессия заблокирована, вы будете перенаправлены на диалог разблокрировки через несколько секунд" Если вместо Ctrl-F7 нажать Сtrl-F8 - сразу попадаешь на диалог разблокриовки. -- Victor Wagner
Re: yandex-browser и пароли
On Fri, 13 Dec 2019 12:54:26 +0300 Artem Chuprina wrote: > У меня используется keepassx. Правда, линукс у меня все еще jessie, в > более новых другая мажорная версия, и я не проверял совместимость с > андроидом. Там менялся в том числе и формат файла. А вот Витус, > подозреваю, проверял. На винде он же, но стоит не первый год. Проверял. Тот keepass, который тогда был в fdroid.org, был совместим с обоими версиями. Тот, который сейчас - заведомо совместим с новой. Вот когда у меня половина машин была с jessie, а половина со stretch - было неудобно. Поскольку там совместимость односторонняя - импортировать старую базу новая версия может, а записать - нет. Помнится, я даже багрепорт на эту тему постил. --
Re: yandex-browser и пароли
On Thu, 12 Dec 2019 13:47:28 +0100 Viktor Karpovych wrote: > Вот трындец чел не может остановиться. Нас тут много. > Ну обсосали же ху-yandex со всех сторон и обложили тоже, так нет же, > опять. Тебе же ответили, что здесь не по этим делам, звони Тема "как помешать наглой и жадной корпорации нарушить твою приватность" очень важна в современном интернете. Особенно для пользователей свободных ОС, т.е. для людей которые ценят свою свободу. Можно еще обсудить приложения других жадных и наглых корпораций - Microsoft (который для Debian выпускает Skype) - Oracle (который deb-пакетов не делат, но Oracle InstantClient на Debian вполне ставится, на днях проверял) - Telegram (клиент у него вроде бы опенсурнсный, и даже входит в состав дистрибутива, но на f-droid про подобные программы пишут "promotes proprietary services") Ну и многие многие другие. --
Re: yandex-browser и пароли
On Thu, 12 Dec 2019 16:02:41 +0500 Stanislav Vlasov wrote: > Вот только яндекс не хочет, чтоб с его сервисами взаимодействовали вне > его программ и теперь запись на его диск через вебдав чего-то больше > нескольких мегабайт сильно тормозит-с... > И заодно убрал из документации что-либо про вебдав Ну естественно, не хочет. И чем больше не хочет, тем больше оснований подозревать его в том, что его програмы - это malware и их близко к своей машине подпускать нельзя. Хотя полагаю, что исчезновение информации про webdav из документации связано в основном со странной политикой микрософта по поводу поддержки этого протокола в файлменеджере windows. Поди яндексовская техподдержка уже замучалась отвечать на вопросы "а что нужно доставить в windows server, чтобы это работало?", "а почему после обновления windows 10 у меня все отвалилось?". --
Re: yandex-browser и пароли
On Thu, 12 Dec 2019 13:14:57 +0300 Pavel Volkov wrote: > On пятница, 6 декабря 2019 г. 13:07:51 MSK, Victor Wagner wrote: > > В яндексе категорически не умеют писать клиентский > > софт. Поэтому не следует ставить себе на машину ни одного байта > > бинарного кода, написанного в яндексе. > > Ну не знаю, Карты и Такси для ОС "Android" достаточно удобные и > эстетичные :). > Ну в ОС Андроид Гугль специально принял меры, чтобы неумение разработчиков писать программы, которым можно доверять, не мешало. Поэтому на телефон ставить продукты от яндекса можно. Равно как веб-приложения от яндекса внутри браузера открывать, благо там авторы браузера позаботились об изоляции одного сайта от другого. А в GNU/Linux, основное преимущество которого заключается в легкости обеспечения взаимодействия программ и обработки одних и тех же данных разными программами, лучше продуктов от яндекса не ставить. --
Re: выравнивание раздела: кому верить, fdisk или parted?
В Sat, 7 Dec 2019 12:40:23 +0300 Eugene Berdnikov пишет: > > > By default, Linux follows an optimistic memory allocation > > > strategy. This means that when malloc() returns non-NULL there is > > > no guarantee that the memory really is available. In case it > > > turns out that the system is out of memory, one or more processes > > > will be killed by the OOM killer. > > Мне что-то подсказывает, что выставление лимитов на память для > процесса и лимитов на количество процессов позволяют свести оптимизм > к величине, соответствующей объёму физической памяти. может проще сказать sysctl vm.overcommit_memory=1 ? -- Victor Wagner
Re: yandex-browser и пароли
On Fri, 06 Dec 2019 12:51:07 +0300 Александр Завгородний wrote: > Да, паролей собрано уже не мало, и их достаточно непросто каждый раз > вводить, к Яндексу пока не обращался, хочу сначала услышать ваши > мнения. Ну если речь идет о мнениях... То мое мнение такое: В яндексе категорически не умеют писать клиентский софт. Поэтому не следует ставить себе на машину ни одного байта бинарного кода, написанного в яндексе. Серверную часть - это они умеют. Более того, они даже умеют соблюдать стандарты на протоколы. Поэтому, скажем, с яндекс-диском я работаю исключительно с помощью сторонних web-dav клиентов (davfs2, cadaver, gnome vfs). Далее, производителям браузеров никогда не следует доверять что либо ХРАНИТЬ. Не умеют они локальные хранилища, а нелокальные, предлагаемые ими, категорически не стоит использовать. Поэтому password manager должен быть отдельно от браузера и любое межпроцессное взаимодействие его с браузером должно происходить после явного действия пользователя в password-manager-е. Да, это несколько снижает удобство. Придется все же нажимать явным образом в другом приложении кнопочку "я хочу, чтобы мне заполнили эту форму логина". Но за повышение безопасности всегда надо расплачиваться понижением удобства. И в данном случае я считаю плату адекватной. --
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019 12:51:18 +0300 sergio wrote: > On 06/12/2019 12:24, Sergey Spiridonov wrote: > > > Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает > > отступ. Может быть в этом есть какой-то сокрытый смысл? > > А в вашем представлении сама таблица разделов места не занимает? > Насколько я помню те времена, когда я копался в загрузочных секторах с шестнадцатиричным редактором и дизассемблером, она занимает 64 байта, и в одном 512-байтном секторе с ней умещается еще и загрузочный код MBR и 2-байтовая сигнатура в конце.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019 10:42:55 +0100 Sergey Spiridonov wrote: > On Wed, 04 Dec 2019 08:45:30 +0300 > Max Kosmach wrote: > > > >Device Start End Sectors Size Type > > >/dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem > > > > > >Partition 1 does not start on physical sector boundary. > > > > Вроде ж правда написана - 512*65535 не кратно 4к? > > Почему parted начинает с 65535, а не с 65536? В чём логика? По-моему, это когда-то, лет 15 назад типичный диск имел 63 сектора на дорожку. Да-да. тех самых, 512 байтных. С тех пор и осталась идея выравнивать на "границу цилиндра". --
Re: О кроссплатформенности Баша
On Wed, 2 Oct 2019 13:28:14 +0300 "Andrey Jr. Melnikov" wrote: > > Вот когда собираешь этот самый OpenWRT для роутера с 8Мб флэш, то > > тогда там не будет ни bash, ни PostgreSQL. Да даже и про ядерный > > модуль tun десять раз подумаешь, класть его туда или нет. > А ты сначала 10 раз удивись, зачем в этом изделии всегда собран atm, > а там глядишь и на tun.ko место найдется. ATM оторвать, это, дело конечно, хорошее. Но если мы кладем tun, значит нам надо что-то, что его использует. Скорее всего openvpn. А это значит нужна нормальная криптобиблиотека, которая сама по себе немаленькая. А то по умолчанию там openvpn с такой библиотекой собрана, в которой по-моему ни одного невзломанного алгоритма не поддерживается. И производительность этого добра на дохлом процессоре роутера будет тоже понятно какая. Оттуда и возникает вопрос, а может нам и tun там не надо, может лучше поддержку трех лишних usb-модемов положить? > и это дохлый TL-MR3020. Тут не только на tun.ko, а еще и на кучу всего Ну кому TL-MR3020 дохлый а по мне так в нем места более чем дофига, если с DLink Dir-300 или ASUS WL500g оригинальным сравнивать. > интересного места хватит. >
Re: bash: команда не найдена
On Wed, 02 Oct 2019 10:16:32 +0300 Pavel Volkov wrote: > On суббота, 28 сентября 2019 г. 23:51:52 MSK, Victor Wagner wrote: > > Желательно взять такую книжку, в которой будет объяснено > > почему такие команды как hdparm или ovenvpn помещают > > в /sbin (или /usr/sbin, но нынче одно - симлинк на другое), и > > почему у нормального пользователя /sbin в PATH быть не должно. > > А почему не должно? Есть какие-нибудь побочные эффекты или неудобства? Да, конечно. Как минимум tab completion медленнее работает. если в пути мешаются команды, на выполнение которых все равно прав нет. > Считается, что 4 директории — дела давно минувших UNIX-дней. В Раньше люди были умнее. Потому что до администрирования Unix-систем добирались только немногие избранные. А сейчас дево-псов понабежало, которые мух от котлет отделять не умеют. > дистрибутивах, наиболее восприимчивых к Леннарту, существует только > /usr/bin — всё остальное засимлинкано. Говорят, Леннарта критикой в интернете чуть не довели до самоубийства, И жаль, что не довели. > Иначе тяжело копипастить юнит-файлы между дистрибутивами — везде те > или иные бинарники в разные места кладут. > А /usr отдельным разделом никто уже не делает, так что проблем не > возникает. Проблем не возникает не из-за этого. А из-за того, что есть initrd, содержащий достаточно утилит, чтобы смонтировать /usr.
Re: О кроссплатформенности Баша (was: Firefox неправильно восстанавливает запомненную при выходе позицию)
В Tue, 01 Oct 2019 23:59:03 +0300
Dmitry Alexandrov <321...@gmail.com> пишет:
> > Ну это разве что OpenWRT или еще какая жуткая эмбедщина, где вообще
> > нет нормальных coreutil, а только busybox.
>
> В OpenWRT Баш, разумеется, есть. И полноценные утилиты тоже. И
> вообще никакая это не «жуткая эмбедщина», а вполне себе популярный
> дистрибутив ГНУ/Линукса для безголовых машинок — да там даже
> PostgreSQL есть.
Вот когда собираешь этот самый OpenWRT для роутера с 8Мб флэш, то тогда
там не будет ни bash, ни PostgreSQL. Да даже и про ядерный модуль tun
десять раз подумаешь, класть его туда или нет.
--
Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
В Tue, 1 Oct 2019 22:26:04 +0300 Vladimir Zhbanov пишет: > On Tue, Oct 01, 2019 at 10:03:43PM +0300, Dmitry Alexandrov wrote: > ... > > > Интересно, а что помешало просто добавить Баш в число этих самых > > пакетов? > > И "облегчить" тем самым работу сопровождающим для всех > дистрибутивов, которые захотят наш проект использовать? А вдруг > там его и в помине не было? И насколько этот самый Баш Ну это разве что OpenWRT или еще какая жуткая эмбедщина, где вообще нет нормальных coreutil, а только busybox. > кросплатформенный, чтобы собираться, например, под > Cygwin/MinGW/msys/msys2/etc? Мне даже голову не хочется ломать о bash, помоему, первое что в подобнрых проектах собирают. -- Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
В Tue, 1 Oct 2019 20:52:20 +0300 Vladimir Zhbanov пишет: > Млин, выбросить бы ещё autotools куда-нибудь... > В наше время многие используют cmake. Мы в openssl-gost-engine, например. Был у нас в конторе один товарищ, который пытался сборку постгреса на cmake переписать. (там призовая игра что есть совершенно отдельные скрипты для сборки Visual Studio, и хотелось это все объединить). Года два все сообщество напряженно следило за его успехами. Потом он плюнул на это дело, уволился от нас и уехал аж в Японию. -- Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Tue, 1 Oct 2019 12:48:42 +0300
"Andrey Jr. Melnikov" wrote:
> Victor Wagner wrote:
> > On Tue, 1 Oct 2019 11:11:48 +0300
> > "Andrey Jr. Melnikov" wrote:
>
>
> > > Дак а кто автору злобный буратино, что он не пользует конструкцию
> > >
> > > _pacman=$(command -v pacman)
> > > if [ -n "${_pacman}" -a ]; ...
>
> > Ну зачем так сложно?
> Затем, что потом сразу можно вызвать ${_pacman} -- ${file} без
> повторного поиска по дискам в $PATH - а где там тот pacman лежало.
>
> > Ведь command -v возвращает ненулевой код если команда не найдена.
> > Я ведь с самого начала про то и пишу, что НЕ ИСПОЛЬЗУЙТЕ КОМАНДУ
> > test, для того чтобы проверить условие, уже проверенное другое
> > командой.
>
> О, расскажи как мне, как в
> if /usr/bin/неведомафигня ; then
> обработать вот это:
> /usr/bin/неведомафигня: cannot execute binary file: Exec format error
А нам оно в данном случае надо?
Бывают такие ошибки которые НЕ НАДО обрабатывать. Ежели юзер сумел
загнать свою систему в такое состояние, он сам себе злобный Билл Гейтс.
Как известно любая мера безопасности порождает новые риски. Поэтому
нужно наступить на горло собственной песне и перестать защищаться от
слишком маловероятных угроз (поскольку это ослабляет защиту от более
вероятных).
В /usr/bin НЕ МОЖЕТ БЫТЬ неведомой фигни. Любая фигня которая попадает в
/usr/bin (а не /usr/local/bin или ${HOME}/bin) должна быть ведома
пакетному менеджеру.
--
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Tue, 1 Oct 2019 12:23:34 +0300 "Andrey Jr. Melnikov" wrote: > Artem Chuprina wrote: > > > > On 29 September 2019 9:50:02 pm GMT+02:00, "Andrey Jr. Melnikov" > > wrote: > > >> При этом что в шелле есть логические операции, что в командной > > >> строке test есть логические операции и они РАЗНЫЕ. > > >Витус, как так ЛОГИЧЕСКИЕ операции могут быть разными? AND и OR - > > >они и в африке AND и OR. > > > Я, конечно, зануда, но должен заметить, что они у нас ни хрена не > > логические. > Вы мне тут оба-двое зубы не заговаривайте. > > > Они вычислительные, и их результат сильно зависит от порядка записи > > операндов. > > Ух, 1 & 0 = 0 таки не 0 & 1 = 0 ? У вас реальность не подтекает? > > И в приведенном баге - красиво всё - там операнд выглядит как > 'pcmanfm --help >/dev/null 2>&1 -a is_file_url_or_path "$1"' В приведенном баге test как раз нет. Там люди попытаплись честно использовать shell command sequence в качестве условия. Но не шмогли. Потому что, как и некоторые читатели данного списка рассылки, перепутали операнды команды test и шелловское условие. --
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Tue, 1 Oct 2019 11:11:48 +0300
"Andrey Jr. Melnikov" wrote:
> Дак а кто автору злобный буратино, что он не пользует конструкцию
>
> _pacman=$(command -v pacman)
> if [ -n "${_pacman}" -a ]; ...
Ну зачем так сложно?
Ведь command -v возвращает ненулевой код если команда не найдена.
Я ведь с самого начала про то и пишу, что НЕ ИСПОЛЬЗУЙТЕ КОМАНДУ test,
для того чтобы проверить условие, уже проверенное другое командой.
--
Re: «Единственный мне известный логичный язык - это Tcl» (was: Firefox неправильно восстанавливает запомненную при выходе позицию)
On Sun, 29 Sep 2019 20:23:47 +0300 Dmitry Alexandrov <321...@gmail.com> wrote: > > Единственный мне известный логичный язык - это Tcl > > «Схема» предельно логична. Да и вообще, пожалуй, любой Лисп будет > пологичнее Тикля. Пока Схема - вещь в себе, пригодная только для препоадавания курса SICP в МИТ, она может еще и логична (хотя МИТ отказался от нее в пользу Питона, видимо слишком логична для обучения реальному программированию) Но как только на ней решать задачи из реального мира, например приделывают ее к Гимпу, так вся логичность и кончается. И выясняется что здесь читать, здесь не читать, здесь рыбу заворачивали. Вот это - встроенный тип SIOD, его garbage-collector собирает, а вот это - гимповский объект, его будь добр освобождать сам. Примерно то же самое произошло с автолиспом. Если и была в том лиспе, который за основу взят, какая-то логичность, то при приделывании к САПР вся сплыла. Ну и вообще сравните объем R5RS с объемом man Tcl. -- pgpTuKiNONM8y.pgp Description: OpenPGP digital signature
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Sun, 29 Sep 2019 22:50:02 +0300 "Andrey Jr. Melnikov" wrote: > > При этом что в шелле есть логические операции, что в командной > > строке test есть логические операции и они РАЗНЫЕ. > Витус, как так ЛОГИЧЕСКИЕ операции могут быть разными? AND и OR - они > и в африке AND и OR. И от наличия в каком-то замшелом man'e надписей > про "deprectated" Как-как! СИНТАКСИЧЕСКИ. В одном случае &&, в другом -a. И это именно то место, на которое наступили авторы xdg-open. Потому что семантически тоже разница есть. && помимо всего прочего - разделитель шелловских команд, а -a - это ключик, который передается в команду и её личное дело как его интерпретирвоать. Поэтому когда вместо pcmanfm --help && is_file_url_or_path написали pcmanfma --help -a is_file_url_or_path результат оказался несколько некорректен. Хотя сама идея проверять факт сущестоввания команды не через which а вызовом ее с --help тоже мнээ, Полуэкт. Только сейчас оратил на это внимание. --
Re: «Единственный мне известный логичный язык - это Tcl» (was: Firefox неправильно восстанавливает запомненную при выходе позицию)
В Mon, 30 Sep 2019 15:54:59 +0100 Stanislav Maslovski пишет: > On Sun, Sep 29, 2019 at 08:23:47PM +0300, Dmitry Alexandrov wrote: > > Victor Wagner wrote: > > > В Sun, 29 Sep 2019 12:16:57 +0300 Eugene Berdnikov > > > пишет: > > >> Короче, Bourne shell это тяжкий груз наследственности. > > > > > > Любая система, получившаяся сколько-нибудь широкое распространие > > > - это тяжкий груз наследственности. > > > > > Единственный мне известный логичный язык - это Tcl > > > > «Схема» предельно логична. Да и вообще, пожалуй, любой Лисп будет > > пологичнее Тикля. > > Если упор на "логичность", то тогда уж, скорее, PROLOG и его > производные. > "Логический" и "Логичный" это разные вещи. Наиболее распространенный язык с логической парадигмой это make. И вот уж где логичностью и не пахнет.
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
В Sun, 29 Sep 2019 12:36:12 +0300 Eugene Berdnikov пишет: > On Sun, Sep 29, 2019 at 12:31:13PM +0300, Victor Wagner wrote: > > Я уж не говорю про остерхутовскую концепцию safe comartments, > > которая была создана более 20 лет назад и которая намного лучше и > > совершеннее того, что предлагают современные решения для исполнения > > недоверенного кода, включая мобильные ОС. > > Подробнее об этом можно? Вообще Остерхут в прошлом году издал книжку "Phylosophy of Software Design" Но вообще я имел в виду вот эту статью с Usenix 1998 года: https://www.usenix.org/legacy/publications/library/proceedings/usenix98/full_papers/levy/levy.pdf -- Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
В Sun, 29 Sep 2019 12:16:57 +0300 Eugene Berdnikov пишет: > Обычный > человек, выросший в нашей современной культуре программирования, > склонен воспринимать [ ... ] как часть синтаксиса, а не думать > постоянно о тонкостях трактовки параметров со множеством неочевидных > "волчьих ям" (piffalls). > > Короче, Bourne shell это тяжкий груз наследственности. Любая система, получившаяся сколько-нибудь широкое распространие - это тяжкий груз наследственности. Вот возьмем, скажем C, программа на котором подобна гороскопу - по расположению звездочек в ней программист пытается понять что произойдет. Или php. Или концепцию сессии в Unix, которая унаследована со времен последовательных терминалов и не понимает ни мультимедиа, ни съемных файловых носителей, контроль над вставкой-выниманием которых у пользователя. Логики в ИТ вообще нет. Есть куча исторических напластований, причем с принципиально разным полаганием у тех, кто создавал разные слои. Единственный мне известный логичный язык - это Tcl (и то если не брать многие позднейшие библиотеки вроде BWidget). Но "люди, выросшие в нашей современной культуре программирования" не читают трехстраничный man Tcl в котором эта логика изложена, а пытаются действовать "интуитивно" то есть по аналогии с другими известными им решениями, и ругают Tcl за quoting hell, хотя правила раскрытия кавычек в нем элементарны, их изложение укладывается в трех абзацах и исключений НЕТ. Я уж не говорю про остерхутовскую концепцию safe comartments, которая была создана более 20 лет назад и которая намного лучше и совершеннее того, что предлагают современные решения для исполнения недоверенного кода, включая мобильные ОС. -- Victor Wagner
Re: bash: команда не найдена
В Sat, 28 Sep 2019 20:01:31 + "S.Kholodny" пишет: > Привет, ребят! > > Уже который раз натыкаюсь в buster'e на ситуацию, где не могу > запустить команду в терминале - выдает "bash: команда не найдена". > Точно были hdparm, openvpn, другие пакеты.. > > Я устанавливал и повторял установку этих пакетов - apt-get каждый раз > убеждает в том, что самая свежая версия пакета уже установлена, а при > очередной попытке запуска команды - то же самое - "bash: команда не > найдена". > > buster+nonfree > > Как лечить такую хворь? Почитать какую-нибудь чайницкую мнижку по работе в shell, обращая особое внимание на переменную среды PATH. Желательно взять такую книжку, в которой будет объяснено почему такие команды как hdparm или ovenvpn помещают в /sbin (или /usr/sbin, но нынче одно - симлинк на другое), и почему у нормального пользователя /sbin в PATH быть не должно. Заодно можно узнать почему man на эти команды лежит в секции 8, а не в секции 1. После чего почитать man sudoers и настроить sudo так, чтобы при выполнении команд с повышенными правами /sbin в пути был. -- Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
В Sat, 28 Sep 2019 13:41:09 +0300 "Andrey Jr. Melnikov" пишет: > Victor Wagner wrote: > > On Thu, 26 Sep 2019 16:14:50 +0300 (MSK) > > yuri.nefe...@gmail.com wrote: > > [...] > > > Тут мы не на grep экономим, а на test. В смысле на команде > > "квадратая скобка". После найденного мной бага #931822 мне очень > > хочется у тех, кто не понимает что такое команда квадратная скобка, > > в чем ее отличие от > Нет давно такой комманды (в понимании современных shell'ов). Уже > давно везде что '[', что 'test' - builtin. buitin, не builtin синтаксически это все равно команда с параметрами. Проблема в том что люди не понимают, что условием в шелловских условных конструкциях является не какое-то там выражениеп, а именно последовательность шелловских команд, формирующая некий код завершения. А [ - это всего лишь такая маленькая команда для проверки часто встречающихся условий. При этом что в шелле есть логические операции, что в командной строке test есть логические операции и они РАЗНЫЕ. -- Victor Wagner
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Thu, 26 Sep 2019 16:14:50 +0300 (MSK) yuri.nefe...@gmail.com wrote: > On Thu, 26 Sep 2019, Victor Wagner wrote: > > > On Wed, 25 Sep 2019 23:49:53 +0300 (MSK) > > yuri.nefe...@gmail.com wrote: > > > >> # wait for the window > >> while [ $(wmctrl -l | grep --count "Mozilla Firefox") -lt 1 ]; do > >> sleep .5s > > > > А почему такой сложный способ проверки > > почему не просто > > > > until wmctrl -l |grep -q "Mozilla Firefox"; do > > >Не помню, скрипт старый. Скорее всего просто не додумался. >Да и вывод wmctrl не такой длинный что бы на grep экономить. Тут мы не на grep экономим, а на test. В смысле на команде "квадратая скобка". После найденного мной бага #931822 мне очень хочется у тех, кто не понимает что такое команда квадратная скобка, в чем ее отличие от пайплайна и как с этим соотносятся шелловские управляющие конструкции, отрывать клавиатуру и обрекать на пожизненное пользование виндами c одной только мышью. >Кстати, grep -q exit with zero status if any match is found, >так что, все равно пришлось бы думать :) grep с любыми параметрами завершается с нулем, если найдено. Поэтому while заменено на until. Экспериментировать куда надо вставить восклицательный знак, чтобы инвертировать статус второй команды в пайплайне, и работает ли это во всех шеллах, или только некоторых, мне было лень. А думать оно да, полезно. > Ю.
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Wed, 25 Sep 2019 23:49:53 +0300 (MSK) yuri.nefe...@gmail.com wrote: > On Thu, 12 Sep 2019, fed05x wrote: > > > > > Сейчас пользуюсь таким скриптом повешеннаным на хоткей: > > #/bin/sh > > for i in $(xdotool search --maxdepth 2 --class "Firefox"); do # > > --onlyvisible xdotool windowsize $i 800 600 windowmove $i 100 50 > > done > > > > для его его работы нужен xdotool. Довольно удобно. у меня в нём не > > только фф, но и кучка других программ, и все по нажатию клавиши > > выстраиваются как надо. > > Можно и в скрипт запуска запуска firefox такое встроить. > Без хоткеев. > > #!/bin/sh > # open firefox in position (0,0) > # > LANG=en_US.UTF-8 /usr/bin/firefox-esr $@ > /dev/null 2>&1 & > # wait for the window > while [ $(wmctrl -l | grep --count "Mozilla Firefox") -lt 1 ]; do А почему такой сложный способ проверки почему не просто until wmctrl -l |grep -q "Mozilla Firefox"; do >sleep .5s > done > # move to 'g,x,y,w,h' (see man wmctrl) > wmctrl -r "Mozilla Firefox" -e 0,0,0,-1,-1 > > Ю.
Re: cal package russian translation
On Thu, 19 Sep 2019 19:10:15 +0500 dv wrote: > Hello. > > Debian stretch/buster have very strange translation of month's names > in Russian language. > "cal" package in Russian translation uses Genitive case instead of > Nominative case, and gives very strange result. > Января...Декабря instead of Январь...Декабрь. > Please make correction of translation. > Thank you very much. I see correct results in stretch dpkg -l bsdmainutils Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture +++-===-==-==- ii bsdmainutils9.0.12+nmu1amd64 but wrong in buster dpkg -l bsdmainutils Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii bsdmainutils 11.1.2+b1amd64collection of more utilities from F > Best regards, Dmitry. >
xrdpxorg и русская клавиатура
Коллеги, Может кто подскажет как правильно организовать работу с русской клавиатурой при заходе на машину с Debian 10 по протоколу RDP? Пока удалось добиться следующих результатов: Если мы заходим на машину с помощью клиента из комплекта Windows Server 2008R2 (ну такая винда оказалась ближайшая в доступе) или Remmina из Debian 10, то по умолчанию у нас клавиатура не работает. Но если выполнить setxkbmap -layout us,ru -variant ',winkeys' -option 'grp:ctrl_shift_toggle' то переключение клавиатуры по control+shift начинает работать. При заходе клиентом xfreerdp все равно не работает. Попытка указать xfreerdp /kbd:Russian приводит к тому что буквы русские, а переключиться на латинские - никак. Попытка засунуть в /etc/xrdp/reconnectwm.sh вышеуказанную команду setxkbmap видимых эффектов не дает. Попытка засунуть в /etc/x11/xrdp/xorg.conf секцию 'InputClass' с Identifier 'xrdpKeyboard' и соответствующими параметрами xkb тоже не помогла, хотя после этого я на всякий случай сервис xrdp запустил. Хочется добиться естественно, того, чтобы все работало из коробки. Чтобы непросвещенный пользователь windows, запустив встроенный в ОС Remote Desktop получал работающую сессию с общим с его локальной машиной клипбордом и подмонтированным диском, и русский латинский у него бы переключался привычным ctrl+shift. Если то же самое будет работать и у пользователя другого Debian, то еще лучше. Но лучше не только в remmina, поскольку у нее слишком много места на экране занимает ее собственный интерфейс, в отличие от xfreerdp и встроенного клиента Windows. Что интересно, попытка поискать в интернете про xrdp layout switching выводит в основном на страницы на польском и чешском или по крайней мере с упоминанием польских и чешских раскладок. --
Re: Debian stable и браузеры
В Sat, 24 Aug 2019 08:48:38 +0300 Dmitry Alexandrov <321...@gmail.com> пишет: > > Но тут такое дело - она веб-девелопментом занимается. Ей надо > > проверять на апдейченных браузерах. > > Насколько я понимаю, ей надо проверять на _разноверсных_ браузерах. > Да еще и, вероятно, иметь ежедневный браузер. Думаю, что это не так. Если человек занимается веб-девелопментом за деньги, то деньги ему платят не за то, чтобы информация была доступна (в том числе и для людей со старыми браузерами), а за то чтобы можно было продемонстрировать крутизну инвесторам или акционерам. Иначе бы не было необходимости "проверять в апдейченных браузерах" Пишешь совместимо со стандартами, убеждаешься что в Firefox ESR работает, проверяешь W3C-шным валидатором и можешь быть уверен что в более новых браузерах не сломается. Но такой режим работы в наше время возможен только для хоббиистов. Денег за это не заплатят. -- Victor Wagner
Re: Сокрытие факта связи
В Tue, 13 Aug 2019 21:29:18 +0300 Eugene Berdnikov пишет: > On Tue, Aug 13, 2019 at 06:44:06PM +0300, Иван Лох wrote: > > Допустим вы рассылаете шифротекст по большому количеству адресов. > > Следователь полагает, что это Mein Kampf, возбуждается, получает > > санкцию приходит к Вам толпа ребят с шлемах ломает Вашу дверь и т. > > д. Преступление не завершено, но это как бы не важно. Есть же > > статья 30 УК РФ. Сажать можно и за приготовление к совершению. > > Стороне обвинения придётся убедить суд, что имело место приготовления > к преступлению. Когда у кого-то находят гранаты, запалы и прочие > боеприпасы, то утверждение о приготовлении будет звучать убедительно. То это уже состав преступления. Ст 222 УК "незаконное хранение оружия". -- Victor Wagner
Re: Э-почта как единственно нужный мессенджер
В Tue, 13 Aug 2019 18:26:15 +0300 Dmitry Alexandrov <321...@gmail.com> пишет: > Victor Wagner wrote: > > On Tue, 13 Aug 2019 14:12:18 +0300 > > Dmitry Alexandrov <321...@gmail.com> wrote: > >> Если же вы, про электронную почту как таковую, то да — именно ее, > >> очевидно, и нужно использовать для любого рода переписки. Она > >> превосходит всякие новомодные и уже-не-модные поделки как по > >> охвату (причем очевидно критически), так зачастую и по техническим > >> возможностям. > > > > Ну и по оверхеду она тоже превосходит любые новомодные и > > уже-не-модные поделки. На каждое сообщение килобайт-другой > > заголовков > > Вот, честно говоря, не уверен. Так или иначе, это совершенно > неважно: XXI век на дворе, люди «про шашлычки» по FullHD-видеосвязи > треплются, а вы про оверхед от заголовков. XXI век это век мобильного интернета. Поэтому low-overhead протоколы это очень важно. Где-нибудь в гребенях у тебя не будет ничего лучше edge. А уж если речь идет о mesh networking, там вообще каждый байт - это бесценные миллиампер-часы из аккумулятора. > > А когда на каждое предложение требуется реакция собеседника, то, > > естественно, протоколы, заточенные на короткие сообщения - > > предпочтительнее. > > Чем предпочтительнее? Ну кроме ментального блока, что это якобы > естественно? > > > Тем более что в них обычно заложена возможность показа статуса > > собеседника - готов он к разговору прямо сейчас. или нет. > > Есть такое дело. Хотя лично я это воспринимаю как антифичу, ну или в > крайнем случае как бесполезную фичу. В подтверждение своих слов могу Это как раз полезная фича. Просто не все люди любят когда их дергают не по делу. А некоторые одновременно не любят, когда по делу - не дергают. Поэтому возможность выбирать - общаться с этим человеком сейчас по протоколу близкому к интерактинвому или по протоколу с отложенной доставкой имеет достаточно большую ценность. > заметить, что в самом популярном протоколе «заточенном на короткие > сообщения», который прямо так и называется «short messaging service», > ничего такого нет, и никто как-то не жалуется. Вот не надо про этот протокол. Это электронная почта такая, только для GSM-сетей. Там срок доставки может нескольких дней достигать. То кчть это тоже протокол с отложенной доставкой. > > А почта - протокол с отложенной доставкой. Предполагается что > > когда-нибудь человек ее прочитает. Instant Messaging и почта > > решают разные коммуникационные задачи. > > ЧТД. Разница чисто социальная, не техническая. Если вам удобно Да, конечно. Программы для коммуникации - это вообще штука социальная. И их usability определяется тем насколько они поддерживают удобные паттерны взаимодействия между людьми. > иметь два разных адреса: для длинных писем и коротких — так бога > ради, э-почта это легко позволяет. > Мне удобно иметь один адрес, но две разных программы с разным интерфейсом. Как раз тут я считаю крайне полезной фичей XMPP то, что он использует тот же формат адресов, что и электронная почта. > > Да-да. Я, собственно, ничего и не говорил про IRC, только про > мессенджеры — то есть те средства, что для переписки с заранее > очерченным кругом лиц. Ну вот, скажем, телеграм достаточно часто используется для переписки с заранее неопределенным кругом лиц. > > Tox и Jami - они вообще бессерверные. Отсюда их достоинства, отсюда > > и их недостатки. > > Ну, и справедливости ради, много ли этих достоинств? Когда вы за > 444-NAT’ом, то еще как «серверные». А когда у вас маршрутизируемый > адрес, то и э-почта без проблем становится «бессерверной», каковой > она во времена своей молодости и была. Нет, не становится. Электронная почта требует чтобы у вас был сервер, прописанный в MX-записи вашего домена. Собственных, независимых от DNS средств поиска абонента в сети она не имеет. > Во-первых, электронная работает поверх HTTP ничуть не хуже Матрикса. > Есть куча проприетарных протоколов и по меньшей мере один открытый — > Exchange. Ну и пачка веб-клиентов, разумеется. Веб-клиент это не "почта поверх http". Почта поверх http, это когда пользоваель видит нормальную удобную почтовую программу. А что там где-то глубоко внутри компьютера какие-то демоны между собой по http договариваются, это их личное демонячье дело. А веб-клиент это использование для общения по почте заведомо неудобного клиента - браузера. (да, иногда это тоже бывает нужно. Ну это примерно как влезать на третий этаж по канату через окно, вместо того чтобы подняться по лестнице и войти в дверь) -- Victor Wagner
Re: Э-почта как единственно нужный мессенджер (was: Проиграна ли борьба за вычислительную свободу?)
On Tue, 13 Aug 2019 14:12:18 +0300 Dmitry Alexandrov <321...@gmail.com> wrote: > Если же вы, про электронную почту как таковую, то да — именно ее, > очевидно, и нужно использовать для любого рода переписки. Она > превосходит всякие новомодные и уже-не-модные поделки как по охвату > (причем очевидно критически), так зачастую и по техническим > возможностям. Ну и по оверхеду она тоже превосходит любые новомодные и уже-не-модные поделки. На каждое сообщение килобайт-другой заголовков, и это не считая сообщений протокола SMTP. И плюс еще принципиальная семибитность, вынуждающая кодировать тексты на человеческих языках в base64. > Зачем поборники вычислительной свободы агитируют за всякие Джабберы, > и уж тем более (прости господи) Матриксы, я никак взять в толк не > могу. Вероятно, из ложного убеждения в том, что текстовая переписка Затем что Twitter и блог - это разные способы самовыражения. Электронная почта хороша, когда элементарный квант общения содержит пару страниц текста, да несколько мегабайт приаттаченных бинарников. А когда на каждое предложение требуется реакция собеседника, то, естественно, протоколы, заточенные на короткие сообщения - предпочтительнее. Тем более что в них обычно заложена возможность показа статуса собеседника - готов он к разговору прямо сейчас. или нет. А почта - протокол с отложенной доставкой. Предполагается что когда-нибудь человек ее прочитает. Instant Messaging и почта решают разные коммуникационные задачи. Далее, модель серверной подсистемы электронной почты (и связанная с ней модель адресации) примерно такая же как у XMPP. В этом смысле они взаимозаменяемы и оба должны использоваться тогда когда вероятность неотбиваемых атак на серверную инфраструктуру можно не рассматривать. А вот у IRC она не такая, она как у usenet. И там выбивание отдельных узлов из серверного "облака" не является критичным для коммуникации. (при условии что человека пускают на несколько серверов). Tox и Jami - они вообще бессерверные. Отсюда их достоинства, отсюда и их недостатки. > Ну а поскольку для аудиовидеосвязи есть столь же промышленно принятая > и коммерчески успешная сеть — SIP, то псевдосвободные хипстерские > поделия навроде Матрикса не нужны совсем. Матрикс интересен тем, что он работает поверх HTTP. Это позволяет ему проникать через некоторые корпоративные файрволлы, через которые не пустят IRC, XMPP, IMAPS и прочие. А так и правда IRC для хипстеров. -- pgpljmHiaX7c5.pgp Description: OpenPGP digital signature
Re: Сокрытие факта связи (was: Проиграна ли борьба за вычислительную свободу?)
On Tue, 13 Aug 2019 14:44:23 +0300 Иван Лох wrote: > Проблема в том, что многие типы сообщений адресованные > _неограниченному кругу лиц_ могут по действующему законодательству > трактоваться как уголовное преступление, даже если тоже сообщение > адресованное _определенному кругу лиц_ совершенно легально. Поэтому неограниченному кругу лиц мы будем адресовать фотографию моей кошки или пейзаж верхневолжских озер. А определенный круг лиц потом из этого jpeg-посредством технологии Chaffing and winnowing вытрясет настоящее сообщение. --
Re: Сокрытие факта связи (was: Проиграна ли борьба за вычислительную свободу?)
On Tue, 13 Aug 2019 13:17:51 +0300 Dmitry Alexandrov <321...@gmail.com> wrote: > Victor Wagner wrote: > > В Fri, 9 Aug 2019 17:23:22 +0300 Eugene Berdnikov > > пишет: > >> никак не мешают защите канала передачи данных. > > > > Защита канала данных не спасает от анализа метаинформации. > > Информация о том, что абонент с номером таким-то передал > > сттолько-то байт абоненту с номером таким-то и в ответ получил > > столько-то байт - все равно останется в логах > > А от этого спасает прием, успешно работающий на передовой уже сотню > лет, — _широковещание_. Не надо устанавливать никакого канала между > корреспондентами, надо условленным образом сделать сообщение > доступным для неограниченного круга лиц. И чем большее количество > людей его получит, тем лучше. Да, пожалуй. > Из существующих сетевых инфраструктур лучше старого доброго Юзнета > для этого ничего, пожалуй, не найти. Собственно, если отсортируете Ну почему, IRC тоже хорош. Обладает тем же преимуществом что и Юзнет - распределенной серверной инфрастуруктурой по которой распростнаняется сообщение, и поди определи к какому из серверов подключилися настоящий адресат сообщения. Я уже как-то рассматривал у себя в ЖЖ возможность использования IRC для координации выступлений (на примере Ирана, естественно). -- pgpRSiC7wTkFy.pgp Description: OpenPGP digital signature
Re: Проиграна ли борьба за вычислительную свободу?
В Fri, 9 Aug 2019 23:04:35 +0300
Eugene Berdnikov пишет:
> > Не может фирма не зависеть от государства.
>
> Может, просто она должна зависеть от другого государства. Ex:
> Телеграмм.
Вы правда считаете что другое государство более заинтересовано в вашем
благополучии, чем это?
Это государство хотя бы налоги с вас собирает, поэтому подкармливает
овец, которых стрижет, и защищает их от волков.
Другое - прекрасно разменяет ваши интересы и вашу жизнь на сиюминутные
pr-эффект во внутренней политике.
Вот посмотрите на жителей Крыма которым взяли и обрезали доступ ко всем
ресурсам в юрисдикции США, от платежных систем до гитхаба. Просто
для того, чтобы наказать то государство, которое теперь с этого Крыма
собирает налоги.
--
Victor Wagner
Re: Проиграна ли борьба за вычислительную свободу?
В Fri, 9 Aug 2019 20:13:14 +0300
artiom пишет:
>
> Шифрование тут не поможет, его возможно запретить и обнаружить
> шифрованный траффик в канале по высокой энтропии, купив такую систему
> за счёт налогоплательщиков, которых и ограничивают.
Шифрование надо комбинировать со стеганографией. Вот как раз спрятать
где-то внутри аудио-или видеопотока узкий (текстовый) канал с высокой
энтропией легче, чем там же спрятать канал с низкой энтропией.
Лист надо прятать в лесу, и маскировать 80 байт траффика который не
хочется показывать государству 8 мегабайтами траффика, который ничего
предосудительного не содержит.
Вот такие технические меры могут сработать.
в--
Victor Wagner
Re: Проиграна ли борьба за вычислительную свободу?
В Fri, 9 Aug 2019 17:23:22 +0300 Eugene Berdnikov пишет: > > > Задача создания защищенного от господслушивания мессенджера > > действительно имеет техническое решение, но этим решением не может > > быть коммерческая фирма с централизованными серверами и привязкой к > > сотовому номеру. > > Ну почему же? От госпрослушивания -- очень даже может, если эта фирма > не зависит от государства. Централизация серверов и привязка к номеру Не может фирма не зависеть от государства. У нее есть счет в банке, который государство (то, на чьей территории находится этот банк) может арестовать. Централизованные сервера где-то размещены физически, и государственные правоохранительные органы (того государства, где размещен этот датацентр) могут их конфисковать. > никак не мешают защите канала передачи данных. Не путать с защитой > данных на конечных узлах, это другая задача. Защита канала данных не спасает от анализа метаинформации. Информация о том, что абонент с номером таким-то передал сттолько-то байт абоненту с номером таким-то и в ответ получил столько-то байт - все равно останется в логах сервера и будет доступна государству.ю > > А вот понимание того, что госпрослушка в 99.99% случаев будет кормить > разных оборотней в погонах, и лишь в 0.01% помогать ловить шпионов и > террористов, это понимание у обывателя вполне себе присутствует. Я пою о том, что оборотни в американских погонах ничуть не лучше оборотней в российских или китайских погонах. -- Victor Wagner
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, 9 Aug 2019 11:14:31 +0300 Eugene Berdnikov wrote: > Можно, и вообще многие нетехнические проблемы вполне себе можно > решать техническими методами. Для этого и существуют замки, заборы, > шифрование... А последний яркий пример в IT это то как мессенджер > Телеграмм вполне себе техническими методами избавил нас от > гэбешников, которые хотят легимитизировать своё желание залезать в > чью-то личную переписку. И государство ничего сделать не может, > только поливает Пашу Дурова и Телеграмм грязью, мол, наркодилеры им > пользуются, поэтому он плохой. Что-то мне сомнительно, что случай с Дуровым не попадает под известную картинку с овечьим стадом и "Ты что и правда веришь, что человек и собака действуют заодно". Вся эта героическая борьба роскомнадзора с телеграмом выглядит как "борьба нанайских мальчиков". Задача создания защищенного от господслушивания мессенджера действительно имеет техническое решение, но этим решением не может быть коммерческая фирма с централизованными серверами и привязкой к сотовому номеру. Tox может, jami может, даже XMPP-based сеть в какой-то степени может. Но не telegram и не signal. Вообще, конечно интересным решением для независимой коммуникации было бы стеганографическое сокрытие текстового чата внутри аудио или видео конференции, которую ГБ имеет возможность слушать но не слышыт там ничего, кроме обсуждения пьянки с шашлыками или няшных котиков. Но тут наибольшую сложность вызывает необходимость правдоподобный аудио-видео поток с безобидным трепом. Поскольку не человеческие же силы на это тратить. --
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, 9 Aug 2019 00:39:17 +0300 artiom wrote: > 08.08.2019 10:31, Victor Wagner пишет: > > On Thu, 8 Aug 2019 09:47:48 +0300 > > artiom wrote: > > > >> > Как ГБ может заставить чужой браузер > >> > ПолярнаяЛиса отдать в JS тот фингерпринт, который должен > >> > быть у интересного юзеру сайта, а не тот, который в подсунутом > >> > чекистами сертификате? > >> > >> Изначальная посылка была в том, что государство может заставить > >> браузер установить их корневой сертификат. > >> Не пользователя. > > > > Это не совсем верная посылка. Поскольку обсуждение в списке рассылки > > Mozilla было на тему "а надо ли разрешать пользователю ставить такой > > сертификат, или его следует жестоко заблеклистить" > > > > Любопытно. А если пользователь развёртывает систему на изолированном > заводе, при этом все его сертификаты, пользуемые WebUI, > самоподписанные, но он не хочет, чтобы операторам браузер как-то > сообщал о "левом сертификате" (и не сообщал о реально "левом")? Ну очевидно сертификат изолировнного от интернета CA не попадет в блеклист, встроенный в браузер, именно потому, что разработчикам браузера про этот сертификат никто не сообщит. С Казахстаном-то проблема не в том, что это изолированная среда, а как раз в том, что они хотели работать в публичном международном интернете. А так-то подобные MitM сертификаты для корпоративных систем - стандартнейшая практика. Тут вам и антивирус, и intrusion detection. --
Re: Проиграна ли борьба за вычислительную свободу?
On Thu, 8 Aug 2019 09:47:48 +0300 artiom wrote: > > Как ГБ может заставить чужой браузер > > ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у > > интересного юзеру сайта, а не тот, который в подсунутом чекистами > > сертификате? > > Изначальная посылка была в том, что государство может заставить > браузер установить их корневой сертификат. > Не пользователя. Это не совсем верная посылка. Поскольку обсуждение в списке рассылки Mozilla было на тему "а надо ли разрешать пользователю ставить такой сертификат, или его следует жестоко заблеклистить" Далеко не всякое государство может себе позволить заставить чего-то производителей браузера. Американское может, китайское - ну, вероятно, российское - под большим вопросом, а уж казахское... Была пара случаев когда национальные CA - какого-то из эмиратов Персидского Залива и китайский пропихивали свои сертификаты в браузер, а ПОТОМ были пойманы на использовании этих сертификатов для MiTM и с позором выкинуты из ca-bundle. --
Re: Проиграна ли борьба за вычислительную свободу?
On Tue, 6 Aug 2019 15:26:48 +0300 Eugene Berdnikov wrote: > > > > Когда вам отдают токен, вы можете быть уверены, что там ключ именно > > того, кто его передаёт (считаем, что механизмы передачи надёжны). > > Свой ключ ещё надёжнее, потому как не передаётся удостоверяющему > центру. А токен, переданный третьей стороной, может быть этой же > стороной слит в ГБ по требованию госорганов. Им это намного легче > сделать, чем добыть ключ, который никогда не покидал хозяина. Токен, вообще говоря, поддерживает интерфейсы PKCS#11 и PKCS#15, которые позволяют сгенерировать ключ прямо на нем. Это будет еще лучше - ключ, который никогда не покидал токена, и был на этом токене создан только после того, как токен попал в руки к хозяину. --
Re: systemd inittab
В Mon, 5 Aug 2019 05:06:38 +0300 sergio пишет: > On 23/05/2019 10:26, Victor Wagner wrote: > > > Может поискать что другое для управления kvm-виртуалками. > > Я после некоторой возни с libvirt плюнул и вообще свой скрипт на > > питоне написал. > > Я выяснил! Оказывается мэинтейнер libvirt, прикрываясь проблемами > секьюрити systemd, решил, что самое безопасное это добавить > policykit-1 в зависимости libvirt. Пять лет назад. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768376#20 > > Ну и все кому нужно без systemd просто пересобрали пакет с > исправленным debian/control. На мой взгляд, зависимость от policykit - это не самая большая проблема libvirt. Самых больших проблем там три 1. Наличие libvirtd - отдельного процесса, который постоянно запущен, даже если ни одной виртуалки или контейнера нет. 2. То что это библиотека. 3. ХML-ные конфиги. -- Victor Wagner
Re: Не просыпается видеокарта
On Wed, 31 Jul 2019 16:08:30 +0300 Alexander Gerasiov wrote: > On Mon, 29 Jul 2019 07:21:26 +0300 > Victor Wagner wrote: > > > Тут после апгрейда на buster обнаружил на > > двух компьютерах следующий эффект - > > иногда после выключения экрана по таймауту компьютер не реагирует на > > нажатие клавиши и не включает экран. Иногда - нет и все просыпается > > нормально. Закономерности не заметил. > > > > > > Помогает нажатие Сtrl-Alt-F1 и переключение на текстовую консоль. > > После этого нажимаю Alt-F7 и на экране появляется надпись > > "Сессия заблокирована, вы будете перенаправлены на диалог > > разблокировки через несколько секунд". Что и происходит. > > > у меня на ноуте intel себя не очень стабильно ведет, я затащил себе > пару патчей из апстрима: Из апстрима x.org или апстрима ядра? > From e5ff8e1828f97891c819c919d7115c6e18b2eb1f Mon Sep 17 00:00:00 2001 > From: Chris Wilson > Date: Mon, 3 Dec 2018 08:58:39 + > Subject: [PATCH] sna: Skip restoring a mode for link-status=bad if the > crtc was idle > > From c37c7ee0748ba828ec5d2c7304cd2a17af2c8109 Mon Sep 17 00:00:00 2001 > From: Chris Wilson > Date: Fri, 30 Nov 2018 14:11:04 + > Subject: [PATCH] sna: Switch off old outputs on topology changes > > После этого он перестал падать при подключении/отключении дока, но еще > понадобилось отключить power saving в конфиге xscreensaver, иначе он > не включал экран. >
Re: Проиграна ли борьба за вычислительную свободу? (was: systemd-networkd)
On Wed, 31 Jul 2019 07:40:09 +0300 Dmitry Alexandrov <321...@gmail.com> wrote: > > Кажется, вы вплотную подошли к тому, чтобы сформулировать парадокс > Брэдли Куна: свободных программ все больше и больше, а _выжить_ без > несвободных все тяжелее и тяжелее. Ну это на мой взгляд, некоторое преувеличение. Если исключить Firefox лицензию которого вы в соседнем сообщении исключительно аргументировано разбиваете в пух и прах, то у меня на домашнем компьютере последние несколько лет нет НИ ОДНОЙ несвободной программы, а зачастую и ни одного несвободного драйвера. (хотя нет вру, там еще лежит в уголку skype, которым я в норме не пользуюсь, но под рукой на всякий случай держу. Хотя в вообще-то его вполне заменяет файрфокс и сайт skype.com). Еще несколько лет назад я не мог обойтись без Acrobat Reader-а, еще раньше - без VMWare. Сейчас evince и qemu все необходимое в этом плане делают. > >> Кстати, в огромном количестве случаев "чтобы она работала как нам > >> надо" будет "поправить дурацкий глюк в драйвере WiFi" или что-то > >> подобное, так что без драйверов никак. > > Ну это, кстати, нам всем Соединенные Штаты крепко подгадили. Еще > пару лет назад купить «коробочку с вайфайем» по крайней мере бытового > класса, где бы не только драйвер, но и прошивка радиомодуля была бы > свободной, проблем не составляло. А теперь их просто _запрещено_ > продавать. В США запрещено, но того более чем достаточно. Ну оплот свободы и либерализма любит в этом плане подгадить. То криптографию экспортировать запретят, то DRM на законодательном уровне потребуют, то вот это. Впрочем ЕС в этом плане им достойный соперник. На этом фоне Казахстан со своим государственным MitM смотрится примерно так же как его бомбардировочная авиация на фоне американской. > О том и речь. Нужна еще возможность то, что из этих исходников > собирается, на железку установить. И вот в этом месте мы утыкаемся в разницу между GPLv2 и GPLv3. GPLv3 этого требует. Во времена GPLv2 необходимость этого требования еще не приходила Столлману в голову. -- pgpv7R6pvBZQT.pgp Description: OpenPGP digital signature
Re: Не просыпается видеокарта
On Mon, 29 Jul 2019 15:10:44 -0400 Tim Sattarov wrote: > On 7/29/19 12:21 AM, Victor Wagner wrote: > > Тут после апгрейда на buster обнаружил на > > двух компьютерах следующий эффект - > > иногда после выключения экрана по таймауту компьютер не реагирует на > > нажатие клавиши и не включает экран. Иногда - нет и все просыпается > > нормально. Закономерности не заметил. > > > > > У меня похожая ситуация. иногда при выходе из энергосбережения лаптоп > не включает экран. Но у меня оно серьёзнее, машина виснет. при > переходе в консоль я иногда могу увидеть panic сообщение. оно из > драйвера intel. Я грешу на проблемы железа и решил это просто - > запретил выключать экран по таймауту. Жму конпку на мониторе (у меня > два внешних). понимаю, что дубово, но времени разбираться не было :) Запретил выключать по таймауту это каким именно способом? Option "DPMS" "no" в конфиге, или более щадящим Option "Offtime" 0 Еще есть Option "NoPM" "yes" Вот, собственно вопрос в том, что из этого выбрать.
Не просыпается видеокарта
Тут после апгрейда на buster обнаружил на двух компьютерах следующий эффект - иногда после выключения экрана по таймауту компьютер не реагирует на нажатие клавиши и не включает экран. Иногда - нет и все просыпается нормально. Закономерности не заметил. Помогает нажатие Сtrl-Alt-F1 и переключение на текстовую консоль. После этого нажимаю Alt-F7 и на экране появляется надпись "Сессия заблокирована, вы будете перенаправлены на диалог разблокировки через несколько секунд". Что и происходит. На обоих компьютерах видеоадаптеры Intel На одном lspci показывает вот такое: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation 2nd Generation Core Processor Family Integrated Graphics Controller [1849:0102] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
Re: BCO System Cryptographic Plugin
On Thu, 25 Jul 2019 14:06:01 + Коротаев Руслан wrote: > Дмитрий Фёдоров пишет: > > > Нужно было думать об этом раньше, когда выбирали банк. > > Банки с ДБО без винды и джавы существуют, подсказывать не буду. > > А может подскажите? > > Я в своё время пробовал разобраться с «отчественной криптографией» и > ничего не понял. Там помимо токена, нужно покупать лицензию криптопро > и без windows это нормально работать не будет. Как я понял, это 1.Совершенно необязательно именно на cryptopro. Есть еще несколько фирм которые продают реализации отечественной криптографии. Для файрфокса лучшее решение по-моему у Лисси. Насколько я пониамаю список фирм можно посмотреть в разделе Authors RFC 4357. 2. Криптопро выпускает продукты для ОС, отличных от Windows. Модуль для linux у них точно есть. Правда почему-то с интерфейсом виндового CSP. Возможно, впрочем, они ее позиционируют как чисто серверное решение. 3. Насколько я помню, реализация PKCS11 в libnss не содержит того профайла, который необходим для использования российской криптографии. В свое время разные люди разными способами пытались этот туда пропихнуть, но радостных воплей по поводу успеха я не слышал. PKCS11 это очень большой и развесистый стандарт. > криптопро постоянно что-то сканирует, куда-то посылает, оно пытается > понять в каком окружении находится — виртуалка или реальное железо, > от этого зависит тип лицензии. Короче, что-то как-то... > > Если хотите, можете написать названия банков в личку. Но если есть > нормальный банк, который выдает сертификаты ДБО, которые можно В любом случае, придется купить лицензию на какой-нибудь российский СКЗИ, подлежащий поэкземплярному учету. Потому что без сертификата (в смысле бумажки такой) на этот СКЗИ российский суд не будет принимать претензий по поводу электронной подписи. > загрузить в токен (рутокен или алладин), а токен в свою очередь можно > подключить к firefox через PKCS#11 [1], то указать название такого > банка в рассылке будет не реклама, а помощь всем людям, которые > опасаются мошенников. > > [1]: > https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/pkcs11 > pgpEP3fqVLyfN.pgp Description: OpenPGP digital signature
Re: BCO System Cryptographic Plugin
On Thu, 25 Jul 2019 13:49:16 +0300 Grigory Fateyev wrote: > Добрый день! > > Возможно ли установить сиё чудо "BCO System Cryptographic Plugin" в > линукс? Этот плагин необходим для ЛК Банка ВТБ-Бизнес, сайт > https://bo.vtb24.ru/login (если немного подождать, вылезет > предупреждение в шапке). Надоело в винду грузиться за каждым чихом. > > Спасибо! Помнится, когда у меня встала аналогичная проблема - нужно было использовать VPN-протокол который в linux не поддерживался толком, я поставил на своем ноутбуке windows в kvm-виртуальную машину, пробросил туда криптографичекий токен как USB-устройство и все у меня работало. Более того (хотя вам в данном случае, это, похоже, не надо) эта виртуальная машина прекрасно роутила траффик той линукс-системы, в которой она выполнялась и я ходил по ssh и http на машины в офисной сети из самого линукса. То есть без перезагрузки можно обойтись за счет использования виртуализации. Можно ли в случае личного кабинета банка обойтись без использования неудобного браузера - не уверен. (да, конечно сначала я попробовал попатчить sstp_client для того, чтобы он работал с токеном. Но сломался на том, что там требовалась двухтактная авторизация через токен - сначала на уровне протокола sstp, а потом на уровне pppd, который sstp-клиент запускает поверх себя после установления соединения. И вот патчение pppd на предмет криптографической аутентификации уже превысило тот лимит времени, который я был готов выделить на эту задачу). --
Re: systemd-networkd
On Thu, 25 Jul 2019 11:58:01 +0300 Eugene Berdnikov wrote: > > доступа к которым с этим китайцем придется судиться. > > в) оно все нихрена не документировано. > > Железка и драйвера нас не интересуют. А вот базовая платформа общая. Как не интересует? Нас интересует изменить поведение железки так, чтобы она делала то, что надо нам. Свобода N1 по Столлману. Как правило, это подразумевает "собрать образ прошивки, включающий все - и ядро, и драйвера и весь софт, включая модифицированный нами". Производители железяк почему-то очень любят оперировать образами прошивок. Как вспомню сколько пришлось Nokia пинать всем сообществом, чтобы они в N800 и иже с ним сделали обновление ядра через пакетный менеджер. И это Nokia, а не китайцы. Кстати, в огромном количестве случаев "чтобы она работала как нам надо" будет "поправить дурацкий глюк в драйвере WiFi" или что-то подобное, так что без драйверов никак. Еще в большом количестве случаев будет "добавить какой-нибудь модуль из стандартного ядра, который гады-китайцы из экономии места не положили" Что скорее всего выльется в "пересобрать все ядро". Ну или "попатчить CVE которое в mainline попатчили 3 версии ядра назад, а у этих китайцев ядро 5 версий назад и сами они апдейтить его не собраются" > Вам Столман не объяснил, в чём разница между свободным и бесплатным? Мне-то как раз объяснил. Это вы тут пытаетесь нагло врать и утверждать что несовободное свободно. Свобода - это когда я (квалифицированный програмист, обремененный семьей) могу в свободное время от своих других дел, заодно разобраться и с этим. У меня на это хватит времени и сил. Поэтому Столлман существенно важной частью концепции Свободного ПО всегда полагал Toolbox Philosophy, которая сводит время на разбирательство к приемлемому. Поэтому монолитные продукты, такие как Firefox, systemd, libreoffice не могут считаться свободным ПО, по какой бы они лицензии не распространялись. > А думать, что "свобода" это когда можно без подготовки и образования > сесть и сходу поправить что-то в коде гигантского проекта, вроде Евгений, вы нагло передергиваете. Вы прекрасно знаете сколько десятилетий у меня практического опыта работы с Linux, что я вообще-то еще лет 20 назад считался в русскоязычном сообществе достаточно квалифицированным человеком и был комодератором соответствующей фидошной эхи. Поэтому об отсутствии подготовки и образования речь не идет. Речь идет о том, что гигантские проекты должны быть структурированы так. чтобы можно было сесть и за полчаса разобраться где что править. При условии что ты умеешь читать на том языке, на котором оно написано. Вопрос в том, что Столлман в свое время осознавал образовательную ценность текстов программ. Поттеринги и де Иказы - нет. Они пишут не для того, чтобы их тексты читали, а чтобы это работало как магический артефакт, который может модифицировать только его создатель. Программирование - это не квантовая физика. Квантовая физика это явление природы, и уж какая есть, такая есть. Программирование - это тексты, созданные людьми и для людей. Поэтому те люди, которые их создают должны подумать о благе тех, кто придет после них. (кстати самим же проще будет читать и править код, в который пару лет не заглядывал). --
Re: systemd-networkd
On Thu, 25 Jul 2019 09:47:34 +0300 Eugene Berdnikov wrote: > On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote: > > Здесь все не так. И война за свободу ПО, которую начал Столлман в > > середине 80-х - проиграна. > > Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде > внутри линукс, а из лога, если он показывается, торчат busybox, > dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на > рынок со своей новой коробочкой, пихает в неё тот же линукс. Потому Проиграна. Попробуйте в этом busybox-е что-нибудь изменить. Выяснится что а) не так-то просто выяснить как и чем это вообще можно собрать б) оно требует патчей и проприетарных драйверов, за получение доступа к которым с этим китайцем придется судиться. в) оно все нихрена не документировано. Собственно нарушается свобода N1. The freedom to study how the program works, and change it so it does your computing as you wish. Более того, формально opensource продукты, такие как мозилла тоже в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный что на выяснение того как там что устроено и "change it so it does computing as you wish" уйдут годы. А за эти годы оно будет три раза переделано. Поэтому если ты не имеешь возможности тратить на работу над конкретным продуктом значительную часть своего времени, ты не сможешь "change it so it does your computing as you wish." А с тех пор как Мозилла стала подписывать расширения ключом, сертификат которого встроен в браузер, там все стало очень плохо со свободой N3. Чтобы распространять модифицированную версию своего расширения, я должен получить разрешение от чиновника из Mozilla foundation. Иначе оно не будет работать у тех, у кого не отключена проверка подписи под расширениями, что во-первых не во всех билдах отключаемо, во-вторых вообще-то security hole. Когда на выполнение какого-то действия требуется разрешительная виза от чиновника - это означает что свободы выполнять это действие нет. > > Экосистема живёт и развивается, это главный результат. А кто там Крепостническая Россия при Екатерине II тоже жила и развивалась, несмотря на отдельные мелкие шероховатости вроде восстания Пугачева. Золотой, говорят, век. Только вот свободы нихрена там не было. --
Re: systemd-networkd
On Thu, 25 Jul 2019 09:04:21 +0300 artiom wrote: > > Прописывать адрес статически. > > А, ну да, в IPv6 у каждого диапазон же. > Можно, конечно, особенно внутри сети. > Но сейчас всё настроено с IPv4 и автоматической выдачей адресов, не > хочется переделывать. > > > Здесь все не так. И война за свободу ПО, которую начал Столлман в > > середине 80-х - проиграна. > > Хм, надо будет почитать... > > > > Если ты не можешь написать софт, который компилируется любым GCC > > начиная с 4.6 и конччая 9.1, то ты не умеешь программировать. Если > > ты скачал откуда-то такой софт, сотри немедленно. Потому что его > > автор не умеет программировать, и отсутствие поддержки компилятора > > имеющейся у тебя версии, скорее всего не единственная и не главная > > его проблема. > > Ну это излишне сильное утверждение. > Я так думаю, вы на C++ не программируете. Правильно думаете. Я имею слишком большой опыт программирования на этому уродце, чтобы заниматься этим в конце второго десятилетия XXI века, когда есть Go и Rust. Код на C писать и поддерижвать - это да, приходится. За полвека его слишком много было написано, и хорошего. А код на C++ который существует ну слова доброго не стоит (ну скажем мозилла или qt). Опять же код на столь безумно устаревших языках интересен только если у нас есть огромная старая codebase (ну скажем mozilla или qt). А эта codebase все равно была написана по стандартам конца прошлого века. Так что продолжать в том же духе не столь уже сложно > (и почему gcc, > а не clang, MSVC, icc, ну и прочие?), а внятное донесение человеку Потому что мы в debian-russian. Были бы во freebsd-russian или macos-russian, шла бы речь про clang. Ну и понятно на какой платформе шла бы речь про MSVC. Лично мне clang под Debian стал интересен примерно год назад. Когда в postgres появился jit-компилятор условий на базе llvm. И вот тут-то оказалось что нужен И gcc, И clang. До этого я игрался периодически с clang-analyze но как-то особой полезности в этом инструменте не увидел. (особенно если у тебя есть 50Мб codebase четверть вековой давности, в которой оно находит этак тысяч пять false positives). > идеи. Причём так, чтобы это ещё и быстро работало, не падая в местах, > где кривые внешние данные или нехватка ресурсов. Вот совместимость с линейкой компиляторов очень способствует "чтобы оно не падало в местах, где...". Разные компиляторы вылавливают в качестве Warning-ов разные огрехи. И если все их гонять с -Werror и аналогами... Очень полезно для этой цели также тестироваться на разных процессорах. Вот, скажем если в тестовой ферме есть спарк, ни один не выровненный доступ к памяти не уйдет. > > Но вообще, если нужен свеженький компилятор в deuvian, в чем > > проблема его собрать самому в пакет (а то и мейнтейнером > > заделаться). > > Ну проблема в том, что это требует времени. Так борьба с systemd тоже требует времени. Вопрос в том, на что потратить время - на борьбу с поделиями поттерингов или на создание альтернативы им. Собственно проблема devuan как раз в том, что люди предпочитают бухтеть про то, какой плохой поттеринг, вместо того чтобы засучить рукава и сделать свое. Столлман 35 лет назад не бухтел про то какая плохая Symbolics, а писал патчи для LMI. > А обновление зависимостей, среди которых будет glibc, от которого > зависит всё, требует ещё больше времени. Не будет там glibc в зависимостях. Я же предлагаю собрать компилятор, а не готовый бинарник тянуть. Я что-то в своей практике не припомню случаев, чтобы софт такого класса, делаемый столь профессиональной командой, не собирался бы на системе 2-3 летней давности. Там проблемы обычно с системами более чем 15-летней давности бывают. > При этом, если моей задачей было что-то от сборки компилятора в > Devuan отличное, где-то на полпути я задумаюсь, что занимаюсь не тем, > чем требовалось. > > В случае, если у меня не будет выбора, я просто возьму Docker-образ с > новым компилятором. То есть вместо того, чтобы потратить время на то, чтобы решить проблему для всех, вы будете тратить время и ресурсы на то, чтобы воспользвоаться решением, сделанным за вам. > > Да я не плачусь, а указываю вам на вполне объективные причины, > которые переход на Devuan блокируют. Объективная причина тут одна - люди не хотят в этом участвовать. Вы не хотите, я не хочу (разок сунулся, остался неуслышанным и плюнул, все равно мне дистрибутивы с systemd поддерживать, так что знать его придется). > Ну и прекращение их выхода для старых версий библиотек (та же OpenSSL > в конце года выкидывает какую-то версию) и прекращение официальной > разработки и поддержки старых диалектов, типа Python 2, на котором в > Devuan много что есть, тоже не стимулирует к переходу. Подавляющее боьшинство крупных корпоративных заказчиков использует системы на базе RHEL 6 и 7. Которые обе гораздо старее Devuan. Так что не беспокойтесь по поводу прекращения поддержки софта менее чем десятилетней давности. > > в ответе человеку, который вынужден > >
Re: systemd-networkd
В Wed, 24 Jul 2019 21:20:24 +0300 artiom пишет: > > Можно прописать ему (в отдельном файлике для каждого интерфейса) > > что надо и что не надо от этого интерфейса требовать. > > > > Я же прописал для bond интерфейса, по крайней мере... > У вас MAC не прописаны, кстати. Я ж говорю - у меня конфигурация проще. Мне не надо менять mac интерфейсу. > > У меня, правда, более простая конфигурация - не бондинг, а бридж > > (куда потом включаются tun-интерфейсы qemu-шных виртуалок и veth > > lxc-шных контейнеров. Зато IPv4 у него статический (потому как > > серый) а ipv6 - динамический (потому как globally routable). > > В том и дело: не хочу статический, хочу DHCP, но всегда одинаковый. > > > > ipv6 - динамический (потому как globally routable). > > Если это сервер, как жить? Прописывать адрес статически. > > > > Потому что есть компания людей, которая считает, что Debian is not > > about choice. И это они как-то открытым текстом в debian-devel > > декларировали. > > Скажите, а мне одному кажется, что здесь что-то не так? Здесь все не так. И война за свободу ПО, которую начал Столлман в середине 80-х - проиграна. > Вот, например, идеологии Linux это не противоречит? Linux это ядро. Его идеологии совершенно пофиг как в юзерспейсе конфигурируются интерфейсы. Вот идеологии GNU-системы, описанной Столлманом в статье Opening The Software toolbox оно противоречит, и еще как. Но я же говорю - битва за свободу ПО проиграна. Замена Free Software на Open Source, которая казалась в конце 90-х замечательным тактическим ходом, позволяющим привлечь на сторону свободы ресурсы копораций, оказалась троянским конем. Она дала возмодность примазаться де Иказам и Поттерингам и постепенно захватить всю экосистему. > Debian, конечно, не Linux, однако ядро основное (а сейчас уже может и > единственное)... > > > > Увы, не поможет. Те, кто согласны с этим утверждением ушли на > > devuan. > > Который отстаёт на две версии от и так далеко не свежайшего Debian > (даже с учётом бэк-портов), что особенно актуально с выходом нового > компилятора (ага, "компильте в Docker или на CI", но мне это иногда > менее удобно). Если ты не можешь написать софт, который компилируется любым GCC начиная с 4.6 и конччая 9.1, то ты не умеешь программировать. Если ты скачал откуда-то такой софт, сотри немедленно. Потому что его автор не умеет программировать, и отсутствие поддержки компилятора имеющейся у тебя версии, скорее всего не единственная и не главная его проблема. Но вообще, если нужен свеженький компилятор в deuvian, в чем проблема его собрать самому в пакет (а то и мейнтейнером заделаться). Чай не Solaris 9 где собрать gcc так, чтобы им потом можно было собрать openssl было еще тем квестом, и требуемые для этого патчи к crt1.o почему-то gcc-шная команда принимать отказывалась. Впрочем, я про Solaris еще могу страшных сказок порассказывать, как там gcc 5.3 работает с 128-битными целыми, передаваемыми в функцию. Помнится мы зимой в pgsql-hackers на эту тему неделю ругались, пока наконец не написали более-менее приличный тест для configure. Вообще, конечно, плакаться по поводу старых компиляторов в devuan, которому без году неделя, в ответе человеку, который вынужден поддерживать софт для RHEL 6, SLES 11sp4 и МСВС-6.3 (про эльбрусы я вообще полмолчу)... > в -- Victor Wagner
Re: systemd-networkd
On Wed, 24 Jul 2019 14:03:34 +0300 Н. Артём wrote: > Есть система, которая имеет SSH сервер в initramfs (dropbear). > Интерфейсы связаны через бондинг в bond0, на котором этот сервер > работает. Роутер выдаёт бондинг интерфейсу через DHCP фиксированный > IP по MAC. > > Когда система загружается, сервер убивается, бондинг разрушается и > запускается "нормальная" сетевая подсистема, которая настраивает > бондинг и поднимает OpenSSH. MAC bond0 не изменяется, IP выдаётся тот > же. > > Когда был Stretch, не было проблем, всё работало. > Обновил на Buster - всё сломалось. > > Выяснилось, что недавно пришедший на замену работающей подсистеме, > networkd-systemd всё ломает. Если я не опускаю бондинг, его > расхреначивает, и он требует IP для каждого адаптера. Когда я C этим мне все-таки удалось побороться. Можно прописать ему (в отдельном файлике для каждого интерфейса) что надо и что не надо от этого интерфейса требовать. У меня, правда, более простая конфигурация - не бондинг, а бридж (куда потом включаются tun-интерфейсы qemu-шных виртуалок и veth lxc-шных контейнеров. Зато IPv4 у него статический (потому как серый) а ipv6 - динамический (потому как globally routable). Получилось примерно так: ==> /etc/systemd/network/br0.netdev <== [NetDev] Name=br0 Kind=bridge ==> /etc/systemd/network/br0.network <== [Match] Name=br0 [Network] Address=192.168.217.1/25 Gateway=192.168.217.63 Broadcast=192.168.217.128 DHCP=ipv6 DNS=127.0.0.1 ==> /etc/systemd/network/eth0.network <== [Match] Name=eth0 [Network] Bridge=br0 DHCP=no Вообще в *.network можно вписать Unmanaged=yes и тогда, по утверждению документации, systemd-networkd вообще не будет трогать этот интерфейс. И можно будет конфигурировать его через ipupdown (это же имеется в виду под старой подсистемой), не снося systemd-networkd. У меня, правда, сходу не получилось. Потому что я не ожидал от ini-style конфигурационного файла того, что пробелы вокруг знака равенства недопустимы. > Отсюда вопросы (реально не в курсе, так что может не в тему): > > - Что я делаю не так? > - Зачем поменяли работающее на это? > - Повинен в этом Леннар или это последователи? Потому что есть компания людей, которая считает, что Debian is not about choice. И это они как-то открытым текстом в debian-devel декларировали. > - Что их не устраивало в resolv.conf? > - Стоит ли намекнуть маинтайнерам дистрибутива на то, что это > какая-то сильно непрозрачная, кривая и неочевидная в настройке херня? Увы, не поможет. Те, кто согласны с этим утверждением ушли на devuan. --
Re: как уменьшить объем обновлений?
В Fri, 12 Jul 2019 12:09:45 +0300 ivan kuznetsov пишет: > нужна конкретная информация об этом так как вне городов и пригородов > скорость может падать до нуля, и спутниковое оборудование дорого (или > рыбалка?). правильно я понимаю что дельты сурсов, рсинк и программа > пар могут помочь? не пора ли для этого организовать любительскую или > полноценную радиостанцию? тогда можно будет слать обновления на > приемники у пользователей и администраторов. пусть кто-нибудь > разберется с этим и напишет статью. заодно -- как обновлять с > наименьшим размером данных антивирусную базу? обычное обновление -- > целиком? Самый надежный способ уменьшить объем обновлений - это не ставить лишних программ. В частности антивирусов. Идея слать обновления бродкастом по радио - интересная, но малоперспективная. Насколько я слышал, идея гнать траффик по радио рассматривалась в свое время фидошниками, и пришли к выводу что для обеспечения достаточной полосы пропускания требуется не менее чем метровые волны (на которых в те времена вещало телевидение). Но метровые волны (как и более короткие) распространяются только в пределах прямой видимости. Так что если и удастся каким-то образом проникнуть с этим каналом на Останкинскую башню, будет покрыта только территория Московской области. А она неплохо покрыта и сотовыми сетями. Там же где проблемы со связью, таких высоких башен нет, поэтому радиостанцию придется организовывать как минимум в каждом втором райцентре. Вот где раньше были телевизионные ретрансляторы, так на каждом из них и организовывать.
Re: systemd inittab
On Fri, 24 May 2019 11:25:00 +0300 sergio wrote: > On 24/05/2019 09:51, Victor Wagner wrote: > > > Ну можно на мой vws посмотреть. Вроде все перечисленное он делает. > > > > https://www.wagner.pp.ru/fossil/vws > > SPICE ради serial console? Это клиент нужен, что бы ходить в него, А как иначе работать с консолью, ну скажем Windows server? SPICE хорош тем что лучше всех других возможных вариантов интегрирует окно виртуальной машины в десктоп. Там и мышь не захватывается в окне, в отличие от sdl-интерфейса qemu, и clipboard общий. Все равно же работаешь на своей рабочей станции в какой-нибудь графической среде. Потому что браузер нужен, читалка pdf-ов нужна. > порты ещё прокидывать. Нет. Плохо объяснил, я хочу serial console > через ssh, как в libvirt (который её через /dev/pts отдаёт) Ну, порты прокидывать - это у меня бродит в голове такая мысль - сделать в vws прозрачную поддержку ssh. Чтобы можно было указать имя виртуалки в виде "имя хоста:имя виртуалки" и оно бы само разобралось как что запускать (при условии правильно заполненных authorized_keys). Вообще я не против включить и поддержку serial console. Только мне она обычно как-то не очень нужна, поэтому сам скорее всего делать не возьмусь. Но патч приму. --
Re: systemd inittab
On Fri, 24 May 2019 04:49:17 +0300 sergio wrote: > On 23/05/2019 10:26, Victor Wagner wrote: > > > > Написать unit-файл, который будет это делать. И кстати и respawn > > средствами systemd организовать можно будет. > > Написал, как дебажить? Я бы использовал для запуска процессов на свободном терминале программу openvt. Она и переменные среды выставит какие надо, и настройки терминала. Судя по тому, что написано ниже, терминал настраивать tty_clock и сам умеет. Но, будучи честной программой на ncurses, нуждается в переменной TERM указывающей, какой тип терминала. Если мы видим, что процесс убит сигналом, надо в первую очередь разрешить ему оставлять core dump. Добавив для этого в unit-файл строчку LimitCORE=infinity, ну и позаботившись о том, чтобы текущая директория процесса была доступна ему на запись (либо чтобы ядро знало, что надо core в какое-то другое место писать). > > # cat /etc/systemd/system/tty_clock.service > [Unit] > Description=tty-clock > > [Service] > Environment="LANG=ru_RU.UTF-8 TERM=linux" > ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f '%%F %%A' -T /dev/tty10 > ExecStartPost=chvt 10 > Restart=on-failure > > [Install] > WantedBy=default.target > > > # systemctl status tty_clock.service > ● tty_clock.service - tty-clock >Loaded: loaded (/etc/systemd/system/tty_clock.service; enabled; > vendor preset: enabled) Active: failed (Result: signal) since Fri > 2019-05-24 04:41:08 MSK; 5s ago Process: 13038 > ExecStart=/usr/bin/tty-clock -x -s -c -C 7 -f %F %A -T /dev/tty10 > (code=killed, signal=ABRT) Process: 13039 ExecStartPost=/bin/chvt 10 > (code=exited, status=0/SUCCESS) Main PID: 13038 (code=killed, > signal=ABRT) > > systemd[1]: tty_clock.service: Service RestartSec=100ms expired, > scheduling restart. systemd[1]: tty_clock.service: Scheduled restart > job, restart counter is at 5. systemd[1]: Stopped tty-clock. > systemd[1]: tty_clock.service: Start request repeated too quickly. > systemd[1]: tty_clock.service: Failed with result 'signal'. > systemd[1]: Failed to start tty-clock. > systemd[1]: tty_clock.service: Start request repeated too quickly. > systemd[1]: tty_clock.service: Failed with result 'signal'. > systemd[1]: Failed to start tty-clock. > > > > > Так работает: > > [Service] > ExecStart=/usr/local/bin/tty_clock > > > # cat /usr/local/bin/tty_clock > #!/bin/sh > > LANG=ru_RU.UTF-8 TERM=linux /usr/bin/tty-clock -x -s -c -C 7 -f '%F > %A' -T /dev/tty10 (4:47:08)[root@boo:system]# > >
Re: systemd inittab
On Fri, 24 May 2019 04:20:39 +0300 sergio wrote: > On 23/05/2019 10:26, Victor Wagner wrote: > > > Может поискать что другое для управления kvm-виртуалками. > > Я пробовал, но не нашёл. > > > Я после некоторой возни с libvirt плюнул и вообще свой скрипт на > > питоне написал. > > Я пробовал, libvirt победил. Требования просты: > > 1. Запуск при загрузке хоста. > 2. Остановка при перезагрузке/выключении хоста. > 3. Консоль. Ну можно на мой vws посмотреть. Вроде все перечисленное он делает. https://www.wagner.pp.ru/fossil/vws
Re: systemd inittab
On Wed, 22 May 2019 23:43:45 +0300 sergio wrote: > > Был хост, в /etc/inittab которого было написано: > > 10:2345:respawn:/usr/local/bin/tty_clock > > > На хосте стоит libvirt-daemon-system для запуска kvm виртуалок, > который требует systemd, и для которого стоял systemd-shim пока там > был stretch. Я обновил его до buster, systemd-shim на нём нет и > systemd там в полный рост. Может поискать что другое для управления kvm-виртуалками. Я после некоторой возни с libvirt плюнул и вообще свой скрипт на питоне написал. > 1. почему меня после загрузки переключает на 10 vt? Видимо потому, что переключение был прописно не в inittab а где-то еще. > 2. как запустить tty_clock на vt 10? Написать unit-файл, который будет это делать. И кстати и respawn средствами systemd организовать можно будет. > >
Re: крик души :)
On Mon, 20 May 2019 19:42:10 +0100 Stanislav Maslovski wrote: > Доброго времени суток, > > Меня упорно не покидает ощущение, что с каждым новым релизом > качество софта в Debian деградирует. > > Что с этим делать, граждане? Так как это, похоже, нынче глобальный > тренд... Есть места где кучкуются те, кто против тренда. Может Devuan https://devuan.org/ поможет?
Откуда в Debian берется /opt?
Коллеги Тут обнаружил удивительную вещь - при установке Debian создается в корне каталог /opt, как это по FHS и положено. Но этот каталог не принадлежит ни одному пакету. Вот /bin, /lib, /run и /tmp - относятся к пакету base-files. А /opt возникает ниоткуда. Соответственно, если делаешь пакет, который ставится в /opt, он становится единственным его хозяином и при удалении этого пакета удаляется и сам /opt. На stackoverflow рекомендуют из postinst-скрипта своего пакета создать в opt какой-нибудь пустой файл-флаг, чтобы каталог после удаления пакета остался пустым и не был удален. Но это как-то криво. Интересно, на какой пакет стоит зафайлить баг. --
Re: firefox + suspend to disk
On Fri, 29 Mar 2019 13:10:52 +0300 Dmitry Alexandrov <321...@gmail.com> wrote: > > > Например, вместо множества вкладок со статусом "прочитать позже", > > найти способ хранения ссылок/цитат вне браузера > > Да чего уж там мелочиться: страниц целиком. Это очень правильно. А то страницы из интернета имеют привычку пропадать. Или менять содержимое в соответствии с колебаниями линии партии. (понять бы еще когда Республиканской партии США, когда Лейбористкой Великобритании, а когда Трудовой Северной Кореи). > > xul-ext-zotero + zotero-standalone, у меня Emacs + org-mode + > > org-capture. > > И искать костыли не надо — файловая система. zotero кстати, как я посмотрел эту задачу как раз умеет решать. И хранит все на файловой системе + частично в sqlite. Правда, мне пришлось довольно долго читать zotero.org, прежде чем я сумел избавиться от предубеждения что это yet another сервис впаривающий свой аккаунт и желающий читать вашу персональную информацию, и понял, что это нормальная софтина, которую можно синхронизировать через произвольный webdav (надо, кстати через свой попробовать - у меня там digest authentication, многие современные софтины этого пугаются) или вообще по файловой системе любой внешней тулзой. -- pgpy1vfXCpwn9.pgp Description: OpenPGP digital signature
Re: ЭЦП и RuToken
On Wed, 27 Mar 2019 14:30:00 +0300 Artem Chuprina wrote: > Там с большими шансами еще прослойка в виде КриптоПро CSP. Которая как > раз может как-то по-разному вести себя в случае виртуальной и > физической винды. Она платная, и там может быть защита. Что-то я не припомню чтобы самому КриптоПро CSP (без PCSC-дополнений) виртуальная машина как-то мешала. Я не говорю про тесты на совместимость с этим CSP, которые мы с тобой вместе делали некогда, но во время работы в более другой криптографической фирме, мы разворачивали в VMWare ESX целые криптографические сети на базе этого CSP и прекрасно отлаживались. --
Re: ЭЦП и RuToken
On Wed, 27 Mar 2019 14:14:24 +0300 Eugene Berdnikov wrote: ... > > Вот идея, что оно под виртуальной виндой встало криво и просят > > физическую, наводит на мысль, что то ли там стало все намного > > хуже, > > Стало хуже по сравнению с чем? Хотелось бы услышать от спецов по Чем было десять лет назад. > виртуализации, какие гипервизоры сегодня дают полноценный проброс > usb-устройств с физической на виртуальную машину, даже если Лично меня все устраивало даже с KVM и пробросом USB через SPICE-протокол. Правда, токен был Алладиновский, к котоорому PKCS10-драйвер под linux был, и мне его даже удалось заставить работать под Debian (исходно он был под редхат). Но мне этот токен нужен был для доступа к VPN, использоваваший протокол SSTP. Причем авторизация по сертификату там требовалась дважды - при установлении самого SSTP-соединения и при запуске поверх него PPP-сессии. И если сам sstp-клиент под Linux я сумел попатчить так, чтобы он использовал токен, то с PPPD - не получилось. Поэтому пришлось поднимать VPN через виртуальную винду, благо для винды SSTP -родной протокол. А на сайте у рутокена прямым текстом пишут, что проброс в виртуальные машины из-под линукс-хоста поддерживается. Правда, не факт что именно как USB-девайса, а не как смарт-карты. Вот с пробросом USB-подключения к смартфону Sony, чтобы с ним потом заработал проприетарный софт от самой Sony были сложности. Дело в том что там предлагалось по ходу дела подключать-отключать телефон от компьютера и организовать дело так, чтобы при втыкании выключенного телефона он сразу пробрасывался - у меня не получилось.
Re: ЭЦП и RuToken
On Wed, 27 Mar 2019 11:35:53 +0300 Artem Chuprina wrote: > Grigory Fateyev -> debian-russian@lists.debian.org @ Wed, 27 Mar > 2019 10:52:16 +0300: > > > А есть вероятность запустить всё это хозяйство на Debian stretch? > > Выпустил сертификат в виртуальной винде, оно встало криво, просят > > физическую машину с виндой, а у меня таких просто нет. Вот дуиаю, > > может на дебе проще будет? > > Подозреваю, что нет. Даже если сам рутокен заведется (хотя в этом есть > большие сомнения, если он даже виртуальную винду не осилил), то тот > софт, для подписи в котором он вообще нужен, наверняка еще более крив > и виндоус-онли. Погоди, погоди, мы ж с тобой десять лет назад вместе делали систему для ДНС-регистраторов как раз на рутокенах. И оно даже под Solaris-ом работало, не то что под линуксами. То есть какие-то PCSC-драйвера для Linux у Актив-а есть. Насколько я помню, тогда была совместимость с openct. Как сейчас - не знаю. Но тогда у меня сложилось впечатление об Актив, как о наиболее open source friendly производителе криптотокенов. Сейчас я у них на сайте вижу среди партнеров почти всех производителей российских сертифицированных дистрибутивов Linux - Astra, AltLinux, RosaLabs, Red Soft, МСВСфера. --
Re: Генерация pool-based репозиториев
В Mon, 04 Mar 2019 23:10:10 +0300 Artem Chuprina пишет: > > Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом > _почти_ атомарная пара rename либо перевешивание симлинка (тоже > _почти_ атомарное). Второе лучше (см. ниже). Вот для этого у rsync есть --link-dest. Которым уже довольно давно научился пользоваться rsnapshot. Поэтому создавать копию можно прямо тем же rsync-ом в процессе. Правда, по-моему авторы всяких дебмирроров об этом пока не задумывались. > > > Отдельное развлечение случается когда у тебя параллельно работает > > десяток jenkins-овских заданий, собирающих разные пакеты, зависящие > > друг от друга. Может запросто получиться так, что задание 1 сделало > > apt-get update, потом задание 2 выложило новую версию своего > > пакета и перергенерировало packages, а потом задание 1 захотело > > этот пакет поставить, потому что он у него Build-Depends. > > В таком раскладе либо задание 2 не должно удалять старую версию пакета > (а делать это должен кто-то третий в конце всего прогона или еще по > какому-то критерию "старая версия больше никому не нужна"), либо у > тебя неконсистентность прямо в постановке задачи. > > То, что задание 2 перегенерировало packages, само по себе для задания > 1, которое уже сделало apt-get update, по барабану. Важно, чтобы пакет > оставался. В принципе, конечно да. Если бы поднимать версию пакета при каждом билде, можно было бы действовать и так. Хотя сформулировать критерий "эта версия пакета больше никому не нужна" крайне нетривиально. Но в процессе отладки пакета его можно пересобрать и десять, и двадцать раз, и в распределенной системе сборки он каждый раз должен попадать во внутренний репозиторий, доступный для других заданий. Поэтому у меня сейчас во внутреннем репозитории допустима замена пакета без изменения его версии. А вот тут уже неатоммарность пары apt-get update - apt-get install вылезает в полный рост. > Другое дело, что race condition вида "у задания 1 прямо в процессе > apt-get update могли оказаться Release и Packages разных версий > репозитория" все равно остается. > > Чтобы его не было, см. выше про симлинк. Перед apt-get update делается > readlink, прочитанное имя пишется в sources.list, и уже с этим readlink по http? > отрезолвленным именем, где заведомо консистентный репозиторий, который > уже никогда не поменяется, можно работать. Это для отрелизенных пакетов я могу себе позволить хранить заведомо-консистентные репозитории на каждый момент времени. Если это делать по схеме rsnapshot-а, т.е. каждый пакет хранить один раз и держать на него десяток хардлинков из разных снапшотов. А если хранить репозитории вечно для всех промежуточных билдов, успевших собрать хотя бы один пакет (а ведь туда для консистентности придется копировать все остальные пакеты из старого репозитория) никакого storage не хватит. У меня сейчас логи билдов всего лишь за год 700 гигов занимают. А репозитории имеют объем примерно на порядок -два больше, чем логи. > > Прикрутить туда осмысленную систему exclusive и shared блокировок > > при условии того, что задания крутятся на куче разных машин и в > > репозиторий ходят apt-ом весьма нетривиально. > > Любая система с блокировками содержит race condition :) Один мутекс > еще нет, а любая система уже да. Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди, способные грамотно спроектировать систему блокировок - найдутся. В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы это один репозиторий, все убунты - другой, а каждая астра - отдельный) тут хватит. Основная проблема - гарантировать то, что при любых сбоях сборочного задания, в том числе и при ошибке установки пакетов-зависимостей, блокировка будет снята. Вообще говоря, для практических целей можно было бы обойтись троекратной попыткой повтора пары apt-get update/apt-get install с задержкой. Вероятность того что задание при этом обломится и потребует ручного перезапуска упадет до практически приемлемой. -- Victor Wagner
Re: Генерация pool-based репозиториев
On Sun, 3 Mar 2019 15:32:47 +0300
Eugene Berdnikov wrote:
> On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
> Возможно, конкретно для reprepro проблемы нет, но в общем случае
> лучше делать репозиторий локальным, а с облаком синхронизовать после
> успешного завершения всех локальных транзакций, т.е. когда всё уже в
> файлах и в консистентном виде. Сохранить целостность при передаче в
> облако несложно, но это так лишь потому, что технология отработана --
> авторы rsync/etc тщательно продумали все возможные сценарии сбоев, и
> мы этим пользуемся.
C сохранением консистентности конкретно у репозиториев есть
определенные проблемы.
Я давно не смотрел на современные средства мирроринга репозиториев, но
когда мне это было надо, при мирроре возникала
проблема, что целевой миррор может оказаться неконсистентным пока
работа миррорящего скрипта не закончена.
Чтобы миррор всегда был консистентным, необходимо действовать в
следующей последовательности:
1. Сначала скачать все новые пакеты
2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
единомоментно атоммарной операцией из заменить.
3. Удалить более ненужные пакеты.
А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
файлы, а потом уже копирует новые. Ну и о том, что Release содержит
контрольную сумму Packages и менять их нужно одновременно - тоже не в
курсе.
Отдельное развлечение случается когда у тебя параллельно работает
десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
друг от друга. Может запросто получиться так, что задание 1 сделало
apt-get update, потом задание 2 выложило новую версию своего пакета
и перергенерировало packages, а потом задание 1 захотело этот пакет
поставить, потому что он у него Build-Depends.
Прикрутить туда осмысленную систему exclusive и shared блокировок при
условии того, что задания крутятся на куче разных машин и в репозиторий
ходят apt-ом весьма нетривиально.
--
Re: Генерация pool-based репозиториев
В Sun, 3 Mar 2019 14:19:37 +0300 Aleksandr Sytar пишет: > сб, 2 мар. 2019 г. в 15:33, Victor Wagner : > > > В Sat, 2 Mar 2019 11:52:55 +0300 > > Igor Savluk пишет: > > > > > > База данных - это не единственное средство организовать дурацкий > > поиск. Вообще говоря, в deb-файле содержится более чем достаточно > > информации, чтобы сгенерировать Packages file entry. > > > > > База данных, наверно едиственный способ сделать это предсказуемо > быстро за ограниченное время. Сканирование deb-пакетов всегда будет > иметь сложность не менее O(n). Поэтому в общем случае так никто не > делает. При разумно-реалистичных N зачастую выгоднее сделать n! но при маленьком О, чем бороться за O(n) или O(log n) ценой увеличения O. Как правило, у людей, которые делают репозитории своих программ под Debian (каковой сценарий явно имели в виду авторы aptly и reprepro) имеется довольно небольшое количество пакетов. Поэтому нужно стремиться не ускорять генерацию файла Packages, а упрощать обработку ошибок при выкладывании. Типичная ошибки например, "в дженкинсе собралось не то и не так" или "при подъеме апстрим-версии забыли сбросить в единичку версию пакета". Или "пакет оказался настолько глюкавым, что мы его сейчас распубликуем обратно до следующего релиза". Но вот о чем совершенно не подумали авторы ни одной из рассмотренных утилит, так это то, что Debian не единственный на свете дистрибутив. Почему-то до сих пор мне попадались ровно два варианта: Либо мы не обращаем внимания на существование в природе чего либо, кроме нашего любимого дистрибутива, либо мы начинаем изобретать свой собственный формат пакетов, что приводит к невозможности подтягивания по зависимостям софта из пакетов, и самостоятельного пакетирования perl, python, openssl et cetera et cetera. -- Victor Wagner
Re: Генерация pool-based репозиториев
В Sat, 2 Mar 2019 11:52:55 +0300 Igor Savluk пишет: > On 26/02/2019 22.57, Victor Wagner wrote: > > В Tue, 26 Feb 2019 11:16:38 -0500 > > Tim Sattarov пишет: > > > >> On 2/26/19 4:24 AM, Victor Wagner wrote: > >>> Коллеги, > >>> > >>> А чем в наше время можно генерировать pool-based репозитории, > >>> КРОМЕ reprepro? > >> я использую для этого aptly > > > > Штука еще более высокоуровневая и навороченная, чем reprepro. > > Обладает тем же нредостатком - хочет испольовать какую-то левую > > базу данных. > > > Для твоих запросов тебе всеравно прийдется использовать утилиту с бд. База данных - это не единственное средство организовать дурацкий поиск. Вообще говоря, в deb-файле содержится более чем достаточно информации, чтобы сгенерировать Packages file entry. Я на самом деле уже выяснил, что apt-ftparchive generate при правильно описанном конфиге мою задачу решает. Ну или почти решает. Во всяком случае текстового filelist хватит для того, чтобы заменить базу данных. Поскольку единственная информация, которая не извлекается однозначно из самого пакета - это к какому suite он относится (и это сделано намеренно, потому что пакеты мигрируют из unstable в testing, testing превращается в stable, a stable в oldstable, а некоторые пакеты по-моему не пересобираются релиза по четыре). > Без них нет утилит. Можеш поставить dak там вообще postgresql. В Только у криворуких идиотов. > документации я так понял ты про архитектуру не читал и зачем эти > утилиты юзают бд ты смотрел? Потому что это вообще традиция современной IT. Нужно сайт, который обновляется через веб-интерфейс - лепят туда базу данных, нужно хранить закладки в браузере - лепят туда sqlite. Более того, пользоваться базами данных эти криворукие идиоты тоже не умеют, о referential integrity, например, вообще обычно не слышали и чем 2 НФ от 4 отличаются не в курсе. Использование dak с клиент-серверной БД для полного дебиановского архива еще можно как-то оправдать - там десятки тысяч пакетов. Но мне-то нужно от силы пара десятков пакетов, зато под 30 дистрибутивов, далеко не все из которых Debian и Ubuntu (отдельная призовая игра - это astra, которая использует deb-пакеты и apt, но при этом у нее codename означает вовсе не версию и для разных codename может быть разная политика версионирования). Поэтому если уж заводить базу данных, то ее надо заводить для всего этого хозяйства. а не отдельно для Debian, отдельно для Ubuntu. отдельно для RHEL. -- Victor Wagner
Re: Генерация pool-based репозиториев
В Tue, 26 Feb 2019 11:16:38 -0500
Tim Sattarov пишет:
> On 2/26/19 4:24 AM, Victor Wagner wrote:
> > Коллеги,
> >
> > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> > reprepro?
> я использую для этого aptly
>
Снапшоты в aptly, конечно, замечательная штука. Но оно же не умеет ни
yum, ни apt-rpm, а использовать для одних дистрибутивов один механизм
снапшотов а для других - другой крайне неудобно.
--
Victor Wagner
Re: Генерация pool-based репозиториев
В Tue, 26 Feb 2019 11:16:38 -0500
Tim Sattarov пишет:
> On 2/26/19 4:24 AM, Victor Wagner wrote:
> > Коллеги,
> >
> > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> > reprepro?
> я использую для этого aptly
Штука еще более высокоуровневая и навороченная, чем reprepro.
Обладает тем же нредостатком - хочет испольовать какую-то левую базу
данных.
У того хотя бы нет глобального (уровня юзера) конфигурационного
файла и каждый репозиторий, в каком бы месте файловой системы он не
находился, абсолютно незевисим.
Ну и добавлять пакеты в репозиторий можно не только на основании файлов
changes, но и отдельными .deb и .dsc. А здесь я этого как-то не увидел.
Я помнится, в reprepro .changes-файлами намучался, когда мне
потребовалось поддерживать всего-то три архитектуры.
--
Victor Wagner
Генерация pool-based репозиториев
Коллеги,
А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
reprepro?
reprepro не нравится тем, что разводит очень много файлов конфигурации
и баз данных, которые в выходной репозиторий попадать не должны.
Ну и манипулировать приходится ими и а не пакетами на файловой системе.
Хотелось бы чего-нибудь более простого и низкоуровневого, чему
указал списко пакетов, а оно и сгенерило для них packages, вроде
dpkg-scanpackages, но из докуменации и на dpkg-scanpackages, и на
apt-ftparchive я не смог вычитать как ими работать с pool-based
репозиториями, а не с репозиториями старого образца, где пакеты лежат
непосредственно в dists/${codename}/main/binary-${arch}.
(да, естественно, в pool-е могут лежать пакеты для нескольких
дистрибутивов, и правильный список файлов я формирую сам).
--
Re: Правка xkb/rules без dpkg-divert(1)
On Mon, 18 Feb 2019 16:39:17 +0300 sergio wrote: > Я чего не могу понять. Вот есть xkb весь из себя такой настраиваемый. > А как эти настройки применить --- а никак, пиши, дорогой > пользователь, скрипты. А это потому что роботы уже поработили людей, и об удобстве пользователей никто не думает, думают об удобстве железяк. То есть простейшая идея, что на машине может быть два пользователя и им нужны разные настройки клавиатуры, в голову авторам этого добра не пришла. Зато идея того, что может быть две клавиатуры, которым не годятся одинаковые настройки - пришла.
Re: два вопроса по иксам
В Mon, 11 Feb 2019 23:05:20 +0300
Alex Kicelew пишет:
> 2) Правильно я понимаю, что на нынешнем витке развития иксы не умеют
> назначать разные DPI на два подключенных монитора? И если к ноуту со
Насколько я понимаю, можно, если не пытаться обеспечить прозрачный
перенос окон с одного монитора на другой, а назначить им разный display
или хотя бы screen.
> встроенным 2560x1440 подключить внешний монитор с 1024x768, то
> придется мириться, что на внешнем будут те же 170, что и на
> встроенном (иначе я не разгляжу мелких буковок на встроенном)? Или
> все-таки есть какой-то способ, которого я не смог найти
> самостоятельно, поставить на них разные DPI?
>
--
Victor Wagner
Re: mail dups
On Fri, 8 Feb 2019 15:26:48 +0300 "Andrey Jr. Melnikov" wrote: > Eugene Berdnikov wrote: > В roundcube и thunderbird есть плагин. Пользователи mutt могут себе > позволить написать и файлик. Счастливые обладатели оутглюков и У claws-mail тоже есть плагин. У prayer web-mail поддержка sieve тоже есть (я использую именно его, поскольку он без php и javascript). А пользователям mutt кроме текстового редактора еще и sieve-connect понадобится, чтобы потом этот файлик на сервер загрузить. Поскольку по imap и smtp mutt разговаривать умеет, так что работать с почтовыми серверами. где у пользователя нет шелла, но есть sieve - может. --
Re: mail dups
On Fri, 08 Feb 2019 12:54:33 +0300 Artem Chuprina wrote: > А товарищи, способные настроить то, что более удобно им, в итоге один > фиг предпочтут procmail. Он, конечно, имеет корявый синтаксис, но зато > полноценный по функциональности, а урезать функциональность самому > себе смысла нет. Во-первых, урезать функциональность того что работает unanttended по событиям, да еще и черт-те-где в датацентре, а не у тебя под столом, смысл есть. Во-вторых, как только мы отходим от традиционной парадигмы юникса, когда почта приходит на многопользовательскую рабочую машину, то procmail, который требует дать каждому владельцу почтового ящика, включая кошку и двух собак, полноценный шелл на почтовом сервере, сразу становится несколько неудобным, в отличие от sieve который менеджится самим почтовым сервером, требует не больше прав, чем LDA и управляется через тот же почтовый клиент и тот же dovecot (правда, по соседнему порту). В общем, я отказался от procmail в пользу sieve когда перенес почтовый сервер с рабочей машины на роутер BananaPI R1. И когда он потом вообще на хостинговую виртуалку уехал не пожалел об этом решении. --
Re: gnome $LANG
On Wed, 30 Jan 2019 17:34:03 +0300
Alexander Danilov wrote:
> > Причем еще, как правило, по умолчанию пытается работать с правами
> > пользователя и ставить исполняемый код пользователю в ${HOME}.
> >
> > А вот за это по-моему надо бить канделябрами.
> >
>
> Вот тут поподробнее: за что и в каком количестве?
user-writable исполняемый файл - среда для размножения вирусов и
троянов. Поэтому user-writable исполняемые файлы должны быть допустимы
только на машине разработчика, который свой код знает в лицо.
А все, что берется извне, должно ставиться в с правами root:root 0755
(0644, если это библиотека) и процесс установки должен быть явным
образом выделен (я в общем даже судо без пароля стараюсь держать только
на специально выделенных тестовых машинах. А там где я запускаю браузер
- только с паролем).
Re: gnome $LANG
On Wed, 30 Jan 2019 17:06:14 +0300 (MSK)
yuri.nefe...@gmail.com wrote:
>Вопрос о программных пакетах как бы повис.
Потому что я не понял, какие именно пакеты имеются в виду.
>Скажем TeX Live. С одной стороны нужный пакет, но сколько
>труда было затрачено, что бы его нормально вписать в дебиан.
>А вот другой пакет - Root. Так ведь до конца и не включили.
>Потому как типичные спагетти из трудно отслеживаемых
>зависимостей, библиотек и программ разных версий. И развивается
>слишком быстро. Так что пакеты, IMHO, зло. Но с ним можно жить.
> Ю.
>
Проблема в том, что сейчас любой крупный программный пакет норовит
включить в себя собственный пакетный менеджер и предоставить
собственные пакеты расширений. У любого языка программирования сейчас
что-то такое есть - CPAN, pip, cargo, cabal, maven и т.д. Даже у emacs-а
свой пакетный менеджер завелся.
Причем еще, как правило, по умолчанию пытается работать с правами
пользователя и ставить исполняемый код пользователю в ${HOME}.
А вот за это по-моему надо бить канделябрами.
--
>p.s. Хорошо воспитанный пользователь может пользоваться всем!
Re: gnome $LANG
On Wed, 30 Jan 2019 15:50:05 +0300 Artem Chuprina wrote: > Бывают задачи, которые надо решать от раза в полгода до раза в два > года. Инструменты их решения не должны быть такими, чтобы их интерфейс > надо было отдельно изучать. Потому что за полгода он забывается, и > изучать его надо заново. Интерфейс для таких задач должен быть самодокументирован. Поскольку за полгода забудется не только какие кнопки нажимать, но и на какие грабли надо не наступить. К сожалению, писать такие интерфейсы очень сложно. Потому что человек, который постоянно работает с такой задачей (и, соответственно знает ее достаточно хорошо, чтобы написать программу), считает совершенно неочевидные causal user'у вещи самоочевидными. --
Re: gnome $LANG
On Wed, 30 Jan 2019 15:45:23 +0300 Eugene Berdnikov wrote: > On Wed, Jan 30, 2019 at 03:27:16PM +0300, Victor Wagner wrote: > > > > Ставить надо (что себе, что другим) набор разных и не связанных > > > > между собой программ. Идея DE порочна сама по себе. > > > > > > Чем идея DE порочна? (давненько здесь флейма не было) > > > > Потому что интерфейс не должен быть единообразным. Для каждой задачи > > есть свои, наиболее подходящие ей интерфейсные решения. Да, их > > придется выучить вместе с предметной областью. > > То есть то, что я переношу копи-пастом текст между различными > иксовыми приложениями -- это неправильно? Нужен свой буфер обмена > и своя магия клавиш для каждой пары приложений, и талмуд впридачу > с описанием интерфейса для изучения "предметной области"? Конечно неправильно. Это ж не винда. В X-ах надо через primary selection копировать средней кнопкой, а не через буфер. Гораздо удобнее. На одно действие меньше выделил и воткнул куда надо, а не выделил, скопировал в буфер, скопировал из буфера. Но вообще обеспечение межпроцессного взаимодейсвтия это не функция DE. Это функция либо ядра операционой системы, либо X-сервера. То есть вещей, лежащих на 1-2 уровня абстракции ниже, чем DE. --
Re: gnome $LANG
On Wed, 30 Jan 2019 14:56:46 +0300 Eugene Berdnikov wrote: > On Wed, Jan 30, 2019 at 02:26:52PM +0300, Victor Wagner wrote: > > On Wed, 30 Jan 2019 14:15:27 +0300 > > sergio wrote: > > > > > > Вопрос в том, что ставить пользователю, если он сам ничего не > > > захотел? Что лучше всего подходит для абстрактного > > > виндоусъюзера? > > > > Ставить надо (что себе, что другим) набор разных и не связанных > > между собой программ. Идея DE порочна сама по себе. > > Чем идея DE порочна? (давненько здесь флейма не было) Потому что интерфейс не должен быть единообразным. Для каждой задачи есть свои, наиболее подходящие ей интерфейсные решения. Да, их придется выучить вместе с предметной областью. Но для решения задачи нужно выбирать лучший инструмент из всех доступных. А не наиболее подходящий по цвету к обоям на десктопе. --
Re: gnome $LANG
On Wed, 30 Jan 2019 14:15:27 +0300 sergio wrote: > On 29/01/2019 23:47, Victor Wagner wrote: > > > Гном ... писали фиолетовые осьминоги > > Я от него тоже не в восторге, но в конкретном случае сам пользователь > захотел именно гном. > > Вопрос в том, что ставить пользователю, если он сам ничего не > захотел? Что лучше всего подходит для абстрактного виндоусъюзера? Ставить надо (что себе, что другим) набор разных и не связанных между собой программ. Идея DE порочна сама по себе. Поэтому я ставлю обычно lxde (там вполне достаточно апплетов для мелких операций, но нет своего офиса, своего браузера и проч), spacefm в качестве файлового менеджера, файрфокс (ну можно и chromium), libreoffice, gimp и evince. --
Re: gnome $LANG
В Tue, 29 Jan 2019 23:35:48 +0300
sergio пишет:
>
> А чем так уникален гном, что ему пользовательское окружение подавай?
> А почему в остальных wm/dm локаль из меню настраивается?
Гном уникален тем, что его писали фиолетовые осьминоги, которые убеждены
что linux is not about choice, и нужно как можно жестче ограничить
пользователя в возможностях настройки.
Это у них даже в HIG написано.
--
Victor Wagner
Re: single-user-mode no root password
В Sun, 13 Jan 2019 09:20:43 +0300 sergio пишет: > On 13/01/2019 09:17, Victor Wagner wrote: > > > Тогда надо загрузиться с init=/bin/sh (или в нормальный режим, если > > он работоспособен) > > Он работоспособен. > > > > найти то место, где запускается sulogin, > > и в этом месте дописать ему --force. > > В этом и вопрос. > Из исходного поста было не совсем очевидно, что имеется работоспособная система, и надо ее настроить так, чтобы можно было попасть в single user mode. > > > в systemd-шных системах нужно завести > > Так, а не в systemd-шных? > В случае SysV init - редактировать /etc/inittab За всякие upstart-ы не скажу, никогда ими не пользовался. -- Victor Wagner
Re: single-user-mode no root password
В Sun, 13 Jan 2019 01:57:22 +0300 sergio пишет: > On 13/01/2019 01:46, Коля Гурьев wrote: > > >> Желающие предложить мне поствить пароль через init=/bin/bash идут > >> мимо этого треда. > > > > А что не так может быть с этим параметром ядра? > > То, что у меня другая цель, не пароль руту задать, а в single-user > попасть. > Тогда надо загрузиться с init=/bin/sh (или в нормальный режим, если он работоспособен), найти то место, где запускается sulogin, и в этом месте дописать ему --force. Вернее, в systemd-шных системах нужно завести /etc/systemd/system/rescue.service куда написать inlcude=/lib/systemd/system/rescue.service и команду ExecStart в которой по сравнению с оригинальным файлом добавлен --force. После этого перегрузиться и уже тогда можно будет попасть в rescue mode. -- Victor Wagner
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV. То-то я смотрю у меня в системе этот файлик 2015 годом датирован.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:16:49 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, > судя по датам модификации файла /var/lib/urandom/random-seed скриптик > исправно отрабатывает при шатдауне и должен отрабатывать при > загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется > на urandom, вместо того, чтобы сохранённый пул использовать? > Кто-нибудь в курсе последних веяний в этой области? Так в системе systemd или sysV init?
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 13:30:06 +0300 Artem Chuprina wrote: > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > шуршать диском и т.д. > > > Но она не может стартовать ни одного сетевого сервиса, не набрав > > достаточно энтропии хотя бы для urandom, потому что все сервисы > > нынче хотят какие-нибудь эфемерные ключи. А следовательно - и > > проявить хоть какую-то сетевую активность, равно и локальный > > ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки > > будет все равно иметь проблемы со своей случайностью. > > Отчасти да. Но энтропию оно набирает, сколь я помню, не только с > сетевых запросов к себе, но и вообще со всего, что пролетает мимо > сетевки. Ага щаз, так уж в эпоху управляемых свитчей и полетит что-нибудь мимо сетевки, что этому хосту не адресовано. ARP-запросы разве что. Но много ли их в типичной серверной стойке? (а уж если это у нас виртуальный эзернет какой-нибудь системы управления виртуальными машинами...) > А сетевую активность без проблем со случайностью можно сделать, > например, так: взять совсем уже псевдослучайное число, например, > 8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый > PRNG, который не криптографического качества, а дальше в параллель > попинговать его следующие значения, периодически подмешивая тайминги > ответов. С этого ядро наберет уже вполне вменяемую энтропию. Интересная идея. Может такую утилитку написать и запускать из post-up в /etc/network/interfaces? Только стартовый адрес надо конфигурируемым сделать. А то вдруг из этого датацентра нет роутинга до 8.8.8.8. --
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 12:24:57 +0300 Artem Chuprina wrote: > Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала > набрать энтропию, и только потом уже раскручивать псевдорандомизацию. > А прикапывать ее между перезагрузками чревато тем же боком. Так-то > считается, что urandom — псевдослучайный, но с криптографическим > качеством. А значит, должен иметь в виду криптографическую модель > угроз. Получается проблема курицы и яйца. Чтобы набрать энтропию, системе требуется начать работать - обрабатывать какие-то сетевые запросы, шуршать диском и т.д. Но она не может стартовать ни одного сетевого сервиса, не набрав достаточно энтропии хотя бы для urandom, потому что все сервисы нынче хотят какие-нибудь эфемерные ключи. А следовательно - и проявить хоть какую-то сетевую активность, равно и локальный ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки будет все равно иметь проблемы со своей случайностью. --
Re: russian firewall
В Mon, 17 Dec 2018 13:31:02 -0500 Tim Sattarov пишет: > On 12/17/18 1:22 PM, Victor Wagner wrote: > > С тех пор я стараюсь добиваться от сотрудников чтобы у них все, > > используемое CI-системами лежало не далее чем на соседнем сервере в > > той же стойке. > > в > > Всеми руками плюсую, я довольно большую часть своего времени трачу на > то, чтобы делать CI системы независимыми от внешних источников и всё > равно находится кто-то умный, кто подсунет внешний докер или, не к > ночи помянут, npm/yarn... > К тому моменту, когда авторы средств разработки научились пользоваться удаленными репозиториями кода, практики осознали что коннективити - вещь хрупкая и ненадежная и бывает не всегда. -- Victor Wagner
Re: russian firewall
В Mon, 17 Dec 2018 13:44:19 +0300 sergio пишет: > Подозреваю, что этот список opensource проектов далеко не полон. Я налетал на блокировку xmlsoft.org. Правда разблокировали уже. Но что обидно это был автоматизирванный nightly build, который оттуда качал libxml. И он внезапно отвалился. С тех пор я стараюсь добиваться от сотрудников чтобы у них все, используемое CI-системами лежало не далее чем на соседнем сервере в той же стойке. в -- Victor Wagner
