Исследователи из компании Binarly выявили серию уязвимостей в коде разбора изображений, используемом в UEFI-прошивках различных производителей. Уязвимости позволяют добиться выполнения своего кода во время загрузки через размещение специально оформленного изображения в разделе ESP (EFI System Partition) или в не заверенной цифровой подписью части обновления прошивки. Предложенный метод атаки может использоваться для обхода механизма верифицированной загрузки UEFI Secure Boot и аппаратных механизмов защиты, таких как Intel Boot Guard, AMD Hardware-Validated Boot и ARM TrustZone Secure Boot...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60217
PCX? TGA? Вау. Оно ещё живо?
Так лучше tga до сих пор ничего не придумали из лосслесс. В чём твоя проблема, вообще?
PNG, не?
Не, как правило, типичный png очень лосси относительно исходника, я уж не вспоминаю о том, что он дико дорогой. Паллетированный png конечно до сих пор остаётся весьма эффективным и совершенно без потери визуального качества, жаль только опенсорс не умеет создавать такие файлы нормально (сопоставимо с проприетарью).
Што?
> Што?Лосслинесс не энфорсед, шо нипонятно?
Формат сжатия PNG внезапно без потерь by design. Такие дела.
Там аттрибуты некуда сохранять (только часть остаётся), в итоге исходный файл никак не восстановишь. Ну и поддержка нестандартных аттрибутов в софте отсутствует, поэтому 2 файла с большой вероятностью будут выглядеть совершенно иначе. Такие дела. Это помимо забав с конвертацией цветовых пространств.
Чо?
Это уже вопросы своему софту задавайте.
Люди любят утверждать, что это лосслесс формат, но это лосслесс с кучей оговорок. JPEGXL кстати полноценный лосслесс емнип, сразу всё есть в стандарте.
Сам формат - абсолютно лосслесс.
Ещё раз: сам формат - без потерь.
Чего вы с ним там будете перед набивкой делать и при разборе - не проблема формата.
Со всеми остальными форматами дальше заложенного изначально - такая же задница.
В PNG как раз таки заложено "из коробки" для интеропа чуть больше, чем у остальных.
Зато стандарт весьма с потерями. В этом проблема: к чему не принудили поддерживаться не будет, поэтому, не будет распространения и поддержки "расширенного" стандарта, необходимого для существования формата "без потерь".
У tiff этой проблемы, кстати, нет, а он как бы не старее лет на 20. Вот что значит инженерное образование, профессиональность и дальновидность создателей, не как у опенсорс васянов.
У tiff то, о чём вы оба вещаете - не то, что в полный рост, а с горкой.
Так-то TIFF вообще лучше ничему, кроме оригинального создавшего его софта, не скармливать.
Это уже вопрос плохой поддержки tiff, ещё желательно не открывать в другой версии ПО. В стандарте то всё предусмотрено. Но, опять же, очень мало навязано, это был задел на будущее. В jpegxl, являющимся современным стандартом, куда больше принуждения к нынешним реалиям (ну и вообще, пока единственная реализация, но идея-то здравая).
Это не вопрос "плохой поддержки tiff". Это вопрос того, что там почти всё через расширения делается.
О чём выше и отметил: в PNG из коробки стандартизовано несколько больше.
> Так-то TIFF вообще лучше ничему, кроме оригинального создавшего его софта, не скармливать.Ну то есть DNG по идее надо показывать - фирмвари фотика или приложухе камеры мобилки создавшей его. Иногда чрезмерные попытки обобщения играют с двуногими весьма забавные шутки :)
> Зато стандарт весьма с потерями. В этом проблема: к чему не принудили
> поддерживаться не будет, поэтому, не будет распространения и поддержки "расширенного"
> стандарта, необходимого для существования формата "без потерь".Вы точно в адеквате? PNG умел 24bpp RGB bitmap пожатый ZLIB по моему с момента его создания аж. Как можно что-то потерять в 24BPP битмапе пожатом zlib'ом? У вас там что, лого в HDR было чтоли? Хотя идея сделать бутлого в HDR это свежо, не отнять! Жаль далеко не любой монитор сможет отобразить все прелести бутлого :)
RGB с потерями, что не ясно?
Ты на каком-то своём языке говоришь.Lossless-формат - это формат со сжатием без потерь. Слово "сжатие" опускается. Всего три варианта: lossy, lossless, несжатый.
"Паллетированный" => индексированный, indexed, с палитрой.
"аттрибуты" => метаданные.
"RGB с потерями, что не ясно?" => непереводимая игра слов.
Конвертация в RGB подразумевает потери. Это буквально означает, что формат _только_ с потерями примерно во всех случаях использования. Т.е. _всегда_ с потерями на практике. Далее, нестандартные (и не стандартизированные) аттрибуты -- это означает, что открыть без потерь не сможет даже та программа, в которой создано изображение (цветокоррекция и прочее, чаще просто стрипается). Ну, остальное комментировать смысла нет.
> Конвертация в RGB подразумевает потери. Это буквально означает, чтоЧто преобразование происходит с потерями. Преобразование между RGB и чем тебе там надо, а не формат файла. Ещё раз, lossy-формат - это про сжатие.
Если я возьму изображение в CIECAM02 JCh или с цветом в quad float и на основании этого объявлю все существующие форматы файлов как lossy - я выставлю себя напрашивающимся на бан демагогом, а не философом-учеником Анонима (2).
При чём тут quad float? Стандарт индустрии это Lab, стандарт печати это CMYK. Такие операции как уменьшение разрешения, лучше всего проходят в LUV. Формат файла без потерь подразумевает, что при конвертации/экспорте в него, данные не будут безвозвратно искажены и потеряны. То, о чём ты говоришь, это скорее про даунсамплинг в 8 бит (чтобы размер покрасивее был, конечно же). Да, png поддерживает 32 бита, но ему это никак не помогает.
> Формат файла без потерь подразумеваетЧто он подразумевает для остального мира - уже рассказали.
Что он подразумевает лично для тебя - значения не имеет.
Для остального мира это означает, что можно восстановить bit perfect копию после лосслесс сжатия. И всю релевантную для воссоздания оригинала техническую информацию восстановить из такого файла. Это и означает "без потерь". Если это не так, то это либо баг (привет мусору по типу ffmpeg), либо формат не лосслесс вовсе.
Правда, справедливости ради, лосслесс того же jpegxl не bit perfect, а pixel perfect. Но, технически это абсолютный лосслесс. У таких форматов, как avif, при заявленности сжатия без потерь (с дополнительными ключами), все пиксели съезжают и непонятно зачем вообще они делают вид, будто это лосслесс.
При чём тут формат хранения, если у тебя потери появляются на этапе конвертации в RGB и обратно, ещё до форматирования? Тот же PNG сам по себе как формат хранения-сжатия ничего не теряет, такие дела.Если хочешь bit-perfect для не-RGB - в PNG придётся добавлять экстеншны.
В TIFF можно либо опять же RGB с экстами для восстановления твоего пространства, либо запихать bit-perfect в исходном пространстве в один экст или юзать нестандартное цветовое пространство.
Но, повторюсь, всё это прочитает только то, что знает, как с твоими конкретными экстами и пространствами из конкретного формата работать.
Теперь смотри на стандарт формата jpegxl и много думай.
> Для остального мира это означаетТо есть возвращаемся к тому, что PNG - lossy, но уже не только для тебя, но и для всего мира?
> означает, что можно восстановить bit perfect копию после лосслесс сжатия
Если сжатие без потерь сжимает с потерями, то это сжатие с потерями, а не сжатие без потерь.
Возвращаемся к тому, что png -- лосслесс только для отдельных индивидов, начитавшихся википедии. Жалкое зрелище, на самом деле, но для таких даже есть специальный термин. А так, конечно, техническая возможность сохранить определённый ограниченный субсет данных без потерь в этом формате имеется. Но эти данные будут иметь тот же характер, что и лосси jpeg.
RGB IN - RGB OUT, ничего не потерялось. Я проверил. Можешь спать спокойно.
Исходник не может быть в RGB, потому что при процессинге в RGB случаются самые разные переполнения и искажения. В том числе нельзя предсказать, во что сконвертируется. Если он в RGB, то это говорит об низкой компетенции автора, потому что это основа основ. Ну и, как правило, там вполне конкретный цветовой профиль с коррекцией, чтобы изображение было воспроизводимым (а не на каждом экране по своему отображалось). И да, ситуация с "не тот оттенок" может серьёзно испортить картину не только при печати. Ты, просто, видимо, не понимаешь, в чём дело, и почему это не лосслесс. Я даже процитирую последнюю часть, где я это объясняю (ты либо пропустил, либо не понял):>эти данные будут иметь тот же характер, что и лосси jpeg
т.е. формат не подходит для хранения и распространения информации без потерь (исходный файл проекта тоже не особо подходит, потому что, как минимум, привязан к конкретной версии конкретной проприетарной программы и сильно специфический).
Я лично рисую в RGB - мне удобно и никто не подумает это печатать, тем более - "как есть". Не, ну, цвет вообще надо в длине волны хранить, желательно даже с фазой, поляризацией и что там ещё есть ) Но ты, имхо, путаешь понятия. "без потерь" передавать и хранить можно любые данные, а не только цвет. Это широкое понятие из области теории информации, а не цвета.
Тебя ждут сюрпризы, когда ты захочешь наложить фильтры или применить постобработку, на многие инструменты тоже влияет. Что касается "без потерь", то имеет значение только обратимость процесса. Если ты сожмёшь psd с zpaq, это будет "без потерь". А вот конвертация легко может оказаться деструктивной и с потерями, если формат неподходящий. К примеру, bmp является таким же прекрасным примером формата "без потерь" и даже "без сжатия". Никаким софтом нормально не поддерживается из моего опыта работы с ним, и вообще все файлы окажутся битыми с большой вероятностью.
(некропостинг)
Жаль, забыл спросить, что для пациента означает "lossless" в спецификации PNG.
Тебя это¸ видимо, очень волнует. Если так и не получилось понять, возьми для примера формат, поддерживающий только чб-кодирование (2 цвета без градентов). Это может быть лосслесс формат без потерь, и в спеках именно так и будет написано. Тут ситуация ровно та же.
То, о чём ты говоришь - вообще ни в один формат кроме TIFF с экстеншнами нормально не запихивается.
Почти все форматы RGB(A) by design, без экстеншнов ты это без потерь не запихаешь.
А экстеншны прочтёт в основном только тот софт, который их записал. Такие дела.
И конечно же ты можешь привести перечень таких форматов? Сейчас почти все форматы изображений YUV by design, только это не подразумевает, что это у них единственный вариант.
> При чём тут quad float? Стандарт индустрии это Lab, стандарт печати это CMYK.Вот ща мы будем в фирмвари для бутлого стандарты для гребаных полиграфистов имплементить! Аж два раза!
> Такие операции как уменьшение разрешения, лучше всего проходят в LUV.
Их можно и в RGB весьма круто проводить - есть несколько весьма эпических рескалеров. Включая и специализированные.
> конечно же). Да, png поддерживает 32 бита, но ему это никак
> не помогает.Чуть ли не большая часть того что бутлого - может чуть ли не изначально сэйвиться в такой формат. Нуачо, вон даже майкрософт .ico стал в таком формате сэйвить по мере роста разрешений иконок. И не, извините, но пихать какое-нибудь EXR для бутлого в фирмвари - это перебор. К тому же это очень урезанный режим для видеоподсистемы, там еще нет полноценных видеодрайверов и операционки со всеми наворотами. И нативным форматом вывода на дисплей - является - тадам! Вот этот вот RGB! Где биты группами по 24 описывают цвет пикселя на экране, что хотите с этим то и делайте. Ну вот нет в этой абстракции никаких float, CMYK, LAB, и прочего искусственного булшита от полиграфистов :). Поэтому они не стоят даже упоминания в этом контексте - ничего нового это не привнесет, даже если б и захотело, когда пикселы пуляются на экран как RGB с 8 битов на канал. Что-то сверх того в бутовой фирмвари мягко говоря - адская экзотика.
> Конвертация в RGB подразумевает потери. Это буквально означает, что формат _только_ с
> потерями примерно во всех случаях использования.Компы нативно в этом самом RGB работают, чудак. Поэтому все и рисуют в RGB сразу, если не отшибленые полиграфисты и что там еще экзотично-маргинальное.
И если в эдиторе RGB был и я им пнгху сэйванул - эдитор просто дампанул пиксели как есть и пожал zlib. Откуда б там потерям быть? Более того, источники в других форматах на PC - в общем то экзотика. Где б смертным вообще брать материал в полиграфистских форматах?! Это же и извращенцве с YUV касается - получить это можно разве что из видео, но зачем в бутлого кадр из видео? А даже если и - так там все равно subsampling был и проч.
> Т.е. _всегда_ с потерями на практике.
Вообще-то "почти никогда" - если это обычные люди с обычными компами и обычным материалом который им под руку попасться может. У них формат вывода на экран вот такой, и самое логичное что можно сделать это теми пикселями влобовую и оперировать. Избегая всяких конверсий которые могут и потерять данные, и время на процессинг жрут. Перепахать какое-нить фулскрин лого по всей площади с хорошим качеством в другой форма пикселей, в приличном разрешении - займет ощутимов времени и сталбыть ЗАТОРМОЗИТ ЗАГРУЗКУ.
> Далее, нестандартные (и не стандартизированные) аттрибуты -- это означает, что
> открыть без потерь не сможет даже та программа, в которой создано
> изображение (цветокоррекция и прочее, чаще просто стрипается).В конечном итоге в RGB есть 256 возможных значений пикселя. Это финальная ауторити - и на экран оно улетает как-то так же. Особенно - в бутовой фирмваре, которая слыхом не слыхивала про профайлы мониторов и прочую хрень.
> Ну, остальное комментировать смысла нет.
Тут по моему все обсуждение - бессмысленное. На PC большая часть пикселов доступных смертным будет в этом самом RGB, а вовсе не. Все остальное - дикая экзотика у узких маргиналов. Или как максимум скрины из видео но они "lossy" с самого начала, никто хомяку там оригинал не даст.
> RGB с потерями, что не ясно?C потерями? Относительно чего?! Там что-то потерять можно в основном при конверсии из всяких HDR форматов, или иных колорспейсов, что как бы экзотика, особенно для бутлого. Большая часть источников на PC будет таким же RGB! Вплоть до того что эту пнгху мог прям графический редактор записать и это и был "источник".
А так то у меня есть и несколько EXR где я слепил фоты снятые с разной экспозицией. И там битов столько ... что ЭТО ни на каком мониторе "в лоб" представить нельзя: у матриц монитора столько битов и динамического диапазона - не бывает! И при этом придется познать весьма специфичную lossy операцию известную как "tonemappting", чтобы вообще это хоть как-то отобразить на реальном железе. И это заведомо компромиссная операция. А результат обычно выглядит узнаваемо. Но все равно почему-то нравится двуногим. Но вот это уже во первых экзотика. Во вторых требовать от фирмвари бутлого жрать EXR какой-нибудь наверное все же уже перебор. Да и повышенную битность и прочие профайлы монитора оно не умеет, это ж не операционка, а всего лишь фирмвар.
Хотя, конечно, можно сделать системной фирмварой какой-нить линух, с гномом, там это все поднять, пафосно показать лого и .. подумать а зачем что-то еще грузить, раз операционка со всеми прибабахами уже в общем то взлетела.
PNG очень тормозной, да и жмет эффективно только в определенных случаях.
Судя по слову "паллетированный", вы в погрузке-разгрузке работаете? Лучше про PNG не вещайте тогда.
Ты шо, поехавший, чем тебе палеттированность теперь не нравится?
> Ты шо, поехавший, чем тебе палеттированность теперь не нравится?Тем что PNG бывает и без палитр - обычным 24 битным битмапом. Еще и с альфа-каналом. Вполне себе lossless. Вроде даже и больше битов на составляющую можно - но это относительно экзотичный диалект.
Де факто PNG и TIFF имеют кое-что общее: оба форматы-контейнеры и что там реально внутрях - ощутимо варьируется. У тиффа гораздо больше бардака. Скажем какой процент софта морально вообще готов сожрать DNG который технически - TIFF, просто, формат пикселей в нем очень уж специфичный. И "поддердка TIFF" де факто вообще ничего не означает в результате.
Палеттированность ≠ паллетированность.
Я знаю только, как в оригинале, вот в соседней ветке подсказали, что в переводе это "индексированный", хотя, я не уверен, поскольку в оригинале оно тоже есть и применяется такой отдельный термин "индексированный" (что вполне может являться техническим термином для обозначения того же).
А базированные - на военной базе в Гуантаномо?
Ещё раз: па_лл_етированный???!!!
Поллютированный, судя по сабжу :)
Поллитрованные.
Да, лосси-png без поллитры не обошёлся.
> А базированные - на военной базе в Гуантаномо?Паллетированые, да на базе.... что бы это могло быть... может там еще и транспортник рядом?!
Я думаю в погрузке-разгрузке работаешь ты, потому что никому кроме тебя такая ассоциация в голову не пришла.
У меня просто словарик большой.
Сказывается гибридное образование.
> PNG, не?Для него парсер в 100500 раз сложнее и больше. Там целый zlib надо подымать чтобы его декомпреснуть, еще adler32 всякие и проч считать. И в фирмвари это может быть и не совсем удобно, zlib IIRC хочет всякую динамическую аллокацию памяти и проч, чего доброго - в фирмваре это если и есть то на минималках и с оговорками.
Плджад, целый сетевой стек - удобно, а злиб - неудобно.
Вот и пойми поди.
> Плджад, целый сетевой стек - удобно, а злиб - неудобно.
> Вот и пойми поди.Сетевой стек на минималках даже в микроконтроллеры запихивают, так что не показатель.
>еще adler32 всякие и проч считатьadler32, а равно любой вариант crc, а равно fletcher - просты как 3 копейки.
Два чаяКод адлера прост, как валенок, и занимает 20 строк
> Два чая Код адлера прост, как валенок, и занимает 20 строкУ пнг он как-то довольно замороченно считается, на каждую строку, чтоли, или типа того. Я как-то хотел несжатую PNGху генерить из "массива пикселей" - без либ - но оказалось что это тот еще гимор, этот формат неудобно крафтить "in place" самому.
stb_image чтение распространённый форматов изображений - 7800 LoC. Сложна?
Если надо того, чего в PNG нет - TIFF
Ток tiff слишком перегружен и миллион форков у каждого вендора не способствуют улучшению поддержки. Не сравнивал вычислительную сложность. Tga максимально простой и универсальный стандарт.
В большинстве случаев PNG хватит. Его правда да, разжимать чуть посложнее надо.
Для заставок хватит gif. Ну джипега там для особохудожественных заставок с полутонами и профилями.
> Если надо того, чего в PNG нет - TIFFДа, давайте DNG парсить в системной фирмвари. Раз системное фирмваре похоже на операционку, чего б ему тогда и дебайер не научиться, право? Заодно и посмотрим сколько там вулнов будет при разборе этой штуки. Ведь мы же жить не можем без парсинга равок фирмварью, еще не хватало - операционки какие-то загружать для этого.
Я думаю, тут для безопасности нужно выгружать картинку в облако разработчика загрузчика, там её перебирать в безопасный битмап с учетом локального профилей мониторов пользователя, прорверять искусственным интеллектом на наличие всего-чего-можно (там же может оказаться недеццкий таки контент!) и затем выгружать обратно на пользовательское устройство, чтобы оно могло продолжить загрузку.
>там её перебирать в безопасный битмапЛучше в блоб машинного кода, выводящий картинку. А всяким нехорошим личностям можно и вредоно^тьфу, advanced network investigation tools, вроде Pegasus, подсунуть.
> Я думаю, тут для безопасности нужно выгружать картинку в облако разработчика загрузчика,
> там её перебирать в безопасный битмап с учетом локального профилей мониторов
> пользователя, прорверять искусственным интеллектом на наличие всего-чего-можно (там
> же может оказаться недеццкий таки контент!) и затем выгружать обратно на
> пользовательское устройство, чтобы оно могло продолжить загрузку.Так то идея забавная, но воооон те обладатели умного дома ксяу-мяу очень интересно коментили когда сервер ушел в даун. И вот ты просыпаешься, а дом не умный - а дохлый, управления нет, что хошь то и делай :)
JPEG XL в lossless режиме?
> JPEG XL в lossless режиме?Дороговато, на контенте с градациями серого png меньше файлы выдаёт. Только есть проблема, это низкие распространённость и слабая поддержка в софте, а так да, файлы в среднем в 2 раза меньше, чем у png. И есть зависимость от достаточно непредсказуемой либы, которая среди прочего включает в себя жит вм.
> И есть зависимость от достаточно непредсказуемой либы, которая среди прочего включает в себя жит вм.С этого места поподробнее, пожалуйста. По запросу libjxl jit ничего не нахожу.
Слишком сложно для бивисов, честно говоря.
> Так лучше tga до сих пор ничего не придумали из лосслесс.Вот только зачем лосслесс в лого на компе ?
Ну PNG для этой цели сложноват, я с ним соглашусь пожалуй.
Но вот конкретно там TGA тоже вообще не упёрся - банального BMP достаточно.
BNP норм. Если хоть одна либа сжатия в прошивку тянется то проблемы нет вообще с размером.
А TGA не банальный, что ли?
> А TGA не банальный, что ли?2.0-то с экстеншнами? Хуже только TIFF.
BMPv5 тоже не подарок. Вплоть до того, что у него внутри PNG или JPEG может быть.
Ну это там необязательное, оно только если цель - например печать без декодирования на устройствах, которые умеют JPEG/PNG нативно. А чего вы от мелкософта хотели :)А вот то, что туда цветовой профиль эмбедится - уже да, с декодированием может слегка весело выйти.
>> Так лучше tga до сих пор ничего не придумали из лосслесс.
> Вот только зачем лосслесс в лого на компе ?Чтобы выглядело идеально, бит в бит, пиксел в пиксел. Иначе нахрен надо такое лого...
Ну да, куча же людей занята в разработке логотипов и там архиважно ни на бит не промахнуться - сразу убытки компании на триллионы сделаются.
> Ну да, куча же людей занята в разработке логотипов и там архиважно
> ни на бит не промахнуться - сразу убытки компании на триллионы
> сделаются.Ну я себе лого делал еще в 90е - увидев комп с кастомным лого кажется в фирме "Формоза" (не знаю, жива ли она до сих пор). Идея зашла - я себе тоже BIOS-ы пропатчив. Пару раз познакомившись с бутблоком, и б-цкими чексумами образа (чексум в конце концов был радостно на@бан, хоть я и понятия не имел где он хранится, но иногда это и не важно).
Погодите, я вангую появление лого в 4k в какой-то момент.
> Погодите, я вангую появление лого в 4k в какой-то момент.Эээ... ну вообще-то это был бы нативный формат для фулскрин лого на 4K монитор/дисплей. Иногда Ванга бывает Капитаном Очевидностью походу.
Не, я про биосы :D
Так-то сейчас смотрю выше 1024x768 не поднимаются, место во флеше экономят.
Главное - успеть рассмотреть
Для тех, кто не успевает рассмотреть вредоносные логотипы, должны быть предусмотрены дополнительные меры принуждения 8-[
Придумали — QOI.
> QOI is fast. It losslessly compresses images to a similar size of PNG, while offering 20x-50x faster encoding and 3x-4x faster decoding.Скорость разуплотнения картинки 1024×768 на современном железе абсолютно не принципиальна, а вот за similar size скрывается «не сильно-то и больше».
> PCX? TGA? Вау. Оно ещё живо?Первое - редко используют. Второе - один из самых простых в парсинге форматов битмапов чтобы читать/писать его. И да, если кто даже TGA распарсить не может, ему наверное лучше рассаду выращивать.
Про оба слышал лет 30 тому назад, а когда последний раз видел.. Примерно тогда же.
> Про оба слышал лет 30 тому назад, а когда последний раз видел..
> Примерно тогда же.TGA неплохо поддерживается софтом и порой попадается - потому что записать "массив пикселей" в этом формате - довольно просто и без либ вообще.
PCX - ну вот как-то да, редко сейчас встречается.
ты, наверное, и 3дмакс тогда же последний раз открывал?
TGA 2.0 с неизвестными экстеншнами?
Я уж пожалуй лучше в рассаду, да.
UEFI c шеллом напоминает дос, что прикольно.
>в котором присутствуют уязвимости, приводящие к переполнению буфера во время разбора некорректных данныхУгадайте с одного раза язык программирования, на котором написан этот код.
Ассемблер? Восславим же пресвятой ассемблер, наш избавитель от оков корпораций!
Для тебя будет открытием, но ассемблер - не язык программирования.
Это один из вариантов транслятора (бывают интепретаторы, компиляторы и ассемблеры). Конкретно ассемблер переводит из языка ассемблера в машинный код.
То, что ты называешь "ассемблером", это ассемблерный язык или язык ассемблера. А не сам ассемблер. Сказать "написано на ассемблере" так же нелепо, как "написано на компиляторе".
И да, это повсеместная айтишная безграмотность, которая не лечится. Наряду с "тся/ться". Или Силиконовой Долиной.
> ассемблер - не язык программирования
> ассемблер переводит из языка ассемблераИ всё-таки гуманитарное образование не проспать.
разницу между ассемблером и языком ассемблера не видишь? Спи дальше
А транслятор/компилятор C переводит с языка C. Но собирательное название у обоих внезапно C.
почитай вики хотя бы. Или не научили пользоваться гуглом?
Let me do that for you
https://ru.wikipedia.org/wiki/Ассемблер
https://ru.wikipedia.org/wiki/Язык_ассемблера
Ну да, вот сейчас пойду, и буду только строго по вики всё фразировать.
Когда говоришь "пишу на ассемблере" - все всё прекрасно понимают, но ты можешь продолжать.
Ну ладно формальностей, всегда говорили "набросал на ассемблере", "ассемблерный код" и т.п.
Вообще-то такие перлы как раз таки технарями выкидываются. Птичий язык тусовочки.
А технарь без гуманитарщины -- как человек с руками, но без головы.
Диалекты ассемблера несовместимы и вполне себе являются каждый своим ЯП, Вася.
Ещё один. О чём я и говорил - беспроссветная айтишная бездарь.
В англоязычном источнике хоть раз видел Assembler как язык программирования?
Это всегда транслятор. Сам язык называется Assembly language, коих великое множество, конечно. Так как приязан к конкретному процессору.
https://www.ibm.com/docs/en/zos/2.1.0?topic=interface-progra...
Идиоты, видимо, и в англоязычной среде встречаются.
Д'Артаньян, вы?
Если не очевидно от чего ассемблер, писали типа "ниже приведен ассемблерный код для _название платформы_". В целом воще не вижу поводов для спора - всем же понятно о чем речь.
Там всё правильно, если немножко разбираться в окончаниях.Assembler - that who assembles.
Assembly - that what is assembled.
Assembly [language] - how to assembly.В великом и могучем такой дифференциации нет.
Но и даже в ангельском слово language выкидывается за ненадобностью.
Поэтому скажем дружно - нафиг нужно.
А почему выкидывается?
Потому что programming in assembly с точки зрения "what is assembled" - смысла не имеет.
Такие дела.
То же самое и в могучем: если я пишу на ассемблере - то это точно не означает, что я взял masm.exe и пытаюсь сверху на битах в нём что-то накорябать, а всего лишь пишу на его диалекте языка. Поэтому вся эта избыточность и лишние слова - полностью бессмысленны.
Более того, можно даже "пишу на as".
Шах и мат.
Угу, у него даже 2-а основных диалекта - at&t и маргинальныйЗыж
А на следующем курсе будете проходить llvm ir.
Во где повеселитесь.
> ассемблер - не язык программирования
>...
> Конкретно ассемблер переводит из языка ассемблераВ каком месте ты .. ошибся?
> То, что ты называешь "ассемблером", это ассемблерный язык или язык ассемблера. А не сам ассемблер. Сказать "написано на ассемблере" так же нелепо, как "написано на компиляторе".Когда школьник впервые почитал про ассемблеры и спешит продемонстрировать свою "экспертизу".
Теперь иди читай, что такое "жаргон" и "лаконичность".
Зачем, интересно, опеннет заполонила толпа людей совершенно не разбирающихся в айти технологиях ... В уютном колхозе что ли скучно стало?
и тем не менее это далеко не первое слово, которое стало нарицательным и приобрело другой смысл, дополнительный или заменив изначальныйтолько накой ты занудствуешь? мы тоже можем...
Аутистические черты характеризуется тем, что пациент не может из контекста понять, о чем собеседник говорит, ему слодно представить систему ценностей другого человека и предсказать его действия
В русском айти языке термин "ассемблер" означает именно мнемонический язык.
А трансляторы так и называют: masm, tasm, etc.
Языки делятся на два вида: на си и на те которые никто не использует.
На дыряшку, и на растишку
"джава" ровно тем же занималась, чем щас "растишка"
> "джава" ровно тем же занималась, чем щас "растишка"Есть пара маленьких отличий...
1) Хруст компилится в нативный код.
2) Нет никаких гребаных VM - и до господ даже доперло что рантайм должен быть опцией, чтобы стать именно подобием системного ЯП.
3) Всяких GC и прочего треша убивающего перфоманс и предсказуемость быть не обязано.
4) На минималках лезет даже в микроконтроллеры типа атмеги.Надеюсь это объясняет почему ява и дотнет на этом фоне выглядят как легаси, а их носители - как динозавры на пешеходном переходе. Каковыми и являются. Им это нечем крыть. Вообще совсем.
Я бы добавил, что
5) можно сконпелять под просто 64-битный линуπс для данного процессора и оно не будет хотеть зависимостей.Может я не прав и есть свои проблемы.. Но по этому поводу хочу его поизучать в 2024м
> Есть пара маленьких отличий...ну с этим никто спорить не будет, посыл в другом - и тот и этот якобы "убийцы" С :)
> как легаси
ну и кто собрался "легаси" джава код переписывать? много таких?
> ну с этим никто спорить не будет, посыл в другом - и
> тот и этот якобы "убийцы" С :)Вообще, как сишник я рассматриваю идею когда-нибудь его может быть даже выучить. Воооооон там в gccrs обнаружены ... тадам! Кишки borrow checker'а! Оказывается начинка gcc в принципе и такую круть позволяет без каких-то диких костылей вроде как. Это пока жесточайший WIP - но если дальше все так пойдет - может быть любопытно поэкспериментировать при случае.
И таки да - в сях довольно много способов прострела пяток, которые довольно сложно загасить даже статисческим анализатором на 100%. Я говорю это как тот кто прошел весьма длинный маршрут в этом направлении.
>> как легаси
> ну и кто собрался "легаси" джава код переписывать? много таких?Можно сказать то же самое про COBOL. На нем даже до сих пор программеры требуются. Но вот новые проекты на вот именно этом начинать сейчас - мало кто станет, имхо.
А ещё хруст оформляет страховку от переполнения буфера.А на вопрос "А точно не случиться прилёта каких-нибудь особых данных? Ты уверен что этого не произойдёт?" отвечает "Всё пучком, что там в будущем твоей проге скормят я уже на мозильской гуще погадал, б*я буду!"
Как он его оформляет unsafe'ом, как перестать орать?
> А ещё хруст оформляет страховку от переполнения буфера.Не оформляет и в целом язык общего назначения не может его оформить. Учи матчасть (собственно можно всем растоманам пожелать).
1) и java давно тоже
3) но раст убивает перформанс, почему то для раста это ок, а для джавы не ок
4) джава лезла ещё в 90е, более того на ней работала большая часть телефонов
По факту есть куча языков попадающих под эти требования, куда более современных чем раст, более безопасные, более быстрые (но не все вместе), более открытые, но вы все равно носитесь с собственностью мелкософта и гугла, даже когда вам явно сказали что это не опенсурсная поляна.
> 1) и java давно тожеЯ рад за них и все такое, но оно вообще совсем не тянет на "системный яп" и поэтому мне не интересно как категория.
> 3) но раст убивает перформанс, почему то для раста это ок, а для джавы не ок
Да ничего он особо не убивает насколько я вижу. А с чего ему? Он большую часть в компилтайме чекает. В чем EPIC WIN и состоит, в том числе и borrow checker и проч. Я нечто отдаленно напоминающее и на сях делаю там где актуально - но это весьма костыльно и увы, подход имеет немало лимитов. Хоть я и сделал "почти хруст" из всего что статически-предвычислимо. Так что скажем в 33-й бит записать? В 32 бит регистре? Нене! Макрос бортанет эту инициативу на фазе компила - с zero runtime penalty, чисто компилтайм фича. Но хруст на эту тему может явно больше и лучше.
И да лучший чек - это компилтайм. Грохнуться в рантайме - прерогатива питоняш всяких, это вы с ними будете рубаться. А мне вы не конкуренты с такими свойствами даже чисто теоретически.
> 4) джава лезла ещё в 90е, более того на ней работала большая
> часть телефоновЯ помню как это все работало. RAM что тогда кончалась, что сейчас кончается. В этом месте если бы моя любовь к яве выражалась как луч лазера, он бы прожег ваш череп насквозь и улетел в бесконечность.
> По факту есть куча языков попадающих под эти требования, куда более современных
> чем раст, более безопасные, более быстрые (но не все вместе), более
> открытые, но вы все равно носитесь с собственностью мелкософта и гугла,
> даже когда вам явно сказали что это не опенсурсная поляна.И на поверку большая часть не подойдет для универсальных применений и системщины вообще никак. Кто-то просто отшиблен, кто-то жить не может без переросточных рантаймов и медвежьих услуг, малопредсказуем и норовит "удружить". Хруст прошел довольно длинную дорогу в том чтобы от этого избавиться.
Ну то есть из хруста можно "интерфейситься к системе" или "к bare metal" - без невъ...ного stdlib который может и не катить по своим допущениям для фирмварей, бутлоадеров, кернелов, софта с кастомными запросами (e.g. реалтайм) и проч. Это все пока кривовато, WIP и проблематика только изучается - но остальные и так не смогли... там реальных конкурентов - ну может Zig и Hare еще. Но у zig например какой-то совсем кастомный тулчейн. Это круто, но...
> 3) Всяких GC и прочего треша убивающего перфоманс и предсказуемость быть не обязано.Вернитесь в реальность. Вот вам видео, которое заставит о ней задуматься:
https://www.youtube.com/watch?v=qbKGw8MQ0i8Если нет 50 минут времени спойлер: видео про то, что никакие операции delete и никакие системные вызовы не бесплатны (даже если у вас rust). Видео про то, что если сделать так, что ваша программа работает быстро на Windows, то она начнет работать быстрее и на Linux.
От себя дополню, что в любом реальном приложении, работающем с большим количеством файлов, сокетов и с базами операция удаления данных может стать жутко медленной. Причем особенно сильно это кусает тех, кто пишет на С++. Вот есть у вас небольшая абстракция:
1. Интерфейс / абстрактный класс
2. Наследник, выделяющий динамическую память в конструкторе и удаляющий в виртуальном деструкторе
3. Наследник наследника, выделяющий динамическую память в конструкторе и удаляющий в деструкторе
Удаление из памяти большой коллекции таких объектов обычной операцией delete приведет к фризу приложения, если объектов слишком много (грид загрузили из базы, например, отобразили и потом решили закрыть форму и удалить объекты из памяти)Чтобы такое правильно удалить нужно:
- Создать "отложенный таск", то есть задачу на удаление в отдельных тредах
- Создать функционал, который позволит передать объекты на удаление и удалить их чуть позже
- Считать ссылки, чтобы не удалить случайно те объекты, которые использует что-то еще
Если вам нужно "лениво" подгружать данные из источника и что-то кэшировать, то эта штука станет еще сложнее.И вот после того как вы всё это сделали, я вас лично поздравляю! Вы переизобрели собственный GC имени собственного приложения. У меня 2 вопроса:
- Вы точно-точно хорошо провели время изобретая собственный велосипед?
- Какова квадратность колёс вашего велосипеда?То что при разработке модулей ядра и драйверов никакой стандартный GC никогда не подойдёт это очевидно. Но то что он не нужен и убивает производительность - это ложь. Java с её несколькими GC под разные случаи жизни и .NET не лезут в системное программирование, но те языки, которые вовсе не имеют GC на самом деле заставляют программиста переизобретать свой GC, когда задача сложнее Hello World. И да, в видео выше показано просто простое скачивание и разархивирование файликов, которое привело к тому, что оптимизация потребовала начать создавать GC.
> Надеюсь это объясняет почему ява и дотнет на этом фоне выглядят как легаси, а их носители - как динозавры на пешеходном переходе. Каковыми и являются. Им это нечем крыть. Вообще совсем.
Также выступающий жалуется на получение "nastygrams". Хамство, зависть и ничем не обоснованное чувство собственного превосходство - это большие проблемы среди невежественных членов так называемого "сообщества". Лекарством от этого является только повышение квалификации и расширение кругозора за счет образования и решения большего количества разных задач.
> Вернитесь в реальность. Вот вам видео, которое заставит о ней задуматься:Я вижу что в реальности можно в принципе писать на хрусте даже вот именно фирмвари если подраспереться.
> rust). Видео про то, что если сделать так, что ваша программа
> работает быстро на Windows, то она начнет работать быстрее и на Linux.Тут топик про СИСТЕМНУЮ ФИРМВАРУ, на минутку. И тут вы такой - тыдыщ - с мувиком на 50 минут и какими то программами для виндус и линукс. Это конечно круто, но - вас куда-то не туда понесло, имхо, с вашими поучениями. Меня интересует системный аспект. И ява в нем - вообще никто и звать никак по сути. И дотнет где-то там же.
> От себя дополню, что в любом реальном приложении, работающем с большим количеством
> файлов, сокетов и с базами операция удаления данных может стать жутко
> медленной. Причем особенно сильно это кусает тех, кто пишет на С++.Даже в любом реальном UEFI-приложении? Кажется единственная база с которой они реально работают - база ключей секурбута какая разве что. И она так то небольшая.
И вот на си++ таки можно получить неплохой контроль за поведением. Без лишней автоматики там где ее не должно быть и баста. А на сях это еще проще. Чем больше абстракций - тем хуже предсказуемость и понимание кодера что реально произойдет, каков worst case, что может обломаться и проч.
> 2. Наследник, выделяющий динамическую память в конструкторе и удаляющий в виртуальном деструктореЕсли это все в системной фирмваре, наверное, кодера лучше уволить, если он не может железно обосновать зачем все это великолепие в системной фирмвари вдруг потребовалось.
> 3. Наследник наследника, выделяющий динамическую память в конструкторе и удаляющий в деструктореДа, и какая же фирмвара то без фабрики фабрик фабрик фабрик?!
> Удаление из памяти большой коллекции таких объектов обычной операцией deleteВот интересно где б системная фирмварь могла таким вообще заняться и зачем?
> поздравляю! Вы переизобрели собственный GC имени собственного приложения. У меня 2
> вопроса:
> - Вы точно-точно хорошо провели время изобретая собственный велосипед?
> - Какова квадратность колёс вашего велосипеда?У меня есть ответ: я зато в отличие от вон того булшита имел 100% контроль над происходщящим в рантайме. А не гадал какую хню откаблучит рантайм, чем мне удружат в новой версии и что там еще. А если это системная фирварь, там половины этих абстракций - и проблем - тупо не было.
> То что при разработке модулей ядра и драйверов никакой стандартный GC никогда
> не подойдёт это очевидно. Но то что он не нужен и
> убивает производительность - это ложь.Ну как бы хрустики делают игогошников только в путь по перфомансу. Не напрягаясь особо.
> Java с её несколькими GC под разные случаи жизни и .NET не лезут в
> системное программирование, но те языки, которые вовсе не имеют GC на самом деле заставляют
> программиста переизобретать свой GC,Или не заставляют. В любом случае - я со своей стороны считаю неотключаемый GC фатальным недостатком для себя.
> когда задача сложнее Hello World. И да, в видео выше показано просто простое
> скачивание и разархивирование файликов, которое привело к тому, что оптимизация
> потребовала начать создавать GC.Сдуру можно и ... сломать... но мы вообще тут в топике про системный фирмвар если что. А это еще более лимитировано чем кернел. Кернел линя позволяет себе всякие штуки типа аналога DEFER-а, воркер-треды и прочие продвинутые абстракции. В фирмвари такое городить не то чтобы нельзя но душновато.
> Также выступающий жалуется на получение "nastygrams". Хамство, зависть
> и ничем не обоснованное чувство собственного превосходство -Я лишь честно сказал что думаю о явах и дотнетах когда уже есть хруст. Он может и в их нишу, и в системную. Это делает его более универсальным и привлекательным в целом. Жабист или дотнетчик в принципе в САБЖЕ - инвалиды на обе ноги. Даже соревнования не будет, господа на поле не явятся.
> это большие проблемы среди невежественных членов так называемого "сообщества".
> Лекарством от этого является только повышение квалификации и расширение кругозора
> за счет образования и решения большего количества разных задач.Человеческий мозг обладает ограниченным ресурсом. Поэтому при прочих равных логично брать более универсальный инструмент.
> Вернитесь в реальность. Вот вам видео, которое заставит о ней задуматься:Я вижу что в реальности можно в принципе писать на хрусте даже вот именно фирмвари если подраспереться.
> rust). Видео про то, что если сделать так, что ваша программа
> работает быстро на Windows, то она начнет работать быстрее и на Linux.Тут топик про СИСТЕМНУЮ ФИРМВАРУ, на минутку. И тут вы такой - тыдыщ - с мувиком на 50 минут и какими то программами для виндус и линукс. Это конечно круто, но - вас куда-то не туда понесло, имхо, с вашими поучениями. Меня интересует системный аспект. И ява в нем - вообще никто и звать никак по сути. И дотнет где-то там же.
> От себя дополню, что в любом реальном приложении, работающем с большим количеством
> файлов, сокетов и с базами операция удаления данных может стать жутко
> медленной. Причем особенно сильно это кусает тех, кто пишет на С++.Даже в любом реальном UEFI-приложении? Кажется единственная база с которой они реально работают - база ключей секурбута какая разве что. И она так то небольшая.
И вот на си++ таки можно получить неплохой контроль за поведением. Без лишней автоматики там где ее не должно быть и баста. А на сях это еще проще. Чем больше абстракций - тем хуже предсказуемость и понимание кодера что реально произойдет, каков worst case, что может обломаться и проч.
> 2. Наследник, выделяющий динамическую память в конструкторе и удаляющий в виртуальном деструктореЕсли это все в системной фирмваре, наверное, кодера лучше уволить, если он не может железно обосновать зачем все это великолепие в системной фирмвари вдруг потребовалось.
> 3. Наследник наследника, выделяющий динамическую память в конструкторе и удаляющий в деструктореДа, и какая же фирмвара то без фабрики фабрик фабрик фабрик?!
> Удаление из памяти большой коллекции таких объектов обычной операцией deleteВот интересно где б системная фирмварь могла таким вообще заняться и зачем?
> поздравляю! Вы переизобрели собственный GC имени собственного приложения. У меня 2
> вопроса:
> - Вы точно-точно хорошо провели время изобретая собственный велосипед?
> - Какова квадратность колёс вашего велосипеда?У меня есть ответ: я зато в отличие от вон того булшита имел 100% контроль над происходщящим в рантайме. А не гадал какую хню откаблучит рантайм, чем мне удружат в новой версии и что там еще. А если это системная фирварь, там половины этих абстракций - и проблем - тупо не было.
> То что при разработке модулей ядра и драйверов никакой стандартный GC никогда
> не подойдёт это очевидно. Но то что он не нужен и
> убивает производительность - это ложь.Ну как бы хрустики делают игогошников только в путь по перфомансу. Не напрягаясь особо.
> Java с её несколькими GC под разные случаи жизни и .NET не лезут в
> системное программирование, но те языки, которые вовсе не имеют GC на самом деле заставляют
> программиста переизобретать свой GC,Или не заставляют. В любом случае - я со своей стороны считаю неотключаемый GC фатальным недостатком для себя.
> когда задача сложнее Hello World. И да, в видео выше показано просто простое
> скачивание и разархивирование файликов, которое привело к тому, что оптимизация
> потребовала начать создавать GC.Сдуру можно и ... сломать... но мы вообще тут в топике про системный фирмвар если что. А это еще более лимитировано чем кернел. Кернел линя позволяет себе всякие штуки типа аналога DEFER-а, воркер-треды и прочие продвинутые абстракции. В фирмвари такое городить не то чтобы нельзя но душновато.
> Также выступающий жалуется на получение "nastygrams". Хамство, зависть
> и ничем не обоснованное чувство собственного превосходство -Я лишь честно сказал что думаю о явах и дотнетах когда уже есть хруст. Он может и в их нишу, и в системную. Это делает его более универсальным и привлекательным в целом. Жабист или дотнетчик в принципе в САБЖЕ - инвалиды на обе ноги. Даже соревнования не будет, господа на поле не явятся.
> это большие проблемы среди невежественных членов так называемого "сообщества".
> Лекарством от этого является только повышение квалификации и расширение кругозора
> за счет образования и решения большего количества разных задач.Человеческий мозг обладает ограниченным ресурсом. Поэтому при прочих равных логично брать более универсальный инструмент. Лично мне вообще не интересны ЯП которые в системщину не могут.
> И тут вы такой - тыдыщ - с мувиком на 50 минут и какими то программами для виндус и линукс. Это конечно круто, но - вас куда-то не туда понесло, имхо, с вашими поучениями. Меня интересует системный аспект. И ява в нем - вообще никто и звать никак по сути.Не буду всё цитировать, а вместо этого скажу по пунктам:
1. Это вас не туда несет когда, вы ругаете GC за низкую производительность. Это вообще никак не связано напрямую. У вас всегда есть логика удаления объектов многопоточная она и сколько в ней наворотов зависит от архитектуры, под которую написан код. И не важно изобретал её программист сам или её предложил рантайм.
2. Вы смешиваете прошивки и системное ПО. И зря, потому что "2 billion devices running Java" - это как раз про прошивки. Системная часть обычно микроядерная и нужна только для того чтобы стартануть JVM. Вы посмотрите на современные BMC, посмотрите на всякие Intel ME и аналогичные AMD-зонды. Это миниксы с Java и это тоже считается за прошивки.
3. На Java и .NET не пишут системное ПО в классическом смысле. То есть не пишут драйверы, ядра ОС и модули. Это технически не возможно и никто и не стремится. Иногда пишут на С++, но даже в мире Windows это считается моветоном. Да Rust это может и может лучше чем С++.
4. Здесь речь не про Linux а про UEFI, которая сама по себе не просто прошивка, а полноценная ОС. Её драйверы - это инициализационные прошивки устройств. Вы юзерспейные программы можете под UEFI писать. UEFI - это другая ОС.> Жабист или дотнетчик в принципе в САБЖЕ - инвалиды на обе ноги.
> Человеческий мозг обладает ограниченным ресурсом.Научись говорить за себя. Это твой мозг ограниченный и невежественный. Ты и тебе подобные бараны - антиреклама rust.
> Он может и в их нишу, и в системную. Это делает его более универсальным и привлекательным в целом.
В их нишу он не может. В системную может, если попинать слегка и допилить. Но в основную нишу .NET и Java не может. И я даже не уверен, что стоит тратить время на объяснения почему... ты слишком глуп и реальных задач скорее всего не видел, раз пишешь такие глупости.
Вот примеры (про бизнес нишу с приложениями обрабатывающими НСИ):
1. Если в языке нет высокопроизводительной реализации SAX-парсера XML - язык не попадает в нишу. Кстати поэтому и питон пролетает мимо и много чего еще
2. Никто в этом мире не работает с БД напрямую. Нужны абстракции по управлению памятью и ORM.
3. GUI. В Rust нет и ближайшее время не будет Native GUI. Он не способен на это пока.
4. Маршалинга нет. Без маршалинга в этой нише нечего делать, а то что есть через С даром там не надо.
Старые приложения никто не будет переписывать на Rust вообще. В этом мире нет поехавших хамовитых энтузиастов. Новые приложения никто не будет писать пока стандартная библиотека не дорастёт до размеров хотя бы .NET не то что Java...> Ну как бы хрустики делают игогошников только в путь по перфомансу. Не напрягаясь особо.
Если не в системном ПО, то rust пригоден максимум микросервисы в кубике крутить. Туда перемещают проблемные куски монолитных приложений, но основная работа с Master Data Management через эту архитектуру не идёт. Да и там одна сплощняя вебня и gRPC. В споре rust vs go я займу сторону rust, по многим причинам, но это не потому что rust такой хороши, а скорее потому что он лучше на фоне go.
> Не буду всё цитировать, а вместо этого скажу по пунктам:
> 1. Это вас не туда несет когда, вы ругаете GC за низкую
> производительность. Это вообще никак не связано напрямую.Таки связано. GC требует времени на выполнение, привносит непредсказуемость в отклик и перфоманс, а вон те на ваше горе придумали ряд способов обойтись без этого всего.
Язык с неотключаемым GC сразу пролетает в системщине и смежных вещах, типа игорей, либ, алго, реалтайма, и проч где такое поведение не является приемлимым. И нефиг синдромом утенка светить имхо.
> У вас всегда есть логика удаления объектов многопоточная она и сколько
> в ней наворотов зависит от архитектуры,Давайте начистоту? Вы кажется не понимаете как это все работает внутри, но с менторским тоном лечите. В зависимости от того что и как - это могут быть и временные аллокации в стеке, которые (де)аллоцируются хардваром "нахаляву". И си - и частично хруст - могут работать и без динамических аллокаций, например. Это открывает новые горизонты. Которые вам вообще не светят. При том это выбираемо кодером под ситуацию. В отличие от.
В случае стека "аллокация" и "деаллокация" сводится к по сути записи в 1 регистр stack pointer. И собссно это и делает аллокации на стеке куда более быстрыми и халявными. Ах да, так можно было. Там есть и свои минусы, но я не вижу смысла дебатировать с вами на эту тему.
> программист сам или её предложил рантайм.
Для системщины и смежных кейсов (либ, реалтайма, игр, алго, ...) важно чтобы рантайм не стоял на пути и был опцией, а не с ножом к горлу. Разница между системным ЯП и средством для постановки индусов в стойло - пролегает вот там имхо. На горе этих - хруст может и в эти ниши залезать. Т.е. тот кто разучил хруст - априори мощнее и имеет больше возможностей. И это плохие новости для жабистов и дотнетчиков. Вы же "ответный вылет" на поле системщиков не сможете. Безвыигрышное комбо -> вас хорошенько подвинут.
> 2. Вы смешиваете прошивки и системное ПО. И зря, потому что "2
> billion devices running Java" - это как раз про прошивки.Это маркетинговый булшит. А реально жабисты могут делать в основном 2 вещи, писать жутковатый бизнес крап да сдаться в рабство гуглу. Дотнетчики даже второй опции лишены. Поэтому делают жутковатых монстров под винду. На фоне которых старый uTorrent - как творение богов, а тут боги кончились, смертные пришли, почувствуйте разницу дескать :)
> Системная часть обычно микроядерная
Обычно? Это где например? В ME чтоли? :)
> и нужна только для того чтобы стартануть JVM.
Вот прямо обычно? Вы это рассказываете любителю фирмвари кодить, если что :)
> Вы посмотрите на современные BMC, посмотрите на всякие Intel ME и
> аналогичные AMD-зонды. Это миниксы с Java и это тоже считается за прошивки.Оно на грани "side by side операционки" по сути. С таким же успехом можно считать прошивкой Linux в роутере или как payload Coreboot. При том роутеров, без всякой явы - тоже наверное миллиарды уже. Фирма ARM называла что-то типа более 100 млрд, чтоли, ядер - на этом фоне 2 миллиарда девайсов - не "обычно" а "жалкие 2%" может случайно оказаться.
> 3. На Java и .NET не пишут системное ПО в классическом смысле.
Вы вообше не конкуренты вон тем господам. А вот они вас с хрустом смогут неплохо подвинуть. Тем более что это будут мощные кодеры, алгоритмисты и проч. Они вполне могут надрать зады. И надерут. Я предвижу дачу конкретных мастерклассов на вашем поле.
> но даже в мире Windows это считается моветоном. Да Rust это
> может и может лучше чем С++.Мне кажется что у них были более удачные идеи в целом. Си++ стал довольно сложный, но при этом страдает рядом сишных проблем и это трабл на предмет статического анализа.
> 4. Здесь речь не про Linux а про UEFI, которая сама по
> себе не просто прошивка, а полноценная ОС.Так и запишем: оказывается, u-boot - "полноценная ОС". А что - он до кучи умеет вывешивать минимальный EFI stub достаточный для пинка EFI программ, если разрешить в билдсистеме. Де факто мизер кода, очень тонкая трансляция в кишки u-boot.
> Её драйверы - это инициализационные прошивки устройств.
Это слишком смелое заявление от гражданина который явно не фирмварщик.
> Вы юзерспейные программы можете под UEFI писать. UEFI - это другая ОС.
Если я ничего не путаю, в окружении EFI вообще нет деления на "кернел" и "юзер" и поэтому понятие "юзерспейс" вообще не имеет смысла: такая абстракция в этот момент еще не существует.
> Научись говорить за себя. Это твой мозг ограниченный и невежественный. Ты и
> тебе подобные бараны - антиреклама rust.Я вообще сишник. Можете перестать юзать сишный софт, заодно и посмотрим как это у вас получится, вот, фирмвару EFI снесите для начала, заодно можно и бутлоадеры с кернелом и либами выпилить. Посмтрим на что ява и дотнет без сей годится? Вот запустить систему сишным софтом без яв и дотнеттов - легко. У меня вообще ни явы ни дотнета не установлено, например.
Но хруст интересен тем что решает ряд проблем которые в сях подутомили - а заодно позволяет и на более масштабном и высокоуровневом поле попроще поиграть. До кучи. Так что я предвижу забавные прецеденты.
>> и привлекательным в целом.
> В их нишу он не может. В системную может, если попинать слегка
> и допилить. Но в основную нишу .NET и Java не может.ИМХО это весьма сомнительное утвержление. Ну так - глядя как на хрусте вон всякие наворачивают и low level и "бизнеслогику" всяких околокриптовых сервисов например. При том умение при нужде и в low level вклиниться позволяет им легко и быстро заделывать проблемы перфоманса, пока такие как вы сутками зеленеют в профайлерах.
> И я даже не уверен, что стоит тратить время на объяснения
> почему... ты слишком глуп и реальных задач скорее всего не видел,
> раз пишешь такие глупости.Мы принадлежим к разным мирам, и меня больше интересует системщина или как максимум geneal purpose.
> Вот примеры (про бизнес нишу с приложениями обрабатывающими НСИ):
> 1. Если в языке нет высокопроизводительной реализации SAX-парсера XML - язык не
> попадает в нишу. Кстати поэтому и питон пролетает мимо и много чего ещеТем не менее, с практической точки зрения даже си или си++ с libxml могут рюхать с XML почти все что угодно. Что дохреналион программ и делает. Черт, де факто они любят XML больше чем допустим ... тадам ... XHR в вебе, где вот именно X как раз и отвалился уже по сути, мало кто пуляет XHR с вот именно "XML" внутри. Потому что парсить его даже в браузере - ну такое себе.
> 2. Никто в этом мире не работает с БД напрямую. Нужны абстракции
> по управлению памятью и ORM.БД это вообще в целом - нишевой случай. Мир не заканчивается на "работе с БД". Ну и вообще-то абстракции такого уровня - можно даже к сишке прицепить. Если нужно. А если не нужно, можно сделать вместо энтерпрайзного урода мелкую шуструю программу. Чего вон тем не дано. И для себя мне как-то прожкой на 20 кил отрабатывающей моментально приятнее пользоваться чем уродом с рантаймом где рантайм запускается дольше чем прога работает, а на виртуалке - вообще капец. Да, приветы powershell и дотнету в этом аспекте, время старта этой шляпы - ацкий треш!
> 3. GUI. В Rust нет и ближайшее время не будет Native GUI.
Его можно легко интерфейснуть к системным либам. В яве с ЭТИМ вообще перманентные грабли. Да и майкрософт с своими WPF и WinForms определиться не мог как правильно, при том что нативное там вообще-то WinAPI и из контролы изначально. И в результате господа развели бардака и страшных как смерть программ и что-то блеят про "нативный гуй". У кого что болит, видимо.
> Он не способен на это пока.
Он может интерфейситься к системным либам - и этого в общем то достаточно.
> 4. Маршалинга нет. Без маршалинга в этой нише нечего делать, а то
> что есть через С даром там не надо.Нишевая штука, нужная сильно некоторым. Потому и похрен почти всем.
> Старые приложения никто не будет переписывать на Rust вообще.
> В этом мире нет поехавших хамовитых энтузиастов.Если это про энтерпрайзный софт, это довольно маргинальный закуток экосистемы софтостроя в целом, который не особо влияет в целом на мир вокруг нас.
> Новые приложения никто не будет писать пока
> стандартная библиотека не дорастёт до размеров хотя бы .NET не то что Java...Лично мне вообще все равно чем там будут пользоваться полтора кговавых энтегпрайза. Я это никогда не увижу - и это достаточный повод чтобы не париться особо на эту тему.
>> Ну как бы хрустики делают игогошников только в путь по перфомансу. Не напрягаясь особо.
> Если не в системном ПО, то rust пригоден максимум микросервисы в кубике крутить.Воооон те сервисы для крипты кажется были не такие уж и "микро". И кстати вот - более гибкие и шустрые откусывают в общем то смежное поле которое уже довольно близко к вам. И возьмут свое.
> Туда перемещают проблемные куски монолитных приложений, но основная работа с
> Master Data Management через эту архитектуру не идёт. Да и там одна сплощняя вебня
> и gRPC. В споре rust vs go я займу сторону rust, по многим причинам, но это не потому
> что rust такой хороши, а скорее потому что он лучше на фоне go.Ну я как бы рассуждаю со своей колокольни. Когда в gccrs допилят borrow checker и ко - у меня будет определенный соблазн посмотреть чего хруст мог предложить. Игого с неотключаемым GC мне не интересен, как и ява с дотнетом. И честно, маршалинг и базы с 100500 записей - далеко не главные проблемы в моей жизни. Представляете?! Для меня это P100500, скажем прямо. А неотключаемый GC - "showstopper" для многих моих начинаний.
Давай так. Игровые движки-то на С перестали писать, а ты про rust воображаешь. C++ и C# там занимают почти всё пространство, перехода на rust даже близко не предвидится.Ты гордо заявляешь, что rust может заменить Java и .NET на их же нише, но при этом пишешь ахинею про XHR.
Когда на rust появится XML-либа способная прожевать многогигабайтные потоковые проливки и перестроить потоки, то тогда и поговорим. В rust поддержка XML, когда я последний раз его видел была не лучше чем в python. А я тебе говорю про высокопроизводительные SAX-парсеры. А ты мне про libxml. У меня нет нематерных слов, чтобы описать этот редхатовский гномовысер, который не способен ни на что. Косорылые бараны писяют криво из-за того что у них DOCX не открывается и винят в этом MS с её якобы проприетарными (на самом деле открытым) стандартом OOXML, а по факту у них XML нормально не работает и не поддерживает хоть сколько-нибудь современные стандарты W3ORG и OASIS.
> БД это вообще в целом - нишевой случай.
Нишевой случай - это эмбедовка и системное программирование. Большая часть кода пишется именно для работы с данными
> Если это про энтерпрайзный софт, это довольно маргинальный закуток экосистемы софтостроя в целом, который не особо влияет в целом на мир вокруг нас.
Ага. Не влияет. Как скажет консорциум Open Group так и будет. Сказали они в 90-е закопать CDE и X11 и перейти на Windows для десктопа - промышленность перешла. Сказали использовать Java EE, все начали писать на ней. Сказали выкинуть Java EE и перейти на микросервисы на специально оформленный Kubernetes внутри инфраструктуры виртуализации - ты не поверишь. Мы здесь. Именно группа промышленников решает, какие технологии будут использоваться. И если ты попрёшь против этого, будешь выкаблучиваться и придумывать как правильно, то они просто сделают по своему и пошлют тебя нафиг со всеми твоими знаниями. Это уже бывало, результат назывется COBOL. С него было велено переходить на БД с хранимыми процедурами и вот только потом на Java EE. А с пришествием Kubernetes и исчезновением Java EE расцвели микросервисы на дотнете, потому что промышленники не переучивают своих джавашных и дотнетных разрабов на rust и go. Не окупится.
Ты можешь продолжать жить в своём замкнутом мире, где маршалинг - это нишевая штука, вот только даже прости б-же JavaScript может динамически подгрузить модуль из источника и инстанцировать его. В rust этого пока нет. В Go этого нет by-design из принципа, а в rust именно что пока нету, недоделами. Через С линкуются, а это не удобно.
Я не против того чтобы GC был в языке отключаемый. Просто ты живешь в танке и не понимаешь, что в общем случае GC нужен и производительность с ним или без него - это вопрос прямоты рук программистов стандартной либы и твоих. И вот в rust его пока нету. Если он хочет в какую-то нишу вне ядра, драйверов или пары нативных либ, он его сделает. Сколько-нибудь серьёзное приложение на нём написать не возможно.
> Давай так. Игровые движки-то на С перестали писать,Да вон Xonotic до сих пор пиляет и релизится. Но вообще ООП хорошо маппится на то что в играх, вот тут не поспоришь.
> а ты про rust воображаешь.
Rust может в более высокоуровневые конструкции.
> C++ и C# там занимают почти всё пространство, перехода на rust даже близко не предвидится.
Мне уже попадались какие-то потуги вот имнено этого, на хрусте, при том что я не искал специально. А таки народ пыжится, и то что сейчас и то что через 10 лет - откуда вам знать?
> Ты гордо заявляешь, что rust может заменить Java и .NET на их
> же нише, но при этом пишешь ахинею про XHR.Я думаю что хруст заметно подвинет этих в ряде ниш. XHR так, ремарка. Ну вот не нравится мне XML. Но походу си/си++ кодеры любят XML больше чем вебдевы. Хотя логичнее было бы наоборот.
> Когда на rust появится XML-либа способная прожевать многогигабайтные
> потоковые проливки и перестроить потоки, то тогда и поговорим.1) Такая @#$нина вообще не является интересным лично мне кейсом и я не сильно мониторю такой маразм, простите.
2) Для себя я буду считать что если кто ЭТИМ занимается, он лоханулся с форматом.
3) Но таки я знаю где БОЛЬШИЕ XML взять, во: https://wiki.openstreetmap.org/wiki/Rust - эти явно умеют Очень Большие XML. Типовой размер этих XML где-то 250-300 гигз, достаточно крупно? Хотя в силу такого размера там люди PBF (protocol buffers) полюбили, он примерно в 10 раз меньше (там правда сжатие есть). К вопросу о форматах, ага.> В rust поддержка XML, когда я последний раз его видел была не лучше чем
> в python. А я тебе говорю про высокопроизводительные SAX-парсеры.Если господа жрут planet.xml и даже вику написали - рискну предположить что производительность у них была не такой уж и плохой. Эта штука ~300 гигз сейчас весит распакованая.
> А ты мне про libxml. У меня нет нематерных слов, чтобы описать этот редхатовский
> гномовысер, который не способен ни на что.Вообще умеет он IIRC прилично, но довольно большой, страшный, я тоже не понял чего он всем так дался. Но факт в том что сишники и плюсеры это юзают. И много. Без понятия почему.
> из-за того что у них DOCX не открывается и винят в этом MS с её якобы проприетарными
И правильно делают!
1) Спеки на формат в 6000 страниц? Господа индусы @#%$улись!
2) Метод принятия этого позора ISO выглядит как коррупция.
3) Народ после выхода этого "стандарта" накидал оптом тривиальные тесткейсы, прямо по MSовским спекам деланые. Только MSO вот их не открывал чего-то. Что и добавило радости к восприятию этого стандарта.А как стандарт юзать если открытие генереного по спекам документа - рандом?! Так что рассуждая о косоруких - будьте готовы что вам этот фавор вернут. Хотя может MSO юзал libxml? :D.
> (на самом деле открытым) стандартом OOXML, а по факту у них XML нормально
> не работает и не поддерживает хоть сколько-нибудь современные стандарты W3ORG и OASIS.Да вот что-то после выхода супер-стандарта MSO - народ по спекам файлов нагенерил. И заметил что откроет ли это файло MSO - полная лотерея. Зачем нужны такие "открытые спеки" я не понимаю. Да и объем спеков в 6000 страниц - если краткость сестра таланта, эти господа были бездарны чуть более чем полностью.
> Нишевой случай - это эмбедовка и системное программирование. Большая часть кода пишется
> именно для работы с даннымиЭмбедовка и системщина - по сути в каждом доме. А базы - "где-то там" и большая часть двуногих, включая и програмеров вообще это не увидит. Более того - без вон того у вас бы сервак не стартанул даже и про базы речь не шла бы от слова вообще.
> Ага. Не влияет. Как скажет консорциум Open Group так и будет. Сказали
> они в 90-е закопать CDE и X11 и перейти на Windows
> для десктопа - промышленность перешла.Да вот что-то линуха в промышленности и рядом - все больше и больше. Блин, его уже даже в космические корабли засунули. И марсианский вертолетик. Приветы винде :).
> Сказали использовать Java EE, все начали писать на ней. Сказали выкинуть Java EE
> и перейти на микросервисы на специально оформленный Kubernetes внутри инфраструктуры
> виртуализации - ты не поверишь. Мы здесь.Вот в это я как раз поверю. Девопсы тема модная, массовая, дешевая. Заодно всякие GOпники с хрустиками как раз и порубятся - глядя на вон тех дино.
> Именно группа промышленников решает, какие технологии будут использоваться.
> И если ты попрёшь против этого, будешь выкаблучиваться и придумывать как
> правильно, то они просто сделают по своему и пошлют тебя нафигНу, у меня есть свои сегменты которые я окучиваю - а вон те пусть сами с своим счастьем разбираются.
> со всеми твоими знаниями. Это уже бывало, результат назывется COBOL.
> С него было велено переходить на БД с хранимыми процедурами и вот
> только потом на Java EE.А таки - воооон там до сих пор какой-то банк даже програмеров ищет на это дело. Или искал недавно. Их правда уже и нет, а банки с этим - есть. Пролетало не так давно на правах курьезной новости где-то.
> А с пришествием Kubernetes и исчезновением Java EE расцвели микросервисы на дотнете,
А точно на дотнете? Микросервисы очень игогошники любят, они и получают карт-бланш. Там HTTP серв умещается на страничку и выглядит это на порядок менее страшно чем ваше легаси зло@#$чее, так, глядя на примеры этого у игогошников. Хрустики иногда наседают на пятки, и где не могут взять лаконичностью и эстетикой - берут перфомансом, у них GC нет, это их козырь.
> потому что промышленники не переучивают своих джавашных и дотнетных разрабов
> на rust и go. Не окупится.Можно просто вышибить и нанять новых готовых, их уже появляется, особенно на go.
> Ты можешь продолжать жить в своём замкнутом мире, где маршалинг - это
> нишевая штука, вот только даже прости б-же JavaScript может динамически подгрузить
> модуль из источника и инстанцировать его. В rust этого пока нет.Rust и JS так то для довольно разного. Ну и на системном ЯП кроме всего прочего можно сделать недостающие абстракции. А вот например отломать GC тулсе для постановки индуса в стойло - не дано, и тому подобные чудные лимиты.
> В Go этого нет by-design из принципа, а в rust именно что пока нету, недоделами.
И это намекает насколько это все реально надо и распостранено, ага! Было бы надо "для захвата мира" - сделали бы в первых рядах. Но вообще прикольно когда вы сами помогаете оспорить свои идеи, мне эта идея нравится.
> Через С линкуются, а это не удобно. Я не против того чтобы GC был в языке отключаемый.
Для лично меня - неотключаемый GC это индикатор. Означаюший что я ЭТО изучать не буду. Я просто не индус с расширенным сознанием которого ставят в стойло. И никогда не буду таковым, хоть тресните.
> Просто ты живешь в танке и не понимаешь, что в общем случае GC нужен и
> производительность с ним или без него - это вопрос прямоты рук программистов
> стандартной либы и твоих. И вот в rust его пока нету.Мля, GC даже в си можно сделать. Если это за каким-то хреном и правда надо. Этим системный ЯП и отличается от средства построения индусов. Позволяет лезть в механику глубоко, в том числе делая и недостающие часть паззла если надо. А уроду с неотключаемым GC ничто не поможет, там жесткое деление на "богов" писавших рантайм и "лохов" которым так низя.
А что, никогда не видали на сях DEFER? Или coroutines? А может воркер-треды немнго похоже на JS? Начо, так можно - стоит только захотеть. Ну или вон HTTP серв лезущий на страницу как у Go? Легко. Только еще в перфомансе жесточайше воткнет.
> Если он хочет в какую-то нишу вне ядра, драйверов или пары нативных либ,
> он его сделает. Сколько-нибудь серьёзное приложение на нём написать не возможно.Лично я в гробу видал весь этот сериоус энтерпрайс крап, будем честны, мне совсем не интересен этот кейс. Так что размахивать им передо мной, с рассказом какому там легаси тяжко что-то переписывать и переучивать - да, блин, вон кто-то и на коболе до сих пор шпрехает. Чего б яве и дотнету не присоединиться туда - хз. С чего у них иммунитет то? Си я еще понимаю почему живучий. Системшины на нем дофига, и вот это реально в обозримом будущем не перепишут.
И да, переписать например Linux Kernel - сложнее чем любую вашу сериоус апликуху. Вон гугель с фуксией уже сколько там лет пыхтит. За 7, чтоли, лет - ну, вот, на 2 фоторамках, FAT умеет ажЪ читать.
Программисты делятся на два вида: на тех, для которых языков кроме Си не существует, и на нормальных.
Ни один истинный шотландец, да
>Языки делятся на два вида: на си и на те которые никто не использует.У нас здесь серьёзно присутствует персонаж, считающий, что кроме си нет популярных языков программирования. Это манямир на 10 из 10.
Когда эту штуку (смена логотипа увидел) так и подумал что это дичь с т зр безопасности (да и усложнения кода). Уверен, многие опытные инженеры так и подумали, но маркетинг победил.
> Когда эту штуку (смена логотипа увидел) так и подумал что это дичь
> с т зр безопасности (да и усложнения кода). Уверен, многие опытные
> инженеры так и подумали, но маркетинг победил.С этими гуаноУЕФИ много всякой дичи внутри присутствует. Но конкретно это зачотная фича.
Вообще, всё что "может использоваться для обхода механизма верифицированной загрузки UEFI Secure Boot и аппаратных механизмов защиты, таких как Intel Boot Guard, AMD Hardware-Validated Boot и ARM TrustZone Secure Boot" достойно похвалы и фича очень нужная в хозяйстве.
Жаль, что скорее всего прикроют, раз так громко спалили и в новых, ещё более онально огороженных материнках её уже скорее всего не будет. :((
Копнул бивис у платы. Там вообще BMP-RLE. Итить-колотить.
Ашотакова? Я вот как раз кот для его разбора пишу щас забавы ради.
Юефи волшебная вещь абсолютно.Когда переносил виндовс с одной мамки на другую, винда оказывается, легко и непринуждённо записала какую-то прошивку (сата чтоли контроллера) от старой мамки в новую.
В результате чего мамка кирпич.Выяснил в чём дело после сервиса, ещё одно окирпичивания, и покупки прошивальщика флеч чипов.
Безопасность - высший класс, когда ОС может непринуждённо записать в биос любую дичь.
Это DRM такое. Читайте внимательно EULA - поставляется AS IS.
> Когда переносил виндовс с одной мамки на другуюв след раз не будете такой ерундой заниматься.
а поставите новую винду с нуля, как завещал Билл Гейтс.
или не винду.
>> Когда переносил виндовс с одной мамки на другую
> в след раз не будете такой ерундой заниматься.
> а поставите новую винду с нуля, как завещал Билл Гейтс.
> или не винду.Так как платформа была той-же, имелась надежда что оно заведётся без особых проблем.
> или не винду.
Низачот, это признано багом в прошивке, а не intentional behavior.
Пострадавшему юзеру как-то монопенисуально.
Когда признанный баг — можно требовать ремонта/замены по гарантии.Когда нормальное поведение винды — just enjoy it.
Хотите от винды нормального поведения — ведите себя нормально. Бэкап данных, чистая установка на новой системе. А не вот это вот «всегда так делал, и работало».Речь вообще не об этом. А о том, что UEFI ущербен by design — любой может взять и запросто окирпичить железо.
> Хотите от винды нормального поведения — ведите себя нормально. Используйте только при крайней необходимости, и только на виртуалке.Починил.
Обычно в виртуалке линукс. Впрочем, с появлением WSL это стало ненужной сущностью.
WSL2 - это и есть в виртуалке линукс.
> WSL2 - это и есть в виртуалке линукс.странно что некоторые не понимают этого тезиса.
и хвастаются уникальной безаналоговой функциональностью.
> Когда признанный баг — можно требовать ремонта/замены по гарантии.Ну да, вперёд, попробуйте. Баги в фирмвари и драйверах основанием для замены железа по гарантии не являются, придётся доказывать, что реально неэксплуатабельно. Причём не в вашем конкретном юзкейсе, а классово.
> винда оказывается, легко и непринуждённо записала какую-то прошивку (сата чтоли контроллера) от старой мамки в новуюЧто-то не очень верится. Можно детали?
>> винда оказывается, легко и непринуждённо записала какую-то прошивку (сата чтоли контроллера) от старой мамки в новую
> Что-то не очень верится. Можно детали?Я тоже оказался немного в шоке. Но именно это происходило.
Обойти можно было выставление пароля на биос, загрузкой винды в безопасном режиме, после чего та подхватывала железо, и потом уже ничего левого не писала.
Винда была 8рка вроде. Платформа FM2+ вроде.
Биос восстанавливался только програматором. Я сравнивал дампы флеш памяти, но точно не помню что там находил.
Конкретно вот на AHCI тогда вышел.
Было предположение что это вирус. Но похоже штатная функция винды и юефая.
Одна мать была биостар, а запарывалась асрок, вроде.
Просто изумительно.
>современные прошивки включают код для разбора форматов BMP, ... в котором присутствуют уязвимости, приводящие к переполнению буфера во время разбора некорректных данных.BMP и PNG это вообще 2 самых простых формата. Там чтобы налажать - надо ОЧЕНЬ сильно постараться. PNG, кстати, в списке нет. Можно было просто ограничиться PNG с zlib-сжатием и одним вариантом цветности - и уязвимости не было бы. Это вообще самый очевидный способ, что надо было делать.
А в принципе, это здорово и очень хорошо. Ибо нефиг не давать пользователю контроля за биосом.
PNG не так прост, там deflate.
deflate и есть zlib. но deflate в биосах и так используется. zlib вообще уже вылизан до блеска.
вылизан, ага
буквально на днях словил zip bomb
zip в png - подарок судьбы для кулхацкеров
Но вот чтобы в PCX или BMP с их RLE налажать...
> Но вот чтобы в PCX или BMP с их RLE налажать...Эту дрянь давно пишут какие-то отшибленые индусы, в виндочке, майкрософтовскими тулсами. Что от них ожидается то? Там весь код - дичайший багодром.
И какой-нибудь ACPI - точно такой же багодром. Достаточно посмотреть что тот же линукскернел пишет при парсинге этой интело-мелкософтовской п@раши, там через раз - нарушения спеков. Вплоть до потуг интерпретируемого кода в out of bound доступ (в случае линуха это ессно рубится нафиг, ибо нефиг) и таблиц с неверно заполненными полями так что парсинг того что написано именно как написано - вообще "подразумевает" out of bound доступ (технически-невалидные структуры). Про мелочи типа левака в чексумах даже и упоминать неудобно.
Всё так.
ACPI - это вообще, как бы помягче сказать-то... п*дец какой-то.
> Эту дрянь давно пишут какие-то отшибленые индусы, в виндочке, майкрософтовскими тулсами. Что от них ожидается то? Там весь код - дичайший багодром.Ну а кто ещё в наше время будет писать на языке без безопасных механизмов работы с памятью?
>> Эту дрянь давно пишут какие-то отшибленые индусы, в виндочке, майкрософтовскими тулсами. Что от них ожидается то? Там весь код - дичайший багодром.
> Ну а кто ещё в наше время будет писать на языке без
> безопасных механизмов работы с памятью?Ну как бы ACPI - "интерпретируемый" и "безопасная работа с памятью" - на совести интерпретатора, в меру его талантов. Но, знаете, когда таблицы с их размерами и проч прописаны так что чтение элемента ПОДРАЗУМЕВАЕТ выход за границы легитимного региона прямо на уровне того что в поля структур вбито - возникают определенные вопросы в каком состоянии сознания ЭТО сгенерили. И я не знаю что винда при этом делает, но как валидация обычно - пуск той винды которая преинсталится.
А если вы вдруг сервиспак заапгрейдите, или тем более версию винды, особенно на ноуте... ну... а вам это и не обещали так то... купите новый ноут и попробуйте еще раз :)))
>Там чтобы налажать - надо ОЧЕНЬ сильно постаратьсяТы не поверишь, сишные диды до сих пор программируют исходя из идеи, что никто не подсунет некорректные данные. И если в нормальных языках сработает какая-нибудь защита, то в сишке из-за повсеместного жонглирования указателями будет выход за пределы массива и разыменование мусора.
Может даже показаться,что кто-то всё-таки включает Secure Boot.
Плин. Почувствовал себя уникальным.
Он кое где неотключаем. Мне попадался бюджетный IdeaPad с такой проблемой, пришлось искать и шить анлокнутый бивис. Хорошо хоть проверки цифровой подписи ещё не было и он без проблем прошился.
А зачем вообще логотипы с картинкаме, да ещё чтоб пользователи их сами грузили?Какой-то лютый треш, угар и содомия.
чтобы нескучные обои были. чтобы могли заменить лого асуса на голую бабу и радоваться
Когда ты последний раз менял обои на рабочем столе?
Для того, чтобы изи (или вообще) сменить режим нативной консоли (точнее того, чем она стала...) в ОС для 4090^WWW Убунточке на боль-мень сьедобное на современном монике. Дарю лайфхак :)
> (Intel, Acer, Lenovo) и производителями прошивок (AMI, Insyde, Phoenix)Ух крутые дяди и крытые вендоры, ничего кроме как сп____ опенсорс код и без малейшего аудита запихнуть в критичную систему безопасности на миллиардах устройств. Класс и высший пилотаж.
Они там хоть не GPL код закорпоратили?
С чего ты взял что это опенсорс?
> приводящие к переполнению буфера во время разбора некорректных данныхДа что ж такое! Опять погромисты на богомоезкой не смогли в память!
Так Lenovo же китайская дрянь. Что тут удивительного.
Ещё много лет тому назад когда ноут выбирал мне сразу сказали - Lenovo не брать!
Проблема у вендоров бивисов (AMI, Insyde, Phoenix (бывший Award)), тут ленова не уникальна.
Ну да, в принципе её советуют не брать не из-за бивиса. Как-то слишком много проблем с ними вообще.
Ага. Например, на него можно линукс ставить, а это уже проблема.
> Так Lenovo же китайская дрянь. Что тут удивительного.Как и Apple. Но почему-то многие устраивают вокруг этого достаточно середнячкового железа целый культ.
У бЛинов кроме бивисов ещё и с совместимостью оборудования для type-c портов не всё хорошо. Тыкал один такой к дисплею кабелем type-c - DP - глухое молчание. Дремучий Dell на ура монитор цепанул. Тыкнул ещё приблуду с USB & ethernet-портами - на блиновах началось подключение-отключение, на Dell - просто подключение. А бюджет упилен-с...
шутка про нескучные обои приобретает новый смысл
Но нафига столько форматов? По сути нужен bmp да gif.
Как будто C-разработчик не может устроить переполнение буфера при разборе BMP.
Может. И устраивает.
открой коды парсера BMP от id или valve из 90ых - это не просто дуршлаг, а заборная сетка.
Проприетарная значит надежная
Печаль в том, что из-за идиотов, у которых бегущие по экрану строки текста вызывают экзистенциальный ужас и причиняют невыносимые нравственные страдания, под ударом оказываются и нормальные пользователи.
На столько нормальные, что не в состоянии переключить настройку. Это же читать инструкцию надо! Кто же нормальный читает инструкции?
Ты сейчас сказал очень важную и правильную мысль - есть более важные дела, нежели изучение документации на свистелки и трещалки ради единствеенной цели от них избавиться.
Ну, и от переключения настройки уязвимый код никуда не исчезнет. Как переключили, так и обратно перепереключить можно.
Full Screen Logo стало стандартом где-то во времена четвёртых пеньков.
От этого оно стало меньшей дуростью?
Оно кого-то поставило под удар?
А ведь многие из присутствующих ещё помнят, что одним из преимуществ UEFI во времена его продавливания заявлялась «безопасность». И лично сам помню, как, ознакомившись с его конструкцией, подумал — «вот это будет нажористая тема».
И вот вопрос: был ли хоть ОДИН задокументированный случай внедрения вредоноса в legacy BIOS?
Чернобыль.
Стирание флешки несколько далековато от внедрения в код, расположенный на флешке.
Вот только в то время нередко удавалось стартануть доску с чужим биосом. Так что скажите спасибо, что автор был студентом, а в Гигабайт устроился позже... а то у него были бы варианты "полезной нагрузки" помимо нулей.
"Слышал звон, да не знает, где он"
Хорошо что в платах Orange Pi нет никаких этих ваших Secure Boot совершенно выдуманных ради вендорлока
наоборот есть, даже жеще чем на UEFI.читать: ArmTrusted, TEE.
Просто за вас уже все собрали и подготовили..
> наоборот есть, даже жеще чем на UEFI.
> читать: ArmTrusted, TEE.Вы гоните сэр. На оранжах обычно не прописан никакой секурбут вообще. И ключ root of trust не вшит. Можно свой, в девственный чип вшить самому, китайцы не парятся этим.
А вот в современных интел и амд - в фузы прям с фабы вписаны ключи ME/PSP внаглую. Отдавать управление платформой индейцам там вообше и не собирались. Ах да, ATF (Arm Trusted Firmware) под эти штуки мало того что опенсорсный - так еще и порт на вот эти платформы есть, и - тадам - можно вот именно СВОЙ ATF в их TrustZone запускать. Технически TrustZone просто самый привилегированый режим проца. Из которого можно часть доступов порезать. И если там МОЙ код - то какие проблемы то? Это секурити фича в таком виде. Полезность замка очень зависит от того есть ли от него ключи и у кого они. Вот там ключи - у меня. А в UEFI на x86 - индейцев держат за индейцев. При том весьма нагло, "девственный" проц вообще купить невозможно, ему собственник в терминах секурбута (владелец мастер-ключа в фузах) прописан прям с фабы. И это интель и амд, почему-то. Так что это ИХ платформа, а вы - в гостях. При этом интел и амд всегда могут обойти все ваши потуги. А вот вы будете делать не более чем они вам милостиво позволят. Круто, да? :)
> Просто за вас уже все собрали и подготовили..
Да вообще-то вот там - ВЕСЬ системный софт можно - таки - свой. В отличие от wintel'ской проприетарной дряни. И DTB (DeviceTree) куда как менее глюкаво под линухом чем долбаное ACPI заполняемое какими-то раджами в состоянии расширенного сознания, судя по содержимому его таблиц.
Внимание вопрос. Кого не устраивал старый добрый текстовый интерфейс и зачем его меняли?Принцип минимализма: ответственный код не должен содержать ничего лишнего, не требующегося для работы. Ни красивостей, ни удобства. Голая функциональность.
> Внимание вопрос. Кого не устраивал старый добрый текстовый интерфейс и зачем его меняли?Практически во всех ноутбуках UEFI с текстовым интерфейсом.
Случались ранее биосы с графическим интерфейсом (AMI WinBIOS, например).
Осмелюсь добавить - во всехх НЕДОРОГИХ ноутах. И обычно это InsydeH2O разных версий. Ноуты по текущим ценам от 80+ - вполне могут быть с графическим UEFI Setup. Что Dell, что HP, что вышеупомянутое бЛиново.
> зачем его менялиСекретарши и бухгалтера пугаются.
У них работа требует регулярно ковыряться в биосе?
Ну включают компьютер, а на мониторе строчки какие-то непонятные бегают, а это значит, что всё сломалось, паника, звонки сисадмину
Пугаются бухгалтера отечественных производителей. Придёт тов.майор, увидит "American Megatrends" и примет меры.
Опция показа логотипа при загрузке ОС никак не связана с текстовым интерфейсом настроек прошивки.Без разницы, включил ты опцию через текстовый или графический интерфейс настроек. Важно наличие опции.
Это как в винде: ты можешь включить у,звтмый SMB1 через гуй, а можешь через консоль. От этого ничего не поменяется.
Зато, внезапно, очень даже связана с видеорежимом этого самого UEFI... :D За что и любима норотом. Ибо более безболезненного способа выставить видеорежим при загрузке тачки под уебой, за значит и нативной консоли - а ужо нетути.
Ждём AMD openSIL. Неиронично кстати.
Про эту "уязвимость" не знает только ленивый или в теме.
*или долекий от темы UEFI
Мне одного заголовка хватило)) Сразу представил с десяток..
Блин. Самая важная фича UEFI. И ту - не доделали. Печалька.
Современный маразм:> библиотеки разбора изображений, выполняемые на уровне прошивки без сброса привилегий
Проблема же не в этом. Проблема же в том, что ваша программа не работает. А не в привилегиях.
Халтур-строй-монтаж...