Интервью с Леннартом Поттерингом на Linux Piter об изменениях в Linux, про systemd и о том, зачем посещать конференции

в базах данных результат и есть цель работы базы данных.

Ок. Файловые БД. Два пользователя одновременно открывают один и тот же файл, и одновременно в него пишут. Какой результат будет по вашему мнению?

стоит добавить, ты не ответил на вопрос «зачем ты это делаешь?

Тут честно говоря я ваш вопрос не понял «зачем ты это делаешь?», поэтому и не ответил на него. Поясните плиз.

Ок. Файловые БД. Два пользователя

Начнем с терминов, между «БД» и «хранением в текстовых файлах» разницы ровно ноль.

Начнем с терминов

1. что такое «текстовый файл»?
2. что такое «БД»?

ты хочешь прекратить начинать с терминов и говорить о частной реализации?
хорошо

1. в чём разница между хранением в текстовых файлах и БД которая не использует ФС в пользу ОЗУ?
   
2. в чём разница между хранением в текстовых файлах и БД которая не использует ФС в пользу ОЗУ, более того, не хранит никакие данные кроме одной процедуры которая возвращает представление данных?

разница есть?

Еще раз:
Одно хранилище файловое, в ОЗУ, еще более быстрое чем ОЗУ, вобщем пофиг, но главное что это один файл и блокировки не предусмотрены. Одномоментно два,три...N пользователей производят изменение записи. Каков результат по вашему мнению?

и блокировки не предусмотрены

теперь ты хочешь говорить только о тех частных реализациях, которые удобны тебе?
ты не ответил прямо ни на один мой вопрос сегодня.
тебе не понятны мои вопросы? их перефразировать? или ты не можешь на них ответить?
тебе не понятна цель моих вопросов? она очевидна — в интернете кто-то неправ:

между «БД» и «хранением в текстовых файлах» разницы ровно ноль

после

Начнем с терминов

тебе не понятны мои вопросы?

Действительно уже не понятны. Возможно поэтому и мои ответы не понятны. Такое бывает «говорим на разных языках»

их перефразировать?

Если не сложно.

давай обобщим слово «БД» до слова «функция», это удобно если я расскажу, что единственное свойство этого слова, «функция» — это выдавать результат.
так вот ты, по моему мнению, приравнял результат функции и саму функцию.
неплохо, но довольно бесполезная функция у нас выходит, если мы не хотим получить один и тот-же результат всегда.

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

как получение содержимого текстового файла ничем не отличается от работы БД, если мы не можем получить даже адрес файла без работы БД?

все слова «содержимое», «адрес» следует заменять на «представление», т.к. эти штуки — частности.

Да стопудов этот лёня поддерживается ЦРУшниками ради создания монстра, с кучей кода и дырами-дырами-дырами, чтобы все было так запутано, что никто не полез читать и вдумываться в его крякозяблы, но при этом поделие было популярным в силу лени и упрощения.

По этой логике произвольное единичное веб-приложение с хранением данных в текстовых файлах устойчивее, чем распределенное с хранением в реплицируемой БД.

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

А, так под KISS вы понимаете бритву Оккама?

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

Простоту эксплуатации и поддержки гарантируют автоматизация и технические процессы.

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

Опенсорц не обязывает автора обеспечивать некую абстрактную свободу выбора в рамках продукта.

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

Любители systemd дискриминируют нелюбителей. Нелюбители дискриминируют любителей. И это абсолютно нормально, частная дискриминация решает.

это не про частные предпочтения. ненужнод педалируется на уровне корпораций. и это плохо для конкуренции софта. см. выше про навязывание решений неквалифицированному юзеру.

все, что нужно знать об интервью с поттерингом:

"... Когда я получал сообщения из Интернета от какого-то очередного “умника” о том, что я тупица, исходил из того, что если этот человек не заслужил моего уважения как специалист, я просто пропускаю эти слова мимо ушей.

Честно говоря, я считаю, что если тебе повезло родиться “толстокожим”, то у тебя блестящее будущее в open source. ... И я абсолютно горд собою, что нам удалось пробиться, а другим нет."

о, так avahi - это тоже его поделие?

да. он мыслит себя как архитектор, но при этом его решения ... хмм ... подходят не всегда и не всем.

На конференции будут авторитетные делегаты от ЛОРа, чтобы доходчиво объяснить Леннарту что он г@вно и ненужен? )

я бы тоже хотел это знать. даже появилась мысль не съездить ли самому.

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

Я с этого мест встряну «как человек, занимающийся надежностью и эксплуатацией систем». Абсолютно согласен насчет «Простоту эксплуатации и поддержки гарантируют автоматизация и технические процессы». Однако у нас есть разные уровни, layers инфраструктуры. Автоматизация может скрывать сложность низлежаших слоев. Iron Bug (и я) по сути против системы а-ля Windows: перед вами граф. интерфейс и три кнопочки. Все автоматзировано, все просто на этом уровне. До тех пор, пока вы не загляните под капот. С systemd то же самое. Мне не нравится, что творится под капотом.

opensource is not about choice

...but UNIX way is about flexibility.

https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html

«Nobody is smart enough to optimize for everything, nor to anticipate all the uses to which their software might be put.»

чем проще вещь - тем сложнее её поломать и тем проще починить

Спорно. По этой логике произвольное единичное веб-приложение с хранением данных в текстовых файлах устойчивее, чем распределенное с хранением в реплицируемой БД. Но мы видим как раз развитие второго подхода - отказоусточивые системы, HA-кластера, георепликации и распределенные ЦОДы не от хорошей жизни строят.

Здесь нет противоречия. Это разные слои, которые собираются последовательно. Отказоусточивые системы лучше строятся на надежном, простом (KISS) основании. Это, как дом, который состоит из кирпичей, блоков и цемента. Вы можете заложить устойчивость, использовать толстые несущие, но если использовать дешевый раствор или простой песок, который выветривается за 3 года, капитальный ремонт придется делать раньше.

грамотный юзер всё это пошлёт лесом и выберет другие дистрибутивы. но не все юзеры могут так поступить.

да... не везде и не всегда так можно поступить. хотя я тут всерьез на днях изучал release cycle freebsd и их compat policy.:) еще пару лет назад не мог себе такого представить.:)

так бсдя - отличная система.

думаю, тебе будет интересно не меньше, чем мне:

https://www.youtube.com/watch?v=1j1UaLsPv3k

такого ладенящего душу пиздеца, как при переходе с 10-STABLE на 11-STABLE я что-то не припомню

а вот при переходе с 11 на 12 на UFS меняет размер inode (32->64). это ломает совместимость, поэтому переходить надо очччень осторожно. четко по инструкции.

По первому впечатлению, если делать всё как положено (то есть загрузиться с новым ядром, в котором включён соответствующий текущей версии COMPAT_FREEBSD, и только потом ставить новый мир) , всё должно пройти чисто.
Да и есть подозрение, что к моменту перехода с 11 на 12 UFS у меня останется только в виде uzip-образов, которые грузятся в память с флешек/по сети. Так что половины связанных с этим проблем даже потенциально не будет.

включение COMPAT - это действие по инструкции или какой-то прием, который все бсдешники знают? все, что я пока видел в инструкциях, это последовательное использование freebsd-update.

Использование для обновления из исходников с major <N> на major <N+1> ядра от <N+1>, собранного с COMPAT_FREEBSD<N> — the Right Thing and the Good Practice. То есть, после make buildworld, make buildkernel и make installkernel делается перзагрузка в singleuser и уже там, на новым ядре, выполняется make installworld и mergemaster.
Мои впечатления по поводу применимости этой практики в данном случае сложились после чтения комментария к changeset-у r318736 и беглого просмотра diff-ов из него.
За freebsd-update не скажу — никогда им не пользовался. Но, насколько я понимаю, бинарные обновления предполагают использование ядра GENERIC, а там все имеющиеся COMPAT_FREEBSD* включены. Так что, если этот freebsd-update позволяет отдельно накатать ядро, а затем продолжить обновление мира после перезагрузки с ним, то почему бы и нет.

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

Человек достойный памятника

Ага, могильного и чем быстрей, тем лучше

BTW, freebsd-update и бинарные пакеты — вещи никак не связанные. freebsd-update предназначен для бинарного обновления базовой системы (core system), а пакеты получаются сборкой портов (ports) и с недавних пор могут устанавливаться и обновляться из централизованного репозитория командой pkg.

Леннарт Поттеринг – одна из легенд Linux-сообщества. Начиная с 90-х годов он работает над ядром операционной системы Linux. Леннарт запустил такие легендарные проекты, как PulseAudio, Avahi, kdbus, systemd и стал их главной движущей силой.

Поправил.

ну эт понятно.

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

Отлично. Теперь вопрос: зачем нам init, нуждающийся в заплатках?

список всех частей в студию.

https://packages.altlinux.org/en/Sisyphus/srpms/systemd
*-debuginfo разрешаю вычесть.