Доступна стабильная версия набора базовых системных утилит GNU Coreutils 9.0, в состав которого входят такие программы, как sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln, ls и т.д. Значительная смена номера версии объясняется наличием изменений в поведении некоторых утилит...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55865
Годно, но кому нужно ускорение wc?
Последние из могикан можно сказать. Скоро все заменит вездесущий системдЫ11!
О как, не нраицца. Но с молчаливого согласия всегда происходят такие вещи. Вспоминаем цитату о "бойся равнодушных".
Скриптам.
При сырой обработке файлов очень удобно иногда.
Кстати есть ли что-то вроде вытаскивалки столбца по пробелм, табам или запятым (про awk, perl варианты знаю).
cut?
Мне, а что? -__-
не нужно получается???
>кому нужно ускорение wcрезонно. wc постоянно использую на гигантских файлах, но в принципе пофиг быстрее оно стало или нет.
Вот sort -u убогий бы ускорили... на многогигабайтных файлах приходится самописной прогой на жабе всё делать
sort ускоряется раза в два выставлением локали POSIX
> Годно, но кому нужно ускорение wc?Мне нужно, для анализа инцидентов в продакшене.
>> В утилитах cp и install по умолчанию при копировании задействован режим copy-on-write (создание полного клона файла вместо совместного использования данных в нескольких файлах).Как-то тут в новости неоднозначно написано. Насколько я понял при копировании как раз будет совместное использование данных в одном файле вместо создания полной копии файла.
По смыслу, вроде бы, так и должно быть. Интересно, на каких ФС это будет работать. По крайней мере в btrfs есть CoW.
Единственное что всерьёз поддерживает reflink на данный момент - это БТР.
В XFS ещё есть, и типа годно для продакшна, но честно говоря у меня от XFS всегда возникает ощущение, что она прямо под ногами сломается.
А это как раз зря. Нестабильна именно бтрфс. Впрочем про ZFS никто что-то и не вспомнил, а ведь там плюшки посерьезнее и не экспериментальный как в бтре.
ZFS на боевых системах - это вообще хождение по граблям. Она в целом годится только для файлопомоек (NAS), где может жрать столько памяти, сколько захочет, да и то с трудом - багов там припасено на целую вечность.Впрочем да, по числу всяких говен внутри БТР не уступает.
> Она в целом годится только для файлопомоек (NAS)Будем считать, что коммент 2018 года, а не 2021. Сейчас на ней можно даже базы вращать, но тем не менее, O_DIRECT не поддерживается.
> где может жрать столько памяти, сколько захочетСильно не любит ООМы, ZFS kthreads крашатся вместе с юзерспейсной прогой. Это мне чувак обещал полгода назад починить. Проверить смогу только с бубунтой 22.04LTS
> Впрочем да, по числу всяких говен внутри БТР не уступает.Я бы сказал что уступает.
> Сейчас на ней можно даже базы вращать, но тем не менееИз буханки хлеба тоже можно троллейбус сделать, но тем не менее...
А так да, эта штука не умеет совмещать свою шерсть с го... простите, свой кеш с системным.
Поэтому что 2021, что 20021, на боевых системах ей не место.
нет понятия "системный кэш". Есть понятие "убогий буферный кэш в линooops образца 1992го года" и есть понятие "ARC".Оба совершенно одинаково "системные". Первый давным-давно надо зак...ть и еще осиновый кол вбить.
12309 передает всем приветы.
Тем не менее ворочается он всё-таки лучше, чем у винды.
В той тяжёлые процессы моментально эвиктят, а если эвиктить уже нечего и в основном лежит запись, оно ещё и OOM'ить умудряется, хотя можно легко отписать и выбросить.Возможно с этим связано то, что винда поотзывчивее при нагрузке на кеш - она предпочитает ронять процессы. Ну и "12309" у меня на винде в полный рост вставал на 82801AB и аналогичных, когда при нагрузке на дисковую подсистему вставало раком всё, одна из многих причин, после которых я по доброй воле на интел больше ни ногой.
Ну а ARC - это вообще не кеш, это аппликушный по сути пул, который вовремя системе при резко поднявшейся нагрузке отдать не выходит от слова "совсем". Получается та самая винда - процессы пороняем, но ни метра кешу не отдадим.
Adaptive Replacement Cache у нас оказывается не кэш, угу, ого.> который вовремя системе при резко поднявшейся нагрузке отдать не выходит от слова "совсем"
выходит, только никому чавойта оказалось нинужна, А кому было нужно - тех не подпустили близко. "Девелоперам" iX платят зарплаты не за это.
От того, что я лежащий в углу кусок говна назову Corner Crap Cache, он кешем внезапно не становится.
Нет, если отбросить софистику - чисто формально он кеш, конечно.
Так же, как у squid'а ворох лежащих файлов - тоже кеш, только совсем другого типа и применения.Или когда я часто используемые объекты из базы подгружаю и держу в памяти - это тоже кеш.
Он же аппликушный пул в памяти при этом, к обсуждаемому контексту - системному кешу/буферу дисковых операций - имеющий мало отношения, хотя мой пул тоже снижает число обращений к диску от RDBMS.Дело не в том. В случае файловых операций важно не только наличие собственно буферизации операций. Системный (ядерный) дисковый кеш/буфер умеет эвиктить по требованию, потому что тесно интегрирован с mm. Когда возрастает нагрузка на память и требуются свободные страницы - ядерный кеш моментально отдаёт mm чистые блоки, и начинает отписывать грязные блоки, чтобы их отдать - заставляя прочие части ядра подождать с аллокацией, но не вызывая при этом OOM в аппликухах. Это как раз тот системный дисковый кеш, о котором идёт речь. ARC же от ядра и mm оторван, а поэтому он свой собственный кеш ZFS, он же аппликушный пул, т.к. ZFS можно в этом контексте рассматривать как обычную не особо интегрированную аппликуху, которая с ядром в плане высвобождения блоков по требованию напрямую не работает.
Но самое страшное в ARC даже не то, что он память вовремя отдать не может.
Самое страшное именно то, что он аппликушный, и с mm не интегрирован.
Это создаёт две большие половинной длины грабли, которые бьют точно по нужным местам:
- Содержимое ARC дублируется в системном дисковом кеше
- В то время, как данные из системного кеша могут быть просто подсунуты приложению страницей без копирования самих данных (mm делает банальный page mapping), данные из ARC реально копируются перед передачей приложению, какую дополнительную нагрузку это создаёт - догадаться не сложно
> Это создаёт две большие половинной длины граблиа вот это - исключительно проблемы linoops'ей и их кастрированной реализации, а не самой fs.
Заметим, у dm'ного bcache нет ни одной из этих проблем.Разумеется, их можно было бы решить несложными путями, патчик на две странички. Но его никто и никогда не примет в ведро, а без нужных апи со стороны ведра ничего не получится. У фри все в этом плане хорошо, у соляриса тоже, а тут низя-низя, тут можно только пользоваться теми апи которые нате-на-лопате, и еще, вот, EXPORT_GPL вам в довесок, потому что вы смерды и не должны ничего грязными лаптями в ведро приносить. А если вас заставить ведро пересобирать, а не только модуль - вы ж завоете как кошка с прищемленным хвостом.
И, разумеется, никто ничего никуда не копирует в нормальных системах. Но тут нюанс: трудами диверсантов из deplhix у нас нынче ARC - compressed, причем отображает реальное состояние дел на диске (ну а диски по умолчанию таки да). Поэтому отдавать страницу из него бесполезно.
> а вот это - исключительноА вот хрен там это исключительно.
Во-первых, во фряхе ARC всё так же дублирует page cache, он же системный кеш.
Во-вторых, он так же не умеет вовремя отдавать страницы, только когда уже поздновато.
В-третьих, точно так же нет zero copy.Короче говоря это проблема ZFS, присущая ей хоть во фряхе, хоть в пингвинах.
Во фряхе нет никакого "системного кэша" в привычном лап4-м понимании вообще.> Короче говоря это проблема ZFS
нет. Это проблема ЛЮБОГО выделения памяти в любой операционной системе. Помимо fs, внезапно, еще миллион мест нуждается в больших блоках памяти при нагрузке.
Просто для линуксного buffer cache ее накостылили, сделав со стороны ведра механизмы memory pressure, для фри такие механизмы достаточно универсальные и существуют изначально, но вот к zfs их приделывать отказались альтернативно-одаренные "владельцы" кода - это ж надо было код писать, а не копипастить у дельфикса.
А за это им зарплату не платили.
Патч, в общем решавший проблему, существовал, но в апстрим принят не был - во первых NIH, а во-вторых зарплату не за это, а за копипастинг.
> Во фряхе нет никакого "системного кэша" в привычном лап4-м понимании вообще.Гонево. Всё тот же page cache.
>ZFS на боевых системах - это вообще хождение по граблям.Зфс годится на боевых серверах в некоторых окружениях. И годится от слово годно. Вместе с тем, некоторые отьявленные в душе одмины локалхостов ставят это и на ноутбуки с одним накопителем. Чем очень гордятся, представляя как придут в офис и на равных пообщаются с одмином своей локалочки. Это конечно бида.
В остальном опензфс вполне допилен и фичаст, под свои задачи.
Да блин, ну одно отсутствие zero-copy из ARC аппликухе - это уже всё, крест на тяжёлых по диску приложениях
> Да блин, ну одно отсутствие zero-copy из ARC аппликухе - это уже
> всё, крест на тяжёлых по диску приложенияхzero copy из _compressed_ arc - совершенно никому не нужен в принципе. Проснитесь, мущина - нежатые сырые данные давно немодно, пока не наступила эра всеобщего щастья в виде persistent memory devices, тяжелым по диску приложениям становится легче от уменьшения объема того, что гоняется между памятью и диском.
Да я не спорю, что он не нужен. Вместе с ZFS собственно и не нужен.
только вот CoW до юзерлэнда в ней - так и не донесли. "luck of developer resources" и так далее.Полтора раба iX заняты важным делом - отлизывают и отcacывают клиентам, которым плевать на эти мелочи. А больше уже и нет никого.
Пора бы давно уже переименовать gnu coreutils в linux-only coreutils. Так честнее. Ни в какой другой unix-like системе все равно ничего не работает и не будет.
Скоро и собираться тоже.
> Полтора раба iXШто? Причём здесь iXsystems к ZoL вообще? Они ведь старую бздовую зфс пилили.
> Пора бы давно уже переименовать gnu coreutils в linux-only coreutils.
Переименуй.
> Ни в какой другой unix-like системе все равно ничего не работает и не будет.
Скоро и собираться тоже.
Бзды, макаки, вантуз(хоть и не юникс), аикс, и даже линукс. Вообще прекрасно не_работает и не_собирается!
>> Полтора раба iX
> Што? Причём здесь iXsystems к ZoL вообще? Они ведь старую бздовую зфс пилили.Это было давно и неправда. Во времена ещё FreeNAS-а
> Это было давно и неправда. Во времена ещё FreeNAS-аони и во времена фринаса пилили больше сук, на котором сами сидели.
Вот, допилили до характерного "хрусь", и полетели вместе с суком вниз. Где уже раззявил пасть комбайн по переработке на древесное волокно.Никого и не жалко.
Отлизывать коки клиентам видать их истиное призвание, а не разработчиками fs работать. "works as intended".
Звучит как хардлинки. Но не должно быть хардлинками. I am confus
Хардлинк позволяет изменить оригинал. При copy-on-write попытка изменить копию как раз и приведёт в её созданию физически. Но это мало какие ФС поддерживают.
> При copy-on-write попытка изменить копию как раз и приведёт в её созданию физически.И вот тут мне становится интересно. А что если у меня на диске например, 55 Гб свободного места и я скопировал в качестве временного бэкапа (чтобы только проверить новый конфиг приложения) файл, ну например в 50 Гб размером. В системе ведь останется 55 Гб свободного места по прежнему? Дальше, пока я переписывал конфиг, допустим, какое-то другое приложение создало на том же разделе файл размером в 6 Гб. И тут я такой, наконец, запускаю своё приложение которое работает с оригинальным 50Гб файлом, в частности пишет в него в различные участки.
Вопрос знатокам - что будет в этом случае? CoW начнёт аллоцировать место только под модифицируемые блоки и где-то будет хранить таблицу распределения данных файла (с 0 по смещение 100500 читай тут, со с 100501 читай там, с 100502 по 100600 читай опять тут)? Или попытается целиком скопировать 50 Гб файл?
По определению только под модифицированные блоки потребуется место. Но вопрос хороший. Если файл модифицируется посредством write(), в какой-то момент вызов завершится с ошибкой "не хватает места". А вот что будет, если файл отображён в память и меняется память, куда интереснее. :)
> По определению только под модифицированные блоки потребуется место.Ну определение определяет что должны быть скопированные некие области даже если в них модифицировано несколько байт (не побайтно же копируется наверное). А каков их размер в данном случае я лично не знаю. Блок? Несколько блоков? Несколько Мб? Гб? Конфигурируется или нет?
Но если допустим только тот блок в котором изменены данные. Ну т.е. потребуется где-то рядом ещё вести таблицу размещения блоков.
Выглядит, не интуитивненько вот прямо ни разу, особо с точки зрения восстановления после сбоев.> Если файл модифицируется посредством write(), в какой-то момент вызов завершится с ошибкой "не хватает места".
Именно! Пользователь т.е. пытается перезаписать с его точки зрения уже существующий файл, тем же объёмом данных что в нём и так был. Т.е. он не ожидает что дополнительные блоки должны быть выделены. А они внезапно должны! И что он получит, no left space on device? Да это же прямо-таки have a lot of fun в отладке приключится. Или там ошибка какая-то специальная уже заложена чтобы совсем с ума не сойти?
> А вот что будет, если файл отображён в память и меняется память, куда интереснее. :)
Об этом мне даже думать страшно. Хорошо что в проде нигде нет таких дивных ФС.
> А вот что будет, если файл отображён в память и меняется память, куда интереснее. :)Получишь SIGBUS, как обычно.
В сценарии ведь не было "файл внезапно укоротился".
> Остальные алгоритмы хэширования (sum, md5sum, b2sum, sha*sum, sm3 и т.п.) реализованы путём вызова функций libcrypto.libcrypto - это из OpenSSL? Текущие coreutils от него не зависят.
Текущий ничего не знает о b2sum, sha*sum, sm3 и т.п.
Если речь, к примеру, о 8.32 из Ubuntu 21.04, то эти утилиты поставляются с coreutils, который не зависит от libssl.
А чем оно лучше бсд-утилс?
https://github.com/dcantrell/bsdutils
Всем, по части функционала.А вообще - попробуй под фрибздой собрать Ungoogled Chromium или Palemoon(уже никак). Там будет огромное количество ГНУ-измов, обусловленных чаще всего опциями, отсутствующими в бздутилсах. На фрибзде я всегда по этой причине ставил все гнутые пакеты. Человек ещё может переучиться, а вот скрипт - только с помощью человека.
>Там будет огромное количество ГНУ-измов,Согласись, что - это не проблема бсдутилит.
Это все этот попоттеринг, будь он не ладен, негодяй.
Да, это проблема гнутых тулз.
Только вот при чем тут Поцтер?
Ну он там вякал дескать: хватит вообще суппортить эти бсди. ичсх после этого такие проекты как либревульф, которые нужны, перестали блджад саппортить.
Вообще непонятно зачем собирать продукты какими-то утилитами. Есть системы сборки и даже иногда кросплатформенные и с ними порой все хорошо даже в Windows, что удивительно ... а вот Гуглу позор что никак не осилят нормальные системы сборок (и я сейчас не про make или говно маонта вроде autotools)
>Вообще непонятно зачем собирать продукты какими-то утилитамиКоллега, я изначально как раз про это.
Ну а если скриптами через боль, то да ручками. Вспоминая поттеринга недобрыми словесами.
Вот и заменяй ручкоме скрипты на сотни строк, но зато - бздутилсъ! Не то что эти ваши ГНУ.
Ты не ояень понял суть. Перечатай плиз есчо разок.
Нет, GNU coreutils проблем не имеют.Проблема есть в разрабов хрома и палемуна которые не следуют стандартам:
https://www.opennet.dev/openforum/vsluhforumID3/125351.html#84
> Да, это проблема гнутых тулз.Вы -- два телепата, или сидите за соседними столами? Я что-то за весь тред не увидел внятного описания самой проблемы, а у вас уже консенсус, ну огонь. )
>> Да, это проблема гнутых тулз.
> Вы -- два телепата, или сидите за соседними столами? Я что-то за
> весь тред не увидел внятного описания самой проблемы, а у вас
> уже консенсус, ну огонь. )Ну, из под мака оно и не видать особо ;)
Речь об использовании "башизмов-пингвинизмов" (применительно к кор-тулзам), особенно в сборочных скриптах.
Совершенно естественно, что бсд-тулзы "умеют" далеко не во все вариации пингвинячьего "а вот нашей левой пяточке захотелось ..." (см. тот же гну-cat "-A, --show-all equivalent to -vET" - именно опции -A в бсд-cat нет, есть только "equivalent").
> Совершенно естественно, что бсд-тулзы "умеют" далеко не во все вариации пингвинячьего "а
> вот нашей левой пяточке захотелось ..."Да, да, грёбанные coreutils. Как же они виноваты, что сторонние проекты завязываются на них, а не на бсд-шные аналоги.
Если это вся логика -- блин, ну что я могу поделать? Стена в метре от тебя. Разбегись хорошенько. Смотреть строго вниз. =)
>> Совершенно естественно, что бсд-тулзы "умеют" далеко не во все вариации пингвинячьего "а
>> вот нашей левой пяточке захотелось ..."
> Да, да, грёбанные coreutils. Как же они виноваты, что сторонние проекты завязываются
> на них, а не на бсд-шные аналоги.Интересно, где ты углядел какие-то обвинения?
А "логика" "гну тулзы всем лучше, потому что у них есть гну-измы, на которые любят завязываться сторонние проекты" примерно того же уровня, что и "WinAPI всем лучше для десктопа, ведь на него завязанно столько софта!" (т.е. это не логика, а обычные софизмы)> Если это вся логика -- блин, ну что я могу поделать? Стена
> в метре от тебя. Разбегись хорошенько. Смотреть строго вниз. =)Если это вся логика - мак-бук в полуметре от тебя. Разбегись хорошенько. Смотреть строго вверх.
Нет, здравый смысл заключается в том, что тут два #$*%&@ только что обсуждали наличие в coreutils "проблемы", и даже ничтоже сумняшеся добазарились до некоего консенсуса, согласившись, что в coreutils эти "проблемы" существуют. И это вообще-то таки называется "какие-то обвинения".У гнутых тулзов есть стадарт передачи опций. И опции всех утилит, разработанных в рамках проекта GNU, приведены к этому стандарту. Это -- унификация. Она упрощает жизнь как пользователей, так и разработчиков.
Но в итоге, по мнению двух #$*%&@, унификация -- это оказывается гнуизмы, и это якобы "проблема". Но по факту, проблему тут только одна: вышеобозначенный #$*%&@ испытывает проблему со сборкой софта, потому что ему хочется ставить не тот комплект утилит, что нужен, а другой. Похожий, но не тот. А если всё-таки приходится ставить нужный, то ему ой как некомфортно. И это -- ну конечно же проблема комплекта утилит, а не проекта, который на них завязался. Огонь.
Ну всё ж шито белыми нитками. П! Проблемы! XD
PS: #$*%&@ -- это конечно же Аноним. А вы что подумали? =)
Вот в чём фишка, дорогуша. Подумай об этой "проблеме" в таком ключе: куда следует послать патчи, чтобы тебе не приходилось ставить комплект гнутых утилит?Тут есть два варианта.
1) Отправить патчи в bsdutils, чтобы они начали поддерживать гнутые опции.
2) Отправить патчи в собираемый тобою проект, чтобы он начал собираться с тулзами из bsdutils.Где, при таких вводных, можно усмотреть проблемы coreutils? )
> Вот в чём фишка, дорогуша.Извини, ты не в моем вкусе.
> Нет, здравый смысл заключается в том, что тут два #$*%&@ только что обсуждали наличие в coreutils "проблемы", и даже ничтоже сумняшеся добазарились до некоего консенсус
...
> Подумай об этой "проблеме" в таком ключе:
> куда следует послать патчи, чтобы тебе не приходилось ставить комплект гнутых утилит?Подумай над тем, как отвечать в правильную ветку - "добазарились" до чего-то там они уже сильно после #18.
А для тебя я процитирую еще раз ключевый начальные вбро^W тезисы:
>>> А чем оно лучше бсд-утилс?
>> Всем, по части функционала. (далее идет про завязку сборки и гнуизмы)Ты же придумал и оспорил явно что-то свое.
> Но в итоге, по мнению двух #$*%&@, унификация -- это оказывается гнуизмы, и это якобы "проблема".Какая замечательная подмена тезиса. Унификация - это следование посикс (или другому стандарту). Отсебятина в опция гну - это гнуизмы. Заметь - я нигде не говорил, что это плохо (или хорошо).
>> А чем оно лучше бсд-утилс?
> Где, при таких вводных, можно усмотреть проблемы coreutils? )Люблю местных демаг^W Пингвиняшь - сами что-то придумают, сами что-то оспорят, защищая Великий ГНУ-(Линукс) из под макоси *g*
> Подумай над тем, как отвечать в правильную ветку - "добазарились" до чего-то там они уже сильно после #18.Камон. В правильную ветку. Серьёзно? Это весь твой тези^W вброс? =)
> А для тебя я процитирую еще раз ключевый начальные вбро^W тезисы:
>>>> А чем оно лучше бсд-утилс?
>>> Всем, по части функционала. (далее идет про завязку сборки и гнуизмы)Ну то есть типа местный анонимушка никак не сообразит, что речь идёт про следующее (а ведь в каждом сообщении есть ссылочка на предыдущее, ты прикинь):
>>> А вообще - попробуй под фрибздой собрать Ungoogled Chromium или Palemoon(уже никак). Там будет огромное количество ГНУ-измов, обусловленных чаще всего опциями, отсутствующими в бздутилсах.
>> это не проблема бсдутилит
> Да, это проблема гнутых тулзЭто -- не проблема "гнутых тулз". Это либо проблема bsdutils (они конечно поддерживают POSIX и не обязаны поддерживать стандарты GNU, однако coreutils потому и популярны, что обеспечивают обратную совместимость с bsdutils), либо проблема Palemoon (они же завязались на GNU-флаги coreutils вместо использования чисто POSIX-subset-а), либо проблема FreeBSD (в конце концов, это в ней Palemoon не собирается).
У coreutils никакой проблемы нет. И #85 кстати как раз об этом. Очень дельный комментарий, оставшийся без внимания местных оналитегов.
> Ты же придумал и оспорил явно что-то свое.
>> Но в итоге, по мнению двух #$*%&@, унификация -- это оказывается гнуизмы, и это якобы "проблема".
> Какая замечательная подмена тезиса.
> Унификация - это следование посикс (или другому стандарту). Отсебятина в опция гну - это гнуизмы.Угу. Угу. Солнышко, да ты свидетель святого POSIX-а!
Понимаю, понимаю. POSIX -- это наше всё, ну конечно. А что не POSIX -- то отсебятина. =)В общем. Ознакомься, почему оно так:
https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Sta...> Заметь - я нигде не говорил, что это плохо (или хорошо).
Ша? И как ты предлагаешь мне это сделать? Вы тут все анонимы, и хз кто из вас кто. Ты хоть сперва залогинься, солнышко. =)
>>> А чем оно лучше бсд-утилс?
>> Где, при таких вводных, можно усмотреть проблемы coreutils? )
> Люблю местных демаг^W Пингвиняшь - сами что-то придумают, сами что-то оспорят, защищая
> Великий ГНУ-(Линукс) из под макоси *g*А я вот последнее время не люблю местных демагогов. Я вообще не знаю, зачем я потратил аж целых 10 минут на это пустотрёпство с тобой. Толку с этого никакого. Сколько вам, зайкам, ни объясняй -- как об стенку горох. =)
Это как раз и есть проблема бздутилит, а не Поттера. При том, он-то к корутилсам особого отношения и не имеет.
Есчо раз. Корень проблемы в разрабах всяких хромых/лисиц которые после набросов болезного на все руки мастера подзабили на бсди. Озвучил ли он свою волю или волю покровителей в принципе не важно. Важен результат. Осталось дождаться замены утилит киссовых на что-то более монструозное/современное. И станет савсем карашо.
>по этой причине ставил все гнутые пакетыДа простят меня прогресствные коллеги, неприемлющие тренд линуксмс (кстати устоявшийся термин на забугорных ресурсах), но не проще в режиме компабилити стартануть нативное линуксовое, если оно таки нужно?
Палемун да, но имхо из геконов рулит сейчас вольныйволчара.
Вулф разве на геко?
Гекон. Но направленность волка сейчас ощутимо востребованнее луны. Имхо.
ЛибреВульф - это форк Фаерфокса. Там тот же движок - Quantum. Gecko, похоже, больше нигде сейчас не применяется.
В Thunderbird, разве что.
Тоже кваквантум, тоже телеметрия.
Форгрейт джастис, коллега.>Quantum is a Mozilla project encompassing several software development efforts to "build the next-generation web engine for Firefox users". It includes numerous improvements to Gecko, largely incorporated from the experimental Servo project. Quantum also includes refinements to the user interface and interactions.
>Servo has always been a research project. It began at the Mozilla Corporation in 2012, and its employees did the bulk of the work until 2020. This included the Quantum project, when portions of Servo were incorporated into the Gecko engine of FirefoxТаким образом имеем, что квантум - это своего рода ребрендинг гекона с включением растафанских фич из сервы. База таки геконовская. Поэтому из уважения к давним заслугам неискапы я лично по-старинке именую геконом. Номинально да, оно теперь квантум. Ну теперь и рендж ровер индусский...:)
> Всем, по части функционала.Угу
https://www.gnu.org/software/coreutils/manual/html_node/cat-...
> -u (ignored)https://www.freebsd.org/cgi/man.cgi?cat(1)
> -u Disable output buffering
$ seq 10|wc --libxo=html
<div class="line"><div class="text"> </div><div class="data" data-tag="lines"> 10</div><div class="text"> </div><div class="data" data-tag="words"> 10</div><div class="text"> </div><div class="data" data-tag="characters"> 21</div></div>$ df -h /usr --libxo=json
{"storage-system-information": {"filesystem": [{"name":"/dev/gpt/userfs","blocks":"274G","used":"98G","available":"100500G","used-percent":35,"mounted-on":"/usr"}]}
}
$ tar --version
bsdtar 3.5.1 - libarchive 3.5.1 zlib/1.2.11 liblzma/5.2.5 bz2lib/1.0.8
$ tar tf lemon_demo.zip
lemon_demo/Makefile
lemon_demo/README
lemon_demo/simple_c.re$ gtar --version
tar (GNU tar) 1.34
$ gtar tf lemon_demo.zip
gtar: This does not look like a tar archive
gtar: Skipping to next header
Опять же все (или почти все) утилиты, реагируют на SIGINFO (Ctrl+T) - это то самое "старперское ненужно, нам хватит SIGUSR!", из-за которого пользователи гну dd лет 16 извращались с pv или скриптами для того, чтобы глянуть прогресс копирования ...
Какая-то шляпа если честно.
А по мне он прав.
Что я знаю из актуальных вещей это \n, \r и \0 и там всё плохо. Libarchive это дрянь ещё та опять же. Вывод в html для wc, серьёзно?
чувак просто не знает о
dd ... status=progress
> чувак просто не знает о
> dd ... status=progressА теперь внимательно перечитай "из-за которого пользователи гну dd лет 16 извращались с pv или скриптами для того, чтобы глянуть прогресс копирования".
https://github.com/coreutils/coreutils/commit/5a74e8ae4ef3f5...
> committed Sep 14, 1997
> #ifndef SIGINFO
> # define SIGINFO SIGUSR1
> #endifа "status=progress" подвезли емпип, аж в 2015 (ну да, моя ошибка - не 16 лет, а все 18).
Причем, Ctrl+T -> SIGINFO приложению -> приложение показывает прогресс, работает и в бсдшных cp,tar, fsck, sleep, sort и т.д.
есть еще progress
https://github.com/Xfennec/progress
>>> Всем, по части функционала.
>> - пример сериализации вывода
>> - пример, как tar "умеет" в zip
>> - упоминание SIGINFO, позволяющее cp, mv, dd, tar, sort и прочему - показать статус/прогресс без "извращений"
> Какая-то шляпа если честно.Да понятно, что "не нужно!"(с)
Палемун не собирается из за нежелания поддерживать фрю разрабами о нулевой интерес со стороны всех остальных.На луну в целом плевать, а Унгуглед жаль, но ради справедливости, его и не в каждом линуксе в репах найдёшь.
Про луну согласен. Про унгуглед - вкусовщина. Предпочел бы волчару.
Ну у линукса унгугль есть хотя бы в сырцах. А вот чтобы на бсди это собрать...
Про луну согласен. Про волчару - вкусовщина. Предпочел бы унгооглед.
Про вкусовщину согласен. Про вкусовщину - вкусовщина. Предпочел бы вкусовщину.
>Палемун не собирается из за нежелания поддерживать фрю разрабами о нулевой интерес со стороны всех остальных.Ты опять стекломоя накатил, как это понимать? Палемун даже солярис поддерживает, с бздой проблемы исключительно из-за питона.
Ты опять стекломоя накатил, как это понимать? С бздой проблемы не только из-за питона. Питон2.7 ещё легко ставится, а вот с патчами и с линкером - проблемы фатальные на сегодняшний день. Особенно когда падает сборка на старых реликтах из нетшкафа. В общем - я манал это чинить, ибо палёный уже даже жидлаб не может открыть. Ещё пару лет - и станет хуже оперы-престо и нетсурфа - вместе взятых.
>Ты опять стекломоя накатил, как это понимать?Ты так говоришь, как буд-то в качественном, не паленом стекломое есть что-то плохое!?
Деды вон денатурат пили и ничего. Ишь зажралася молодежь. Еще скажи бояра плоха!
>Палемун даже солярис поддерживает
Проверять лень. Оно теперь хипстор называется. А для меня - это табу. Поверю на слово.
>бздой проблемы исключительно из-за питоняшных последователей молодых движущих сил "эволюции".
Зафиксил.
Не знаю что там на солярке но я не могу его даже на виндовс поставить.
Во-первых у меня не стоит на виндовс.
Во вторых даже если бы стоял я бы cannot be bothered этим палемуном даже в бинарниках. Ещё вирус с ним прелетит.Так что неудивительно что во фре его нет.
> А вообще - попробуй под фрибздой собрать Ungoogled Chromium или Palemoon(уже никак).
> Там будет огромное количество ГНУ-измов, обусловленных чаще всего опциями, отсутствующими в бздутилсах.Есть такая проблема.
> На фрибзде я всегда по этой причине ставил все гнутые пакеты.
Неверное решение проблемы.
> Человек ещё может переучиться, а вот скрипт - только с помощью человека.
И?
Для решение проблем с совместимостью люди придумали стандартизацию. Есть стандарт POSIX который должны держать все UNIX. В GNU есть опция "posixly correct" которая отключает расширения GNU и заставляет все программы coreutils строго следовать стандарту POSIX.
Проблема в разрабах хрома и палемуна которые не следуют стандарту POSIX в своих зборочных скриптах. Поговори с ними, пришли патчик, может и не пошлют.
>Есть стандарт POSIX который должны держать все UNIXЩа скажут расшифровку акронима...
На сколько я знаю ГНУ-опции в утилитах не противоречат ПОЗИКСУ, а лишь дополняют его новыми фичами. ГНУ-тые уважают стандарты. А опция "posixly correct" я думаю тупо отключает расширения ГНУ. Да и так ведь принято, некоторые расширения в будущем могут войти в следующую редакцию ПОЗИКСА.
Проще. Они скажут: GNU’s Not UNIX
Дескать у нас свои позиксы с шляпами и микрософтами, шатали труба ваш дом...
Чем бсд-утилс.
Как-то переносимость растворяется.
Fallback никуда не делся.
https://www.opennet.dev/openforum/vsluhforumID3/125351.html#82
https://www.gnu.org/software/coreutils/manual/html_node/Stan...export POSIXLY_CORRECT=True
export _POSIX2_VERSION=200809И аккуратно подправить все скрипты согласно стандарту POSIX 1003.1-2008
Жаль только POSIX проприетарный и платный. Ценник на стандарт мяко говоря кусючий для разработчиков СПО.
а и кому она нужна? always have been линoops-онли поделкой. Не на мертворожденный же hurd ориентироваться, в самом деле?
В целом тонко.А по хурду жаль. Хейтерам микроядер предложил бы пощупать куникс ака бб10 от почвшей яжевички. Ничего не тормозило. Да.
Ну и в итоге от монополии имеем что имеем...
мне вполне хватило хурда. Да, не поверишь, было время когда он запускался на реальном железе.Нет, он, конечно, подарил нам лучший бутменеджер всех времен - grub 0.9x, но и этот дар продолбан. Вместо него скриптованная образина умеющая только падать и разваливаться.
У меня GRUB-2 не разваливается, и скрипты его нравятся, хотелось бы больше bash функционала.
> У меня GRUB-2 не разваливается, и скрипты его нравятся, хотелось бы больше
> bash функционала.точно, это именно та херня которой крайне не хватает в загрузчике.
А меня вот всем устраивает отсутствие ненужных скриптов.
Возвращайся к истокам: в Слаке до сих пор по умолчанию lilo.
меня не интересуют истоки. Меня интересует надежный и удобный софт.
Изобретение grub - лучшее, что трэш прожект хурд принес миру.
> меня не интересуют истоки. Меня интересует надежный и удобный софт.
> Изобретение grub - лучшее, что трэш прожект хурд принес миру.Хурд хороший проект. Но ты ведь понимаешь, почему это не надо владельцами линолиупса? И почему GRUB Legacy стал Legacy, зато в каждой новой материнке УЁФи.
Собственно, никто тебе и всем желающим не мешает заниматься поддержкой GRUB Legacy. Только ни в один дистрибутив не примут и новые материнки на нём не заведутся, но это ведь мелочи жизни, правда? :)
> Хурд хороший проект. Но ты ведь понимаешь, почему это не надо владельцами линолиупса?ну чего в нем было хорошего? Корявые вырванные с мясом из линукса драйвера?
> И почему GRUB Legacy стал Legacy, зато в каждой новой материнке
> УЁФи.ничто не мешало вовремя заменить это легаси uefi кодом. Чай попроще задачка чем уместиться в 480 байт. Но никому снова было не нужно. next-next-next, ok! А автор сделался, кажется, вечноживой.
Теперь имеем уродливую этажерку из двух недо-грубов, которая иногда ломает загрузку - все как во времена lilo, недобной памяти.
> Собственно, никто тебе и всем желающим не мешает заниматься поддержкой GRUB Legacy.
> Только ни в один дистрибутив не примут и новые материнки наАвтор ни разу не собирался ни в один дистрибутив, он свои личные задачи решал.
А у меня нет документации, времени и вдохновения. Мне тут в очередной раз напомнили, что времени вообще уже не остается, пора собираться "в путешествие", а мой лист еще даже толком не дорисован.
Но тот лист рисуется не в визуалстудиях. Я когда-то выбрал не очень удачное хобби.
>> Хурд хороший проект. Но ты ведь понимаешь, почему это не надо владельцами линолиупса?
> ну чего в нем было хорошего? Корявые вырванные с мясом из линукса
> драйвера?Микроядро в нём было и есть хорошего. В прямых руках и с приложением ума на многое бы хватило. Но не нужно никому и после ударной работы на конвейере над выпуском жизненно важных квадратных колёс к незаменимым новым велосипедам у погромиздов не остаётся сил и времени. Микроядра как концепт совершенно не вписываются в базарную модель СПО. Коммерческая компания бы могла, да. QNX не даст соврать.
> Но никому снова было не нужно.
> next-next-next, ok!Понимаешь, погромизды такими уже вырастают. Они такие уже до того, как написали своей первый хелловрот. Их не интересует, что писали диды на перфокартах и по каким учились книжкам. У молодых на повестке дня программирование микроконтроллеров на жопоскрипте.
> А у меня нет документации, времени и вдохновения. Мне тут в очередной
> раз напомнили, что времени вообще уже не остается, пора собираться "в
> путешествие", а мой лист еще даже толком не дорисован.
> Но тот лист рисуется не в визуалстудиях. Я когда-то выбрал не очень
> удачное хобби.Попробуй объяснить это молодым хипсторам, которые уверены, что будут молодыми и жить вечно.
> Микроядро в нём было и есть хорошего.что хорошего в микроядре? Обычный фетиш, в теории занимательный, на практике бесполезный и неудобный в разработке.
И да, работающее не в виде "загружается!" микроядро с работающими драйверами в те же годы написали ДВА упор... заинтересованных человека. l3. Применения по факту отсутствуют. Потому что не нужно.
> Попробуй объяснить это молодым хипсторам, которые уверены, что будут молодыми и жить вечно.
зачем? Это ненужный хлам. От них ничего не останется, ведь их поделки через час уже остынут и перестанут так липнуть. А значит - выбросят и заменят новыми еще дымящими.
>> Микроядро в нём было и есть хорошего.
> что хорошего в микроядре? Обычный фетиш, в теории занимательный, на практике бесполезный
> и неудобный в разработке.Микроядро как программа при прочих равных заведомо архитектурно совершенней большого монолитного ядра. Преимущества и недостатки того и другого известны, я их не буду пересказывать. Отмечу лишь то, что микроядро и вообще малые ядра не очень совместимы с индустриальной разработкой и с амбициями молодых и глупых погромиздов. «Быстрые» инвесторы не дают на микроядра денег, а заниматься ими на энтузиазме — ну вот же на Хурд посмотри, да на Миникс: некому делать. А если денег таки дают, микроядра показывают все свои преимущества не только в теории, но и на практике (QNX). Потом, правда, туда тоже приходят индустриальные быстроинвесторы и нанимают всяких дешёвых обезьян откуда попало и начинается разложение.
Ссылка не для поха, он и так знает, а для опоздавших родиться и не читающих книги:
https://ru.wikipedia.org/wiki/Микроядро
Учение маркса истино, потому что оно верно? Ну ок, расходимся, товарищи.> «Быстрые» инвесторы не дают на микроядра денег, а заниматься ими на энтузиазме — ну вот же на
> Хурд посмотри, да на Миникс: некому делать.повторяю - незачем смотреть на выcepы академических проектов и программистов-теоретиков - они изначально делались для попила грантов а не решения каких-то реальных задач.
Смотри на l3/l4 - все в точности наоборот.
Но это нишевые проекты - и виной тому не вредные инвесторы или отсутствие энтузиастов (нашлось и то и другое) а неудобство технологии для универсальных применений, подобных линуксу.
А для неуниверсальных всех победил RTOS. Потому что ради одной программы без многозадачности не нужна операционная система, пары библиотечек хватило.
А все остальное на соседнем ядре под обычным линуксом.
Инвесторам и прочим рулевым айтишной индустрии заведомо не нужны ни высокая надёжность и безопасность, ни долговечность продукта. Им нужно регулярно каннибализировать старый продукт и на смену ему выпускать новый такой же, принуждая потребителя обновляться. В этом суть айтишного бизнеса, а не в создании хорошей программы. Микроядра и другие программы схожего назначения (надёжные, безопасные, отказоустойчивые по конструкции) не просто не нужны этой индустрии, но и вредны для неё.
Нужны, почему не нужны. Можно уволить всех макак из поддержки же ж, если оно само стоит.Проблема что не стоит, и не само, а требует еще более дорогих специалистов, которые еще и не могут обосновать внятно для бизнеса свои хотелки - только поют мантры про всесильное учение истинное потому что верное.
С моей личной точки зрения у микроядра есть только очевидные фатальные недостатки, и ровно ноль преимуществ на современных архитектурах. Возможно, во времена каких-нибудь Tandem'ов где надежность системы начиналась с уровня железа, оно имело бы смысл. Но оно и на них не работало.
Планирование, создание и затем сопровождение и развитие микроядра и концептуально схожих малых ядер и сопутствующей им инфраструктуры требуют широкого кругозора, фундаментального образования, большого опыта, системного подхода и системного же мышления, то есть людей уровня и масштаба Кнута, Вирта, Танненбаума. Это не уровень типичных погромиздов на зарплате и тем более не уровень бангалорских ногоруких.Индустрия ПО, как я выше писал, не заинтересована в продуктах, которые не требуют постоянных обновлений. Как ты понимаешь, микроядро именно из таких программ.
Потенциальный потребитель микроядер, который может извлечь себе из них наибольшую пользу и получить экономию — разное производство из реального сектора и вообще бизнес. Но содержать собственную команду высококлассных разработчиков, описанных в первом абзаце, на пожизненной работе никто себе не может позволить. Вместо этого заказывают себе ПО у индустрии, которая имеет свой интерес, находящийся в противоречии с концепцией микроядра.
> Нужны, почему не нужны. Можно уволить всех макак из поддержки же ж,
> если оно само стоит.Бангалорская поддержка стоит рупь за пучок, причём даже не надо импортировать ыкспердов из Бангалора, они прямо оттуда, из навозной кучи работают. И даже хорошо, что поддержка никудышная! Клиент раз обломается в дешифровке лепета кумаров, два раза, три раза — и придёт к белому человеку в контору подписывать договор на поставку нового, луТшего, инновационного и прогрессивного.
Но представь себя директором завода. Тебе не только не подходит бангалорская поддержка, но и сами обновления хуже инфляции и ремонта. Для тебя как производственника самый лучшая, идеальная автоматика — риалтаймовая и микроядерная. Пусть она тикает не так часто, как модно-молодёжная на Цоре-100500, зато всегда одинаково и в ней нечему ломаться, потому что она простая и прямая, как хелловорлд школьника. Неспроста, знаешь ли, при станках и машинах кое-где работают древние писюки с ДОСиком на борту.
Эта проблема в чём-то перекликается с проблемой Кобола и миллиардов написанных на нём программ. Кобол изобрели специально для финансовых, банковских и прочих прикладных специалистов, отлично знающих свою предметную область и немного умеющих программировать, а не для профессиональных кодобезьян, которые никакую предметную область не знают и знать никогда не будут. Когда придумали Кобол, знали нужды людей, занятых там, где этот Кобол будет применяться. Однако отрасль индустриального производства ПО не заинтересована в том, чтобы однажды написанное работало вечно. У неё есть дешёвые рабы и, когда никто не видит, розги и плети от инвесторов и акционеров. Они хотят, чтобы ты выбросил всё то, что у тебя хорошо работает уже полвека, и раз в пару лет заказывал переписывать, исправлять и обновлять ПО, то есть платил не один раз ещё при дидах после войны, а регулярно.
Кому ты там куникс хотел предложить? Куникс это не про щупать ;)
Ыыы вот знал, знал, что заострят внимание! Кросаффчег!
А аообще конечно: адъ, развратъ и погибель. Одному крайняя плоть кругом мерещится, второму оральные ласки женщине...
Но в целом для пубертатов - это намана. Сам таким был:)Посоны, посетите годный шалман. Отдатите дешевле, чем нонешние прынцессы требують за кекс (при этом почти всегда в нем ничего не умея), будете в ласке и внимании, мозг никто не вынесет. А на пару дней полегчает! Донны аппрувед.
/me пошёл изучать ассортимент Ishuzoku Reviewers
/ме избегал бы суккубов:)
> Возвращайся к истокамТы так сказал, как буд-то это хуже новомодных секуре бутов.
Приятно когда в таких вещах которые используются повсеместно проходят оптимизации, заметно ускоряющие операции.
Где-то сразу после обновления по всей планете снижается на гигаватты потребление электричества.
Ради сваботки придется пожертвовать эколохией во благо криптоанархизму11!
Годовое потребление корутилсов на уровне двух лампочек накаливания. Вот бы из браузеров жс выкинули, тогда вообще ледники обратно замёрзнут.
А на что жс предлагаешь заменить?
ни на что, зачем вобще в браузере что-то выполнять? Он должен отображать документ согласно разметке.
Что полезного делает сейчас жс?
На server side. А на клиенте предопределённые виджеты.
Wasm. В нём сборщика мусора нет. Только хардкор.
А зачем они собственно нужны, если линукс уже подделка на тему виндовс а не юникс, уже логи читаем парсим и не ними а журналДебилом