В snapd (https://github.com/snapcore/snapd), инструментарии для управления самодостаточными пакетами в формате snap, выявлена (https://shenaniganslabs.io/2019/02/13/Dirty-Sock.html) уязвимость (CVE-2019-7304 (https://security-tracker.debian.org/tracker/CVE-2019-7304)), позволяющая непривилегированному пользователю получить права администратора (root) в системе. Для проверки систем на наличие уязвимости опубликовано (https://github.com/initstring/dirty_sock/) два прототипа эксплоита - первый позволяет завести нового пользователя в системе, а второй даёт возможность установить любой snap-пакет и запустить код с правами root (через установку пакета в режиме "devmode" с прикреплением обработчика, вызываемого при установке с привилегиями root).Уявимость вызвана (https://bugs.launchpad.net/snapd/+bug/1813365) отсутствием в snapd должных проверок при обработке адреса внешнего сокета в процессе оценки прав доступа для Unix-сокетов. В частности, при обработке запросов к API через Unix-сокет проверяется ассоциированный с соединением UID пользователя и на основании его принимается решение о предоставлении доступа. Пользователь может прикрепить к имени файла с сокетом строку ";uid=0;" и код парсинга параметров в snapd использует её для определения идентификатора пользователя. Локальный атакующий может использовать данную ошибку для доступа через сокет /run/snapd.socket к привилегированным API snapd и получения полномочий администратора (в вышеупомянутых эксплоитах используется обращение к API v2/create-user и /v2/snaps).
Проблема проявляется в версиях snapd с 2.28 по 2.37 и затрагивает все поддерживаемые ветки дистрибутива Ubuntu (с 14.04 по 18.10), в котором начиная с Ubuntu 18.04 поддержка snap предлагается по умолчанию. Проблема также затрагивает дистрибутивы Fedora (https://bodhi.fedoraproject.org/updates/?releases=F29&type=s...), Debian, в которых snapd предлагается из штатных репозиториев. Уязвимость устранена (https://bugs.launchpad.net/snapd/+bug/1813365) в выпуске snapd 2.37.1, а также в обновлениях пакетов для дистрибутивов Ubuntu (https://security-tracker.debian.org/tracker/CVE-2019-7304) и Debian (https://security-tracker.debian.org/tracker/CVE-2019-7304).
URL: https://shenaniganslabs.io/2019/02/13/Dirty-Sock.html
Новость: https://www.opennet.me/opennews/art.shtml?num=50141
Как же классно пользоваться Rolling дистрибутивом, новость что уязвимость устранена в версии 2.37.1, смотрю, а в системе уже стоит 2.37.2
Не пользоваться snapd тоже классно, новость что уязвимость в snapd... А пофигу.
А если вообще ПК не пользоваться, то даже Spectre становится нестрашен.
неоднозначно, т.к. есть ПК без Spectre
А ещё есть компьютеры без Линукс.
И без Windows тоже бывают. И что?
> И без Windows тоже бывают. И что?Раз уж человек так просил, упомяну: http://wiki.opennet.ru/NoWindows :)
Вообще, спор не о чём, даже если у тебя нет компьютера, данные о тебе обрабатываются где-то на компьютере...
не понятно, каких утверждений производителя, так-то ноутов уже в землю зарытых было не мало
Да он на ПК и так не страшен. Это ж не сервер с кучей виртуалок, которые друг от друга изолировать надо
так пользоваться-то я буду. Ты, главное, не торопись его сносить (заботливо установленный убунточкой, даже если нахрен тебе не нужен)!
К сожаленью, livepatch к примеру работает только через snap. Или если кто знает как организовать это без snap, объясните, как.
Сильно оно вообще на роллингах надо? Виделись мне они всегда костылем по доставке свежачка в релизоцикличных дистрибутивах.
Роллинг ещё и на качество влияет положительно, т.к. можно видеть регресс между версиями, и быстро фиксить, а не ждать десяток релизов, а потом пытаться понять, когда же оно начало глючить, в последней версии, или в более ранних? Программисты из этих же соображений быстро пушат код в репы, как только он готов
Вопрос был про какую-никакую пользу снэпофлэтов в роллингах все же, а не роллинги vs релизоциклы.
Ставить софт, жестко зависящий от чего-то древнего разве что. В основном проприетарь. Ну и просто чтобы не тянуть эту проприетарь (в основном чтобы не мешалась, с изоляцией у них не все ок сейчас)
> Ну и просто чтобы не тянуть эту проприетарь (в основном чтобы
> не мешалась, с изоляцией у них не все ок сейчас)Ну так голые namespaces -- это вовсе не полный openvz :(
>> Ну и просто чтобы не тянуть эту проприетарь (в основном чтобы
>> не мешалась, с изоляцией у них не все ок сейчас)
> Ну так голые namespaces -- это вовсе не полный openvz :(так там даже до этого не доходит, у 90% пакетов прямо и открыто r/w в ~, после чего о чем-то более серьезном говорить сложно
Ну админам локалхоста обычно и заняться то нечем как правило.. только за роллингом и наблюдать...
Ну так роллинг для десктопчика удобнее всего как раз. Релизоциклизм остро просит снэпофлетокостылей в десктоп раскладе.
Но чет лень снова лекции читать о ролях машин, историю возникновения модели релизоциклов и почему многим десктопоюзерам (но далеко не всем) или девопсикам в оной модели неуютно. А для админов линуксоинфраструктур манна небесная и изначально под их потребности создавалось, впрочем.
Альтернатива - выбираешь то, что устраивает по функциональности и безглючности, и сидишь на нём много лет (да ещё и с обновлениями безопасности) - ещё лучше. А меняешь только тогда, когда есть реальная потребность.
sudo apt purge snapd - один из первых пургов которые делаю после установки системы.)
Лишаете себя кучи софта, которого нет через механизм репо, и всё!
Про "кучу" это вы верно подметили. А если нужен какоё-то софт, которого нет в репах, его можно просто собрать. И опакетить, чтобы не превращать систему в раннюю Слакварь (при всём уважении).
Вопрос с обновлениями: если в программе найдут серьезную дыру, а ты об этом не узнаешь и не обновишь?
Большинство разработчиков предоставляют репозитории deb/flatpak/snapd и наверное все же правильно ими пользоваться.
в абсолютном большинстве случаев десктопному софту дыры не критичны. Тем более тому, что в репах нет - это обычно какая-то экзотика.
>Вопрос с обновлениями: если в программе найдут серьезную дыру, а ты об этом не узнаешь и не обновишь?Ну да, какой ужас, надо теперь совсем запретить отключать обновления. Вэйт, ох щи..
Могу согласиться, но частично. Если программа - дерьмо, то в упакованном в snap виде оно дерьмом и останется. Из последнего - snap Nextcloud для Ubuntu Server 18.04 (тоже, кстати, дерьмо порядочное с поломанным всем, что можно было сломать).
> его можно просто собрать.Действительно. Зачем snap, если можно стоя и в гамаке.
Костыли оказались не просто костылями, а ещё и написанными индусами, не умеющими банально экранировать данные. Вот ведь удивительно.
Что это за язык программирования, где берется последнее совпадение? Строка в любом регэкспе читается слева направо и после первого совпадения проверка заканчивается
В новости есть ссылка на исходник. Язык Go, но не имеет отношения к проблеме, там сделана цикличная проверка опций, и в итоге возможно переопределение уже ранее заданных значений.
У утилит командной строки, например, очень часто выходит так, что самая важная опция -- последняя.> Что это за язык программирования, где берется последнее совпадение?
На чём там принято писать утилиты командной строки?
> У утилит командной строки, например, очень часто выходит так, что самая важная опция -- последняя.И, если подумать, как работает парсинг? Правильно, читается слева на право, в результате, последняя опция остается... последней.
>> У утилит командной строки, например, очень часто выходит так, что самая важная опция -- последняя.
> И, если подумать, как работает парсинг? Правильно, читается слева на право, в
> результате, последняя опция остается... последней.Да ладно, не может быть. Настоящие мужики используют обратную грамматику и парсят с конца. С начала парсят только лошки всякие да скрипткиддисы, у которых интеллекта недостаточно, чтобы обратить грамматику.
apt purge snap*
Ерунду эту
Любителям понабегать в темы о дырках с гошечками, ржавчинкой, дотнетиками и прочим: мотайте на ус наконец, ложное чувство безопасности полезно бывает разве что атакующему.
Атакующий сделает атаку, пока ты не ввел sudo apt upgrade, ибо способ уже спалили широкой общественности. Такую атаку любой кали школьник сделает.
то есть ты думаешь, что эта последняя дырка в снап-де?
Откуда ты взял это ложное чувство безопасности? Ты можешь привести пример комментария, демонстрирующий это самое ложное чувство безопасности?Что за манера вообще приписывать оппонентам всякие ложные чувства, ради того, чтобы потом блестяще их побеждать?
> Откуда ты взял это ложное чувство безопасности?Из книжки Шнайера, вестимо.
> Ты можешь привести пример комментария
> демонстрирующий это самое ложное чувство безопасности?Да. Однако, лень копировать широкоизвестный труд классика для Вас.
> Однако, лень копировать широкоизвестный труд классика для Вас.И не стоит. Если примером такого чувства безопасности является труд Шнайера, то не стоит. Тут и так всё ясно.
>> Однако, лень копировать широкоизвестный труд классика для Вас.
> И не стоит. Если примером такого чувства безопасности является труд Шнайера, то
> не стоит. Тут и так всё ясно.Вот и ладненько. Если Вы не смекнули на какую часть книжки намёк, то доктрину АНБ обсуждать тем паче не стоит.
> обсуждать тем паче не стоит.Если тебе кажется, что здесь есть какое-либо обсуждение, то ты льстишь себе. У тебя нет аргументов, это видно любому мимопроходилу, даже несмотря на то, что ты встал в позу, подразумевающую, что они у тебя есть.
> это видно любому мимопроходилуне стоит говорить за всех, ок?
Обсуждение подразумевает наличие постоянной темы. Никто не просил привести аргументы. Ответ на заданный вопрос дан сразу же. Так что можно не проецировать позы. ;-)
Любой комментарий, осуждающий наличие уязвимости. Это демонстрирует полное непонимание человеком двух фактов:
1) В коде всегда есть ошибки. Часто исправление старых порождает появление новых. Это попросту человеческий фактор.
2) Ошибки порождают уязвимости
Непонимание этих фактов и является ложным чувством безопасности по определению.
> Любой комментарий, осуждающий наличие уязвимости.Уязвимость -- это плохо. Уязвимость надо осуждать. Разговоры о том, что уязвимости неизбежны -- это не оправдание. Точнее оправдание, в том смысле, что я готов согласиться с тем, что расстреливать программистов за уязвимости не стоит, поскольку уязвимости неизбежны. Мы просто останемся без программистов, если будем их расстреливать. Поэтому наказание должно быть мягче. Таким образом, неизбежность уязвимостей оправдывает программистов, но лишь отчасти.
> Это демонстрирует полное непонимание
> человеком двух фактов:
> 1) В коде всегда есть ошибки. Часто исправление старых порождает появление новых.
> Это попросту человеческий фактор.
> 2) Ошибки порождают уязвимостиПочему же? Вот я понимаю оба факта. И делаю из него единственно-возможный вывод, что человеческий фактор надо исключать из программирования. Его невозможно исключить полностью, но отчасти его исключить возможно. Это делается посредством выбора инструментов и организации процесса написания и приёмки кода.
> Непонимание этих фактов и является ложным чувством безопасности по определению.
Но мне кажется, что непониманием этих фактов грешат больше апологеты C и C++, которые предлагают стратегию борьбы с ошибками, сводящуюся к тому, что надо нанимать квалифицированных программистов. Не, квалифицированные программисты -- это хорошо, но квалифицированный программист отличается от неквалифицированного только тем, что ошибки квалифицированного обходятся в большие суммы денег.
>Разговоры о том, что уязвимости неизбежны -- это не оправданиеВоля человека равносильна уязвимости. Говорят, создать идеальный мир - утопия, а по мне, утопия - убить волю человека. Убей волю человека и ты создашь идеальный мир (ц) (да, да, этот мир будет похож на программу без уязъвимостей, роботы)
>что человеческий фактор надо исключать из программирования
значить программы должны писать те же программы, предложением выше про утопию. А что в итоге мы имеем? Как и говорил ранее, человек придумал программы переводящие с одного языка в другой, но так и не придумал ничего подобного, когда программа сама пишет другую программу.
>Это делается посредством выбора инструментов и организации процесса написания и приёмки кода.
А сами инструменты какими средствами (инструментами) делать нужно? порочный круг, а вы как думаете?
>Но мне кажется, что непониманием этих фактов грешат больше апологеты C и C++, которые предлагают стратегию борьбы с ошибками, сводящуюся к тому, что надо нанимать квалифицированных программистов.
Стандарты программирования и всякие секурные кодинг гайды, их тоже нужно проверять на уязвимости (проверка на непротиворечивость)
>что ошибки квалифицированного обходятся в большие суммы денег.
опять всему мерило - бабло, хммммм
>>что человеческий фактор надо исключать из программирования
> значить программы должны писать те же программы, предложением выше про утопию. А
> что в итоге мы имеем? Как и говорил ранее, человек придумал
> программы переводящие с одного языка в другой, но так и не
> придумал ничего подобного, когда программа сама пишет другую программу.И что? Человек придумал ассемблеры, чтобы не считать адреса меток вручную, и не совершать при этом ошибок. Человек придумал типизацию, чтобы описывать свою программерскую задумку точнее, позволяя компилятору лучше проверять соответствие кода задумке. И человек продолжает придумывать всё больше и больше вещей, которые позволяют описать больше деталей своей задумки, и ошибки вылезают чаще и чаще. Хочешь я тебе ссылок накидаю на то, какие ошибки позволяет отлавливать rust?
Вот например.
https://medium.com/@sgrif/no-the-problem-isnt-bad-coder...Чувак любопытно описывает проблему, так что она выглядит проблемой с самого начала, но потом объясняет, почему когда код был написан, она не была проблемой. Код не был ошибочен, когда он был написан. Но когда изменились другие части программы, он стал ошибочным.
>>Но мне кажется, что непониманием этих фактов грешат больше апологеты C и C++, которые предлагают стратегию борьбы с ошибками, сводящуюся к тому, что надо нанимать квалифицированных программистов.
> Стандарты программирования и всякие секурные кодинг гайды, их тоже нужно проверять на
> уязвимости (проверка на непротиворечивость)Кодинг-гайды не панацея. Нет ни одного кодинг-гайда, который бы объяснил, как править код так, чтобы гарантированно не привнести ошибку. Единственный способ, который как мне кажется может сработать -- это писать программу с нуля, каждый раз когда надо внести туда изменение. Не менять программу, а менять ТЗ, и заново проходить через все этапы начиная с проектирования программы. Но это абсолютно непрактичный способ, если только мы не найдём способ автоматизировать эти этапы.
И развитие языков программирования идёт в сторону автоматизации этого процесса. Даже если мы посмотрим на C, мы увидим, что он развивается в сторону автоматизации этого процесса. Точнее развивался некоторое время, он уже застыл и дальше развиваться неспособен. C++ идёт дальше в этом направлении, но его развитие было сильно повреждено идеей "повторного использования кода", с которой программисты носились как с писаной торбой в 90-е и 00-е. То есть, в результате мы поняли фундаментальные ограничения идеи, что хорошо для нас, но C++'у от этого не легче.
>>Это делается посредством выбора инструментов и организации процесса написания и приёмки кода.
> А сами инструменты какими средствами (инструментами) делать нужно? порочный круг, а вы
> как думаете?Нет. Это теоретическое рассуждение, которое противоречит практике. Если бы оно было верно, то самые надёжными программами были бы те, что написаны на ассемблере. Но как мы видим, на практике ассемблер используют не для надёжности, а для экономии ресурсов, в первую очередь памяти. Код ядра специфичный для x86 (который гарантированно не будет выполняться на arm'ах, а значит ему не нужна кроссплатформенность C), написан почти весь целиком на C, на асме только то, что на C писать не удаётся.
Любопытно было бы ознакомиться с теоретической моделью, которая покажет, почему этот порочный круг не работает. А пока я не знаю такой теоретической модели, я отметаю этот порочный круг исходя из эмпирики. (что-то крутится в голове, связанное со сложностью по Колмогорову, но я не могу вспомнить)
Впрочем, я могу поделиться чисто практическим опытом, который наводит на мысль о том, как это работает. Точнее как этот порочный круг не работает. Мне периодически приходится обрабатывать данные, как правило это какая-нибудь табличка с кучей чисел. И я избегаю пользоваться калькулятором. Каждый раз когда мне надо что-то подобное провернуть, я либо лезу в *scratch* emacs'а, либо достаю текстовый процессор, либо запускаю R, либо сажусь писать программу на C или Rust (R на мой взгляд бредовое убожество из 80-х, который хорош лишь тем, что к нему есть куча готовых скриптов). Казалось бы, программу писать дольше, чем взять два столбца чисел, посчитать в каждой строчке разницу, возвести её в квадрат, и сложить эти квадраты, зачем писать программу? Я не задумывался об этом, пока мне не пришлось работать рука об руку с людьми далёкими от программирования, которые настаивали на использовании калькулятора, и даже пытались считать со мной наперегонки, чтобы показать, что калькулятор лучше.
Так зачем писать программу? Я понаблюдал за процессом, и я понял в чём дело. Дело даже не в том, что на калькуляторе надо выполнить больше действий и проще совершить ошибку -- не, это не всегда так, иногда отладка программы и обработка всех специальных случаев приводит к тому, что программу создавать дольше, чем просто посчитать. Но в любом случае я получаю воспроизводимый результат. Я получаю программу, в которой сведены воедино все специальные случаи, которые я нашёл. Эта программа позволяет рассуждать о том, как она работает и, например, убедиться в том, что специальные случаи какого-то типа я обрабатываю одинаково. Если у меня есть сомнения в том, как обрабатывать какой-то специальный случай, то иногда я могу выяснить это экспериментально, засовывая в программу специально подготовленные данные, состоящие исключительно из специальных случаев. Если я совершил ошибку подготавливая данные (те два столбца в табличке содержали косяки), то когда я найду ошибку, я могу исправить табличку и запустить программу заново, не выполняя все вычисления заново вручную.
Если я выполняю расчёты вручную, я никогда не могу быть уверен в том, что они выполнены верно, когда же я автоматизирую, то я могу со временем обрести уверенность в них. Достаточную уверенность для того, чтобы когда мне коллеги скажут, что у тебя какой-то косяк, потому что не сходится с их данными, я бы без малейшего сомнения (не только снаружи но и внутренне не испытывая сомнений) заявлял бы им, что у меня всё ок, косяк где-то у них. И мало того, что заявить, но на самом деле оказаться правым в итоге.
Так вот, мне кажется, что создание специализированных инструментов для полностью автоматизированного выполнения расчётов, имеют что-то общее с созданием сложных инструментов для создания кода.
>>что ошибки квалифицированного обходятся в большие суммы денег.
> опять всему мерило - бабло, хмммммЕстественно. А чем вы ещё будете мерять? Духовность -- увы -- это качественное мерило, которое не позволяет делать количественных оценок.
> И что? Человек придумал ассемблеры, чтобы не считать адреса меток вручную, и
> не совершать при этом ошибок.Так для начала нужно задать вопрос, зачем человек придумал адреса и метки (привет Тьюрингу)? Зачем потом ему понадобился ассемблер, и зачем потом он создает Си, чтобы избавится от ассемблера. Зачем? В корень зреть нужно, ошибка именно там. (Слышал про то, что нужно изменить направление роста стека, чтобы избавится от переполнения его :) и тому подобной ереси)
> Человек придумал типизацию, чтобы описывать свою
> программерскую задумку точнее, позволяя компилятору лучше проверять соответствие кода
> задумке.Не типизацию, а абстракцию. Последовательность из восьми битов он назвал абстрактно байтом, и тд. В ассемблере нет типов, как таковых, обсуждали это уже.
> И человек продолжает придумывать всё больше и больше вещей, которые
> позволяют описать больше деталей своей задумки, и ошибки вылезают чаще и
> чаще.Это все уже обсуждали, человек склонен все сваливать в кучу, а потом еще создает инструменты для разгребания этой кучи. Все якобы сложное состоит из простых частей, если простые части сваливать в кучу то черт там голову потом сломит, а если по порядку, то сложное становится простым.
> Хочешь я тебе ссылок накидаю на то, какие ошибки позволяет
> отлавливать rust?На каком языке написан ваш rust?
> это писать программу с нуля, каждый раз когда надо внести туда изменение.так чтение с первой строчки кода, даст тот же результат. Если человек при этом не заметил ошибки, думаете при переписывании он заметит?
> И развитие языков программирования идёт в сторону автоматизации этого процесса. Даже если
> мы посмотрим на C, мы увидим, что он развивается в сторону
> автоматизации этого процесса.вот тут я не понял какой именно процесс и его автоматизация? Автоматизация гроша не стоит если нет оптимального управления.
> Точнее развивался некоторое время, он уже застыл и
> дальше развиваться неспособен. C++ идёт дальше в этом направлении, но его
> развитие было сильно повреждено идеей "повторного использования кода", с которой программисты
> носились как с писаной торбой в 90-е и 00-е. То есть,
> в результате мы поняли фундаментальные ограничения идеи, что хорошо для нас,
> но C++'у от этого не легче.так почему до сих пор из кирпичей складывают дома?
> Нет. Это теоретическое рассуждение, которое противоречит практике.
Почему же теоретическое? Вот когда ответите на выше заданный вопрос, на чем написан ваш rust, то поймете. И тут нет противоречия.
> Если бы оно было верно,
> то самые надёжными программами были бы те, что написаны на ассемблере."надежными" - расплывчатое понятие, уточните.
> Но как мы видим, на практике ассемблер используют не для надёжности,
> а для экономии ресурсов, в первую очередь памяти.Смотреть как работают чужие руки, равносильно не иметь своих (ц). Возьмите в руки инструмент, и познайте для чего он создан.
> Код ядра специфичный
> для x86 (который гарантированно не будет выполняться на arm'ах, а значит
> ему не нужна кроссплатформенность C), написан почти весь целиком на C,
> на асме только то, что на C писать не удаётся.А что такого можно написать на асме, которого нельзя написать на Си? Я уже задавал такой вопрос, повторю, "существует ли такой алгоритм, который можно написать ТОЛЬКО на javascript"?
> Любопытно было бы ознакомиться с теоретической моделью, которая покажет, почему этот порочный
> круг не работает.Курица или яйцо? работает ведь, такая же ситуация ждет и ЯП.
> Впрочем, я могу поделиться чисто практическим опытом, который наводит на мысль о
> том, как это работает. Точнее как этот порочный круг не работает.Он и работает
>[оверквотинг удален]
> мне надо что-то подобное провернуть, я либо лезу в *scratch* emacs'а,
> либо достаю текстовый процессор, либо запускаю R, либо сажусь писать программу
> на C или Rust (R на мой взгляд бредовое убожество из
> 80-х, который хорош лишь тем, что к нему есть куча готовых
> скриптов). Казалось бы, программу писать дольше, чем взять два столбца чисел,
> посчитать в каждой строчке разницу, возвести её в квадрат, и сложить
> эти квадраты, зачем писать программу? Я не задумывался об этом, пока
> мне не пришлось работать рука об руку с людьми далёкими от
> программирования, которые настаивали на использовании калькулятора, и даже пытались считать
> со мной наперегонки, чтобы показать, что калькулятор лучше.Такс начнем сначала с утонения, садясь писать программу, для решения какой либо задачи, вы знаете точно ожидаемый результат? (ну из вашего примера про сложения чисел в столбце и т.д., то есть вы знаете чему в конечном итоге должна равняться сумма эта?)
Если да, то в чем проблема, вы сразу выявите ошибку в программе, если результат не сходится.
Если нет, то и вычисления на калькуляторе не дадут гарантий безошибочности вычислений. И потратите ровно столько времени на выявления ошибок вычислений на калькуляторе, сколько на написание программы. Порой даже необходимо прибегнуть к листу бумаги с карандашом. Представьте вот, написали программу сложения положительных чисел, а в результате получилось отрицательное кхммм мат ожидание говорит об обратном, и вы полезете искать ошибку (и смех и грех, сумма натурального ряда равна -1/12 мда уж :))по теме: Автоматическое доказательство
https://ru.wikipedia.org/wiki/%D0%90%D0%...
> Так зачем писать программу? Я понаблюдал за процессом, и я понял в
> чём дело. Дело даже не в том, что на калькуляторе надо
> выполнить больше действий и проще совершить ошибку -- не, это не
> всегда так, иногда отладка программы и обработка всех специальных случаев приводит
> к тому, что программу создавать дольше, чем просто посчитать.ну как зачем, сами выше писали, автоматизация.
>[оверквотинг удален]
> любом случае я получаю воспроизводимый результат. Я получаю программу, в которой
> сведены воедино все специальные случаи, которые я нашёл. Эта программа позволяет
> рассуждать о том, как она работает и, например, убедиться в том,
> что специальные случаи какого-то типа я обрабатываю одинаково. Если у меня
> есть сомнения в том, как обрабатывать какой-то специальный случай, то иногда
> я могу выяснить это экспериментально, засовывая в программу специально подготовленные
> данные, состоящие исключительно из специальных случаев. Если я совершил ошибку подготавливая
> данные (те два столбца в табличке содержали косяки), то когда я
> найду ошибку, я могу исправить табличку и запустить программу заново, не
> выполняя все вычисления заново вручную.хммм, тут небольшой спорный момент, теоретически, если я пишу алгоритм (давайте лучше функцию), на вход которой ДОЛЖНО поступать положительное число, то собственно спрашивается, зачем туда пихать отрицательное?
В математике (в теории скажем так) описывают какую-то формулу, и уточняют, что мол для всех "положительных n" и т. д. в этом роде, тут будет избыточно говорить, что формула не применима для отрицательных, ибо это ясно по определению самой формулы. А вот в практическом программировании совсем не так, но это спорный момент и отдельная тема для рассуждения, конечно желательно в практическом программировании проверять все условия достаточные и необходимые для правильности исполнения алгоритма.
> Если я выполняю расчёты вручную, я никогда не могу быть уверен в
> том, что они выполнены верно, когда же я автоматизирую, то я
> могу со временем обрести уверенность в них. Достаточную уверенность для того,
> чтобы когда мне коллеги скажут, что у тебя какой-то косяк, потому
> что не сходится с их данными, я бы без малейшего сомнения
> (не только снаружи но и внутренне не испытывая сомнений) заявлял бы
> им, что у меня всё ок, косяк где-то у них. И
> мало того, что заявить, но на самом деле оказаться правым в
> итоге.немного спорный момент, даже на автоматизированном производстве, изготовленные детали обычно на качество проверяет человек, собственными глазами и руками.
> Так вот, мне кажется, что создание специализированных инструментов для полностью автоматизированного
> выполнения расчётов, имеют что-то общее с созданием сложных инструментов для создания
> кода.увы пока мы не создали код, который будет создавать код без участия человека :)
> Естественно. А чем вы ещё будете мерять?
тогда зачем мы четвертым измерением выбрали время? замените его на деньги :) время-деньги, а не пространство-времени.
>> Хочешь я тебе ссылок накидаю на то, какие ошибки позволяет
>> отлавливать rust?
> На каком языке написан ваш rust?Какая разница? Ты ошибку-то посмотрел по ссылке? Это реальная ошибка, которая реально была поймана. Вне зависимости от того, на чём написан rust. Его можно написать на ассемблере, или на lisp'е, или даже в машинных кодах написать, он всё равно отловит ту ошибку.
>> это писать программу с нуля, каждый раз когда надо внести туда изменение.
> так чтение с первой строчки кода, даст тот же результат. Если человек
> при этом не заметил ошибки, думаете при переписывании он заметит?Нет не даст. И не заметит. Это особенности функционирования человеческой психики, человеческое мышление постоянно "срезает углы", оно всё построено на "срезании углов", на том, чтобы не думать одну и ту же мысль дважды. И никакие тренинги не могут научить человека не срезать углов. Можно научить его не срезать некоторые углы, но он всё равно продолжит срезать другие. А чтобы отловить ошибку вызванную изменением кода, надо обдумать всё-всё-всё заново. Целиком и полностью заново.
Вам не приходилось сидеть и двадцать минут тупо смотреть на ошибку в коде и не видеть её? Утомительная отладка привела к выводу, что вот они 15 строк кода, в которых запрятана ошибка. Но разглядывание этих строк кода не приводит к идентификации ошибки. Через двадцать минут надоедает, начинаешь смотреть ассемблерные дампы, и вдруг видишь косяк. Я нашёл баг в компиляторе! Я нашёл баг в компиляторе? хммм... дай ка я напишу минимальный код, демонстрирующий баг... но баг не вылезает на минимальном коде... ммм... и ассемблерные дампы его выглядят правильно... а может... да хз... ёёёппп... мать ж твою за ногу, просто слов таких матерных нет, чтобы описать свою тупость, которая провела два часа времени, пытаясь заметить, что в третьей строчке сверху не та переменная используется... Она давно там используется, уже пару недель, но раньше это не было заметно, в силу стечения всяких обстоятельств. А потом я привык к тому, что эта переменная там, и перестал её замечать. И потребовались невероятные сознательные усилия, чтобы заметить её вновь.
Не случалось такого? Если нет, то значит у вас ещё всё впереди.Вам не приходилось читать о типографских ошибках, и как люди начиная с древних времён боролись с опечатками? Как они вкидывали невероятные ресурсы в то, чтобы избавить книгу от опечаток, и тем не менее эти опечатки допускали? Они придумывали кучу всяких методов как читать книгу так, чтобы не пропускать опечаток. Но всё бестолку. Если интересно, я могу поискать, и может даже найду -- я как-то читал текст, который описывал насколько всё безнадёжно. Было безнадёжно до появления компьютеров. С компьютерами же надежда забрезжила. Где-то в светлом будущем, наполненном AI.
И психика не просто кеширует мысли, она заполняет пустоты. И не только в мыслях, в ощущениях даже. Описывали человека с "дырой" в сетчатке: она у него повреждена была, был кусок сетчатки нечувствительный к свету. Но эта дыра воспринималась человеком не как чёрное пятно, она _заполнялась_ окружением. Он смотрел на небо, и небо было без дыр. Он переводил взгляд на белую стену, и... дыра появлялась, как кусочек неба на стене. Через десяток секунд кусочек неба пропадал. Но если он переводил взгляд обратно на небо, то на небе было белое пятнышко стены. Невозможно сознательными усилиями заметить такое слепое пятно, которое психика заботливо заполнила чем-то, чтобы оно не маячило в поле зрения и не отвлекало от более важных вещей. Его можно заметить, если психика ошиблась, из-за того, что работала на другом уровне, и заполнила неправдоподобно. Доверять такой психике писать программы можно только от безысходности, только потому, что другого инструмента для написания программ у нас нет.
Даже процесс переписывания программы -- это _пере_писывание, человек будет пользоваться кешированными мыслями при этом, и он будет повторять те же ошибки, но всё же ему придётся проводить много времени с кодом, ему придётся продумывать мысли на определённую глубину, чтобы создать код, и... может быть из этого что-то и выйдет. Я не уверен, но это единственный способ заставить человека думать заново, который мне приходит в голову. А! Ну да! Можно постоянно менять программистов! Новый программист, скорее всего не думал эту программу, и он будет вынужден думать её заново.
>> И развитие языков программирования идёт в сторону автоматизации этого процесса. Даже если
>> мы посмотрим на C, мы увидим, что он развивается в сторону
>> автоматизации этого процесса.
> вот тут я не понял какой именно процесс и его автоматизация?Уууу... Вот эта ваша фраза наводит на мысль, что одному из нас двоих не помешает познакомиться с ассемблером, и этот один -- не я. Попробуйте писать на ассемблере. Под linux на асме писать -- одно удовольствие. Удобные сисколлы, индивидуальное адресное пространство для процесса, которое гарантирует, что не удастся нечаянно завалить ядро или какой-нибудь посторонний процесс. Или вогнать нечаянно какую-нибудь железку в какое-нибудь странное состояние, из которого её потом не удастся вывести. Куча библиотек и никаких проблем с тем, чтобы подгружать их динамически. Единственное что: не знаю хорошего отладчика для asm'а, но если обвешать gdb скриптами, то в принципе можно жить. Во всяком случае, если не забывать про отладочную информацию -- как отлаживать без отладочной информации я до сих пор не понимаю, в этом смысле линь cocёт у видны причмокивая. Но если писать код, то отладочная информация -- не проблема, и в целом выходит очень приятно. Попробуйте. И продолжайте пробовать до тех пор, пока вы не почувствуете растущего внутри раздражения от того, что вам приходится раз за разом выполнять одни и те же тупые действия, которые gcc может делать за вас автоматически. Я именно таким образом когда-то переключался с асма на C, и готов порекомендовать это любому. Очень просветляет. И вопрос о том, что именно автоматизирует компилятор, после такого опыта не возникает вообще.
> Какая разница? Ты ошибку-то посмотрел по ссылке? Это реальная ошибка, которая реально
> была поймана. Вне зависимости от того, на чём написан rust. Его
> можно написать на ассемблере, или на lisp'е, или даже в машинных
> кодах написать, он всё равно отловит ту ошибку.Давайте сначало разберемся с какими ошибками мы имеем дело. Если речь идет о логических ошибках, то это ваша проблема, это вы в ответе за то, как логически правильно должна выполняться ваша программа. Если вы ожидаете один результат, а машина выдает другой, то тоже ваша ошибка, либо вы не достаточно владеете знаниями о машине, либо в самой машине есть ошибка. Ошибки связанные с синтаксисом, и невнимательность я отбрасываю, меня больше волнует не человеческий фактор, хотя от него ни куда не убежишь. Я промолчу про всякие UB, отдельная тема.
> Нет не даст. И не заметит. Это особенности функционирования человеческой психики, человеческое
> мышление постоянно "срезает углы", оно всё построено на "срезании углов", на
> том, чтобы не думать одну и ту же мысль дважды. И
> никакие тренинги не могут научить человека не срезать углов. Можно научить
> его не срезать некоторые углы, но он всё равно продолжит срезать
> другие. А чтобы отловить ошибку вызванную изменением кода, надо обдумать всё-всё-всё
> заново. Целиком и полностью заново.Опять таки все упирается в то, на сколько хорошо прорисован ваш алгоритм в мозгу, и на сколько он свободен от лишних мыслей, чтобы безошибочно его реализовать в программном коде.
> Вам не приходилось сидеть и двадцать минут тупо смотреть на ошибку в
> коде и не видеть её?Это банальная невнимательность!
>[оверквотинг удален]
> я напишу минимальный код, демонстрирующий баг... но баг не вылезает на
> минимальном коде... ммм... и ассемблерные дампы его выглядят правильно... а может...
> да хз... ёёёппп... мать ж твою за ногу, просто слов таких
> матерных нет, чтобы описать свою тупость, которая провела два часа времени,
> пытаясь заметить, что в третьей строчке сверху не та переменная используется...
> Она давно там используется, уже пару недель, но раньше это не
> было заметно, в силу стечения всяких обстоятельств. А потом я привык
> к тому, что эта переменная там, и перестал её замечать. И
> потребовались невероятные сознательные усилия, чтобы заметить её вновь.
> Не случалось такого? Если нет, то значит у вас ещё всё впереди.Ну тут букет, нет гарантий безошибочности самой машины, системы, компилятора, языка, и придачу ваша невнимательность, не знание предметной области и т. д. Опять таки про UB (undefined behavior) промолчу
> Вам не приходилось читать о типографских ошибках, и как люди начиная с
> древних времён боролись с опечатками?Ну и как это решается? машина тупо посимвольно сравнивает текст со словарем, и где собственно встречает различие, то выдает ошибку. Так вот, а кто этот словарь составлял? Где гарантии, что словарь сам не содержит ошибок (если человек заполнял этот словарь вручную, и собственно мог допустить ошибку)? Бесполезна в этом случае такая программа. Человек должен посимвольно весь словарь проверить, перепроверить с другими словарями и с уверенностью в 99% может её использовать, но 1% неуверенности все же остается. Программа исполнит ровно то, что написал человек. И думаю дальше смысла не вижу рассуждать о безошибочности программ, пока не безошибочен пишущий её человек.
> Было безнадёжно до появления компьютеров. С компьютерами
> же надежда забрезжила. Где-то в светлом будущем, наполненном AI.нет, все осталось таким же, АИ вообще сказка детям, ни одна программа еще не написала ни единой строчки кода.
> Доверять такой психике писать программы можно только от безысходности, только потому,
> что другого инструмента для написания программ у нас нет.Ну это есть изьян, какой результат ожидать от заведомо сломанного механизма?
> Даже процесс переписывания программы -- это _пере_писывание, человек будет пользоваться
> кешированными мыслями при этом, и он будет повторять те же ошибки,
> но всё же ему придётся проводить много времени с кодом, ему
> придётся продумывать мысли на определённую глубину, чтобы создать код, и... может
> быть из этого что-то и выйдет. Я не уверен, но это
> единственный способ заставить человека думать заново, который мне приходит в голову.
> А! Ну да! Можно постоянно менять программистов! Новый программист, скорее всего
> не думал эту программу, и он будет вынужден думать её заново.Много времени с кодом, ))) а что вы хотели? Вы изначально научную дисциплину превратили в "золотую курицу", и по жизни идете с девизом - время-деньги, на что вы жалуетесь? Жалуется ли математик, говоря, что он не решил какую-то гипотезу за месяц?
> Уууу... Вот эта ваша фраза наводит на мысль, что одному из нас
> двоих не помешает познакомиться с ассемблером, и этот один -- не
> я.Я так и не услышал про процесс и его автоматизацию, ассемблер всего лишь переводит (транслирует) из мнемонического символьного представления программного кода в машинный код.
> И вопрос о том, что именно автоматизирует компилятор, после
> такого опыта не возникает вообще.Зачем мне компилятор если есть транслятор? И каково мое удивление когда компилятор генерирует мою программу совсем не так как я писал бы на самом асм? Вы думаете это правильно? Компилятор за вас решает, что правильно и как должно быть, вы с этим соглашаетесь? Вы разве, получаетесь автором результирующей программы или программист компилятора? Тогда пусть будет добрым и напишет за меня программу.
>> Какая разница? Ты ошибку-то посмотрел по ссылке? Это реальная ошибка, которая реально
>> была поймана.
> Давайте сначало разберемся с какими ошибками мы имеем дело.Мне становится реально любопытно, в каком вузе вы учитесь? Где вас учат тому, что искусство дискуссии сводится у искусству не отвечать на вопросы, уводя разговор в сторону?
Сходите по ссылке, там ошибка описана в деталях. Сходите прочитайте, а потом, если вам покажется это полезным, классифицируйте её согласно вашей классификации. Я не вижу смысла обсуждать эти вопросы абстрактно: если не предпринимать постоянных усилий, чтобы поддерживать связь с реальностью, то эта связь будет утеряна, и абстракции станут бессмысленными.
> Это банальная невнимательность!
Да, именно об этом я и говорю. Это невнимательность. Банальная и неустранимая.
> Вы изначально научную дисциплину превратили в "золотую курицу"
Написание софта никогда не было научной дисциплиной. Написание софта -- это практическая деятельность. Наука может предложить инструменты для того, чтобы сделать эту деятельность более успешной, но она не может создавать софт. И знаете почему? Потому что превращение программирование в золотую курицу, очень хорошо укладывается в экономику, которая, в частности, способ организации взаимодействия людей. И таким образом, программисты имеют инструменты для того, чтобы организовываться, для того, чтобы создавать успешные софтверные компании, и даже софтверные гиганты-корпорации, а учёные -- нет. В своей оторванности от реалий мира, учёные ни на что не способны. Пока программы были небольшими, и их мог написать один человек, учёные могли выполнять задачи инженеров и быть конкуретноспособными (то есть востребованными), как только конкуретноспособные программы стали больше, учёные остались позади, потому что их способности к кооперации существенно ниже, чем способности к кооперации у инженеров.
Да блин, гляньте на Танненбаума, и на то как тот со своим minix'ом позорно слил Торвальдсу и linux'у. Весь их срач о микро/макроядерности, на самом деле ничего не решал, Танненбаум слил не потому, что макроядерность чем-то лучше, а потому, что он не был готов кооперироваться с другими. Танненбаум не готов был думать о том, как изменить модель разработки minix'а так, чтобы привлечь туда всех желающих разрабатывать minix. Вместо этого он полез доказывать Торвальдсу, что микроядро рулит. Ну, допустим, доказал, и что с того? И где этот ваш рулящий minix?
Можно ещё Вирта вспомнить, тот тоже где-то в 80-е пилил ОС, и тоже офигенно крутую теоретически, и где эта его ОС? А нигде, не нужна никому, потому что тот тоже был так восхищён и горд своими идеями, что забыл о том, что идеи сами по себе без людей работающих над их реализацией не стоят выеденного яйца.
Единственная отрасль науки, которая помнит о том, что идеи -- это пустые звуки, если они не могут двигать людей -- это экономика. Но экономика забывает про идеи, и сосредотачивается только на том, чтобы двигать людьми, предлагая им денег. Поэтому она тоже ничего не может создать сама по себе. Поэтому она столь же оторвана от реальности, как и математика. И так же как и математика может решать только идеализированные задачи, из которых было выкинуто всё, что мешало абстракциям, вне зависимости от того, насколько это выкинутое важно, для получения верного ответа.
> Я так и не услышал про процесс и его автоматизацию, ассемблер всего лишь переводит (транслирует) из мнемонического символьного представления программного кода в машинный код.
Если это не автоматизация, я предлагаю вам попробовать проделать это руками. Кстати это довольно забавно писать программы в двоичных кодах. Поначалу это резко медленнее, чем в мнемониках, но потом получается вполне пристойно. По-крайней мере до тех пор, пока не возникает необходимости менять уже написанный код.
Попробуйте -- это объяснит вам, что значит автоматизация. Попробуйте: если вы думаете, что теория может объяснить всё, то вы ошибаетесь. Программирование -- это практическая деятельность, и понять его можно лишь через практику. И так будет до тех пор, пока не будет создан AI, который будет писать программы за человека, вот после этого, может быть, программирование сможет стать теоретической дисциплиной. А пока программы пишет человек, программирование неотделимо от психологии, социологии, экономики, маркетинга, потребительской культуры в головах у клиентов, политкорректности и социальной справедливости.
В исходниках могут быть ошибки, но это не тот случай. Здесь ошибка - сама идея. Таких примеров множество. Автором большинства является оффтопик, но и сабж решил внести свой вклад в копилку глупостей.
> В коде всегда есть ошибкиДавай не удем их правит скажем что это фича
>Непонимание этих фактов и является ложным чувством безопасности по определению.
Может убрат идерастическую "непрерывную дегенерацию"? Нет на такое мы пойти не можем!
> Откуда ты взял это ложное чувство безопасности?Здесь -- из типовых комментариев вида "а вот писали бы на XYZ" и разборов таких вот полётов софтов на этих самых XYZ, разумеется.
> Ты можешь привести пример комментария
http://www.opennet.me/openforum/vsluhforumID3/111522.html#6
(ещё пару ссылок решил не приводить, там и так зачитаться можно, а где-то Вы тоже отметились не только зачитываясь)
> Что за манера вообще приписывать
http://www.opennet.me/openforum/vsluhforumID3/115889.html#132
>> Ты можешь привести пример комментария
> https://www.opennet.me/openforum/vsluhforumID3/111522.html#6А, да, вот так оно понятнее. Но даже там, человек ведь не понимает суть того, что называют "memory safety", и... ну, вряд ли, он не понимает того, что ошибки подобные тому что описано в данной новости, возможны вне зависимости от языка программирования. Как написать язык программирования избавляющий от таких ошибок, ещё не придумали.
Ну так вот, я к чему это. Твоё замечание, которое по-крайней мере по его форме, адресовано такому человеку, ничерта ему не поможет, как раз по описанной выше причине. Ты просто представь себе его состояние ума, и ты увидишь, что он твоё замечание просто отметёт и даже думать о нём не будет.
> замечание, которое по-крайней мере по его форме, адресовано такому человекуВосприятие формы индивидуально. Например:
Некто считает, что сообщение адресовано не ему. При этом отвечает на сообщение.> Ты просто представь себе его состояние ума, и ты увидишь
А когда ты осознаешь, что у тебя каша похлеще, что будешь делать?
>> замечание, которое по-крайней мере по его форме, адресовано такому человеку
> Восприятие формы индивидуально. Например:
> Некто считает, что сообщение адресовано не ему. При этом отвечает на сообщение.И что?
>> Ты просто представь себе его состояние ума, и ты увидишь
> А когда ты осознаешь, что у тебя каша похлеще, что будешь делать?Я много работаю над этой кашей. Ежедневно, годами. Я знаю, что у меня в голове такая каша, которую мало лишь кто в состоянии в своей голове создать. Я настолько к этому привык, что уже даже не испытываю гордости за содеянное, воспринимая это как заурядный факт.
>>> замечание, которое по-крайней мере по его форме, адресовано такому человеку
>> Восприятие формы индивидуально. Например:
>> Некто считает, что сообщение адресовано не ему. При этом отвечает на сообщение.
> И что?Что что?
>>> Ты просто представь себе его состояние ума, и ты увидишь
>> А когда ты осознаешь, что у тебя каша похлеще, что будешь делать?
> Я много работаю над этой кашей. Ежедневно, годами. Я знаю, что у
> меня в голове такая каша, которую мало лишь кто в состоянии
> в своей голове создать. Я настолько к этому привык, что уже
> даже не испытываю гордости за содеянное, воспринимая это как заурядный факт.О, умничка. Порвал мне шаблон. Два часа склеивал. Получилось "своё г. не пахнет". Народная мудрость, однако.
Наерняка это не последняя уязвимость. snap, flatpack - это всё костыли. Неужели нельзя было разрулить проблему репозиториями и реструктуризацией файловой иерархии для приложений и версий библиотек? Если дистрибутив устарел, обновился на новый, то почему нельзя установить приложение из старого репозитория? Зачем все эти контейнеры, сложности, которые открывают уязвимости на пустом месте?
Nix & Guix к вашим услугам.
По факту контейнеры закрывают уязвимости. Пользовательские apt репозитории небезопасны по определению, их владелец может делать с вашей системой все что хочет. Контейнеры же могут предоставлять доступы только к необходимым приложению вещам, при этом дав выбор пользователю.
В том же apt и аналогах все та же куча уязвимостей.
а никто и не говорил о пользовательских репозиториях. Разумеется, это дыра. Используйте родные.
> По факту контейнеры закрывают уязвимости.по-факту, контейнеры создавались для других целей (тащить свои несовместимые версии библиотек) и их изоляция до сих пор оставляет желать лучшего, не говоря уже про дыры.
> Контейнеры же могут предоставлять доступы только к необходимым приложению вещам, при этом дав выбор пользователю.
кстати, о каких контейнерах речь? и о каком выборе, если не секрет? при установке snap-пакета тебя особо ни о чем не спрашивают, и скорее всего все твои данные из домашней папки оно легко сможет удалить. (я правда в снапе тестировал только системные приложения типа juju, MaaS, k8s перед тем как его удалить, чтоб зря проц не жрал)
Уязвимости во всяких контейнерах находят постоянно, там основная фишка в том, чтобы юзверь запустил софт собранный как задумано автором, который автор у себя и тестит. Еслиб эта хрень еще не жрала столько и с темами работала нормально... Flatpak не нравится тем, что тащит за собой Гном и ГТК, какой бы софт я не ставил, зачем? Ну и с темами да файловыми диалогами там вообще беда. Жалко Snap не взлетит, RedHat двигает стандарты, убунтоиды частенько отступают и не доводят дело до конца.
Ох не даром я выпиливаю этот мерзкий snapd из системы, ох не даром..
Даже не заметил. 2.37.1
Увы, Ubuntu теперь пропихивает этот snap чересчур навязчиво. Возникает впечатление, что snap-пакеты планируются как способ доставки приложений по умолчанию. Понятно, что его поддержку можно из системы выпилить к чертям и адвансед юзеру пофиг, но что-то в этом неправильно в принципе.Для сравнения - есть Fedora, есть flatpak и есть таки свобода выбора. И если есть нужда дать адекватный десктопный Linux обычному пользователю - то довести десктопную Fedor'у до убунтушной юзабилити и недефолтового внешнего вида (Adwaita уныла чуть менее, чем полностью) - дело 15 минут.
Ubuntu вообще после версии 16.04 не радует. А посему аноним рассматривает Ubuntu только в качестве хранителя репозитория системных вещей (прикладные там - просто древний мусор).
Ну, Unity был интересен, да. Но третьегном + Dash to dock делает Unity ненужным. И за вычетом snap'одрочества и непоспевания за таки излечивающимися болезнями развития третьегнома 18-я Ubuntu кагбэ не испортилась же - в том, что недесктопное, какой-то порчи не прозреваю я, 18 LTS сервера в продакшене не глючат и хвала Омниссии.
На сервер обычно не ставят DE. Хотя некоторые, о ком не говорят здесь, ставят.
> На сервер обычно не ставят DEСервер бывает разным.
Сам топи свой необычный сервер в ртути.
Ну так к серверной Убунте претензий и нет.
> Для сравнения - есть Fedora
> и есть таки свобода выбораА Вы-таки смешной.
PS: на днях как раз вспоминал https://www.redhat.com/archives/fedora-devel-list/2004-May/m...
> А Вы-таки смешной.
> PS: на днях как раз вспоминал https://www.redhat.com/archives/fedora-devel-list/2004-May/m...Ну вы-то, Шигорин, дефакто смешнее - взяли и анекдот запостили.
А что по существу-то сказать хотели?
"дефакто" -> "де-факто", разумеется
стесняюсь спросить, но зачем ему демон?
Он сразу монтирует все пакеты что установлены, даже если они не запущены.