The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Компания Canonical представила утилиту etrace и добавила поддержку LZO в snap

01.11.2020 09:44

Компания Canonical представила утилиту etrace, предназначенную для отслеживания активности во время выполнения приложения. Программа напоминает утилиты strace и ltrace, и также использует ptrace в процессе работы. Код распространяется под лицензией GPLv3.

Основным назначением etrace является отладка и анализ приложений, запускаемых из пакетов в формате snap. Утилита позволяет быстро оценить какие программы и какие файлы используются при запуске snap-пакета. Предоставляются две команды - "exec" и "file", позволяющие получить информацию об обращении к файлам и выполнению других процессов. В первом случае отслеживается работа системных вызовов, связанных с работой с файлами, а во втором перехватывается семейство системных вызов execve.


   $ etrace exec telegram-desktop --no-window-wait
   56 exec calls during snap run:
        Start   Stop     Elapsed       Exec
        0       95417    95.417022ms   /snap/bin/telegram-desktop
        14991   20267    5.276918ms    /usr/lib/snapd/snap-seccomp
        38522   39649    1.127004ms    /usr/lib/snapd/snap-device-helper
        ...
        88778   93460    4.682064ms    snap-update-ns
        95417   100613   5.196094ms    /usr/lib/snapd/snap-exec
        100613  212749   112.13684ms   /snap/telegram-desktop/1708/bin/desktop-launch
        105275  107645   2.36988ms     /usr/bin/date
        115309  118616   3.30615ms     /usr/bin/getent
        ...
        120239  122471   2.232074ms    /usr/bin/md5sum
        192968  196316   3.347873ms    /usr/bin/head
        199725  203120   3.395795ms    /usr/bin/ln
        204533  207864   3.331899ms    /usr/bin/rm
        208199  211477   3.277063ms    /usr/bin/ln
        212749  6000720  5.787970066s  /snap/telegram-desktop/1708/usr/bin/telegram-desktop
   Total time:  6.000720024s
   Total startup time: 6.008373172s

Утилита также может применяться для определения узких мест в производительности графических приложений на базе X11, и показывает какое время приложение затрачивает на инициализацию до начала отрисовки окна. Дополнительно доступны специфичные для snap опции "--reinstall-snap" и "--clean-snap-user-data", дающие возможность перед запуском переустановить snap-пакет для проведения измерения без учёта кэша или удалить связанные с пакетом пользовательские данные.

Кроме того, компания Canonical объявила о реализации поддержки в snap-пакетах алгоритма сжатия LZO. Алгоритм LZO сфокусирован на достижении максимальной скорости распаковки, ценой увеличения размера итогового архива. При тестировании пакета с Chromium применение LZO вместо используемого по умолчанию алгоритма XZ позволяет в 2-3 раза ускорить запуск snap-пакета за счёт сокращения времени на распаковку образа SquashFS.

В частности, первый запуск Chromium, установленного из обычного deb-пакета, занимает около 1.7 секунд. Первый запуск из snap при использовании XZ занимает 8.1 сек, а при использовании LZO - 3.1 сек. При повторном запуске, в условиях когда данные прокэшированы в памяти, время запуска составляет 0.6, 0.7 и 0.6 сек. соответственно. Размер snap-пакета при использовании LZO увеличился со 150 до 250 МБ.

  1. Главная ссылка к новости (https://ubuntu.com//blog/intro...)
  2. OpenNews: Выпуск strace 5.3
  3. OpenNews: Выпуск системы динамической отладки SystemTap 3.3
  4. OpenNews: Oracle перелицензировал код DTrace под GPLv2
  5. OpenNews: Для Linux представлена система динамической отладки BPFtrace (DTrace 2.0)
  6. OpenNews: Компания Oracle намерена переработать DTrace для Linux с использованием eBPF
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53998-etrace
Ключевые слова: etrace, debug
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (71) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:47, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    1. Почему не zstd?
    2. Не пора ли deb пакеты начать сжимать с помощью zstd, вместо xz?
     
     
  • 2.3, lockywolf (ok), 09:53, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему не  brotli?
     
     
  • 3.42, Аноним (-), 15:09, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Пачём broccoli?
     
  • 3.66, Аноним (1), 21:15, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    zstd более эффективно, плюс brotli делали под web
     
  • 2.18, Аноним (-), 11:12, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Ааа! Что они делают. Сколько лет снапу и попытались решить проблему со скоростью запуска, и взяли не zstd, и даже не lz4, а lzo. В 2020-м. Они даже не пытаются делать вид, что снап не постигнет участь прошлых велосипедов Canonical.
     
     
  • 3.22, Аноним (22), 11:36, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Велосипед Ubuntu всё ещё ездит. Желаете снапу той же участи? :)
     
     
  • 4.53, НяшМяш (ok), 17:21, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Это та убунта, где к дебиану вместо колёс Unity + Upstart прикрутили две красных шляпы?
     
  • 3.60, zstd (?), 19:16, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так-то lzo быстрее zstd.
     
     
  • 4.64, Аноним (64), 21:04, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Правда, сильно менее эффективен
     
  • 2.26, timur.davletshin (ok), 11:57, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Неплохо по уровню настраивания уровня компрессии, но на всяких там армах дико тормозит даже на слабых настройках. Плюс, декомпрессия на уровне ядерных алгоритмов, особенно сильно пожатого, приводит к блокировке всего запущенного от усера. Например, тот же pulse может исчерпать свои буфера и начать икать при банальном запуске софта из снапа! Я не говорю, что это сугубо специфичная проблема для снапа (установи корень на btrfs+zstd в макс. уровне сжатия и порадуйся диким тупнякам юзерспейса при каждом обращении к FS), просто вынос сего дела на ядерные алгоритмы имеет свои серьёзные минусы.
     
     
  • 3.29, cjaushe4ka (?), 12:32, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    не наблюдаю тормозов на arm64, orange pi 3.

    плюс не вижу проблем с btrfs + zstd на hdd диске, x64, 5.4. зато оно дает очень приличную компрессию.

     
     
  • 4.30, timur.davletshin (ok), 12:51, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Значит, ты просто его не бенчмаркал. Даже Canonical увидела тормоза и решила, что надо что-то не просто делать, а выносить это в дефолт. А ты не видишь...
     
     
  • 5.38, Аноним (38), 14:06, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ДАЖЕ
     
  • 5.39, Аноним (1), 14:09, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    fedora вынесла btrfs в дефолт
     
     
  • 6.48, timur.davletshin (ok), 16:31, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > fedora вынесла btrfs в дефолт

    Причём тут Федора? Зюзя это сделала на годы раньше. Но она тоже не при делах.

     
  • 3.35, Shevchuk (ok), 13:53, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > zstd в макс. уровне сжатия

    Это очень странный способ готовить zstd в ФС.
    На высоких уровнях сжатия он становится медленным, как xz (при сжатии; при распаковке по-прежнему быстр) — естественно, будут тормоза. Для сжатия на лету годятся первые 3-4 уровня (опередить lzo/lz4 по сжатию хватит и 1 уровня), дальше уже только если у вас всё рассчитано и вы очень хорошо понимаете, что делаете, на мой взгляд.

     
     
  • 4.47, timur.davletshin (ok), 16:30, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за справку, я его использую с момента попадания в ядро. Тестировал на разных размерах блока, уровнях сжатия и архитектурах. ZSTD оставил на дефолтных настройках и только на зашифрованных внешних дисках с выравненным размером блока. Да и вообще там быстродействие не критично.
     
     
  • 5.51, Shevchuk (ok), 17:04, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да я без претензий же (минусы не мои) — понятно, что макс сжатие это для бенчмарка : ) Написал просто чтоб другие так в живых системах не делали.
     
     
  • 6.65, Аноним (1), 21:15, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    максимальное сжатие это сценарий для deb или snap пакета.
    для среды с активным io - лучший сценарий как вы написал это уровень сжатия 3 для zstd
     
     
  • 7.68, timur.davletshin (ok), 23:17, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Приболел? Deb распаковывается один раз - при установке, а из snap распаковывается при холодном старте и каждый раз, когда нужный объект вытесняется из кэша FS. Алгоритм высокой степени сжатия в первом случае оправдан, а во втором скорость более приоритетна. Ждать несколько секунд для запуска Хрома на SSD - это сраный стыд, когда из несжатой FS он стартует у меня на счёт "раз-два".
     
  • 2.36, Аноним (36), 14:03, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    По-моему, что 1.7 с, что 8.1 с - не критично. Приемлемо вплоть до 10 c запуска тяжёлого приложения. Не стоит на это мастурбировать.
     
     
  • 3.40, iPony129412 (?), 14:26, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну когда десять секунд калькулятор запускается — это так себе.
     
     
  • 4.57, Сишник (?), 17:36, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну а что, калькулятор на электроне в снапе вполне себе сложный тяжёлый софт, включающий в себя сочетание тысяч человеколет напряжённого труда уважаемых профессионалов, взвешенные решения и передовую архитектуру, можно и почтить их тяжёлый труд 8.1с паузой.
     
  • 2.58, liberal (?), 18:05, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > zstd

    Архиватор Попова значительно лучше этой устаревшей поделки!

     
  • 2.76, fuggy (ok), 19:49, 02/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хоть я и предпочитаю xz для долговременного архивирования. Они что не знали, что их образы для запуска и требуют быстрого разархивирования, но выбрали xz. А теперь бросаются из крайности в крайность, когда для ускорения меняют медленный сильножмущий на быстрый, но не жмущий. На zstd менять было бы логичнее.

    В Arch GNU/Linux вон даже для простых пакетов перешли на zstd без большого увеличения размера.
    > Пересборка пакетов в формат zstd привела к суммарному увеличению размера пакетов на 0.8%, но обеспечило ускорение распаковки на 1300%

    Результат.

     

  • 1.5, Аноним (5), 10:17, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А смысл почти в два раза увеличивать размер пакета чтобы сэкономить пару секунд при первом запуске и какие-то несущественные доли секунд при повторных запусках.
     
  • 1.6, Аноним (6), 10:26, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    >При тестировании пакета с Chromium применение LZO вместо используемого по умолчанию алгоритма XZ позволяет в 2-3 раза ускорить запуск snap-пакета за счёт сокращения времени на распаковку образа SquashFS.

    А нормальный пакет во сколько раз бы ускорил запуск хромого, по сравнению со снапом? Может пора уже закопать стюардессу?

     
  • 1.7, m.makhno (ok), 10:31, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Снапы, контейнеры - нафига они для обычных приложений? Как-то это не по UNIX-way.
     
     
  • 2.8, Аноним (8), 10:42, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Это ubuntu-way. Видимо попытка уменьшить зависимость от debian. Но увы, все что пилит Canonical - рано или поздно оказывается в мусорке - upstart, mir, unity. И эта их идея - перетащить все пользьовательское ПО в snap пойдет туда же.
     
     
  • 3.15, Аноним (15), 11:10, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вот Юнити очень жаль, да.
     
     
  • 4.32, Аноним (32), 12:55, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На самом деле нет.
     
  • 3.16, Аноним (16), 11:10, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Нет, это не попытка уменьшить зависимость от Debian, им пофиг Debian или нет, та... большой текст свёрнут, показать
     
     
  • 4.44, Аноним (44), 15:51, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У меня есть фреймворк Бросаешь ссылку на репозиторий ну или на архив с исходни... большой текст свёрнут, показать
     
     
  • 5.52, n00by (ok), 17:07, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А Вы случаем не планируете в ближайшее время опубликовать (ссылку на) сам проект?

    P.S.
    Интересно, кто и зачем минусанул комментарий выше, не потрудившись пояснить несогласие?


     
     
  • 6.70, Аноним (44), 00:49, 02/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https github com KOLANICH prebuilder py Заранее предупреждаю, о нюансах 1 ... большой текст свёрнут, показать
     
     
  • 7.74, n00by (ok), 16:01, 02/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > https://github.com/KOLANICH/prebuilder.py

    Благодарю. Не пишу на Питоне, но немного его читаю, в данном случае интересен сам подход (если честно, мне раньше было не ясно, почему нет подобных инструментов, а оказывается, я просто про них не знаю).

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

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

     
     
  • 8.77, Аноним (44), 10:59, 04/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот им и пришлось, загрузившись с livecd так как апт сам сломался в результате ... текст свёрнут, показать
     
  • 2.12, Аноним (16), 11:01, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А им пофиг, вся задумка, чтобы сами разрабы опакечивали в снапы, а снапы по заду... большой текст свёрнут, показать
     
  • 2.14, ИмяХ (?), 11:08, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В макОС-Х все приложения такие, но никто им не говорит, что это не по юниксу
     
     
  • 3.19, Sluggard (ok), 11:16, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > никто им не говорит, что это не по юниксу

    Потому что маководы вообще не в курсе, о чём речь?

     
  • 3.20, Lex (??), 11:23, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В яблоке вообще стараются про юникс не вспоминать.
    Хотя, как только что-то серьезное, там самый простой путь - через консоль, как и во многом другом юникс-подобном.

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

    Очень нагляден до недавних пор был Slack - в нем не было возможности выхода из аккаунта, а «принятые» на яблоке способы удаления и установки приложения... не приводили к сбросу параметров входа и приходилось лезть в системные папки чисто чтобы вручную вычистить его мусор даже для возможности входа в другой акк :)))

     
     
  • 4.56, НяшМяш (ok), 17:30, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  В яблоке вообще стараются про юникс не вспоминать.

    При этом не забывая макось сертифицировать как юникс.

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

    Если не запускать из-под рута, то гадят только в домашней папке и tmpfs. Неожиданно так же и на линуксе.

    > а «принятые» на яблоке способы удаления и установки приложения... не приводили к сбросу параметров входа и приходилось лезть в системные папки чисто чтобы вручную вычистить его мусор даже для возможности входа в другой акк

    Внезапно, если я на бубунточке сделаю apt remove slack и переустановлю - то это тоже к сбросу параметров не приводит. И так же придётся лезть в ~/.config/Slack и его удалять. Даже в винде работает - деинсталляция приложения не удаляет пользовательских файлов. Наезд тут в том, что на макоси путь чуть длиннее - ~/Library/Application Support/Slack ?

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

     
     
  • 5.67, Аноним (64), 21:23, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты часть про "вроде бы в отдельных каталогах лежат" решил (тактично) не читать?
     
  • 5.73, Lex (??), 11:29, 02/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/

    > Если не запускать из-под рута, то гадят только в домашней папке и
    > tmpfs. Неожиданно так же и на линуксе.
    > Внезапно, если я на бубунточке сделаю apt remove slack и переустановлю -
    > то это тоже к сбросу параметров не приводит. И так же
    > придётся лезть в ~/.config/Slack и его удалять. Даже в винде работает
    > - деинсталляция приложения не удаляет пользовательских файлов. Наезд тут в том,
    > что на макоси путь чуть длиннее - ~/Library/Application Support/Slack ?

    Мне без разницы, как оно на "бубунточке".
    С десяток вложенных каталогов. Вы предлагаете всю т.н домашнюю папку нафиг выпиливать при каждой переустановке каждого приложения только потому что приложение гадит вне своего собственного каталога ?)
    "Наезд" тут в том, что установка-удаление обычных приложений на макси - это обычное перетаскивание его каталога, которое, "теоретически" должно полностью вычищать весь мусор приложения из системы.
    В любом случае, это прямо противоречит заученным мантрам маководов, согласно которым, все параметры и данные приложения хранятся внутри него самого и обычное перетаскивание его в корзину означает полное и бесследное его выпиливание из системы, не оставляющее какого-либо мусора.

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

    Где КОНКРЕТНО я утверждал, что на других осях( и на каких конкретно ) сделано лучше ?
    Но на яблоке это сделано реально ужасно. И, кстати, наличие питона и рубина искаропки нередко приводит к возможности работы на яблоке даже вирусов-скриптов.

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

     
  • 2.37, Аноним (36), 14:05, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Снапы, контейнеры - нафига они для обычных приложений? Как-то это не по UNIX-way.

    Ну не все же приложения так представлены. Я думаю, что если  5 - 10% софта так будет ставится, то приемлемо.

     
  • 2.72, max (??), 09:37, 02/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Забыли что-ли, как нерадивые контрибьюторы удаляли /usr или ещё что-нибудь. И это только непреднамеренные пакости, а существуют ещё злонамеренные.
     

  • 1.9, Иваня (?), 10:50, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    На Go'шечке О - отлично!
     
     
  • 2.17, Аноним (15), 11:11, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там, блин, обмазка из os/exec.
     

  • 1.10, Аноним (10), 10:54, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    оо Круто, давно пользуюсь снапом, очень удобен в упаковки и использовании.
    Но конечно не без своих сложностей. Если надо упаковать что что требует доступ файлам из системных каталогов то здесь надо очень осторожно.
     
     
  • 2.25, timur.davletshin (ok), 11:54, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Свой "магазин" запилить можно или обязательно только проприетарщиной от Canonical пользоваться для распространения? Не кажется ли это как-то не очень open source?
     
     
  • 3.28, Аноним (28), 12:24, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Снапы не привязаны к магазину, как собственно и deb-пакеты, т е вы можете испол... большой текст свёрнут, показать
     
     
  • 4.31, timur.davletshin (ok), 12:52, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > использовать ppa на launchpad.net, но можете запилить и свой собственный ppa,
    > и распространять также самостоятельно, snapstore это просто очередной своеобразный launchpad,
    > только для снапов.
    > Но если вы разработчик Свободного ПО, то ваша задача выкладывать сорцы, вы
    > не обязаны лепить снапы, если не хотите, можете просто по старинке
    > выкладывать статически слинкованные бинари тарболами, "для потестить" в любом дистре этого
    > достаточно, и не надо городить огород с рантаймами и прочим шлаком,
    > а нативные пакеты - это дело майнтейнеров конкретных дистрибутивов, на этом
    > фоне, жалобы на необходимость самим разработчикам "собирать для всего зоопарка линуксов"
    > мне непонятны и выглядят как тупое нытьё-наброс.

    Не-не, не надо мне этой демагогии. Где исходники магазина?

     
     
  • 5.59, Аноним (59), 18:44, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    gt оверквотинг удален Я вам ответили конкретно на ваш вопрос Свой магазин з... большой текст свёрнут, показать
     
     
  • 6.61, timur.davletshin (ok), 19:53, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Напомни версию, с которой snap стал поддерживать магазины (репозитории) отличные от Ubuntu'овского? Чисто так, конкретно версию и опции для этого. А то языком чесать тут многие мастаки.
     
  • 6.69, timur.davletshin (ok), 23:18, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Собственно, что и следовало доказать )))
     

  • 1.11, Аноним (15), 10:57, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть они сами намекают, что snap - небезопасно и не вызывает доверия.
     
     
  • 2.27, Аноним (27), 12:03, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть они сами намекают, что snap - небезопасно и не вызывает
    > доверия.

    Нет, они прямо говорят, что ответственность за то, что будет лежать в снапах, это не их дело, потому как снапы будут упаковывать не они, они конечно же будут создавать цирк безопасности в своём снапсторе, типа как гугол в своём, когда какой-нибудь энтузиаст спалит очередную прогу на зловредстве, они дружно сделют сердитую мину, и погрозят пальчиком, сделая вид, что они озабочены проблемой и всенепременно "перепроверят" весь этот store на предмет злодеяний:
    -Ата-та, фу такими быть, Каноникал за секурность хомячков!
    И всё в таком духе, у гуголя же прокатывает!

     
     
  • 3.49, Аноним (8), 16:50, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наконец-то в этих ваших линуксах появятся нормальные вирусы, а значит и антивири для хомячков. Все будут при деле
     
     
  • 4.50, Аноним (50), 16:59, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А какие антивири не работают на линуксе? Вроде, все без исключения, имеют линукс версии. Или ты о чём-то другом? Или, наверное, ты пропустил момент, когда линукс стал чересчур популярным? Лет 10 назад так примерно, да.
     

  • 1.13, Аноним (15), 11:01, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не, ну хотя бы libptrace прикрутили, а то вызовы через Exec() это уж совсем смешно.
     
  • 1.21, timur.davletshin (ok), 11:29, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я так понял, что там добавлена поддержка подготовки образов с другим алгоритмом сжатия, сами алгоритмы и возможность монтирования образов там всегда были, т.к. это ядро монтирует образ squashfs со специально оформленным содержимым. Сама идея здравая с поддержкой алгоритмов, но было бы неплохо вообще присобачить возможность или конвертации или выбора алгоритма в момент установки пакетов. Например, для дешёвых VPS место более критично, чем пара-тройка секунд холодного старта.

    P.S. snap сосал по скорости всегда. Лично я даже не понимал, как им вообще на постоянной основе можно пользоваться. Я первый раз после запуска Хромого даже успел подумать, что у меня что-то не так в системе, пока он раздупливался. И это на SSD. Зоопарк этих разных версий того же core... Ставил Gimp - почти гиг места отожрал.

     
  • 1.34, Аноним (32), 13:02, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Компания Canonical представила утилиту etrace, предназначенную для отслеживания активности во время выполнения приложения. Программа напоминает утилиты strace и ltrace, и также использует ptrace в процессе работы

    …но при этом лишена фатального недостатка!

     
  • 1.41, Аноним (41), 15:04, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Flatpak с головой хватает
     
     
  • 2.45, Аноним (45), 16:17, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот вам Snap pздюки https://flathub.org/home
     
     
  • 3.55, Аноним (55), 17:28, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    AppImage же https://appimage.org/
     
  • 2.62, timur.davletshin (ok), 19:55, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Flatpak с головой хватает

    Хватало бы, если бы там была поддержка серверного ПО и скриптов раннего запуска.
    И это только для начала разговора...

     

  • 1.54, Аноним (55), 17:27, 01/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Алгоритм LZO сфокусирован на достижении максимальной скорости распаковки, ценой увеличения размера итогового архиваю.

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

     
     
  • 2.63, timur.davletshin (ok), 19:59, 01/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Алгоритм LZO сфокусирован на достижении максимальной скорости распаковки, ценой увеличения размера итогового архиваю.
    > Тогда нужно брать TAR без сжатия — скорость распаковки будет бешенная, ценой
    > увеличения размера итогового архива.

    Тогда ленивые пускальщики докеров и некстклаудов в vps'ках повесятся. Я и так не знаю, как они эту новость восприняли без валокордина.

     

  • 1.71, ZULUL (?), 00:59, 02/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не нужно. Самым первым делом на любой убунте делают sudo apt purge snapd, и все проблемы с долгим запуском софта пропадают. Естественно нужно будет установить из apt замету тем программам что были захреначены в snap, емнип это системный монитор и калькулятор в гноме (заранее посмотрите на вывод snap list).
     
  • 1.75, Аноним (75), 18:12, 02/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    snap это такая поделка виндузятников неудачников

    именно благодаря использованию snap внутри debian bosh недавно проиграл большой тендер

     
  • 1.78, And (??), 15:43, 07/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мда. Это ж чтоб сами проверяли какой адвари натащили в систему внутри снэпов?

    Спасибо, мне бы тогда без снэпов, совсем.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру