Вышел Castor 0.8.3

Это такой браузер для Gopher, Gemini и Finger

Кто все эти люди?

пробовал этот браузер?

Нет.

Lynx мне кажется удобнее этого, зато castor моднее.

Странно. Не угадал автора по теме. =)

Ещё и на GTK+. Совсем финиш.

Gopher, Gemini и Finger

тот случай, когда не знаешь вообще кто это)

Такое разве норм?

[dependencies]
gdk = "*"
gdk-pixbuf = "*"
gio = "*"
glib = "*"
glib-sys = "*"
pango = "*"
open = "*"
regex = "*"
native-tls = "*"
openssl = "*"
url = "*"
tempfile = "*"
dirs = "*"
lazy_static = "*"
ansi-parser = "0.6.5"
percent-encoding="*"
toml="*"
serde="*"
serde_derive="*"

Такое разве норм?

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

Ну у него там Cargo.lock лежит, так что норм. Но в целом да, не канон.

Там Cargo.lock лежит.

У них Cargo.lock в репе, так что не всё так страшно, но всё равно так делать, конечно, не рекомендуется.

<anekdot-mode>А Gopher это куда?</anekdot-mode>

Всё-равно не хорошо, хотя конечно и предотвратит проблемы.

Скриншот https://i.imgur.com/Rwyhb4a.png

gopherddit.com

кажется я знаю куда можно свалить с лорчика и не потерять в плане элитности

ждем install.msi

Ты же вроде раст любишь, а gtk хейтишь, так почему совсем финиш? Только из-за GTK или потому что это эталонное ненужно из палаты мер и весов?

Gtk делит любую программу на ноль, увы.

Про Gopher слышал, даже видел, но кто это: Gemini и Finger такие?

на rust

С rust-оманами все понятно, а go-хипстеры что пилят?

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

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

Есть два стула…

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

есть третий, мягкий и удобный, с ортопедической спинкой

Ох уж эти сказочники. А dependency hell не про пакеты придумали.

Ох уж эти сказочники. А dependency hell не про пакеты придумали.

Dependency hell сильно зависит от экосистемы - прежде всего от разлапистости дерева зависимостей и живости пакетов. Экосистемы питона, рупи, перла замечательно живут в пакетных репозиториях безо всяких хеллов. Go и rust, не смотря на полную неприспособленность их пакетных систем для этого, тоже опакечивают, потому что не хотят сидеть на первых двух стулях. Вот насчёт nodejs где есть пакеты типа is-odd и is-even у меня были бы большие сомнения, но её тоже опакечивают нативно. Вот и весь ответ.

А расскажи, каким магическим способом «экосистема пакетов» решит проблемы изменения api? Те же самые проблемы полезут. И решать их будет тот же разработчик, а не ты. Поэтому сказочки про третий стул оставь обычным пользователям.

И решать их будет тот же разработчик, а не ты.

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

Их будет решать мантейнер

Перестань делать мне смешно.

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

обычное дело и замечательно работает.

Да. Хороший пример в этом плане пакеты из pypi.org, которые предполагалось ставить через pip, но в gentoo нормально и лучше ставить через emerge.

ибо опакечивание модулей в репозиториях

Причём тут опакечивание, если вопрос в изменении кода программ? Да, для некоторых пакетов, которые важны для системы в целом или являются очень популярными, мантейнеры могут сделать изменения и отправить пулреквест разработчику. Могут даже сами тянуть свою ветку и заниматься его патченьем. Но это не для всех и не всегда. А если твой пакет не в офицальной репе, то каким волшебным образом «экосистема» исправит зависимости?

Так что прекращай рассказывать сказки о молочных реках и кисельных берегах.

Причём тут опакечивание, если вопрос в изменении кода программ? Да, для некоторых пакетов, которые важны для системы в целом или являются очень популярными, мантейнеры могут сделать изменения и отправить пулреквест разработчику. Могут даже сами тянуть свою ветку и заниматься его патченьем. Но это не для всех и не всегда. А если твой пакет не в офицальной репе, то каким волшебным образом «экосистема» исправит зависимости?

При чём тут пулл реквесты, какие нахрен ветки? Обсуждаемая ситуация: есть A, B и C которые зависят от D. Пусть у D две версии API. A зависит от 0.*, B от 1.*, C от *. В D находят критическую уязвимость, исправляют в последней версии.

Что происходит в ублюдской экосистеме, предлагаемой нам pip, npm, cargo, go get и компанией? Два варианта:

• в A, B, C зафризены определённые коммиты зависимости. При установке ничего не конфликтует, нам прилетают 3 версии D, возможно все уязвимые. Чтобы их исправить, нужно сначала найти все проекты что их используют, узнать уязвим ли каждый зафризенный коммит и пропатчить заново в каждом случае.
• Коммиты не зафризены. Нам прилетает N версий D, причем при каждой сборке может прилететь новая. Для A всегда прилетает уязвимая версия. Для остальных возможно исправленная, если их вовремя пересобрать. Узнать с каким конкретно коммитом D собран каждый конкретный потребитель может быть проблематично. Исправлять руками нужно каждого потребителя использующего непоследнюю мажорную ветку зависимости. C может ещё и сломаться в любой момент.

Что происходит в нормальной экосистеме нативных пакетов? Мантейнер D видит обновление, проверяет работу A, B, C с ним. В лучшем случае всё продолжает работать, потому что изменение API не затронуло A (обычная, вообще, ситуация, учитывая как легко сломать API и как мало оно сломает практике). Копия D одна, патчить ничего не нужно. Фикс уязвимости в D мгновенно прорастает во всех потребителей. Лепота. Менее общий случай - A таки ломается, но тривиально патчится. То же самое, лепота. Плохой случай, A тривиально не пропатчить. Добавляется compat версия пакета D, в ней впоследствии ОДИН раз исправляется уязвимость. Нужно следить за ещё одной версией D, но и только. Сколько бы не было потребителей, они не ломаются и не подвержены уязвимостям.

Так что прекращай рассказывать сказки о молочных реках и кисельных берегах.

Ещё раз, ты будешь спорить с тысячами опакеченных и замечательно работающих в любом уважающем себя репозитории модулей? Питон, например, в arch/aur 6k, nix, freebsd, opensuse, fedora - 3k, gentoo 2.5k, debian 2k, macports 1.5k, pkgsrc, rosa, mageia, guix - 1k. Даже хипстерские rust и go, не смотря на хитровыгнутые собственные пакетные менеджеры, вообще никак не приспособленные для опакечивания в системе, в fedora и ubuntu опакечены уже по 1-1.5k штук.

При чём тут пулл реквесты, какие нахрен ветки?

В D находят критическую уязвимость, исправляют в последней версии.

Ты вообще чем читаешь о чём я тебе пишу, жопой? Речь идёт о смене API. Уязвимость патчится без изменения API, как правило. И не ломает совместимость. Я тебе говорю о случае когда ломается обратная совместимость, привет openssl. И там был не «Фикс уязвимости в D», а исправление всех зависимых пакетов.

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

Я спорю с тобой, для которого «деньги из тумбочки».

Ты вообще чем читаешь о чём я тебе пишу, жопой?

Это прежде всего к тебе вопрос.

Речь идёт о смене API.

Про смену API я все подробнейшим образом написал, можешь перечитать ещё раз не жопой.

Уязвимость патчится

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

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