Представлен набор патчей для GCC, позволяющий генерировать исполняемые файлы в формате APE (Actually Portable Executable), которые при связывании приложений со стандартной Си-библиотекой Cosmopolitan дают возможность создавать универсальные сборки приложений, запускаемые в разных операционных системах. Исполняемый файл в формате APE не привязан к отдельным платформам и может быть запущен в Linux, FreeBSD, macOS, OpenBSD, NetBSD и Windows...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59446
> GCC 11.2Ну то есть в апстриме можно не ждать.
Баян, версия 2023 года.2009 https://www.opennet.dev/opennews/art.shtml?num=23948
Ну и в общем, попыток много было https://en.wikipedia.org/wiki/Fat_binaryВсе они дохнут из-за того, что никто не хочет переписывать функционал
уже существующих библиотек, типа Boost, Qt, WxWidget, GMP, OpenMPI, ...И ваще, уже 100500 лет есть Java ... java -jar ля-ля-ля.jar и всё щастливы!
java давно протухла
Мужики-то и не знают.
Кстати java в основном используется на серверах. под десктоп мало где используется. У обычных пользователей установленная java - редкость
Миллионы игроков в Minecraft & Runescape для тебя это шутка?
> Миллионы игроков в Minecraft & Runescape для тебя это шутка?Хех... Даже пришлось гуглить....
Эти миллионы игроков используют не старый оригинальный майнкрафт на джаве, а Minecraft Bedrock, который не имеет к джаве отношения вообще. А то и современный Minecraft RTX.Вы что, думаете что майнкрафт для Wii U, Switch, PS4/PS5, Xbox всех вариантов, iOS и тп на джаве? Миллионы игроков - это на всех платформах вместе, а не только винде. Безо всякой джавы. Да и под виндой основная масса на Bedrock для нормального освещения и прочего...
Ты серьёзно так считаешь? Ожидаемый контраргумент, но Java-версия попросту незаменима для линуксоидов и любителей поиграть с модами, а это всё ещё миллионы игроков, Curseforge не даст соврать.
> Кстати java в основном используется на серверах. под десктоп мало где
> используется. У обычных пользователей установленная java - редкостьЕсть не мало софта и на десктопе. На винде - немного, но тоже есть.
> У обычных пользователей установленная java - редкостьLibreOffice
> Кстати java в основном используется на серверах. под десктоп мало где
> используется. У обычных пользователей установленная java - редкостьИз тех, что у меня есть: Netbeans, Eclipse, Android Studio, Kubios+MatLab, Maple, OWASP, Azureus, BikeXperience
Не смотря на "жирность" самой жавы, тормознутость и требование к ресурсам,...
только Sun Microsystems и Java добились реальной аппаратной независимости,
портабельности и многоплатформенности.
При известных недостатках Явы на десктопе вообще то это один из немногих способов сделать portable придожение, да под несколько ОС одновременно, и с вменяемой производительностью, и вменяемыми аппетитами к ресурсам, по сравнению с альтернативными решениями.
В общем, будет еще и жить,и развиваться.
Конечно будет. Она в кровавом энтрерпайзе еще тысячу лет будет работать. Тысячи сеньоров-помидоров не откажутся от спринга
Настолько "щасливы"... Про "запускать только под Java под Windows" ни разу не слышали? Не часто, но сталкивался. Или "не так" под разными ОС работает приложение (Винда, Линь (в самих линях не сталкивался между дистрибутивами)).
Так что эта многоОСность - весьма условна.
К слову, конкретно эта проблема писателей, которые нарочно привязывались либо к конкретному рантайму, либо через jni к конкретной библиотеке под конкретную версию ОСи, либо используют запрещённые колдунства с sun.misc.unsafe (которые не являются частью стандартного api, просто так недоступны снаружи, меняются от рантайма к рантайму, зато там возможна работа с указателями)
> К слову, конкретно эта проблема писателей, которые нарочно привязывались либо к конкретному
> рантайму, либо через jni к конкретной библиотеке под конкретную версию ОСи, либо используют
> запрещённые колдунства с sun.misc.unsafe (которые не являются частью стандартного api, просто
> так недоступны снаружи, меняются от рантайма к рантайму, зато там возможна работа с указателями)Можно это высказать разрабам из Cisco... Но толку?
>К слову, конкретно эта проблема писателейК слову тогда любой Ёзык - кросс-платформенный. Всё зло от писак!(С)
... хех! И кстати это почти 146% правда :)
> Все они дохнут из-за того, что никто не хочет переписывать функционалуже существующих библиотек, типа Boost, Qt, WxWidget, GMP, OpenMPI
главное gcc и утилиты gnu - как минимум можно избавиться от cygwin, остальное не интересно.
у гцц и гну утилит проблема не в компиляции под винду, а в отсутствии стандартных позикс библиотек. цигвин собственно их и добавляет
В цигвине утилиты гну (make, rm, cp и тд) которые нужны для сборки проектов на венде, сейчас их можно собрать без танцев с бубноцигвином
> В цигвине утилиты гну (make, rm, cp и тд) которые нужны для
> сборки проектов на венде, сейчас их можно собрать без танцев с
> бубноцигвинома что вам мешает просто взять виндовый компилятор и собрать эти гну утилиты под винду без цигвина?
Какие дыры у данной библиотеки? Файлы весом в целую ОСь?
Бесспорно крутая штука. Теоретически можно канпелировать, например, универсальный бинарник своей программулины и раздавать его на оф. сайте. Но практически это упирается в разные графические стеки разных ОС. Теоретически, эту проблему можно решить, но опять же, практически -- эта задача выглядит слишком большой.
С точки зрения "смотри как могу" интересный. Ещё теоретически может быть полезен в случае если пользователь не может сам выбрать свою систему и эту информацию никак нельзя получить. На практике сложно придумать нормальное применение кроме написания вирусни. А вот само наличие таких программ подталкивает к использованию странного кода со странными патчами. Уже представляю маркетологов которые со слоганами "скачай один файл, запускай везде", это начнут пихать во всевозможные приложения и рекламировать как преимущество (пользователю якобы не надо думать, а фронтендерам меньше работы). На деле же разработка только усложнится, а запуск (и возможно и работа) программ замедлится. Увы, это не остановить, можно только игнорировать(в начале, чтобы минимизировать последствия), критиковать(после бума, чтобы у нововошедших не возникло соблазна переоткрыть америку) и переждать.
Этого не случится. Просто оценивай трезво. Сабж ещё трешовее мюслей, и мюсли уже дикий треш, который в прод тянут только абсолютные неадекваты. Ну и потом, проблема не запустить, проблема, чтобы оно вообще работало на платформе. И нет ровно ни одной причины заморачиваться с багами кастомной либц, если нормальная поддержка платформы уже имеется. Но я рад за автора, хорошая развлекуха.
Это в какой это психбольнице мусл трешем стал, уважаемый? Срочно скажите, кто вас этому надоумил, что бы не дай бог этого человека на работу не нанять.
В той, в которой не приемлют просадки производительности в половину, а так же arbitrary code execution в printf (оно и логично, что подобное там есть ещё много где, потому что никто не использует и некому проверять).
в printf везде arbitrary code execution. printf - полн по Тьюрингу.
бинарники не запустятся на linux.
сначала пользователь должен выполнить скрипт вроде от рута...
Проблема «универсального» файла для всех осей может начаться с того, что в некоторых бинарнику даже прав на исполнение может не хватить и придётся это руками прописыватьНе всё же винда, где запускаемым является всё что с расширением .exe
>Не всё же винда, где запускаемым является всё что с расширением .exeНу wine это совсем не мешает загружать виндовые Portable Executable в собственный Linux процесс. Переписать имя процесса, чтобы ps видел не wine ./app.exe, а просто app.exe вполне возможно. Флаг X нужен только для запуска прямым execve.
а че толку если оно тупо в ошибку падает пока не запустишь из меню "запустить от аминистратора"..
вобщемта, линуха пошла по тому же пути, со своими се-линуксами, недавно поднимал ssh туннель, все из каробки, все из гуи, и не работает, 2-3 часа гугления и компилирования новых правил, и ура, теперь ssh имеет права настраивать tap. мне вот даже интересно, зачем пихать плагин для нетворкМанагера если оно не работает, очевидно у разраба се-линукс выключен.Впрочем, контейнеры победят
скорее всего это будет только лаунчер, который определит систему и уже скачает/поставит/запустит нормально собранный бинарник под нее.
Вобщем-то под разными юниксами это уже используется - баш скрипт, который определяет нужные флаги/пути/ядро перед запуском основного екзешника (и собственно который запускать - линуксовый или бсд-ный).
Учитывая что GUI нынешнее поколение программистов умеет ваять только в Javascript для отрисовки встроенным браузером, то не такая уж это большая проблема. Впрочем, на Си уже тоже скоро разучатся писать, к добру или к худу...
Писать на Си мало кто умел, увы, всегда, что странно при наличии ядра или ффмпега, где можно было подсмотреть. Но многие имели опыт, а он помогал им мыслить здраво даже в js. А сейчас js-only “программисты” иногда заставляют меня фейспалмить до красного лба
Не то чтобы было много альтернатив браузереому гую, оно ещё относительно адекватно и не сломано.Недавно нужно было простенький гуй на куте в питоне налабать, запустил куте десингер(или как его там) и чуть не проблевался. Что это за жесть такая? Как кнопку прилепилить к углу окна?
Потыкался потыкался в этой мерзости, плюнул, сделал всё программно.Это же дно полное, проэктирвать что-то невозможно в этой гадости.
Верстаешь просто сеткой и всё.
Да всё это для облачных приложений. Иначе зоопарк системных вызовов.
Ой, а расскажите, как предыдущее поколение умело.
>кхе кхе раньше было лучше
>> GUI ... для отрисовки встроенным браузеромДа это не самый плохой вариант. При нынешнем GUI-вом зоопарке.
>> на Си уже тоже скоро разучатся
И к добру и к худу
Си ну очень "доброжелателен" и требует от прогера знаний, таланта и аккуратности, а это сочетание дано не всем.
Тот же раст для корпоративной разработки больше подходит - пиши по рельсам, и если нет unsafe и тесты проходит - скорее всего и проблем не будет. Снимается дикая нагрузка с верхнего эшелона разрабов(а они как раз дороже стоят и их мало) и порог входа в разработку снижается(экономика должна быть экономной). Потому раст и пихают)
>> Си ну очень "доброжелателен" и требует от прогера знаний, таланта и аккуратности, а это сочетание дано не всем.Оно любому программисту требуется, проблема-то не в Си, а в том с какими проблемами ты сталкиваешься, просто Си этих проблем не скрывает под капотом, превращая явные ошибки в неявное поведение и вместо утечки памяти у тебя тупо раздувает приложение пока оно систему не вешает и/или не убивается OOM и т.д. Не то чтобы Си был без недостатков и своих подковырок, но они зато известны заранее и в любом учебнике или пособии про них будет рассказано. Поэтому все эти аргументы про снятие нагрузки с программиста для меня звучат как продаванский пиар когда тебе хотят втюхать непонятное г. Другие языки просто дают иллюзию что можно программировать не думая о типах, а памяти и т.д. Когда разраб на полной скорости врезается в эти проблемы, он уже будет пытаться их решить, воюя с "умным" языком которые все за него атвоматизировал и теперь заставить его работать как тебе надо очень непросто.
>Другие языки просто дают иллюзию что можно программировать не думая о типахЭм, а в сишке типо нужно много думать о типах?
В ней система типов практически отсутствует как таковая.
И что это за другие языки такие, расскажите, хочу не думать о типах.>Си этих проблем не скрывает под капотом, превращая явные ошибки в неявное поведение
Лолчто, это в Си нету Undefined Behaviour? Там где должны быть явные ошибки?
Остальное тоже бред полнейший...
> Лолчто, это в Си нету Undefined Behaviour? Там где должны быть явные
> ошибки?Читайте внимательно вторую строку:
Note 1 to entry: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results,
to behaving during translation or program execution in a documented manner characteristic of the environment (with or
without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic
message).
Перевод: возможное неопределённое поведение может варьироваться между:
1) Выполнением как-есть с неким результатом,
2) Дальнейшим определением поведения,
3) И выводом ошибки во время компиляции или выполнения программы.
>Тот же раст для корпоративной разработки больше подходитПричём тут корпоративная разработка в принципе - я не очень понял, но да ладно.
В корпоративной разработке больше подходит то, что позволит сваять софтину за три дня силами полутора кодеров с донной З/П. А учитывая лёрнинг курву раста и тот факт, что популярен он преимущественно либо среди маргиналов-самоучек, либо среди получателей грантов - то становится очень сложно утверждать, что для среднестатистических корпоратов ржавый лучше условного жаваскрипта. И очень смешно видеть утверждения про "пиши по рельсам" в контексте ЯПа с таким количеством абстракций и миллионом способов решения одной проблемы.
>>Си ну очень "доброжелателен" и требует от прогера знанийПаскаль, и тем более Delphi очень доброжелательны. Но, не смотря на былую популярность, грамотных программитов было мало, ибо без знаний можно было только нашлёпать компонентов на форму, и считать что программирование это просто.
Турбо Паскаль умел это 20 лет назад.Можно было с дискетки программу вообще без ОС загрузить и было зашибись.
До паскаля это тоже умели - загрузчик называется
> Турбо Паскаль умел это 20 лет назад.
> Можно было с дискетки программу вообще без ОС загрузить и было зашибись.Это и сейчас можно сделать на любом достаточно низкоуровневом языке. Только это не нужно: операционные системы не просто так придумали.
Если говорить о всяких юниксах, то их придумали чтобы запускать сишкопрограммы...
> Если говорить о всяких юниксах, то их придумали чтобы запускать сишкопрограммы...Их придумали, чтобы управлять другими программами. На сишке или не сишке -- не важно.
>> Если говорить о всяких юниксах, то их придумали чтобы запускать сишкопрограммы...
> Их придумали, чтобы управлять другими программами. На сишке или не сишке --
> не важно.Управлять не совсем подходящее слово в таком контексте.
Правильнее будет управлять процессором запуска программ изначально, затем управлять ресурсами в ситуации одновременной работы нескольких программ.
Причем это всё развивалось в рамках очень конкретных программ и аппаратных архитектур.
Абсолютно согласен. Просто мне не хотелось углубляться. Ведь тогда придётся вспомнить про прерывания, и тд и тп.
> Это и сейчас можно сделать на любом достаточно низкоуровневом языке. Только это
> не нужно: операционные системы не просто так придумали.их придумали, чтобы не таскать с собой дисковые драйвера. а потом всё стало Очень Плохо.
>> Это и сейчас можно сделать на любом достаточно низкоуровневом языке. Только это
>> не нужно: операционные системы не просто так придумали.
> их придумали, чтобы не таскать с собой дисковые драйвера. а потом всё
> стало Очень Плохо.Нет, и нет. У ОС много разных функций, и драйвера -- не единственная. И нет, потом стало Очень Хорошо. Если есть ностальгия по 60-м, можете писать на асме под баре метал. Это не то чтобы очень весело.
> 60-м, можете писать на асме под баре метал. Это не то
> чтобы очень весело.это очень весело, и в итоге намного более прикольно и эффективно, чем современные бегемоты. Project Oberon свидетель.
>> 60-м, можете писать на асме под баре метал. Это не то
>> чтобы очень весело.
> это очень весело, и в итоге намного более прикольно и эффективно, чем
> современные бегемоты. Project Oberon свидетель.Веселье -- вещь субъективная, но эффективность? Если бы это было и впрямь эффективно, этим бы пользовались. Много ли вы можете назвать полезных программ под баре метал навскидку? Я -- всего три: Linux, Grub и memtest86+. А всё потому, что время программиста давно сильно дороже процессорного времени. Потому и эффективность теперь другая.
ясно. про Project Oberon ты знаешь ничего. но пафосно рассуждаешь — как и полагается — на темы, в которых полный профан. с любимым аргументом: «я не видел — поэтому не бывает!» и вторым любимым про «время программиста».кстати, чтобы ты знал, твои любимые программисты убили как минимум несколько миллионов человек. возможно, больше, точно не помню. не так сложно посчитать время, потраченое на тормоза в том, что они называют «софт», и поделить на среднее время жизни человека. вот столько жизней они украли — и продолжают красть.
поэтому не удивляйтесь, когда вас однажды начнут просто убивать.
Эй, непрофан, так ты кроме оберона на баре метал ничего и не знаешь? Я уважаю труды Вирта и его самого, но назвать их полезными можно только в образовательном контексте.А вместо бреда про "время, потраченное на тормоза", подумай лучше, сколько человекочасов потрачено на чтение твоих бесполезных комметариев? Тебе бы тогда определённо стоило побеспокоиться за свою жизнь!
> Я уважаю труды Вирта и его самого, но назвать их
> полезными можно только в образовательном контексте.а ты ещё глупее, чем показался вначале.
А действительно, непрофан кроме оберона ничего не знает. Экие нынче непрофаны то повелись!
Basic это вообще умел, чуть ли не с 60х.)))
Системные вызовы разные же. Сплошная условная компиляция.
Это как раз не проблема, вызывать всё через диспетчер, который в зависимости от среды исполнения и перенаправит куда надо. Вот с кодами ошибок сложнее, и в данной библиотеке не получилось соответствовать стандарту.
>универсальный бинарник своей программулиныСлинкуй свой "универсальный бинарник" статически с операционной системой и запускай на bare железе. Согласись, это удобно-же.
>>универсальный бинарник своей программулины
> Слинкуй свой "универсальный бинарник" статически с операционной системой и запускай на
> bare железе. Согласись, это удобно-же.Сам то понял, что высрал? Ты юзеры своей программулины хочешь заставить запускать её на bare metal? Ах да, у тебя же нет никаких программулин, и даже хеловорлдов.
> Слинкуй свой "универсальный бинарник" статически с операционной системой и запускай на
> bare железе. Согласись, это удобно-же.Сейчас плюёмся, что под капотом простенькой програмули бегемотистый браузер,
а будет виртуалка с полной ОС. ;)
Так это самое...
Я не настоящий художник, но тот же QT можно и под оффтопиком использовать...
Я даже видел работающее ПО с его использованием :)Или есть какие-то не очевидные для меня сложности?
> Так это самое...
> Я не настоящий художник, но тот же QT можно и под оффтопиком
> использовать...
> Я даже видел работающее ПО с его использованием :)
> Или есть какие-то не очевидные для меня сложности?Я тоже не настоящий. Но хорошо усвоил, что графика -- это очень, очень сложно. Драйвера, аппаратное ускорение, дисплейные менеджеры, X11/Wayland, тулкиты... И в каждом из этого содержатся костыли для подпорки других костылей из всего этого месива технологий. Поэтому я уверен, что неочевидных сложностей будет предостаточно.
ГУЙ можно писать отдельно.
А иногда он не сильно и нужен - профит могли бы поиметь куча классных проектов: grep, nmap, ytd-dlp (youtube-dl), ffmpeg, rclone, imagemagick, Dwarf Fortress и т.д. И это назвал всего парочку (всем известных).
Конечно, существует куча полезных консольных программ. Но я слабо представляю, зачем консольную программу качать с сайта. Скорее, используется "<YOUR_PM> install grep". Хотя в целях тестирования это действительно может быть удобно!Но вряд ли такое взлетит, ведь большинство программописателей не осиливают даже банальный appimage, приходится канпелять и подбирать зависимости, если нужна версия не из реп. Какой уж там Cosmopolitan...
GCC тут ни при чём. Это свободный проект, и любой срамец может запилить любой патч.
Космополитан это все сплошной грязный хак. Автору просто повезло, что есть путь по которому ОС могут прожевать "универсальный" бинарник. Если в каком-нибудь из апдейтов венды прилетит поправленный парсер PE формата, который будет реджектит всякий мусор в файле а не skip'ать, то космополитан превратится в тыкву.
Кто на это решиться в microsoft? Там полно легаси.
Там практически всего один линкер, и выпускает его Микрософт.
Было бы очень неплохо, если бы винда перешла на ELF или linux - на PE. ELF вроде простой и понятный. Но архаичный слишком, на JSON слишком похож. PE вроде посовременней - machine-readable структуры, которые можно по памяти разложить, а не по именам секций ориентироваться, перечисляя их.
В Linux уже есть загрузчик Portable Executable -- в составе Wine. Имеет смысл, поскольку заодно предоставляет WinAPI. Иначе зачем он нужен? Универсальность от лукавого. Например, в Linux mremap() предоставляет возможности, коих нет у конкурентов, и они могут заметно упростить код и дать выигрыш по скорости.
для упразднения этого безобразного зоопарка. Чтобы на всех системах использовался один и тот же формат бинарей, и мне чтобы не надо было поддерживать 3 бэкенда: по одному на каждый из основных форматов. И ещё чтобы была утилитка, которая все бинарники сконвертирует, в которую можно пользователей носом тыкать, когда им нужно работать с неподдерживаемым в моей утилите форматом.
Только конкурентов все 99%
Так потому что не используют конкурентное преимущество. Получается порочный круг.
Исторически, ELF появился позже PE. Во времена рождения Win95, в Linux ещё использовался a.out.
При чем тут линукс? ELF появился в SVR4 (1988).
>>> Космополитан это все сплошной грязный хак. <<<Сам по себе язык Си это тоже тот ещё хак:) взять хотя бы, тот же do {...} while(0)
Just use C++.
Предпочитаю Python и С, но да, когда не хватает возможностей С, - хорошо что есть С++!
>>>> Космополитан это все сплошной грязный хак. <<<
> Сам по себе язык Си это тоже тот ещё хак:) взять хотя
> бы, тот же do {...} while(0)Это не фича Си, а фича препроцессора.
Без которой можно и обойтись.А в случаях когда препроцессор неоходим, то в языках без него, вызывается внешний не стандартный, кто как сможет, генератор кода.
Альтернатива - сотворение нередактируемого исходника ручками, или медленная динамическая обработка в реалтайме.
Если ваш исполняемый файл использует платформо-зависимую библиотеку скажем GTK/Qt то ничего не выйдет.
> Если ваш исполняемый файл использует платформо-зависимую библиотеку скажем GTK/Qt то ничего
> не выйдет.А если в зависимости от платформы связываться с разными библиотеками? Да, это очень сложно, но ведь возможно?
Интересно, но не вполне ясно, зачем оно. Да и в реальности будет много разных НО, включая внешние библиотеки, их разные версии для для каждой ОС и т.п. Да и нет проблем загрузить нужную версию приложения для определённой ОС.
> Интересно, но не вполне ясно, зачем оно.затем, что автор упоротый. тот случай, когда придумал забавный хак для развлечения, а потом на нём заклинило.
> макросы, подобные EINVAL, не являются константами в CosmopolitanОчень интересный момент.
Действительно, определены вот так:/**
* Result too large.
*/
extern const errno_t ERANGE;https://github.com/jart/cosmopolitan/blob/18536950b3db37da45...
А вот как должно быть в языке Си:C17 ballot ISO/IEC 9899:2017
7.5 Errors <errno.h>
1 The header <errno.h> defines several macros, all relating to the reporting of error conditions.
2 The macros are
EDOM
EILSEQ
ERANGEwhich expand to integer constant expressions with type int, distinct positive values, and which are suitable for use in #if preprocessing directives;
То есть формулировка "Си-библиотека Cosmopolitan" не является корректной.
Правильнее говорить "похожая на Си"
Определено как extern const, что бы гарантировать наличие объекта в памяти.
Наверняка при инициализации библиотеки подставляются подходящие для среды исполнения значение.
То есть в угоду "универсальности" пожертвованы эффективность и соответствие стандарту.
Как всегда чётко и по делу. 👍
Спасибо, кэп.
Вот бы кто сначала придумал для линуксов универсальный бинарник. А то для разных версий убунты разные deb'ы качать надо.
Это давно придумано и называется "статическое связывание". Аргументы против него в основном идеологические, подогреваемые заинтересованностью майнтейнеров.
Хотя там вопрос где поставить границу между обязательной динамичность. Динамичностью на малый сегмент прог и полной статичностью. Надеюсь нейросети решат этот вопрос.
Идеология - это то, что определяет все компромиссы. Так как компромиссы есть во всём, идеология определяет всё. Если вы готовы разбазаривать память и иметь уязвимые и забагованные программы, но гарантированно рабттающие - вам контейнеры и/или статическое связывание. Если вам насрать на гарантии работоспособности хлама, а важнее чтобы не было уязвимостей и багов, и чтобы память рационально использовалась - вам пакеты.
Идеология - это буллшит, обязывающий гарантировать работу нубкитов с LD_PRELOAD и работу сборщикам пакетиков и экспертам по безопасности, видимшим руткиты лишь на картинках.
>LD_PRELOAD- удобная вещь.
>работу сборщикам пакетиков и экспертам по безопасности,
Причём тут контейнеры?
>LD_PRELOADДико неудобная
> LD_PRELOADСтатическое связывание тебя не спасёт на машине с отладчиком.
> руткиты
В пространстве ядра. Какая разница какое связывание?
Для видевших руткиты лишь на картинках попробую объяснить. Нубкит - это "руткит" режима пользователя. Он не запускает процесс под отладкой для трассировки и поиска нужных для перехвата мест, не использует дизассемблер с той же целью, решая NP-полную задачу. Он тупо смотрит импорт/экспорт.
> гарантировать работу нубкитовВот статическая линковка и пустые надежды на nooby-разрабов ПО, как раз, гарантируют работоспособность эксплоитов, налдолго и во всех дистрибутивах страны (с такой моделью сборки-доставки ПО).
А там, где сопроводители пакетов и разделяемые либы, там ни дыр в libSSL.a, исправленных полвека назад, ни совместимости для эксплоитейшн-автоматики, зато сплошные удобства для частых обновлений ПО.
> с такой моделью сборки-доставки ПО.А теперь обратите внимание на "гарантировать работу ... сборщикам пакетиков".
"Пакетики" намекает, что эти люди заняты не своим делом. Они пытаются внушить доверчивому пользователю, что обновление мифической .so чем-то принципиально отличается от обновления приложений, когда библиотека в них "вкомпилирована". Потому что сами в существование такого отличия веруют.> А там, где сопроводители пакетов и разделяемые либы, там
Там вопрос из FAQ на хеккерном форуме:
Q: как закрепиться в системе линукс, где чорная консоль?!
А: используй LD_PRELOAD, бро!!!111
Я правильно понимаю, что вы утверждаете, что те>Они пытаются внушить доверчивому пользователю, что обновление мифической .so чем-то принципиально отличается от обновления приложений, когда библиотека в них "вкомпилирована".
неправы, и что пересобрать и обновить всю систему со всеми программам в ней - это то же самое, что обновить одну библиотеку?
Мейнтейнеры и сборщики пакетов делают свою работу. Без этой работы нам бы пришлось обновлять всю систему и каждую программу в ней. Количество работы для сопровождающих снап-пакетов только увеличится. Но частота необходимости обновления каждого контейнера - тоже. И придётся платить каждому сопровождающему, который желает подзаработать (а почти все захотят подзаработать, коммерциализация опенсорса - это стандартная тема для нытья деятелей опенсорса, видите-ли работают не покладая рук, а сверхприбылей нет), каждого snapcraft-образа за каждую пересборку. С отчислением процента Canonical. Sustainable commercial opensource. Не говоря уже о потреблении памяти. Вот это то будущее, за которое вы так топите.
> Я правильно понимаю, что вы утверждаете, что те
>>Они пытаются внушить доверчивому пользователю, что обновление мифической .so чем-то принципиально отличается от обновления приложений, когда библиотека в них "вкомпилирована".
> неправы, и что пересобрать и обновить всю систему со всеми программам в
> ней - это то же самое, что обновить одну библиотеку?Я утверждаю, что вы не понимаете, что такое принципиальное отличие. Вы полагаете это отличие количественным, тогда как оно качественное.
> Мейнтейнеры и сборщики пакетов делают свою работу.
Архитектура системы - это дело архитектора, а не специалиста по автоматизации запуска git clone && rpmbuild. Собственно потому архитектура форков форков и скопирована у RedHat.
> Количество работы для сопровождающих снап-пакетов только увеличится.
Сам придумал тезис про снап пакеты, сам с ним поспорил - вот это настоящий эксперт.
>> Я правильно понимаю, что вы утверждаете, что <...мейнтейнеры...>
>> неправы, и что пересобрать и обновить всю систему со всеми программам в
>> ней - это то же самое, что обновить одну библиотеку?Дорогой Аноним! Я думаю, всё гораздо проще:
> Архитектура системы - это дело архитектора, а не специалиста по автоматизации запуска git clone && rpmbuild.
Товарищ c говорящим псевдонимом n00by попросту не понимает и не уважает работу мейнтейнеров.
Эта позиция в некоторых кругах столь же распространена, как и мнение "мой начальник -- дурак, вот был бы главным я"... К этому надо просто привыкнуть.
Я насмотрелся на эту "работу" в одном местячковом дистрибутиве. Майнтайнер не способен исправить переполнение стека, когда ему указывают точную строку с ошибкой в исходнике. И никого там нет, кто бы мог ему подсказать. Потому то майнтайнеры и стесняются перевести название своей профессии на родной язык.
Ну, может быть не может, а может быть не хочет. Это в конце концов не важно, потому что это -- не его работа.Впрочем, претензии у тебя, товарищ... Пойди ещё прожекту скажи, что он не нужен, потому что переполнение стека не может исправить. И продакту заодно то же самое передай. =)
> Ну, может быть не может, а может быть не хочет. Это в
> конце концов не важно, потому что это -- не его работа.Действительно, я и пишу, что понимать и уметь программировать - это не работа майнтайнера. И как раз из-за отсутствия понимания и умения, не майнтайнеру решать, как следует линковать компоненты ОС и приложения.
Его работа собрать в пакетик трендовый сет иконок, а потом хлопать глазками, когда rpm при установке этого дела падает. И написать ему некуда, потому что добрый дядя в RedHat давно не поддерживает его версию rpm.
> Его работа собрать в пакетик трендовый сет иконок, а потом хлопать глазками, когда rpm при установке этого дела падает.Дорогой, если мейнтейнер всегда такой дурак, что ж... Ну так займи место мейнтейнера и выполни его работу достойно. =)
> Дорогой, если мейнтейнер всегда такой дурак, что ж... Ну так займи место мейнтейнера и выполни его работу достойно.Кстати, именно это делают сопроводители пакетов - отправляют исправления (сборки и ошибок) разработчикам. Занимаясь сопровождением пакетов, кажется, написал больше кода, чем занимаясь собственными проектами. Причем, в отличие от самоделок, этот код практически более полезен, им намного больше людей пользуется.
В данном случае "сопроводители" проще поступили в итоге. Выкинули rpm5 и взяли rpm4. А то там делает Аноним - это никому не известно, потому что в ядро анонимные коммиты не принимают, например.
>> Его работа собрать в пакетик трендовый сет иконок, а потом хлопать глазками, когда rpm при установке этого дела падает.
> Дорогой, если мейнтейнер всегда такой дурак, что ж... Ну так займи место
> мейнтейнера и выполни его работу достойно. =)Я и выполнил за него его работу. Мою работу приняли и принялись продавать, нарушая ТК РФ. Мне за эту работу заплатили публичной клеветой и травлей.
Что скажет на это господин идеолог, ненавязчиво призывающий массы к труду за идею, то есть рабству?
> Я и выполнил за него его работу. Мою работу приняли и принялись
> продавать, нарушая ТК РФ. Мне за эту работу заплатили публичной клеветой
> и травлей.То есть ты-то конечно всё выполнил достойно и на уровне, но работодатель этого никогда не подтвердит, да? Бедненький.
> Что скажет на это господин идеолог, ненавязчиво призывающий массы к труду за идею, то есть рабству?
Воу, товарищ n00by решил, что простой чуши уже недостаточно, и решил заняться клеветой, хотя буквально только что именно за это критиковал некоего своего бывшего работодателя? )
> понимать и уметь программировать - это не работа майнтайнера. И как раз из-за отсутствия понимания и умения, не майнтайнеру решать, как следует линковать компоненты ОС и приложения.На практике, большинство пакетов пакетируется (автоматизированно) меньшинством сопрводителей в дистрибутиве. И это меньшинство одновременно является разработчиками дистрибутива (и ПО).
>> понимать и уметь программировать - это не работа майнтайнера. И как раз из-за отсутствия понимания и умения, не майнтайнеру решать, как следует линковать компоненты ОС и приложения.
> На практике, большинство пакетов пакетируется (автоматизированно) меньшинством сопрводителей
> в дистрибутиве. И это меньшинство одновременно является разработчиками дистрибутива (и
> ПО).Ну да. А архитектор на всю эту толпу один и работал в RedHat, а теперь в Microsoft... (оратора скручивают фанаты и уносят на экзекуцию с криками "да здравствует SysV init!" и "долой Wayland!").
> не майнтайнеру решать, как следует линковать компоненты ОС и приложенияВ организованном дистрибутиве существует общие соглашения, какие настройки (оптимизаций и безопасности) компиляции и линковки использовать для сборки *всего* ПО, и как всё это своевременно обновлять.
А что могут предложить разрозненые разработчики ПО? Бинарные блобы, собранные в разнобой с неизвестными настройками, с обновляемыми по желанию левой пятки зависимостями, как в Винде? Спасибо, не надо.
>> не майнтайнеру решать, как следует линковать компоненты ОС и приложения
> В организованном дистрибутиве существует общие соглашения, какие настройки (оптимизаций
> и безопасности) компиляции и линковки использовать для сборки *всего* ПО, и
> как всё это своевременно обновлять.Подробнее можно почитать по ключевому слову "франшиза".
> А что могут предложить разрозненые разработчики ПО? Бинарные блобы, собранные в разнобой
> с неизвестными настройками, с обновляемыми по желанию левой пятки зависимостями, как
> в Винде? Спасибо, не надо.Так в Винде динамическое связывание как раз. Сюрприз, да?
> Так в Винде динамическое связывание как раз. Сюрприз, да?Ты для Винды горе-погромировал даже меньше, чем для Линукса, да? Иначе, был бы в курсе, что полагаться на наличие нужных твоей программе динамических библиотек в Винде не приходится, подтянуть средствами системы, как зависимость, практически тоже нельзя, без централизованных-то методов доставки ПО (пакетника, репозиториев и сопротиводителей), поэтому прикладные программы всё своё носят с собой. А статически или динамически линковаться - вопрос десятый, только в лицензии упирается (GPL vs LGPL/BSD).
> А статически или динамически линковаться - вопрос десятый,
> только в лицензии упирается (GPL vs LGPL/BSD).Вот это да. Оказывается, упирается в лицензии. То есть аргументы против статического связывания - идеологические, как я и заявлял изначально. Спасибо.
>> Так в Винде динамическое связывание как раз. Сюрприз, да?
> Ты для Винды горе-погромировал даже меньше, чем для Линукса, да? Иначе, был
> бы в курсе, что полагаться на наличие нужных твоей программе динамических
> библиотек в Винде не приходится, подтянуть средствами системы, как зависимость, практически
> тоже нельзя, без централизованных-то методов доставки ПО (пакетника, репозиториев и сопротиводителей),
> поэтому прикладные программы всё своё носят с собой.Если бы ты сам нагорепрограммировал для Винды хоть что-то, то бы был в курсе, что это вопрос уровня FAQ и описан в MSDN и наверняка у Рихтера. Проблема в консистентности инициализации рантайма Си, с которым динамечески связаны чужие библиотеки. Исходников от последних нет, пересобрать их нельзя, потому и самому приходится линковать динамически.
В Линуксе этой проблемы нет, исходники доступны, пересобирай как удобно, но делают "лишь бы ни как в Венде" и линкуют точно так же -- динамически. =)
> Оказывается, упирается в лицензии.На Винде - да. Там разработчики сами себе предоставленины, выбора у них нет. А в Линуксе есть пакетные менеджеры, репозитории и сопроводители ПО - здесь есть, кому думать, как лучше.
> консистентности инициализации рантайма Си
Ой, не выделывайся. Всё проще - M$ вместо библиотек предпочитает инсталляторы (с дозвонами) и не шмогла в централизованную доставку (не захотела, так схавают).
>> консистентности инициализации рантайма Си
> Ой, не выделывайся. Всё проще - M$ вместо библиотек предпочитает инсталляторы (с
> дозвонами) и не шмогла в централизованную доставку (не захотела, так схавают).Опять идеологический аргумент. В принципе, можешь остановиться. После твоего откровения про лицензии интерес к тебе пропал, задачу ты выполнил на отлично.
Ещё раз для туговатых на уши просвещаю. Вантуз-разработчики линкуются статически с BSD-либами (проще слямзить) и динамически с LGPL-либами. По сугубо идеологическим причинам.В Линуксе решение принимается по техническим причинам. Лицензия роли не играет, потому что всё ПО открытое, линкуйся как хочешь.
> В Линуксе решение принимаетсяне тобой. Ты достаточно подробно рассказал про себя: сборщик-любитель нескольких пакетиков, программировать не умеешь.
> Архитектура системы - это дело архитектора, а не специалиста по автоматизации запуска git clone && rpmbuild. Собственно потому архитектура форков форков и скопирована у RedHat.Такими архитекторами являются разработчики дистрибутивов, которые отлично справлялись со своей работой, когда RedHat ещё под стол пешком ходил.
Debian, например, стал популярен задолго до появления systemd и для многих начинающих разработчиков других дистрибутивов был образцом правильной архитектуры системы и настройки ПО. А свою архитектуру redhat-засланцы туда чуть ли не насильно пропихивали. Те, кто "по-доброму" не хотел "копировать у Redhat-а" даже откололись в свой дистрибутив. И до них уже полно nosystemd-дистрибутивов существовало.
>> Архитектура системы - это дело архитектора, а не специалиста по автоматизации запуска git clone && rpmbuild. Собственно потому архитектура форков форков и скопирована у RedHat.
> Такими архитекторами являются разработчики дистрибутивов, которые отлично справлялись
> со своей работой, когда RedHat ещё под стол пешком ходил.
> Debian, например, стал популярен задолго до появления systemd и для многих начинающих
> разработчиков других дистрибутивов был образцом правильной архитектуры системы и настройки
> ПО.Вспомнила бабка, как девкой была.
> А свою архитектуру redhat-засланцы туда чуть ли не насильно пропихивали.
> Те, кто "по-доброму" не хотел "копировать у Redhat-а" даже откололись в
> свой дистрибутив. И до них уже полно nosystemd-дистрибутивов существовало.Ой, RedHat виноваты, что новое поколение обслуживающего персонала не умеет кодить и не доросло до самостоятельного решения вопросов архитектуры, а сильно в основном в тезисах "ленивым и тупым разработчикам прикладного ПО" и "лишь бы не как в Винде".
Повзрослей.
> обновление мифической .so чем-то принципиально отличается от обновления приложений, когда библиотека в них "вкомпилирована".Отличается. Принципиально.
- Обновление .so не влечет обязательного обновления всех зависимых программ, только несовместимых по API.
- Модель сборки с разделяемыми библиотеками позволяет осуществлять централизованное управление зависимостями программ. Например, следить и выполнять исправление уязвимостей во всех программах, а не только тех, про которые мы не забыли.> как закрепиться в системе линукс
> используй LD_PRELOADЭто не про закрепление (восстановление после перезагрузки), а про эксплуатацию.
>> обновление мифической .so чем-то принципиально отличается от обновления приложений, когда библиотека в них "вкомпилирована".
> Отличается. Принципиально.
> - Обновление .so не влечет обязательного обновления всех зависимых программ, только несовместимых
> по API.То есть отличие - в количестве обновляемых байт. Не принципиальное. Неискушённый пользователь вообще не видит разницы: он запускает "обновление", ждёт и радуется.
> - Модель сборки с разделяемыми библиотеками позволяет осуществлять централизованное управление
> зависимостями программ. Например, следить и выполнять исправление уязвимостей во всех
> программах, а не только тех, про которые мы не забыли.Ну понятно - граф зависимостей построить не судьба. Это же надо уметь кодить, а не только менять цифирки в сборочных сценариях
>> как закрепиться в системе линукс
>> используй LD_PRELOAD
> Это не про закрепление (восстановление после перезагрузки), а про эксплуатацию.Молчал бы ты, анонимный эксперт, когда в вопросе не смыслишь.
Это именно "закреп" и мой пересказ реальных вопросов и ответов.
Нет, подтверждать я тебе скриншотами не собираюсь - иди сам регистрируйся и читай.
> Ну понятно - граф зависимостей построить не судьба. Это же надо уметь кодить, а не только менять цифирки в сборочных сценарияхНачинай кодить, когда закончишь приходи. А у нас уже всё налажено и работает - только циферки меняем, да чаёк попиваем. На блюде мы вертели таких инноваторов.
> Это не про закрепление (восстановление после перезагрузки), а про эксплуатацию.Я хз что там можно эксплуатировать. Если пытаться в setuid программки лезть, то ld.so будет игнорировать, а если в не setuid, то не понятнозачем, если ты не получаешь новых привилегий.
Меня напрягает эта фиксация на приоритетной загрузке.
> Я хз что там можно эксплуатировать.
> не понятнозачем, если ты не получаешь новых привилегий.Эксплуатация - это не только эскалация привилегий, это ещё, как минимум, отказ в обслуживании и похищение или порча данных. Да и эскалацию можно попытаться провести при определенном стечении обстоятельств, обладая знаниями о системе, это мало чем отличается от user shell.
А вот как поможет закрепиться в системе LD_PRELOAD на процессе, запущенном с пользовательскими привилегиями - это только nooby-эксперт ведает, но он нам не расскажет. В .bashrc он его, что ли, экспортирует? Но тогда зачем так сложно - через динамический линковщик? Когда bashrc - это и так полноценный shell? Загадки, тайны, тени...
Я лично тебе не расскажу, потому что слишком долго потребуется объяснять, что такое руткит, зачем он перехватывает функции. Почему в приоритете модифицируют данные, а не код - это уже тема лекций для следующего курса.
А ниче, что руткиту для установки требуются привилегии суперпользователя?
> А ниче, что руткиту для установки требуются привилегии суперпользователя?Это уже не моя компетенция. Сходи к доктору, расскажи о фантазиях. К сожалению, подобная твоей чушь является здесь "нормой".
Ты хоть лично себе, для начала, расскажи, что такое руткит.
А был бы ты поумнее, а не просто анонимным сборщиком пакетиков в выдуманном дистрибутиве, нашёл бы у меня на гитхапе это слово.
Что бы угнать пароли из браузера или пошифровать данные пользователя - достаточно прав пользователя.
> Что бы угнать пароли из браузера или пошифровать данные пользователя - достаточно
> прав пользователя.Ну и чем cat отличается от LD_PRELOAD= cat?
>> Что бы угнать пароли из браузера или пошифровать данные пользователя - достаточно
>> прав пользователя.
> Ну и чем cat отличается от LD_PRELOAD= cat?Занятно вот так через время перечитать ветку с начала. Особенно вот эти передёргивания, когда контекст и предыдущие вопросы выкидываются.
Ага, а потом Stable API nonsense.
И это только про убунту речь, а уж между дистрибутивами…
> Ага, а потом Stable API nonsense.Это мнение типичного эксперта, кто где-то что-то прочёл и принялся повсюду копировать, не понимая, о чём оно.
А вот золотое правило Linux kernel: DO NOT BREAK THE ***** USERLAND.
> "статическое связывание"
> Аргументы против него* 100500 версий одних и тех же библиотек на диске и в памяти
* вечноживые дыры в каждой, спасибо ленивым и тупым разработчикам прикладного ПО
* заинтересованность в нём зловредных nooby-какиров
>> "статическое связывание"
>> Аргументы против него
> * 100500 версий одних и тех же библиотек на диске и в
> памятиСпасибо за пример идеологического аргумента.
Результаты измерений отсутствуют, сравнения занимаемого объёма памяти не производится, фантазия выдаётся за истину.> * вечноживые дыры в каждой, спасибо ленивым и тупым разработчикам прикладного ПО
Они настолько ленивы и тупы, что смогли написать ПО, которое анонимные сборщики пакетиков написать сами не могут, но с продажи которого кормятся.
> * заинтересованность в нём зловредных nooby-какиров
Эксперт забыл развернуть мысль, или её вовсе не было?
Результаты измерений - достаточно посмотреть на размер программ на Rustе и потребление оперативы во время сборки, и размер директории с кешем cargo-пакетов. Простая либа, позиционирующаяся как для embeddedа вроде Arduino, занимает в отстрипанном виде 2 мебибайта. А папка кэша занимает 10 гигов. Пихал я в рот такой эмбеддед и такие языки программирования.
> Результаты измерений - достаточно посмотреть на размер программ на Rustе и потребление
> оперативы во время сборки, и размер директории с кешем cargo-пакетов.Спасибо за второй пример идеологического аргумента. Подмена предмета (большинство приложения написаны на С, а не на Rust) и "доказательство по аналогии" -- типичная демагогия.
> Результаты измерений отсутствуютИ так вижу, при установке и обновлениях, сколько пакетов используют общие библиотеки. А когда прилетает исправление уязвимости в одной из них, могу гарантировать, что ни одна программа не останется связанной со старой уязвимой версией.
> смогли написать ПО, которое анонимные сборщики пакетиков написать сами не могут
Я писал ПО, когда ещё даже SourceForge не было. При наличии свободного времени (будучи студентом) - ничего особенного. А сейчас ПО, в основном, не пишут, а друг у друга копируют с Github-а, а получается всё хуже и хуже. Всё сколько-нибудь приличное ПО написано ещё в прошлом веке и сегодня развивается.
> с продажи которого кормятся
Я пакеты исключительно бесплатно собираю для себя и других.
> забыл развернуть мысль
Мысль всё та же: одинаковые сборки слинкованные с устаревшими библиотеками - праздник для скрипт-кидди с готовыми автоматизированными фреймворками.
>> Результаты измерений отсутствуют
> И так вижу, при установке и обновлениях, сколько пакетов используют общие библиотеки.Давайте же уверуем словам гуру! Математика, статистика и метрология - луддитские лженауки!
>> забыл развернуть мысль
> Мысль всё та же: одинаковые сборки слинкованные с устаревшими библиотеками - праздник
> для скрипт-кидди с готовыми автоматизированными фреймворками.То есть мысль, что при обновлении статически слинкованной библиотеки этот "аргумент" превращается в тыкву, так и не появляется.
> Математика, статистика и метрология - луддитские лженауки!Ну так приводи математические доказательства подтверждающие твою позицию. Это ведь ты решил "изменить систему", так вперёд, доказывай, что титаническая работа, которую ты хочешь возложить на сопроводителей, и которую обычные разрозненные разработчики просто не потянут, как не тянут уже сейчас, когда её сильно меньше, оправдана.
> обновлении статически слинкованной библиотекиНет такого понятия. Есть понятия:
- обновление разделяемой библиотеки и некоторых ставших несовместимыми с новым API программ;
- обновление всех-всех статически слинкованных программ в системе;
И есть немалая практическая разница между этими двумя понятиями, которую тебе не понять, ведь ни одного исползуемого тобой пакета, ты сам не собрал.
>> Математика, статистика и метрология - луддитские лженауки!
> Ну так приводи математические доказательства подтверждающие твою позицию.Мне необходимо и достаточно напомнить свою позицию из #40:
"Аргументы против него [статического связывания] в основном идеологические, подогреваемые заинтересованностью майнтейнеров."
Подтверждений фанаты понаписали в виде "аргументов".
> Это ведь ты решил "изменить систему"
"Ты" это кто? Голос в твоей голове? Или этот ты читает мои мысли?
> Это давно придумано и называется "статическое связывание". Аргументы против него в основном идеологическиеОднако. То есть, вот на диске GNU/Linux-системы по сравнении с Windows занимают меньше места аж на порядок, а это оказывается называется "идеологические"...
>> Это давно придумано и называется "статическое связывание". Аргументы против него в основном идеологические
> Однако. То есть, вот на диске GNU/Linux-системы по сравнении с Windows занимают
> меньше места аж на порядок, а это оказывается называется "идеологические"...Да, именно идеологические.
"Аж на порядок" - в 10 раз.
Это значение могло бы быть получено в результате деления, если бы заявитель обладал фактами и предоставил результаты измерений.Но он владеет в основном демагогией, потому написал как есть.
> Это значение могло бы быть получено в результате деления, если бы заявитель обладал фактами и предоставил результаты измерений.Я конечно понимаю, что бремя доказательства лежит на утверждающем, чайник Рассела, все дела... Но товарищ n00by, Вы бы хоть сделали вид, что используете GNU/Linux. Это ведь общеизвестный факт. Думаю, на него в своё время обратили внимание все, кто когда-либо переходил с винды на линухи. )
Не, Вы конечно можете поиграть циферками, и сказать например, что ubuntu-де после свежей установки жрёт 4 гб диска, а win 10 home edition 16, и вот это вот всего лишь в 4 раза, но та же pro edition займёт 25 гб, то есть разница уже в 6 раз. А потом мы начнём ставить прикладной софт из репозитория, и внезапно разница сильно возрастёт не в пользу win. Ах да, забыл, кажется в ubuntu прикладной софт-то уже включён в первой цифре, в то время как в win это голая ось с минимумом необходимого, разве нет? )
И ведь это речь идёт только про размер занятого дискового пространства, даже не затрагивая вопроса доставки обновлений безопасности слинкованных с бинарями библиотек. )
Фиг с ним, с дисковым местом. Оперативку жалко. Вот уж, где жор, когда несколько приложений на, скажем, Электроне одновременно запущены. А если их закрывать-открывать, то опять же разница вида и по скорости запуска, когда программы, связанные динамически, повторно стартуют почти мгновенно, а в это время статические всё ещё скрипят диском.
>> Это значение могло бы быть получено в результате деления, если бы заявитель обладал фактами и предоставил результаты измерений.
> Я конечно понимаю, что бремя доказательства лежит на утверждающем, чайник Рассела, все
> дела... Но товарищ n00by, Вы бы хоть сделали вид, что используете
> GNU/Linux. Это ведь общеизвестный факт. Думаю, на него в своё время
> обратили внимание все, кто когда-либо переходил с винды на линухи. )Я сделаю вид, что не заметил рефлективную попытку гуру вызвать стадный рефлекс у читателя.
Вот такой статически слинкованный код на плюсах
int main () {
std::cout << "hello world";
}У меня весил в Винде менее 30 Кб.
Не стесняйтесь, покажите, сколько гигабайт экономится разделяемой библиотекой. ;)> Не, Вы конечно можете поиграть циферками, и сказать например
Нет, не могу. Бремя доказательства лежит на утверждающем.
Фу таким быть.
> Я сделаю вид, что не заметил рефлективную попытку гуру вызвать стадный рефлекс у читателя.Однако. А ведь я только лишь обращаю внимание на то, что Вы, по-видимому, не являлись активным пользователем некоторых операционных систем.
> У меня весил в Винде менее 30 Кб.
И что?
> Не стесняйтесь, покажите, сколько гигабайт экономится разделяемой библиотекой. ;)
Что это за хитрый реверанс? Ужели Вы взаправду предполагаете, что я займусь доказательством заведомой чуши, которой Вы только что подменили мои утверждения?
> Бремя доказательства лежит на утверждающем.
Это, между прочем, работает и в обратную сторону. Ваш исходный тезис гласит:
>>> Это давно придумано и называется "статическое связывание". Аргументы против него в основном идеологические
Вот и докажите, что аргументы за динамическое связывание -- идеологические. Впрочем, пожалуйста, не мне.
> Фу таким быть.
Кстати, согласен.
>>>> Это давно придумано и называется "статическое связывание". Аргументы против него в основном идеологические
> Вот и докажите, что аргументы за динамическое связывание -- идеологические. Впрочем, пожалуйста,
> не мне.Легко:
"на диске GNU/Linux-системы по сравнении с Windows занимают меньше места аж на порядок" (с) freehck
В Windows используется как раз динамическое связывание.
>> Не стесняйтесь, покажите, сколько гигабайт экономится разделяемой библиотекой. ;)
> Что это за хитрый реверанс? Ужели Вы взаправду предполагаете, что я займусь
> доказательством заведомой чуши, которой Вы только что подменили мои утверждения?Нет, ты как всегда удалишь мои сообщения.
> В Windows используется как раз динамическое связывание.Мда, как всё грустно. Видимо, придётся объяснять элементарные вещи.
Ну да, используется. Вот только есть два обстоятельства. Первое обстоятельство -- это энтерпрайзный продукт, и в нём весьма низкая степень связности. Второе обстоятельство заключается в том, что софт для неё -- это коробочные продукты. А они всё своё с собой тащат. То есть зачастую библиотеки, которые могли бы быть разделяемыми и использоваться в разных коробочных продуктах, тащатся каждым коробочным продуктом отдельно. Таким образом такая форма поставки -- в плане дистрибьюции максимально приближена к статической линковке.
> Нет, ты как всегда удалишь мои сообщения.
Конечно удалю. У меня же зуб на тебя, я денно и нощно за тобой слежу, чтобы удалить твои выстраданные сообщения под надуманными предлогами. =)
>> В Windows используется как раз динамическое связывание.
> Мда, как всё грустно. Видимо, придётся объяснять элементарные вещи.
> Ну да, используется. Вот только есть два обстоятельства.Обстоятельство одно.
Ты сравнил динамическое связывание с динамическим связыванием, вообразил разницу в объёме ОС в 10 раз, и из этого сделал вывод: статическое связывание негодно.
За что тебе и спасибо - твоя "аргументация" будет служить ярким примером, как ничего не смыслящие в предмете мастера демагогии оправдывают негодные технические решения.
> Ты сравнил динамическое связывание с динамическим связыванием, вообразил разницу в объёме
> ОС в 10 раз, и из этого сделал вывод: статическое связывание негодно.Мне основательно надоело, что ты мне приписываешь утверждения, автором которых я не являюсь.
Я заканчиваю это общение.> За что тебе и спасибо - твоя "аргументация" будет служить ярким примером,
> как ничего не смыслящие в предмете мастера демагогии оправдывают негодные технические
> решения.Без проблем. Более того, я настаиваю на том, чтобы ты показывал этот тред всем своим работодателям при трудоустройстве.
Чтобы им сразу видно было на моём фоне, насколько ты хорош! =)
>> Ты сравнил динамическое связывание с динамическим связыванием, вообразил разницу в объёме
>> ОС в 10 раз, и из этого сделал вывод: статическое связывание негодно.
> Мне основательно надоело, что ты мне приписываешь утверждения, автором которых я не
> являюсь.А на самом деле ты профессиональный демагог, сел в лужу и пытаешься отрицать своё сообщение №123, скатившись до хуцпы.
>> Это давно придумано и называется "статическое связывание".
>> Аргументы против него в основном идеологические
> Однако. То есть, вот на диске GNU/Linux-системы по сравнении
> с Windows занимают меньше места аж на порядок, а это оказывается называется "идеологические"...
>Бремя доказательства лежит на утверждающем.@
>"ну я вот кароче чот сканпелировал и оно мало весит давай пруфай скока у тебя)))))))"Потрясающий ход от того, кто раннее ещё и к демагогии апеллировал. С таким-же успехом я могу утверждать, что я скомпилировал хелловорлд на хтмл и получился бинарник размером 5 бит.
Если намёк не ясен, пишу прямо - полную конфигурацию в студию, какой компилятор и какой версии, какие аргументы, какая версия винды. А главное, ещё умудрись доказать, что всё это работает не благодаря винапи, которое всегда линкуется динамически, гы-гы.
>>Бремя доказательства лежит на утверждающем.
> @
>>"ну я вот кароче чот сканпелировал и оно мало весит давай пруфай скока у тебя)))))))"
> Потрясающий ход от того, кто раннее ещё и к демагогии апеллировал.Обычное зеркало. Он, в принципе, дал мне право писать ему в ответ вообще любую чушь. Поскольку начал сравнивать с Windows, где, точно так же как и в Linux, статическое связывание НЕ используется (за редким исключением). Он банально не знает про это.
> С таким-же успехом я могу утверждать, что я скомпилировал хелловорлд на хтмл
> и получился бинарник размером 5 бит.Но подтвердить никак не сможете. Кроме того, это заявление очевидно абсурдное, поскольку гранулярность 8 бит - это наконец внесли в стандарт Си.
> Если намёк не ясен, пишу прямо - полную конфигурацию в студию, какой
> компилятор и какой версии, какие аргументы, какая версия винды.Сам код https://code.google.com/archive/p/ontl/wikis/HelloWorld.wiki
разметка сбилась, когда Гугл заархивировал гуглокод, но понять можно.Ключи компиляции там указаны:
cl /DNDEBUG hw.cpp ntl/rtl/iostream.cpp ntl/rtl/crt.cpp ntl/rtl/wchar_mask_data.cpp /W4 /GL /GR- /Ob2gty /GzyS-Совместимые версии компиляторов перечислены здесь https://code.google.com/archive/p/ontl/wikis/Compilers.wiki
Какой конкретно из MSVC - не играет роли, поскольку я указал с запасом (по факту было 24,5).
> А главное,
> ещё умудрись доказать, что всё это работает не благодаря винапи, которое
> всегда линкуется динамически, гы-гы.Оно работает благодаря собственной реализации стандартной библиотеки Си++, на примеры к которой я привёл ссылки. Если неудобно смотреть там, она есть у меня на гитхапе. Работает библиотека поверх htdll.dll (либо ntoskrnl.exe). Я надеюсь, Вы воздержитесь от "гы-гы, всегда линкуется динамически". Потому что при адаптации этого к Linux окажется достаточно syscall-ов без ld-linux.so. В Windows номера сервисов не постоянны, потому для совместимости с различными версиями используется системная прослойка.
> Он, в принципе, дал мне право писать ему в ответ вообще любую чушь.То есть ты понимаешь, что пишешь чушь, но всё равно её пишешь. Молодец.
>> Он, в принципе, дал мне право писать ему в ответ вообще любую чушь.
> То есть ты понимаешь, что пишешь чушь, но всё равно её пишешь.
> Молодец.То есть ты безусловно бы таким правом воспользовался, в отличите от меня. Спасибо, что признался.
>Он, в принципе, дал мне право писать ему в ответ вообще любую чушь.Чем ты успешно воспользовался, класс.
>Поскольку начал сравнивать с Windows, где, точно так же как и в Linux, статическое связывание НЕ используется (за редким исключением).
Действительно, зато обширно используется тактика запихивания всех динамически-слинкованных DLLок в комплект поставки, которые, внезапно, зачастую используются только одной единственной программой. И разбавляют этот коричневый поток раздутых поделий разве что всякие основанные на дотнете. Мегадинамично, но почему-то приводит к тому самому избыточному поглощению пространства, как на винте, так и в раме. Наверное, всё-таки не зря в линуксе, помимо ставки на динамку, ещё также не совсем забивают на менеджмент зависимостей, не?
>>Поскольку начал сравнивать с Windows, где, точно так же как и в Linux, статическое связывание НЕ используется (за редким исключением).
> Действительно, зато обширно используется тактика запихивания всех динамически-слинкованных
> DLLок в комплект поставки, которые, внезапно, зачастую используются только одной единственной
> программой.Априори я считаю человека технически грамотным. Ты зарегистрировался только что, потому я потратил время и ответил тебе развёрнуто.
Сейчас лишь скажу, что вся эта билеберда не имеет отношения к статическому связыванию, которое, якобы, плохо - потому что оно якобы в Венде.
>вся эта билеберда не имеет отношения к статическому связываниюИмеет, с точки зрения занимаемых ресурсов - это и есть "статическое связывание". Если динамически-слинкованная либа используется исключительно одной программой и не подразумевается её использование в других - то это есть максимально близкое понятие к "статически-слинкованной" либе. Можно сколько угодно при этом верещать формалистские лозунги, факт-же в том, что эффект мы имеем очень близкий.
>которое, якобы, плохо
А вот тут уже весьма подлое проецирование не высказывавшихся в процессе диалога тезисов на оппонента. Я разве где-то оценивал понятие "статическое связывание", тем более категориями "плохо"-"хорошо"? Цитаты в студию.
>потому что оно якобы в Венде.
А таковой "логической" "цепочки" я вообще тут не видел. Перестаньте разводить демагогию, пожалуйста.
>>вся эта билеберда не имеет отношения к статическому связыванию
> Имеет, с точки зрения занимаемых ресурсов - это и есть "статическое связывание".ЧТО?
Динамическеое - это когда есть основной исполняемый файл и отдельные библиотеки. Динамическое - потому что системный загрузчик всё это грузит и разрешает связи при запуске.
Статическое - это когда вместо всего этого один файл. Линкер связывает при сборке.
> Если динамически-слинкованная либа используется исключительно одной программой и не подразумевается
> её использование в других - то это есть максимально близкое понятие
> к "статически-слинкованной" либе.Мне сейчас интересно одно. Это какая-то особенность GPL, что она подобных экспертов к себе притягивает. Или она с вами что-то делает?
>ЧТО?Скорее "А что не так?".
>Динамическеое - это когда...
Держи в курсе. Про формализм я уже упоминал. Эффект от модели использования динамически-привязанных библиотек "всё своё ношу с собой" близок/аналогичен эффекту от использования статически? Да, ведь раму и диск оно жрёт +- также, в силу дублирования.
>Это какая-то особенность GPL
Это какая-то твоя особенность, возможно даже клиническая, которая заключается в постоянных попытках спроецировать свои фантазии. Я вроде про GPL даже близко ничего не писал и не упоминал.
Собственно, статика имеет смысл, в определённых случаях (e.g. критичные, но простые системные компоненты, с малым числом зависимостей), но утверждение об идеологической природе аргументации против её использования - звучит как шиза. Неоднократно упомянутое выше дублирование данных - это вполне себе объективный критерий и аргумент "против", в хорошем проекте допускаться такой ереси не должно, без очень веских на то причин.
>>Динамическеое - это когда...
> Держи в курсе. Про формализм я уже упоминал. Эффект от модели использования
> динамически-привязанных библиотек "всё своё ношу с собой" близок/аналогичен эффекту от
> использования статически? Да, ведь раму и диск оно жрёт +- также,
> в силу дублирования.Нет, не близок, ведь отличие связываний одного от другого -- во времени этого связывания, а не в количестве байтиков, который ты приплёл в силу непонимания базовых вещей.
>>Это какая-то особенность GPL
> Это какая-то твоя особенность, возможно даже клиническая, которая заключается в постоянных
> попытках спроецировать свои фантазии. Я вроде про GPL даже близко ничего
> не писал и не упоминал.Да, это моя особенность, провоцировать местных экспертов давать признания. Я полагал, что ты новорег, и потому в тебе ошибся, приняв тебя за технически грамотного. Теперь я закрыл гештальт и вижу типичного демагога, не понимающего смысл термина "связывание" и ведущего пропаганду мракобесия.
> Вот такой статически слинкованный код на плюсах
>
> int main () {
> std::cout << "hello world";
> }
>
> У меня весил в Винде менее 30 Кб.
> Не стесняйтесь, покажите, сколько гигабайт экономится разделяемой библиотекой. ;)Нифига себе! У меня прога для индексации и поиска по zip архиву весит 15Кб. С динамической линковкой к libc, zlib и minizip, но с отключённым relro. С включённым relro 17Кб.
Ну и твой helloworld:
Динамика: g++ -mthumb -fno-math-errno -fmerge-all-constants -fno-ident -pipe -fno-plt -mcpu=native -D_GNU_SOURCE -fvisibility=hidden -flto -fno-fat-lto-objects -Os -s -fno-stack-protector -fno-asynchronous-unwind-tables -fno-unwind-tables -DNDEBUG -Wl,-z,max-page-size=0x1000 -Wl,-z,norelro hw.cpp -fno-rtti -fno-exceptions -fwhole-program && sstrip -z a.out
2.5Кбg++ -mthumb -fno-math-errno -fmerge-all-constants -fno-ident -pipe -fno-plt -mcpu=native -D_GNU_SOURCE -fvisibility=hidden -flto -fno-fat-lto-objects -Os -s -fno-stack-protector -fno-asynchronous-unwind-tables -fno-unwind-tables -DNDEBUG -Wl,-z,max-page-size=0x1000 -Wl,-z,norelro hw.cpp -fno-rtti -fno-exceptions -fwhole-program -static -fdata-sections -ffunction-sections -fipa-pta -Wl,--gc-sections,--as-needed && sstrip -z a.out
949Кб
>[оверквотинг удален]
>>
>> int main () {
>> std::cout << "hello world";
>> }
>>
>> У меня весил в Винде менее 30 Кб.
>> Не стесняйтесь, покажите, сколько гигабайт экономится разделяемой библиотекой. ;)
> Нифига себе! У меня прога для индексации и поиска по zip архиву
> весит 15Кб. С динамической линковкой к libc, zlib и minizip, но
> с отключённым relro. С включённым relro 17Кб.Ну, раз с динамической, прибавляйте к 15Кб размеры вон тех библиотек.
> Ну и твой helloworld:
> Динамика: g++ -mthumb -fno-math-errno -fmerge-all-constants -fno-ident -pipe -fno-plt
> -mcpu=native -D_GNU_SOURCE -fvisibility=hidden -flto -fno-fat-lto-objects -Os -s -fno-stack-protector
> -fno-asynchronous-unwind-tables -fno-unwind-tables -DNDEBUG -Wl,-z,max-page-size=0x1000
> -Wl,-z,norelro hw.cpp -fno-rtti -fno-exceptions -fwhole-program && sstrip -z a.out
> 2.5КбИ к этому прибавляйте.
> g++ -mthumb -fno-math-errno -fmerge-all-constants -fno-ident -pipe -fno-plt -mcpu=native
> -D_GNU_SOURCE -fvisibility=hidden -flto -fno-fat-lto-objects -Os -s -fno-stack-protector
> -fno-asynchronous-unwind-tables -fno-unwind-tables -DNDEBUG -Wl,-z,max-page-size=0x1000
> -Wl,-z,norelro hw.cpp -fno-rtti -fno-exceptions -fwhole-program -static -fdata-sections
> -ffunction-sections -fipa-pta -Wl,--gc-sections,--as-needed && sstrip -z a.out
> 949КбВот вместо 949 у меня 30. Подробности в №160. И даже с RTTI и исключениями будет заметно меньше 900.
Мы размер бинарников хелловорлдов сравниваем или нечто другое?> Вот вместо 949 у меня 30.
Ты забыл добавить User32.dll и Kernel32.dll)
> Мы размер бинарников хелловорлдов сравниваем или нечто другое?Априори я ничего не сравниваю. Я утверждаю, что "аргументы против против статического связывания основном идеологические, подогреваемые заинтересованностью майнтейнеров".
Мне нужны были подтверждения, и я их получил.
>> Вот вместо 949 у меня 30.
> Ты забыл добавить User32.dll и Kernel32.dll)Нет, не забыл. Ты просто не в курсе, что такое User32.dll, потому и сел в лужу.
- И прибавляй libc.so туда, потому что так мои доводы выглядят лучше
- Ок, прибавляй Kernel32.dll, User32.dll, а так же ws2_32.dll
- Нет, ты нипанимаешь, это же другое!
У меня не используются User32.dll, а тем более ws2_32.dll (первую ещё могу понять, но предположение о необходимости последней для "ПриветМира" считаю глупостью). От Kernel32.dll требуется лишь функция вывода на консоль, поскольку без неё довольно муторно инициализировать сервер, с учётом поддержки различных версий ОС. В Линукс она не нужна, достаточно вызова ядра через шлюз. И да, это другое - тебе для плюсов libc.so не достаточно.
Вообще, 949 против 30 я считаю вполне годным показателем для столь солидной библиотеки как GNU. Странно, что ты на это триггернулся и принял как нападку на них. Они ведь не решали задачу "помочь линкеру выкинуть ненужное". Потому что не принято линковать статически, и куча говорящих голов находит "аргументы". Если бы статическое связывание было не десятым приоритетом, в твоём примере была бы цифра порядка 100. Я собственно для намёка на это и показал свой результат.
> сколько гигабайт экономится разделяемой библиотекойРовно столько, сколько ты в неё вынес функций из основной программы.
>>хоть сделали вид, что используете GNU/Linux.
>>ubuntu-де после свежей установки жрёт 4 гб диска, а win 10 home edition 16Ключевое слово - используете. (а не балуетесь)
И свежеустановленной Убунтой так и пользуются? Нет? Доставляют ПО.
Причем, как и с Windows не стороннее ПО и игры, а из системного репозитория, то что нужно для работы.Да, последние Windows за счет bloatware разжирели, но разница и тем хламом, далеко не на порядки.
Обычно, при установке с ходу у меня Debian занимает 12-16 ГБ. Минимум. Без стороннего софта.
Впрочем, признаю, часть встроенного ПО снимает нужду в стороннем.
Но система утрамбованная в 4ГБ, на десктопе - это или инвалид, или конструктор для доустановки ПО по вкусу. А во втором варианте объём будет.Сравним иначе.
Глянул осносительно _свежие_, не разжиревшие от времени и работы ноутбуки и виртуалки, отбросил игры и проекты, Wine, Виртуалки, ПО для 3D принтеров и 3D графики, а оставшееся усреднил.
Важно, кэши приложений браузеров, временные файлы, свопы, файлы подкачки, то что можно обнулить - исключил.- Windows10, Офис, Visual Studio(не весь конечно, а скромно самое нужное), и ПО по мелочи. 28-42ГБ.(без свопа и файла подкачки)
- Linux система для программирования, опять же не на все случаи. ~18-33Гб.>> pro edition займёт 25 гб
Не займёт, а установит по умолчанию. И часть мусора и заведомо ненужно ПО можно и нужно удалить, и будет ~16.
>>win это голая ось с минимумом необходимого
Только если чего то по недостаточно, и понадобится из Windows, то вот тебе бегемот Wine,
если что то не совместимо с ОС, то вот тебе /opt и snap.
А если впасть в snap, то понеслась.
Сторонние проприетарные приложения весьма жирные, ибо тащат все с собой.Разница есть, голые системы на Linux меньше, но не в разы, и не всегда.
_kp, вы слишком серьёзно отнеслись к данному размышлению: материал для него я выдернул из первых ссылок гугла по запросам "сколько места займёт ubuntu/windows", не более =)размер занятого пространства непосредственно после установки я брал по простой причине -- если мы начнём сравнивать ещё и разные конфигурации, то мы увязнем, и откроется огромное поле для полемики
вот например:
>> pro edition займёт 25 гб
> Не займёт, а установит по умолчанию. И часть мусора и заведомо ненужно ПО можно и нужно удалить, и будет ~16.так ведь тот же манёвр можно и в линуксе провернуть, но он ближе к нулю, так относительная разница будет расти; мало того, обязательно найдётся умник, который предложить почищенную винду сравнить с debootstrap-нутой системой, в чём собственно тоже смысла мало, потому что линуксы урезаются куда сильнее винды
а при установке дополнительного софта, как это сделали вы -- уже начинает ролять выбор софта, ибо если вы наполняете свою систему коробочными продуктами, то такой способ дистрибьюции ничем не отличается от соперника в сравнении, а мы ведь хотели сравнить выгоду от механизмов дистрибьюции, разве нет?
поэтому -- только чистая установка
> Обычно, при установке с ходу у меня Debian занимает 12-16 ГБ.
Интересно. Как же летит время:
2015й: https://www.debian.org/releases/jessie/amd64/apds02.html.en
2023й: https://www.debian.org/releases/bookworm/amd64/ch03s04.en.html
>>выдернул из первых ссылок гуглаЯ Вам назвал более точно
>>только чистая установка
Никто не использует системы в виде чистой установки. Помимо стороннего ПО, есть дженьльменский набор ПО который ставится сразу.
Добавлено:тут коллега про Мак напомнил, что там в стоковом виде система более готова к использорванию. Возможно, но там и не 4Гб, и не 16.
Например если нужно сделать Линукс на флешке,
то я лично могу её утрамбовать в 1ГБ, с Х и браузером. Но это будет плохая, не практичная система. Поэтому я не буду ставить Линукс и на 8Гб, несмотря, что голая ситема влазит в 4Гб.Как только ставим небольшую програмку, в Линукс она тянет за собой мешок зависимостей. И так на кадый чих, пока не распухнет примерно до 16Гб.
Под узкие скромные задачи можно поставить Линукс на флеку от 16ГБ. Но при этом Wine и играх даже не заикаюсь. А, и своп и гибернацию тоже не используем, а то это еще +16 .. 32 ГБ потребует, сверх заявленных 4Гб ;
Итого, мнимальный объем для простенького Линукс, который можно использовать принимаю за 16Гб. Но это будет жать.Windows10home после установки занимат 16Гб.
Деинсталируем лишнее, ставивим DirectX, TC, redist, и объём теперь 15Гб.
Но теперь мы можем ставить игры и объём windows не распухнет. Точнее, сразу не распухнет. Но, на старте готовая к работе Windows система занимает 15-20 Гб.А далее самое интересное.
В Windows объём раздут за счёт blotware, при удалении которого объём можно ещё очень сильно сократить. А в Linux только полезные нужные компоненты. А объемы сопоставимы>>Интересно. Как же летит время
Да. Когда то мой bootstrap Debian5 с Lxde, gcc библиотеками для разработки, и сопутсвуючим ПО, как то помещался в 350Мб. Стоковая установка, как ни оптимизуруй занимала 1.5Гб, что тоже достаточно скромно.
Ну что ж, возможно мои данные слегка устарели, всё-таки я ушёл с GNU/Linux в 2019м, и уже тогда не пользовался DE, а сидел на чистом i3wm. Я благодарен Вам, _kp, за то что указали мне на это.Тем не менее, факт: в начале 2010х мы на рутовый раздел линуксов выделяли 10-15 гигов и этого в целом хватало, в то время как на системный диск Windows 7 меньше 100 гигов не отрезали, да и сама она из коробки занимала 20 гигов места на диске. Если в 2023м году эта разница стала сильно меньше, это печально, и свидетельствует скорее об общем снижении квалификации IT-специалистов. Но она всё ещё есть, и за это спасибо надо говорить прежде всего ld-linux.so.
> Linux система для программирования, опять же не на все случаи. ~18-33Гб.Linux система для программирования: gcc, binutils, qtcreator, plasma, xfce(да, я установил два окружения), chromium, исходники ядра, заголовки для каждего пакета, ебилды на все случаи жизни и всякая мелочь. <7.5Гб вся система с учётом барахла в хомяке.
У меня обычно что одно из kde/mate и помимо сборки под десктоп добавляется и для микроконтроллеров компиляторы библиотеки и сопутсвующие инструменты.
это описание быдлокодинга или кододрочерства. система для программирования — это A2, например.
Путаешь бинарники и пакеты программ.
Ну всё этот ваш Линукс можно собрать переносимо и нативно запускать на шинде.
>и нативно запускать на шинде.Давно ,очень давно можно было.Ещё во времена вин98.Был
такой загрузчик- loadlin с бантиком,запускал Линукс из под винды.
Да, нужен был хак (ums-dos ??? Или как он там назывался)для файловой системы фат,подменял название файлов и атрибуты,должен был быть включен в ядро,у популярной на тот момент сласквари уже был готовый 130мгб ЗИП образ,просто распоковывался и работал.
Чуть позже для 2000 и xp тоже выпустили драйвер чтобы линь под этими операционками работал ,требовался правда падченное Лин ядро.Правда уже вмваре появился,проще в нем было запускать...
Небольшое уточнение. Чистая система, это свежеустановленная система, настроеенная, с ПО для работы. ("Стороннее" в подсчете упускал)
Это то состояние, в котором есть смысл сделать первый бекап/снапшот.А бекап голой системы с настройками и компонентами по умолчанию, это редкость, и то, разве что для быстрого развертывания, например на Распберри.
>>loadlin
Когда функционал grub и lilo был слабый, так ради loadlin, делал раздел с DOS примерно до 2010г. ;)
А это позволяло разводить _шуточные_ споры, что Линух тоже всего лишь надстройка над DOS. ;)
Открыл для себя WSL2?
Не понятно зачем это всё. Кроме форматов файлов есть еще системные вызовы и на этом всё заканчивается
Ждем, когда библиотека переродится полноценную VM, чтобы решить проблему разных окружений.
Хотя...стоп. Джава, ты ли это?
> Ждем, когда библиотека переродится полноценную VM, чтобы решить проблему разных окружений.я немножко не понял, зачем ждать то, что уже сделали: https://github.com/jart/blink
> когда библиотека переродится полноценную VM, чтобы решить проблему разных окружений.Тогда будут с теплотой ностальгировать о шустром и компактном Электроне. :)
Вроде минимальный набор системных вызов тоже поддерживаются: файлы, сокеты и тп
> Переносимость обеспечивается при помощи библиотеки Cosmopolitan, которая предоставляет универсальную обвязку над системными вызовами различных операционных систем.Почему бы просто новость не прочитать дальше заголовка?
почему бы не балаболить а действительно посмотреть что оно поддерживает?
Я очень надеюсь, что это cargo cult bloatware отклонят. Практической пользы от этой космополитан-diversity 0.
Вчера читал исследование про уязвимости в парсерах ELF-файлов. В общем, все парсят неправильно, включая ядро Linux и загрузчик. Например, игнорируется endianness. Это приводит к тому, что поле endianness в формате становится фактически бесполезным. Это приводит к тому, что endianness надо знать наперёд при парсинге формата. Это приводит к тому, что программы, полагающиеся да указанное поле, можно ввести в заблуждение, поменяв это поле на дезу. А ядро и загрузчик - прожуют, они это поле не проверяют совсем. Если бы ядро и загрузчик это поле проверяли, то обфусцированный таким образом бинарник бы вообще бы не загрузился и этого способа обфускации бы в принципе не существовало.Я считаю, что нужно сломать все программы, использующие этот способ обфускации, путём введения проверки в ядро и загрузчик.
Вероятно это потому, что для x86_64 другого endianness не бывает. А вот для POWER, MIPS наверняка это поле проверяется.
ARM тоже. Обе разрядности.
> Это приводит к тому, что endianness надо знать наперёд при парсинге формата.https://man7.org/linux/man-pages/man5/elf.5.html
Ложь, поклёп и провокация! Читаешь шестой байт - вот тебе endianess
Только ядро Linux и ld.so его не читают и безропотно грузят файлы, в которых указана несовместимая endianness. А инструменты реверсинга - читают и используют. Поэтому кульхацкеры ставят неправильное значение. Программа всё равно работает, а вот декомпиляторы и дизассемблеры сосут.
> $ gcc -nostdlib main.c -mbig-endian -o test
> $ ./test
> bash: ./a.out: cannot execute binary file: Exec format errorЧЯДНТ?
За что купил - за то и продаю https://tmpout.sh/2/3.html
> игнорируется endianness.Ну, забыли объявить deprecated, живых массовых систем, ради которых это надо было уже нет.
Садо-мазо. Проще уж просто взять и принять PE за стандарт. Под виндой он и так работает. Под DOS есть HX. Под линухом есть Wine. Андройд это жаба под линухом, так что не в счет. Остальные поделки лесом, ибо кто прогибается под агрессивный маркетинг, тот должен страдать.
Но работает только на одной архитектуре и в одном порядке байт. Зачем?
Так ещё и препроцессор использовать нельзя.
#ifdef WIN32 всё поломает.
Ну либо использовать только библиотечные вызовы, что грустно.
>Ну либо использовать только библиотечные вызовы, что грустно.Ну а что вы хотели? Кроссплатформенность - она такая. Тут либо крестик снять, либо трусы надеть.
Я _очень_ надеюсь, что авторы этих патчей, вместе с самими патчами, разрабами ГЦЦ будут отправлены лесом.
Нафиг не надо, более бредовой идеи сложно придумать.