LINUX.ORG.RU

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

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

Crocodoom ★★★ ()

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

Нет.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

Difrex ★★★★ ()

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

praseodim ★★★★ ()

Gopher, Gemini и Finger

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

xperious ★★ ()

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

[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="*"
theNamelessOne ★★★★★ ()
Ответ на: комментарий от theNamelessOne

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

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

WatchCat ★★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

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

RazrFalcon ★★★★★ ()
Ответ на: комментарий от WatchCat

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

DarkEld3r ★★★★★ ()

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

scanner ()
Ответ на: комментарий от RazrFalcon

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

WatchCat ★★★★★ ()

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

gopherddit.com

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

ждем install.msi

Shulman ()
Последнее исправление: Shulman (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

peregrine ★★★★★ ()

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

на rust

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

Kolins ()
Ответ на: комментарий от WatchCat

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

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

slovazap ★★★★★ ()
Ответ на: комментарий от WatchCat

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

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

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

WatchCat ★★★★★ ()
Ответ на: комментарий от WatchCat

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

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

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

WatchCat ★★★★★ ()
Ответ на: комментарий от WatchCat

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

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

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

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

WatchCat ★★★★★ ()
Ответ на: комментарий от WatchCat

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

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

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

grem ★★★★★ ()
Ответ на: комментарий от slovazap

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

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

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

WatchCat ★★★★★ ()
Ответ на: комментарий от WatchCat

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

При чём тут пулл реквесты, какие нахрен ветки? Обсуждаемая ситуация: есть 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 штук.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

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

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

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

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

WatchCat ★★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от WatchCat

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

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

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

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

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

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

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

slovazap ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)