История изменений

При чём тут вообще хелперы, любитель передёрнуть ты наш?

Любитель передергивать тут только один - это ты ;) А хелперы тут при том, что контроль поведения сервисов при установке пакетов относится, очевидно, к установке пакетов.

Что, решил продолжать клоунаду, всеми правдами и неправдами уходя от ответа?

Ну ты же клоунадишь весь тред, почему и мне немножко нельзя? Не должен же я с исключительно серьезной миной парировать все те бредни, что ты тут несешь про взрослые пакетные менеджеры (r) (c) (tm).

Шутка была в том, что fsync гарантирует доставку до железа и подтверждение от него, но не гарантирует, что железо тебе не врет. А взрослый dpkg на это надеется :)

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

Просто поразительная самоуверенность! Да будет тебе известно, клоун, зачем-то притворяющийся инженером, что хороший инженер анализирует задачу и следует ТЗ, а не пытается параноидально достичь абстрактной надежности. Разработка подобной системы всегда требует соблюдения баланса между скоростью, надежностью и разумностью всех требований.

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

Разумеется, это полная чушь. Итак, следим за руками:

Dpkg делает fsync и rename на каждый файл, что превращает обновление в синхронный процесс. Очень медленный синхронный процесс.
При этом прерывание обновления все равно приводит к потере целостности, потому что в системе существуют хоть и непобитые, но уже несовместимые друг с другом файлы - библиотеки, бинарники, скрипты, что угодно. Сравнивать сорта побитых состояний - такое себе занятие, потому что оба они будут приводить к непредсказуемым сбоям. Или не будут. Тут не предскажешь.
Пакман работает очень быстро, потому что не ждет fsync. Это снижает время обновления кратно, благодаря тому, что процесс не является синхронным.
Из чего хороший инженер (не ты) сделает вывод, что чем быстрее происходит обновление, тем ниже вероятность, что во время обновления произойдет сбой питания или любой другой внешний сбой. Кстати, еще этому способствует крупноблочность пакетов - меньше постинсталлов и сопутствующих накладных расходов.
Таким образом, из-за синхронной записи на диск, dpkg лишь увеличивает вероятность возникновения сбоя. Высокая степень гранулярности пакетов лишь ухудшает эту ситуацию.

Такие вот дела.

И то, что pacman при данных условиях этим механизмом не пользуется, – это или дилетантизм его разработчиков…

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

А еще dpkg - это решение в себе. Если я захочу сделать A/B-систему на снапшотах, то пакман подойдет мне лучше dpkg, потому что не будет создавать оверхед на лишние операции обеспечения целостности, ибо целостностью будет заниматься файловая система. Я просто сделаю снапшот, запущу пакман, и если его работа завершилась успешно, то я буду уверен, что никаких проблем нет. А если нет - откачу ФС и начну сначала. Или не начну, по необходимости.

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

«Достаточно» – это субъективная мера.

Достаточно - это объективная мера соответствия техзаданию, дружок. «Достаточно» становится, когда система отвечает количественным и качественным требованиям.

Случаев, когда частичное или даже полное обновление вызывали поломки в Arch, которых просто не было бы при должной реализации зависимостей на уровне версий символов, – просто дофига.

Я уже объяснял, что при крупноблочных зависимостях проблема не является существенной. А в дебиане ситуация еще хуже: из-за сильной гранулярности пакетов пришлось изобретать лукап по символам, который при этом еще и не работает нормально, пример я приводил. И таких примеров можно наскрести вагон.

Название пакета с такой проблемой – в студию!

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

Ты применил фразу «полумертвый форк» к апстримному репозиторию, в котором остановилась разработка.

Во-первых, ты врёшь, клоун. Ты взял в кавычки свою собственную фразу, которой не было в моем сообщении. Я писал так: то, что привел ты называется мертвый репозиторий с архивным кодом. Или для тебя слова «репозиторий», «архив» и «форк» являются синонимами? Дружище, ты точно разработчик?

Во-вторых, давай поищем значение слова «апстрим», применительно к опенсорсу. Думаю, Red Hat сойдет за авторитетный источник:

Within information technology, the term upstream (and related term «downstream») refers to the flow of data. An upstream in open source is the source repository and project where contributions happen and releases are made.

Обрати внимание на слово happen. Не happened, лол. Репозиторий, в котором разработка умерла 11 лет назад - это максимум архив старого апстрима, но никак не апстрим, и тем более - не актуальный апстрим. Апстрим - это место, где код разрабатывается. Их может быть несколько, если у нас несколько форков, но в данном случае живой форк только один, и апстрим его лежит на гитхабе.

Слово «upstream» сам найдёшь, или помощь нужна?

Ты всерьез мне подсовываешь ченжлог деб-пакета как доказательство своей правоты? Ты сам-то его вообще читал? Итак, смотрим на дату:

Sat, 03 Dec 2016 12:20:57 -0500

Это было 8 лет назад. Тогда с момента остановки разработки rng-tools прошло всего три года. В 2017, спустя год после этого коммита в ченжлоге дебиана, разработка продолжилась в гитхабе, о чем можно узнать из [https://api.github.com/repos/nhorman/rng-tools](даты создания репозитория rng-tools), см. поле created_at. Получается, что уже на тот момент у нас был архивный реп, и живой, развивающийся код.

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

Тут всё прекрасно. На этом этапе тебя можно просто класть в палату мер и весов. Впрочем, весы и меры опциональны.

При чём тут вообще хелперы, любитель передёрнуть ты наш?

Любитель передергивать тут только один - это ты ;) А хелперы тут при том, что контроль поведения сервисов при установке пакетов относится, очевидно, к установке пакетов.

Что, решил продолжать клоунаду, всеми правдами и неправдами уходя от ответа?

Ну ты же клоунадишь весь тред, почему и мне немножко нельзя? Не должен же я с исключительно серьезной миной парировать все те бредни, что ты тут несешь про взрослые пакетные менеджеры (r) (c) (tm).

Шутка была в том, что fsync гарантирует доставку до железа и подтверждение от него, но не гарантирует, что железо тебе не врет. А взрослый dpkg на это надеется :)

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

Просто поразительная самоуверенность! Да будет тебе известно, клоун, зачем-то притворяющийся инженером, что хороший инженер анализирует задачу и следует ТЗ, а не пытается параноидально достичь абстрактной надежности. Разработка подобной системы всегда требует соблюдения баланса между скоростью, надежностью и разумностью всех требований.

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

Разумеется, это полная чушь. Итак, следим за руками:

Dpkg делает fsync и rename на каждый файл, что превращает обновление в синхронный процесс. Очень медленный синхронный процесс.
При этом прерывание обновления все равно приводит к потере целостности, потому что в системе существуют хоть и непобитые, но уже несовместимые друг с другом файлы - библиотеки, бинарники, скрипты, что угодно. Сравнивать сорта побитых состояний - такое себе занятие, потому что оба они будут приводить к непредсказуемым сбоям. Или не будут. Тут не предскажешь.
Пакман работает очень быстро, потому что не ждет fsync. Это снижает время обновления кратно, благодаря тому, что процесс не является синхронным.
Из чего хороший инженер (не ты) сделает вывод, что чем быстрее происходит обновление, тем ниже вероятность, что во время обновления произойдет сбой питания или любой другой внешний сбой. Кстати, еще этому способствует крупноблочность пакетов - меньше постинсталлов и сопутствующих накладных расходов.
Таким образом, из-за синхронной записи на диск, dpkg лишь увеличивает вероятность возникновения сбоя. Высокая степень гранулярности пакетов лишь ухудшает эту ситуацию.

Такие вот дела.

И то, что pacman при данных условиях этим механизмом не пользуется, – это или дилетантизм его разработчиков…

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

А еще dpkg - это решение в себе. Если я захочу сделать A/B-систему на снапшотах, то пакман подойдет мне лучше dpkg, потому что не будет создавать оверхед на лишние операции обеспечения целостности, ибо целостностью будет заниматься файловая система. Я просто сделаю снапшот, запущу пакман, и если его работа завершилась успешно, то я буду уверен, что никаких проблем нет. А если нет - откачу ФС и начну сначала. Или не начну, по необходимости.

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

«Достаточно» – это субъективная мера.

Достаточно - это объективная мера соответствия техзаданию, дружок. «Достаточно» становится, когда система отвечает количественным и качественным требованиям.

Случаев, когда частичное или даже полное обновление вызывали поломки в Arch, которых просто не было бы при должной реализации зависимостей на уровне версий символов, – просто дофига.

Я уже объяснял, что при крупноблочных зависимостях проблема не является существенной. А в дебиане ситуация еще хуже: из-за сильной гранулярности пакетов пришлось изобретать лукап по символам, который при этом еще и не работает нормально, пример я приводил. И таких примеров можно наскрести вагон.

Название пакета с такой проблемой – в студию!

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

Ты применил фразу «полумертвый форк» к апстримному репозиторию, в котором остановилась разработка.

Во-первых, ты врёшь, клоун. Ты взял в кавычки свою собственную фразу, которой не было в моем сообщении. Я писал так: то, что привел ты называется мертвый репозиторий с архивным кодом. Или для тебя слова «репозиторий», «архив» и «форк» являются синонимами? Дружище, ты точно разработчик?

Во-вторых, давай поищем значение слова «апстрим», применительно к опенсорсу. Думаю, Red Hat сойдет за авторитетный источник:

Within information technology, the term upstream (and related term «downstream») refers to the flow of data. An upstream in open source is the source repository and project where contributions happen and releases are made.

Обрати внимание на слово happen. Не happened, лол. Репозиторий, в котором разработка умерла 11 лет назад - это максимум архив старого апстрима, но никак не апстрим, и тем более - не актуальный апстрим. Апстрим - это место, где код разрабатывается. Их может быть несколько, если у нас несколько форков, но в данном случае живой форк только один, и апстрим его лежит на гитхабе.

Слово «upstream» сам найдёшь, или помощь нужна?

Ты всерьез мне подсовываешь ченжлог деб-пакета как доказательство своей правоты? Ты сам-то его вообще читал? Итак, смотрим на дату:

Sat, 03 Dec 2016 12:20:57 -0500

Это было 8 лет назад. Тогда с момента остановки разработки rng-tools прошло всего три года. В 2017, спустя год после этого коммита в ченжлоге дебиана, разработка продолжилась в гитхабе, о чем можно узнать из [https://api.github.com/repos/nhorman/rng-tools](даты создания репозитория rng-tools), см. поле created_at. Получается, что уже на тот момент у нас был архивный реп, и живой, развивающийся код.

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

Тут всё прекрасно. На этом этапе тебя можно просто класть в палату мер и весов. Впрочем, весы и меры опциональны.

При чём тут вообще хелперы, любитель передёрнуть ты наш?

Любитель передергивать тут только один - это ты ;) А хелперы тут при том, что контроль поведения сервисов при установке пакетов относится, очевидно, к установке пакетов.

Что, решил продолжать клоунаду, всеми правдами и неправдами уходя от ответа?

Ну ты же клоунадишь весь тред, почему и мне немножко нельзя? Не должен же я с исключительно серьезной миной парировать все те бредни, что ты тут несешь про взрослые пакетные менеджеры (r) (c) (tm).

Шутка была в том, что fsync гарантирует доставку до железа и подтверждение от него, но не гарантирует, что железо тебе не врет. А взрослый dpkg на это надеется :)

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

Просто поразительная самоуверенность! Да будет тебе известно, клоун, зачем-то притворяющийся инженером, что хороший инженер анализирует задачу и следует ТЗ, а не пытается параноидально достичь абстрактной надежности. Разработка подобной системы всегда требует соблюдения баланса между скоростью, надежностью и разумностью всех требований.

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

Разумеется, это полная чушь. Итак, следим за руками:

Dpkg делает fsync и rename на каждый файл, что превращает обновление в синхронный процесс. Очень медленный синхронный процесс.
При этом прерывание обновления все равно приводит к потере целостности, потому что в системе существуют хоть и непобитые, но уже несовместимые друг с другом файлы - библиотеки, бинарники, скрипты, что угодно. Сравнивать сорта побитых состояний - такое себе занятие, потому что оба они будут приводить к непредсказуемым сбоям. Или не будут. Тут не предскажешь.
Пакман работает очень быстро, потому что не ждет fsync. Это снижает время обновления кратно, благодаря тому, что процесс не является синхронным.
Из чего хороший инженер (не ты) сделает вывод, что чем быстрее происходит обновление, тем ниже вероятность, что во время обновления произойдет сбой питания или любой другой внешний сбой.
Таким образом, из-за синхронной записи на диск, dpkg лишь увеличивает вероятность возникновения сбоя.

Такие вот дела.

И то, что pacman при данных условиях этим механизмом не пользуется, – это или дилетантизм его разработчиков…

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

А еще dpkg - это решение в себе. Если я захочу сделать A/B-систему на снапшотах, то пакман подойдет мне лучше dpkg, потому что не будет создавать оверхед на лишние операции обеспечения целостности, ибо целостностью будет заниматься файловая система. Я просто сделаю снапшот, запущу пакман, и если его работа завершилась успешно, то я буду уверен, что никаких проблем нет. А если нет - откачу ФС и начну сначала. Или не начну, по необходимости.

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

«Достаточно» – это субъективная мера.

Достаточно - это объективная мера соответствия техзаданию, дружок. «Достаточно» становится, когда система отвечает количественным и качественным требованиям.

Случаев, когда частичное или даже полное обновление вызывали поломки в Arch, которых просто не было бы при должной реализации зависимостей на уровне версий символов, – просто дофига.

Я уже объяснял, что при крупноблочных зависимостях проблема не является существенной. А в дебиане ситуация еще хуже: из-за сильной гранулярности пакетов пришлось изобретать лукап по символам, который при этом еще и не работает нормально, пример я приводил. И таких примеров можно наскрести вагон.

Название пакета с такой проблемой – в студию!

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

Ты применил фразу «полумертвый форк» к апстримному репозиторию, в котором остановилась разработка.

Во-первых, ты врёшь, клоун. Ты взял в кавычки свою собственную фразу, которой не было в моем сообщении. Я писал так: то, что привел ты называется мертвый репозиторий с архивным кодом. Или для тебя слова «репозиторий», «архив» и «форк» являются синонимами? Дружище, ты точно разработчик?

Во-вторых, давай поищем значение слова «апстрим», применительно к опенсорсу. Думаю, Red Hat сойдет за авторитетный источник:

Within information technology, the term upstream (and related term «downstream») refers to the flow of data. An upstream in open source is the source repository and project where contributions happen and releases are made.

Обрати внимание на слово happen. Не happened, лол. Репозиторий, в котором разработка умерла 11 лет назад - это максимум архив старого апстрима, но никак не апстрим, и тем более - не актуальный апстрим. Апстрим - это место, где код разрабатывается. Их может быть несколько, если у нас несколько форков, но в данном случае живой форк только один, и апстрим его лежит на гитхабе.

Слово «upstream» сам найдёшь, или помощь нужна?

Ты всерьез мне подсовываешь ченжлог деб-пакета как доказательство своей правоты? Ты сам-то его вообще читал? Итак, смотрим на дату:

Sat, 03 Dec 2016 12:20:57 -0500

Это было 8 лет назад. Тогда с момента остановки разработки rng-tools прошло всего три года. В 2017, спустя год после этого коммита в ченжлоге дебиана, разработка продолжилась в гитхабе, о чем можно узнать из [https://api.github.com/repos/nhorman/rng-tools](даты создания репозитория rng-tools), см. поле created_at. Получается, что уже на тот момент у нас был архивный реп, и живой, развивающийся код.

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

Тут всё прекрасно. На этом этапе тебя можно просто класть в палату мер и весов. Впрочем, весы и меры опциональны.