Re: DevFS и прочие
Спасибо. > Видимо это и есть ответ на ваш вопрос:) Похоже, что да, и ответ полный: написано подробнее и точнее, чем мой текст. Мне остаётся это только в "художественном стиле" переписать, и всё. 31.07.2022 20:03, IL Ka пишет: Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? Не совсем imho: В devfs файлы устройств появлялись от вызова драйвером devfs_register. devfsd мог по ним сделать символические ссылки, но сами файлы он не трогал. В случае же udev, драйвер создает специальную структуру (она видна в /sys), и посылает uevent (через NETLINK), и udev уже создает нужную запись. Кмк, дело было так: До 2.4 все устройства создавались mkdev и драйвер привязывался к major номеру. Ненужные файлы забивали /dev, путали пользователя, имели проблемы с безопасностью (решение о пермишенах принимал автор скрипта MAKEDEV) а еще и major номера начали кончаться (их было-то всего 255). В 2.4 проблему решили devfs, позволив драйверу самому создавать устройство через devfs_register. Подробнее погуглите главу "The Device Filesystem" второго (не третьего!) издания Linux Driver Development. Стало лучше: в dev не стало несуществующих устройств и драйвер смог выбирать пермишены на файл. Однако осталась проблемы, наример пользователь всё еще не мог выбирать как назвать устройство оперируя его идентификатором. У каждой шины (PCI, USB) у устройства есть уникальные ID, и хотелось бы привязывать имена к ним. Кроме того, все существующие имена приходилось хранить в памяти ядра (невыгружаемой). Появилось желание вынести это в userspace. Всё это привело к вот такому (там много жалоб на devfs): http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf В 2.6 сделали sys, куда драйверы стали репортовать свои устройства, затем посылать uevent, который забирал udev, и на основе рулов создавал нужное устройство, а еще он по D-Bus мог сообщить об этом вашему DE, чтобы тот нарисовал красивый попап. Почитать можно тут: https://linux-kernel-labs.github.io/refs/heads/master/labs/device_model.html#sysfs Часть людей была против, вот тут их переубеждают: https://lwn.net/Articles/65197/ Затем udev смерджили с systemd:) Но тут оказалось, что udev не нравится емебдщикам и не подходит для всяких rescue mode, потому что требует нехилый userspace udev. Тогда был создан devtmpfs (тут подробно написано) https://lwn.net/Articles/330985/ Он просто брал имена (те, что драйверы репортуют в sys)и создавал для них устройства. Файловая система была создана на основе tmpfs, так что она была намного проще, и позволяла udevу работать поверх нее Естественно, все тут же сказали "мы опять изобрели devfs!" https://lwn.net/Articles/331818/ Но утверждается, что: * devtmpfs проще (сделана на основе tmpfs) * совместима с udev Видимо это и есть ответ на ваш вопрос:)
Re: DevFS и прочие
Хотя, в целом, для врезки информации достаточно. 31.07.2022 14:48, Maksim Dmitrichenko пишет: вс, 31 июл. 2022 г. в 14:27, Артём Н. : В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды. ...
Re: DevFS и прочие
Ну, или точнее, про демон, который идёт вместе с devfs, там есть одно упоминание, но мне не вполне ясно, это про devfsd (который пришёл на замену devfs вместе с её демоном, как я понял) или нет? Т.е., udev к devtmpfs не имеет прямого отношения: это просто независимо работающие вещи, тут всё ясно. А что пришло на замену devfs не вполне ясно: то ли был параллельно какой-то devfsd (именно независимый от devfs "пользовательский" демон), то ли после, то ли сразу был udev...
Re: DevFS и прочие
> Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный > элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока > udev наплодит там нужные ноды. Ну, т.е. сначала ноды экспортируются из ядра, затем применяются udev правила (операция переименования быстрая), после чего, по inotify (другой вызов, но я не помню) на sysfs делаются корректировки по событиям? > Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было > предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не > составит никакого труда. Да, я читал (и там, скорее "ну опять devfs?"). Они говорят, что нет, таких проблем, как было, не будет. А каких, там не упомянуто, видимо "и так все знают". > То есть да - во многом идеи, которые вложены в обе > подсистемы, общие. Но я вам кинул ссылку, > где Грэг сравнивает вполне себе > доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили > изучить? Ну, вообще-то у меня далеко не один источник и не единственная задача. Но почему вы считаете, что я "не осилил изучить"? Я прочитал и уже дописал к себе причины. В источнике написано примерно то, о чём вы и сказали: "персистентность устройств" - главное преимущество. Это разве в чём-то противоречит тому, что devfsd занимался примерно тем же самым, что и udev, да и вообще, разве там есть хоть что-то про devfsd (я обращаю внимание: про демон, а не про ФС)? > От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, > что через /proc задавался путь программы, которая будет запускаться ядром, > если требуется какое-то действие. Это называлось usermode helper. В случае > с udev программу запускает юзер один раз, и она общается с ядром по > интерфейсу а-ля шина. > ... Т.е., как и написал выше: суть та же. Но более прозрачно и эффективно сделано, более естественно. И гораздо более гибко настраивается. Кстати, про user-helper я с трудом но что-то припомнил, тоже допишу. Если я помню верно, хэлпер давал сигнал демону. Т.е. это были не скрипты, которые применяли какие-то правила, а именно запускалась программа (возможно это был симлинк на бинарник демона), которая давала сигнал демону? > без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs. Допишу в "плюсы". 31.07.2022 14:48, Maksim Dmitrichenko пишет: вс, 31 июл. 2022 г. в 14:27, Артём Н. : В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. Если я правильно понимаю, то сейчас devtmpfs совершенно не обязательный элемент. Он нужен только для того, чтобы ускорить загрузку и не ждать пока udev наплодит там нужные ноды. > Кажется, нельзя было например попросить систему всегда давать определенное > имя сетевой карте с определенным мак-адресом > (сейчас через udev это легко делается) Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? > Фишка udev еще в том, что пользователь настраивает правила, имея > возможность давать устройствам имена, > запускать скрипты при их появлении, запрещать какие-то устройства итд. Я так понимаю, что devfsd, который был до него, этим тоже занимался? запускать скрипты при их появлении, запрещать какие-то устройства итд. Если вы почитаете дискуссию мейнтейнров ядра в тот момент, когда было предложено devtmpfs, то встретить там вогласы "так это ж devfs2" не составит никакого труда. То есть да - во многом идеи, которые вложены в обе подсистемы, общие. Но я вам кинул ссылку, где Грэг сравнивает вполне себе доступно и поясняет в чем одно лучше другого. Вы до сих пор не осилили изучить? От себя добавлю: интерфейс devfs, если я правильно помню, подразумевал то, что через /proc задавался путь программы, которая будет запускаться ядром, если требуется какое-то действие. Это называлось usermode helper. В случае с udev программу запускает юзер один раз, и она общается с ядром по интерфейсу а-ля шина. Вместе с этим через шину стало проще передавать параметры, исходя из которых юзер может кастомизировать присваиваемые названия нодам и устройствам, а также задавать права доступа к ним. Как то: адрес на шине, серийный номер устройства, MAC-адрес и так далее. Наверное, было можно заморочиться и сделать подобное с devfs, но решили отказаться потому что придумали как сделать это всё более чисто и без необходимости писать и самое главное поддерживать в ядре и в драйверах кучу кода, отвечающего за devfs.
Re: DevFS и прочие
Здравствуйте. > Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. В DevTmpFS, по сути, тоже самое: если вы её примонтируете куда-то не в /dev, просто ради любопыства, там будут устройства, выставленные ядром. > Кажется, нельзя было например попросить систему всегда давать определенное > имя сетевой карте с определенным мак-адресом > (сейчас через udev это легко делается) Но это же делает набор правил уже *после* того, как устройство было выставлено драйвером. Или я что-то неправильно понимаю? > Фишка udev еще в том, что пользователь настраивает правила, имея > возможность давать устройствам имена, > запускать скрипты при их появлении, запрещать какие-то устройства итд. Я так понимаю, что devfsd, который был до него, этим тоже занимался? 31.07.2022 11:57, IL Ka пишет: Добрый день, Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. Кажется, нельзя было например попросить систему всегда давать определенное имя сетевой карте с определенным мак-адресом (сейчас через udev это легко делается) Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. Фишка udev еще в том, что пользователь настраивает правила, имея возможность давать устройствам имена, запускать скрипты при их появлении, запрещать какие-то устройства итд.
Re: DevFS и прочие
Ну, а я про что?
Андроид же, как я понял, хочет наоборот: сделать отдельный велосипед
("вернуть всё взад").
Не вижу тут ничего весёлого.
31.07.2022 09:41, Alexander Galanin пишет:
31.07.2022 02:17, Артём Н. пишет:
Понял, допишу. Спасибо.
Не хватало ещё очередного демона взамен udev, интегрированного в systemd.
Спасибо, повеселило. Ничего, что udev самым бессовестным образом лежит
_внутри_ репозитория systemd?
Re: DevFS и прочие
Понял, допишу. Спасибо. Не хватало ещё очередного демона взамен udev, интегрированного в systemd. 30.07.2022 20:02, Maksim Dmitrichenko пишет: сб, 30 июл. 2022 г. в 16:39, Артём Н. : Вот, отлично. То, что надо. А по udev в чём проблема? Он же появился самый последний? Ну то, в каком виде он сейчас - это не то, как была на рубеже отказа от devfs. Если я правильно помню, то тогда никакого devtmpfs не было. Была просто tmpfs, ноды в котором создавал udev. И ещё это работало с паре с вот этим делом https://linux.die.net/man/8/hotplug И я в конце его упомянул (а сейчас и так все знают, что это). А сейчас вроде читал, что ещё что-то хотят внедрить, так как Android не хочет в себя udev тянуть, а без него там тяжко. Хотят придумать что-то, что устроит всех.
Re: DevFS и прочие
Вот, отлично. То, что надо. А по udev в чём проблема? Он же появился самый последний? И я в конце его упомянул (а сейчас и так все знают, что это). 30.07.2022 16:18, Maksim Dmitrichenko пишет: Уф... давно дело было, конечно, но. Во-первых, в вашем повествовании пропущена целая эпоха под названием udev. Во-вторых, на сколько я помню, всю эту кашу заварили по сути из-за hotplug, когда ноды стали появляться и исчезать динамически. Devfs была интересной штукой, но в зависимости от последовательности вставления девайсов или в зависимости от енумератора шин при загрузке, девайсы не имели предсказуемых имен. По-моему, вот тут всё описано более менее четко: https://web.archive.org/web/20110411233322/http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs сб, 30 июл. 2022 г. в 14:24, Артём Н. : Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? Уверен, что тут есть те, кто и первой активно пользовались, и в любом случае, буду вам благодарен за любые замечания по тексту: ``` Существовало несколько вариантов поддержки устройств в Unix-подобных ОС и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через вызов makedev() создаёт большой набор файлов устройств, не проверяя то, есть эти устройства реально или нет. Если пользователь обратится к несуществующему устройству, система просто выдаст ошибку. Тогда /dev был лишь подкаталогом корневой файловой системы. И созданные файлы устройств существовали там всегда, а MAKEDEV запускался при необходимости. Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал устройства, о которых ядро предоставляло информацию (т.е. которые реально существуют). У такого подхода были недостатки: излишние обращения к ядру, по сути двойное перечисление устройств, понижающие скорость загрузки, необходимость поддержки в пространстве пользователя. Всё это усложняло использование системы во встраиваемых устройствах. Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. ```
Re: DevFS и прочие
Ok, буду искать дискуссию. А описание я видел это. Там "красота devfs", но система почему-то загнулась... 30.07.2022 16:13, Иван Лох пишет: On Sat, Jul 30, 2022 at 03:57:35PM +0300, Артём Н. wrote: Так 2002-2020, а некоторые решения, о которых я спрашиваю - это ещё 90-е. Кроме того, искать в тысячах сообщений именно то, что нужно, далеко не так просто, ну и та информация по devfs, которая там есть, мало о чём говорит: https://www.google.com/search?q=devfs+site:lkml.org Возможно кто-то помнит или может кинуть ссылку на конкретную документацию/обсуждение по вопросу? Дискуссия, которая привела к появлению udev была именно там. О devfs совсем просто написано здесь http://rus-linux.net/MyLDP/file-sys/holm/l-fs4_ru.html 30.07.2022 15:04, Иван Лох пишет: On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote: Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? https://lkml.org/
Re: DevFS и прочие
Так 2002-2020, а некоторые решения, о которых я спрашиваю - это ещё 90-е. Кроме того, искать в тысячах сообщений именно то, что нужно, далеко не так просто, ну и та информация по devfs, которая там есть, мало о чём говорит: https://www.google.com/search?q=devfs+site:lkml.org Возможно кто-то помнит или может кинуть ссылку на конкретную документацию/обсуждение по вопросу? 30.07.2022 15:04, Иван Лох пишет: On Sat, Jul 30, 2022 at 02:14:31PM +0300, Артём Н. wrote: Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? https://lkml.org/
DevFS и прочие
Здравствуйте. Пишу врезку для главы книги, и нужно краткую историю DevFS привести. Кто-нибудь помнит реальные причины того, почему devfs "не взлетел" и был заменён на devtmpfs? Уверен, что тут есть те, кто и первой активно пользовались, и в любом случае, буду вам благодарен за любые замечания по тексту: ``` Существовало несколько вариантов поддержки устройств в Unix-подобных ОС и в Linux, в частности. Один из первых - скрипт MAKEDEV, который через вызов makedev() создаёт большой набор файлов устройств, не проверяя то, есть эти устройства реально или нет. Если пользователь обратится к несуществующему устройству, система просто выдаст ошибку. Тогда /dev был лишь подкаталогом корневой файловой системы. И созданные файлы устройств существовали там всегда, а MAKEDEV запускался при необходимости. Затем разработчики Linux добавили в ядро поддержку devfs (не той, которая используется сейчас). С ней возникли проблемы. Например, пользовательские скрипты при загрузке должны были ожидать заполнения иерархии и как-то синхронизироваться, необходимость явных вызовов изо всех драйверов и т.д. Проблемы решались с переменным успехом, но система не прижилась. Следующим шагом был демон devfsd, обращающийся к ядру. Он создавал устройства, о которых ядро предоставляло информацию (т.е. которые реально существуют). У такого подхода были недостатки: излишние обращения к ядру, по сути двойное перечисление устройств, понижающие скорость загрузки, необходимость поддержки в пространстве пользователя. Всё это усложняло использование системы во встраиваемых устройствах. Современный Linux монтирует в /dev файловую систему DevTmpFS, которая сразу отображает все перечисленные ядром устройства, и поддерживающий различные правила и события демон udev, при необходимости, обеспечивающий её динамическую конфигурацию из пространства пользователя. ```
Интересное поведение сети
Здравствуйте. Есть UDP echo-сервер (не важно какой, пусть будет на основе Netcat): ``` ncat -4 --exec /bin/cat -u --listen 2000 ``` Запускаю клиент на той же машине: ``` ncat -4 -s 192.168.2.13 -u 127.0.0.1 2000 ``` Адрес 192.168.2.13 от реально существующего адаптера, т.е. адрес машины в ЛВС. Пишу что-то на клиенте - сервер выходит с кодом 0. Запрос принимает, ответ успевает отправить, но ответ не доходит. Почему?
Re: Зачем нужны библиотеки?
Технически, я shared memory, либо пайпы могу использовать, конечно. Но, согласен: всё же минус любой оверхед на IPC - ещё один плюс. Спасибо. 26.01.2022 22:34, Жанибек Нагашыбай пишет: В Wed, 26 Jan 2022 21:59:15 +0300 Артём Н. пишет: Но есть множество библиотек, например libhttpd, libmicrohttpd и т.п.. В целом, есть крайне ограниченное число вариантов, где их возможно использовать, но что-то всё у меня в сторону embedded уходит. Можете какие-то варианты предложить, где Nginx, в приницпе, не применим, и возможно использовать только библиотеки? Как вариант, веб-админка какого-нибудь сервера. К примеру, в игре Unreal Tournament (99 года, ага) есть встроенный веб-сервер, через который можно управлять сервером. В этом случае, готовая библиотека упрощает интеграцию вебчервера. А с nginx всё же придётся организовывать IPC.
Зачем нужны библиотеки?
Пишу учебный материал и задумался над таким вопросом: есть у меня, например тот же Nginx, который: - Расширяемый - я могу писать модули на любом языке. - Гибко конфигурируемый - с шаблонизатором я могу сделать конфигурации, динамически подхватывающие Docker-контейнеры, отправляющие запросы к ним по доменным именам, плюс включающие авторизацию, если у сервиса её нет. - Быстрый, надёжный, безопасный. Его достаточно легко встроить, особенно, в микросервсиную систему. Но есть множество библиотек, например libhttpd, libmicrohttpd и т.п.. В целом, есть крайне ограниченное число вариантов, где их возможно использовать, но что-то всё у меня в сторону embedded уходит. Можете какие-то варианты предложить, где Nginx, в приницпе, не применим, и возможно использовать только библиотеки?
Re: Проблема с дисками
Ладно, обновлю систему, буду смотреть дальше. 12.09.2021 00:01, Dmitry Semyonov пишет: On Sat, 11 Sept 2021 at 23:05, Артём Н. wrote: Контроллер - маловероятно: работало же ранее. Как вариант, проблема могла вскрыться при изменившемся профиле нагрузки и/или новой версии ядра.
Re: Проблема с дисками
8 дисков, но: - БП рассчитывался с запасом, и это Gold. - Ранее система работала стабильно года с 2018. Возможно, что подох блок, конечно... Контроллер - маловероятно: работало же ранее. Плата тоже ASRock, кстати. 11.09.2021 14:53, Dmitry Semyonov пишет: On Sat, 11 Sept 2021 at 04:33, spied wrote: Из моего опыта, чаще всего источником «непонятных» проблем является или нестабильное питание — умирающий БП или «вспухшие» конденсаторы на материнской плате; или «битая» память. БП может быть и не умирающий, а просто недостаточно мощный. Ещё бывают глючные контроллеры SATA (или их драйвера). Не знаю, насколько это применимо к SAS, но на одном сервере с PCIe SATA контроллером опция ядра libata.force=noncq,8:3.0 (число перед ":3.0" в другой конфигурации железа будет своё, а может и не одно) помогла перевести один сыпавший ошибками BTRFS RAID1-массив, подключенный к такому контроллеру, в состояние супер-стабильности. Причём ключевым параметром стало ограничение скорости до SATA 3.0; noncq сам по себе помог, но не до конца. Кусок вывода lspci, чтобы в поиске всплывало: 01:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04) 05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
Проблема с дисками
Здравствуйте. Рушатся ZFS пулы. Грешу на кабели, т.к. падают разные диски. Но кабели я поменял, а стыки разъёмов дополнительно укрепил капроном. Провёл badblocks на паре дисков. Битых нет. Однако, на SMART - ошибки, один пул degraded, второй suspended. Диски SAS HGST HUS724040ALS640 A320 и подобные 4 и 6 ТБ по 4 штуки. Один заменён на Seagate Exos ST4000NM003A. С ним, вроде, проблем нет. В чём может быть проблема остальными дисками? SMART, если требуется могу скинуть позже.
Re: Debian 10, SSD, full disk encryption
С 2018 использую ZFS в NAS/сервере. Корень, на ZFS, систему разворачивал вручную. Почти всё делаю вручную через консоль. Её команд не помню, мне приходится лезть в справочник. Потому что, это решение типа "поставил и забыл" - за время использования пока особых претензий нет и проблем тоже. On 26.05.2020 17:37, Maksim Dmitrichenko wrote: Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у данного решения, кроме нативной поддержки шифрования. С этим сталкиваешься только один раз - когда сетапишься. А жить потом с этим всю ноутбучную жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование сделано, если только на перформансе это не сказывается. сб, 23 мая 2020 г. в 13:04, Sergey Matveev mailto:stargr...@stargrave.org>>: *** Maksim Dmitrichenko [2020-05-23 01:47]: >2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM >уменьшает безопасность шифрования. Что, прям так сильно бьет? TRIM это просто утечка знаний/информации о том что вы там что-то у себя удаляется, а также конкретные места где вы это что-то удалили. Если злоумышленник, видя ваш зашифрованный диск (как? другой вопрос), отправил вам файл по почте, файл к вам упал и сохранился на диске: он видит изменение какого-то блока (+плюс блоки метаинформации). А когда вы удалили файл, то он видит, что именно этот блок снова стал пустым и он с высокой долей вероятностью может сказать что файл удалён (или переписан, если это CoW ФС типа ZFS или btrfs). В общем, утечка метаинформации есть и тут уж каждый сам решает готов он на такую жертву пойти или нет. Лично мне кажется, что преобладающему большинству пользователей будет пофиг на подобное. Поэтому смело можно (и нужно!) использовать TRIM. Кстати, в native ZFS шифровании точно такая же проблема: подобная метаинформация тоже утекает злоумышленнику (как и кол-во используемого места например). В этой рассылке уже как-то обсуждался native ZFS encryption vs ZFS over LUKS/whatever. В принципе, LUKS/whatever (даже с TRIM) более безопасен, но тоже из серии сильно гипотетически теоретических атак на которые на практике даже внимания обращать не стоит. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF -- With best regards Maksim Dmitrichenko
Re: Debian 10, SSD, full disk encryption
On 23.05.2020 01:47, Maksim Dmitrichenko wrote: Привет всем! На работе подогнали новый лэптоп с SSD. Требованием работодателя является работа на полностью шифрованном разделе. Собираюсь ставить на него десятый Дебиан. Вопросы: 1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt поверх обычного раздела sdaX? 2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM уменьшает безопасность шифрования. Что, прям так сильно бьет? А вообще это реально, чтобы SSD жил долго и счастливо без TRIM? 3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А может запускаться по расписанию. Что посоветуют многоуважаемые доны? -- With best regards Maksim Dmitrichenko 1. Сразу шифрование: так проще эксплуатация и безопаснее. Но лучше /boot выделить отдельным разделом без LVM. Ибо меня раздражает, как grub из EFI спрашивает и переспрашивает для раздела пароль. 2. Бьёт кто? Нарушитель - Агентство или Вася, попёрший ноут? Раз у вас есть такой вопрос: не имеет значения TRIM, - смело включайте. 3. Не столь важно, когда будет делаться TRIM, пока есть место, но "долго и счастливо" SSD без него жить не будет, а конкретика зависит от технологии SSD.
Re: Debian 10, SSD, full disk encryption
On 26.05.2020 17:51, sergio wrote: SSD жил долго ... без TRIM А это как-то связано? Я так понимаю, что когда контроллеру диска говорят TRIM на тот или иной блок, то он имеет возможность его перемапить на менее поюзанный, или наоборот заменить им другой блок, который уже хорошенько поюзан. Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear leveling влиять возможности нет. https://ru.wikipedia.org/wiki/Trim_(команда_для_накопителей) Любопытно, я почему-то думал, что влияет... А что бы SSD жил долго у меня /tmp, /var/cache/apt и пользовательский кэш в tmpfs.
Re: Fwd: Новая версия российского дистрибутива Astra Linux Common Edition
On 25.05.2020 13:57, Stanislav Maslovski wrote: On Sun, May 24, 2020 at 12:15:53PM +0300, Michael Shigorin wrote: Здравствуйте. Коллеги, если у кого будет лишний раз возможность помочь с вразумлением руководства русбитеха -- не пренебрегайте. ИМХО, эффективные менеджеры вразумляются только на нарах, да и то не в нашей реальности. +1. Особенно, с учётом того, что, дескать, сообщество Debian "вне политики". Но даже если бы это было не так, разбираться с российским сертифицированным дистрибутивом надо точно не здесь.
OMV в Docker
Всем привет. Есть NAS на Debian, полностью на ZFS. Все службы - в докере, есть поддерживающая инфраструктура (обратный прокси, Let's Encrypt, LDAP, простой Basic HTTP Auth, для тех, кто не поддерживает и т.п.). Для управления был пакетом установлен OpenMediaVault с ZFS плагином. Плагин кривой, не поддерживал рут на ZFS, но был пропатчен и залит Всё было нормально, до того, как Debian был обновлён, и пришёл новый PHP 7.3. Сейчас 10.3. Разработчики опять сломали плагин. Web-интерфейс OMV не работает. Короче: после обновления - уже давно пляски с бубном и функцию по управлению с web-ui не выполняет. Разбираться и чинить надоело. Имеет ли смысл убрать и поставить OMV в контейнере? Или это ни то, ни сё и приведёт к тому, что управлять не будет нормально, а безопасность понизит (из-за проброса лишнего в контейнер)?
Re: Э-почта как единственно нужный мессенджер
Далее, модель серверной подсистемы электронной почты (и связанная с ней модель адресации) примерно такая же как у XMPP. В этом смысле они взаимозаменяемы и оба должны использоваться тогда когда вероятность неотбиваемых атак на серверную инфраструктуру можно не рассматривать. А вот у IRC она не такая, она как у usenet. И там выбивание отдельных узлов из серверного "облака" не является критичным для коммуникации. (при условии что человека пускают на несколько серверов). Tox и Jami - они вообще бессерверные. Отсюда их достоинства, отсюда и их недостатки. Только все их "достоинства" перекрываются одним недостатком: не работают. Кстати, вы же в курсе, что государство весьма интересуется пользователями Tor? Ну а поскольку для аудиовидеосвязи есть столь же промышленно принятая и коммерчески успешная сеть — SIP, то псевдосвободные хипстерские поделия навроде Матрикса не нужны совсем. Матрикс интересен тем, что он работает поверх HTTP. Это позволяет ему проникать через некоторые корпоративные файрволлы, через которые не пустят IRC, XMPP, IMAPS и прочие. А так и правда IRC для хипстеров. Они все для "хипстеров": либо это версии не вышедщие за стадию бета-тестирования, либо требующие сложной настройки с использованием SIP, либо вообще просто обеспечивающие переписку текстом без звонков.
Re: Сокрытие факта связи
On 14.08.2019 13:31, Dmitry Alexandrov wrote: Иван Лох wrote: On Tue, Aug 13, 2019 at 04:46:59PM +0300, Dmitry Alexandrov wrote: Иван Лох wrote: Проблема в том, что многие типы сообщений адресованные _неограниченному кругу лиц_ могут по действующему законодательству трактоваться как уголовное преступление, даже если тоже сообщение адресованное _определенному кругу лиц_ совершенно легально. У меня подозрение, что вы напрочь упустили контекст беседы. Речь шла об способах усиления _тайны переписки_: как сохранить в тайне не только (1) содержание письма, но и (2) его адресата(-ов). Ответ на первой вопрос всем очевиден: шифровать его. Ответ на второй же вопрос почему-то менее очевиден, хотя столь же стар (если еще не старее): передавать его «в эфир», что сегодня значит — во всемирную сеть. На настоящий момент мне неизвестны места, где можно оказаться репрессированным за публикацию в Сети шифротекста. Ну по-крайней мере это сегодня делается повсеместно и массово: думаю, что и вы неоднократно загружали на публичные файлообменники объемные зашифрованные файлы, а потом кидали адресату на них ссылку по э-почте. Я что, отстал от жизни? Например, в Британии по себе отказ от предоставления ключа — уголовное преступление см. http://www.legislation.gov.uk/ukpga/2000/23/section/53 Хм. Да, известная вещь. Ну получается, что если вам есть почему опасаться британской карательных органов, то шифровать письма себе не надо, только адресатам. [В России], впрочем, нет. Но есть нюанс. Допустим вы рассылаете шифротекст по большому количеству адресов. Да нет, зачем, только в одно место достаточно отправить. Следователь полагает, что это Mein Kampf, возбуждается, получает санкцию приходит к Вам толпа ребят с шлемах ломает Вашу дверь и т. д. Преступление не завершено, но это как бы не важно. Есть же статья 30 УК РФ. Сажать можно и за приготовление к совершению. На самом деле я утрирую. 282 статья не может быть применена через 30. Чтобы сесть посылать надо не Mein Kampf) Ну... вам виднее, возражать не возьмусь. Но вот узнать конкретные прецеденты было бы любопытно. Между тем Вы имеет конституционное право читать и посылать по электронной почте текст этой книжки ограниченному кругу лиц. А вот здесь поподробнее, если можно. Насколько мне известно, закон воспрещает распространение «экстремистских материалов» вообще и всячески. Иначе как за «массовое распространение» не установлена уголовная ответственность — да, но «конституционное право»? На ваши "конституционные права" давно уже положили: им куча законов противоречит, если вчитаться.
Re: Сокрытие факта связи
On 13.08.2019 18:44, Иван Лох wrote: On Tue, Aug 13, 2019 at 04:46:59PM +0300, Dmitry Alexandrov wrote: Иван Лох wrote: Проблема в том, что многие типы сообщений адресованные _неограниченному кругу лиц_ могут по действующему законодательству трактоваться как уголовное преступление, даже если тоже сообщение адресованное _определенному кругу лиц_ совершенно легально. У меня подозрение, что вы напрочь упустили контекст беседы. Речь шла об способах усиления _тайны переписки_: как сохранить в тайне не только (1) содержание письма, но и (2) его адресата(-ов). Ответ на первой вопрос всем очевиден: шифровать его. Ответ на второй же вопрос почему-то менее очевиден, хотя столь же стар (если еще не старее): передавать его «в эфир», что сегодня значит — во всемирную сеть. На настоящий момент мне неизвестны места, где можно оказаться репрессированным за публикацию в Сети шифротекста. Ну по-крайней мере это сегодня делается повсеместно и массово: думаю, что и вы неоднократно загружали на публичные файлообменники объемные зашифрованные файлы, а потом кидали адресату на них ссылку по э-почте. Я что, отстал от жизни? Например, в Британии по себе отказ от предоставления ключа — уголовное преступление см. http://www.legislation.gov.uk/ukpga/2000/23/section/53 У нас, впрочем, нет. Но есть нюанс. Допустим вы рассылаете шифротекст по большому количеству адресов. Следователь полагает, что это Mein Kampf, возбуждается, получает санкцию приходит к Вам толпа ребят с шлемах ломает Вашу дверь и т. д. Преступление не завершено, но это как бы не важно. Есть же статья 30 УК РФ. Сажать можно и за приготовление к совершению. Между тем Вы имеет конституционное право читать и посылать по электронной почте текст этой книжки ограниченному кругу лиц. На самом деле я утрирую. 282 статья не может быть применена через 30. Чтобы сесть посылать надо не Mein Kampf) Спорно. Вообще ответственность есть за распространение и хранение с целью распространения. Докажете, что вы храните для себя электронную копию?
Re: Не могу найти файл
On 14.04.2018 00:14, sergio wrote: On 13/04/18 22:56, Иван Лох wrote: man journalctl Кстати, а bootlog теперь где искать? journalctl -b
Re: LDAP
Вот тут пока сложно: с IPv6 я только ознакомился, практически же не работал с ним. Это существенно упрощает администрирование, если коротко, то при использовании IPv6 необходимости в NAT нет, все устройства будут иметь глобально маршрутизируемые адреса. 1. Это вносит проблемы с безопасностью. 2. "Нормальным людям" пока ещё далеко до этого: где я, и где IPv6? Я статью почитал, там какая-то сильно передовая маргинальщина: IPv6, новый файрволл, TAYGA и NAS64. Если я с этим сейчас буду разбираться, мои проекты встанут на год, и меня проклянут. В текущем варианте, я просто хочу "чтобы работало", заниматься исследованиями новых сетевых технологий, пока времени нет. Да, белый IP уже есть, но для того, чтобы отличать VPS нужны доменные имена. Я могу использовать динамический DNS и диспетчер на nginx-proxy. Однако сейчас я пробрасываю порты. … если вы своим VPS будете раздавать IPv6-адреса, ничего пробрасывать не надо, берете любой бесплатный DNS-сервис (например dns.he.net) и присваиваете им доменные имена. То есть VPS с вашего NAS становятся доступны всему интернету, также как VPS какого-нибудь Амазона, нужно только защитить их файрволом. Ну примерно так я и собираюсь сделать, только на v4. В смысле? Любой, знающий IP, считается "прошедшим аутентификацию"? Не вариант. Не знающий IP, а получивший IP. Допустим, вы хотите дать своему знакомому доступ к как каталогу по NFS/FTP. Заводите на RADIUS-сервере учетную запись вашего знакомого (пароли могут хранится в виде хеша, а не открытым текстом) и говорите: «Подключайся к точке доступа с именем HomeShare». Далее он проходит, аутентификацию по сертификату и получает IP. Всё, с этого IP он напрямую получает доступ, ничего больше не требуется. А, в смысле точка ему выдаёт IP?
Re: LDAP
On 15.04.2018 12:19, Alexander Gerasiov wrote: Hello Артём, On Sat, 14 Apr 2018 23:00:46 +0300 Артём Н. wrote: Хочу сделать так, чтобы все сервисы на NAS централизованно получали данные о пользователях. Решил это реализовать через LDAP. Почитал. Вроде, теоретически понятно, а практически как-то не очень, бьюсь с LDAP уже немало. Тут описано не особо подробно и с опечатками (не slapd.conf, а ldap.conf): https://wiki.debian.org/LDAP/OpenLDAPSetup Это не очепятка, читай внимательнее, там сказано, что slapd.conf - это старый конфиг, теперь всё хранится в slapd.d ldap.conf используется только ldap-tools Я читал лог strace, и понял, что /etc/slapd.conf теперь вообще не читается. - Как настроить его так, чтобы был TLS (в перспективе будет торчать "наружу") с самоподписанным сертификатом? По документации. Легко сказать. Настроил "по документации". Не работает. - Где хранить .ldif файлы? Не надо их нигде хранить, ldap хранит всё внутри своей БД. Для управления пользователями можно использовать, например обертку вроде ldapscripts Уже разобрался: я их просто загружаю в базу LDAP. - Лучше запускать LDAP сервер в контейнере или устанавливать в систему? Удобнее, если в контейнере, конечно. Уже перенёс: теперь в контейнере (osixia/openldap:1.2.0). Рекомендую еще вот этот мануал, не знаю как сейчас, но раньше он был гораздо лучшее написан, чем debian wiki: https://help.ubuntu.com/lts/serverguide/openldap-server.html Спасибо. Читаю.
Re: LDAP
Если возможностей RADIUS-сервера будет не достаточно, то можно прикрутить к нему LDAP, но это скорее для крупных компаний, для дома это лишнее. [1]: https://blog.kr.pp.ru/post/2017-12-12/ Кое-как настроил LDAP локльно: это чудовище просто какое-то. Задолбался подключать к нему gitlab. Переделал всё на контейнеры, пока не работает TLS.
Re: LDAP
On 15.04.2018 12:05, Коротаев Руслан wrote: В сообщении от [Сб 2018-04-14 23:00 +0300] Артём Н. пишет: Хочу сделать так, чтобы все сервисы на NAS централизованно получали данные о пользователях. Решил это реализовать через LDAP. Почитал. Вроде, теоретически понятно, а практически как-то не очень, бьюсь с LDAP уже немало. - Оправданно ли вообще использование LDAP в таком случае? Рекомендую RADIUS (FreeRADIUS есть в репозитории). Смотрел его, и так понял, что он мне не нужен. Вы очень мало написали о сути проблемы, поэтому поделюсь своим решением, возможно оно и вам поможет. Фактически, писать тут особо нечего. Есть n сервисов, поддерживающих LDAP из коробки, и m пользователей, которые хотят пользоваться частью сервисов и, возможно, иметь личный каталог в ФС. Надо это реализовать. Логично, что управлять пользователями надо централизованно. Задача дальнего будущего - на внешних машинках авторизоваться с LDAP сервера, который крутится в NAS. Проблема: дома есть NAS, на котором крутятся сервисы раздачи файлов и мультимедиа по разным протоколам. Для себя и домашних проблем нет, подключаемся и получаем к ним доступ. Но что если пришли гости и просят WiFi, вряд ли вы хотите чтобы они увидели что-то вроде «Жесть. Отжигаю в Турции». Очевидное решение: сделать на роутере два VLAN — домашний и гостевой, и защитить паролем. Однако, пароля будет недостаточно, когда вас не будет дома, бабушка наверняка их перепутает. Поэтому нужен RADIUS, он есть даже в самом дешевом китайском роутере. Схема сложновата. В моём случае, NAS - вещь в себе. Я могу всё поднять на нём. - Как настроить его так, чтобы был TLS (в перспективе будет торчать "наружу") с самоподписанным сертификатом? Да, аутентификация по сертификату есть, если вы купите у своего провайдера белый IP-адрес, то вам не нужны самоподписанные сертификаты, можно использовать Let's Encrypt и разместить RADIUS-сервер на VPS. Да, белый IP уже есть, но для того, чтобы отличать VPS нужны доменные имена. Я могу использовать динамический DNS и диспетчер на nginx-proxy. Однако сейчас я пробрасываю порты. Имея белый IP-адрес, вы можете подключить IPv6, например через NAT64 [1]. Вы уже не будете ограничены домашней сетью и сможете давать доступ к своим сервисам на различных VPS исходя из IPv6-адреса. Вот тут пока сложно: с IPv6 я только ознакомился, практически же не работал с ним. В общем политика безопасности очень простая — получил IP-адрес (любой IPv4 и/или IPv6), значит прошел аутентификацию и можно давать доступ, дальше всё реализуем через файрвол. В смысле? Любой, знающий IP, считается "прошедшим аутентификацию"? Не вариант. Если возможностей RADIUS-сервера будет не достаточно, то можно прикрутить к нему LDAP, но это скорее для крупных компаний, для дома это лишнее. [1]: https://blog.kr.pp.ru/post/2017-12-12/ Я бы с удовольствием не парился с LDAP, но его поддерживают gitlab, OMV, urbackup, etc.
LDAP
Хочу сделать так, чтобы все сервисы на NAS централизованно получали данные о пользователях. Решил это реализовать через LDAP. Почитал. Вроде, теоретически понятно, а практически как-то не очень, бьюсь с LDAP уже немало. Тут описано не особо подробно и с опечатками (не slapd.conf, а ldap.conf): https://wiki.debian.org/LDAP/OpenLDAPSetup Может кто-нибудь объяснить (по шагам): - Оправданно ли вообще использование LDAP в таком случае? - Как настроить его так, чтобы был TLS (в перспективе будет торчать "наружу") с самоподписанным сертификатом? - Где хранить .ldif файлы? - Нужно ли делать /etc/ldap/ldap.conf или, как в руководстве, нужно "add attributes to cn=config"? - Лучше запускать LDAP сервер в контейнере или устанавливать в систему?
Re: Нюансы взаимодействия ZFS
On 02.04.2018 14:17, Dmitry Kulagin wrote: Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS pool лучше поверх LUKS, а не наоборот. LUKS почти не вносит оверхед. А кэширование записи диска всегда возможно включить вручную (как и подобрать размер блока, который у ZFS, к тому же, переменный). А после этого возникает закономерный вопрос: а зачем вам zfs? Вы только что избавились от одного из самых больших плюсов zfs и начали работать с device mapper, ну так продолжайте с ним работать, lvm и вперед, зачем плодить сущности? От какого же плюса я избавился? Как томами ZFS управлял, так и управляет. В чём тут проблема?
SAS hotswap и баг
Вытащил диск, вставил на место, но в /dev его не увидел. Зато увидел вот это в dmesg: [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page read [69930.896113] list_del corruption, 986c0632b010->next is LIST_POISON1 (dead0100) [69930.896226] [ cut here ] [69930.896227] kernel BUG at /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47! [69930.896329] invalid opcode: [#1] SMP PTI [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding xt_tcpudp cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate intel_uncore pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf rc_core ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) [69930.896925] spl(O) btrfs zstd_decompress zstd_compress xxhash algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd libahci mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas dca i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1 [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015 [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work [mpt3sas] [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000 [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90 [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086 [69930.898070] RAX: 004e RBX: 0246 RCX: [69930.898185] RDX: RSI: 986c1fdd66f8 RDI: 986c1fdd66f8 [69930.898298] RBP: 986c0632b738 R08: R09: 0fdf [69930.898413] R10: 017d R11: 99b88e6d R12: 986c0636b180 [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: 986c0d078010 [69930.898641] FS: () GS:986c1fdc() knlGS: [69930.898779] CS: 0010 DS: ES: CR0: 80050033 [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: 001606e0 [69930.899008] Call Trace: [69930.899121] scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod] [69930.899242] execute_in_process_context+0x5e/0x70 [69930.899358] device_release+0x2d/0x80 [69930.899467] kobject_put+0xa5/0x1a0 [69930.899580] scsi_remove_target+0x171/0x1b0 [scsi_mod] [69930.899699] sas_rphy_remove+0x55/0x60 [scsi_transport_sas] [69930.899814] sas_port_delete+0x2a/0x160 [scsi_transport_sas] [69930.899931] mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas] [69930.900053] _scsih_remove_device+0x21d/0x330 [mpt3sas] [69930.900171] ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas] [69930.900290] _scsih_device_remove_by_handle.part.30+0x78/0xc0 [mpt3sas] [69930.900407] _firmware_event_work+0x15c7/0x1d80 [mpt3sas] [69930.900519] ? update_curr+0xf0/0x1a0 [69930.900627] ? pick_next_task_fair+0x156/0x570 [69930.900737] ? __switch_to+0xa8/0x450 [69930.900844] process_one_work+0x181/0x370 [69930.900953] worker_thread+0x4d/0x3c0 [69930.901061] kthread+0xfc/0x130 [69930.901168] ? process_one_work+0x370/0x370 [69930.901278] ? kthread_create_on_node+0x70/0x70 [69930.901388] ret_from_fork+0x1f/0x30 [69930.901494] Code: 74 2b 48 8b 12 48 39 d7 75 34 48 8b 50 08 48 39 d7 75 3c b8 01 00 00 00 c3 48 89 fe 48 89 c2 48 c7 c7 60 9e 44 99 e8 7d 21 d5 ff <0f> 0b 48 89 fe 48 c7 c7 98 9e 44 99 e8 6c 21 d5 ff 0f 0b 48 89 [69930.901702] RIP: __list_del_entry_valid+0x4e/0x90 RSP: bbcfca9abb48 [69930.901816] ---[ end trace b1b41653fc7fb543 ]--- Чтобы это могло быть?
Re: SirfAtlas V
On 11.01.2018 23:06, Andrey Jr. Melnikov wrote: artiom wrote: Не особо надеюсь на помощь, но попробую. [...] Возможно ли это? Кто-нибудь занимался? Как это сделать? Возможно, надо только написать "чуть-чуть" кода в ядре, понять как организован NAND (в частности ECC), как работать с переферией. А потом выяснить, что ARMv6 (возможно даже без VFP) - это совсем грустно, а сигнал с SiGe SE4150L надо обрабатывать через DSP в процессоре, скорость вывода на экран - печальна, и на это всё нет никакой документации. Проще - положить на полочку. А как же заявленная совместимость с Linux? > Пусть работает памятником для wince. Так буду пользовать, для велосипеда же: лучше, чем ничего.
Re: Снова о ZFS
On 09.01.2018 20:25, Sergey Matveev wrote: *** Артём Н. [2018-01-09 20:23]: Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со впаянным Avoton). Если так, то тогда про мать молчу. Только корпус хороший точно получается. Корпус, да. Проблема матери ASRock в том, что она не miniITX, а miniITX extended (китайцы запилили свой форм-фактор). Для того, чтобы она влезла в корпус SilverStone DS380B, пришлось убрать в нём кусок металла. Жалею, что не взял корпус от FreeNAS (мать для Xeon, собственно, менять не на что, разве, что на Asus, но там контроллер SAS только один встроен). Но теперь, увы.
Re: Снова о ZFS
Потеря ZIL грозит потере части транзакций последних, верно. Но просто получается что с точки зрения ОС выполнен fsync, а на самом деле, при потере log устройства мы всё-равно теряет данные как-будто fsync-а не было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала скорость от них, то можно просто zfs set sync=disabled выставить -- и скорость не просядет и надёжность не зависит от вылета несдублированного log устройства. Но это моё личное мнение :-). Насколько знаю, log-device нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь не сказать что много софта нуждается в fsync-е. Как-то это противоречит тому, что потеря ZIL грозит потерей данных.
Re: Снова о ZFS
Ну предполагается, что журнал пишется синхронно с записью данных. В ZFS все записи (данных, изменённых метаданных) какое-то время агрегируются в памяти, а потом сбрасываются одним большим куском на диски. fsync для ZIL означает что эти данные не ждут когда они накопятся, а сразу же записываются на диск, но только в особую для ZIL область и только потом они уже распределяются по дискам нормально, штатно. http://www.freenas.org/blog/zfs-zil-and-slog-demystified/ Тут вот они и говорят, что сначала данные запишутся в short-term ZIL область, а только потом, второй раз ещё запишутся учитывая все эти RAIDZ конфигурации и прочее. То есть писаться они будут по два раза. Отдельное log устройство как-раз просто и выносит эту short-term область на отдельный диск. Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в итоге я всё-же куплю 2-й SSD)? Эм... Сейчас у меня только одна SSD и та - системная. А ведь потеря части ZIL мне грозит лишь частичной потерей последних транзакций? Потеря ZIL грозит потере части транзакций последних, верно. Но просто получается что с точки зрения ОС выполнен fsync, а на самом деле, при потере log устройства мы всё-равно теряет данные как-будто fsync-а не было. Если бы не было log-устройства, то fsync на обычные диски в RAIDZ надёжен -- при вылете одного из дисков всё-равно данные есть. Поэтому если вам так не нужна надёжность fsync-ов и не хочется чтобы проседала скорость от них, то можно просто zfs set sync=disabled выставить -- и скорость не просядет и надёжность не зависит от вылета несдублированного log устройства. Но это моё личное мнение :-). Насколько знаю, log-device нужен тем у кого нагруженные почтовые сервера, СУБД всякие. А так ведь не сказать что много софта нуждается в fsync-е. Для тех кто готов "сливать" только факт изменения всего блока, но не конкретной позиции в нём, есть режим EME -- который делает двойное шифрование (туда-обратно), что в два раза дороже для CPU, но да -- надёжнее. Каким образом он сливал? Вряд ли хранил в незашифрованном журнале. Я так думаю, что дисковое шифрование нужно для предотвращения оффлайновых атак, разве нет? Смотрите, у вас есть 512-байт блок жёсткого диска. Он шифруется в CBC режиме: то есть это 32 128-битных блока симметричного шифра. Вы перезаписываете данные в этом секторе диска, но начиная например с 300-го байта. Само собой весь блок физически на диск записывается с нуля, но перед этим он перешифровывается. Ключ у вас точно такой же как и был прежде, изменяемого вектора инициализации нет (его просто негде хранить на диске) Почему? Возможно хранить список векторов в метаданных, шифрованных на фиксированном ключе. Собственно, там же, где хранится реальный ключ шифрования диска. и первые 16 128-битных блоков такие же как и были прежде -- поэтому их перешифрование произведёт абсолютно точно такой же шифротекст как и был прежде. Но с 17-го блока (288-го байта внутри сектора) блок шифротекста уже поменяется. Если злоумышленник видел каким был блок до этой перезаписи и после, то он и видит что в этом секторе вы начали что-то менять в пределах с 288-304 байт этого сектора. Данные само собой не слились, но данные об этих данных (метаинформация) выдаёт где именно эти данные менялись. Так же как сделав LUKS/GELI на чистом диске, вы всё-равно видите что диск забит на 100% сплошными нулями и значит, хоть он и зашифрован, но ещё не использовался и данных на нём не было. Всё, понял: атака возможна, при наличии постоянного физического доступа к шифрованному диску. Я когда-то очень давно (больше 10 лет назад) писал вот такую статью: http://www.stargrave.org/Disk-encryption.html Прочитаю, спасибо. само собой не я придумывал все эти атаки, а просто собирал из разных источников эти знания в одной статье. Атак много разных. И до изобретения XTS режима (и tweakable block cipher) вы или мирились с двойным проседанием по скорости (по CPU) или шли на жертвы по разным атакам. Вот у меня дома жёсткие диски, но дома кроме меня, грубо говоря, никогда никого не бывает и я не представляю что в моё отсутствие кто-то приходил, вынимал диски, что-то с ними делал, вставлял обратно, итд. Я готов мириться с такими видами атак и поэтому вряд ли бы жёг на них свой CPU (хотя понимаю что сейчас производительность CPU такая, что все эти лишние перешифрования на скоростях НЖМД -- копейки). Зависит от загрузки. Или вот GELI/LUKS по-умолчанию не предоставляют никакой аутентификации данных, так как это начнёт занимать дополнительное место, но тоже не самый безопасный вариант. В смысле? GELI по-умолчанию делает просто XTS шифрование и не более. Вы можете спокойно изменить зашифрованные данные на диске и никто вам не скажет что их аутентичность/целостность нарушена. Полнодисковое шифрование требует чтобы никакого дополнительного места под это шифрование не занималось (ну не считая заголовков LUKS/GELI само собой). LUKS, насколько помню, тоже просто делает XTS/CBC/whatever шифрование -- аутентификации нет. В GELI это можно
Re: Снова о ZFS
On 09.01.2018 16:56, Sergey Matveev wrote: *** Артём Н. [2018-01-09 16:50]: https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже не собирал свой. У меня кстати именно буквально в таком же корпусе целых два своих сервера. И начинка наверное (материнская плата этой платформы) такая же как у них. Отличная платформа! Если бы мне снова пришлось бы себе NAS собирать, то я бы снова выбрал бы такое тоже. Только дорого, и начинка у меня получше будет (я так понимаю, там ASRock со впаянным Avoton).
Re: Снова о ZFS
On 08.01.2018 11:38, Sergey Matveev wrote: *** artiom [2018-01-08 04:18]: Как известно, FreeNAS продаёт свои уже собранные аппаратные конфигурации. И я заметил у них вот такой интересный девайс: https://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A Есть ли отличия от обычной SSD и, если да, то какие? Лично я про FreeNAS мало чего знаю, но удивлён что у них вот такие брэндовые штуки оказывается есть. Мне кажется что это простая SSD-шка. Даже не знаю что там может быть оптимального/специфичного для L2ARC. Они продают NAS в сборе, и честно говоря, я бы его может и взял, если бы уже не собирал свой.
Re: Снова о ZFS
Вроде немного, но я так полагаю, что оптимальное решение - просто сделать пул RAIDZ из 4-х дисков (и по скорости будет нормально, и избыточность не 33%, а 25%) и не париться. А, пардон: я всё это время почему-то подумал что у вас 4*4 дисков, то бишь 16. А это 4 четырёхтерабайтных. Да, тогда о RAIDZ3 или stripe из RAIDZ-ов можно не думать конечно же. Я бы наверное тоже как и вы бы сделал: просто RAIDZ4 из них и не парился. Именно. Четыре четырёхтерабайтника. Это же не стойка, а всего-лишь корпус с корзиной горячей замены. В смысле? RAIDZ из 4-х дисков? Не вполне понятно другое: 'To double your read IOPS, you would need to halve the number of "data" disks in the RAID-Z group (e.g. with RAIDZ-2, go from 12 to 7 disks).' Они же не хотят сказать, что при использовании RAIDZ на четырёх дисках, производительность упадёт в четыре раза, по отношению к одному диску? Честно говоря, с ходу я пока тоже не могу понять этой их фразы. Вот минут 10 пытаюсь понять, но не доходит :-) Однако, производительность не падает в два раза, при увеличении числа дисков вдвое? Ok, вас понял. Сжатие оставляю. Кроме того, серьёзных вычислительных задач, которые загрузят Xeon, там по-идее не будет: оно не должно мешать. У меня дома есть очень слабенький Celeron в котором я всюду и везде упираюсь в скорость SHA2/AES/Skein (вообще во всех задачах, не только ZFS) и прочей криптографии, но никогда не упирался в compression=lz4 (включай, не включай -- всё-равно упрусь в хэши). Ok, с этим всё ясно.
Re: Снова о ZFS
On 07.01.2018 19:22, Sergey Matveev wrote: *** artiom [2018-01-07 18:51]: - ZFS более оптимально работает с голым диском (делает ioctl, определяет диск ли это, если результат вызова положительный, выставляет оптимальные для себя параметры работы). Будет ли работать ZFS также оптимально через различные слои, в частности LUKS или gely? С голым диском работает без проблем. Но возможно надо будет указывать ashift параметр: http://www.open-zfs.org/wiki/Performance_tuning#Alignment_Shift_.28ashift.29 для дисков с 4KB размером блока. Это очевидно. Вопрос был в том, как она работает не с "голым диском"? Где то я видел что иногда ZFS не справляется с автоматическим нахождением всех членов пула если диски переименовываются (был sda, стал sdb, итд). И давали совет всегда делать ZFS поверх хотя бы GPT раздела с label-ом. Этот label очевидно при смене контроллера/диска/backplane не будет меняться, в отличии от имени диска. Кроме того, GPT ещё и от необходимости ashift избавит. Не будет менять контроллер (это смена платы, потому что он встроен), ни имя диска (диски в корзине). ZFS раздел в начале имеет немного зарезервированного места в которое например можно засунуть загрузчик ОС. FreeBSD например может быть полностью установлена на диск без каких-либо MBR/GPT на чисто ZFS диск. https://www.unix.com/man-page/freebsd/8/zfsboot/ Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. Насчёт ZFS поверх LUKS слышал что люди делают и проблем не было. Сам я использую ZFS поверх GELI -- тоже проблем нет. Более того, GELI даже TRIM-ы "пробрасывает" наверх по-умолчанию, так что SSD-GELI-ZFS всё-равно будет с TRIM-ом. Ладно trim, пробрасывается ли другие специфичные ioctl к диску или это будет ioctl к geli? - Если нет, то насколько стабильно, надёжно, изучено шифрование ZFS (по сравнению с вышеназванными)? Выполняется ли полнодисковое шифрование или это шифрование пофайловое (+метаданные)? Есть ли защита от cold boot attack (как в Linux ZFS, так и в BSD ZFS)? Родное шифрование сделано вроде бы грамотно, но оно не полнодисковое. Только часть метаинформации и данные шифруются и аутентифицируются. Плюсы родного шифрования: scrub, resilver, send/recv будут работать без предоставления ключа, тогда как с LUKS/GELI, не "открыв" ключом диск, нельзя будет сделать ничего. В смысле "без предоставления ключа"? Имеется ввиду, что он хранится глобально? Я пока не задумывался, как будет делать хот-своп для шифрованного диска, но возможно это будет сделать через udev (или аналогичную систему во FreeBSD). Т.е., если система работает, ничто не мешает мне проверить наличие шифрования с данным ключом у воткнутого диска. Если диск не шифрован, я просто создам шифрованный раздел, используя известный "ключ". Насчёт cold boot защиты не в курсе касательно ZFS. В Linux есть патч, переводящий ключи LUKS в регистры.
Re: Сканер
Подключить к другому роутеру, который будет стоять рядом. Вы мне предлагаете подключить по wi-fi? Ну это же изврат. Почему? Почему соединиться по беспроводу с машинкой в корпусе сканера — это приемлемо, а соединиться по беспроводу с машинкой вне корпуса — извращение? Потому что разводить набор беспроводных сетей для соединения машин на одном метре, я не хочу. Так или иначе, зная теперь, что оно и локально не подключается, могу только добавить «+1» к предложению Игоря Савлука: Ну да. Напишу в ТП sane чуть позже. Дело в том, что у них заявлена поддержка Linux: даже на коробке наклеечка и на самом МФУ Да я тоже так накалывался на этом. Они и не врут, драйвер для локальной USB печати у них есть (и бывает что его еще фиг поставиш). Тут только бежать в магазин и возвращать принтер побыстрее. Если не пожелают менять, то, наверное, имеет смысл попросить продавца показать, как же эта самая наклеечка реализуется на практике. 1. Печать работает. 2. Скан на FTP есть, а FTP может быть на Linux. очень не хотелось городить костыли. А, вероятно, придется. Не уважающая вашу свободу аппаратура — она такая. Я не заметил ни одного свободного МФУ (по крайней мере, а заданной ценовой категории, но в других тоже навряд ли это есть). Да даже не всего МФУ (как «железа»), хотя бы программ. Но даже так их нет, насколько я знаю. Именно. И вряд ли будут. О чём тогда разговор?
Re: Сканер
On 28.12.2017 23:56, Dmitry Alexandrov wrote: Остался вопрос по сканеру. В SANE предполагается, что сканер обязательно подключен локально. Вовсе нет. Предполагается, что клиент и сервер владеют каким-то общим протоколом. А когда стандарта (как с принтерами) нет — каждый производитель изгаляется как хочет. В данном случае, сканером, к принтеру-то они драйвер предоставили (для CUPS и ещё встроенную поддержку lpr). Для ХП и Самсунгов есть костыли, позволяющие использовать удалённые сканеры, но для Xerox такого нет. Это не костыли, это библиотеки, добавляющие поддержку тех самых собственнических протоколов. Да, я уже посмотрел в исходники sane-common. Как подключить сканер от Xerox по сети? Ну а чего вы хотите от проприетарщины? Если нельзя ни на тамошнюю ось поставить ничего совместимого с SANE, ни наоборот, то все — самостоятельным сетевым узлом вы ее не подключите. Хочу от не самого дешёвого МФУ известной фирмы, передовой в GUI для Unix-like систем, заявляющей о поддержке Linux, чтобы работало. Открытой ОС там нет, там же прошивка. Кроме того, веб-гуй на ASP. Подключите ее к USB к какой-нибудь машинке, куда можно поставить свободную юникс-подобную ось и на нее SANE. Бытовой маршрутизатор с LibreCMC / LEDE для этого вполне должен подойти. 1. Я пробовал его подключить по USB. SANE его не видит. Затем, я добавил usb vid/pid в конфиг для xerox_mfu, но оно не сработало (в дебаге видно, что он увидел сканер и пытается сделать INQUIRE, но видимо, отличается протокол). 2. Молодёжные проектировщики в Xerox решили, что Ethernet - не модно и оставили только Wi-Fi (а я недосмотрел), так что, с учётом пункта 1 - не вариант. 3. Он и так в сеть через общий роутер торчит, очень не хотелось городить костыли.
Re: странные kernel ошибки в логе
On 29.07.2017 17:13, Sohin Vyacheslav wrote: 29.07.2017 06:54, artiom пишет: Короче, ничего интересного. Интереснее выяснить: - Как вы его словили? читал email отчеты logwatch и увидел мегатонны kernel варнингов/ерроров 8-) В смысле, как вы его словили в систему? - Как он запускается? судя по ps auxw | fgrep vnsoxpd запускался ручками примерно так: $ ./vnsoxpd Чьими? o.O
Re: странные kernel ошибки в логе
On 28.07.2017 11:03, Sohin Vyacheslav wrote: 27.07.2017 21:03, artiom пишет: Скиньте бинарь. Willkommen Sie => das ist nicht problem => http://bit.ly/2w5rR6z Действительно, это "обычный майнер"... С открытыми исходниками (см. по строкам, там даже Usage сохранился), ссылку на которые дали выше. С непострипанной отладочной информацией. И даже вирустоталом он определяется, как майнер. Майнинг сервер: xmr.crypto-pool.fr: Майнит он некий cryptonight (очередная криптовалюта). Видимо, это кошелёк: 46qz79xUEuijoncPp3T96o2uLg9UFoyT6SKT6t2 Почему он криво работает, я разбираться не стал. Криворукий (не скажу, что дурачок, ибо начинать надо с малого) автор просто выкинул все проверки, видимо какая-то фигня при работе с XMM расширением (сразу в начале он его пытается использовать).
Re: nvidia
On 23.07.2017 04:14, Ivan Petrov wrote: 23.07.2017 00:50, Артём Н. пишет: On 22.07.2017 20:22, Ivan Petrov wrote: Пытался проапгрейдиться с jessie до stretch: "This system has a graphics card which is no longer handled by the NVIDIA driver (package nvidia-driver). You may wish to keep the package installed -for instance to drive some other card - but the card with the following chipset won't be usable: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [I0de:0a65] (rev a2) The above card requires either the non-free legacy NVIDIA driver (package nvidia-legacy-340xx-dnver) or the free Nouveau driver (package xserver- xorg- viaeo-no^veau). Use the update-glx command to switch between different installed drivers. Before the Nouveau driver can be used you must remove NVIDIA configuration from xorg.conf (and xorg.conf .d/). Install NVIDIA driver despite unsupported graphics card?" В стретч будет только базовый линуксовый драйвер для моей карточки? Чем это чревато в работе? Д. Вам же написано: "The above card requires either the non-free legacy NVIDIA driver (package nvidia-legacy-340xx-dnver) or the free Nouveau driver (package xserver- xorg- viaeo-no^veau)." Поставьте пакет nvidia-legacy-340xx-driver. Поставил, но не помогло. Так а предыдущий драйвер удалили (хотя, наверное, они конфликтуют)? И что значит "не помогло"? Симптомы какие?
Re: nvidia
On 22.07.2017 20:22, Ivan Petrov wrote: Пытался проапгрейдиться с jessie до stretch: "This system has a graphics card which is no longer handled by the NVIDIA driver (package nvidia-driver). You may wish to keep the package installed -for instance to drive some other card - but the card with the following chipset won't be usable: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [I0de:0a65] (rev a2) The above card requires either the non-free legacy NVIDIA driver (package nvidia-legacy-340xx-dnver) or the free Nouveau driver (package xserver- xorg- viaeo-no^veau). Use the update-glx command to switch between different installed drivers. Before the Nouveau driver can be used you must remove NVIDIA configuration from xorg.conf (and xorg.conf .d/). Install NVIDIA driver despite unsupported graphics card?" В стретч будет только базовый линуксовый драйвер для моей карточки? Чем это чревато в работе? Д. Вам же написано: "The above card requires either the non-free legacy NVIDIA driver (package nvidia-legacy-340xx-dnver) or the free Nouveau driver (package xserver- xorg- viaeo-no^veau)." Поставьте пакет nvidia-legacy-340xx-driver.
Re: NAS
А какой форм-фактор дисков лучше использовать? 2.5 или 3.5? Поискал, вроде как, 2.5 рекомендуют (характеристики те же, а размер меньше), почему тогда 3.5 до сих пор выпускаются?
Re: NAS
On 24.06.2017 15:54, Oleksandr Gavenko wrote: On 2017-06-23, artiom wrote: - RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял часть данных, упал диск в рэйде - рейд может и не пересобраться, потеряются все данные, упало два - капут). Это верно? - Mirror - слишком дорого, не стоит его ставить на домашний NAS? Обычно говорят что RAID повышает *доступность*. Меньше простоя. Когда говорят о надожности в RAID - приводят пример легитимной операции удаления файла )) Где же надежность? Она легитимна, хотя и может быть нужный файл удалён умышленно, это крайне маловероятно. Вопрос в том, что будет, если один из пачки дисков откажет, и что выдержит рейд. Дома за доступностьплатить нет смысла. А за надежность есть. Но достигается надежность избыточностью, бекапами и архивированием. С NAS? Репликацией в облако?
Re: NAS
On 24.06.2017 16:05, Oleksandr Gavenko wrote: On 2017-06-23, Sergey Matveev wrote: то Western Digital, но ни в коем случае не всякие Green модели, типа тихие, экологичные и прочее -- насколько знаю, это просто бракованные модели которые на пониженных нагрузках/мощностях хоть как-то тянуть. У меня все зелёные модели сдыхали довольно быстро -- табу на их приобретение. Добавлю свою небольшую статистику по всем двум зеленым, которые были, дохнут заразы. За годик.Но было это давно, лет 5 назад. См. выше, там есть статистика от backblaze.
Re: NAS
On 24.06.2017 13:06, Vasiliy P. Melnik wrote: Данные невозможно было восстановить или просто не имело смысла, т.к. проще переустановить монтирование пула приводило к краху системы, никакого программного обеспечения по восстановлению данных из зфс на тот момент не существовало, подозреваю, что и на текущий момент нет На любой системе? Т.е., подключение пула в другую систему или загрузка в ремонтной системе и последующее монтирование тоже крашились? С kernel panic что-ли?
Re: NAS
On 24.06.2017 13:25, Sergey Matveev wrote: *** artiom [2017-06-24 13:06]: Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так дорого стоят как время потраченное на вылет хотя бы одного из массива и его восстановление. Если у вас нет возможности поменять hotspare диски, то хотя бы это сильно увеличит время работы этого массива пока вылетит то один, то другой диск (или третий в случае с RAIDZ3). Слабо представляю, как это в домашнем NAS реализовать. Просто держать один диск резервным и неиспользуемым? Ну... да. Hotspare диски это называется. В mdadm или ZFS оно spare так и называется. Если кто-то вылетел, то mdadm/ZFS автоматически диск подхватывают в массив. По хорошему они и питание на диск должны отключить, чтобы он не крутился пока бездействует. И вручную отслеживать проблемы, его включать, в случае вылета кого-либо из рабочих? Если питание не отключить (или в корзине нет места для spare диска), то да, мониторинг и ручное вмешательство. Так программное управление питанием дисков через штатные средства или там какой-то специальный контроллер?
Re: Плееры на Linux
On 19.06.2017 23:46, Артём Н. wrote: Подскажите, чем удобно играть музыку "в фоне"? В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). Также, желательно не GTK. Попробовал Clementine, хороший, но не нравится управление. Amarok как-то в последнее время разочаровывает. Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже Clementine удобнее и функциональнее. mpg321 не предлагать. Вот ещё пара плееров, которые поставились и которыми, на первый взгляд вполне возможно пользоваться: http://www.guayadeque.org/ http://getnightingale.com/all-versions.php Последний из распакованного в локальный каталог тарбола.
Re: NAS
On 24.06.2017 11:35, Sergey Matveev wrote: *** Артём Н. [2017-06-24 01:19]: Рекомендовал он его затем, что данные не слишком критичные. Да, потерялась часть музыки, но это не важно: с другого компа возможно восстановить. Тогда можно не париться с RAID-ами действительно. Хотя я бы предпочёл RAID0 чтобы хотя бы быстрее работало. Тогда потеряется всё. Мне кажется что если кто-то вылетел в JBOD или RAID0 -- то больше потратишь времени на разбирательства что пропало и что надо восстановить -- проще всегда будет восстановить всё. Разумно, мне вариант с JBOD тоже не особенно нравится.
Re: NAS
On 24.06.2017 11:33, Sergey Matveev wrote: *** Артём Н. [2017-06-24 01:17]: В зеркале вы получаете полезного места только на три. При этом, получая высокую надёжность. Я вас не понимаю. Может вылететь половина, но не любые диски из неё. В RAID5 или RAID6 может вылететь любой (1 или 2). О какой надёжности речь? Вылететь могут они как одновременно (диски покупаются одновременно и есть вероятность брака в партии, например), так и в процессе перестройки рэйда. Одновременно -- я такого не встречал и не слышал что такое бывает. Запросто. Достаточно одного криворукого индуса в компании-производителе дисков. Вот здесь есть мануал, как сделать весьма неплохой граммофон из seagate на 3 Тб (он вылететь может в любой момент): https://habrahabr.ru/post/251941/ А вот в процессе перестройки -- да, может. Особенно когда ёмкость дисков стала огромной и время перестройки массива увеличилось. Поэтому и придуман RAID6, чтобы выдержать вылет ещё одного диска. Кроме того, надо менять диск. А под рукой его может не оказаться, также как может не быть и физического доступа к NAS. Обычно всегда в массив сразу же добавляют hotspare или хотя бы просто под рукой из точно такой же партии имеют диск где-то в ящике. Если нет физического доступа к NAS, то от вылета дисков ничего не спасёт. Ну, в том и фишка, что доступа к NAS может не быть неделю (не потащусь же я в другой город диск заменить). При этом, кроме меня заменить его некому. Интересно, а что там говорят про ZFS? В каком плане? Про его зеркало и RAIDZ? Всё то же самое что и про RAID. В плане замены рэйдов, LVM и прочего на ZFS.
Re: Стратегия поддержания резервных копий. Деградация носителей.
On 24.06.2017 01:17, Tim Sattarov wrote: On 06/23/17 17:41, Sergey Matveev wrote: *** Tim Sattarov [2017-06-24 00:21]: не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда в RAIDz ? Так просто не скажешь. Короче нужно смотреть на задачи, на режимы использования, на настройки. ZFS дорогая: на паршивом железе ведёт себя паршиво, на хорошем, с памятью, ведёт, как правило, лучше остальных. У меня сейчас одна задача с большим количеством (несколько терабайт) мелких и уже сжатых файлов: это ElasticSearch причём в AWS. где диски можно подобрать разные, но они все "сетевые" (EBS), то есть есть некоторая задержка в доступе. Там же важна скорость чтения. На своём ноутбуке с 4 GB памяти я не замечал разницы в производительности с переходом от XFS к ZFS, А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь, реально интересно. я потенциально думаю заменить мои LVM тома на ZFS в домашнем хранилище, но ещё не уверен... жду волшебного пенделя :) Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там RAIDZ есть, но дальше я не интересовался)? И что будет, если один диск из связки вылетит? Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и остановится ли система)?
Re: Странная ошибка при конфигурировании пакета
On 24.06.2017 09:58, Vasiliy P. Melnik wrote: |попробуйте так apt-get download sudo dpkg --unpack *.deb sudo rm /var/lib/dpkg/info/.postinst -f sudo dpkg --configure sudo apt-get install -yf #To fix dependencies| 24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал: Обновился апач. И у меня когда-то уже была такая ошибка: Настраивается пакет apache2 (2.4.25-3+deb9u1) … info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc ERROR: Conf apache2-doc does not exist! dpkg: ошибка при обработке пакета apache2 (--configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 1 При обработке следующих пакетов произошли ошибки: apache2 E: Sub-process /usr/bin/dpkg returned an error code (1) При этом, apache2-doc установлен и не обновляется. Aptitude выдаёт Internal error. Из-за такой дурацкой ошибки я не могу работать с другими пакетами: удаление, обновление и установка всего остального падают на этом. Надёжность на уровне. Что это за фигня и почему оно вообще появляется? И на кой делается a2enconf apache2-doc (причём, для пакета, которого может не быть)? После нескольких приседаний апач запустился, но это как-то не тянет на Debian stable.
Re: Странная ошибка при конфигурировании пакета
On 24.06.2017 09:58, Vasiliy P. Melnik wrote: |попробуйте так apt-get download sudo dpkg --unpack *.deb sudo rm /var/lib/dpkg/info/.postinst -f sudo dpkg --configure sudo apt-get install -yf #To fix dependencies| 24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал: Обновился апач. И у меня когда-то уже была такая ошибка: Настраивается пакет apache2 (2.4.25-3+deb9u1) … info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc ERROR: Conf apache2-doc does not exist! dpkg: ошибка при обработке пакета apache2 (--configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 1 При обработке следующих пакетов произошли ошибки: apache2 E: Sub-process /usr/bin/dpkg returned an error code (1) При этом, apache2-doc установлен и не обновляется. Aptitude выдаёт Internal error. Из-за такой дурацкой ошибки я не могу работать с другими пакетами: удаление, обновление и установка всего остального падают на этом. Надёжность на уровне. Что это за фигня и почему оно вообще появляется? И на кой делается a2enconf apache2-doc (причём, для пакета, которого может не быть)? При этом: # ll /var/cache/apache2/ итого 4,0K drwxr-xr-x 2 www-data www-data 4,0K июл 23 2014 mod_cache_disk -rw-r--r-- 1 root root0 июл 26 2014 reload
Re: Странная ошибка при конфигурировании пакета
On 24.06.2017 09:58, Vasiliy P. Melnik wrote: |попробуйте так apt-get download sudo dpkg --unpack *.deb sudo rm /var/lib/dpkg/info/.postinst -f sudo dpkg --configure sudo apt-get install -yf #To fix dependencies| 24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал: Обновился апач. И у меня когда-то уже была такая ошибка: Настраивается пакет apache2 (2.4.25-3+deb9u1) … info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc ERROR: Conf apache2-doc does not exist! dpkg: ошибка при обработке пакета apache2 (--configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 1 При обработке следующих пакетов произошли ошибки: apache2 E: Sub-process /usr/bin/dpkg returned an error code (1) При этом, apache2-doc установлен и не обновляется. Aptitude выдаёт Internal error. Из-за такой дурацкой ошибки я не могу работать с другими пакетами: удаление, обновление и установка всего остального падают на этом. Надёжность на уровне. Что это за фигня и почему оно вообще появляется? И на кой делается a2enconf apache2-doc (причём, для пакета, которого может не быть)? И дальше: июн 24 11:28:01 dana htcacheclean[27764]: htcacheclean error: Could not set filepath to '/var/cache/apache2/mod_disk_cache': No such file or directory июн 24 11:28:01 dana htcacheclean[27764]: htcacheclean -- program for cleaning the disk cache. Почему [оно у меня не работает из коробки]?
Re: Странная ошибка при конфигурировании пакета
On 24.06.2017 09:58, Vasiliy P. Melnik wrote: |попробуйте так apt-get download sudo dpkg --unpack *.deb sudo rm /var/lib/dpkg/info/.postinst -f sudo dpkg --configure sudo apt-get install -yf #To fix dependencies| 24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал: Обновился апач. И у меня когда-то уже была такая ошибка: Настраивается пакет apache2 (2.4.25-3+deb9u1) … info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc ERROR: Conf apache2-doc does not exist! dpkg: ошибка при обработке пакета apache2 (--configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 1 При обработке следующих пакетов произошли ошибки: apache2 E: Sub-process /usr/bin/dpkg returned an error code (1) При этом, apache2-doc установлен и не обновляется. Aptitude выдаёт Internal error. Из-за такой дурацкой ошибки я не могу работать с другими пакетами: удаление, обновление и установка всего остального падают на этом. Надёжность на уровне. Что это за фигня и почему оно вообще появляется? И на кой делается a2enconf apache2-doc (причём, для пакета, которого может не быть)? Не, я понимаю, что вручную это пофиксить возможно, только делать это каждый раз муторно. Я не понимаю, почему это возникает в данном пакете (апач как-бы не левый пакет)? И почему один кривой пакет, у которого не проходит конфигурация, ломает всю систему? Смотрит он на наличие вот этой фиготы: # dpkg -S /var/lib/apache2/deferred_actions dpkg-query: не найден путь, подходящий под шаблон /var/lib/apache2/deferred_actions # cat /var/lib/apache2/deferred_actions apache2-doc apache2_invoke enconf apache2-doc Откуда это? И если я его удалю, ничего не сломается?
Странная ошибка при конфигурировании пакета
Обновился апач. И у меня когда-то уже была такая ошибка: Настраивается пакет apache2 (2.4.25-3+deb9u1) … info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc ERROR: Conf apache2-doc does not exist! dpkg: ошибка при обработке пакета apache2 (--configure): подпроцесс установлен сценарий post-installation возвратил код ошибки 1 При обработке следующих пакетов произошли ошибки: apache2 E: Sub-process /usr/bin/dpkg returned an error code (1) При этом, apache2-doc установлен и не обновляется. Aptitude выдаёт Internal error. Из-за такой дурацкой ошибки я не могу работать с другими пакетами: удаление, обновление и установка всего остального падают на этом. Надёжность на уровне. Что это за фигня и почему оно вообще появляется? И на кой делается a2enconf apache2-doc (причём, для пакета, которого может не быть)?
Re: Плееры на Linux
On 24.06.2017 01:51, Артём Н. wrote: On 19.06.2017 23:46, Артём Н. wrote: Подскажите, чем удобно играть музыку "в фоне"? В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). Также, желательно не GTK. Попробовал Clementine, хороший, но не нравится управление. Amarok как-то в последнее время разочаровывает. Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже Clementine удобнее и функциональнее. mpg321 не предлагать. Ещё один любопытный плеер: http://foobnix.com/en/ Ставлю. Как всегда: Traceback (most recent call last): File "/usr/bin/foobnix", line 98, in foobnix() File "/usr/bin/foobnix", line 71, in foobnix from foobnix.gui.controls.dbus_manager import foobnix_dbus_interface File "/usr/lib/python2.7/dist-packages/foobnix/gui/controls/dbus_manager.py", line 9, in import dbus.service ImportError: No module named dbus.service Нафиг. Разбираться лень, почему он этот модуль не находит, а в зависимостях его нет.
Re: Плееры на Linux
On 19.06.2017 23:46, Артём Н. wrote: Подскажите, чем удобно играть музыку "в фоне"? В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). Также, желательно не GTK. Попробовал Clementine, хороший, но не нравится управление. Amarok как-то в последнее время разочаровывает. Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже Clementine удобнее и функциональнее. mpg321 не предлагать. Ещё один любопытный плеер: http://foobnix.com/en/ Ставлю.
Re: NAS
On 23.06.2017 22:48, Sergey Matveev wrote: *** artiom [2017-06-23 22:27]: Хочу, чтобы NAS торчал в Интернет и был точкой синхронизации пока между ноутом и стационарным компом. - Какие диски лучше использовать (объём, марка)? Был обзор со статистикой, вроде как Хитачи отказывают меньше всех. Так? Лично мой опыт говорит что Hitachi/HGST действительно самые качественные. Seagate самые некачественные. Однако у Hitachi цена покусывается. Если не Hitachi, то Western Digital, но ни в коем случае не всякие Green модели, типа тихие, экологичные и прочее -- насколько знаю, это просто бракованные модели которые на пониженных нагрузках/мощностях хоть как-то тянуть. У меня все зелёные модели сдыхали довольно быстро -- табу на их приобретение. Вот: https://habrahabr.ru/post/237887/ https://geektimes.ru/post/275948/ - Покупать готовую железку не имеет смысла: дорого и малопроизводительно. Так? - Возможно купить коробку и поставить в неё китайский промышленный ПК в корпусе. Выйдет мощнее за те же деньги. Чем плох этот вариант? Готовые железки бывают разные. Которые ориентированы для дома -- да, как правило там совсем простенькое железо на котором, например о ZFS, можно даже не мечтать. А вот например такие железки: http://netberg.ru/products/netberg-demos-p200-m3/ хороши тем что компактны, тихи, надёжны Лучше уж тогда брать нечто слабее, но с пассивным охлаждением. внутри нормальный Xeon с ECC памятью можно поставить и иметь hot-plug для трёх дисков. Когда-то подобные железки стоили своих денег (сейчас не знаю). Xeon избыточен для NAS, мне так кажется (и это изделие позиционируется не как NAS, а как офисный сервер). Для ZFS обязательна (крайне желательна) ECC память? И нужен ли ZFS? - Аппаратные RAID контроллеры могут быть лишь дорогими, либо это те же самые программные и вместо них лучше использовать обычный программный RAID, предоставляемый ОС. Это верно? Бывают и действительно аппаратно "ускоряемые" (где отдельные чипы считающие тот же код Рида-Соломона для RAID6), бывают и просто маленькие компьютеры с обычным процессором и простой ОС. Самое фиговое в аппаратных это то, что они зачастую несовместимы ни с кем и поэтому если он выйдет из строя, то не получится засунуть в другой контроллер и попытаться считать данные. Раньше аппаратные имели смысл, а сейчас, из-за дешёвых мощных CPU -- по моему уже как лет 5-10 абсолютно никакого. Xeon десятилетней давности на 50-60% загружался при rebuild многоуровневого массива RAID6 из 24 дисков на mdadm-е. Я бы советовал однозначно и только программный RAID (mdadm в GNU/Linux) -- современные процессоры достаточно быстры чтобы даже RAID6 иметь без проблем, плюс лёгкость использования массива в любой другой системе, без vendor lockin. Ok, с контроллерами вопрос решённый: не нужен. И лишних затрат не будет. А нужен ли RAID или всё-таки ZFS, который многие хвалят, но с которым я пока не разбирался? - RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял часть данных, упал диск в рэйде - рейд может и не пересобраться, потеряются все данные, упало два - капут). Это верно? Совершенно не верно. RAID0 (stripe) -- да, при потере диска, теряется весь. RAID5 -- рассчитан чтобы пережить вылет одного диска (минимум три диска нужно). RAID6 -- двух любых дисков (минимум четыре нужно). Если делать (а для большого количества дисков только так и надо делать) многоуровневый RAID, то там может вылететь приличное кол-во дисков и данные не будут потеряны. То что RAID может не пересобраться... странно это как-то. Как это он не пересоберётся? Вышел из строя второй диск, сдох контроллер (в случае аппаратного), зависла ОС (из-за system.d) в процессе пересборки. Или: Значит он не рабочий, с багами, кривой? Тогда ничто не поможет. Вариантов много. Фактически все RAID уровни расчитаны на надёжность, кроме RAID0, который и не всегда за RAID-то считают. Я имел ввиду надёжность, по сравнению с JBOD. - Mirror - слишком дорого, не стоит его ставить на домашний NAS? Смотря сколько дисков. Если три, то делать RAID5. Если четыре диска, то я за RAID6 и яро против RAID10: в RAID10 у вас могут вылететь *не* любые два диска, а в RAID6 любые, хотя и ценой CPU, но они же ведь дешёвые и мощные сейчас. В любом случае RAID1 это только для двух дисков скорее имеет смысл, а при большем кол-ве дисков лучше другие уровни чтобы не такие потери (50%!) места были. Само собой своевременно делая rebuild, подставляя новые диски, при утрате старых. Вот последнее как-раз сложно. - По картинкам мне понравился GUI FreeNAS. OpenMediaVault не хуже FreeNAS по функциональности и удобству? Лично я слабо знаком с FreeNAS и никак не знаком с OpenMediaVault, но, судя по Wikipedia, последний не держит ZFS. Лично я бы даже не стал рассматривать -- без ZFS жизни нет, тем более там, где речь о больших объёмах данных и множестве дисков. В смысле, не держит? Это Debian. Возможно туда впилить ZFS не особо напрягаясь. Но, в случае ZFS, вам нужно забыть будет про RAID. Stripe, зеркало, ана
Re: NAS
On 23.06.2017 23:07, Sergey Matveev wrote: *** artiom [2017-06-23 22:58]: Да, как-раз JBOD и рекомендовался. Зачем? У вас JBOD на двух 1TiB дисках -- значит вылетел один диск и какой-то из двух терабайт вы потеряли навсегда. Для NAS непонятно зачем оно, ведь если вылетел один диск, то, скорее всего, данные на всех остальных станут бесполезными. Второе - далеко не факт и зависит от того, как данные распределены. Рекомендовал он его затем, что данные не слишком критичные. Да, потерялась часть музыки, но это не важно: с другого компа возможно восстановить.
Re: NAS
On 23.06.2017 23:05, Sergey Matveev wrote: *** artiom [2017-06-23 22:57]: Не про отказоустойчивость вопрос, а про повышение надёжности относительно отсутствие рэйда. Рэйды 5 и 8, если не ошибаюсь, где хранятся контрольные суммы не увеличивают надёжность, по утверждению товарища. RAID5 не хранит контрольные суммы, он хранит XOR от блоков на других дисках -- то есть там нет диска который просто может показать проблему, он "восстановит" данные, в отсутствии одного из дисков. RAID6 использует код Рида-Соломона (или вариации) -- аналогично, он способен при отсутствии двух "слагаемых" восстановить всё остальное. Я не помню, как они устроены и лень смотреть было, но вы меня поняли. Чисто технически надёжность дисков остаётся такой же, само собой. Вот только компромиссы между скоростью, потерей места, доступностью данных. Например у вас 6 дисков. В зеркале вы получаете полезного места только на три. При этом, получая высокую надёжность. И вылет только некоторой половины массив сможет пережить. В RAID6 у вас полезного места на четыре диска, а вылететь могут любые. Не будете же вы ждать пока вылетит второй, после первого, а потом ещё и третий чтобы массив стал вообще недоступен? Вылетел кто-то -- неспешно заменили, запустили rebuild. Но саму вероятность выхода жёсткого диска из строя никто из RAID увеличить не может. Вылететь могут они как одновременно (диски покупаются одновременно и есть вероятность брака в партии, например), так и в процессе перестройки рэйда. Кроме того, надо менять диск. А под рукой его может не оказаться, также как может не быть и физического доступа к NAS. Интересно, а что там говорят про ZFS?
Re: optical media
300? На прежней моей работе было более 3000 дисков архива. Собственно, и сейчас есть, хотя новые данные идут на НЖМД. […] Суровые вы ребята. Эксперты рекомендуют: https://cld.bz/users/user-WmA6B3j/Arctic-World-Archive/1 Плёнка - лучший вариант. :-) http://www.piql.com/
Re: Ищу голосовую общалк у.
On 22.06.2017 10:42, sergio wrote: Я нашёл --- это Riot! https://riot.im А в чём плюсы, почему она?
Re: Ищу голосовую общалк у.
On 22.06.2017 12:16, Oleksandr Gavenko wrote: On 2017-06-22, Sohin Vyacheslav wrote: 22.06.2017 10:42, sergio пишет: Я нашёл --- это Riot! https://riot.im Current release: v0.11.3 не сыровато ли? Смотрю что Message-Id ведет к моему давнему вопросу. Из децентрализованых я пробовал Tox и Ring. Оба были год назад сырыми и неудачными решениями. Я также смотрел на наличие Android клиентов. Весь спектр "общалок" доступен для выбора на сайтах типа: http://alternativeto.net/software/tox/ Tox пока сыроват (реализация сырая).
Re: Плееры на Linux
On 20.06.2017 17:34, Victor Wagner wrote: On Tue, 20 Jun 2017 13:19:46 +0300 artiom wrote: Вполне себе unix-way. вся активность НА РАБОЧЕЙ СТАНЦИИ, которая не требует непосредственной интеракции с пользователем как то, работа с принтером, проигрывание звуков, качание торрентов обеспечивается демонами, которыми GUI-программы только управляют. Это всё круто, но если без *-way? Какие преимущества мне это даст? Преимущества - 1. возможность сделать logout и завершить сессию, не дожидаясь завершения заданий Не вполне понял что это значит, и что мне мешает это сделать в любом случае. 2. Возможность поуправлять фоновыми заданиями из другой сессии, как того же самого пользователя (например, зайдя удаленно по ssh), так и другого. Согласен. Редко, но может быть полезно. Тем не менее, у многих плееров сейчас есть плагины, даже Web интерфейс предоставляющие. И какие недостатки имеет? Недостатки, соотвественно продолжение достоинств. А именно задачи не будут автоматически прерваны при завершении сессии, и демон будет требовать какого-никакого конфигурирования. Любопытно, он поддерживает всякую там оценку музыки? Позволяет выбирать, что проигрывать? И, кроме того, позволяет проигрывать на клиенте? У меня две машинки: стационарная и ноут. Я держу полные копии на обеих. Я там единственный пользователь. Какие преимущества мне даст MPD перед обычными плеерами? Можно будет запустить длинную последовательность музыки играть на колонках стационарной машины, а самому, валяясь с ноутом на диване, ей вдруг поуправлять, если приспичит. Это плюс, но дело в том, что ноут я беру с собой, там, в любом случае, должен быть хотя бы частичный дубликат коллекции. Ну то есть что касается конкретно звука, там можно поспорить. Поскольку есть вопрос о том, является ли звуковой ввод-вывод частью сессии или нет, и должен ли звук замолкать, если пользователь залочил экран или сделал logout и отошел от компьютера. Это да, но тут конечно клиент MPD может останавливать проигрывание. Насколько я понимаю, весь смысл MPD в том, что ты запустил что-то играться, потом закрыл клиент и оно продолжает играться. Помнится был некогда такой продукт vmware server. Обладал он интересным свойсвом - если ты запусаешь его клиент, запускаешь в нем виртуальную машину, и закрываешь клиент, виртуальная машина продолжает работать. Почему был? Можно туда, скажем по ssh ходить. А если ты забыл закрыть клиент, и завершил сессию, то почему-то прибивание клиента при завершении сессии пришибало и виртуальную машину. Очень злило. Потом, правда этот продукт быстро прекратил развиваться. Часть его функциональности перенесли в VMware workstation, а для части стали рекомендвоать более тяжелые продукты ESX и Sphere. Он сейчас и есть ESX. Поэтому я считаю что клиент к демону не должен "автоматически" при завершении останавливать работу сервера. Это напоминает богопротивный андроид, или того робота из азимовских рассказов, который отказывался перемещаться без человека на шее. Если уж ты поделил какую-то работу между клиентом и демоном, то это ровно для того, чтобы эта работа могла делаться без человеческого присмотра. Опять же: у меня не "умный дом" с 5-D аудиосистемой по всем комнатам, а нищебродский вариант с двумя компами. Мне сейчас проще нужно.
Re: Плееры на Linux
On 20.06.2017 14:36, Evgenij Kravtsov wrote: Попробуйте DeaDBeeF (http://deadbeef.sourceforge.net/) Пробовал буквально неделю назад. Не понравился. Не увидел преимуществ по сравнению с Clementine. 20 июня 2017 г., 13:21 пользователь artiom mailto:artio...@yandex.ru>> написал: > Я активно пользуюсь Audacious. Есть гуй на gtk, есть - на qt. Очень > минемалистичный, но поддерживает достаточно много полезных дополнений. > Так тоже самое, что Qmmp? > 19 июня 2017 г. 23:46:58 GMT+03:00, "Артём Н." mailto:artio...@yandex.ru>> пишет: > > Подскажите, чем удобно играть музыку "в фоне"? > В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). > Также, желательно не GTK. > Попробовал Clementine, хороший, но не нравится управление. > Amarok как-то в последнее время разочаровывает. > Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже Clementine удобнее и функциональнее. > mpg321 не предлагать. > > > -- > С уважением, > walterd -- С уважением Кравцов Евгений тел 89192821798 skype: ejkrav telegram: @ejkrav
Re: Установить debian без systemd
On 20.06.2017 05:32, Tim Sattarov wrote: On 11/06/17 11:13 AM, artiom wrote: Не вам одному это не нравится: "The controversy around systemd culminated also into personal attacks and death threats on Poettering. In October 2014 Poettering complained that the "Open Source community is full of assholes, and I probably more than most others am one of their most favourite targets." Poettering went on to put some blame on Linus Torvalds and other kernel developers for being a bad role model for encouraging an abusive discussion culture on technical disagreements; a position which was shared by others like kernel developer Sarah Sharp." Bad role modeling ? правда штоле ? :) https://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/ Я за такое,на месте Линуса, сделал бы и сказал то же самое. При всей моей поддержке systemd, личность Поттеринга совсем не внушает приязни... Дык, символичный жест, это ж не поттерингу а Каю Стивенсу.
Re: Плееры на Linux
On 20.06.2017 00:08, ugoday wrote: А почем не mpd? Так некуда. Ставить его сервер локально - это извращение. СХД пока не запилил. Как будет, так и буду думать насчёт MPD. И как совместить всё это с ноутом, который может быть иногда и не подключен к сети.
Re: Плееры на Linux
Не GTK, умеет демонизироваться, умеет gapless playback, playlist, разные звуковые устройства и кодеки. И не MPD. Хотя, поддержка MPD лишней не будет. На будущее. Gtk тоже возможно, если по всем остальным параметрам он прекрасен.
Re: Плееры на Linux
On 19.06.2017 23:52, Sergey Matveev wrote: *** Артём Н. [2017-06-19 23:47]: Подскажите, чем удобно играть музыку "в фоне"? В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). Также, желательно не GTK. https://en.wikipedia.org/wiki/Music_on_Console Не GTK, умеет демонизироваться, умеет gapless playback, playlist, разные звуковые устройства и кодеки. Может, это покажется странным, но GUI что-нибудь есть? Я консольку почти всегда в графической среде держу (если нет, значит что-то сломалось, и мне не до плеера). Не хочется консольный.
Плееры на Linux
Подскажите, чем удобно играть музыку "в фоне"? В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не обязательно). Также, желательно не GTK. Попробовал Clementine, хороший, но не нравится управление. Amarok как-то в последнее время разочаровывает. Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже Clementine удобнее и функциональнее. mpg321 не предлагать.
Re: Установить debian без systemd
On 19.06.2017 13:44, Иван Лох wrote: On Mon, Jun 19, 2017 at 01:33:13PM +0300, artiom wrote: Кстати, а почему? Я почитал и нашёл, что они препятствуют разработке свободных драйверов, дескать, чтобы нельзя было превратить слабую модель в топовую. Но это звучит, как бред. Это звучит совершенно нормально. Грубо говоря, вся линейка делается по одной технологии. Конечно, есть выбраковка, отключение нестабильно работающих блоков и т. д. Но все-равно, различия топовых и массовых устройств отличаются незначительно. Маркетологи же хотят максимально широкую линейку по производительности. При этом портить устройства следует особым образом, сохраняя высокую работоспособность на базовых операциях и т. д. Проще всего это делать именно в драйвере. Т.е., во-первых, реально топовая нвидия отличается от нетоповой только идентификатором (в некоторых случаях)? Во-вторых, разве много пользователей будут этим заниматься, даже при возможности?
Re: Замена x.org
On 16.01.2017 03:12, Max Dmitrichenko wrote: Зачем вам переключалка? Переключалка подразумевает, что вы должны помнить, какой у вас язык сейчас. То есть модальность. Модальность в интерфейсе - это грех. Много лет назад мучился с этой проблемой, пока не понял, что виндоус привил вредную привычку. Лучше, когда у вас включалка на каждую раскладку. У меня caps lock на английский, shift+caps lock на русский. И я просто на автомате переключаясь на другое окно включаю ту раскладку, на которой буду писать. Чего и вам рекомендую. Весьма разумно. Пожалуй, так и сделаю, хотя и придётся менять привычку, потому что если более двух языков, переключалка уже становится неудобной. Но на Windows тоже придётся делать подобное. 15 Янв 2017 г. 11:35 пользователь "Артём Н." mailto:artio...@yandex.ru>> написал: Надоело патчить x.org <http://x.org> для того, чтобы переключать раскладку по ctrl+shift и ловить проблемы с нерабочими патчами. Баг висит с 2004-го года, постоянно к нему добавляют патчики, но они просто наплевали на то, что их софт не совместим с соглашениями, которые являются стандартом де факто: https://bugs.freedesktop.org/show_bug.cgi?id=865 <https://bugs.freedesktop.org/show_bug.cgi?id=865> Отсюда вопрос: на что заменить X.org и насколько это поддерживается (и насколько поддерживают драйвера nvidia)? Слышал про wayland. Может у кого-нибудь есть опыт?
Re: Замена x.org
On 17.01.2017 19:30, dimas wrote: 2017-015 22:04 Egorov N.V. wrote: Настройка переключения в консоли и в графике никак не связана. Если используешь графический терминал, то используется переключатель X.org. ну, у меня вот все настроено через /etc/default/keyboard, или как там его. в графике (хфсе) ничего не настраивал и вообще никогда не трогал. все работает одинаково (переключается заданными кнопками, при русской раскладке горит scroll lock) что в tty, что в иксах. У меня также и конфига иксов давным давно уже нет.
Re: Замена x.org
On 15.01.2017 12:54, Egorov N.V. wrote: В Sun, 15 Jan 2017 11:26:50 +0300 Артём Н. пишет: Надоело патчить x.org для того, чтобы переключать раскладку по ctrl+shift и ловить проблемы с нерабочими патчами. Баг висит с 2004-го года, постоянно к нему добавляют патчики, но они просто наплевали на то, что их софт не совместим с соглашениями, которые являются стандартом де факто: https://bugs.freedesktop.org/show_bug.cgi?id=865 Вроде как там расписано что бага так просто не фиксится, и нужно сильно корежить протокол чтобы оно работало нормально более чем с двумя раскладками... Да, я в курсе, однако патчи, временно это исправляющие есть. К тому же, не фиксится "просто так", с 2004-го года? Просто не хотят. Отсюда вопрос: на что заменить X.org и насколько это поддерживается (и насколько поддерживают драйвера nvidia)? Слышал про wayland. Может у кого-нибудь есть опыт? Я слышал что у Волонда проблемы с некоторыми программами из-за частичной поддержки X протокола. Например, какие? В ubuntu его используют, вроде. Или какое-то время он штатным был, пока они там своё не стали разрабатывать. ИМХО есть три варианта: 1. Использовать альтернативный клавиатурный метод ввода IME (это больше про азатские языки, но можно и кирелические символы) Несколько похоже на изврат: японский мне сейчас не нужен, но некоторое представление имею об этой "альтернативе". Вполне глючно и не особенно удобно. 2. Настроить xneur Выключить переключалку в X-ах и передать в ведение xneur, а с консолькой подмудрить (давно не настраивал)? 3.Отказаться от Ctrl + Shift в качестве переключателя (который даже в Windows не по умолчанию) и пересесть на другой переключатель. К примеру на правый ctrl, который не задействован практически у всех. Возможный вариант, но я привык к ctrl+shift, кроме того, при постоянных переходах между windows и Linux, начинаешь путаться. P.S. Если удастся пересесть на Wayland, хотелось бы почитать как это удалось и какие проблемы! Угу, мне бы тоже хотелось. На себе я уже опробовал переход с jessie на текущий testing (решил обновить компилятор для поддержки C++14). Не собирались дрова и ядро, буквально на днях починил. Если перейду, отпишусь, но пока сомневаюсь ещё.
Re: Замена x.org
On 15.01.2017 11:41, Дмитрий Фёдоров wrote: 15 января 2017 г., 15:26 пользователь Артём Н. написал: Надоело патчить x.org для того, чтобы переключать раскладку по ctrl+shift что их софт не совместим с соглашениями, которые являются стандартом де факто: Это не стандарт, это просто мастдайство. Так что правильно делают, что не поддерживают. "Мастдайство" - действия по отпусканию модификатора, а не по его нажатию? Отсюда вопрос: на что заменить X.org На винду. Интересуют конструктивные комментарии.
Замена x.org
Надоело патчить x.org для того, чтобы переключать раскладку по ctrl+shift и ловить проблемы с нерабочими патчами. Баг висит с 2004-го года, постоянно к нему добавляют патчики, но они просто наплевали на то, что их софт не совместим с соглашениями, которые являются стандартом де факто: https://bugs.freedesktop.org/show_bug.cgi?id=865 Отсюда вопрос: на что заменить X.org и насколько это поддерживается (и насколько поддерживают драйвера nvidia)? Слышал про wayland. Может у кого-нибудь есть опыт?
Не работает камера после обновления
Bus 002 Device 003: ID 0c45:6341 Microdia Defender G-Lens 2577 HD720p Camera Обновился до testing. На ядре 3.x всё работало. Сейчас какая-то фигня с uvcvideo: [35406.141777] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:6341) [35406.155260] uvcvideo 2-1.2:1.0: Entity type for entity Extension 4 was not initialized! [35406.155263] uvcvideo 2-1.2:1.0: Entity type for entity Processing 3 was not initialized! [35406.155265] uvcvideo 2-1.2:1.0: Entity type for entity Camera 1 was not initialized! [35406.155443] input: USB 2.0 Camera as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input29 Как это починить?
Re: Криптовечеринка в Москве
Жаль, у меня не получилось приехать. :-(
Re: Стабильная система?
On 17.10.2015 22:21, Dmitrii Kashin wrote: "Артём Н." writes: On 16.10.2015 16:46, Artem Chuprina wrote: Артём Н. -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 16:04:15 +0300: АН> Хосспади, OCaml... o.O АН> Может, когда требуется "большой кусок в императивном стиле", АН> следует отказаться от использования функционального языка в сторону императивного? АН> Или религия не позволяет? ;-) А смысл, если есть язык, который это позволяет прямо тут? Ocaml, насколько я понимаю, ничем не плох. "Большой кусок в императивном стиле" может иметь разный размер. Смысл в том, чтобы молотком забивать гвозди, а под микроскопом рассматривать нечто под увеличением. Конечно, возможно на молоток линзу приделать, но зачем? Артём, всё в толк не возьму: Вы что сказать-то хотели? Для чего использовать инструмент, не ориентированный на данную задачу? Возможно конечно пытаться "задать порядок выполнения" в функциональном языке, а возможно использовать императивный для "императивного" куска и не городить огород (к тому же, если код уже фактически написан). Почему просто не выделить в отдельный проект?
Re: Стабильная система?
On 16.10.2015 16:46, Artem Chuprina wrote: Артём Н. -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 16:04:15 +0300: АН> Хосспади, OCaml... o.O АН> Может, когда требуется "большой кусок в императивном стиле", АН> следует отказаться от использования функционального языка в сторону императивного? АН> Или религия не позволяет? ;-) А смысл, если есть язык, который это позволяет прямо тут? Ocaml, насколько я понимаю, ничем не плох. "Большой кусок в императивном стиле" может иметь разный размер. Смысл в том, чтобы молотком забивать гвозди, а под микроскопом рассматривать нечто под увеличением. Конечно, возможно на молоток линзу приделать, но зачем?
Re: Криптовечеринка в Москве
On 15.10.2015 22:01, Dmitrii Kashin wrote: Собственно, а почему бы нам не организовать небольшое мероприятие? Я бы предложил посидеть в Брудере на Бутырской (ст. м. Савёловская)[1], можно хорошо покушать, выпить пива/чаю, ну и конечно же, подписать друг другу ключи. В Москве сейчас живу и работаю. Короче, всегда готов. Думаю, вечер пятницы -- очень хорошее время. Какой именно, сейчас и разберёмся. Может быть, есть желающие присоединиться, познакомиться, пообщаться? Давайте обсудим! :) [1] http://butirskaya.beerbruder.ru/gallery/ Ключа нет и вроде не особо нужен, пока что. Но пожрать я не против. :-) В Москву переезжаю через неделю-две. P.S.: Подписать ключи "на Бутырской", навевает интересные ассоциации. ;-)
Re: Стабильная система?
Хосспади, OCaml... o.O Может, когда требуется "большой кусок в императивном стиле", следует отказаться от использования функционального языка в сторону императивного? Или религия не позволяет? ;-) On 15.10.2015 21:02, Dmitrii Kashin wrote: 1) Позволяет более просто комбинировать функциональное и императивное программирование: не надо изворачиваться монадами, чтобы добиться последовательного выполнения команд. Но зачем? "This is no matter of religion or esthetics; a priori neither style is prettier or holier than the other. On the contrary, one style may be more adequate than the other depending on the problem to be solved. The first rule to apply is the rule of simplicity. Whether the algorithm to use implemented is written in a book, or whether its seed is in the mind of the programmer, the algorithm is itself described in a certain style. It is natural to use the same style when implementing it. The second criterion of choice is the efficiency of the program. One may say that an imperative program (if well written) is more efficient that its functional analogue, but in very many cases the difference is not enough to justify complicating the code to adopt an imperative style where the functional style would be natural". [1] Бывает, что императивное программирование разумнее. Большинство алгоритмов можно писать в функциональном стиле, но бывает и так, что это порождает большой оверхед в производительности. При столкновении с подобным "узким горлом" приходится реализовывать часть функционала в императивном стиле. Например, управление большими словарями много выгоднее, если они мутабельны. [1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html
Re: Стабильная система?
Ok, если оффтоп, так полный. On 07.10.2015 02:07, Dmitrii Kashin wrote: Artem Chuprina writes: Артём Н. -> debian-russian@lists.debian.org @ Mon, 28 Sep 2015 10:37:48 +0300: АН> Offtopic: АН> А что кто-то реально использует Haskell? Да. И на данный момент я его считаю лучшим вариантом по соотношению затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от конкурентов. Я хотел бы высказать сомнение в большом отрыве Haskell от Ocaml. Последний видится мне весьма живым проектом. За время работы с ним меня приятно удивило после Haskell: 1) Позволяет более просто комбинировать функциональное и императивное программирование: не надо изворачиваться монадами, чтобы добиться последовательного выполнения команд. Но зачем? 2) Позволяет таки определять полиморфные функции. Да, это нарушение системы типов, но если этим не злоупотреблять, то это даже удобно. Я в своё время с Вашей подачи пытался взять Haskell наскоком. Увы, он меня расстроил по целому ряду причин. Если хотите, могу рассказать. Короче, тут сплошные функциональщики, я себя ощущаю неполноценным C-шником. :-) Знаю, что :[|||]:, но: '— Ты функциональщик! - прокричал Сергей на весь оупен-спейс-рум номер 14. Комната притихла в ожидании развязки. — Я видел, как ты вчера вечером каррировал и декаррировал прямо за рабочим компьютером! Неодобрительный ропот и возгласы удивления прокатились по комнате. Кто-то громким шепотом сказал "какой ужас, а я с ним за руку здоровался". — Знаешь что, Сергей, — сказал Денис, вставая из-за рабочего стола, — любой нормальный мужчина, если у него всё в порядке, может позволить себе позаниматься функциональным программированием. Это естественно. Каждый хотя бы раз, да пробовал. Зачем только об этом кричать на всю комнату? Я же не кричу, что ты объектно-ориентированный! Девушки захихикали, кто-то снова громко пробормотал "ну надо же, а по нему и не скажешь". Присутствовавший при этом Игорь Матвеевич сильнее вжался в кресло. Только бы никто не узнал про его процедурные наклонности!' %-)
Re: iceweasel
On 02.10.2015 21:08, Ivan Petrov wrote: При попытке сделать aptitude update : ... Игнор http://ppa.launchpad.net oneiric/main Translation-ru_RU Игнор http://ppa.launchpad.net oneiric/main Translation-ru Игнор http://ppa.launchpad.net oneiric/main Translation-en Попробуйте временно репозиторию приоритет выше, чем основной выставить (в /etc/apt/preferences сделайте у debian приоритет 90, а приоритет убунты 900). После aptitude update будет ли требовать обновить кучу пакетов на убунтовские? Ничего устанавливать, естественно нельзя, иначе систему развалите, только update сделайте, проверьте, затем верните приоритеты обратно и снова сделайте update. Если нет, создайте /etc/apt/sources.list.d/ubuntu.list со следующим содержанием: # # Ubuntu Main Repos # deb http://archive.ubuntu.com/ubuntu/ utopic main restricted universe multiverse deb-src http://archive.ubuntu.com/ubuntu/ utopic main restricted universe multiverse # # Ubuntu Partner Repo # deb http://archive.canonical.com/ubuntu utopic partner deb-src http://archive.canonical.com/ubuntu utopic partner # # Ubuntu Extras Repo # deb http://extras.ubuntu.com/ubuntu utopic main deb-src http://extras.ubuntu.com/ubuntu utopic main # # Contrib. # #deb http://packages.ubuntu.com/precise utopic main non-free contrib #deb-src http://packages.ubuntu.com/precise utopic main non-free contrib Не забудьте вернуть обратно приоритет.
Re: iceweasel
On 02.10.2015 23:33, Федот Куракин wrote: Самый правильный способ получить фокса: http://mozilla.debian.net/ И ещё, единственно верный и "самый правильный" способ вы могли бы заметить закомментированным в моём firefox.list, который я сюда скинул. Я не помню почему он мне не понравился. Но подозреваю, что iceweasel там не отличается от того, который в основном репозитории.
Re: iceweasel
On 02.10.2015 23:33, Федот Куракин wrote: Самый правильный способ получить фокса: http://mozilla.debian.net/ И есть разница между тем, что в репозитории?
Re: iceweasel
On 02.10.2015 16:27, Andrey Tataranovich wrote: On Fri, 02 Oct 2015 16:16:55 +0300 "Артём Н." wrote: * периодически не играет html5 видео на youtube.com 1. Старый флеш-плеер. 2. Кодеки выдернуты (H. какой-то там, потому не играет HTML5). Обе догадки неверные, достаточно несколько раз перезапустить браузер и начнет работать тот же ролик. Странно. Но кодек, я точно помню, они выкидывали.
Re: iceweasel
Потому что туда сядет какой-нибудь вирус или троян. Кстати, не соглашусь. Это как правило возможно только если атака целевая. Но если она целевая, способ всегда найдётся.
Re: iceweasel
On 02.10.2015 13:59, Руслан Коротаев wrote: В сообщении от [Чт 2015-10-01 18:25 +0300] "Артём Н." пишет: Да выкиньте вы этот криво собранный Iceweasel и поставьте firefox. Я задолбался бороться с их "оригинальной" сборкой, соответствующей "духу свободы". Пересобирать самому со включенными кодеками мне не захотелось и я просто стал использовать оригинальный firefox, чего и вам желаю: deb http://ppa.launchpad.net/mozillateam/firefox-next/ubuntu trusty main Это для Jessie, для wheezy используйте oneiric. А почему вы используете firefox из убунтовского репозитория (у них своя сборка?), когда можно скачать его с официального сайта, он же идет уже скомпилированным? А так проще: уже готовый репозиторий и пакет, по путям совместимый с Debian. Можно растарить в каталог ~/bin и дать ссылку на файл firefox. Удобно тем, что браузер обновляется автоматически с правами пользователя, соответственно не надо настраивать sudo, автообновления и прочее. Безопасный серфинг и свежий браузер — большинству пользователей этого вполне достаточно. Да ну. Пусть лучше будет системным. Каких-либо серьёзных зависимостей из убунты я не тяну.
Re: iceweasel
Ставить файрфокс с официального сайта вполне можно. Но не с правами пользователя. Лучше пожертвовать автоматическими обновлениями (хотя я думаю, что придумать способ автоматизировать обновления так, чтобы при этом при нормальной работе пользователя не возникало риска - можно). Кстати, в случае с убунтовским репозиторием, жертвовать ничем не придётся.
Re: iceweasel
On 02.10.2015 15:12, Руслан Коротаев wrote: Но, большинство пользователей (сисадминов не считаем), избегает debian потому что считает что там «устаревший софт», и в большинстве случаев кроме браузера они ничего устаревавшего назвать не могут. Поэтому мое предложение установить firefox c официального сайта, можно считать компромиссом между безопасностью и удобством. Выбор остается за пользователем. Собственно, я так и не понял, что плохого в использовании Debian и установке отдельных прикладных программ (в частности firefox) из репозиториев Ubuntu.
Re: iceweasel
On 02.10.2015 09:42, Andrey Tataranovich wrote: On Thu, 01 Oct 2015 22:52:25 +0300 Oleksandr Gavenko wrote: On 2015-10-01, Артём Н. wrote: Да выкиньте вы этот криво собранный Iceweasel и поставьте firefox. Я задолбался бороться с их "оригинальной" сборкой, соответствующей "духу свободы". И что там плохо? * периодически не играет html5 видео на youtube.com * не печатает страницу, если ее заголовок слишком длинный или отсутствует (Debian bug #792782, Mozilla Bug #1185236) Последний баг точно есть в расово верном firefox, насчет первого - возможно и дебьяновцы что-то отломали. 1. Старый флеш-плеер. 2. Кодеки выдернуты (H. какой-то там, потому не играет HTML5).
Re: Стабильная система?
Как измеряется надёжность? Количеством, гм, ВНЕЗАПНЫХ глюков в единицу времени. Если серьёзно говорить об измерении, это не является показателем. не исключена просто логическая ошибка в алгоритме, которую без тестов вы не сможете отловить (да знаю, это очевидно). Ну да, естественно. Вот это как раз обычно лечится ручным прогоном. Либо вы несколько противоречите сами себе, либо кода не так много. В таком случае, чтобы проверить все пути выполнения, вам надо выполнить столько же операций, сколько выполнят тесты. Только вручную. Кстати, в оригинальном приборе (который стоит в реальных вертолетах) таки благополучно перепутали в одном месте плюс с минусом, и отловлено это было (мной) на стенде при ручном прогоне. Фактически, в данном случае стенд являлся тестом для реальной системы, а реальная система тестом для стенда. Тесты, кстати, могли и не поймать - написать тест, который это ловит, весьма нетривиально. И вручную, простым прогоном без дополнительных данных, я так понимаю, вы тоже не поймали ошибку? Вообще мне приходилось работать в режиме TDD, когда я не знал про хаскель. Там, собственно, я и узнал на практике, что прекрасная в теории идея TDD на практике выражается в квадратичном количестве тестов и многочасовом их прогоне. Да, я тоже это знаю. Ну, по факту, странный "спор". По-моему, вы сами прекрасно знаете, что без тестов никогда нельзя гарантированно сказать, что система не работает на некотором подмножестве случаев после её изменения. И тесты нужны. Хотя писать их лень и оверхед. Позже, уже в Транзасе, мне коллеги рассказывали, что они изначально тоже писали тесты, и автоматически прогоняли их каждое утро, когда приходили на работу и запускали smalltalk. Профессиональных параноиков среди низ не было, с количеством тестов они не перенапрягались, но все равно через несколько месяцев прогон тестов стал занимать столько времени, что был отключен. Может проблема в Smalltalk? Я представил себя на месте пилота (если это не тренажёр). Наверное, если бы летал я, для себя я бы не стал отключать тесты... Да, и может проблема не в тестах? Если изменяется кусок, который сильно изолирован, так ли часто надо прогонять _все_ тесты? Благодаря иммутабельности блокировки надо делать не на каждый чих, а только при _явной_ операции записи, которых в иммутабельной парадигме немного. Всё-таки принципиально ничего не меняется, и для записи они нужны... Но да, согласен, мало - меньший оверхед и меньше вероятность получить побочный эффект. Выше изоляция - лучше, мне тоже нравится (а многопоточность нравится не особенно по сравнению с многопроцессностью). >> В смысле, человека берут решать сложную >> задачу, а на чем он ее решает - это уже его личное дело. >> Задача сложная, "программист на XXX" ее не решит. АН> Как правило, всё-таки декларируют определённый язык. АН> Решите вы задачу и уйдёте. АН> А кто будет поддерживать ваш код затем? Поскольку задача сложная, то поддерживать будет человек со сравнимым интеллектом. Собственно, я не единственный сотрудник Транзаса, способный поддерживать код на хаскеле. Но есть ещё "умение разбираться в чужом коде". Хотя, в данном случае, наверное Хаскелю будет плюс, в целом. Сложно найти людей, которые с ним работают, чтобы поручить им поддерживать кусочки задачи (не думаю, что интеллект измеряется знанием или незнанием Haskell, я вот его не знаю, так что, я автоматически попадаю у вас в категорию "тупой"?). Человеку со сравнимым интеллектом будет дешевле выучить хаскель и разобраться в хаскельном коде, чем разобраться в коде того же назначения, написанном на C++, который он, предположим, уже знает. Вероятно. Это зависит от того, кем, как и с какой целью так написан C++ код. Есть C++ код, в некоторой степени написанный для того, чтобы показать "какая крутая у меня квалификация". А если учитывать, что "поддерживать" часто начинается с "рефакторить", то тут преимущество хаскеля с его "как только после рефакторинга скомпилировалось, то почти наверняка работает правильно" становится заметным. Странная поддержка... Если задача простая, то ситуация, разумеется, иная. На C++ любую задачу возможно решить сложно. Я пробовал, довольно много. ООП как парадигма - это duck typing Да не обязательно. Это выражение больше напоминает Python. И всё вытекающее: нестрогую типизации прежде всего, прототипное "наследование" и т.п.. следствие, вышеупомянутое квадратичное количество тестов. Собственно, это оно у хорошо примененной ООП квадратичное, у спагетти-кода оно экспоненциальное. И на хаскеле возможно так написать. :-\ А вот функциональная парадигма с богатой системой типов позволяет поднять удерживаемый в голове уровень сложности задачи на следующую ступень. Разве не проще оперировать объектами в терминах какого-нибудь DSL? Ещё тут рядом на Erlang пытались что-то делать, не пошло. Некому это поддерживать. Просто людей не найти, кто станет на этом писать. У меня коллега уехал в Швецию как раз на позицию, где был нужен Erlang. Идет
Re: Стабильная система?
On 01.10.2015 19:39, Artem Chuprina wrote: Артём Н. -> debian-russian@lists.debian.org @ Thu, 01 Oct 2015 18:36:54 +0300: >> >> АН> Offtopic: >> >> АН> А что кто-то реально использует Haskell? >> >> >> >> Да. И на данный момент я его считаю лучшим вариантом по соотношению >> >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от >> >> конкурентов. >> >> >> АН> А, если не секрет, для разработки чего и, что важно, кем, а также для кого? >> >> В одном месте это часть разработки авиационных тренажеров. АН> "Сухой" или МАНС? Транзас-Авиация. А, не слышал. Посмотрел. Интересная компания. >> Приходится много рефакторить, когда выясняется, что вот тут он ведет >> себя совсем не так, как мы раньше думали. Хаскель спасает от дилеммы >> "много молиться или писать тестов в разы больше, чем работающего кода". >> АН> Каким образом спасает? АН> Разве для ФП не требуются тесты? АН> В чём отличия. В том, что для достижения того же (высокого) уровня уверенности в работоспособности кода тестов требуется на порядок меньше. Не квадрат от размера кода, а линейно. Из-за отсутствия зависимостей и состояния функций? А для достижения приемлемого уровня уверенности можно вообще без тестов жить. У меня в том проекте за три года работы и минимум трех крупных рефакторингах раза три-четыре вылезали ошибки типа "перепутал ветки then и else" или "перепутал плюс с минусом". Остальное ловилось системой типов на стадии компиляции и изредка - первым же ручным прогоном того места, где менялась функциональность. Тестов у хреновины нет вообще. Хреновина при этом оказывается одним из самых надежных мест в тренажере. Как измеряется надёжность? Тестов там вообще почти нет, надо сказать. Потому что работать они начинают тогда, когда их квадрат от размера кода, а кода в проекте много. По-моему, TDD не зависит от языка и парадигмы (не использую, но есть, кто использует). Если нет тестов, сложно проверить корректность изменений. Т.е., надёжность здесь просто словесная характеристика, а не показатель: "раза три-четыре вылезали ошибки типа "перепутал ветки then и else" или "перепутал плюс с минусом"", - не исключена просто логическая ошибка в алгоритме, которую без тестов вы не сможете отловить (да знаю, это очевидно). АН> и скорость выполнения всё-таки ниже C++ (но это не всегда минус). У меня есть знакомый программист, который мерил. Зачастую сборка ghc превосходит по скорости C, а C++ (если на нем пишут как на плюсах, а не чисто как на C с чуть более удобным синтаксисом) так и как правило (вероятно, потому что если писать как на плюсах, то будет довольно много выделений памяти, которые по умолчанию защищены мутексами, а также из-за неоптимизируемых разыменований виртуальных функций). В Глазго оптимизировать тоже умеют, а иммутабельность и статическая типизация открывают куда более широкие возможности для оптимизации. Это он писал обработку мощного потока информации, на плюсах на имевшейся технике уже требовавшую ручного тюнинга параллелизации. Для определённых задач, согласен. Только это не Хаскелл, а парадигма. Однако я не совсем понимаю: там всё-равно там есть данные... Пусть, надо что-то записать, как обойтись без блокировок вообще? >> Непосредственный заказчик - работодатель, а потребитель тренажера и >> критик, если что-то работает не так, как в настоящей машине - летчик. >> Это ответ на вопрос "для кого". >> АН> Вопрос был к тому, что вакансий на Haskell я не видел. Так на Haskell не индусы пишут. Кстати, индусы тоже пишут: они разные бывают. :-) В смысле, человека берут решать сложную задачу, а на чем он ее решает - это уже его личное дело. Задача сложная, "программист на XXX" ее не решит. Как правило, всё-таки декларируют определённый язык. Решите вы задачу и уйдёте. А кто будет поддерживать ваш код затем? И я, когда ищу себе работу, тоже не ищу вакансии "программиста на YYY". Потому что это вакансии для негров, у меня тупая монотонная работа плохо получается. У меня тоже, я заметил. Я ищу вакансии разработчика ПО, где надо думать головой. Это не обязательно работа на Haskell. >> В другом месте веб-сервер, встраивающийся в существующий и без того >> нетривиальный бизнес-процесс, и добавляющий еще своей нетривиальности. >> Попытка сделать его на рельсах мне не понравилась - трогать страшно, >> сейчас переписываю на yesod. >> АН> Любопытно уже хотя бы то, что он не умер и не остался эзотерическим языком, АН> а вполне стабильно обрастает инфраструктурой... АН> Плотно ФП руки не доходили заняться (на началах Lisp, это всё и закончилось). В мире довольно много людей с развитым аб
