Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз ядра Linux 6.5"	+/–
Сообщение от opennews (?), 28-Авг-23, 11:40
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.5. Среди наиболее заметных изменений: поддержка механизма управления питанием Intel TPMI, системный вызов cachestat, продолжение интеграции поддержки языка Rust,  поддержка протокола Unaccepted Memory, поддержка векторных инструкций RISC-V,  механизм "fprobe-events", перевод в разряд устаревших механизма распределения памяти SLAB, режим "data-only" в Overlayfs, режим монтирования "beneath"... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59670
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Релиз ядра Linux 6.5"	–31 +/–
Сообщение от АНБ (?), 28-Авг-23, 11:40
> продолжение интеграции поддержки языка Rust Радует, что развивают действительно безопасный язык популярный для молодого поколения, что позволит больше привлечь людей для написания ядра. А известно как скоро планируют добавить бинарные блобы для ускорения компиляции?
Ответить | Правка | Наверх | Cообщить модератору

	6. "Релиз ядра Linux 6.5"	–5 +/–
	Сообщение от Аноним (6), 28-Авг-23, 12:14
	Давно пора добавить, но всякие престарелые хиппи противятся этому. Ну, недолго им осталось!
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (187), 29-Авг-23, 03:37
	> Давно пора добавить, но всякие престарелые хиппи противятся этому. Ну, недолго им > осталось! Судя по редоксу, нехиппи стоило бы бояться своих желаний...
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (6), 29-Авг-23, 15:39
	Это потому что текущие разработчики на расте ещё школу не успели закончить, у них все еще впереди!
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Релиз ядра Linux 6.5"	+39 +/–
	Сообщение от Аноним2 (?), 28-Авг-23, 12:31
	Слишком тонко для опеннета, тут могут подумать что ты не шутишь.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	31. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (31), 28-Авг-23, 13:14
	А он и не шутит. Без бинарных блобов долговато ржавчина компилируется. Насчёт популярности, правда, не уверен, что-то вроде популярности перла в ядре.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Релиз ядра Linux 6.5"	+4 +/–
	Сообщение от Аноним (35), 28-Авг-23, 13:41
	Без бинарных блобов, известных как firmware, на большей части современного оборудования ядро Linux либо не работает, либо работает так себе.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Аноним (31), 28-Авг-23, 14:30
	Нормально работает. Только единицы железок требуют внешних блобов (в дополнение к зашитым в железе). Как правило, не работают вайфай и видеокарты. Тут речь всё же про растовский паттерн curl|sh, с запуском случайных файлов из интернета, в целях ускорения и упрощения.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Релиз ядра Linux 6.5"	+11 +/–
	Сообщение от коньюктивит (?), 28-Авг-23, 15:18
	>Только единицы железок требуют внешних блобов >Как правило, не работают вайфай и видеокарты Вот за это я и люблю опенет :)
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Релиз ядра Linux 6.5"	+4 +/–
	Сообщение от Анонимусс (?), 28-Авг-23, 15:29
	> Нормально работает > не работают вайфай и видеокарты Прикольное у вас "нормально" однако...
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	98. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (98), 28-Авг-23, 16:48
	Для сервера и без того, и без другого нормально.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (114), 28-Авг-23, 17:21
	Только если сервер - старый десктоп под кроватью. Потому что на нормальных стоечных серваках стоят сетевые карты под модули SFP+, и оно тоже обычно требует фирмвари.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от коньюктивит (?), 28-Авг-23, 20:15
	Оспади, ну, хоть с фактом "линукс не для десктопа" ты согласен.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	305. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 01-Сен-23, 12:11
	> Для сервера и без того, и без другого нормально. Ну да, суперкомпьютеры для всяких ИИ очевидно без видеокарт работают. У Гугла вообще свои ускорители не  стоят. И в процессорах ну совсем нет встроенных FPGA.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	80. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 28-Авг-23, 16:04
	А у кого сейчас вайфай в системном блоке? У всех внешние роутеры. Видеокарты нормально работают, я всю жизнь сижу на nouveau (NVIDIA). А если же речь идёт о проприетраных блобах, то firmware драйверов для видеокарт не кладут. Проприетарные пакеты для видеокарт нужны только игроманам. В реальной жизни драйвера из firmware не нужны. Требуемые драйвера для броудкомовских блютуз адаптеров в firmware всегда отсутствуют. И чтобы завести свои блютуз адаптеры, все драйвера я скачивал из интернета. Mне иногда кажется что в firmware кладут драйвера для устройств, которые настолько редки, что не продаются в магазине.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	89. "Релиз ядра Linux 6.5"	+/–
	Сообщение от fyjybvec (?), 28-Авг-23, 16:35
	А на ноутах тоже все хорошо? Или туда линукс ставить не нужно? можно и провод, с собой носить, правда не каждый админ позволит совать провода ручками в свою технику Во многих десктопных платах есть вайфа, просто подключил и все работает, но вам наверное это тоже "не нужно"
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (31), 28-Авг-23, 16:36
	>А у кого сейчас вайфай в системном блоке? примерно у всех? >У всех внешние роутеры. именно по этой причине вайфай необходим "в системном блоке", хотя для переносных пк более актуально. > firmware драйверов для видеокарт не кладут устаревшая информация (лет на 10-15), никакие "опенсорсные" дрова видеокарт без проприетарных блобов просто работать не будут никак. У NVIDIA на данный момент самый безблобный драйвер (но чтобы vdpau работал надо было скачивать блобы для него отдельно) и подгрузка блобов для реклокинга через GSP-интерфейс только на самых новейших картах. А так, ты просто не можешь выставить частоту выше минимальной, управлять вентилятором в зависимости от температуры, и многое другое. Это очень мешает в "реальной жизни", поверь. На игры то плевать всем. Все блобы для intel и amd идут вместе с ядром, для nvidia они поставляются отдельно. Штатный пакет с прошивками обычно содержит необходимые блобы для сетевых карт, не знаю, что там скачивать надо. Я использую out-of-tree драйвер сетевой карты только потому что он поддерживает больше функций железа (аппаратный чексуминг пакетов и прочее).
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	105. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (-), 28-Авг-23, 17:02
	В реальной жизни 90% линуксоидов проприетарные драйвера для видеокарт не нужны. Для NVIDIA в firmware лежат какие-то устаревшие блобы, которые в реальной жизни никому не нужны. Реальная ценность каталога firmware завышена. Ты много чего написал, да лично тебе тюнинг в виде "выставления частот", "скорость вентиляторов", "аппаратный чексуминг" и прочее очень нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (31), 28-Авг-23, 17:14
	Выдеокарты не работают без проприетарных прошивок. Юзерспейсная часть может быть "открытой" (как выяснилось не очень, какой-нибудь блендер уже не запустишь нормально), но дополнительные блобы для их работы необходимы всегда. Ты видел, какое слайдшоу на минимальных частотах? Что ты собираешься делать с пк, если для нормальной работы примерно всех без исключения программ сегодня необходима видеокарта? Старые программы отрисовывались на процессоре, но у них тоже проблемы с лагами в нынешних реалиях. Скорость вентиляторов? О, я уверен, ты ценитель перманентных завываний в 100 децибел громкостью, они помогают тебе лучше сконцентрироваться, и это только я такой ценитель странного хочу адекватной работы от купленного железа.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (157), 28-Авг-23, 20:32
	А теперь поговорим про видеокарты от AMD, которые без бинарной firmware, работают только с nomodeset. Надеюсь не нужно писать что это и как это делает видеокарту от красных в аналог видеокарт 90-ых?
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	172. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 28-Авг-23, 22:41
	> А теперь поговорим про видеокарты от AMD, которые без бинарной firmware, работают > только с nomodeset. Надеюсь не нужно писать что это и как > это делает видеокарту от красных в аналог видеокарт 90-ых? Ну как бы нува при переходе в нативный режим тоже фирмвари грузит. И они либо есть либо нет. Да даже i915 современный скурвился и требует фирмварей. Старый таки реально без фирмварей работает, но кодинг все и вся в железе привел к дикой багованости железа от интела и тому факту что драйвер состоял из воркэраундов глюков железа чуть менее чем полностью. Вот видяшники и стали в фирвари выность то что чисто в железе туго шло.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (6), 28-Авг-23, 19:08
	>На игры то плевать всем. Кому плевать, у тех встройка от Intel, которой ни проприетарные драйвера, ни прошивки не нужны. Ну и вай-фай на декстопе используют только дегенераты, даже если он у них есть.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	148. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Аноним (31), 28-Авг-23, 19:38
	Тебе показать в каком месте у интеловской встройки блобики подгружаются или сам найдёшь? Не дегенерат ты наш замечательный. Ещё вроде с новыми чипами не всё так чудесно, там вообще есть дрова?
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (6), 28-Авг-23, 21:01
	Разработчикам linux libre покажи: https://wiki.parabola.nu/Intel
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (31), 28-Авг-23, 21:26
	Ну так они клованы ещё те и статья судя по виду утратила актуальность лет 20 назад, ты прекрасно об этом осведомлён.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 28-Авг-23, 22:44
	> Разработчикам linux libre покажи: https://wiki.parabola.nu/Intel Старый интел реально без блобов работал. Но с энного момента и ему стали нужны блобы. Да - старенький ноут с интельским интегратом и без блобов в графике взлетит. Правда, видеобиос там все ж проприетарный - будет. В флехе. Более новый интеграт от интеля - без блобов вообще не работает.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

	113. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Бывалый смузихлёб (?), 28-Авг-23, 17:20
	интегрированная графика интола или амуде норм заведётся без блобов ?
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	144. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Анонит (?), 28-Авг-23, 19:17
	Так вы блютузоман раз блоб качаете для него.Нет?
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	147. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (6), 28-Авг-23, 19:22
	Пр блютузу звук в тыщу раз лучше, учёные давно доказали.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (157), 28-Авг-23, 20:28
	Видеокарта от AMD от RX 400 и выше обязательно нужен бинарный firmware, если ты не хочешь сидеть с nomodeset. Про последний не нужно расписывать, ты же знаешь что это? ЗЫ Сначало тему изучи, а потом пиши!
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	257. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (257), 29-Авг-23, 19:59
	> Исправлена опечатка «Сначало». Отменить
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 28-Авг-23, 22:27
	> А у кого сейчас вайфай в системном блоке? У ноутов и мелочи. > У всех внешние роутеры. Ну как бы это надежнее и быстрее. Но к ноуту провод таскать такое себе, как и к околомобильным гаджетам всяким. > Видеокарты нормально работают, я всю жизнь сижу на nouveau (NVIDIA). > А если же речь идёт о проприетраных блобах, то firmware драйверов для > видеокарт не кладут. Проприетарные пакеты для видеокарт нужны только игроманам. Э, без фирвари видяхи даже управления питанием не будет в нативном режиме. И оно вообще дальше VGA-адаптера не уедет по сути. А 3D нужен кроме игроманов и в CAD например. В общем, чем даунплеить проблему лучше честно констатировать что есть место для улучшения в этом аспекте. > В реальной жизни драйвера из firmware не нужны. Требуемые драйвера для броудкомовских > блютуз адаптеров в firmware всегда отсутствуют. И чтобы завести свои блютуз адаптеры, > все драйвера я скачивал из интернета. А таки многие вафельницы без фирмвари просто не операбельны. Если кого до .n устроит (в x2 режиме до 300Мбит что обычно за глаза) - ну, ath9k есть. Там единственное что фирмвару требует это ath9k_htc но там фирмвара опенсорсная. Однако всяких .ac там нет. А ath10k и новее - скурвился и требует фирмвару уже, увы. Как и почти все остальные. И даже если кто не требует, у него все равно на борту фирмварь вшита, так что радости мало. Какая разница, снаружи блоб или из флешки догружается, один хрен стремный блоб.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	237. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (6), 29-Авг-23, 15:57
	>А ath10k и новее - скурвился и требует фирмвару уже, увы. Наоборот, что бы там не говорили фанатики Столлмана. В обоих случаях прошивки проприетарные, но для ath10k прошивку пропатчило сообщество, а юзерам ath9k приходится довольствоваться тем, что у них есть. Поэтому наличие механизма загрузки внешних прошивок - лучше, чем его отсутствие. У ath9k_htc раньше прошивка проприетарной была, только потом её открыли.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 30-Авг-23, 01:07
	> Наоборот, что бы там не говорили фанатики Столлмана. В обоих случаях прошивки > проприетарные, но для ath10k прошивку пропатчило сообщество, Какое, в ж@, сообщество у бинарного вареза? Мутные васянокрекеры? И что они там пропатчили? Эта хрень весом более мега бывает! Они прям от и до проаудитили что этот мег крапа вообще может? И какие там подставы? А подстав в вафле можно более 9000 запихать. Типа небольшого ассистирования ремоте в допустим прецизионном определении вашей локации. Так, мелочи. > а юзерам ath9k приходится довольствоваться тем, что у них есть. А в ath9к вообще нет никаких фирмварей, это просто хардварный автомат управляемый драйвером. Единственные девайсы где вообще с ath9k прошивка есть - это usb'шные ath9k_htc и проц там только для того чтобы гейтовать usb в pcie, на котором висит обычный ath9k "как обычно". У 7000-й серии это 2 чипа и pcie даже явно торчит из чипа, у 9271 и ко это в 1 чип упаковали но идея осталась. А само радио все тот же ath9k @ PCIe. Исходники тех прошивок на ath9k_htc выложил внезапно сам атерос и это нормальные рекомпиляемые сорцы, а не васянский варез. Все что для этого надо - тулчейн для Xtensa. И кстати есть и очень интересные прошивки для ath9k_htc где процик запрягли чуть больше чем только бриджить pcie <-> usb. Но их дают в лапки только исследователям вафель в силу того что это даже эффективнее чем MDK3/4 может быть. > Поэтому наличие механизма загрузки внешних прошивок - лучше, чем его отсутствие. В ath9k в "самом по себе" - вообще прошивок нет. Машина состояний оффлоадит, драйвер делает остальное. Там нет процессоров. И соответственно нет мутных блобов создающих проблемы. > У ath9k_htc раньше прошивка проприетарной была, только потом её открыли. А какая разница? Мы рассматриваем то что есть здесь и сейчас. По факту. Если вдруг для ath10k прошивку откроют - коменты будут иные. Но это имхо маловероятно, потому что атероса скушал квалкомм - и это уже не инженерная культура атероса, а таки, увы, квалкомм. Одна из самых жестких проприетарных корпораций на планете. Если вы не знаете чем они знамениты, сообщаю: они своими CDMA-патентами клинили прогресс в продвинутом использовании эфира и шустрой передаче данных лет наверное десять к ряду. Будучи почти монополистом в CDMA - и оставаясь таковыми вплоть до пришествия 3G довольно много лет. p.s. а механизм загрузки прошивки в флеху обычно всяко есть. Вы ж не думаете что прошивка в флехе самозарождается?! То что его опять же не всегда отдают юзерам в лапы - на то и проприетарщики, и в этом тоже подгадить могут. И вообще они вас туда пускать не собираются, так что секурбутами начинают обвешивать от и до. Единственное что это реально изменит это железо от энтузиастов, имхо.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (6), 30-Авг-23, 03:42
	> А какая разница? Мы рассматриваем то что есть здесь и сейчас. По факту. Если вдруг для ath10k прошивку откроют - коменты будут иные. Я говорю о том, что наличие возможности обновлять прошивку с жёсткого диска, т.е. вместе с ядром - это скорее плюс, т.к. даёт возможность создать открытую прошивку и включить её в ядро. А если таковой механизм не предусмотрен, то это же не всегда означает, что девайсу прошивка не нужна, чаще всего она защита во флеху на девайсе. Но почему то такой подход сообществу фанатиков больше нравится и они дружно выпиливают блобы из ядра. Будто бы использовать устаревшие прошивки (и микрокод процессора) чем то лучше или безопасней. Тем более, что некоторые девайсы (без внешних прошивок вообще не работают. По такой логике, юзеру и жёсткий диск не использовать, т.к. там прошивка проприетарная?! Лучше было бы сесть и написать замену, а коли не можете, то какой смысл винить вендоров? Они не обязаны ничего открывать. > И что они там пропатчили? Эта хрень весом более мега бывает! Они прям от и до проаудитили что этот мег крапа вообще может? И какие там подставы? https://www.candelatech.com/ath10k.php Лучше, чем вообще ничего. Не предусмотрели бы механизм подгрузки прошивки ядром, то и того бы не было.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 30-Авг-23, 15:42
	> Я говорю о том, что наличие возможности обновлять прошивку с жёсткого диска, > т.е. вместе с ядром - это скорее плюс, т.к. даёт возможность ...при случае получить от супер-доверяемого вендора блоботы адаптированные к новой версии системы и окружения бэкдоры, в случае если вдруг изменения в кернеле или чем там старому мешать начнут? :). И еще и лицензионные проблемы дистрибуции этого вареза. В случае самодостаточной железки все это остается между теми кто железки продает и покупает. А вон там вылезает в проблемы дистро и остальных. Оно ж как бы копирайченый материалец, если что-то более-менее официально распостранять - надо чего доброго разрешения на эот спрашивать. > создать открытую прошивку и включить её в ядро. И как, много открытых прошивок для хотя-бы ath10k? А там уже ath12k на минутку. И кроме того в случае если ЭТО не было часть плана (т.е. сорц не дали) - оок, но вы уж не обижайтесь тогда что от вас секурбут влепят если не сразу так в следующей версии чипа. Чтоб не портили компот. Ну вон нвидия как-то так с нувой поступила. То что квалкомм чем-то лучше - не факт, мерзкая фирма. > А если таковой механизм не предусмотрен, то это же не всегда означает, что девайсу > прошивка не нужна, чаще всего она защита во флеху на девайсе. И при этом отпадает гимор с редистрибуцией этой блоботы, а заодно оно не отапдейтит себя под совпадение с рапсоследним кернелом чтоб и его при случае правильно выносить. Может оно и не выносит его но в DMA-capable девайсе с процом верить джентльменам на слово - ну нафиг. А колупать те мег+ кода мазохистов все же мало. > Но почему то такой подход сообществу фанатиков больше нравится Потому что отпадает парочка проблем а железка самодостаточная становится. > и они дружно выпиливают блобы из ядра. Неудобный по лицензированию материалец. Впрочем ядерщиков и самих это все задолбало и они в целоп уже почти выперли весь подобный хлам в linux-firmware. Который как бы отдельная репа, отдельно от ядра. > Будто бы использовать устаревшие прошивки (и микрокод процессора) чем то лучше Ну тут как бы зависит от ченжлога. Он может быть как полезным так и вредным, а блобмейкеры ессно его и тем более комитдиффы не покажут. > или безопасней. Или  НЕбезопаснее. Смотря что вендор имел на уме. Без сорца не видно же. А уж интелу с его ME и шифрованым микрокодом только про безопасность и лечить. > Тем более, что некоторые девайсы (без внешних прошивок вообще не работают. Ну дык. Мир не идеален. Это не значит что к этому и надо стремиться. > По такой логике, юзеру и жёсткий диск не использовать, т.к. там прошивка проприетарная?! ...одна из причин по которой есть инициативы по созданию как минимум открытых SSD. Где контроллер и фирмвара будут таки - свои и заведомо дружественные. А не хз что и почему. > Лучше было бы сесть и написать замену, а коли не можете, то > какой смысл винить вендоров? Они не обязаны ничего открывать. Да, и спеки открывать не обязаны. А вы тут пишите без спеков разгребая кал за всякими некооперативными м...ками. И потом они удивляются за что же их не любят. Наверное за то что некооперативные проприетарные м...ки? Да и кодить для чужого девайса забеспатно чтоб работало - довольно спорное занятие. Я то как раз лучше для своих проциков фирмвару покожу. Некоторые таки и под открытыми лицензиями бывают, а уж для себя то я точно все сорцы открою. > https://www.candelatech.com/ath10k.php > Лучше, чем вообще ничего. Не предусмотрели бы механизм подгрузки прошивки ядром, то > и того бы не было. В случае ath9k к нему т.к. это хардварный автомат - приделали вообще все что можно и нельзя. Начиная от полного режима монитора с инжекцией любых пакетов как попало (сие дало старт ряду весьма кастомных протоколов "на основе вафли", скажем для передачи видео с graceful degradation почти как с аналоговых камер, но в цифре, с шифрованием и FEC) - и до какого-нибудь режима OCB, про который вы вообще может и не слышали. На момент разработки и выпуска этих чипов OCB даже в проекте еще по-моему не было. А на 2.4 ГГц его даже и в том проекте на момент создания проекта - нету вроде, черт знает, может в более поздней субревизии и сделали. Но поскольку чипсет позволяет - взяли и прикрутили вот. Прям на 2.4 ГГц, прям OCB, даже работает, пакетному автомату оффлоада так то похрен что там за пакеты, модуляция ж вайфайная а остальное ему ортогонально :)
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Full Master (?), 29-Авг-23, 09:08
	>А у кого сейчас вайфай в системном блоке? У меня, например. В Strix B550-I "из коробки" воткнута M.2 WiFi карточка.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	67. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (67), 28-Авг-23, 15:23
	А че, пускай переписывает ядро на Ржавом, ну десятилетия полтора у него уйдёт минимум.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	106. "Релиз ядра Linux 6.5"	+/–
	Сообщение от fyjybvec (?), 28-Авг-23, 17:03
	так это хорошо! 1. станет меньше ошибок связанных с памятью 2. куча новых прогрессивных программеров получит работу в составе корпораций, которые и пишут ядро 3. диды, которые до сих пор не могут научиться не выходить за пределы массива, отправятся на заслуженную пенсию
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (124), 28-Авг-23, 18:05
	как ты быстро на пенсию намылился, заработать только забыл
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Релиз ядра Linux 6.5"	+6 +/–
	Сообщение от Аноним (11), 28-Авг-23, 12:31
	Американского майора радует, что развивают действительно безопасТный язык, впопулярный для молодого смузипоколения, что позволит больше привлечь говнокодеров для написания ядра.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	40. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (35), 28-Авг-23, 13:47
	Сишка достаточно хорошо привлекает смузипоколение. Особенно тем, что не стесняет полёт творческой личности при работе с памятью. Раст - для унылых серьёзных дядек, которым надо не самовыражаться, записывая за границы буфера, а просто чтобы работало и не падало.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (98), 28-Авг-23, 14:42
	Поглядим, как сурьёзные дяденьки будут сами выражаться, пользуясь тем безопастным язычком.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Релиз ядра Linux 6.5"	+/–
	Сообщение от fyjybvec (?), 28-Авг-23, 16:38
	ты про тех дидов, которые дарят нам возможность читать каждые пару недель про уязвимости в ядре? ну эти точно ругаться будут
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Серб (ok), 31-Авг-23, 17:27
	> ну эти точно ругаться будут А есть другие?
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 28-Авг-23, 22:35
	> Раст - для унылых серьёзных дядек, которым надо не самовыражаться, записывая за > границы буфера, а просто чтобы работало и не падало. Ну ты не путай менеджеров и акционеров с ламонубами с горящими глазами, бурно радующимися что завтра их как раз вон те лихо заменят на раджу который еще вчера индийские сортиры чистил а теперь - вместо вас за копье ядро кодит. БезопасТно же - значит по мнению вон тех, дров не наломает даже такой, можно брать! А их там длиииинная очередь. По сравнению с чисткой деревенского сортира со змеями в уютном офисе то с кондеем эвона какой апгрейд! На практике конечно все чуть сложнее, но об этом вон те начинают догадываться когда проект уже ушатан в г@внину и уже немного поздняк, там только Геракла позвать для расчистки авгиевых конюшен... (после чего цикл жабы и ушатывания у корпов повторится, а вовсе не то что вы подумали).
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	182. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (157), 29-Авг-23, 01:12
	>Раст - для унылых серьёзных дядек Когда ПО для атомных станций, авиации, космоса, банков и бирж будут писать на Rust, тогда можно говорить говорить о Rust в хорошем ключе, а пока это поделка такая же как и D.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	207. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (207), 29-Авг-23, 08:02
	>ПО для атомных станций,… а может лучше не надо? T_T
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 30-Авг-23, 01:10
	>>ПО для атомных станций,… > а может лучше не надо? T_T Предпочитаешь вручную стержни реактору двигать и мониторить состояние систем мясными мешками? Мясной мешок обделается в таких вещах гораздо быстрее чем софт. У мяса другие времена реакции, и вообще, оно могло не выспаться, задолбаться и ему все похрен. В этом смысле компы и микроконтроллеры всякие которые в случае чего сами все вырубят куда как надежнее.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Анонимусс (?), 28-Авг-23, 16:34
	Пока что раст ядре не используется, а вот говнокодеров для написания ядра - целая орава.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	133. "Релиз ядра Linux 6.5"	+/–
	Сообщение от _ (??), 28-Авг-23, 18:35
	и эта орава ждёт когда ржвачик таки будет в ведре использоваться :) Удачи!
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (6), 28-Авг-23, 19:18
	Проблемой стало найти говнокодеров, который на сях будет за миску риса писать, а на расте таких навалом среди зумеров. Все же знают, что чем больше студентов будет пилить ядро, тем оно безопаснее, и тем лучше для майора.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	29. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon888 (?), 28-Авг-23, 13:09
	Слишком толсто.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	32. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от BeLord (ok), 28-Авг-23, 13:24
	Вначале новую версию Ады выпусти, потом и блобы будут, а то все на халяву получить хочет-)))
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	42. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (42), 28-Авг-23, 13:50
	Я боюсь что итогом будет 2 яп в ядре и раст, скорей всего, отвалится в какой-то момент но драйвера останутся в легаси и придется их тянуть хз сколько. По поводу безопасности раста: статический анализ в С чинит все проблемы что и раст, не исключено появление разширения для С в виде стандарта что добавит "умную" работу с памятью, переход на полдмножество с++ может решить эту проблему, например. И все раст можно хоронить, но драйвера никуда не денутся... итог печален будут тянуть легаси лет 20.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	95. "Релиз ядра Linux 6.5"	+/–
	Сообщение от keydon (ok), 28-Авг-23, 16:40
	Так и будет. Я об этом говорю уже ~ лет 10 и без привязки к ядру. Раст умрет, а кому-то придется собирать кучу ненужного софта. К счастью в основном на расте писали мелкие бесполезные утилитки и в энтерпрайз он только начинал заходить, так что есть шанс что обойдется малой кровью.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от _ (??), 28-Авг-23, 18:45
	Забудь надежду ... (С) Нашинские, Ынрерпрайзные - _всегда_ выбирают наихудшее решение :)
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от fyjybvec (?), 28-Авг-23, 17:07
	> статический анализ в С чинит все проблемы что и раст если бы так было - то ядро бы обмазали всеми видами статики какими можна и исправили бы все баги с памятью но этого почему-то не произошло
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	135. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (135), 28-Авг-23, 18:44
	Это не говоря уж о OpenSSL с его бесконечными дырами - а ведь он уже обмазан статическими анализаторами, да и размером несоизмеримо меньше ядра. Как обычно, у опеннетных критиков Раста уровень знаний о нем "слышал звон, да не знаю, где он".
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от _ (??), 28-Авг-23, 18:50
	Но есть нюанс ... (С) OpenSSL - есть и используется, а вот замену ему на ржавчике раз 300 анонсировали, уеб сайты(С) делали ... (для поха - там даже СоС был!!! :-р ) ... но все как сидели насишныхдыренях(С) так почему-то и сидят ... Не понимают дураки своего счастья ...
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (126), 28-Авг-23, 18:08
	То есть ты вбрасываешь мысль от том, что "Раст не нужен, просто сишку надо сделать подмножеством С++". Я как сишник скажу - Плюсам в ядре места нет!
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	191. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 29-Авг-23, 04:01
	> То есть ты вбрасываешь мысль от том, что "Раст не нужен, просто > сишку надо сделать подмножеством С++". Я как сишник скажу - Плюсам в ядре места нет! Однако какой-нить _Generic в С11 таки сделали. Это не совсем то что в плюсах но все же.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (187), 29-Авг-23, 04:00
	> По поводу безопасности раста: статический анализ в С чинит все проблемы что > и раст, не исключено появление разширения для С в виде стандарта У сей есть определенная проблема с статическим анализом указателей. Особенно void* какого-нибудь. Там прсото нет аннотации намерений кодера. Мы не знаем что хотел кодер, какой у этого был размер и валидна ли вон та операция. Ни компил тайм ни даже ран тайм вот так нахаляву. Конечно если вообще совсем все трекать, как asan - ну да, только из сишки получается дотнет какой-то: жрет гигазы рамы на трек этого, бинарь жирнеет в разы и скорость сливается.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	277. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от keydon (ok), 30-Авг-23, 14:13
	>> По поводу безопасности раста: статический анализ в С чинит все проблемы что >> и раст, не исключено появление разширения для С в виде стандарта > У сей есть определенная проблема с статическим анализом указателей. Особенно void* какого-нибудь. > Там прсото нет аннотации намерений кодера. Мы не знаем что хотел > кодер, какой у этого был размер и валидна ли вон та > операция. Ни компил тайм ни даже ран тайм вот так нахаляву. > Конечно если вообще совсем все трекать, как asan - ну да, > только из сишки получается дотнет какой-то: жрет гигазы рамы на трек > этого, бинарь жирнеет в разы и скорость сливается. Ну в таких случаях и раст включает unsafe. Только вот почему-то вынести небезопасный код в unsafe растоманы считают нормой, а вынести работу с указателями в либу/функцию это "дырявый си", а в плюсах и вовсе давно все вынесено и с указателями стараются не работать. Почему-то криворукое поделие на си это "дырявый си", а криворукое поделие на расте "это разработчик виноват, сейчас поправим и дальше все будет безопасно"...до следующего найденного бага. Лицемерие чистой воды.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 30-Авг-23, 15:55
	> Ну в таких случаях и раст включает unsafe. В сях это все ж почаще - указатели юзают часто, и весьма часто они "безразмерные" и даже чисто теоретичеси в компилтайме это просчитать получается нельзя. Только в рантайме чекать тяжеловесами типа asan+ubsan, а это уже дотнет какой-то из сишки получается. Бинарь жиреет в разы особенно с asan, скорость тоже в пару раз может слететь, и рам asan жрет очень даже. Ubsan скромнее но ловит не все. > Только вот почему-то вынести небезопасный код в unsafe растоманы считают нормой, а > вынести работу с указателями в либу/функцию это "дырявый си", Ну как бы положа руку на сердце, диды кодили как полные раздолбаи - и за ними их чудные апи и код писаный безбашенно приходится разруливать. Они ж вообще тогда не думали что кто-то коду пришлет пакет, чего доброго по воздуху, без спроса и - явно кривой?! > а в плюсах и вовсе давно все вынесено и с указателями стараются не работать. Да даже на сях культурным определением типов это решить можно. Тут кто-то ссыль давал кажись как из сей + гнутого расширения для мутексов сделали GUARD который так то жутко далек от стандартного управления ресурсами в си. Но можно решить это одно. А то что там в древнем коде это сделано - сильно другое. Ну и вот чтобы понимать где нас reboot в этих знаниях древних - и появились asan'ы и ubsan-ы с fuzzer'ами. Которые так то недурно ловят факапы дидов оптом методом миллиона обезьян^W вообще процессоров генерящих рандом по сути. > Почему-то криворукое поделие на си это "дырявый си", а криворукое поделие на > расте "это разработчик виноват, сейчас поправим и дальше все будет безопасно"...до > следующего найденного бага. > Лицемерие чистой воды. Ну вот тут я не спорю, у хрустиков на вулны сразу отмазки забавные начинаются. Еще забавнее что на нем толком накодить то ничего не успели а список на несколько сот CVE уже - отрос.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от keydon (ok), 31-Авг-23, 15:24
	> В сях это все ж почаще - указатели юзают часто, и весьма > часто они "безразмерные" и даже чисто теоретичеси в компилтайме это просчитать > получается нельзя. Только в рантайме чекать тяжеловесами типа asan+ubsan, а это > уже дотнет какой-то из сишки получается. Бинарь жиреет в разы особенно > с asan, скорость тоже в пару раз может слететь, и рам > asan жрет очень даже. Ubsan скромнее но ловит не все. Прям как в анекдоте https://www.anekdot.ru/id/75546/ > Ну как бы положа руку на сердце, диды кодили как полные раздолбаи > - и за ними их чудные апи и код писаный безбашенно > приходится разруливать. Они ж вообще тогда не думали что кто-то коду > пришлет пакет, чего доброго по воздуху, без спроса и - явно > кривой?! > Но можно решить это одно. А то что там в древнем коде > это сделано - сильно другое. Ну и вот чтобы понимать где > нас reboot в этих знаниях древних - и появились asan'ы и > ubsan-ы с fuzzer'ами. Которые так то недурно ловят факапы дидов оптом > методом миллиона обезьян^W вообще процессоров генерящих рандом по сути. Деды уже как 20+ лет не при делах, уже 20+ лет есть сети и все про это в курсе и даже с менеджерских позиций их давно поперли, но все равно продолжают валить на дедов. Но что-то в расте уязвимостей меньше не стало, а вот фейспалмов стало больше.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 03-Сен-23, 16:04
	> Прям как в анекдоте https://www.anekdot.ru/id/75546/ Не, нам так не катит. Я хочу знать о своем и чужом коде истинное состояние дел а не пребывать в блаженном неведении под красивые сказки. Видите ли, я управляющими системами развлекаюсь. Микроконтроллеры, одноплатники, вот это все. И меня при этом интересует знать именно истинное состояние дел. И чтобы код был как можно качественнее. Если ему что-то ответственное доверить собираемся - это как-то так. Сейчас компьютеры и мк управляют АЭС, химпредприятиями, энергетикой, производствами, транспортом всех мастей и направлений. Наша цивилизация изменилась. И требования к коду стали в ряде аспектов здорово другие. И просто для понимания, по состоянию на сейчас в линух домерживают последние оставшиеся патчи проекта RT_LINUX. Которые, как вы понимаете, совсем не для красоты. Да что там, отсутствие багов в ядре актуально даже на обычном десктопе, потому что порушенная В ЯДРЕ рама может накрыть структуры файлухи, с чудной кончиной ОС или потерей данных, или уронить систему в панику. В этом месте дидам надлежит познать тао antibug coding - или уйти. Как исправивший ряд вулнов в их чудном коде говорю. > Деды уже как 20+ лет не при делах, уже 20+ лет есть сети и все про это в > курсе и даже с менеджерских позиций их давно поперли, но все равно > продолжают валить на дедов. Чей код фэйлит - к тому и претензии. Все просто. Я за олдовым и весьма кондовым кодером вот прям ща например алго запатчил - могло отрицательные индексы массиву скормить при определенных входных данных. Круто, да? Люблю дидов, int в индексах, пофигизм на проверки входных параметров функции и валидацию математики, неструктурированные апи и void* в каддой дырке, так что ни я ни компилер даже в проекте не разберемся что реально хотел засабмитить кодер - за отсутствием аннотаций намерений. Это именно их стиль писать вот так :). К сожалению натурный эксперимент показал что стиль богов не годится для смертных - они на богов не тянут и сажают тупейшие баги. Ну, вот, индексы отрицательные. Куда оно там по памяти скатается при этом только ubsan и знает :) > Но что-то в расте уязвимостей меньше не стало, а вот фейспалмов > стало больше. Ну мне не нравятся эти типы - но иногда они таки имеют пойнт. В том числе с UB, жестко оговоренным размером типов без разночтений вместо "int" е...чего. А еще у си вообще довольно много странной фигни в стандартах. Скажем integer promotion. Или формат представления знаковых - разные варианты при этом и результирующий UB при врапе. Это уж совсем незачет.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от keydon (ok), 04-Сен-23, 13:11
	> Не, нам так не катит. Я хочу знать о своем и чужом коде истинное состояние дел а не пребывать в блаженном неведении под красивые сказки. Поэтому используете раст, где сплошные сказки про безопасность, а реальные механизмы сводятся к профанации? > И чтобы код был как можно качественнее. О да, поэтому надо использовать раст, который разрабатывало 1,5 специалиста и орава студентов во время учебы. > Сейчас компьютеры и мк управляют АЭС, химпредприятиями, энергетикой, производствами, транспортом всех мастей и направлений. Наша цивилизация изменилась. И требования к коду стали в ряде аспектов здорово другие. Если вы собираетесь доверить управление АЭС коду на си или тем более на расте без дополнительных органичений, то боюсь наша цивилизация скоро еще больше изменится. > И просто для понимания, по состоянию на сейчас в линух домерживают последние оставшиеся патчи проекта RT_LINUX. Которые, как вы понимаете, совсем не для красоты. Как раз для красоты. Раст вызвал бурю негодования, а Линус как обычно решает проблему методом выживания - кто выживет, того и оставят. Он всегда так делал и с более худшими решениями и это весьма неплохая стратегия. > Да что там, отсутствие багов в ядре актуально даже на обычном десктопе, потому что порушенная В ЯДРЕ рама может накрыть структуры файлухи, с чудной кончиной ОС или потерей данных, или уронить систему в панику. Только хруст не избавляет от багов, а только добавляет их. > В этом месте дидам надлежит познать тао antibug coding - или уйти. Так дедов нет уже. Не пишут они уже код. Деды это вы. Для начала antibug coding должен быть читаемым, а не быть изотерическим ЯП с магическими символами из...начала двухтысячных. О да, раст создан дедом на основе языков дедов и изначально вообще был наколеночным проектом для полтора пользователей, это потом в мозилле в спешке начали править синтаксис. Результат на лицо. А вы тут про антибаг кодинг... > Как исправивший ряд вулнов в их чудном коде говорю. Осталось дождаться пока ваше чудное исправление кто-то посмотрит и найдет в нем баг. > Люблю дидов, int в индексах, пофигизм на проверки входных параметров функции и валидацию математики, неструктурированные апи и void* в каддой дырке, так что ни я ни компилер даже в проекте не разберемся что реально хотел засабмитить кодер - за отсутствием аннотаций намерений. И все это человеческие проблемы, которые раст может решить примерно никак. > В том числе с UB, жестко оговоренным размером типов без разночтений вместо "int" е...чего. А еще у си вообще довольно много странной фигни в стандартах. Скажем integer promotion. Или формат представления знаковых - разные варианты при этом и результирующий UB при врапе. Это уж совсем незачет. Только вот UB это по сути unsafe для разработчиков компиляторов. Но unsafe в расте это "модно и необходимо", а UB в си это "деды понаписали".
	Ответить | Правка | Наверх | Cообщить модератору

	341. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (341), 05-Сен-23, 17:09
	> Поэтому используете раст, где сплошные сказки про безопасность, Пока еще нет. Но вообще рассматриваю идею выучить его когда в gcc будет нормальная поддержка и я пойму как обходиться без закладывания на стремные пакеты из реп от гугломайкрософтамазона. > а реальные механизмы сводятся к профанации? А таки у сей есть слабые стороны... 1) Те доперли до данных фиксированой ширины. А не "int" е...чий! В сях этот рак вклинился очень глубоко. Поэтому в макросах, enum и проч возникает много вопросов "какой реально тип данных будет?!" и "безопасна ли такая математика вообще?". Особенно если учесть определение "int" в стандарте. 1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum не распостраняется! По крайней мере в цивильном и контролируемом виде. 2) integer promotion в си работает совсем не так как представляло себе большинство кодеров. Почему это должно быть через такой @нус для меня загадка. А ваш код переживает -Wconversion без единого варнинга? Скажите честно! 3) UB. Извините но в си это за гранью добра и зла, стандартизаторы упростили жизнь себе в ущерб остальным. Даже wrap "int" - ub?! Потому что было минимум 2 формата хранения signed? А сам "int" - что угодно, от 16 битов и далее со всеми остановками? И сколько кода готово все возможные варианты "int" без фаллаута схарчить?! Примрено нисколько?! Круто! А мы точно хотели такие стандарты и такой код? Потому что он разваливается от тыкания палочкой. 4) Переменная типа "enum" в си жрет любой хлам. Даже зачастую без варнинга. Круто, но можно это и получше сделать так то. 5) В сях аннотации массивов весьма декоративные. В функцию можно с кормить func(arr[10]) но реально это - указатель. Без малейшего намека на bounds checking. Продвинутые анализаторы в принципе могут поспорить с этим но по дефолту это так не работает и аннотация смысла не имеет. Можно через struct сделать - но тогда это крайне неэффективно будет. 6) Struct в си кстати отдельная боль. На уровне апей и абей профачено все что можно профачить. Поэтому если вы мечтали о структурированом апи, да еще с предсказуемым аби - забудьте. Хотя затрахавшиеся люди все равно стали нормальные апи с "struct" делать. Потому что неструктурированные апи без аннотации намерений кодера ведут к багам. 6.1) Битовые поля в оных. Это грабледром. Код который генерят компилеры ужасен. А определено это так что можно получить более 9000 грабель. Ряд кода на это кладет и все равно юзает. Потому что все остальные способы еще ужаснее. За это он становится непортабельным и этот арбалет - с термоядерным наконечником стрелы. Эта обугленная косточка - пятка кодера который пытался перенести сие на соседнюю платформу. Не прокатило. 7) Даже самый крутой статический анализатор не знает что вы намеревались дать в void* и было ли это валидно, и не порушит ли это память. Узнать это можно только рантайм чекерами типа asan, делающими из сей долбаный дотнет. А в математике указателей можно прострелить себе пятки более 9000 разных способов. 7.1) Сишники повернуты на сабмите неструктурированного хлама в функции и поэтому аргументы не подлежат какой либо автоматической проверке. Что ведет к морю багов. 7.2) И возврате такого же хлама. С тем же эффектом. В си вообще нельзя вернуть 2 значения по простому. На самом деле, правда, struct это позволяет. Но за это вас проклянут по линии ABI. 8) 1, 1U, 1UL и 1ULL это 4 довольно разные вещи. А 01 вообще - октальное число. Как и +/- 0 в плавучке. И граблями это может #%нуть мама не горюй. 9) Половину stdlib сей стоило бы запретить к использованию. Особенно олдовые функции работы с строками и неудачно сделанную аллокацию памяти где то забывают освободить, то дважды освобождают, то юзают после этого - и ничего хорошего конечно же не выходит. ...за последнюю неделю я зашиб минимум 2 ошибки работы с памятью (unchecked alloc) и чЮдную математику сабмитящую (в который раз!) в массив отрицательный "int" как индекс. > О да, поэтому надо использовать раст, который разрабатывало 1,5 специалиста и орава > студентов во время учебы. Ну он по крайней мере решает ряд осточертевших проблем сей. Создает ли взамен больше проблем чем решает - это мы будем посмотреть. Для начала с безопасной дистанции, а потом как пойдет. > Если вы собираетесь доверить управление АЭС коду на си или тем более > на расте без дополнительных органичений, то боюсь наша цивилизация скоро еще > больше изменится. Конечно же с ограничениями. И длииииинный список рулесов типа MISRA какой намекает что половина этого должна была быть вбита в стандарт, с расчисткой от UB, недоговорок и маразма. Но это не было сделано. Поэтому наш софт норовит нас отыметь. А жесткой логикой или мясом рулить такими вещами получается еще хуже. Эзотерика типа ады деланая академами - для системного програмизма непригодна от слова вообще. Пусть сами ей пользуются, перепрофилировавшись из теоретиков в системных кодеров, если им так угодно. Тогда глядишь их попустит ментальный булшит чутка. >> И просто для понимания, по состоянию на сейчас в линух домерживают последние >> оставшиеся патчи проекта RT_LINUX. Которые, как вы понимаете, совсем не для красоты. > Как раз для красоты. Раст вызвал бурю негодования, а Линус как обычно > решает проблему методом выживания - RT_LINUX к раст не относится - но намекает что линух очень хотят юзать для управляющих систем толпа народа. Я один из таковых. А раст... некоторые кодеры ядра полагают что он им позволит лепить меньше багов и писать более читаемый и майнтенабельный код. И они имеют определенный пойнт. > кто выживет, того и оставят. Он всегда так делал и с более худшими решениями и это весьма > неплохая стратегия. Торвальдс и вся его шайка таки заинтересованы в отсутствии багов и неплохой работе своего кода. Я это вижу. И с сями это приблизилось к своим лимитам. В силу особенности конструкции сей. С11 немного улучшает это но - лишь маргинально. А у кернела есть более 9000 собственных костылей для компил-тайм чеков, воркэраундов сишной идиотеки и много чего еще. Это не значит что нас не задолбало i++'й раз изобретать вел с квадратными колесами. > Только хруст не избавляет от багов, а только добавляет их. Ну, пока он еще не в форме чтобы это делать. А его проблематика применительно к вон тому - еще не понята. Так что я не буду настаивать что он годен для critical систем. Но у него есть предпосылки есть ряд вещей сильно лучше чем си. А в сях эти проблемы кажется никто так и не будет решать. >> В этом месте дидам надлежит познать тао antibug coding - или уйти. > Так дедов нет уже. Не пишут они уже код. Деды это вы. Нет, вон тот код с вон тем качеством - оставили таки мои предшественники. И я имею кое-что против такого уровня качества кода, такого структурирования апи, и проч. Потому что можно намного лучше. Но с сями это тяжко. Вплоть до того что if (i = 10) в сях может прокатить. И даже без варнингов если не повезет. Это ляп сразу на уровне дизайна конструкции ЯП. > Для начала antibug coding должен быть читаемым, а не быть изотерическим ЯП > с магическими символами из...начала двухтысячных. Ну, не сишникам на магические символы жаловаться. Будете вырубаться - достану из загашника прикольные конструкции на си которые таки - формально валидный код. У меня есть. > О да, раст создан дедом на основе языков дедов и изначально вообще был > наколеночным проектом для полтора пользователей, это потом в мозилле в > спешке начали править синтаксис. Результат на лицо. А вы тут про антибаг кодинг... Ну так им пока и 50 лет нету. А определенные задатки антибага в виде более структурированых апец и более вменяемой работы с целыми числами - есть. Они конечно за это других грабель налепили, хипстюки. Ну так пока все только начинается. >> Как исправивший ряд вулнов в их чудном коде говорю. > Осталось дождаться пока ваше чудное исправление кто-то посмотрит и найдет в нем баг. Это будет только подчеркивать фэйловость сей и повод перейти на что-то менее прострельное для пяток. Потому что я хочу видеть качественный софт который не лажает. Я далеко не хучший из кодеров по части паранои и антибага. Если даже я лажаю по глупому, остальные будут это делать еще сильнее и надо править что-то на более фундаментальных уровнях. В тулзах. > И все это человеческие проблемы, которые раст может решить примерно никак. А таки - какой-нибудь borrow checker или нормальные типы целых здорово снижают предпосылки для багов. На сях тоже можно сделать ряд забавных вещей - см что в рассылке сделали с GUARD для мутексов (почти RAII-style из плюсов но на сях). Однако уповает на гнутый экстеншн, в стандарте дефера для cleanup при выходе из видимости нетути. И вот так - в 20 раз меньше вариантов как облажаться с мутексом. А если его наимно попробовать как обычно в си - вот там можно откушать от души. И откушают. > Только вот UB это по сути unsafe для разработчиков компиляторов. Но unsafe > в расте это "модно и необходимо", а UB в си это "деды понаписали". UB это UB. Это не unsafe, это х-вые стандарты. И только. Если что я махровый сишник повернутый на антибаги. Потому что люблю кодить системщину и фирмвари. И я вижу что есть много месте для улучшения - а комитету похрен, он только себе жизнь упрощает и трясется за легаси. И это не круто. Делегировать такое проприетари типа мисры - еще менее круто.
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 00:57
	Долгих вам лет и здоровья. На таких людях оно всё как-то ещё и держится.
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 06-Сен-23, 14:52
	> Долгих вам лет и здоровья.На таких людях оно всё как-то ещё и держится. Ну как бы занимаясь управляющими системами, что васянски, что не васянски, я таки поместил себя в точку где врать и отнекиваться не вариант. Приходится делать так чтобы было реально зашибись, иначе это мне же и выходит боком. Ядерщики находятся в примерно такой же точке т.к. линух и в управляющие систмы уже ставят, и отказ в режиме ядра - весьма фатальная штука по природе своей. Если программа покрешится или вылетит в любимый хрустиками panic() это одно. А если кернел, то это совсем другой опыт уже получается. И совсем другие testimonials о кодерах которые так делают. Ну и рассматривая варианты как сделать свой код лучше - не очень понятно с чего я обязан игнорить появляющиеся технологии. Мои критерии - не должно втравливать меня в корпоративное рабство имени гугла, амазона и майкрософта. Я не доверяю этим компаниям. И закладываться на них это мой хучший ночной кошмар. Они при первом удобном случае кинут кодеров и юзерей, они всегда это делали. ...тем временем, кто-то на этом глобусе запускает космические корабли, делает самолеты, гоняет вертолетики на марсе, управляет опасными процессами, лезет в жесткий реалтайм. И я все никак не могу понять почему бы и мне не присоединиться к этому банкету. Ведь будущее - это вот так. Что бы там ни вещали олды от стимпанка, мы не вернемся в мир с дубовой механикой и мониторингом мясом. И рулить процессами будет софт. От фирмварей в мелочи до SCADA и глобальной аналитики. p.s. Linux достаточно интересная штука поучиться antibug приемам. Но им и самим нехило взять мастеркласс по смежным топикам.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 01:07
	> Эзотерика типа ады деланая академами - для системного програмизма непригодна от слова вообще. Пусть сами ей пользуются, перепрофилировавшись из теоретиков в системных кодеров, если им так угодно. Тогда глядишь их попустит ментальный булшит чутка. Вроде всё не так там плохо. А что на счет хаскеля например? Я недавно пробегался бегло по нему.
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	363. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 06-Сен-23, 14:55
	> Вроде всё не так там плохо. > А что на счет хаскеля например? Я недавно пробегался бегло по нему. Ни то ни другое не маппится в нормальном виде на мой низкоуровневый системный мозг. Если вы хотите делать системщину на этом, и понимаете как оно - окей, делайте. Я придерживаюсь достаточно простой идеи: чем менее навороченны концепции, тем выше шанс что я и другие кодеры поймут что там творится и поймут правильно. Это делает код поддерживаемым, и спасает от целого класса багов "кодер неверно понял что делает этот код". Хаскелисты предпочитают очень крутые абстракции, специфичный стиль - и потом примерно 0 желающих в такой код вштыривать, 0 майнтайнеров, 0 тех кто захочет или сможет его понять. И если автор выдохся, проекту наступает амба. А совместная работа и вовсе не получается почти.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Релиз ядра Linux 6.5"	+/–
	Сообщение от keydon (ok), 06-Сен-23, 16:00
	> Ни то ни другое не маппится в нормальном виде на мой низкоуровневый > системный мозг. Если вы хотите делать системщину на этом, и понимаете > как оно - окей, делайте. Хочу надежно и безопасно, но разбираться не хочу. Окай. > Я придерживаюсь достаточно простой идеи: чем менее навороченны концепции, тем выше шанс > что я и другие кодеры поймут что там творится и поймут > правильно. Это делает код поддерживаемым, и спасает от целого класса багов > "кодер неверно понял что делает этот код". Поэтому буду использовать раст на LLVM и не буду понимать как же он спасет меня от багов и спасет ли? > Хаскелисты предпочитают очень крутые > абстракции, специфичный стиль - и потом примерно 0 желающих в такой > код вштыривать, 0 майнтайнеров, 0 тех кто захочет или сможет его > понять. И если автор выдохся, проекту наступает амба. А совместная работа > и вовсе не получается почти. Растоман не осилил хаскель? Ну как же, тут же максимально как вы любите - сильная типизация с автоматическим выведением типов, охраняющие выражения, чистые функции, гарантии для компилятора, математическая доказуемость...вот где действительно безопасность. Но нет, мы поругаем си за отсутствие гарантий (в стандарте, как там на деле, мы растоманы не проверяем) и будем топить за профанацию безопасности.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 07-Сен-23, 00:33
	> Хочу надежно и безопасно, но разбираться не хочу. Окай. Хочу простой, предсказуемый, читаемый код БЕЗ навороченных концепций и абстракций. Не вызывающий разночтения у разных двуногих и проблемы майнтенанса. И чтобы рантайм, концепции и проч не стояли лишний раз на пути. Вот си - примерно это. Но с дурацкостями. А ады и хаскели это противоположный полюс, и почему надо из крайности в крайность шарахаться я не понимаю. Это контрпродуктивно и выглядит как обычная оверкомпенсация. > Поэтому буду использовать раст на LLVM и не буду понимать как же > он спасет меня от багов и спасет ли? Предпочту GCC. И таки от вон тех сишных проблем - некоторые предпосылки для этого я вижу. А вот эзотерикой заниматься в мои планы не входит. Особенно в системшине. Более того я ни разу не видел на этом кода который бы вызвал желание в него сунуться или интересных мне проектов. > Растоман не осилил хаскель? Ну как же, тут же максимально как вы > любите - сильная типизация с автоматическим выведением типов, охраняющие выражения, чистые > функции, гарантии для компилятора, математическая доказуемость... Раст видите ли уловил некоторые идеи сишников. Как то не усложнять сущности без необходимости, нормальные целочисленные типы, таки - возможность гранд оверрайда где это реально надо - и отсутствие оверхеда за вот это все. Так что называя вещи своими именами он единственный реальный претендент на звании "второго системного ЯП". ...во всяком случае есть потуги писать на этом кернелы, бутлоадеры, фирмвары МК и при этом не выглядит совсем уж ужастиком. Когда вы на ваших хаскелях и адах это все покажете как оно, делом проиллюстрировав чем это лучше - будет разговор. А абстрактные блабла о достоинствах от тех кто судя по всему системщину не практикует - это о чем? Кто из вас хоть раз в жизни программировал DMA автомат? И как, сие очень удобно из вашего хаскеля было? Не, извините, DMA не умеет в лямбды. Он от сих до сих блок данных тасует. Ему интересны размер и адрес. А мне - контроль lifetime, дабы не вышло так что под автоматом пакет убрали уже и там что-то совсем иное. > вот где действительно безопасность. Но нет, мы поругаем си за отсутствие > гарантий (в стандарте, как там на деле, мы растоманы не проверяем) и будем топить > за профанацию безопасности. Я не намерен шарахаться из крайности в крайность. Мне больше импонирует сбалансированный подход к решению проблем и итеративное заруливание known issues. Я считаю что это лучше в целом работает. Это так сложно понять?
	Ответить | Правка | Наверх | Cообщить модератору

	380. "Релиз ядра Linux 6.5"	+/–
	Сообщение от keydon (ok), 08-Сен-23, 16:49
	> Хочу простой, предсказуемый, читаемый код БЕЗ навороченных концепций и абстракций. Не вызывающий > разночтения у разных двуногих и проблемы майнтенанса. И чтобы рантайм, концепции > и проч не стояли лишний раз на пути. В общем-то я тоже этого хочу ближе к ассмеблеру, но увы, ничего похожего нет. > А ады и хаскели это противоположный > полюс, и почему надо из крайности в крайность шарахаться я не > понимаю. Это контрпродуктивно и выглядит как обычная оверкомпенсация. Функциональщина гораздо ближе к процессору чем может показаться и как раз таки избавляет от многих лишних абстракций. > Раст видите ли уловил некоторые идеи сишников. Ага, вижу, самые худшие уловил и усилил, а мимо самых лучших прошел мимо. > Как то не усложнять сущности без необходимости Это в расте то? Не смешите. > возможность гранд оверрайда где > это реально надо Это тот который не усложняет сущности? > Так что называя вещи своими именами он единственный реальный претендент на > звании "второго системного ЯП". Он вообще не претендент. Еще лет 5 с ним повозюкаются, а через 10 никто и не вспомнит. > ...во всяком случае есть потуги писать на этом кернелы, бутлоадеры, фирмвары МК > и при этом не выглядит совсем уж ужастиком. Толку то от этих потугов. Знаю ровно 2 работающих проекта на расте. Один аналог грепа, другой тимвивера. Все остальные проекты либо используются примерно нигде, либо в принципе не работают, либо давно заброшены. > Я не намерен шарахаться из крайности в крайность. Мне больше импонирует сбалансированный > подход к решению проблем и итеративное заруливание known issues. Я считаю > что это лучше в целом работает. Это так сложно понять? Променять си на еще более худший си, да, это тяжело для понимания.
	Ответить | Правка | К родителю #374 | Наверх | Cообщить модератору

	384. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 11-Сен-23, 22:07
	> В общем-то я тоже этого хочу ближе к ассмеблеру, но увы, ничего похожего нет. Zig/hare/C с минимальным ubsan (лезет даже в мелкие МК типа cortex m0/m3). В любом случае - шарахаться в противоположный полюс - такое себе. > Функциональщина гораздо ближе к процессору чем может показаться и как раз таки > избавляет от многих лишних абстракций. К сожалению абстракции провоцирует навороченные, другие кодеры их потом не понимают или понимают неверно. Для совместной разработки - не вариант. По проектам и их состоянию это отлично видно. Почти все - (полу)дохлые проекты, с 1 кодером. Зачем оно такое? > Ага, вижу, самые худшие уловил и усилил, а мимо самых лучших прошел мимо. Да как раз вещи типа нормальных типов, возможности фигачить без стдлиба если так надо, относительно низкоуровневых примитивов и проч, вплоть до указателей - есть. Как и в целом сиобразный синтаксис. Конечно закорюк добавить и стдлиб отращивать жирным - это зря. >> Как то не усложнять сущности без необходимости > Это в расте то? Не смешите. У остальных еще хуже получилось, так что системщину на этом вообще никто и не пытается даже делать. В силу гиморности или фэйловости начинания. Ну может D еще с большим скрипом может потрепыхаться. Там жаба фирмачей погубила. Дожабились. >> возможность гранд оверрайда где это реально надо > Это тот который не усложняет сущности? Это тот случай когда в правилах бывают исключения. Это не означает что так делать хорошо и правильно, и тем более глупо возводить антипаттерны в ранг правил. > Он вообще не претендент. Еще лет 5 с ним повозюкаются, а через > 10 никто и не вспомнит. Мне почему-то кажется что это у вас wishful thinking. > Толку то от этих потугов. Знаю ровно 2 работающих проекта на расте. Ну как, оно как-то ползает. Доказывая _делом_ что в принципе так можно было. А у вон тех теоретически-крутых оно, например, где? Теоретически-крутым бутлоадером на загрузишься, и теоретической DMA транзакцией блок памяти не передашь. > Один аналог грепа, другой тимвивера. Все остальные проекты либо используются примерно > нигде, либо в принципе не работают, либо давно заброшены. Ну как бы да, часть этого добра сделано на волне хайпа. Ну, вон, librdvg. С свежим безопасным CVE из соседней новости, чего уж :). Хотя конечно мерзотная жирнолиба для веьманкового формата. > Променять си на еще более худший си, да, это тяжело для понимания. Чинит часть косяков. Наиболее задолбавших из. Вот и весь секрет. Остальные и так не смогли. Ну не, есть конечно zig/hare и еще парочка наподобие. Но у них своих траблов, главная из которых - у них там перетрясы еще злее.
	Ответить | Правка | К родителю #380 | Наверх | Cообщить модератору

	369. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 20:35
	Не думаю что есть проблема в понимании по крайней мере в связи с новороченностью концепций. Системный софт успешно писали на смаллтаке и на Лиспе пишут прямо сейчас, хотя Лисп конечно очень простой, и для системщины хорошо иметь сильную систему типов. Что даёт Хаскель и Ада. Проблема понимания тут только в бартере между специалистами программирующие и на разных языках. Сильная типизация как раз сильно пониманию помогает.
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	373. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 07-Сен-23, 00:15
	> Не думаю что есть проблема в понимании по крайней мере в связи > с новороченностью концепций. Если яп провоцирует навороченные конструкции и абстракции - имхо жесткий недостаток. Потому что при совместной разработке софта это ведет к суровым обломинго когда кто-то что-то не так понял в чужом коде - и это ведет к багам, непоняткам и фэйлам в проекте. > Системный софт успешно писали на смаллтаке и на Лиспе пишут прямо сейчас, Да его даже на брейнфаке можно писать. Теоретически. Практически - не лучшая идея на свете. > хотя Лисп конечно очень простой, и для системщины хорошо иметь сильную > систему типов. Для системщины хорошо - делать то что попросил программер и не делать мозг. И предсказуемо работать с железом. А не вы#$%ываться с концепциями, абстракциями, всякими лямбда-заподвыподвертами и чем там еще. Там чем проще - тем надежнее и предсказуемее, в общем то. А заодно толпа народа прочекает что делается и правда что задумано. Но для этого они должны въехать в этот код. > Что даёт Хаскель и Ада. Как я уже сказал - можете програмить системщину на этом если хотите. Я этого за вас делать совершенно точно не буду. Как и въезжать в все ваши вы#$%ны с высокими концепциями. Цель системщины не показать что вы первый кодер на деревне а написать понятный, читаемый, предсказуемый код. Без разночтений его другими двуногими. > Проблема понимания тут только в бартере между специалистами программирующие и на разных > языках. По моему проблема тут в том что академики от CS страшно далеки от системного программирования и поэтому порождают какие-то жуткие франкенштейны. Которые круты только для них, а практикующие системщики - с этого блюют радугой, вместе с руководством проектов. > Сильная типизация как раз сильно пониманию помогает. Видите ли - иногда надо и гранд-оверрайд. С вполне легитимными целями. Простой пример: вот тут я могу хотеть рассмотреть пакет как массив - чтобы его отдать DMA автомату по (адрес, размер) - а вот там дербанить его на субкомпоненты, чтобы осмысленно поля кроить. Ну и какой у него при этом тип? В терминах си это "union" если что. И если жесткие типы вообще совсем зарубят эту идею - окей, инструмент встал на моем пути и нагнул решение задачи. И это не круто. А ключевая претензия к сям будет пожалуй "хреново определенный struct в стандарте". В том плане что не, взять и рассмотреть его поля как части struct - не то чтобы совсем нельзя, но за это очень даже может воздаться. А вот когда вы захотите с DMA автоматом, не понимающим ничего кроме (addr, len) поработать - я посмотрю как вы захотите крутые абстракции и жесткие типы. И чесать репу что в DMA автомат впрограмить при этом всем.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от keydon (ok), 06-Сен-23, 15:34
	> Пока еще нет. Но вообще рассматриваю идею выучить его когда в gcc > будет нормальная поддержка и я пойму как обходиться без закладывания на > стремные пакеты из реп от гугломайкрософтамазона. Никак, раст это гугломайкрософтамазон, избавление от их влияния уже проходили например в андройде, ничем хорошим это не закончилось. > А таки у сей есть слабые стороны... У всего есть слабые стороны. > 1) Те доперли до данных фиксированой ширины. А не "int" е...чий! В > сях этот рак вклинился очень глубоко. Поэтому в макросах, enum и > проч возникает много вопросов "какой реально тип данных будет?!" и "безопасна > ли такая математика вообще?". Особенно если учесть определение "int" в стандарте. Потому что типов нет. Есть байтики, а ты сам можешь их интерпретировать. И раст и вообще всё именно так и работают. Где-то с большим контролем, где-то с меньшим. Нет у процессора знания что же туда положил программист на ДРУГОМ КОМПЬЮТЕРЕ НА ДРУГОЙ АРХИТЕКТУРЕ С НЕИЗВЕСТНЫМИ ВВОДНЫМИ. А в пределах одной программы и у сей никаких проблем нет. Компилятор знает на сколько байтиков у него int, а всякие извращенные типы инта используются крайне редко на редкоиспользуемых архитектурах (а не только x64 и arm как на расте). Более того именно из-за этого комитет по плюсам так долго мурыжил C++11 в котором ABI наконец решили поменять. И у раста будут точно такие же проблемы (если уже не случились). Но смузипогромистов не знакомых с ассемблером это конечно вряд ли волнует, для них программа это не инструкции, а типы и классы головного мозга. > 1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum > не распостраняется! По крайней мере в цивильном и контролируемом виде. Не понял. > 2) integer promotion в си работает совсем не так как представляло себе > большинство кодеров. Почему это должно быть через такой @нус для меня > загадка. А ваш код переживает -Wconversion без единого варнинга? Скажите честно! Вот как раз integer promotion достаточно подробно описан в стандарте. Большинство кодеров (подходящее слово) очевидно не читали его и не собирались, но ВНЕЗАПНО он работает не так как они ОЖИДАЛИ. Ну знаете ли, многое работает не так как я ожидаю.   > 3) UB. Извините но в си это за гранью добра и зла, > стандартизаторы упростили жизнь себе в ущерб остальным. Даже wrap "int" - > ub?! Потому что было минимум 2 формата хранения signed? А сам > "int" - что угодно, от 16 битов и далее со всеми > остановками? И сколько кода готово все возможные варианты "int" без фаллаута > схарчить?! Примрено нисколько?! Круто! А мы точно хотели такие стандарты и > такой код? Потому что он разваливается от тыкания палочкой. Уже обсуждалось. Специфичные условия чтобы развязать руки разработчикам компилятора. В реальной жизни в рамках одной программы проблемы не встречается, компилятор знает что у него UB и как на него реагировать, еще и расскажет об этом. А то что байтики на разных компьютерах могут перекладываться по-разному, так это ВНЕЗАПНО всегда будет, хотя бы из-за разных архитектур (собственно поэтому и добавили UB). Мне и самому не нравится концепция UB, я считаю ее неудачной (да и авторы тоже). Но сишники уже на нее наступили, а раст...ее повторил! При этом UB в си это плохо-плохо-как-так-можно, а unsafe в расте который ТОЖЕ САМОЕ это почему-то благо. Лицемерие, сэр. > 4) Переменная типа "enum" в си жрет любой хлам. Даже зачастую без > варнинга. Круто, но можно это и получше сделать так то. Уже описывал. Ну используй другой класс, который при инициализации будет проверять контрольные суммы и поля и выдавать исключения если байтики не похожи на класс, вот только заплатишь за это производительностью. И в сях и в расте и в любом другом языке, потому что так работает процессор и ничего ты с этим не сделаешь. Ну а в рамках одной программы ты внезапно можешь этого не делать. > 5) В сях аннотации массивов весьма декоративные. В функцию можно с кормить > func(arr[10]) но реально это - указатель. Без малейшего намека на bounds > checking. Продвинутые анализаторы в принципе могут поспорить с этим но по > дефолту это так не работает и аннотация смысла не имеет. Можно > через struct сделать - но тогда это крайне неэффективно будет. Как и в любом другом языке. И в расте тоже (кто-то из растоманов даже ПРЕДЛАГАЛ ОТКЛЮЧАТЬ ПРОВЕРКУ ВЫХОДА ЗА ПРЕДЕЛЫ МАССИВА ДЛЯ УСКОРЕНИЯ ПРОГРАМММ НА РАСТЕ, ну просто верх лицемерия). Внезапно и в сях ты можешь использовать типы с bounds checking и подозреваю при грамотно написанном коде производительность будет выше чем в расте. > 6) Struct в си кстати отдельная боль. На уровне апей и абей > профачено все что можно профачить. Поэтому если вы мечтали о структурированом > апи, да еще с предсказуемым аби - забудьте. Хотя затрахавшиеся люди > все равно стали нормальные апи с "struct" делать. Потому что неструктурированные > апи без аннотации намерений кодера ведут к багам. Такие абстрактные вещи сказать про любой проект/ЯП и т.д.. Про то что у N отстойное апи я слышу всю жизнь. У N меняются названия, языки, разработчики, платформы, годы разработки, но смысл всегда один "неструктурированный, неудобный, непонятный апи", даже сейчас во времена протобафа. Очевидно это больше психологическая проблема, чем технологическая. > 6.1) Битовые поля в оных. Это грабледром. Код который генерят компилеры ужасен. > А определено это так что можно получить более 9000 грабель. Ряд > кода на это кладет и все равно юзает. Потому что все > остальные способы еще ужаснее. За это он становится непортабельным и этот > арбалет - с термоядерным наконечником стрелы. Эта обугленная косточка - пятка > кодера который пытался перенести сие на соседнюю платформу. Не прокатило. Вот тут согласен, все популярные компиляторы  это !@#$%^, особенно gcc. Ну а раст еще больше этого !@#$%^ добавляет и внезапно работает на... сишном llvm. Ну т.е. да, разобраться что и почему генерит компилятор это проблема, а раст ВСЕ ЕЩЕ УСЛОЖНЯЕТ. > 7) Даже самый крутой статический анализатор не знает что вы намеревались дать > в void* и было ли это валидно, и не порушит ли > это память. Узнать это можно только рантайм чекерами типа asan, делающими > из сей долбаный дотнет. А в математике указателей можно прострелить себе > пятки более 9000 разных способов. Уже писал. Не используй указатели где не нужны. Почему-то unsafe для тебя норм, а не использовать указатели по каждому чиху (что тоже своего рода unsafe) тебя не устраивает. > 7.1) Сишники повернуты на сабмите неструктурированного хлама в функции и поэтому аргументы > не подлежат какой либо автоматической проверке. Что ведет к морю багов. Частично согласен. Только вот раст вместо того чтобы избавиться от этого где можно (понятно что от байтиков и каста непонятно чего в ожидаемое не избавишься), например от макросов...еще все ухудшил и создал для макросов отдельный язык. Растоманы, вы больные. И лицемерные. > 7.2) И возврате такого же хлама. С тем же эффектом. В си > вообще нельзя вернуть 2 значения по простому. На самом деле, правда, > struct это позволяет. Но за это вас проклянут по линии ABI. В си другой механизм. Мне тоже приятнее отправлять пачку в return, но в итоге это вопрос привычки и вкуса. > 8) 1, 1U, 1UL и 1ULL это 4 довольно разные вещи. А > 01 вообще - октальное число. Как и +/- 0 в плавучке. > И граблями это может #%нуть мама не горюй. Так ты же можешь выбрать что-то одно и использовать. А остальное не использовать. Ну и в расте не то чтобы сильно лучше, например 0b1111_0000. А еще в расте есть юникод, который нехило так добавляет интересных применений в коде. > 9) Половину stdlib сей стоило бы запретить к использованию. Особенно олдовые функции > работы с строками и неудачно сделанную аллокацию памяти где то забывают > освободить, то дважды освобождают, то юзают после этого - и ничего > хорошего конечно же не выходит. О, первый нормальный наброс и то случайный. В си и правда есть проблемы со строками. Их много. Конечно они не просто так появились и у каждого типа строки свое назначение, но кастить их между друг другом та еще головная боль. Ну а про аллокацию - используй умные указатели. > ...за последнюю неделю я зашиб минимум 2 ошибки работы с памятью (unchecked > alloc) и чЮдную математику сабмитящую (в который раз!) в массив отрицательный > "int" как индекс. А я видел 2 аварии, переводим всех водителей машин на самокаты? Примерно такая же логика у растоманов. "А машинам можно будет ездить только по unsafe дорогам" !@#$%, кэп, итак все нормальные люди так уже и делают. > Ну он по крайней мере решает ряд осточертевших проблем сей. Пока ни одну не услышал. > Создает ли > взамен больше проблем чем решает - это мы будем посмотреть. Для > начала с безопасной дистанции, а потом как пойдет. Уже видно. > Конечно же с ограничениями. И длииииинный список рулесов типа MISRA какой намекает > что половина этого должна была быть вбита в стандарт, с расчисткой > от UB, недоговорок и маразма. Но это не было сделано. Поэтому > наш софт норовит нас отыметь. Если вы пишете софт для АЭС на сях, то у меня плохие новости. И на расте у вас будут точно такие же проблемы. > А жесткой логикой или мясом рулить > такими вещами получается еще хуже. Эзотерика типа ады деланая академами - > для системного програмизма непригодна от слова вообще. Пусть сами ей пользуются, > перепрофилировавшись из теоретиков в системных кодеров, если им так угодно. Тогда > глядишь их попустит ментальный булшит чутка. Не подскажешь где ваш софт используется, может я успею переехать? > RT_LINUX к раст не относится - но намекает что линух очень хотят > юзать для управляющих систем толпа народа. Так он не для управляющих систем. Он для "типа управляющих систем". Т.е. какому-то музыканту ЦАП наверное заменит, а вот для чего-то серьезного надо использовать специализированные RTOS. Т.е. RT в линуксе это "мы попробуем подтюнить линукс чтобы снизить задержки, но ничего не гарантируем". Где-то применимо, но далеко не там где нужны реальные RTOS. > А раст... некоторые кодеры ядра полагают что он им позволит лепить меньше > багов и писать более читаемый и майнтенабельный код. И они имеют > определенный пойнт. Некоторые компании хотели бы больше контроллировать ядро и раст это очередная попытка, долгоиграющий стартап. Ну а насчет читаемого кода - раст явно не читаемый (си, кстати тоже). И явно не поддерживаемый (тут уже даже растоманы успели поматерить раст). > И с сями это приблизилось > к своим лимитам. В силу особенности конструкции сей. С11 немного улучшает > это но - лишь маргинально. Вот только лучше пока не придумали. > А у кернела есть более 9000 > собственных костылей для компил-тайм чеков, воркэраундов сишной идиотеки и много чего > еще. Это не значит что нас не задолбало i++'й раз изобретать > вел с квадратными колесами. Поэтому при внедрении раста в линукс переизобретают растоманские примитивы? Опять лицемерите. > Но > у него есть предпосылки есть ряд вещей сильно лучше чем си. Пока ни одну не услышал, зато есть куча проблем, от которых походу никто не собирается избавляться к расте. Раст это не современный язык, это домашний проект из двухтысячных который по-быстрому попытались привести к чему-то похожему на поделия конца двухтысячных, но который подхватили маркетологи и довольно успешно зафорсили. Примерно то же самое было с php, ничем хорошим это не закончилось. Но php хотя бы был хорош как темплейтер в свое время, а раст просто предлагает все переписать на раст не предлагая ничего взамен кроме как переставлять кровати (unsafe, встроенный в компилятор линтер, встроенные проверки в стандартные типы, да этот список даже смешно звучит, раньше бы я подумал что это юмористический язык). Раст это не будущее, не решение проблем си (которые конечно есть, но в основном не те которые вы назвали). > Нет, вон тот код с вон тем качеством - оставили таки мои > предшественники. Ваши предшественники это не деды. Это вы. Деды это Столлман, Ритчи, можно наверное Линукса туда запихнуть. А 35летний мужик который уволился перед вами это ваш современник и вероятно он и дальше пишет код в другой шаражке. > Это ляп сразу на уровне дизайна конструкции ЯП. А ляпы в конструкциях раста вас не смущает? Или итераторы вместо индексов (которые тоже есть в расте) существенно меняют дело? > Ну, не сишникам на магические символы жаловаться. Будете вырубаться - достану из > загашника прикольные конструкции на си которые таки - формально валидный код. > У меня есть. Ну меня в си магические символы не устраивают. Но конкретно в языке их не очень много и язык все же наследник, а зачем городить в новом языке такие символы не понятно. Но если вспомнить что раст это домашний проект из начала двухтысячных, да и вероятно человека с узким кругозором (иначе он бы уже знал про питон например), то все встает на свои места. Ну тогда и си можно простить его устаревший синтаксис. > Это будет только подчеркивать фэйловость сей и повод перейти на что-то менее > прострельное для пяток. Потому что я хочу видеть качественный софт который > не лажает. Похвальное качество но раст в этом не помогает. > UB это UB. Это не unsafe, это х-вые стандарты. И только. Если > что я махровый сишник повернутый на антибаги. Который не знает что Linux RT это не RTOS и вероятно не знает альтернатив? Который не знает как пишут софт с особыми требованиями к надежности? Который знает проблемы указателей и стандартных типов, но не знает современных альтернатив и не использует их? Который ругает си за проблемы, которых фактически нет у практикующих разработчиков, но про которые пишут новички столкнувшись с проблемами потому что учились по учебникам 1980ых переведенных в РФ в 2000ых? Вы либо студент, либо начинающий разработчик какой-то шаражки, либо пришли из какого-нибудь особо высокоуровнего языка вроде джавы и не особо развивались. Практически все что вы назвали сводится к теоритическим проблемам. Их часто ругают, но по факту они не столь влияют на работу. UB ну есть такое, есть предпоссылки почему они попыли в стандарт, стандарт не описывает как с ними работать, потому что не должен, реализации довольно успешно их обрабатывают. Да, можно встретить на конференции как какой-нибудь проженный сишник ругается на UB в стандарте в какой-нибудь специфичной ситуации из которой он вполне успешно на практике выходит. Встроенные типы си из коробки были рассчитаны на производительность и простоту, а не на разработку надежного кода, а сейчас просто являются наследием. Для этого есть отдельные либы, есть отдельные гайдлайны по современному безопасному кодингу, потому что применений множество и разработчики стандарта си не ограничивают применение. Вот например регэкспы - кому-то нужны быстрые проверяемые, кому-то нужны быстро компилируемые, кому-то с определенным функционалом, а кому-то с наименьшим количеством потребляемых ресурсов, кому-то под опеределнную архитектуру, а кому-то под определенные данные. Что должен сделать разработчик ЯП? 1) Ограничить оптимизации компилятора (явно прописать какие типы и как должны использоваться и сколько байтов в них должно быть и все равно не достигнуть бинарной совместимости на разных платформах), зато без UB 2) Ограничить сферу применения (по сути написать фреймворк по конкретную задачу, как сделали в php, тогда ЯП не будет способен использоваться в других сферах) 3) Описать все варианты (нереально, по сути сводится к п.2 только с переусложеннным ЯП, в некотором роде плюсы частично следовали этой логике и раст ее частично применяет, тот же safe/unsafe это попытка совместить две области). 4) Описать только то что явно понятно (и получить UB, а реализацию оставить на откуп компиляторам) Теперь уберем первый пункт потому что непонятно какая архитектура будет через 5-10 лет. Теперь уберем второй пункт потому что си это язык общего назначения. Теперь уберем третий пункт потому что си это язык общего назначения. Прошу, выбирайте. > Потому что люблю кодить > системщину и фирмвари. И я вижу что есть много месте для > улучшения - а комитету похрен, он только себе жизнь упрощает и > трясется за легаси. И это не круто. Делегировать такое проприетари типа > мисры - еще менее круто. В целом согласен. Но на мой взгляд комитет просто видит свою цель в строительстве нового языка, а в неполомании текущего. Очевидно что как только комитет начнет ломать ABI (как раст), то на си все сразу забьют, поэтому он вынужден ломать оооочень медленно почуть-чуть, чтобы жильцы (и это не хипстеры-студенты, а целые устоявшиеся отрасли) успели переехать. С другой стороны на си итак рано или поздно забьют. Но я надеюсь что за это время придет что-то поадекватнее и посовременней раста и желательно без корпораций которые будут полностью контролировать закулисье ЯП.
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	376. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 07-Сен-23, 02:55
	> Никак, раст это гугломайкрософтамазон, избавление от их влияния уже проходили например > в андройде, ничем хорошим это не закончилось. Ну насколько я вижу по librust-* в дебиане, прошаренные господа с своим путем на все свой антидот найти в принципе могут, если захотят. Но как вариант - мне может зайти что-то типа zig или hare. Но точно не ады с хаскелями, блин. > У всего есть слабые стороны. И вопрос в том насколько оно далеко от моих хотелок, соответственно. И насколько проблемы под интересную мне проблематику фиксятся. А еще мне нравится curly bracket. > Потому что типов нет. Есть байтики, а ты сам можешь их интерпретировать. У процов нативно есть юниты N байтов за присест, т.е. u16/u32/u64/... - и при этом еще начинает интересовать видение проца в регистре vs в оперативе. Возникает такая штука как endianess. Это не пустой звук, если я пакет в DMA зарядил. Он то шлет "как в RAM было". А не как в регистрах считалось. А если мы в сериальный интерфейс данные шлем, на самом нижнем уровне кроме этого еще вопрос и какой _бит_ каждого _байта_ первый. Даже байт можно слать по разному. Старшим битом вперед или младшим ;). А в C "int" трабл в том что мы не знаем сколько там битов. И байтов. Ведет к эпикфейлам в анализе граничных условий. А если кто удумает мандатом стандарта воспользоваться... ну вот на AVR можете заказать 16-битный int. Как вы думаете сколько кода потом работать будет правильно? По стандарту можно же. Де факто половина кода сломается. > ВВОДНЫМИ. А в пределах одной программы и у сей никаких проблем нет. Зато как только IO с внешним миром (сеть, файлы, интерфейсы, ...) становится очень уж не очень. Как платформенно нейтрально сериализовать "int"?! Никак?! Т.е. надо отдельно договориться что там столько-то битов? О конкретном формате signed? А в лоб в "int" вообще нини? Теперь вы догадываетесь почему появились (u)intXX_t... ибо "int" системщиков заманало в край на самом базовом уровне: мы даже не знаем хватит ли точности переменной для работы с вот этим полем пакета, например. > Компилятор знает на сколько байтиков у него int, а всякие > извращенные типы инта используются крайне редко на редкоиспользуемых архитектурах Никак не облегчает участь при желании пульнуть пакет бит-за-битом в эфир из фирмвари вон того датчика с показаниями - ну, пусть, хотя-бы температуры за бортом (еще и signed чтоб вы не скучали). С файлами такая же ерунда. > (а не только x64 и arm как на расте). Что-то мне подсказывает что gccrs будет уметь почти все что умеет GCC. Минус совсем заброшенные архитектуры конечно. Во всяком случае был тут один кадр пытавшийся под AVR на расте. Ну а вы можете показать как под такого уродца на хаскеле и аде получается. У того гражданина хоть что-то получалось. > (если уже не случились). Но смузипогромистов не знакомых с ассемблером А, теперь я понимаю - вы шарахаетесь от асма в хаскел. Без особых промежуточных вариантов. Знакомый антипаттерн. Предпочитаю более сбалансированные варианты. >> 1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum >> не распостраняется! По крайней мере в цивильном и контролируемом виде. > Не понял. Что бы вы ни сделали, препроцессор не оперирует НОРМАЛЬНЫМИ, ПРЕДСКАЗУЕМЫМИ типами вроде "uint16_t" при вычислениях! Все числовые константы которые в нем встречаются (да, он умеет в математику и почти-тюринг-полный) работают более-менее эквивалентно "классическим" типам сей. Зафорсить там конкретную битность математики как C99? Щаз! И "enum" определен весьма фривольно, вкатив -Wconversion можно узнать много нового о своем коде. И как он делал не то что вы себе вообразили и не так. Зафорсить enum в конкретный тип? И даже с конкретными диапазонами? Чтобы баги в заполнении многочисленных констант ловить? Ишь размечтались. Существуют весьма неортодоксальные трюки с препроцессором позводяющим все-равно запилить компилтайм-чеки, и САБЖ даже даст мастеркласс как это. Но это через ж... в левый глаз и выглядит довольно мерзко в коде. В С11 еще компилтайм ассерты но препроцессор может и попродвинутее чем это, в большем числе случаев. > Вот как раз integer promotion достаточно подробно описан в стандарте. Да. Но он все равно контринтуитивный, дурацкий, и часто делает совсем не то что ожидал кодер. > Большинство кодеров (подходящее слово) очевидно не читали его и не собирались, И это было большой ощибкой с их стороны. > но ВНЕЗАПНО он работает не так как они ОЖИДАЛИ. Ну знаете ли, многое > работает не так как я ожидаю. И это фигово. Инструмент не должен обламывать ожидания, ведет к куче багов на ровном месте. >> такой код? Потому что он разваливается от тыкания палочкой. > Уже обсуждалось. Специфичные условия чтобы развязать руки разработчикам компилятора. Можно создать море проблем на ровном месте. Это один из способов - и это фигово. Я за то чтобы подкрутить в очередном C2x спеки и - прибить такой булшит на корню. Иначе раст прибьет сишников, вон то никуда не годится. > В реальной жизни в рамках одной программы проблемы не встречается, В реальной жизни даже тупенькая фирмварь погодной станции шлет одним процом температуру за бортом другому. И никто не обещал что там одинаковые процы, компилеры и проч. Про файлы, интерфейсы и сети даже и вспоминать неудобно. > компилятор знает что у него UB и как на него реагировать, А надо чтобы знал програмер. И имел конкретные ожидания поведения. Одинаковые на разных платформах. Тогда будет меньше глупых багов в математике. > могут перекладываться по-разному, так это ВНЕЗАПНО всегда будет, хотя бы из-за > разных архитектур (собственно поэтому и добавили UB). И с этим явно перестарались. В ущерб всему остальному. А вот это уже фэйл. > Мне и самому не нравится концепция UB, я считаю ее неудачной (да и авторы тоже). Ну так либо починить - либо сишников замнет раст. Не вижу тут места для компромиссов, наслаждаться багами изниоткуда до упора мы, таки, не будем. Хоть там как! > Но сишники уже на нее наступили, а раст...ее повторил! В нем значительно меньше бестолковостей напрягающих в типовых случаях подводящих сишников. > Уже описывал. Ну используй другой класс, В сях нет классов, на минуточку. > который при инициализации будет проверять контрольные > суммы и поля и выдавать исключения В сях нет исключений. Более того - это не самая удачная идея в кернелах, бутлоадерах и особенно фирмварях. Но я бы посмотрел на ваш фэйс когда ECU авто на скорости за стольник в исключение уйдет, и как вы это оцените по достоинству. Мы, кажется, про системщину? :) > если байтики не похожи на класс, вот только заплатишь за это производительностью. В системщине я не ОК с оверхедом в run time. И с исключениями тоже. Вы точно системщик? Кому и зачем нужны тормозящие и непредсказуемо фэйлящие системы? > И в сях и в расте и в любом другом языке, потому что так работает > процессор и ничего ты с этим не сделаешь. Сгородив пачку проверок и предвычислений препроцессором я готов поспорить с этим утверждением. А Zig может предвычислить произвольное выражение на этапе сборки используя основной синтаксис ЯП. Так что наблюдаемые факты не подтверждают вашу теорию. И хотя это окучивает частные случаи, спасает от множества багов и/или сильно оптимизирует код. > Ну а в рамках одной программы ты внезапно можешь этого не делать. Вы задолбали одной программой. Даже в пределах 1 ОС программ сейчас сильно более 1 и они даже могут взаимодействовать. Если даже забыть про файлы, сеть, интерфейсы, и все такое. Хотя если про это все забыть то что останется то - особенно в системщине? > Как и в любом другом языке. И в расте тоже Моя претензия к сям что они по факту 100% сливают аннотацию без какого либо использования. А нехило бы обязать компилеры детектить левые доступы как минимум при предвычисляемых сценариях. ЧСХ вещи типа LTO optimizer отлично в курсе всех краевых условий. Только наружу знание вывесить не могут. В этом месте внешний интерфейс сей из стандарта клинит state of art компилеров. > ты можешь использовать типы с bounds checking и подозреваю при грамотно > написанном коде производительность будет выше чем в расте. В сях нет типов с встроенным bounds checking, а если его в рантайм делать получится, извините, дотнет какой-то. Хотя для ряда статических сценариев когда и размер массива и индекс известны можно и проверить такие вещи. LTOшный оптимизер так половину кода выкидыает, ДОКАЗАВ что энные ветки кода никак не могут вызываться во всей программе вообще. > Такие абстрактные вещи сказать про любой проект/ЯП и т.д.. В сях видите ли вообще по сути нет ABI на struct. Нельзя заявить struct в апи и потом получить interop в сколь-нить гарантированном виде. Более того - у gcc для ARM есть минимум 2 варианта ABI как передавать структы. Хотите вызвать функцию "bios" (boot loader, ...) с культурным, структурированным апи из основной фирмвари? Нннну, хотеть не вредно. Как вам требование что бут и фирмвара будут обязаны собираться 1 компилером с 1 набором флагов? Круто и интероперабельно. Давайте, еще раз булшит про "одну программу". Бутлоадеры же не нужны, а код реюз для лохов. Или нет?! > "неструктурированный, неудобный, непонятный апи", даже сейчас во времена протобафа. > Очевидно это больше психологическая проблема, чем технологическая. Да вот нормальные сишники таки взмахнули факами - и таки struct всякие в апях юзать стали. А чтоб эффективно - как указатель. На вот именно конкретный тип. С typedef даже не так плохо получается. И код не очень мерзкий, и левак ему в отличие от void* уже не впаришь. Вот так у них в коде багов на порядок меньше чем у кодеров с "одной программой" видимо подвешенной в сферическом вакууме а потому не обрабатываюшей внешние данные вообще никак.0 > Вот тут согласен, все популярные компиляторы  это !@#$%^, особенно gcc. Это связано в основном с дурным определением этого хлама в стандартах. А сами struct плохо определены по выравниванию. Но вот тут есть __attribute__(()) и прочие pragma, а то что не стандартно... ну... если у вас не GCC, и даже не шланг - suxx to be you, just f...g die! Как-то так, да. Потому что packed struck форсанутый на конкретные адреса - позволяет таки по простому поработать с чем-то типа хардварных регистров и их вот блин реально отдельных битов. > сишном llvm. Ну т.е. да, разобраться что и почему генерит компилятор > это проблема, а раст ВСЕ ЕЩЕ УСЛОЖНЯЕТ. Местами - да. Но это не выглядит фатальным. А вот определенные баги сей - особенно int безразмерный, не подлежащий сериализации, реально достали, вот честно. > Уже писал. Не используй указатели где не нужны. Почему-то unsafe для тебя > норм, а не использовать указатели по каждому чиху (что тоже своего > рода unsafe) тебя не устраивает. У unsafe есть жирный плюс. Это большой красный флаг места где я должен трижды проверить код этого господина что все ЗБС. А у сишника void* с безразмерным нечто - норма жизни, удачи в проверках что они сделали и как это совпало с намерениями вообще. > не избавишься), например от макросов...еще все ухудшил и создал для макросов > отдельный язык. Растоманы, вы больные. И лицемерные. У сей препроцессор тоже видите ли не совпадает по синтаксису с основным яп. И никакого проигрыша нет. Дада, и "uint16_t" препроцессор сей сожрать в принципе не может. Мне больше всего нравится как это в zig сделано. Просто компилтайм вычисления, сразу основным ЯПом. Самое логичное решение, и самое крутое и гибкое. Как злостному юзеру макро в С мне показалось что хрустиковские макро мощнее сишных. Хоть и инопланетнее в замен. > В си другой механизм. Мне тоже приятнее отправлять пачку в return, но > в итоге это вопрос привычки и вкуса. Это вопрос отсутствия багов и кода который не выглядит как УГ. > Так ты же можешь выбрать что-то одно и использовать. В этом месте мы узнаем что one size doesnt fits all. Более того - что такое 1U может быть еще и платформозависимо, бжад. Не, конечно можно везде 1ULL ввернуть. К сожалению это настолко круто промотит все вычисления что резко деоптимизирует код. В самых критичных местах, типа операций с битиками регистров. Самое то - заякорить всю работу с периферией в пару раз. И вот выбирайте дескать между тормозами и прострелом пяток, дорогой сишник. А поприкольнее выбор нельзя ли? Чувствую что можно. > 0b1111_0000. Это кстати как раз весьма читабельно. А в именно сях это легально только в C23, кажется, и без разделителя. Хотя конечно все МКщники юзали GCC экстеншн со времен 99 и плевали на формальности. Потому что иные способы выражения констант для регистров железа не очень информативны. > О, первый нормальный наброс и то случайный. В си и правда есть > проблемы со строками. Их много. Конечно они не просто так появились А потому что функции stdlib это окаменелое дерьмо мамонта. Которое давно надо было списать в утиль. Те варианты которые не чекают размер буфера calle'а и выносят все. > используй умные указатели. В сях нет никаких умных указателей. Можно конечно скроить себе самому много чего - даже функции для работы с строками. Что половина софта и делает. А дырявый мусор в stdlib зачем?! > А я видел 2 аварии, переводим всех водителей машин на самокаты? На лично мой вкус я бы сильно ужесточил экзамен на водительские права и сделал так что попадение в аварию серьезно дисквалифицирует виновника на тему управления ТС. Надолго. И вероятно с пересдачей экзамена как чайник. То что сейчас вытворяют некоторые двуногие на дорогах полнейшая жесть и ад. > по unsafe дорогам" !@#$%, кэп, итак все нормальные люди так уже и делают. Проблема с сями начинается в случае когда начинает хотеться предсказуемости, а булшит про 1 программу не взаимодействюущую с внешним миром начинает вызывать вопросы. > Пока ни одну не услышал. Да вот - память рушат реже, типы целых так то получше. А, еще и многопоточность кой-как все ж сделали. И не надо меня плсами кормить. Это здоровый страшный урод. Который не си. И которому совсем не место в кернеле, фирмвари МК и проч. Во избежание. Потому что вот эти ваши экспешны там - ну совсем не айс например. > Уже видно. Ну дык, если GCC разовьется на эту тему - я подумаю. Кент вон тоже так считает. Я такой далеко не один имхо. > Если вы пишете софт для АЭС на сях, то у меня плохие > новости. И на расте у вас будут точно такие же проблемы. На сях написана чертова куча критичных фирмварей и софта для всего чего угодно. Авиация, космос, автомотивщики, производства, вот это все. А если вы будете ждать фирмварь ECU на аде - будете пешком ходить, имхо. > Не подскажешь где ваш софт используется, может я успею переехать? Хехе фирмвари на сях много где используются. Вы будете пещком теперь ходить? Не, поезда, автомобили и проч - не для вас, там этого добра выше крыши. Вплоть до непосредственного кручения колес, как то управления мотором "от и до". > Так он не для управляющих систем. Он для "типа управляющих систем". И теперь мы собираемся избавиться от "типа" повысив гарантии... > использовать специализированные RTOS. Т.е. RT в линуксе это "мы попробуем подтюнить > линукс чтобы снизить задержки, но ничего не гарантируем". Где-то применимо, но > далеко не там где нужны реальные RTOS. В линух уже довольно много чего вкомитили на тему именно выдачи достаточно жестких гарантий, вида что на интервале X программа будет выполняться не менее Y. Это именно ртосовские гарантии. И там очень много оговорок и специфики. Вплоть до рефактора кода, блин, консолей. Дабы printk оптом таки не смог заякорить реалтаймный софт. А когда мне жесткое реальное время надо - ну я могу себе фирмварь МК накодить. Там вообще весь камень может быть посвящен задаче и я могу менее чем микросекунду потрогать руками. > Некоторые компании хотели бы больше контроллировать ядро и раст это очередная попытка, Кодеры со своей стороны хотят меньше багов лепить. А вот именно контролировать - врядли особо получится, ядерщики пронырливые типы. > раст явно не читаемый (си, кстати тоже). Ну уж не фанатам хаскеля про читаемый код рассуждать. > Вот только лучше пока не придумали. А таки для меня раст смотрелся бы апгрейдом по ряду моментов. И даунгрейдом по другим. Но как я вижу в истории с кернелом - они не чужды решению проблем. Выгодное отличие от ISO. > Поэтому при внедрении раста в линукс переизобретают растоманские примитивы? У них было более 9000 костылей для именно си, задолго для всяких хрустов. Я оттуда половину идей бессовестно спер в окружения типа фирмварей, там компилтайм проверки и все такое очень кстати. А вы можете исключения кидать. В программах которые работают одним. Лучше это сделать в ECU вашего авто сразу, чтобы оценить как это офигенно в системщине. > это домашний проект из двухтысячных который по-быстрому попытались привести к чему-то > похожему на поделия конца двухтысячных, но который подхватили маркетологи и довольно > успешно зафорсили. А таки для меня это выглядит как инкрементальный фикс ряда проблем сей. Не, ваши ады и заскелы сеье оставьте, это не ко мне с их парадигмами и синтаксисом. > Примерно то же самое было с php, ничем хорошим это не закончилось. ...но ничего лучше phpbb для форумов и mediawiki для вики так никто и не смог. > не предлагая ничего взамен кроме как переставлять кровати (unsafe, встроенный в > компилятор линтер, встроенные проверки в стандартные типы, да этот список даже > смешно звучит, раньше бы я подумал что это юмористический язык). Ну как бы в сях как раз половина проблем системщины из-за таких вещей и лезет. Скостить объем багов в разы - то что доктор прописал. > Раст это не будущее, не решение проблем си (которые конечно есть, но > в основном не те которые вы назвали). КМК про си в свое время тоже вещали что-то такое. А паскалисты это и по сей день втирают. Правда, забыв накодить сравнимое со всеми этими фирмварями, бутлоадерами, ядрами, либами... > Ваши предшественники это не деды. Это вы. Деды это Столлман, Ритчи, можно > наверное Линукса туда запихнуть. А кто сказал что вот у Столлмана такой уж офигенный код? И нет если багу влепил некто возрастом почти с столлмана и еще в C89 - это, очевидно, был не я. Я вообще в принципе менее чем C99 не оперирую. Такая ерунда. > это ваш современник и вероятно он и дальше пишет код в другой шаражке. Это реверанс про XFSника чтоли? А то передо мной увольняться некому - я сам себе режиссер. > А ляпы в конструкциях раста вас не смущает? Или итераторы вместо индексов > (которые тоже есть в расте) существенно меняют дело? Хм, сделать итератором аналог отрицательного индекса в массив я бы уже напрягся. Как и последствия от всего сэмулировать в виде шарахания в совсем левую память. > Ну меня в си магические символы не устраивают. Но конкретно в языке > их не очень много и язык все же наследник, а зачем > городить в новом языке такие символы не понятно. Тут я даже согласен что усугубили грабли, но 1 раз в жизни я могу закорючки выучить если это разгонит эффективность и побустает баги. > человека с узким кругозором (иначе он бы уже знал про питон например), Я не желаю иметь ничего общего с питоном. И это уж точно не системный ЯП. > Похвальное качество но раст в этом не помогает. Это не вам судить. Да и работоспособных рецептов лучше вы не предложили. > Который не знает что Linux RT это не RTOS Который знает что в линух вкатили гарантии характерные для ртос. Что приближает его к именно ртосам по уровню гарантий. > и вероятно не знает альтернатив? Знает но - крепко не любит иметь с ними дело. Для себя я предпочитаю вообще выпихнуть low level на мк а линух - координатор. При этом можно избавить себя от сомнительной радости иметь дело с недо-ос. > Который не знает как пишут софт с особыми требованиями к надежности? И только опеннетовские посетители все в белом и мастеркласс в скромности дадут. > Который знает проблемы указателей и стандартных типов, но не > знает современных альтернатив и не использует их? Удачи убедить препроцессор рассматривать числа как именно вот те современные типы. Ах, этот крап все равно будет трактовать 1ULL как нечто близкое к (unsigned long long) в результате? > Который ругает си за проблемы, которых фактически нет у практикующих разработчиков, Длинный список CVE что-то с вами не согласен. > но про которые пишут новички столкнувшись с проблемами потому что учились > по учебникам 1980ых переведенных в РФ в 2000ых? Я уж точно не учился по этому хламу. А antibug для сей в рф вообще никто не преподаст. Этого знания у россиян вообще мизер. У вас больше апломба, в что-то практическое он не транслируется. > Вы либо студент, либо начинающий разработчик какой-то > шаражки, либо пришли из какого-нибудь особо высокоуровнего языка вроде джавы и > не особо развивались. "Играл но не угадал ни 1 буквы. Ход переходит к анониму!" :) > Практически все что вы назвали сводится к теоритическим проблемам. Это _практические_ проблемы доставшие меня и вон тех кодеров кернела. Но вы можете конечно рассказывать всем что проблем нет. Только не обижайтесь на то что за этим последует. > Их часто ругают, но по факту они не столь влияют на работу. UB ну > есть такое, есть предпоссылки почему они попыли в стандарт, Мне похрен на предпосылки если это ведет к такому числу багов, вулнов и т.п. - пора пересмотреть эти предпосылки. И либо радикально починить - либо нехай вон те из rust, hare, zig и т.п. порубятся за звание "более хорошего си" если ISO совсем уж импотенты стали. > успешно их обрабатывают. Да, можно встретить на конференции как какой-нибудь проженный > сишник ругается на UB в стандарте в какой-нибудь специфичной ситуации из > которой он вполне успешно на практике выходит. Я не желаю видеть станларты с кучей UB, implementation defined и прочего крапа. И хочу чтобы long standing issues были решены. ISO это либо обеспечит, либо его сделают obsolete те же хрустики - или "убийцы хруста". Там уже очередь за головами - и таки имея на то веские причины. Все уже поняли что можно сильно лучше чем вон то, сохранив общую идею. Что бы вы там не вещали. > Встроенные типы си из коробки были рассчитаны на производительность и простоту, Это все булшит бинго. Даже просто прочитать "int" из файла это нечто ... почти нереализуемое в нормальном кроссплатформенном виде. И это уж точно не эталон простоты и производительности будет если файло захочется читать на других платформах. > либы, есть отдельные гайдлайны по современному безопасному кодингу, потому что применений > множество и разработчики стандарта си не ограничивают применение. Да и как по мне настало время либо починить long standing BS который нагибает девов в планетарном масштабе - либо вон те займут нишу. > кому-то под опеределнную архитектуру, а кому-то под определенные данные. Что должен > сделать разработчик ЯП? А ничего - опцией/сторонней либой/etc. В этом смысле то что си не стали чрезмерно отращивать stdlib как раз умный ход. > В целом согласен. Но на мой взгляд комитет просто видит свою цель > в строительстве нового языка, а в неполомании текущего. Тогда их доломают хрустики или убийцы хруста. Сделав "как си только лучше и без топовых грабель оного". Выбор за ними как им там угодно. Я не вижу смысл принимать новый стандарт если он не чинит старые проблемы. Кому это надо и зачем? > Очевидно что как только комитет начнет ломать ABI (как раст), Да оно и так сломаное - а какой у struct abi? А, implementation defined, да еще с абы каким выравниванием по дефолту? Ох, круто, это конечно такое ABI... > (и это не хипстеры-студенты, а целые устоявшиеся отрасли) успели переехать. Устоявшимся отраслям между прочим никто не запрещает билдить с опцией что это C89 до сих пор, если они окей с тем качеством кода и багов вдруг. Правда это мы еще будем посмотреть кто там с чем ок, CVE нас уже таки подутомили, видите ли. > и желательно без корпораций которые будут полностью контролировать закулисье ЯП. Корпоряции мне тоже не нравятся. С другой стороны _полностью_ контролировать что-то они таки облажаются. Ну вон дебиан пакетит либы в своем варианте, gccrs вон той клике не подконтролен, контрол начинает разваливаться, опенсорс так и работает.
	Ответить | Правка | Наверх | Cообщить модератору

	379. "Релиз ядра Linux 6.5"	+/–
	Сообщение от keydon (ok), 08-Сен-23, 14:28
	> Ну насколько я вижу по librust-* в дебиане, прошаренные господа с своим > путем на все свой антидот найти в принципе могут, если захотят. Всегда можно найти свой антидот со своими побочными эффектами. Проблема растоманов в том что они находят старые антидоты с неподходящими побочными эффектами и преподносят их как новые. Собственно кроме борроу чекера, который никто не может объяснить как же он работает, включая растоманов, ничего нового раст не предлагал. > Но как вариант - мне может зайти что-то типа zig или > hare. Но точно не ады с хаскелями, блин. Тогда нет математического доказательства и вся надежность сведется к "что нашли тестировщики". Впрочем и на хаскеле будут нюансы, например все равно придется уйти от чистых функций (и это точно такой же unsafe, так что не понимаю что с ним носятся растоманы). > И вопрос в том насколько оно далеко от моих хотелок, соответственно. И > насколько проблемы под интересную мне проблематику фиксятся. Твои хотелки меняются каждую минуту. То тебе надежный код нужен. То тебе нужен си-стайл код. То тебе внезапно нужен gcc. Ты только в рамках этого треда успел несколько раз попрыгать. > А еще мне нравится > curly bracket. Сочувствую. Сильно ухудшает читаемость, приводит к проблемам у новичков (ну как у новичков - у школьников), замедляет написание кода (даже с подстановками от редакторов). В нем был смысл в  досишные времена магических символов когда программа могла состоять из одной строки или номер строки мог иметь решающее значение для выполнения программы. > У процов нативно есть юниты N байтов за присест, т.е. u16/u32/u64/... - > и при этом еще начинает интересовать видение проца в регистре vs > в оперативе. Возникает такая штука как endianess. Это не пустой звук, > если я пакет в DMA зарядил. Он то шлет "как в > RAM было". А не как в регистрах считалось. А если мы > в сериальный интерфейс данные шлем, на самом нижнем уровне кроме этого > еще вопрос и какой _бит_ каждого _байта_ первый. Даже байт можно > слать по разному. Старшим битом вперед или младшим ;). Вот запомни свои слова. > А в C "int" трабл в том что мы не знаем сколько > там битов. И байтов. Ведет к эпикфейлам в анализе граничных условий. > А если кто удумает мандатом стандарта воспользоваться... ну вот на AVR > можете заказать 16-битный int. Как вы думаете сколько кода потом работать > будет правильно? По стандарту можно же. Де факто половина кода сломается. Си и не должен знать, потому что это стандарт, а не реализация. Реализация (компилятор) знает. У тебя выбор либо пишешь под конкретный компилятор и конкретную архитектуру тогда твой код будет непереносим, либо пишешь непроизводительную программу под минимальный размер, тогда проблем у тебя не будет, либо пишешь обобщенный код и всегда учитываешь что у тебя несколько архитектур. Это принципиальная трилемма. И си как язык общего назначения оставляет тебе решать что ты выберешь. Раст же более ограничен и решает за тебя. Как я и сказал, раст предлагает старые методы с сомнительными и отвергнутыми побочными эффектами под новой упоковкой. Вот и вся разница. > Зато как только IO с внешним миром (сеть, файлы, интерфейсы, ...) становится > очень уж не очень. Как платформенно нейтрально сериализовать "int"?! Никак?! Т.е. > надо отдельно договориться что там столько-то битов? О конкретном формате signed? > А в лоб в "int" вообще нини? Теперь вы догадываетесь почему > появились (u)intXX_t... ибо "int" системщиков заманало в край на самом базовом > уровне: мы даже не знаем хватит ли точности переменной для работы > с вот этим полем пакета, например. Когда ты взаимодействуешь с внешним миром ты либо контроллируешь данные, либо нет. Если контроллируешь, то для тебя нет разницы что с внешним миром ты взаимодействуешь или в рамках одной программы, ты всегда знаешь в каком формате тебе придет, сколько байт и в каком порядке. Если ты не контроллируешь данные, то тебе в любом случае придется договариваться или перепроверять. Более того те данные которые к тебе отправились могут не быть теми данными которые пришли в твою программу. Например может поменяться порядок. Ты просто сериализуешь по выбранному протоколу и у тебя нет никаких проблем. На любой архитектуре на любом ЯП. Если в протоколе указн BE то преобразуешь (если требуется в BE), если указано 8 бит на поле, то делаешь необходимые преобразования для своей архитектуры, своего компилятора, etc. > Никак не облегчает участь при желании пульнуть пакет бит-за-битом в эфир из > фирмвари вон того датчика с показаниями - ну, пусть, хотя-бы температуры > за бортом (еще и signed чтоб вы не скучали). С файлами > такая же ерунда. Если ты контроллируешь данные, то пуляй с необходимыми преобразованиями сколько хочешь и проблем у тебя не будет. Если не контролируешь и не собираешься их проверять, то можешь дальше есть кактус и раст (и никто другой) тут тебе не поможет. > Что-то мне подсказывает что gccrs будет уметь почти все что умеет GCC. > Минус совсем заброшенные архитектуры конечно. Во всяком случае был тут один > кадр пытавшийся под AVR на расте. Вы с одной стороны топите за недежность и ругаете си за костыльность, но при этом форсите древний и довольно костыльный gcc. > Ну а вы можете показать > как под такого уродца на хаскеле и аде получается. У того > гражданина хоть что-то получалось. Хаскель это не императивный язык вроде раста и си. И он не так сильно завязан на архитектуру и даже на систему (впрочем и си тоже может быть не сильно завязан, LLVM как пример). > А, теперь я понимаю - вы шарахаетесь от асма в хаскел. Без > особых промежуточных вариантов. Знакомый антипаттерн. Предпочитаю более сбалансированные > варианты. Я как раз больше использовал промежуточные варианты, а вот вы похоже плохо понимаете альтернативы и боитесь их. Вероятно вы не знакомы с историей ЯП, да и в принципе с видами ЯП за исключением популярных императивных и поэтому стали жертвой расторекламы, которая предлагает старые вещи под новыми именами. >[оверквотинг удален] > типам сей. Зафорсить там конкретную битность математики как C99? Щаз! И > "enum" определен весьма фривольно, вкатив -Wconversion можно узнать много нового о > своем коде. И как он делал не то что вы себе > вообразили и не так. Зафорсить enum в конкретный тип? И даже > с конкретными диапазонами? Чтобы баги в заполнении многочисленных констант ловить? Ишь > размечтались. Существуют весьма неортодоксальные трюки с препроцессором позводяющим > все-равно запилить компилтайм-чеки, и САБЖ даже даст мастеркласс как это. Но > это через ж... в левый глаз и выглядит довольно мерзко в > коде. В С11 еще компилтайм ассерты но препроцессор может и попродвинутее > чем это, в большем числе случаев. Потому что все что делает препроцессор это делает автозамены строк. Просто подстановщик. Отсюда и все его ограничения. Собственно поэтому он и ПРЕпроцессор. Вообще это дикий костыль, одно из худших решений в си, но раст СКОПИРОВАЛ его и СДЕЛАЛ ЕЩЕ ХУЖЕ. > Да. Но он все равно контринтуитивный, дурацкий, и часто делает совсем не > то что ожидал кодер. Если кодер не читал и не учил, то понятно что он НЕ ОЖИДАЛ. Ну тут ССЗБ. > И это фигово. Инструмент не должен обламывать ожидания, ведет к куче багов > на ровном месте. У вас одни ожидания, у меня другие. Чьи именно ожидания инструмент не должен обламывать? > Можно создать море проблем на ровном месте. Это один из способов - > и это фигово. Я за то чтобы подкрутить в очередном C2x > спеки и - прибить такой булшит на корню. Иначе раст прибьет > сишников, вон то никуда не годится. В целом я согласен. Вот только сейчас ясно что раст никого не прибьет кроме себя. > В реальной жизни даже тупенькая фирмварь погодной станции шлет одним процом температуру > за бортом другому. И никто не обещал что там одинаковые процы, > компилеры и проч. Про файлы, интерфейсы и сети даже и вспоминать > неудобно. Никто и не обещал что оно будет работать. Либо контролируешь свои данные (например используешь протокол), либо нет. И раст тут не поможет. > А надо чтобы знал програмер. И имел конкретные ожидания поведения. Одинаковые на > разных платформах. Тогда будет меньше глупых багов в математике. Програмер знал бы если бы разбирался в компиляторе, увы, но и компиляторы стали весьма сложные и програмеры стали сильно слабее. Тут замкнутый круг, одно ведет к другому и раст его только сильнее запутает. > И с этим явно перестарались. В ущерб всему остальному. А вот это > уже фэйл. Я тоже так считаю, но это скорее теоритическая проблема, чем практическая. > Ну так либо починить - либо сишников замнет раст. Не вижу тут > места для компромиссов, наслаждаться багами изниоткуда до упора мы, таки, не > будем. Хоть там как! Так починили, но не в стандарте, а в реализациях. > В нем значительно меньше бестолковостей напрягающих в типовых случаях подводящих сишников. Растоманы уже еще больше сишников бестолково лажают. Просто потому что они даже не слышали об алгоритмах, об структурах, об альтернативах, все что они знают это вот так создать переменную и как-то там с помощью магии какой-то борроу чекер что-то за меня проверит. А если ошибка, то это наверняка в unsafe. Увы, есть вещи которые ЯП решить не в силах, поэтому раст их не решит. Есть вещи которые ЯП может решить или улучшить, но по иронии раст ничего с ними не делает или ухудшает. > В сях нет классов, на минуточку. > В сях нет исключений. В perl тоже почти всю жизнь не было классов, но это не мешало их использовать ;) > Более того - это не самая удачная идея > в кернелах, бутлоадерах и особенно фирмварях. Но я бы посмотрел на > ваш фэйс когда ECU авто на скорости за стольник в исключение > уйдет, и как вы это оцените по достоинству. Мы, кажется, про > системщину? :) Мы про си. А на си я бы не стал делать ничего от чего бы зависила человеческая жизнь. Исключение это всего лишь абстракция и она ничем не отличается от явной обработки ошибок и не может быть не самой удачно идеей. Другое дело конкретная реализация. > В системщине я не ОК с оверхедом в run time. И с > исключениями тоже. Вы точно системщик? Кому и зачем нужны тормозящие и > непредсказуемо фэйлящие системы? Нет, я вообще не системщик. В расте не ок с оверхедом и с тормозами и даже с предсказуемостью как показывает практика не ок. Но почему-то вы сюда свернули. > Сгородив пачку проверок и предвычислений препроцессором я готов поспорить с этим утверждением. > А Zig может предвычислить произвольное выражение на этапе сборки используя основной > синтаксис ЯП. Так что наблюдаемые факты не подтверждают вашу теорию. Ну так предвычисли мне размер данных которые я отправлю только завтра. Совсем люди головой не думают. А заменить функцию из констант на константу так это еще паскаль делал когда я в школе учился. То что константа может выглядеть как динамический класс это проблема конкретного ЯП. > Вы задолбали одной программой. Даже в пределах 1 ОС программ сейчас сильно > более 1 и они даже могут взаимодействовать. Если даже забыть про > файлы, сеть, интерфейсы, и все такое. Хотя если про это все > забыть то что останется то - особенно в системщине? Потому что все сводится к одной программе. Либо контролируешь данные, либо нет и тогда проводишь с каждой порцией данных разъяснительную беседу. Тут нет особо вариантов. > Моя претензия к сям что они по факту 100% сливают аннотацию без > какого либо использования. А нехило бы обязать компилеры детектить левые доступы > как минимум при предвычисляемых сценариях. ЧСХ вещи типа LTO optimizer отлично > в курсе всех краевых условий. Только наружу знание вывесить не могут. > В этом месте внешний интерфейс сей из стандарта клинит state of > art компилеров. Возможно дело в том что добавление в стандарт аннотаций приведет к тому что их нужно будет реализовать всем, а это не всем нужно и приведет к очевидному снижению производительности. А на уровне реализаций итак есть аннотации и если не ошибаюсь например clang может их вывести. > В сях нет типов с встроенным bounds checking, а если его в > рантайм делать получится, извините, дотнет какой-то. Хотя для ряда статических сценариев > когда и размер массива и индекс известны можно и проверить такие > вещи. LTOшный оптимизер так половину кода выкидыает, ДОКАЗАВ что энные ветки > кода никак не могут вызываться во всей программе вообще. Так в сях и то и другое есть. И либы с структурами с bounds checking и компиляторы с LTO. > В сях видите ли вообще по сути нет ABI на struct. Нельзя > заявить struct в апи и потом получить interop в сколь-нить гарантированном > виде. Само собой, потому что базовые структуры они на то и базовые, что не реализуют функционал который может не всем потребоваться. Используйте подходящие либы и инструменты. > Более того - у gcc для ARM есть минимум 2 > варианта ABI как передавать структы. Даже на x64 знаю как миниум 3 варианта. > Хотите вызвать функцию "bios" (boot loader, > ...) с культурным, структурированным апи из основной фирмвари? Нннну, хотеть не > вредно. Ох уж это поколение смузи. Ну используй подходящую либу. Она тебе и проверки автоматически сделает и тесты и доку составит и либы сгенерит. Почему ты хочешь этого от базового функционала языка общего назначения? Не всем это нужно, поэтому этого нет из коробки и не должно быть. > Как вам требование что бут и фирмвара будут обязаны собираться > 1 компилером с 1 набором флагов? Круто и интероперабельно. Все нулевые так и было. Сейчас стало получше, решили придумать раст, который в принципе делает тоже самое, но со своим компилятором. Было 10 проблем, стало 11. > Давайте, еще > раз булшит про "одну программу". Бутлоадеры же не нужны, а код > реюз для лохов. Или нет?! Там то как раз есть протокол который определяет как бутлоадер будет дальше запускать код. В этом нет никаких проблем ни для си, ни для ассемблера, ни для чего-либо другого потому что не надо контролировать данные. > Да вот нормальные сишники таки взмахнули факами - и таки struct всякие > в апях юзать стали. А чтоб эффективно - как указатель. На > вот именно конкретный тип. С typedef даже не так плохо получается. > И код не очень мерзкий, и левак ему в отличие от > void* уже не впаришь. Вот так у них в коде багов > на порядок меньше чем у кодеров с "одной программой" видимо подвешенной > в сферическом вакууме а потому не обрабатываюшей внешние данные вообще никак.0 Не буду повторяться про одну программу. > Это связано в основном с дурным определением этого хлама в стандартах. А > сами struct плохо определены по выравниванию. Но вот тут есть __attribute__(()) > и прочие pragma, а то что не стандартно... ну... если у > вас не GCC, и даже не шланг - suxx to be > you, just f...g die! Как-то так, да. Потому что packed struck > форсанутый на конкретные адреса - позволяет таки по простому поработать с > чем-то типа хардварных регистров и их вот блин реально отдельных битов. Структ и не должны быть определены по выравниванию, потому что процесс выравнивания в разных ситуациях по разному влияет на производительность и очень важен. > Местами - да. Но это не выглядит фатальным. А вот определенные баги > сей - особенно int безразмерный, не подлежащий сериализации, реально достали, вот > честно. Какую-то дичь вы пишете. int в си подлежит сериализации, иначе вы бы на линуксе не смогли бы пользоваться интернетом, например, потому что внезапно ваш драйвер сетевухи написан на си и скорее всего с int'ами. > У unsafe есть жирный плюс. Это большой красный флаг места где я > должен трижды проверить код этого господина что все ЗБС. А у > сишника void* с безразмерным нечто - норма жизни, удачи в проверках > что они сделали и как это совпало с намерениями вообще. Unsafe это большой красный плащ конкистадора для быка програмера. Вот только пока бык бежит проверять unsafe конкистадор делает мемори лик в safe. Ну а в хорошем коде обычно итак критичные и бытовые вещи разделены на любом языке. Так что не будь быком, не ведись на красную тряпку. > У сей препроцессор тоже видите ли не совпадает по синтаксису с основным > яп. И никакого проигрыша нет. Есть. В си препроцессор это жесткий костыль. От которого страдает и безопасность и читаемость и скорость компиляции. А в расте это еще более жесткий костыль. > Как злостному юзеру макро в С мне показалось что хрустиковские макро мощнее > сишных. Хоть и инопланетнее в замен. Вас не смутило что в си макро подставляется препроцессором-подстановщиком, а в расте это ЦЕЛЫЙ ОТДЕЛЬНЫЙ ЯП В ЯП имеющего мало общего с самим растом? > Это вопрос отсутствия багов и кода который не выглядит как УГ. Нет, это просто синтаксичесис никак на баги не влияющий. Ну а с синтаксисом у раста еще большие проблемы. > В этом месте мы узнаем что one size doesnt fits all. Более > того - что такое 1U может быть еще и платформозависимо, бжад. > Не, конечно можно везде 1ULL ввернуть. К сожалению это настолко круто > промотит все вычисления что резко деоптимизирует код. В самых критичных местах, > типа операций с битиками регистров. Самое то - заякорить всю работу > с периферией в пару раз. И вот выбирайте дескать между тормозами > и прострелом пяток, дорогой сишник. А поприкольнее выбор нельзя ли? Чувствую > что можно. Про одну программу я уже писал, тут тоже самое. > А потому что функции stdlib это окаменелое дерьмо мамонта. Которое давно надо > было списать в утиль. Те варианты которые не чекают размер буфера > calle'а и выносят все. И не должны чекать. Поэтому то она и СТАНДАРТНАЯ либа. > В сях нет никаких умных указателей. Можно конечно скроить себе самому много > чего - даже функции для работы с строками. Что половина софта > и делает. А дырявый мусор в stdlib зачем?! Ох черт, что же ты такое. Ну так НЕ ИСПОЛЬЗУЙ СТАНДАРТНУЮ ЛИБУ ЕСЛИ ОНА ТЕБЕ НЕ ПОДХОДИТ. Это же очевидно. > На лично мой вкус я бы сильно ужесточил экзамен на водительские права > и сделал так что попадение в аварию серьезно дисквалифицирует виновника на > тему управления ТС. Надолго. И вероятно с пересдачей экзамена как чайник. > То что сейчас вытворяют некоторые двуногие на дорогах полнейшая жесть и > ад. И ты опять попытался решить человеческую проблему техническими методами. Эти двуногие дадут взятку и дальше будут разъезжать. Ну а остальные просто заполонят гибдд бесполезными очередями. > Да вот - память рушат реже, типы целых так то получше. А, > еще и многопоточность кой-как все ж сделали. Не рушит реже. Такие же типы как и в gcc например. Реализовали один вид многопоточности со своими проблемами и забили на остальные. Как я и говорил очередное старое решение с побочками под новой упаковкой. > И не надо меня плсами кормить. Это здоровый страшный урод. Который не > си. И которому совсем не место в кернеле, фирмвари МК и > проч. Во избежание. Потому что вот эти ваши экспешны там - > ну совсем не айс например. Но если бы ты попробовал плюсы, ты бы знал что эксепшены отключаемы, а современные плюсы гораздо интереснее по стандартным типа и по предвычислениям чем си.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 12-Сен-23, 01:43
	> может объяснить как же он работает, включая растоманов, ничего нового раст не предлагал. Еще нормальные типы, отсутствие UB, явное маркирование откровенно опасных операций. То на что тупарей из ISO никак прожать в сях не получается, особенно по ВСЕЙ площади вплоть до препроцессора, enum и прочих struct'ов. Мне похрен новое оно или как, меня решение практических проблем "в интерьере" интересует. > Тогда нет математического доказательства и вся надежность сведется к "что > нашли тестировщики". Меня интересует отлов типовых массовых факапов. Никаие математические доказательства не знают правильно я сделал алго или нет. Может я еще в дизайне лоханулся. В этом смысле - десяток посмотревших в тривиальный код больше помогут. А вон то сложность подымает до небес. Начинают обходить, затыкать, мухлевать, и получается как с ариан5. С хрустом конечно тоже так можно но поводов меньше. И никому не интересны оправдания и переваливание ответственности, интересно чтобы этого всего не было а при этом начинают интересовать уже таки комплексные аспекты прожектменеджмента и сбалансированные свойства, а не утыки в погоню за идеалом ведущие к провалу в других аспектах. > Впрочем и на хаскеле будут нюансы, например все равно придется уйти > от чистых функций (и это точно такой же unsafe, так что > не понимаю что с ним носятся растоманы). На хаскеле по моему основной нюанс в том что потом кроме автора программы ее вообще читать никто не хочет и въезжать в это все. У меня тоже нет никакого желания вкуривать в крутые абстракции уникальные для 1 проекта на всю планету. А если чувак кодивший ECU модуль кода неверно поймет намерения коллеги, ничем хорошим это не закончится. > Твои хотелки меняются каждую минуту. То тебе надежный код нужен. То тебе > нужен си-стайл код. То тебе внезапно нужен gcc. Ты только в > рамках этого треда успел несколько раз попрыгать. У меня может быть более 1 предпочтения! И если тул сразу эн окучивает, это бонус в пользу тула. Представляете, это сложный комплексный процесс с интегральной оценкой факторов. От реюза знаний по "backend" до возможности других людей въехать в код и вероятностей что они поймут его правильно. > Сочувствую. Сильно ухудшает читаемость, приводит к проблемам у новичков Меня читаемость устраивает. Лучше чем у других. И к тому же печатать не сильно много а несовпадение скобок сразу хайлайтит что что-то пошло сильно не так. > новичков - у школьников), замедляет написание кода (даже с подстановками от > редакторов). Да ничего оно не замедляет особо. И это, выделяет логические блоки, при том если при редактировани полблока снести случайно, или при копипасте лоханулись, это по крайней мере замечено будет. Сразу. А не через где-то в рантайме. > когда программа могла состоять из одной строки или номер строки мог > иметь решающее значение для выполнения программы. Номера строк тут не при чем. Это про логическое выделение блоков - и контроль что блок существует атомарно, не вынесли часть случайно при редактировании, копипасте, вот это все. > Си и не должен знать, потому что это стандарт, а не реализация. > Реализация (компилятор) знает. Я нахожу такой подход крайне неудачным. Спихивает все проблемы стандартизаторов и имплементеров на кодера. Это ведет к багам на ровном месте - 100% булшит. > У тебя выбор либо пишешь под конкретный компилятор и конкретную архитектуру тогда > твой код будет непереносим, либо пишешь непроизводительную программу под минимальный размер, А хотели мы таки писать более-меенее портабельно, реюзабельно, шустро и без багов. Get the idea. Если до додиков из исы туго доходит, мы им популярно объясним какой у нас выбор на самом деле может быть. Может и без них - если с ними не получается. > тогда проблем у тебя не будет, либо пишешь обобщенный код и > всегда учитываешь что у тебя несколько архитектур. Я использую типы из C99 и не имею глупых проблем. Но правила математики в си таки остаются кривыми и костыльными, а препроцессор и enum таки все равно грабли. И это утомило. > Это принципиальная трилемма. Принципиально это 1) Решать имеющиеся проблемы а не заметать под ковер. 2) Достигать нормального результата по общему набору свойств за разумное время. 3) Не заниматься откровенными идиотизмами и прыгом по минному полю. > И си как язык общего назначения оставляет тебе решать что ты выберешь. Я для себя уже и выбрал типы из C99 и ниже в принципе не оперирую. А "int" безжалостно выпиливается если вдруг попадается. И апи совсем иначе строятся. > Раст же более ограничен и решает за тебя. Как я и сказал, раст предлагает старые > методы с сомнительными и отвергнутыми побочными эффектами > под новой упоковкой. Вот и вся разница. Остальные вообще адекватных решений не предложили. > Когда ты взаимодействуешь с внешним миром ты либо контроллируешь данные, либо нет. > Если контроллируешь, то для тебя нет разницы что с внешним миром > ты взаимодействуешь или в рамках одной программы, Да, я захватил планету и на ней исключительно мои устройства с моими форматами данных. Разве не заметно? Про то что устройства могут делать более 1 производителя а на протоколы и форматы данных должны быть внятные спеки вы видимо не слышали. > ты всегда знаешь в каком формате тебе придет, сколько байт и в каком порядке. До первого хаксора который решит это палочкой потыкать, не загонит ли олд отрицательный индекс своим "int" куда. > Если ты не контроллируешь данные, то тебе в любом случае придется договариваться > или перепроверять. И когда это типы фиксированной битности все почему-то проще а багов в цать раз меньше. Откуда и идея отправить горбатые типы на свалку истории и если не валить компил с error то как минимум warning кидать. Сразу минус 9000 багов на программу. Особенно если идиотские правила integer promotion и UB при signed overflow пофиксить. > не быть теми данными которые пришли в твою программу. Например может > поменяться порядок. Вот это на самом деле сильно зависит от. В сериальном интерфейсе порядок ну вот не поменяется хоть там как. Чисто физически некуда. > нет никаких проблем. На любой архитектуре на любом ЯП. "int" в его изначальном определении - сериализации вот так по простому вообще не подлежит. Такая ерунда. И это фигово. > Если ты контроллируешь данные, то пуляй с необходимыми преобразованиями сколько хочешь > и проблем у тебя не будет. Кроме того что этот код на другом проце сломается к хренам. И это источник багов. > Если не контролируешь и не собираешься их проверять, то можешь дальше есть кактус и раст (и > никто другой) тут тебе не поможет. В расте по крайней мере доперли СРАЗУ сделать нормальные типы более годные для вон того - и не делать мозг "int" неопределенного размера что ведет к факапищам математики, IO и проч на всех мыслимых уровнях и тоннам CVE на этом поприще. А даунплеить это я таки вам не дам. Зело дохрена зафиксил такого чтобы игнорить топик. > Вы с одной стороны топите за недежность и ругаете си за костыльность, > но при этом форсите древний и довольно костыльный gcc. Я форшу сбалансированное сочетание свойств и реюз знаний. Ну и шустрый и компактный код, нафиг мне в системщине дотнет очередной. > Хаскель это не императивный язык вроде раста и си. И он не > так сильно завязан на архитектуру и даже на систему (впрочем и > си тоже может быть не сильно завязан, LLVM как пример). Что-то мне подсказывает что от кадавра который постоянно жрет лучше отойти на безопасное расстояние. LLVM это капец на уровне архитектуры. Либа весом аж 80 мегов, с вообще всеми кодогенераторами подо все что можно одним куском? Концептуалы, с си++ жутковатым. Подмятые на двоих аж гуглем и эплом. Весьма такое себе. > Я как раз больше использовал промежуточные варианты, а вот вы похоже плохо > понимаете альтернативы и боитесь их. Я предпочитаю разумный общий баланс свойств, реюз знаний по бэку тулчейна по возможности и проч. Видите ли, в системщине меня могут интересовать весьма интересные вещи. Вот вы когда-нибудь компоновали кастомно бинарник? С написанием линкер скрипта? А теперь покажите как вы это - в ваших альтернативах? И там бутлоадерок на этом - разложите? DMA транзакцию, с жестким контролем лэйаута памяти, времени жизни буфера, и формата данных - зарядите? Без всего этого булшита про взаимодействие сам с собой. Заодно и узнаете почему реюзать эти знания хочется. А на чем-то с атмегу или cortex M0 - заведется? Без булшита про докупите проц пожирнее. Хотя за ваш счет я и суперкомпьютер, конечно, купить готов. А за свой - вот пардон. > императивных и поэтому стали жертвой расторекламы, которая предлагает старые вещи под > новыми именами. Хрустики делом доказали что все вон то у них в принципе сделать можно - хоть иногда и с костылями и WIP. Покажите как оно у альтернатив вообще, чтобы про системность вообще заикаться. > Потому что все что делает препроцессор это делает автозамены строк. Просто подстановщик. Он еще умеет математику и условные операторы. И даже рекурсию до энного предела. Поэтому он "почти тюринг полный". Это по сути почти отдельный яп позволяющий весьма мощную логику. > Отсюда и все его ограничения. Собственно поэтому он и ПРЕпроцессор. Вообще > это дикий костыль, одно из худших решений в си, но раст СКОПИРОВАЛ его и СДЕЛАЛ ЕЩЕ ХУЖЕ. Я не спорю что Zig прикольнее сделал. Но он позже вылупился. И имеет ряд своих дурных проблем. > Если кодер не читал и не учил, то понятно что он НЕ ОЖИДАЛ. Ну тут ССЗБ. Не облегчают нашу участь на тему кучи багов от ССЗБ-кодеров -> бесполезное по жизни знание. > У вас одни ожидания, у меня другие. Чьи именно ожидания инструмент не > должен обламывать? Я буду ориентироваться на статистику по числу багов и общее состояние проектов в поиске ответа на этот вопрос. Если 90% обломается а 10% нет, мне наплевать входите вы в те 10% или где. > никого не прибьет кроме себя. Да пока вроде не собирается. Даже вон в gcc начальную реализацию втулили. Она еще не полная но таки - вот - уже есть. > Никто и не обещал что оно будет работать. Либо контролируешь свои данные > (например используешь протокол), либо нет. И раст тут не поможет. Как минимум нормальные типы данных с самого начала багов в таком коде поубавят. Почему-то. А "int" в коде - это почти гарантия багованости - уж пардон. Чисто статисически. И мне похрен чем это вызвано. Это ФАКТЫ, спорить с ними, винить кодеров и проч контрпродуктивно. > стали весьма сложные и програмеры стали сильно слабее. Тут замкнутый круг, > одно ведет к другому и раст его только сильнее запутает. Как показал натурный эксперимент, програмеры возомнив себя богами начали неимоверно лажать в этом самом. И загоняя очередной void* хзкакого размера и array[int] с чем-то отрицательным в индексе получается знатный й0пс с пантеона то. И вот у именно олдов зачастую самый поганый код, нубы более трезво свои скиллы оценивают и более параноидальны, а заодно и новые стандарты изучить не ломаются - и не доверяя себе чрезмерно предпринимают меры для отсутствия лажи если не ленивые. А ленивые вообще идут в питоняши и сишку не используют. >> И с этим явно перестарались. В ущерб всему остальному. А вот это уже фэйл. > Я тоже так считаю, но это скорее теоритическая проблема, чем практическая. Это таки жесткая практическая проблема - куча багов изниоткуда на ровном месте. Стандарт или будет переделан - или писать софт будут на чем-то ином. Глупо получать левые баги за сам факт дурости стандарта. > Так починили, но не в стандарте, а в реализациях. Это не есть приемлимый на практике вариант имхо. > Растоманы уже еще больше сишников бестолково лажают. Просто потому что они даже > не слышали об алгоритмах, об структурах, об альтернативах, все что они > знают это вот так создать переменную и как-то там с помощью > магии какой-то борроу чекер что-то за меня проверит. Ну вот это уже от кодеров зависит. Гунявый кодер на чем угодно гуняв конечно, чуда не произойдет. Но предпосылок для багов меньше при прочих равных. И мне нравится когда при дизайне яп это понимают, особенно если что-то вякают про системщину. > ЯП может решить или улучшить, но по иронии раст ничего с > ними не делает или ухудшает. Вопрос еще и в цене которую приходится за то или иное действо платить и общий баланс. > В perl тоже почти всю жизнь не было классов, но это не мешало их использовать ;) И тем не менее в сях нет классов. Поэтому простой лаконичный код без левых багов - ага, ща. > Мы про си. А на си я бы не стал делать ничего > от чего бы зависила человеческая жизнь. Это показывает насколько вы некомпетентны в вопросах системного программирования. Потому что есть. Работает. И этого - не просто дофига, а "почти все". Если теории не стыкуются с фактами - хреновые теории. Ну то-есть можно. Если захотеть. Но сложно. И с ограничениями. Типа дохреналиона правил MISRA намекающих на "удачность" дизайна ЯП. > Исключение это всего лишь абстракция и она ничем не отличается от явной > обработки ошибок и не может быть не самой удачно идеей. Другое > дело конкретная реализация. Это упрощает жизнь кодеру - ценой потери предсказуемости, что в системщине смерти подобно. Этим и плохо. > Нет, я вообще не системщик. Оно и видно. А какого черта вы лезете учить системщиков что им должно быть надо? Идите вон хирурга поучите как вас оперировать. > В расте не ок с оверхедом и с тормозами и даже с предсказуемостью как показывает > практика не ок. Но почему-то вы сюда свернули. Ну как бы хруст даже в атмегу вон засунул 1 из местных. А вы так сможете с своими "альтернативами"? Если нет - тогда какие нахрен альтернативы и чему?! Явно не сям. И даже не хрусту. Такая ерунда - вы можете так же, или нет, это bool. > Ну так предвычисли мне размер данных которые я отправлю только завтра. Разумеется так можно обыграть не все. Зато можно очень крутой и годный препроцессинг оформить, тем же синтаксисом, и менее ограниченно. В сях с этим больше изврашений. Не, извините, на МК питаемом от мелкой батареечки я не могу навороченные вычисления - мелкая батареечка от них быстро сядет и юзер меня проклянет. Добро пожаловать в системщину - "energy-aware coding". Поэтому если что-то можно предвычислить и загнать результат - это нужно предвычислить. > Совсем люди головой не думают. А заменить функцию из констант на константу > так это еще паскаль делал когда я в школе учился. В системщине хочется получать этот процесс явно и гарантированно. С четким отлупом на фазе компила если это вдруг сделать не удалось. Вместо ВНЕЗАПНОГО получения ломового жора батарейки вон той пакостью на ровном месте, с постоянной тряской над профайлингом. Мы вам тут не жабисты и не дотнетчики. > То что константа может выглядеть как динамический класс это проблема конкретного ЯП. В системщине хочется весьма конкретный и явный контроль над такими вещами. Например для energy aware coding. Когда я четко понимаю истинную вычислительную сложность вот этого вот - и сколько у меня батарейки в трубу с этого улетит, ага. > Потому что все сводится к одной программе. Либо контролируешь данные, либо нет > и тогда проводишь с каждой порцией данных разъяснительную беседу. Тут нет > особо вариантов. Примем как факт. В мире более 1 программы, данные мы не всегда контролируем - и в нем более 1 человека, вендора железа, протоколов и прчо. Поэтому мы хотим чтобы этот сценарий работал без гимора и багов. "int" в эту хотелку совсем не вписывается. > Возможно дело в том что добавление в стандарт аннотаций приведет к тому > что их нужно будет реализовать всем, И вообще-то - да вы знаете - надо прожать этих господ чтобы не делать это проблемой ВСЕХ ВООБЩЕ. Если они так не могут - вот отлично! Это - легаси е...чее! Noncompliant. Которое не имеет право называть себя C2X. Пусть C99 декларят! Или что там они могут. А C2X сорец, вот, не соберется на этом хламе с совершенно законными основаниями. Заодно добавит желания поднапрячься и - заимплементить, вместо переваливания своих проблем на других. Иначе хрустики это за них сделают. > а это не всем нужно и приведет к очевидному снижению производительности. Как показал пример C99 - ничего там не снизится. Просто булшит надо вытряхнуть не наполовину а весь. А очевидно снизится - число багов. Со всякими отрицательными индексами в массивах бжад. Более того - в сях можно завернуть array -> struct и это даже работать будет. С вполне приличной эффективностью в общем то, если как указатель на тип передать. И даже - таки - будет злой typecheck. А почему сразу нельзя без этого извращения uint8_t[10] как конкретный тип рассмотреть и требовать везде вот именно это и так - кто б его знает. Просто легаси тупняк. > А на уровне реализаций итак есть аннотации и если не ошибаюсь например > clang может их вывести. Аннотация вида u8[10] видите ли для машины и в общем то автопроверок, так то по задумке. Там где это катит. Си же так сразу сливает это знание в толч и не пользуется. То что кто-то где-то сбоку - ну, это уже не то. Это надо на гвозди, в стандарт, как mandatory. Тогда станет хорошо. А noncompliant'ы - не имеют право декларить стандарт. Прям так. Чтобы отделять мух от котлет и дидов с осточертевшим "int" от более нормального кода. > Так в сях и то и другое есть. И либы с структурами с bounds checking и компиляторы с LTO. Либы не катят - это в половине случаев работать не будет. Попробуйте такое на мк какой вкатить. Вот в компилтайме прочекать - оно как бы и там нормально будет. И да, вы ж не хотите фирмвару падающую в рантайм?! Поэтому чекать и считать в компил тайм все по максимуму. > Само собой, потому что базовые структуры они на то и базовые, что > не реализуют функционал который может не всем потребоваться. Используйте подходящие либы > и инструменты. Это все булшит. Я хочу видеть нормальные базовые типы. Предсказуемые и без UB. Точка. > Даже на x64 знаю как миниум 3 варианта. И это совсем не круто, между прочим. > Ох уж это поколение смузи. Ну используй подходящую либу. Вот когда вы это сами такие умные это все вот именно в ранний бутлоадер втулить попробуете - тогда с вами будет смысл разговаривать об этом. Представляете, там даже malloc какой делать еще может некуда быть делать - потому что DRAM еще не подняли, а SRAM с гулькин нос. И тут вы такой с своей либой. Даже если забыть что 80% клевых либ обгадиться собраться или адекватно работать в "freestanding". Когда попробуете что-то в этом режиме сей тогда и вещайте. > Она тебе и проверки автоматически сделает и тесты и доку составит и либы сгенерит. А заодно убьет понимание процессов кодером, привнесет более 9000 нежданчиков, в 80% случаев вообще не сбилдуется, а автоматические тесты окажутся наглухо неприменимы для фирмвари или бутлоадера с ядрами. А вот грабли зато #$%нут от души, каким нить рантайм еррором. Я вообще хочу посмотреть как вы "либу" из бутлоадера будете с другой стороны звать. Это будет гимор на всю голову. Потому что для начала - вот вы же ABI и создаете наполовину. Типа call table какого, через которого вас вообще вызывать. И вот именно какие-то либы на этом пути резко прибавят гимора на раз. > Почему ты хочешь этого от базового функционала языка общего назначения? Не > всем это нужно, поэтому этого нет из коробки и не должно быть. Я считаю сильно иначе - хрустики очень правильно нормальные целые типы оформили. Так как это должно быть в сях было. > Все нулевые так и было. Сейчас стало получше, В каком месте? С ABI Struct как был бардак так и есть. Сами же вон там написали. > в принципе делает тоже самое, но со своим компилятором. Было 10 > проблем, стало 11. У них как бы свои траблы тоже есть. Но они по крайней мере дали мастеркласс на тему что на самом деле надо было в сях сделать в ряде мест. И так то давно пора. > Там то как раз есть протокол который определяет как бутлоадер будет дальше > запускать код. А что если я часть бутлоадера потом из кода хочу позвать? И да, прототип и там будет. Но если я захочу одупляемое API с чем-то типа struct вместо вашего окаменелого кала с void* - до чего уже даже САБЖИ доперли как и все минимально продвинутые сишники, вот с ABI этого таки будет много радости. По причинам которые вы сами же и озвучили. > В этом нет никаких проблем ни для си, ни для ассемблера, ни для чего-либо другого > потому что не надо контролировать данные. Си вообще не дает прямой контроль над ABI вызова. Равно как и скажем не позволяет стандартно поместить вон то в конкретную секцию. Это пара мест где стандартный си таки сольет асму и это будет либо кусочек на асм либо экстеншн типа attribute((section)) какой. > Структ и не должны быть определены по выравниванию, потому что процесс выравнивания > в разных ситуациях по разному влияет на производительность и очень важен. На мой вкус - нехило бы определить стандартный способ решения этого вопроса, когда надо именно packed. Иногда предсказуемость ABI важнее. И это, DMA автомат вообще гораздо эффективнее это все пошлет чем проц. Он даже трафик из кода на шине не создает, а вот дырки в данных ему не подарок, он блок данных от сих видите ли тягает. Посоревнуйтесь с ними в эффективности, ага! Думаете, за что мы лю DMA? Это хардварная асинхронщина - и весьма эффективная. > Какую-то дичь вы пишете. int в си подлежит сериализации, иначе вы бы > на линуксе не смогли бы пользоваться интернетом, например, потому что внезапно > ваш драйвер сетевухи написан на си и скорее всего с int'ами. И грабель по этой линии там скушали тыщи. САБЖ унутрях поэтому заводил сто лет к ряду свои кастомные типы, куда более вменяемые. А с переходом на C11 смогут, видимо, и не изобретать вел с квадратными колесами лишний раз. > Unsafe это большой красный плащ конкистадора для быка програмера. Не важно. Важно что заметный и хайлайтит место требуюшее внимания. > Есть. В си препроцессор это жесткий костыль. От которого страдает и безопасность > и читаемость и скорость компиляции. А в расте это еще более жесткий костыль. Если в регистре было 32 бита, а препроцессор меня кастомной логикой жестко завернул с попыткой сунуться в 35-й бит, коего нет, на фазе компила - очевидно, фирварь безопаснее стала, ага. Потому что если бы этого не случилось, оно бы в рантайм сделало какую-то хрень в стиле олдов с отрицательными массивами, эта хрень не имела бы смысла и далее это undefined: програмер хотел невозможного, гарантировано-бажный код. > Вас не смутило что в си макро подставляется препроцессором-подстановщиком, а в расте > это ЦЕЛЫЙ ОТДЕЛЬНЫЙ ЯП В ЯП имеющего мало общего с самим растом? В си это тоже по сути отдельный яп. Вы просто не видели что с ним сделать можно. От генерации предвычисляемых массивов констант для довольно сложной хрени до проверки параметров и констант в компилтайме. Простой пример: const uint8_t ones[256] = {     #define B2(n) n,     n+1,     n+1,     n+2     #define B4(n) B2(n), B2(n+1), B2(n+1), B2(n+2)     #define B6(n) B4(n), B4(n+1), B4(n+1), B4(n+2)     B6(0), B6(1), B6(1), B6(2) }; Да, это всего лишь автозамена. И немного математики. Даже условные операторы не поюзали еще. Те же ядерщики и поинтереснее умеют. Как вам генерация масок для операций длля битового поля от сих до сих на автомате? Да и проверить что в 35-й бит 32-битного регистра не влезли заодно можно. И да, железки опять же нативно маппятся в память как C99-style типы. >> Это вопрос отсутствия багов и кода который не выглядит как УГ. > Нет, это просто синтаксичесис никак на баги не влияющий. Как тот кто загасил кучу багов из-за тупых типов я имею основания считать сильно иначе. > Про одну программу я уже писал, тут тоже самое. ИМХО Вы можете курить бамбук с одной программой. Это не от мира сего. > И не должны чекать. Поэтому то она и СТАНДАРТНАЯ либа. С чего бы стандарт должен быть дырявым гамном? > Ох черт, что же ты такое. Ну так НЕ ИСПОЛЬЗУЙ СТАНДАРТНУЮ ЛИБУ > ЕСЛИ ОНА ТЕБЕ НЕ ПОДХОДИТ. Это же очевидно. Да вот тут еще есть пачка господ которых бы за вот это самое нехило бы захайлайтить как минимум жирным варнингом за юзеж вон тех функций. Потому что CVEшек в их поделиях лезет более чем. Постоянно. И это утомило. > И ты опять попытался решить человеческую проблему техническими методами. А таки частично работает. CAD чекает что я все подключил - вместо упования на внимательность. ERC/DRC чекает что фаба это сможет сделать и нет явных ляпов. Анализатор в компилере чекает что я не сделал что-то явно левое, где декларация и реализация явно разошлись. Машины должны помогать решать проблемы а не перепихивать все на человека и создавать проблемы. > взятку и дальше будут разъезжать. Ну а остальные просто заполонят гибдд > бесполезными очередями. А, ну это решаемо, Судья Дредд показал как надо. Можно и автоматизировать - автоматическая туррель справится не хуже. А для надежности противотанковой ракетой можно подкрепить. > Не рушит реже. Такие же типы как и в gcc например. Да вот видите ли GCC таки может и хлам с "int" собирать. И хотелось бы хайлайтить такой код. Потому что статистически, там обычно полный хлам с математикой и граничными условиями. А на стандарты эти ваши олды как раз возлагали известно что. > Но если бы ты попробовал плюсы, ты бы знал что эксепшены отключаемы, > а современные плюсы гораздо интереснее по стандартным типа и по предвычислениям чем си. Я их попробовал - но это еще более ужасное месиво, а для системшины вообще малопригодное имхо. Дада, я согласен с Торвальсом на этот счет. Получаются капец-ужастики.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз ядра Linux 6.5"	+5 +/–
	Сообщение от pavlinux (ok), 28-Авг-23, 14:08
	> действительно безопасный язык популярный для молодого поколения, 90-e - все писались от С++ 2000 - все протекали от Java 2005 - все капали от С# (MONO) 2010 - все дро4или на Питон/PHP 2015 - теребонькали на Go . . . 1969 - 2023 - а нам пох... на вас, ANSI С  ©
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	56. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (98), 28-Авг-23, 14:46
	На Похапе наяривали в первой половине 2000-х
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от pavlinux (ok), 28-Авг-23, 15:03
	> На Похапе наяривали в первой половине 2000-х Там ещё на Perl наяривали,  пыха стала модной с появлением всяких CRM (Joomla, WordPress,  Drupal)
	Ответить | Правка | Наверх | Cообщить модератору

	70. Скрыто модератором	+2 +/–
	Сообщение от Анонин (?), 28-Авг-23, 15:38
	Как выходили за пределы массива в 70х, так и сейчас выходят! Штабильность. Потому что пох))
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	78. Скрыто модератором	+/–
	Сообщение от pavlinux (ok), 28-Авг-23, 15:55
	> Как выходили за пределы массива Программисты считают, что за компами работают не дол6оящеры и комбинаций 255 знаков из 94 (94^255) хватит для имён файлов. Но всегда найдётся задротохакер и впихнёт свой 256-й кусок го8неца. и будет махать 5-см членом на весь инет "смарите какой я крутой, я научился делать файзинг на чужом софте и осилил static analysis"
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Анонин (?), 28-Авг-23, 16:06
	Раз уж речь про дол6оящеров - то они до сих пор не научились проверять размер входных данных. А уже 50 лет прошло однако.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	82. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от pavlinux (ok), 28-Авг-23, 16:08
	Ну какой адектват станет называть свои mp3 Весна_опять_пришла,_и_лучики_тепла_доверчиво_глядят_в_моё_окно__Опять_защемит_грудь,_и_в_душу_влезет_грусть,_по_памяти_пойдёт_со_мной_Владимирский_централ_Михаил_Круг.mp3
	Ответить | Правка | Наверх | Cообщить модератору

	84. Скрыто модератором	+2 +/–
	Сообщение от Аноним (-), 28-Авг-23, 16:13
	Во-первых, адекватный человек не станет слушать "Владимирский централ"...
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Анонин (?), 28-Авг-23, 16:19
	Есть спецификация на имена файлов и путей. И если имя ей удовлетворяет, то софт обязан с ним работать правильно. Если нет - кидай ошибку. А не "и так сойдет"
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	128. "Релиз ядра Linux 6.5"	+/–
	Сообщение от FF (?), 28-Авг-23, 18:21
	8+3?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Анонин (?), 28-Авг-23, 18:40
	exFAT file system specification, 7.7.3 FileName Field
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Релиз ядра Linux 6.5"	+/–
	Сообщение от pavlinux (ok), 03-Сен-23, 15:13
	> Есть спецификация на имена файлов и путей. И если имя ей удовлетворяет, > то софт обязан с ним работать правильно. Если нет - кидай > ошибку. А не "и так сойдет" POSIX: 255 знаков, все кроме NUL, ... какого жуя, они пихают 256 знаков?
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	115. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (114), 28-Авг-23, 17:23
	>  Ну какой адектват станет называть свои mp3 Ну какой адекват станет ставить в название файла нулевой символ? Действительно, незачем такие ситуации обрабатывать.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	313. "Релиз ядра Linux 6.5"	+/–
	Сообщение от pavlinux (ok), 03-Сен-23, 15:14
	>>  Ну какой адектват станет называть свои mp3 > Действительно, незачем такие ситуации обрабатывать. Этим прикладной софт должен заниматься, а не ядро
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от fyjybvec (?), 28-Авг-23, 16:13
	в 90х не было нужды в мелких вирт. машинах (мощности не позволяли), а потом распространилась java в 90х не было нужды много и быстро писать под винду, а потом распространились С# (MONO) в 90х не было нужды в простых сайтах или скриптах, а потом распространились PHP/Питон в 90х не было нужды в написании кучи серверного кода, а потом распространился Go но все эти годы продолжалисы выходы out-of-bounds, use-after-free и ошибки указателей с 1969 по 2023 ANSIСшники прямого говорят - а нам пох на вас, как производим Г, так и бдем производить
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	129. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от FF (?), 28-Авг-23, 18:22
	гонят на сишников только безопытные джуны или вообще сочувствующие околоайтишечные гики, нетакие как все поставившие линукс
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от FF (?), 28-Авг-23, 18:30
	с 1969 по 2023 каждое поколение школьников думало, что оно уникально, делая модную прическу, надевая модный шмот, увлекаясь очередным хайпом
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	143. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от fyjybvec (?), 28-Авг-23, 19:12
	вот только этот "хайп" живет и работает и сайты на пыхе, и скрипты на питоне (а сколько там лаб по математике сделано)) и жаба-машина живет и здравствует, с#/моно работает в юнити, на сайты использующие го люди ходят каждый день (Google, Netflix, Paypal, Cloudflare)
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Релиз ядра Linux 6.5"	+/–
	Сообщение от keydon (ok), 30-Авг-23, 14:31
	> вот только этот "хайп" живет и работает > и сайты на пыхе, и скрипты на питоне (а сколько там лаб > по математике сделано)) > и жаба-машина живет и здравствует, > с#/моно работает в юнити, на сайты использующие го люди ходят каждый день > (Google, Netflix, Paypal, Cloudflare) Вот чудо, даже работает! Работать то оно работает, да вот не особо хорошо. Пыха просто славится своей болезненностью и небезопасностью. Сколько человекочасов было потрачено на простые сайты и не сосчитать (а сколько на то чтобы их переделать тем более). Количество памяти пущенное под джаву тоже не сосчитать. А сколько костылей было в ней сделано... C# и юнити это просто куски !@#$%^, а то что люди используют богомерзкие гугл, нетфликс или пайпел не показатель, если их на брейнфак переписать, люди все равно будут на них заходить Понятно что пыха была сделана на коленке в свободное время как темплейтер (да и галимый юнити тоже был изначально на флеше и за полноценный движок не считался), джава была переписана бесконечное количество раз с бесконечным количеством вводных, и это скорее проблемы обезьян которые стали молотком забивать гвозди, но превозносить их тоже не стоит. P.S. Ну а питончик хорош, там тоже костыли (вроде gil), но поменьше чем в джаве. Ну медленный, но на этикетке так и написано. Показал всем как надо делать читаемый синтаксис, за это и любим.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 28-Авг-23, 23:01
	> 1969 - 2023 - а нам пох... на вас, ANSI С © Не хомячок а очень даже гордый суслик, между прочим. И не ANSI C а вполне себе C11 с гнутыми расширениями, между прочим. То-бишь GNU11. Без вон расширений в системщине вообще далеко не уедешь так то - стандарты си не определяют некоторые важные для системщины вещи. Поэтому на ка вот тебе какой-нибудь __builtin* или __attribute__(()) без которых у тебя нихрена не выйдет а в стандарте ими и не пахло. Особенно в анси. Особенно прикольно в анси си получить какой-нить статик ассерт или генерик. И как хочешь так и имплементь.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	270. "Релиз ядра Linux 6.5"	+/–
	Сообщение от User (??), 30-Авг-23, 08:41
	> 1969 - 2023 - а нам пох... на вас, ANSI С  © И сортировку пузырьком - фигак!
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	164. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Гашпшпщм (?), 28-Авг-23, 21:46
	Хорошо набросил ))
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	256. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (257), 29-Авг-23, 19:45
	что позволит больше привлечь людей для написания ядра. И оно скоро не поместится в грузовик?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Релиз ядра Linux 6.5"	–1 +/–
Сообщение от Аноним (2), 28-Авг-23, 11:43
>поддержка векторных инструкций RISC-V Что это значит? Векторный инструкции нужны для ГПУ?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (4), 28-Авг-23, 11:57
	>> поддержка векторных инструкций RISC-V > Что это значит? Векторный инструкции нужны для ГПУ? значит можно использовать их в контексте ядра - например для быстрого копирования
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (11), 28-Авг-23, 12:33
	Для внутриядерной криптографии и CRC пригодятся.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	76. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Archer73 (ok), 28-Авг-23, 15:49
	Векторные инструкции производят операции над векторами (одномерными массивами) данных. Например, инструкция может разом сложить (умножить и т.д.) четыре числа двойной точности из одного 256-битного регистра с четырьмя числами двойной точности в другом 256-битном регистре. Получается аналог четырех последовательных операций, но в единственной процессорной инструкции. Есть даже вариант оптимизации кода, когда вместо массивов структур используют структуру с массивами, что позволяет значительно повысить производительность векторных операций над элементами структур.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	108. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (-), 28-Авг-23, 17:09
	Немного придирусь к терминологии. Векторная инструкция в процессоре, и "вектор" как абстрактный тип данных, который есть, например в C++, это разные вещи. По-моему, процессорные инструкции - это операции с двоичными наборами.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Релиз ядра Linux 6.5"	–3 +/–
	Сообщение от Аноним (187), 28-Авг-23, 23:27
	> Векторные инструкции производят операции над векторами (одномерными массивами) данных. > Например, инструкция может разом сложить (умножить и т.д.) четыре числа двойной > точности из одного 256-битного регистра с четырьмя числами двойной точности в > другом 256-битном регистре. Самое интересное что кому сильно хотелось что-то такое даже и в "обычных" регистрах делали. Это называется SWAR и таки иногда позволяет весьма эффективные параллельные вычисления за 1 такт даже там где "настоящий" SIMD и не ночевал, симдшники лишь сделали это удобнее и производительнее, отрастив широкие регистры с явными lanes. К сожалению это не халява - сохранять при переключении контекста пачку здоровенных регистров ну вот вообще совсем не бесплатная операция получается. Апликушникам то похрен - а в ядре где то IRQ, то задачу переключить, как раз самый экшн. И самый головняк от вон того. > Получается аналог четырех последовательных операций, но в единственной > процессорной инструкции. Так можно было даже без всяких simd регистров. И кому надо этим пользовались лет так дохрена, поздравляю с прозрением. > Есть даже вариант оптимизации кода, когда вместо массивов структур используют > структуру с массивами, что позволяет значительно повысить производительность > векторных операций над элементами структур. А в чем разница на уровне ассемблерного кода который компилер генерит? Ему какая-то большая разница есть?
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	211. "Релиз ядра Linux 6.5"	+/–
	Сообщение от voiceofreason (?), 29-Авг-23, 10:45
	> весьма эффективные параллельные вычисления за 1 такт даже там где "настоящий" SIMD и не ночевал Через libastral что-ли? Обычные инструкции будут жевать данные кусками по 64 бита с кучей приседаний, там где simd одним действием прожуёт 256 и более.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (261), 30-Авг-23, 01:20
	> Через libastral что-ли? Обычные инструкции будут жевать данные кусками по 64 бита Внезапно можно рассмотреть 64 бита как 8 параллельных lanes по 8 bit. Или 4 по 16. И смолотить за 1 такт 8 одинаковых операций над u8, или 4 над u16 за присест. На базе этого внезапно есть довольно эффективные алгоритмы. Собственно, когда это началось и пришло понимание что сделать регистр вообще битов так 256-512 может быть и еще интереснее. Вон то имеет определенные плюсы: эти регистры проца всяко сохранять, и допущений минимум. А симдшные контекст очень отращивают. Если хочется посмотреть как сие бывает, поискать по слову SWAR и будет вам SIMD без simd-регистров. > с кучей приседаний, там где simd одним действием прожуёт 256 и более. Приседаний там примерно столько же - идея та же самая. Просто чуть менее удобно т.к. вон там в simd регистрах - lanes могут быть и не снабжены carry в соседний lane в принудиловку. Но многие алгоритмы "для обычных регистров" просто обходят это дело - не делая математику ведущую к carry в другой lane. Просто чуть менее удобно и код специфичненько выглядит. Simd всего лишь возвел эту идею на следующий уровень, расщирив и добавив регистры и сделав lanes независимыми.
	Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз ядра Linux 6.5"	+/–
Сообщение от Аноним (7), 28-Авг-23, 12:21
> Включена по умолчанию функциональность "secretmem" Как её включить в предыдущем ядре?
Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз ядра Linux 6.5"	+2 +/–
Сообщение от Иваня (?), 28-Авг-23, 12:23
Капец, сколько примерно времени потребуется, чтобы изучить все возможности (архитектуры, криптография, файловые системы, память, сеть, виртуализация и прочее) только ядра linux?
Ответить | Правка | Наверх | Cообщить модератору

	26. "Релиз ядра Linux 6.5"	+5 +/–
	Сообщение от Аноним (26), 28-Авг-23, 13:05
	Реалистичный срок -- три года минимум. Но обычно изучаешь только то, что тебе надо, в этом случае реалистичный срок -- от 15 минут.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Ржомба (?), 28-Авг-23, 13:07
	Это вряд ли было возможно уже во времена 2.4.-2.6. По верхам - да, но так чтобы разобраться во всем - нет.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	37. "Релиз ядра Linux 6.5"	+4 +/–
	Сообщение от Аноним (35), 28-Авг-23, 13:43
	>  Капец, сколько примерно времени потребуется, чтобы изучить все возможности (архитектуры, криптография, файловые системы, память, сеть, виртуализация и прочее) только ядра linux? Nobody wants to say how this works.  Maybe nobody knows ... © man xorg.conf, но про ядро тоже актуально
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	49. "Релиз ядра Linux 6.5"	+6 +/–
	Сообщение от pavlinux (ok), 28-Авг-23, 14:17
	> . . . сколько примерно времени потребуется, чтобы изучить все возможности только ядра linux? Я с 1997 трахаюсь. Пока полностью вник в ipchains оно уже исчезло, iptables быстрее, но там уже подоспели bpf/netfilter, с BPF можно трахаться вечно.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	62. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от birdie (ok), 28-Авг-23, 15:00
	А зачем вам всё это знать? Просто интересно.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	92. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (92), 28-Авг-23, 16:37
	За год поверхностно реально освоить.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	94. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (92), 28-Авг-23, 16:39
	А зачем это всё изучать? Если эти знания через пару лет уже не будет неактуальны. Можно поверхностно разобраться за месяц, а дальше при надобности углубляться.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	163. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от microcoder (ok), 28-Авг-23, 21:35
	Всю жизнь надо изучать, родной, всю жизнь :))) И то, не догонишь!
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	180. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (187), 28-Авг-23, 23:34
	> Капец, сколько примерно времени потребуется, чтобы изучить все возможности (архитектуры, > криптография, файловые системы, память, сеть, виртуализация и прочее) только ядра linux? Сколько времени надо чтобы в 1 лицо построить межгалактический крейсер размером с город? Примерно бесконечность. Слишком большой объем работ. Вот линукс - ничуть не меньше. Одного мозга может быть маловато чтобы вместить ВСЕ закоулки проекта на 30+ миллионов строк. Общее понимание структуры? И типовые штуки, особенно нужные и интересные вот именно тебе, именно здесь? Легко. Но знать ВСЕ возможности - сначала стань сверхчеловеком, потом поговорим.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. "Релиз ядра Linux 6.5"	–2 +/–
Сообщение от Oe (?), 28-Авг-23, 12:25
Оно по прежнему размазывает однопоточные приложения по всем ядрам на время, достаточное для буста частот ядра на максимум? В итоге процессор держит максимальную частоту ядер при общей нагрузке в 1%. Приходится жить с отключенном бустом, ибо компьютер взлетает при нагрузке на процессор 1%.
Ответить | Правка | Наверх | Cообщить модератору

	14. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним2 (?), 28-Авг-23, 12:35
	Оно по-прежнему поддерживает разные планировщики, часть из которых гибко настраиваются.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (11), 28-Авг-23, 12:36
	CPU Affinity для ваших нужд?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	39. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 28-Авг-23, 13:45
	А есть статистика о жизни ЦП в таком режиме? (повреждение от неравномерного нагрева кристала и термоциклирования)
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (98), 28-Авг-23, 14:48
	У меня нет.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (284), 31-Авг-23, 02:07
	> А есть статистика о жизни ЦП в таком режиме? (повреждение от неравномерного > нагрева кристала и термоциклирования) Ну если ты этого боишься то буст частот тебе и вовсе противопоказан т.к. все только усугубляет.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	25. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (25), 28-Авг-23, 13:04
	Так это не мультиядро, чтобы каждое приложение на отдельном ядре, вот и распределяют.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	44. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (-), 28-Авг-23, 14:02
	Этот вопрос задавай производителям процессоров. Этим занимаются разработчики микрокодов (процессора). А микрокоды процессора пишут внутри компаний Intel и AMD, отдельно от Сообщества. Это архитектура "железа" такая, когда потоки обрабатываются разными ядрами, так получается проще, да и система работает быстрей. Спроектировать системную логику так, чтобы процессор обрабатывал одно приложение на первом ядре, а другое на втором ядре сложно и нецелесообразно.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	61. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от pavlinux (ok), 28-Авг-23, 14:58
	> Спроектировать системную логику так, чтобы процессор обрабатывал одно приложение на первом ядре, > а другое на втором ядре сложно и нецелесообразно. schedtool -a AFFINITY_MASK      set CPU-affinity to bitmask or list
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (68), 28-Авг-23, 15:24
	Что ты несешь? Внутренности процов с аппаратным анадизатором делают говнокод быстрее. Если планировщик раскладывает всегда по всем ядрам это проблема алгоритма программы. И вот если процессорного времени сожрется 3,5% это никак не напряжет процессор. Ты бы врубил мониторинг потребления процессора и обгадился бы что там около 1 - полутора ватт всего лишь на многоядерном процессоре. И если разложить на 16 ядер по 800мгц проще значит проще. Планировщику и установкам энергопотребления можно указать чтобы так не делали.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	50. "Релиз ядра Linux 6.5"	+/–
	Сообщение от pavlinux (ok), 28-Авг-23, 14:21
	> Приходится жить с отключенном бустом, ибо ... разные планировщики юзай (ondemand, conservative, userspace, ....)
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	158. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Oe (?), 28-Авг-23, 20:57
	Дак бустом частот выше базовой занимается исключительно сам процессор, планировщики только могут сбросить частоты ниже базовой. В android например, свои проприетарные модули ядра от производителя процессора, которые подкручивают буст частот.
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Релиз ядра Linux 6.5"	+/–
	Сообщение от pavlinux (ok), 03-Сен-23, 15:21
	> Дак бустом частот выше базовой занимается исключительно сам процессор, планировщики только Планировщики накидывают на ядро если оно простаивает.  Если ты на 146% уверен, что умнее их, то  разруливай процессы вручную, хотя бы долго живущие.
	Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Ананимус (?), 28-Авг-23, 12:34
> Добавлена, но пока не задействована в ядре, инфраструктура для применения в коде атрибута "cleanup" (Scope-based Resource Management), который может использоваться для дополнительной защиты от ошибок, приводящих к утечкам памяти и проблемам с освобождением блокировок. Вот это годная штука.
Ответить | Правка | Наверх | Cообщить модератору

	38. "Релиз ядра Linux 6.5"	–3 +/–
	Сообщение от Аноним (35), 28-Авг-23, 13:45
	Но всё равно растом попахивает. Как и все эти address sanitizer-ы и stack protector-ы.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Ананимус (?), 28-Авг-23, 14:01
	> Но всё равно растом попахивает. Как и все эти address sanitizer-ы и stack protector-ы. От тебя шизой попахивает, stack protector в gcc принесли ещё в нулевых.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (187), 29-Авг-23, 03:45
	> Но всё равно растом попахивает. Как и все эти address sanitizer-ы и > stack protector-ы. Да вот видишь ли надоело за олдами перечитывать где они там еще отрицательный индекс массиву скормили и что там еще. Пришлось сделать тулсы которые позволят такой кал обнаруживать и выгребать сразу оптом.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

17. "Релиз ядра Linux 6.5"	–4 +/–
Сообщение от cheburnator9000 (ok), 28-Авг-23, 12:40
> Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.5 - Linux-libre 6.5-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода. Снова эти самопровозглашённые блюстители частоты берут на себя роль по чтению буков и слов грязных проприетарный названий и различных строк в драйверах линукса. Ибо в их представлении простому пользователю линукса не должна быть доступна вся функциональность купленных закрытых железок. И они как мессии взяли на себя бремя по вычищению всего "богохульского" из священного писания Линуса linux-6.5.tar.xz? Логично что производители просто не занесли Столлману мешочек зеленых купюр, а он так страдает, так страдает из-за этого, иначе бы закрывали глаза так как закрывают на закрытые версии busybox в азиатских устройствах.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Релиз ядра Linux 6.5"	+6 +/–
	Сообщение от Ананимус (?), 28-Авг-23, 12:43
	Они тебя заставляют пользоваться своим форком что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (25), 28-Авг-23, 13:06
	К слову, да. Удивительно, что железка на которой встроенная проприетарщина, что нельзя перепрошить считается более свободной, чем железка, где можно применять реверс инжиниринг и поменять на свою.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	192. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 29-Авг-23, 04:04
	> перепрошить считается более свободной, чем железка, где можно применять реверс > инжиниринг и поменять на свою. От таких там ща часто секурбут есть - так что то что ты загрузил интеловский uCode процу совсем не поможет тебе свой uCode сделать - оригинал RSA подписан и у тебя приватной части этого ключа ессно почему-то нету.
	Ответить | Правка | Наверх | Cообщить модератору

18. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Герострат (?), 28-Авг-23, 12:43
Оно когда-нибудь лопнет от драйверов
Ответить | Правка | Наверх | Cообщить модератору

	23. "Релиз ядра Linux 6.5"	+4 +/–
	Сообщение от Аноним (11), 28-Авг-23, 13:01
	Поддержка железа нам ненужна?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз ядра Linux 6.5"	+5 +/–
	Сообщение от Аноним (33), 28-Авг-23, 13:24
	В нормальной системе драйверы должны быть отделены от ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Аноним (41), 28-Авг-23, 13:49
	В "нормальной системе" для работы новой "нормальной системы" тебя производитель чипов для устройства, который делает драйвера для работы этих чипов в "нормальной системе", обязал тебя купить новую карту. А не нравится - сам отключишь интернет, когда тебя одним wannacryем взломают.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Релиз ядра Linux 6.5"	+/–
	Сообщение от voiceofreason (?), 29-Авг-23, 12:38
	Зато для актуального железа дрова всегда БУДУТ и как правило лучше опенсосочных. Сидеть на мамкиной шее и наяривать на свой c2d "для учёбы" - ну такое. 500$ на апгрейд раз в 5 лет это правда неподъёмно для линукс-экспертов?
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 13:35
	> Зато для актуального железа дрова всегда БУДУТ и как правило лучше опенсосочных. > Сидеть на мамкиной шее и наяривать на свой c2d "для учёбы" > - ну такое. 500$ на апгрейд раз в 5 лет это > правда неподъёмно для линукс-экспертов? линукс-эксперд просто выиграет не предусматривающий откаты тендер. На распильных объектах, каждые 5 лет по 500$ на апгрейд АРМ-ов - золотая жила руководства. А вот что делать заказчикам, бродившим по нищете?
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Релиз ядра Linux 6.5"	+/–
	Сообщение от коньюктивит (?), 29-Авг-23, 17:50
	Этим виндузятникам только дай волю, они и тёплых ватерклозетов начнут у вас требовать.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Ананимус (?), 28-Авг-23, 14:04
	> В нормальной системе драйверы должны быть отделены от ядра. Нет, не должны. Буквально единственная причина по которой они открыты сейчас это требование ядра открывать код.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	85. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 28-Авг-23, 16:17
	Ты его не правильно понял. Он прочитал статьи Эндрю Таненбаума про микроядерную архитектуру ядра, и стал адептом микроядерной архитектуры.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Релиз ядра Linux 6.5"	+/–
	Сообщение от voiceofreason (?), 29-Авг-23, 12:40
	Рекомендую посмотреть, как работают микроядерные AmigaOS 4 и MorphOS на немощном железе типа 1 ГГц single-core PowerPC. Очень хорошо мозги прочищает.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 14:27
	> Рекомендую посмотреть, как работают микроядерные AmigaOS 4 и MorphOS на немощном железе > типа 1 ГГц single-core PowerPC. Очень хорошо мозги прочищает. Где посмотреть?
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 01:32
	Под Линукс есть и закрытые драйвера. Я уже молчу о бинарных блобах в этих самых "открытых" драйверах. Так что ненужно бредить, эти вещи никак не связаны.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	224. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананимус (?), 29-Авг-23, 13:20
	> Так что ненужно бредить, эти вещи никак не связаны. Прости, какие драйверы в drivers/ закрытые? Покажи мне, пожалуйста.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 14:26
	>> Так что ненужно бредить, эти вещи никак не связаны. > Прости, какие драйверы в drivers/ закрытые? Покажи мне, пожалуйста. Я до конца не понимаю о чем вы, наверное о официальных репах линукса? Вас вот это не смущает - > Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.5 - Linux-libre 6.5-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты Вот например, инфа старая, сейчас их гораздо больше - http://manulix.wikidot.com/kernel-blobs И вы себе представляете примерно программную начинку обычного андроид телефона например? Вы серьезно думаете что за пределом оф репы линуса не существует линукс драйверов? Нвидия немного в недоумении.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Ананимус (?), 29-Авг-23, 15:08
	> Вас вот это не смущает Нет, прошивки меня не смущают. Это отдельный мир с отдельной войной с блобами. > Вы серьезно думаете что за пределом оф репы линуса не существует линукс драйверов? Я серьезно думаю что у меня ни один сервер или ляптоп за последние десять лет не содержал ни одного закрытого драйвера. И даже десктопы, после открытия драйверов amd.
	Ответить | Правка | Наверх | Cообщить модератору

	252. Скрыто модератором	+1 +/–
	Сообщение от коньюктивит (?), 29-Авг-23, 17:54
	Но ты же по существу не ответил. Так на попугайчиково-краснорубашечном ядре сидишь или на околованильном?
	Ответить | Правка | Наверх | Cообщить модератору

	269. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 30-Авг-23, 07:30
	А зачем на хамские вбросы отвечать по-существу?
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (-), 31-Авг-23, 02:25
	> Вот например, инфа старая, сейчас их гораздо больше - > http://manulix.wikidot.com/kernel-blobs О, "эксперт" по ядру от сохи^W винды совсем не палится! "Blob list for Linux v2.6.30". Ну спасибо что не 2.4. Про то что в какой-то момент блобы выпихнули из ядра в отдельный реп linux-firmware как раз чтобы с блобами бодались их авторы и кому это надо - великий эксперт не в курсе. > И вы себе представляете примерно программную начинку обычного андроид телефона например? Вы в своем праве покупать любой мусор - но Linux это именно ядро и именно майнлайновое. А частные форки каких-то левых господ в общем то их персональные инициативы. Настолько, что ни на каком другом варианте и даже версии линукса вы ЭТО прицепить не сможете. И оно умрет вместе с вашим недоразумением, соответственно. > Вы серьезно думаете что за пределом оф репы линуса не существует линукс драйверов? Для большинства практических целей их и правда не существует. Единственный для кого они существуют это крупный OEM способный это потянуть. > Нвидия немного в недоумении. После того как ей фак то показали? Заодно запретив юзать подсистемы DRM/KMS/GBM так что той самой пришлось кодить половину графической подсистемы ядра, и выходит туго, глюкаво, и с отставанием на месяцы и месяцы от майнлайна то? Ну а заодно вот и из топ500 амд ее немного подвинули. Неудобный вендор системному интегратору - не подарок ;). Как по мне пусть нвидия с своими кастомерами и е#$%тся там в своей помойке на двоих. Разработчиков линя вся эта мышиная возня вообще не касается. Вы даже баг зарепортить на майнлайн кернел не сможете такие красивые, вас в этом контексте просто не существует. Вы не клиенты этих разработчиков. Tainted kernel -> гудбай! И даже если какой каркуша отпатчит taint кернела, вас таких все равно видно как облупленых по еще десятку признаков которые забыли отпатчить. А вон там у нелоха с нвидией файлуха сыпется - модуль нвидии оперативу рушит. Как это дебажить? А вот вы там сами и изучайте этот вопрос, на двоих с нвидией. Заодно узнаете насколько крутой и эффективный у проприетарщиков саппорт и как он мастерски решит все ваши проблемы с минимумом усилий. Для референса, амдшные опенсорсные девы выкатили мне фикс на мою проблему в пределах суток. Вот можете посмотреть - смогет ли нвидия так же, или где.
	Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

	292. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 31-Авг-23, 03:32
	Какой извращённый бреб. Так изыскано.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананимус (?), 31-Авг-23, 16:53
	> Какой извращённый бреб. > Так изыскано. Ну вообще он все по делу говорит, в 6.6 только что новый забор от NVIDIA вставили.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 31-Авг-23, 18:39
	> Ну вообще он все по делу говорит, в 6.6 только что новый > забор от NVIDIA вставили. Дело у нас вот такое: >> В нормальной системе драйверы должны быть отделены от ядра. > Нет, не должны. Буквально единственная причина по которой они открыты сейчас это требование ядра открывать код. То что аноним выше пишет в контексте этого дела бред. Закрытые драйвера в Линуксе факт, как и бинарные блобы в "открытых" драйверах. Так же бред то, что Линукс не может предоставить нормальный апи для драйверов. Разборки Самсунга с Нвидией через установку DMCA на апи в свабодном коде это бред вопиющий, это абсолютно новый уровень бреда.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананимус (?), 01-Сен-23, 13:13
	> Закрытые драйвера в Линуксе факт, как и бинарные блобы в "открытых" драйверах. То что есть пара закрытых драйверов никто не отрицает. Отрицают возможность существования такого количества **открытых** драйверов от вендров в рамках не обязывающего открывать код ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 01-Сен-23, 16:21
	>> Закрытые драйвера в Линуксе факт, как и бинарные блобы в "открытых" драйверах. > То что есть пара закрытых драйверов никто не отрицает. Отрицают возможность существования > такого количества **открытых** драйверов от вендров в рамках не обязывающего открывать > код ядра. Нет никакого обязательства открывать код. И существование закрытых дров тому доказательство. Есть кривой косой недокументированный постоянно изменяющийся апи ядра. И это мягко говоря плохо, очень плохо. И есть искусственное вставляете палок в колеса. И это мягко говоря маразм и острая шизофрения.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Ананимус (?), 04-Сен-23, 11:47
	> Нет никакого обязательства открывать код. Ну это уже совсем троллинг тупизной какой-то. man GPL. > И существование закрытых дров тому доказательство. Out-of-tree? Да, их сколько-то есть. > Есть кривой косой недокументированный постоянно изменяющийся апи ядра. Внезапно всем нормально, кроме NVIDIA, которые не могут открыть код и Oracle, которые не хотят открывать Virtualbox. Ты навскидку вспомнишь ещё хотя бы десяток закрытых драйверов? > И это мягко говоря плохо, очень плохо. Кому? Пока что всем очень хорошо. Драйвер есть из коробки, вставил железку в слот и все работает.
	Ответить | Правка | К родителю #311 | Наверх | Cообщить модератору

	331. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 04-Сен-23, 13:56
	> Кому? Разработчикам дров? На каждый чих левой пятки Линуса и его хозяев переписывать всё. > Пока что всем очень хорошо. Не все мазахисты тащемто. Так что не всем.
	Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

	332. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананимус (?), 04-Сен-23, 14:25
	> Разработчикам дров? На каждый чих левой пятки Линуса и его хозяев переписывать всё. Признайся честно, ты этот ядерный API в глаза видел? Потому что чаще всего "слом API" выглядит так: - поцоны, мы тут вместо одной функции две другие принесли в наш стек, но оно и вашу подсистему тоже затрагивает - а чо? а зачем? - а вот тут и тут лучше становится - ну ок давайте смержим Все.
	Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

	317. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 03-Сен-23, 16:25
	> То что аноним выше пишет в контексте этого дела бред. > Закрытые драйвера в Линуксе факт, как и бинарные блобы в "открытых" драйверах. Они и не собирались, лолка! У нас все просто: кто не с нами - тот против нас. Это прямым текстом Торвальдс сказал. Либо комиты, либо GTFO и сами там сношайтесь как хотите. А фак можно и на чисто техническом уровне показать. Так что с пришествием еще и понятия GPU VA management + вон те подарки нвидия сейчас огребет очень приличный технический фак. Учитывая что ей это все денег стоит и отваживает кастомеров на амд - выбор за ними, конечно, но ядерщики с отсутствия нвидии совсем ничего не теряют, в отличие от нвидии у которой ломовая доля бизнеса на лине держится. И ядерщики, вот, доступно объясняют наглому корпу в понятном формате - лупя по кошельку и репутации от души ;) > Так же бред то, что Линукс не может предоставить нормальный апи для драйверов. А они видите ли тоже вам ничем таким - не обязаны. Не нравится - не пользуйтесь! Валите со своей нвидией нафих, отдачи все равно никакой а людям работы меньше. > Разборки Самсунга с Нвидией через установку DMCA на апи в свабодном коде > это бред вопиющий, это абсолютно новый уровень бреда. Я думаю что по DMCA там вся тусовочка захочет укатать, от интеля и амд до режхата и айбиэма, ключевой майнтайнер системы - редхатовский Дэйв Эйлри. И он искренне ненавидит нвидию как и все остальные создатели подсистем DRM/KMS/GBM и прочие кодеры вэйландов и проч. Если кто думает что опенсорсники дадут проприерасу навязывать апи или что-то еще - скорее ад замерзнет чем это случится. И да, они все - рьяные убежденные опенсорсники. И через эту культуру даже заклятые конкуренты выработали общие интерфейсы. В более-менее удобном им всем виде. Кроме нвидии, которая, вот, в пролете. Сама она эквиваленты DRM/KMS/GBM кодить конкретно обделалась и попыталась на кривой козе подтыривать GPL_ONLY символы в свой блоб. А им ща и объяснят как это пахнет. Вызовом в суд и DMCA, например. Амеровскому суду реально пофиг кого иметь за нарушение лицензии. Васяна за EULA от MS? Ok! Нвидию за нарушение GPL и "обход технических средств"? Тоже ок! Просто возьмут - и просто поимеют, если более культурно не доходит. А то что пришлось "технические ограничения" поставить - что поделать, гоп понимает только кулаком в лицо. Иные интерфейсы с ним не работают. Приходится дать то что гоп понимает.
	Ответить | Правка | К родителю #303 | Наверх | Cообщить модератору

	320. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 03-Сен-23, 18:06
	А очі як горять! Горять пилають червоні очі!
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 05-Сен-23, 17:23
	> А очі як горять! > Горять пилають червоні очі! Да ты не боись, там и "technical measures" - "as described in DMCA" не заржавеют, если это единственное что проприерас понимает.
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	316. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 03-Сен-23, 16:14
	>> Какой извращённый бреб. >> Так изыскано. > Ну вообще он все по делу говорит, в 6.6 только что новый > забор от NVIDIA вставили. И даже пообещали оттрахать DMCA "just in case" - вот прям статьей "обход технических ограничений". Это шикарно, я считаю. Добро должно быть с кулаками, ниипет.
	Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

	337. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 04-Сен-23, 18:30
	> И даже пообещали оттрахать DMCA "just in case" - вот прям статьей > "обход технических ограничений". Это шикарно, я считаю. Добро должно быть с > кулаками, ниипет. https://i.imgflip.com/3w2zoc.jpg
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 05-Сен-23, 17:29
	> https://i.imgflip.com/3w2zoc.jpg А вот опять видно корпорат-холуя, ссыль на сервис с клаудспайварой подогнал. Характерненько. И не, GPLщики никогда не обещали быть вам халявой которую можно иметь от и до ничего не давая взамен. И всегда оперировали именно корпорасовскими тулкитами для гасилова самих копирасов. Они не анархисты, они хакеры которые subvert'ят существующий мир служить своим целям вместо блабла про идеалы. GPL - это самоходный алгоритм вируса. Записаный как текст для людей. Но работающий. Копирасы настаивали что автор бог, может просить хоть трусы в горошек. Ну мы и попросили - правов одинаково для всех, такую же лицензию для всего, и никакого деления на master-slave. Как авторы имеем полное право, раз уж копирасы так настаивали. Так что нате-ка вам вашим же вооружением, голубчики :P
	Ответить | Правка | Наверх | Cообщить модератору

	351. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 05-Сен-23, 19:19
	Вам там это, безусловный микрокод вставили в ваш GNU Linux - https://lore.kernel.org/lkml/20230828122533.GBZOySPQIjw25NiU.../ > The first, cleanup part of the microcode loader reorg tglx has been working on. This part makes the loader core code as it is practically enabled on pretty much every baremetal machine so there's no need to have the Kconfig items. In addition, there are cleanups which prepare for future feature enablement. > no need to have the Kconfig items Так что расслабьтесь. Это кого надо бинарные блобы.
	Ответить | Правка | К родителю #343 | Наверх | Cообщить модератору

	352. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 05-Сен-23, 19:42
	> Вам там это, безусловный микрокод вставили в ваш GNU Linux Понимаешь, ты в мою систему вообще совсем ничего без моего явного желания на то не вставишь. Если я не захочу вон того - кернел просто не найдет этот файл. Загрузка продолжится, куда ж он денется. Оптимальность этой идеи на x86, учитывая дырявость дефолтного микрокода впрочем под большим вопросом. Ведь микрокод то в проце есть - что так что сяк. И который из них хуже - вообще, гуры говорят, что с именно фабричным оно спасибо если загружатся вообще, так что BIOS со своей стороны и так патчил его до чего-то более свежего, но свежесть BIOS это тоже отдельный топик и вот там апдейтить ЭТО - уже может быть чревато. > Так что расслабьтесь. Это кого надо бинарные блобы. Лоадер это одно, блоб это другое. Чтобы он вообще образовался - это к стороннему репу "linux-firmware" вообще. Куда всю блоботу и выпихнули из ядра. И с практической точки зрения x86 вообще один большой зонд со всеми его ME и PSP, если кто еще вдруг жираф и не догадался. Без блобов реально ряд армов поднять, RISCV всякие, etc. Ну там и лоадера микрокода нет почему-то. Как и микрокода. Но ты конечно хотел бы дать мне мастеркласс на тему как быть свободным. Маленькая проблемка в том что бы это не умеешь и эти потуги и ерничания выглядят жалко. Небось или макосник или бздюк какой-то если не юзер винды. А как ваши "свободы" и что вы имели предложить выглядит я усвоил. Поэтому предпочитаю более адекватных союзников.
	Ответить | Правка | К родителю #351 | Наверх | Cообщить модератору

	356. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 00:44
	Так интел это корпорасты сующие бинарные блобы, или это не корпорасты? Бинарные блобы хорошие или плохие? То что вы умеете компилировать свое ядро отключая зачем-то его свободные подсистемы я уже понял.
	Ответить | Правка | К родителю #352 | Наверх | Cообщить модератору

	364. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 06-Сен-23, 15:18
	> Так интел это корпорасты сующие бинарные блобы, или это не корпорасты? Если вы не заметили - файл микрокода в линукскернел вообще не входит. Это отдельная репа. Ортогональная сабжу. И нормальные дистро эти файлики - в отдельные пакеты кладут. Кто хочет ставит, кто не хочет не ставит. А вон то лишь про сам лоадер микрокода в проц. Про возможность отключки лоадера этого файла. А даже самые ярые адепты типа LibreLinux вырубали вообще вот имнено сам лоадер то? Чтобы микрокод в принципе нельзя было грузить ядром, хоть там что? У меня так то есть местами и гигабитные реалтеки, которым ядро хотело бы какой-то патч фирмвари догрузить. Но не находит - и работает с тем что есть. И ничо, пашет. Может мне и на этого лоадера обидеться? Чего он не опция, отключить чтоб не пиндел?! А то чего эта зараза не находит какой-то блоб? Да, я его не поставил раз все работает и я не в курсе веских причин для инсталла того пакета :). Вот с микрокодом - за последние пару месяцев такие причины появились более активно, с CVEшками то на процы. И то не все и не всегда. Ставить ли пакет с uCode что так на мое усмотрение было что сяк. > Бинарные блобы хорошие или плохие? В идеале - без них лучше. Реально - ну вон там господа с CVE на свои чудные процы и тут уже вопрос какие из угроз хуже. А так для себя - я с x86 постепенно уйду, имхо, и в идеале в пользу RISCV от дружественных к опенсорсу компаний или как минимум без явных подстав. > То что вы умеете компилировать свое ядро отключая зачем-то его свободные подсистемы > я уже понял. В данном случае если я не захочу апдейты микрокода грузить - ну ядро и не найдет их. А лоадер микрокода "как категорию" я и не собирался отключать на x86 в общем случае. Я все же ближе к прагматичным взглядам Торвальдса. Т.е. - замочить по возможности, но - без кончины от этого вместе с ними и прочего collateral.
	Ответить | Правка | К родителю #356 | Наверх | Cообщить модератору

	64. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от birdie (ok), 28-Авг-23, 15:05
	Так оно так, но это если у вас бюджеты огромные. У Линукса бюджеты не очень, поэтому вот так. И не только драйвера. Я бы ещё выкинул: arch/ fs/ sound/
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	96. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Менеджер Антона Алексеевича (?), 28-Авг-23, 16:43
	> Я бы ещё выкинул: > > arch/ > fs/ > sound/ Да и весь остальной код тоже. Деды тумблерами программировали и ничего, бороды только гуще росли.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 29-Авг-23, 04:07
	> Деды тумблерами программировали и ничего, бороды только гуще росли. Да вы и ща так можете. С JTAG даже проще стало - тумблеров всего пару штук надо. Можете натсукивать вот прям совсем побитово :)
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (-), 31-Авг-23, 02:31
	> И не только драйвера. Я бы ещё выкинул: > arch/ > fs/ > sound/ Хорошо что ты не Торвальдс и его майнтайнеры! Поэтому девелопай там какой-нибудь свой дрыщ-проект в ж@пе мира сам, а мы в сторонке посмотрим - сможет это недоразумение захватить мир как линух или нет. Ставлю на то что не сможет. p.s. а если сделать вон то - потом разработчики линя могут смело менять род деятельности, кому такая операционка вообще нужна будет?! Ее ж ни в 1 задачу не приткнешь без поддержки архитектур, файлух и чего там там. Оно скопытится быстрее чем *бсд после этого.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	306. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 01-Сен-23, 12:22
	Я так понимаю под викинуть подразумевается сделать стабильный документированный апи и вынести разработку всего этого в отдельные проекты. А не отказаться от драйверов. То что чуть ли не каждое изменение ядра требует патча кода драйверов и ФС - глупость.
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (333), 04-Сен-23, 15:40
	> Я так понимаю под викинуть подразумевается сделать стабильный документированный апи и вынести > разработку всего этого в отдельные проекты. > А не отказаться от драйверов. > То что чуть ли не каждое изменение ядра требует патча кода драйверов > и ФС - глупость. Мордочка у всяких блоборасов треснет им еще stable api чтобы вон те бесплатно ублажали их без отдачи в кернел пока они там миллиарды рубят. А остальным и так нормалек было ;). Нет, ребятки, виндочки но халявной - вам тут не обломится. Даже не надейтесь. И если то не заметил - майкрософт с их stable api во первых апи так то тоже периодически перетряхивает, потому что иначе система все ж совсем загнется. А чтоб держать дровописак в узде еще и подписи на все требует. И вот что что а дровописаки никогда не будут никому свою волю диктовать. И линуксоиды уж точно не лохастее майкрософта чтобы прогибаться под всякуюф некооперативную шваль. Те намного лучше DMCA takedown понимают как аргумент. Почему бы и не дать его собственно, если это единственное что доходит. Эти люди и проекты никогда не намеревались бесплатно ублажать проприетарщиков без отдачи. Кто не понял - тому популярно объяснят. В отличие от чистой идеологии тут прагматики, так что вместо увещевания - бить будут жестко, на результат, по самым болючим местам. Бишь кошельку и репутации.
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 04-Сен-23, 18:15
	В чём конкретно вклад производителя железа в вакууме в ядро состоит? Если нужно что-то в самом ядре править так жпл обязывает (!!открывать свой код а НЕ слать патчи!!), да, и это хорошо, хотя не то чтобы производителю сетевых карт допустим в страшном сне снится как он свою особую ОС выпускает для своей железки. А драйвера то нахрена конкретно вот заставлять !!искусскуственными!! палками в колеса в ядро пихать? Кому от этого хорошо? Из за этого не таким огромным как Интел или нвидия производителям приходится выпускать свои версии линукса со своими патчами. Потому что они во первых не в состоянии всё это изменение апи отслеживать и патчить. А во вторых, ты ещё попробуй свой открытый код в открытый Линукс отправить, если ты не золотой спонсор то хрен тебе. А у вас острый диаритический синдром борцуна за свободу корпораций Линукс иметь.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (-), 05-Сен-23, 20:19
	> В чём конкретно вклад производителя железа в вакууме в ядро состоит? В дровах. И совместной работе над подсистемами которые такой тип драйверов реюзает. В случае конкретно видеокарт это будут (довольно крутые и годные) подсистемы DRM, KMS, GBM, а теперь еще VA management для вулкана. Эти куски в первом приближении можно сделать общими для всех и вместо изобретения велика - реюзать на всю толпу. Что они и делают всей толпенью, даже если и конкуренты, это им всем сокращает объем работ. И вот так они получают моральное право проталкивать изменения в подсистемы учитывающие их. Это все равно отбалансируется с другими. В хучшем случае не получится сделать реюзабельным и будет жить в дереве драйвера. Нвидия не часть всего этого - зато смела лезть с "давайте сделаем менеджер памяти GPU вместо GBM с учетом нас", или "а запилите для нас EGL" - что конечно не нашло понимания у ALL. И им таким красивым сделали GPL_ONLY на вон те подсистемы. А когда они попробовали на кривой козе "gpl condom", господа, вот, оформили теперь это все так - что нвидии придется обойти технические ограничения. Попав под свой любимый DMCA. Которым ей и укатают без ложной скромности, если вдруг. Кодеры тех подсистем совсем не хотят упрощать жизнь некооперативному вендору который контрибутить не хочет и вместо этого пытается на кривой козе лицензию обойти. Я с этим чертовски солидарен - eParasite'ы заслуживают дуст, а вовсе не... > Если нужно что-то в самом ядре править так жпл обязывает (!!открывать свой > код а НЕ слать патчи!!), да, и это хорошо, хотя не > то чтобы производителю сетевых карт допустим в страшном сне снится как > он свою особую ОС выпускает для своей железки. Не хотят - не комитят. Линух не будет эту железку поддерживать из коробки. Кому хуже будет - вопрос интересный, учитывая парк серверов на оном. А вот если они удумают блобы сватать, отправятся вслед за нвидией. Тоже половина подсистем станет неюзабельной и тоже придется половину функций ядра кодить самим. Потому что там тоже врядли кто хотел иметь дело с некооперативными м...ками. Видите ли, когда "core" технологий размазывается на всех и каждый понемногу доводит до ума это одно. А когда работу воротят одни а паразитируют на этом какие-то жлобы которые вообще делиться не хотят - соблазн посыпать их дустом сильно выше среднего. И всем похрен какие там операционки кто хочет делать. Это о совместной работе над проектом и подсистемой, а подачки с лопаты и без майнтенанса там никому не интересны. Эту позицию майнтайнеров и торвальдса никто никогда и не скрывал, много лет к ряду. Это такой прагматичный и довольно жесткий взгляд на GPL как инструмент для стимулирования развития системы. И это работает. > А драйвера то нахрена конкретно вот заставлять !!искусскуственными!! палками в колеса в > ядро пихать? Потому что eParasites заслуживают разве что eDust. Они ничего не привносят в линукс и только подгружают других работой от которой в плюсе только нвидия. За это их терпеть там не могут - и совсем не прочь люлей в панамку насыпать. Никаких преимуществ от деятельности нвидии линукс как система - и его разработчики - не получают! А вот гимор и бесполезняшек качаюших права - вполне. Если это все пропадет, разработчики линуха вообще скорее в плюсе. Минус порция головняка и проприетарного хамья, а комитов и денег сколько было столько и есть, с вон тех полезностей для линукса было ровно ноль. > Кому от этого хорошо? Как минимум разработчикам, которые с превеликим удовольствием скинули задолбавший балласт за борт. А чисто по человечески еще и приятно спрыснуть дустом офигевшего халявщика который ухватил работы толпы людей, показал им фигу самым наглым образом из возможных, и теперь чему-то смеет удивляться? А они видите ли тоже могут фигу то показать. Да еще и поэффективнее. А вот пусть нвидия сама и кодит DRM/KMS/GBM/VA management. Ох, получается глюкало и они отстают на месяцы и месяцы? Так что начинают подтыривать функции ядра левыми воркэрааааундами? А вот вам "технические ограничения" тогда, дорогая нвидия. И DMCA. Все как вы любите. И я думаю они, как видные секурбутчики-DRMщики, отлично в курсе что бывает за "обход технических ограничений". А теперь это шоу - специально для НИХ. Ах, они не думали что в эти щи они сами попадут? Ну надо же. А тогда может, treat others the way you want to be treated стоило и к себе таким суперценным применять? А то вот - отзеркалили 1 в 1 по сути. За все. За зажатые сорцы. За отсутствие спеков. За цифровые подписи на фирмвари - при отсутствии оных. Нвидия поставила немало палок в чужие колеса. Почему бы им не ощутить свои методы на СЕБЕ?! > Из за этого не таким огромным как Интел или нвидия производителям приходится > выпускать свои версии линукса со своими патчами. Вот отлично, чем им больше траха - тем прикольнее. Они вон как нуву нагибали и саботировали, пусть свои подходы на себе потестят. Они вообще заслуживают чтобы линукс наглухо заблеклистил их железо и дрова. С описанием "unsupported hardware". Посмотреть как они вообще будут вон тот бизнес на миллиарды вести после этого. > Потому что они во первых не в состоянии всё это изменение апи > отслеживать и патчить. Так это же замечательно. Значит это им ударит по кошельку и репутации. А вот так уже даже паскудные проприетарщики понимают. И Торвальдс и ко что угодно но не лохи. И знают как отспорить свое. Да-да, если вы пользуетесь их работами и возомнили что можно миллиардный бизнес вести - и даже патчи не прислать, у них могут быть немного иные идеи на этот счет. У прямо вообще всей иерархии, от Торвальдса до мелких майнтайнеров вспомогаловки вокруг подсистем. Вы же понимаете что девелопать линух первым делом идут те кому эти парадигмы вполне по вкусу? :) > А во вторых, ты ещё попробуй свой открытый код в открытый Линукс > отправить, если ты не золотой спонсор то хрен тебе. Да ващет они нормальные господа вполне. Я проверял. Если им кто дельные патчи шлет - они не отбиваются. И баги сообща загасить - весьма круто и кайфово. Но для этого надо понимать их процессы и систему ценностей. С своим уставом в чужой монастырь не ходят. А кто не понял - тому объяснят. И весьма доходчиво, если так надо. > А у вас острый диаритический синдром борцуна за свободу корпораций Линукс иметь. У меня... я их форматы попробовал, проникся, и - отлично этих людей понимаю. Это как раз нормальный процесс разработки. С самоуважением. Отказом быть вторым сортом, сливным бачком и мусоркой. С желанием равных прав. Заботой о развитии проекта, включая рефактор подсистем и оформление shared фич совместными усилиями вместо дублирования кода. А кто стоит на этом пути - я ему сочувствую. Он будет аннигилирован мощной высокотехнологичной силой объединенных умов. Которые озаботятся вопросом "как вам надрать зад" и достигнут в этом определенных успехов. Они всегда достигают успехов. Работает это так.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (166), 28-Авг-23, 22:08
	нереально у ядра нет стабильного внутреннего API
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	186. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (186), 29-Авг-23, 03:25
	А и не нужно. Достаточно вынести драйверы из ядра и сделать стабильный внешний API для взаимодействия с ними. Лет 30 как реализовано в полноценных операционках, даже в полуоси такое было.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от vitalif (ok), 29-Авг-23, 14:19
	и где та полуось?
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (34), 28-Авг-23, 13:41
	Надеюсь, ко времени смерти линукса хурд наконец-то допилят.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	74. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (74), 28-Авг-23, 15:48
	Надейся. Хотя, хурд уже допилили до полной неработоспособности на железе, но нет предела совершенству.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (98), 28-Авг-23, 15:53
	Кстати, команда Шишкина могла бы помочь с передовыми ФС. Там бы код приняли. А то в Hurd есть только нежурналируемая Ext2FS.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	97. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Менеджер Антона Алексеевича (?), 28-Авг-23, 16:44
	Им некогда, они ещё ResiserFS не допилили.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (98), 28-Авг-23, 17:02
	ReiserFS, та, которая v3, в линуксовом ядре работает давно и успешно.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Менеджер Антона Алексеевича (?), 28-Авг-23, 17:25
	И не менее успешно теряет данные на диске. Может подскаешь, в каких крупных деплоях, скажем, от тысячи ядер, используется ReiserFS?
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (187), 29-Авг-23, 03:54
	> ReiserFS, та, которая v3, в линуксовом ядре работает давно и успешно. "F...k you ReiserFS!" (c) amule.org. Дадада, вот такой testimonial от довольных пользователей. За вот именно разнесенный в вермишель их чудным fsck том. И вообще - оно scheduled for removal, потому что на перевод на новые апи ядра забили и никто не майнтайнит код. Если не найдется желающего окультурить этот битрот, он скоро вылетит из сабжа. Шышкин и ко вместо этого предпочитают выкатывать полурабочие рейзер4 а потом и 5 - видимо чтобы показать как файлухи для ядра девелопать не надо.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	200. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Авг-23, 07:25
	Одна надежда на Ганса Рэйзера, как только он выйдет он всех построит.
	Ответить | Правка | Наверх | Cообщить модератору

	262. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Авг-23, 01:32
	> Одна надежда на Ганса Рэйзера, как только он выйдет он всех построит. Что-то это сомнительно, я лучше буду надеяться на то что у кента оверстрита все получится и он комитнет свое нечто в майнлайн. А Ганс Рейзер придумал вести датарекавери бизнес. Не то чтобы это само по себе чем-то плохо но вот от разработчика файлухи это вызывает вопросы. Так понятнее почему вынос тома в лапшу fsck-ом это "known issue" а на "urgent fix". Портить себе же бизнес наверное не очень хочется.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Аноним (121), 28-Авг-23, 17:54
	Шишкин занимается файловой системой Рейзера как математик теоретик. Он не трудяга инженер. Он отказался сопровождать в ядре файловую систему Рейзера.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	139. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (34), 28-Авг-23, 18:59
	Надо сперва что-нибудь более стабильное, вроде ext4 или xfs. Рейзер5 как идея неплох, но насчёт его текущей стабильности ситуация не вполне ясна.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	120. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от gdg (??), 28-Авг-23, 17:48
	Хурд ненужон, потому что есть DragonflyBSD.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	123. Скрыто модератором	+/–
	Сообщение от Аноним (123), 28-Авг-23, 18:02
	Hurd для Свободивцев, а БЗДа для пермиссивщиков. Умей различать.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (34), 28-Авг-23, 19:00
	Миру бздюков можно позавидовать, столько разных бздей. А у сторонников копилефта из юзабельных систем есть только линух.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	142. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Менеджер Антона Алексеевича (?), 28-Авг-23, 19:09
	Ровно на одну юзабельную систему больше, чем в мире бздюков. Я считаю, это победа.
	Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз ядра Linux 6.5"	+2 +/–
Сообщение от Шарп (ok), 28-Авг-23, 12:54
>Включена сборка ядра с опцией компилятора "-fstrict-flex-arrays=3", включающей третий уровень проверки гибкого элемента-массива в структурах (Flexible Array Members, массив неопределённого размера в конце структуры). А первые два уровня оказались неспособны обнаружить все утечки и выходы за границы массива, которые понаписали профессиональные сишники?
Ответить | Правка | Наверх | Cообщить модератору

	127. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 28-Авг-23, 18:16
	Мне вот сильно интересно, что-нибудь похожее в rust'е есть? Это не отдельная выделяемая память, а объект соответствующий конкретной структуре может быть разного размера. Весь вопрос в оптимизации выделения-освобождения памяти и проверок прав доступа.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 04:06
	Нет там никакого объекта. Сишка просто выделяет кусок памяти, и мапит его через структуру. Вам ещё и самому нужно рассчитать какой кусок выделять учитывая все заголовочные поля. Я прикола не понимаю.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 29-Авг-23, 10:50
	Это как раз и есть эмуляция наследования в ООП. Базовая структура на основе которой могут быть унаследованные.
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 04-Сен-23, 18:26
	> Это как раз и есть эмуляция наследования в ООП. Базовая структура на > основе которой могут быть унаследованные. В ООП нет наследования. Оно есть в системе типов Страуструпа. И это страшное зло. А эмулировать это чудо такими замысловатыми методами это отдельный ад для разработки и отладки.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 05-Сен-23, 12:31
	> В ООП нет наследования. Оно есть в системе типов Страуструпа. > И это страшное зло. Это твое личное мнение, мало относящееся к реальности. > А эмулировать это чудо такими замысловатыми методами это отдельный ад для разработки и отладки. Да. Это тяжко. Но вот конкретно в ядре - приходится это делать. В других местах - не знаю. Так разные структуры данных, имеющие своей базой одну легко укладываются в контейнеры. И алгоритмы работающие с этими контейнерами удобно и легко разрабатывать. Ну и главная причина - скорость. Как я уже говорил, выделение памяти за один раз и проверка доступа одинаковая для всех полей.
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 05-Сен-23, 17:08
	Это мнение создателя ООП.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 05-Сен-23, 17:46
	> Это мнение создателя ООП. И? Это должно о чем то сказать? Даже если кто-то приложил к чему-то руку первым, это не дает ему права быть арбитром или судьёй. В данном случае, значительное множество программ разрабатываются используя наработки определённой теории. В случае с ядром - это приводит к удобству разработки и выигрышу в скорости. И совершенно не важно мнение кого-либо. Вон, Таненбаум про микроядерность втирал. Ну и?
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 05-Сен-23, 18:49
	Если говорить о наследовании, то в индустрии существует огромная и обоснованная критика сего подхода. Вкратце, это приводит к множеству проблем как функциональных так и связанных с поддержкой кода, и нарушает глобально инкапсуляцию. Поэтому люди в своём уме ограничивают наследование наследованием интерфейсов. А для изменения поведения объектов существует dependency inversion principle.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 05-Сен-23, 18:54
	Ну и? Вот вообще причем тут это? У наследования есть преимущества. И они используются во всю. Ты хочешь доказать что это неправильно?
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 05-Сен-23, 18:57
	> Ну и? Б. > Вот вообще причем тут это? Что где когда? > У наследования есть преимущества. И они используются во всю. Ты хочешь доказать > что это неправильно? Преимущества перед чем и какие, расскажите пожалуйста.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 05-Сен-23, 19:02
	> Преимущества перед чем и какие, расскажите пожалуйста. Пример: При реализации наследования не интерфейсов а данных в ядре дает скорость выполняемому коду.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 00:39
	>> Преимущества перед чем и какие, расскажите пожалуйста. > Пример: > При реализации наследования не интерфейсов а данных в ядре дает скорость выполняемому > коду. Что такое "наследование данных"? Пример кода можете показать? Вы уверенны что ООП имеет к этому вообще хоть какое-то отношение?
	Ответить | Правка | Наверх | Cообщить модератору

	361. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Серб (ok), 06-Сен-23, 14:29
	> Что такое "наследование данных"? Разговор окончен.
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

	347. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 05-Сен-23, 18:55
	> И? > Это должно о чем то сказать? Должно. > Даже если кто-то приложил к чему-то руку первым, это не дает ему > права быть арбитром или судьёй. Не делает. Но мнение такого человека, консультирующего индустрию сегодня, стоит брать в расчет. Тем более в сравнении с не аргументированным мнением анонима. > В данном случае, значительное множество программ разрабатываются используя наработки определённой теории. В ООП типа джава/С++ мизер теории, если она там вообще есть, заблуждения предрассудки и итеративный дизайн устанавливающий новые костыли на плохой изначальный дизайн без оглядки на разумность прошлых решений, уровня - ООП очень удобно потому что автодополнение после того как я точечку жамкнул мне члены класса показывает.
	Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

	350. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Серб (ok), 05-Сен-23, 19:09
	> Должно. Почему? Я должен преклонятся перед авторитетами? >> Даже если кто-то приложил к чему-то руку первым, это не дает ему >> права быть арбитром или судьёй. > Не делает. > Но мнение такого человека, консультирующего индустрию сегодня, стоит брать в расчет. > Тем более в сравнении с не аргументированным мнением анонима. Вот и бери. Мнение анонима не учитывай. На сложившуюся практику разработки множества проектов забей. Живи в своей нише в своем окружении. >> В данном случае, значительное множество программ разрабатываются используя наработки определённой теории. > В ООП типа джава/С++ мизер теории, если она там вообще есть, заблуждения > предрассудки и итеративный дизайн устанавливающий новые костыли на плохой изначальный > дизайн без оглядки на разумность прошлых решений, уровня - ООП очень > удобно потому что автодополнение после того как я точечку жамкнул мне > члены класса показывает. Очевидно же они все ошибаются, а вот ты и те, к кому ты прислушиваешься нет. Пусть они и дальше ошибаются. А ты разрабатывай свое. Ядро к твоему не относится.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноньимъ (ok), 06-Сен-23, 00:35
	> Почему? Я должен преклонятся перед авторитетами? У вас промежуточных стадий между "это туфта" и "я должен преклоняться" в отношении образованных умных и опытных людей нет? Либо бяка либо няка? По моему вы просто демонстрируете неуважение к интеллекту.
	Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Аноним (36), 28-Авг-23, 13:42
>Добавлена возможность монтирования другой ФС слоем ниже в существующую точку монтирования pivot_root больше не нужен, как и и initramfs?
Ответить | Правка | Наверх | Cообщить модератору

	45. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 28-Авг-23, 14:04
	pivot_root и initramfs и сейчас не нужен. Но без них менее гибок и элегантен для большинства применений А вот сабж из новости позволяет лишь более элегантно жить без ненужно, и не является какой-то уникальной фичей (смотрите ссылку в тексте новости на оригинал, кейсы возможного применения хорошо расписаны)
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (98), 28-Авг-23, 16:51
	Подскажи, как корень на LVM2 подключить без initramfs?
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 28-Авг-23, 22:48
	> Подскажи, как корень на LVM2 подключить без initramfs? Советую читаль дальше первого предложения: >> Но без них менее гибок и элегантен для большинства применений Кейс с LVM2 входит в большинство применений, а потому лучше использовать initramfs Если не хотите initramfs, можете содержимое initramfs разместить на ином блочном устройстве с файловой системой и после начальной инициализации сделать pivot_root на root с LVM2 Можно сделать BSD-style, обьявить что "корень на LVM2" является эталонным ненужно и самостоятельно накостылять функционал, требующийся от LVM2, на других технологиях
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 29-Авг-23, 07:36
	> Можно сделать BSD-style, обьявить что "корень на LVM2" является эталонным ненужно и > самостоятельно накостылять функционал, требующийся от LVM2, на других технологиях Зачем нам LVM при наличии ZFS?
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 13:01
	>> Можно сделать BSD-style, обьявить что "корень на LVM2" является эталонным ненужно и >> самостоятельно накостылять функционал, требующийся от LVM2, на других технологиях > Зачем нам LVM при наличии ZFS? Ну вот когда писал о BSD-style, как раз и подразумевал под >> на других технологиях как раз btrfs. Но в виду недостаточных компетенций, уточнять не стал Вроде на этом форуме (или хабре), была мысль от одного из великих (пох?), что выбор технологии сроден взятию вещи в кредит. И есть разница, взять в кредит велосипед (LVM2) или феррари (ZFS). Одно дело, когда уже есть собственные деньги на феррари (компетенции по ZFS), другое, когда надо отдавать кредить за прогоревший бизнес (т.е. в виду отсутствия компетенций восстанавливать небекапленные данные). И тут лучше восстанавливать с LVM2, чем с ZFS или btrfs (помним, что компетенции слабоваты)
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 30-Авг-23, 14:06
	> Ну вот когда писал о BSD-style, как раз и подразумевал под >>> на других технологиях > как раз btrfs. Но в виду недостаточных компетенций, уточнять не стал btrfs это косплей ZFS в линуксе, в BSD её нет. > Вроде на этом форуме (или хабре), была мысль от одного из великих > (пох?), что выбор технологии сроден взятию вещи в кредит. И есть > разница, взять в кредит велосипед (LVM2) или феррари (ZFS). Одно дело, > когда уже есть собственные деньги на феррари (компетенции по ZFS), другое, > когда надо отдавать кредить за прогоревший бизнес (т.е. в виду отсутствия > компетенций восстанавливать небекапленные данные). И тут лучше восстанавливать с LVM2, > чем с ZFS или btrfs (помним, что компетенции слабоваты) Вероятность вытащить небитые данные с ZFS выше чем с LVM.
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 30-Авг-23, 19:14
	>> в BSD её нет Я говорил не о BSD, а о BSD-style решения задач: >> обьявить что N является эталонным ненужно и самостоятельно накостылять функционал, требующийся от N, на других технологиях как стандартную аргументацию поклонников BSD-систем на утверждение, что в BSD чего-то нет присутствующего в Linux >> Вероятность вытащить небитые данные с ZFS выше чем с LVM В сферрическом вакууме вы правы Мне надо было так написать? > ПОМНИМ, ЧТО КОМПЕТЕНЦИИ СЛАБОВАТЫ!!!!1111 За вменяемое время с битого харда с файловой системой, превратившейся в кашу, или в следствие  выполненного до конца rm -rf /home в кривом скрипте при благоприятном положении луны можно вытянуть с ext4 (немного помучиться если LVM не сильно фичасто настроенный). С xfs уже почти не реально что-то вытащить. Я тут заметил, что обычно ответ не читают дальше первого предложения. Приятно дискутировать с человеком, прочитавшим твой комментарий полностью. Но я как-то думал, необходимо оставаться в контексте темы породишвей подветку обсуждения, которая заключается в: >>> Подскажи, как корень на LVM2 подключить без initramfs? Человеку не нужно ZFS, btrfs etc. Не нужно ему предлагать купить кирпич или слона
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 31-Авг-23, 10:27
	> Я говорил не о BSD, а о BSD-style решения задач: > обьявить что N является эталонным ненужно и самостоятельно накостылять функционал, требующийся от N, на других технологиях Это не BSD-style, это NIH-style.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 31-Авг-23, 18:43
	> Это не BSD-style, это NIH-style. NIH-style как раз присущ linux экосистеме, btrfs как ответ zfs, snap как ответ flatpack BSD-style же это например обьявить ненужным k8s или тот же snap и утверждать, что это все можно сделать на jail Для NIH же нужно доступное работающее решение уже сейчас, чего у BSD-атлетов спецсоревнований обычно не наблюдается
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (366), 06-Сен-23, 15:48
	>> Это не BSD-style, это NIH-style. > NIH-style как раз присущ linux экосистеме, btrfs как ответ zfs, А в чем собственно проблема когда некто видя технологию но не у себя - начинает задумываться что можно как-то так же и у себя, да еще вот тут улучшить. ZFS видите ли лицензией не вышел и слишком переклинен на 1 конкретном кейсе - энтерпрайзные хранилки. А если это не оно - упс, "этанинужна!!!111" (с) мегаодмины соляры и ко. > snap как ответ flatpack Они оба линуксные. > BSD-style же это например обьявить ненужным k8s или тот же snap и > утверждать, что это все можно сделать на jail И в результате остаться с голой джеппой и вылететь из продакшнов... > Для NIH же нужно доступное работающее решение уже сейчас, чего у BSD-атлетов > спецсоревнований обычно не наблюдается А как же куча видов BSD для начала?
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (288), 31-Авг-23, 02:50
	> btrfs это косплей ZFS в линуксе, в BSD её нет. Линукс не мусорница для технологий отработавших свое. ZFS мало на что годен кроме энтерпрайзных файлопомоек. Btrfs вполне универсальная штука - даже на роутере с 64 мегами оперативы цепляется без напрягов. Такой вот косплей. > Вероятность вытащить небитые данные с ZFS выше чем с LVM. Мммда? А что вы делаете если оно замаунтиться не сизволило?
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

	296. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 31-Авг-23, 10:39
	>> btrfs это косплей ZFS в линуксе, в BSD её нет. > Линукс не мусорница для технологий отработавших свое. ZFS мало на что годен > кроме энтерпрайзных файлопомоек. Btrfs вполне универсальная штука - даже на роутере > с 64 мегами оперативы цепляется без напрягов. Такой вот косплей. Ога-ога. btrfs это косплей технологий реализованных в ZFS, причём косплей местами кривой. Зачем на роутере COW FS. >> Вероятность вытащить небитые данные с ZFS выше чем с LVM. > Мммда? А что вы делаете если оно замаунтиться не сизволило? У меня есть секретный бубен. 😎
	Ответить | Правка | Наверх | Cообщить модератору

	319. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 03-Сен-23, 17:26
	>> кроме энтерпрайзных файлопомоек. Btrfs вполне универсальная штука - даже на роутере >> с 64 мегами оперативы цепляется без напрягов. Такой вот косплей. > Ога-ога. btrfs это косплей технологий реализованных в ZFS, причём косплей местами кривой. А местами - весьма радикально усовершенствованный и улучшенный. Управление местом в RAID куда как приятнее, снапшоты логичнее сделаны, рефлинки сто лет уж есть (вроде, говорят кой-как прикрутили вроде наконец и в zfs, как минимум линуксовой). А, да, апей для всяких вещей типа рефлинков в стандартах как обычно не было. Так что линуксоиды конечно свелосипедили - но должен же кто-то двигать прогресс вперед?! Та же ерунда и с hole punching и много чем еще. Если кивать на только существующие стандарты и отсутствие в них фич, далеко не уедешь. > Зачем на роутере COW FS. Затем же зачем и везде. 1) Удобное управление местом. 2) Снапшоты, рефлинки. Это круто, быстро, эффективно. А на хилой системе круть и эффективность нужнее всего. 3) Чексумы наконец - гнилые кабели, устройства и питальники будут запалены. А не так что втихаря все загадится. 4) Сжатие, все дела. В том числе и довольно быстрое. > У меня есть секретный бубен. 😎 А у меня вот есть вполне документированная офлайн-читалка умеющая пробовать деревья с разных generation, несколько суперов, возможность маунта с более старых деревьев, ... и мне это как-то больше доверия внушает. Да и девы вон там зарекомендовали себя компетентными и эффективными. Интереснее этого дизайна может быть получится разве что у Кента. Если он сможет что хотел - покажет как делать nextgen nextgen'а. А ZFS на этом фоне будет чем-то типа мамонта. Чисто структурально и на уровне менеджмента.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 04-Сен-23, 08:18
	> А местами - весьма радикально усовершенствованный и улучшенный. RAID 5|6 в btrfs уже допили до продакшена? А аналог raidz3? А новый draid? >> Зачем на роутере COW FS. > Затем же зачем и везде. 🤦‍♂️ Ты точно знаешь зачем нужен роутер? >> У меня есть секретный бубен. 😎 > А у меня вот есть вполне документированная офлайн-читалка умеющая пробовать деревья с Рад за тебя. Мне хватало штатных средств. > Интереснее этого дизайна может > быть получится разве что у Кента. Если он сможет что хотел > - покажет как делать nextgen nextgen'а. А ZFS на этом фоне > будет чем-то типа мамонта. Чисто структурально и на уровне менеджмента. Шишкин тоже хотел показать как надо.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (334), 04-Сен-23, 15:53
	> RAID 5|6 в btrfs уже допили до продакшена? Примерно 50/50. В Raid5 таки write hole более-менее заткнули. В Raid6 еще не до конца. К тому же метаданные могут быть в другой схеме - и это спасает от ряда траблов. В мануале все написано. > А аналог raidz3? > А новый draid? Аналог чего либо из zfs в btrfs - упаси меня от ЭТОГО. У btrfs намного более крутое управление этим всем, а "аналогами" пусть zfs'ники наслаждаются. В btrfs для начала можно просто прицепить "вот этот винч". И получить +эн места. Без выравниваний, эн девайсов и проч. Когда zfs что-то такое сможет, пусть и вякает про аналоги. > Ты точно знаешь зачем нужен роутер? Для меня это лишь +1 компьютер, всегда включеный, всегда онлайн, поэтому удобный для всяких сетевых сервисов. В том числе и логичная точка раздачи филезов по сети до кучи. Но конечно можно и 19" стойку дома поставить, с некоторых станется. Я не спорю что у некоторых это даже осмысленно выходит, как у Ларабеля. Но вы на Ларабеля не похожи. > Рад за тебя. > Мне хватало штатных средств. Которые состоят - например - в чем? Не то чтобы мне та читалка сильно требовалась но как практикующий data recovery для других - я таки приветствую такой подход к делу. А не так что вон, дескать, коммерческих тулсов еще докупите. Под винду. Ух, круто, отличный системный менеджмент. Всю жизнь мечтал о таком. >> - покажет как делать nextgen nextgen'а. А ZFS на этом фоне >> будет чем-то типа мамонта. Чисто структурально и на уровне менеджмента. > Шишкин тоже хотел показать как надо. Но нишмог, распугав всю команду. А один в поле не воин. Особенно в файлухах. Да еще высунув нос в реальный мир проникся и пошел переделывать 4 -> 5 а вы тем временем там как-нибудь перекантуйтесь, "в пути кормить никто и не обещал". Так что неубедительно получилось. Кент убедительней, он по крайней мере юзает что накодил для себя, у него более 0 желающих комитить, он нашел язык с майнтайнерами, хоть и со скрипом, до 20 терабайт без развалов - отрастил. И даже кой-какие тесты практикует. Так что имеет определенные шансы в реальном мире. Шишкин же живет в башне из слоновой кости и какие-то внятные перспективы его проекта не просматриваются.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 06-Сен-23, 13:12
	>> RAID 5|6 в btrfs уже допили до продакшена? > Примерно 50/50. >> А аналог raidz3? >> А новый draid? > Аналог чего либо из zfs в btrfs - упаси меня от ЭТОГО. >> Ты точно знаешь зачем нужен роутер? > Для меня это лишь +1 компьютер Ясно, админ локалхоста.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (366), 06-Сен-23, 15:52
	>>> Ты точно знаешь зачем нужен роутер? >> Для меня это лишь +1 компьютер > Ясно, админ локалхоста. Ну я как бы уже на примере гражданина поха увидел к чему приводит чрезмерный фап на энтерпрайз, когда ты сам без мегакорпа - ноль без палочки. Что-то мне такое же светлое будущее на свою бошку вообще не хочется. А еще хочется чтобы технологии с которыми я имею дело работали для меня. Не "где-то там" - а вообще везде. Так, по жизни. Где0то там - сидя с голой жо вот тут - мне не интересно, сорянчик. И я буду обоими руками за масштабируемые технологии, соответственно. ..а вон те, пафосные, энтерпрайзные, уже и не знают куда деваться, вон на виндочку тыкаются. Успех их юниксэя как он есть.
	Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

	371. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 06-Сен-23, 20:48
	>[оверквотинг удален] > Ну я как бы уже на примере гражданина поха увидел к чему > приводит чрезмерный фап на энтерпрайз, когда ты сам без мегакорпа - > ноль без палочки. Что-то мне такое же светлое будущее на свою > бошку вообще не хочется. А еще хочется чтобы технологии с которыми > я имею дело работали для меня. Не "где-то там" - а > вообще везде. Так, по жизни. Где0то там - сидя с голой > жо вот тут - мне не интересно, сорянчик. И я буду > обоими руками за масштабируемые технологии, соответственно. > ..а вон те, пафосные, энтерпрайзные, уже и не знают куда деваться, вон > на виндочку тыкаются. Успех их юниксэя как он есть. Не хочу тебя разочаровывать, но эти самые масштабируемые технологии двигает мегакорп.
	Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

	377. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 07-Сен-23, 12:56
	>> ..а вон те, пафосные, энтерпрайзные, уже и не знают куда деваться, вон >> на виндочку тыкаются. Успех их юниксэя как он есть. > Не хочу тебя разочаровывать, но эти самые масштабируемые технологии двигает мегакорп. Видишь ли, чудик, мой friend or foe identification работает по значительно более сложным алгоримтам чем у примитивных существ бросающихся на абстрактные лейблы без учета деталей как бык на красную тряпку. Я анализирую общее состояние дел и как оно согласуется с моими пожеланиями на тему того как я бы хотел видеть вон то и вот это. В этом контексте, friend - тот кто помогает достичь этого. Foe тот кто мешает, соответственно. И конечно оценка вероятности с учетом предысторий, трендов и косвенных индикаторов, дабы не получать внезапный ножик в спину. Отсюда следует что у меня есть место для взаимодействия с мегакорпами, и допускается мысль что мои задачи и пожелания могут в ряде мест (а возможно много где) неслабо совпасть с мегакорпми. Напрочь уникальных кейсов - не так уж много. А вопрос сводится к форматам, деталям и отношениям. Как пример: многое в моем управлении систем навеяно технологиями которые практикуют энтерпрайзы, когда я не оперирую инсталлерами по часу, деплоя образа, а факапы разруливаются снапшотами, или рероллом vm/контейнера из снапшота. Просто потому что это эффективно. А то что некоторые вообще не смогли в этот уровень технологий - их проблемы. Я никогда не вернусь на окучивание локалхостов часами с убиением времени ни на что, и мне пофиг насколько это не тепло и не лампово для вас. И так далее. Туда же типов с двойными стандартами вещающих за юниксвэй из виндов: если для вас ваши вэи не сработали, с вами нечего обсуждать.
	Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

	378. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 07-Сен-23, 14:59
	>[оверквотинг удален] > и отношениям. > Как пример: многое в моем управлении систем навеяно технологиями которые практикуют энтерпрайзы, > когда я не оперирую инсталлерами по часу, деплоя образа, а факапы > разруливаются снапшотами, или рероллом vm/контейнера из снапшота. Просто потому что это > эффективно. А то что некоторые вообще не смогли в этот уровень > технологий - их проблемы. Я никогда не вернусь на окучивание локалхостов > часами с убиением времени ни на что, и мне пофиг насколько > это не тепло и не лампово для вас. И так далее. > Туда же типов с двойными стандартами вещающих за юниксвэй из виндов: > если для вас ваши вэи не сработали, с вами нечего обсуждать. Правильно, что может обсуждать админ энтерпрайза с админом локалхоста. 😎
	Ответить | Правка | К родителю #377 | Наверх | Cообщить модератору

	387. Скрыто модератором	+/–
	Сообщение от Аноним (-), 12-Сен-23, 01:49
	> Правильно, что может обсуждать админ энтерпрайза с админом локалхоста. 😎 Как дырку от бублика не назови а дыркой от бублика и останется. Ты без твоего энтерпрайза и корпов - нихрена. А мне такой расклад не нравится. Быть взаимозаменимым винтиком у каких-то п-сов мне как-то так себе.
	Ответить | Правка | К родителю #378 | Наверх | Cообщить модератору

	388. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (388), 17-Сен-23, 12:47
	> Правильно, что может обсуждать админ энтерпрайза с админом локалхоста. 😎 Поскольку энтерпрайзные BSDшники давно доBSDелись уже и повылетели отовсюду - ну вы сами все сказали. И никакой ZFS им не поможет, только усугубит скорее. То что они своим ходом даже и так не смогли - тем хуже для них. А линуксоидам вон кентушка сейчас bcachefs закомитит. Вот это - будущее. А ваши окаменелые ошметки выброшенные дохлокорпом - удачи закладываться на это, но имхо вы будете коллегой с сэром похом. Вечно недовольные, ненавидящие свою работу, а дома вообще с голой ж, вообще виндочку нахваливающие. Фу такими быть, как по мне. Ваше будущее - отвратительно и ваши концепции неработоспособны. В отличие от линуха.
	Ответить | Правка | К родителю #378 | Наверх | Cообщить модератору

	389. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 18-Сен-23, 21:38
	>[оверквотинг удален] > Поскольку энтерпрайзные BSDшники давно доBSDелись уже и повылетели отовсюду - ну вы > сами все сказали. И никакой ZFS им не поможет, только усугубит > скорее. То что они своим ходом даже и так не смогли > - тем хуже для них. А линуксоидам вон кентушка сейчас bcachefs > закомитит. Вот это - будущее. А ваши окаменелые ошметки выброшенные дохлокорпом > - удачи закладываться на это, но имхо вы будете коллегой с > сэром похом. Вечно недовольные, ненавидящие свою работу, а дома вообще с > голой ж, вообще виндочку нахваливающие. Фу такими быть, как по мне. > Ваше будущее - отвратительно и ваши концепции неработоспособны. В отличие от > линуха. 😂👏 Ещё немного, ещё чуть-чуть… и вот-вот наступит будущее файлух линукса. Где-то я уже это слышал… ах да, это же по btrfs говорили.
	Ответить | Правка | К родителю #388 | Наверх | Cообщить модератору

	392. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (392), 18-Сен-23, 22:53
	> 😂👏 Стремительно скатываешься на уровень поняши, но это тебе не поможет. > Ещё немного, ещё чуть-чуть… и вот-вот наступит будущее файлух линукса. > Где-то я уже это слышал… ах да, это же по btrfs говорили. Если сравнить сколько линуха юзают и сколько бсдей - будущее уже давным давно наступило. В том числе и благодаря тому что в бсдах с файлухами знатный швах. И если по пальцам топтаться как вы, как там, ZFS у вас уже не улетает в панику ядра потому что на этом аж нжинкс запустили? А если еще и перфоманс этого захотеть... эээ... ну да, вот этот утюг и блеснет RPS'ами то. Где-то на внизу. А если это все не нравится, там у вас чего еще есть, UFS целый? Эпическое предложение. Так что тему про энтерпрайзных админов нехило бы развить. Что за админы с бсд и зфс и в каком "энтерпрайзе" это есть? Потому что чего-то отдаленно напоминающего энтерпрайз осталось пару мест и вы врядли именно в LLNL или Netflix работаете.
	Ответить | Правка | К родителю #389 | Наверх | Cообщить модератору

	393. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 19-Сен-23, 13:51
	> Если сравнить сколько линуха юзают и сколько бсдей - будущее уже давным > давно наступило. В том числе и благодаря тому что в бсдах > с файлухами знатный швах. Во FreeBSD всё хорошо с ФС. Они не ждут коммита очередного чуда ФС-о строения, которое вот-вот будет готово к локалхосту. > И если по пальцам топтаться как вы, как там, ZFS у вас > уже не улетает в панику ядра потому что на этом аж В панику улетает Линукс. На Проксе это воспроизводится с тех пор как туда ZFS вкорячили. На FreeBSD ZFS стабильно работает 10+ лет. А на Solaris ещё дольше. > нжинкс запустили? А если еще и перфоманс этого захотеть... эээ... ну > да, вот этот утюг и блеснет RPS'ами то. Где-то на внизу. При создании ZFS производительность не была главной целью инженеров Sun. Однако, лет этак 5+ тому назад на Хайлоаде представитель какой-то стриминговой платформы (не Нетфликс) рассказывал как они отдают потоки в 10-40 Гбит с ZFS. > А если это все не нравится, там у вас чего еще > есть, UFS целый? Эпическое предложение. А вот тут ты сел в лужу. Netflix как раз использует UFS. > Так что тему про энтерпрайзных админов нехило бы развить. Что за админы > с бсд и зфс и в каком "энтерпрайзе" это есть? Потому Если тебе конкретно о FreeBSD+ZFS, то можешь поинтересоваться у iXsystems. А полный список тут https://www.freebsd.org/commercial/ > что чего-то отдаленно напоминающего энтерпрайз осталось пару мест и вы врядли > именно в LLNL или Netflix работаете. В нашем энтерпрайзе есть всё: Windows, Solaris, Linux, FreeBSD и даже OpenVMS. Хранилок на FreeBSD нет, но есть девайсы от NetApp. Конкретно я использую Solaris для отделовской файлопомойки.
	Ответить | Правка | К родителю #392 | Наверх | Cообщить модератору

	287. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (288), 31-Авг-23, 02:44
	> (пох?), что выбор технологии сроден взятию вещи в кредит. И есть > разница, взять в кредит велосипед (LVM2) или феррари (ZFS). Одно дело, > когда уже есть собственные деньги на феррари (компетенции по ZFS), другое, > когда надо отдавать кредить за прогоревший бизнес (т.е. в виду отсутствия > компетенций восстанавливать небекапленные данные). Ну во первых, бизнес намного лучше когда он не прогоревший. И сразу ориентироваться на прогорание это какой-то совсем уж фэйловый миндсет. Во вторых... > И тут лучше восстанавливать с LVM2, чем с ZFS или btrfs (помним, что компетенции слабоваты) Вот это довольно спорное утверждение. Btrfs если он не маунтится можно во первых попытаться зацепить с альтернативными (более старыми) деревьями, копиями суперблока и проч. И если факап случился недавно, есть нехилый шанс что это еще и прокатит. Во вторых, снапшоты неплохо помогают от допустим неудачно вбитого rm который / или его существенную часть вынес. В третьих если ну вообще ничего не прокатило у btrfs в ее утилсу встроена офлайн-читалка типа того что для нтфс в коммерческом софте бывает, которая умеет сама парсить ФС без монтирования и скидывать найденое файло на другой носитель без монтирования. Там можно потыкаться по разным generation и нащупать относительно работающую точку входа. Поскольку это CoW - это мультивселенная, где более старые состояния уничтожаются не сразу. И шанс что что-то из этого зацепится и распарсится - вполне себе. И это будет таки оно, может в чуть устаревшем виде зато с автоматическим парсингом и вычитыванием этого. А вот что вы с более другими файлухами да еще и LVM при этом делать будете - а вот кто вас там знает. Заодно и покажете мастеркласс как раз. Если сможете.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	308. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 01-Сен-23, 14:14
	>> А вот что вы с более другими файлухами да еще и LVM при этом делать будете - а вот кто вас там знает. Восстановим из проверенных бэкапов, которые уже есть в связи с наличием увлекательного опыта по восстановлению данных. >> Заодно и покажете мастеркласс как раз. Если сможете Да, для не критичных небекапленных данных лежит виртуалка с установленными _кощунственными_ _коммерческими_ решениями r-studio и ufs explorer. Потому, что опыт, релевантный на момент 3-4 года назад, показал, что свободно доступные решения не позволяют получить результат, лучше массовых коммерческих решений, а результат лучших (по моему скромному мнению) из них (r-studio и ufs explorer) вообще не достижим. Возможно, на текущий момент, действительно встроенная в btrfs-utils офлайн читалка рвет лучших коммерческих представителей для fat, ntfs, ext2-4 + LVM2(только LV) или появилось _качественое_ коммерческое решение по восстановлению данных с btrfs Только вот меня беспокоит ваша антиаргументация: 1. > Ну во первых, бизнес намного лучше когда он не прогоревший. У вас точно имеется увлекательный опыт восстановления данных? Оно то понятно, что быть богатым и здоровым намного лучше, чем бедным и больным 2. > И сразу ориентироваться на прогорание это какой-то совсем уж фэйловый миндсет да, есть люди которые не делают бекапы, и я их прекрасно понимаю: нафиг упаднические настроения и фэйловый миндсет, я буду жить вечно, ведь, пока что, все идет по плану К тому же, действительно, часто данные не так уж и важны, и на длинном промежутке времени суммарные усилия по их бекапу будут превышать усилия по маловероятному восстановлению данных 3. > Поскольку это CoW - это мультивселенная, где более старые состояния уничтожаются не сразу... Но механизмы, вроде CoW, dedup, сжатие - только увеличивают область повреждения _данных_. ---------------------------------------- К тому же у нас разногласия по термину данные. Вы в данные по видимому включаете также метаданные файловой системы. btrfs действительно имеет множество механизмов для сохранности и восстановления метаданных. И у LVM есть множество недостатков относительно btrfs, которые приведут к потере метаданных - можно наворотить вложенных LVM, тонких снимков так, что будет аналогично или хуже, чем в btrfs (относительно восстановления _данных_). - по умолчанию LVM не хранит несколько копий своих метаданных - сложннее настройка, где неосторожным движением кривых рук можно все поломать К тому же, как вы понимаете слабые компетенции (о которых я специально упомянул)? Доступно ли слабым компетенциям: > попытаться зацепить с альтернативными (более старыми) деревьями, копиями суперблока и проч. > потыкаться по разным generation и нащупать относительно работающую точку входа. Я, для слабых компетенций, максимум допускаю > у btrfs в ее утилсу встроена офлайн-читалка типа того что для нтфс в коммерческом софте бывает, которая _умеет сама_ парсить ФС без монтирования и скидывать найденое файло на другой носитель При этом команда для ее запуска будет скопирована из какого-то форума, без внятного понимания, что она сейчас будет делать. А понимание структур данных файловой системы и методов их хранения и распределения в них не входит
	Ответить | Правка | Наверх | Cообщить модератору

	309. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 01-Сен-23, 14:41
	>> А вот что вы с более другими файлухами да еще и LVM при этом делать будете - а вот кто вас там знает. Восстановим из проверенных бэкапов, которые уже есть в связи с наличием увлекательного опыта по восстановлению данных. >> Заодно и покажете мастеркласс как раз. Если сможете Да, для не критичных небекапленных данных лежит виртуалка с установленными _кощунственными_ _коммерческими_ решениями r-studio и ufs explorer. Потому, что опыт, релевантный на момент 3-4 года назад, показал, что свободно доступные решения не позволяют получить результат, лучше массовых коммерческих решений, а результат лучших (по моему скромному мнению) из них (r-studio и ufs explorer) вообще не достижим. Возможно, на текущий момент, действительно встроенная в btrfs-utils офлайн читалка рвет лучших коммерческих представителей для fat, ntfs, ext2-4 + LVM2(только LV) или появилось _качественое_ коммерческое решение по восстановлению данных с btrfs Только вот меня беспокоит ваша антиаргументация: 1. > Ну во первых, бизнес намного лучше когда он не прогоревший. У вас точно имеется увлекательный опыт восстановления данных? Оно то понятно, что быть богатым и здоровым намного лучше, чем бедным и больным 2. > И сразу ориентироваться на прогорание это какой-то совсем уж фэйловый миндсет да, есть люди которые не делают бекапы, и я их прекрасно понимаю: нафиг упаднические настроения и фэйловый миндсет, я буду жить вечно, ведь, пока что, все идет по плану К тому же, действительно, часто данные не так уж и важны, и на длинном промежутке времени суммарные усилия по их бекапу будут превышать усилия по маловероятному восстановлению данных 3. > Поскольку это CoW - это мультивселенная, где более старые состояния уничтожаются не сразу... Но механизмы, вроде CoW, dedup, сжатие - только увеличивают область повреждения _данных_. ---------------------------------------- К тому же у нас разногласия по термину данные. Вы в данные по видимому включаете также метаданные файловой системы. btrfs действительно имеет множество механизмов для сохранности и восстановления метаданных. И у LVM есть множество недостатков относительно btrfs, которые приведут к потере метаданных - можно наворотить вложенных LVM, тонких снимков так, что будет аналогично или хуже, чем в btrfs (относительно восстановления _данных_). - по умолчанию LVM не хранит несколько копий своих метаданных - сложннее настройка, где неосторожным движением кривых рук можно все поломать К тому же, как вы понимаете слабые компетенции (о которых я специально упомянул)? Доступно ли слабым компетенциям: > попытаться зацепить с альтернативными (более старыми) деревьями, копиями суперблока и проч. > потыкаться по разным generation и нащупать относительно работающую точку входа. Я, для слабых компетенций, максимум допускаю > у btrfs в ее утилсу встроена офлайн-читалка типа того что для нтфс в коммерческом софте бывает, которая _умеет сама_ парсить ФС без монтирования и скидывать найденое файло на другой носитель При этом команда для ее запуска будет скопирована из какого-то форума, без внятного понимания, что она сейчас будет делать. А понимание структур данных файловой системы и методов их хранения и распределения в них не входит
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

	321. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 03-Сен-23, 19:06
	> Восстановим из проверенных бэкапов, которые уже есть в связи с наличием увлекательного > опыта по восстановлению данных. Рояль в кустах это отлично, но во первых это не достоинство файлухи и решения. Во вторых, существование дата рекавери лаб и цены на их услуги как бы намекают что это работает не для всех и не всегда. "Теоретически, Петька, мы с тобой миллионеры...". Так что запасной план не такая уж плохая идея. Как и ряд фич ФС на такие случаи, типа аж 3 копий суперов в очень разных логических смещениях. Или склонность ФС юзать DUP или RAID1 на метаданных, что сильно повышает их шансы при отклонении от идеала. Без метаданных все гораздо печальнее, сами понимаете. >>> Заодно и покажете мастеркласс как раз. Если сможете > Да, для не критичных небекапленных данных лежит виртуалка с установленными _кощунственными_ > _коммерческими_ решениями r-studio Это все может и является достоинством r-studio но уж точно не достоинство решения и штатных тулсов файлухи. Соответственно о чем мы говорим? О том что можно развестись на бабки в польщу виндовых комерсов? Предпочту чтобы мои бабки получали более дружественные чем ЭТО персонажи. >  и ufs explorer. Это то-то покупает? Интересно на...я? Я бы такой ФС пользоваться не стал даже если б мне доплатили за это. На данный момент это просто мамонты. > Потому, что опыт, релевантный на момент 3-4 года назад, показал, что свободно > доступные решения не позволяют получить результат, лучше массовых коммерческих > решений, а результат лучших (по моему скромному мнению) из них (r-studio и > ufs explorer) вообще не достижим. Хызы, я народу доставал "почти все" даже с основательно ушатанных дисков, откровенно сыпящихся. В лине есть вполне приличные туслы для отстройки образов, а WHDD так еще и через команды умеет работать в обход интерфейсов ядра. Ну а я умею в системную механику, более-менее понимаю как это все работает и знаю основные DOS и DONTS. А потом ... потом вот знаете ли гибкость btrfs очень крута, когда и стораж можно под разовую задачу отрастить до небес, а закончив действо можно и вынуть из него девайсы. И рефлинки очень рулят, когда у меня штук пять чушек по якобы эн терабайта каждая, с прогрессивным восстанвлением/фиксом и возможностью передумать/откатить это все если лажа вышла, при том что суммарный жор места "копий" лишь чуть более 1 образа. Итеративненько то потусоваться в образах без ломовых требований к месту и быстро - вполне. > Возможно, на текущий момент, действительно встроенная в btrfs-utils офлайн читалка рвет > лучших коммерческих представителей для fat, ntfs, ext2-4 + LVM2(только LV) или > появилось _качественое_ коммерческое решение по восстановлению данных с btrfs По крайней мере мне очень импонирует когда разработчики ФС сразу в тулкит кладут такие вещи вместо того чтобы делать рожу кирпичом что это не их проблемы. И в дизайн файлухи закладывают ряд вещей чтобы там были шансы потрепыхаться даже в заковыристых случаях. Ну вот например на эмбедовке часто только 1 девайс. А штучный бэд под libc - жутко обидный сценарий. Потому что разэмбедовать одноплатник где-то в ж... дорого, долго и гиморно может быть. Btrfs на это можно с схемой DUP разложить. Он и скажет - csum failed .... corrected, а природа CoW такова что это все и к ремапу довольно дружественно. Т.е. эти данные более не нужны - и туда можно запись сделать. Накопитель сможет ремап без потерь вообще. Даже если сектор и не читался. Конечно можно LVM похожего франкенштейна скроить, но опять же - без чексум мы не узнаем какая копия правильная. И все становится сложно. А в btrfs это 1 командой делается. Можно даже в рантайм решения переиграть. Быстро, просто, ненапряжно. >> Ну во первых, бизнес намного лучше когда он не прогоревший. > У вас точно имеется увлекательный опыт восстановления данных? Иначе я бы имхо вообше не знал про вещицы типа whdd ;). Самым интересным (и опасным) было ремотно, по ssh вот это самое сделать. Крайне не рекомендуется к повторению, вы наверное и сами понимаете почему. Но иногда выбора просто нет. Даже прокатило, хоть и пришлось понервничать. > Оно то понятно, что быть богатым и здоровым намного лучше, чем бедным и больным А я таки делал датарекавери эн линуксоидам, а до кучи и нескольким маздайцам с NTFS. Благо в FUSE или ntfs драйвере линя парсинг более другой и на этом можно сыграть. А в тяжких случаях testdisk и phororec даже с совсем убитого нечто много чего достают без кивания на фс вообще. А потом я вот как-то корябнул забавные скриптики, посмотрев что юниксвэй может предложить. Ну, например, может DCIM/ юзеру вернуть из трухи в нормальном виде - "достав" имена файлов из... тегов файлов, спасибо камерам за это, сделал из гамна и палок анализатор, он за 10 минут не только имена вернул но и по годам по папкам раскидал. Ну и да - я свои лимиты знаю, всякий перелив фирмварей/служебок/etc конечно к профи уже. Но там и цены и времянки другие будут. > да, есть люди которые не делают бекапы, и я их прекрасно понимаю: Вы как бы имеете определенный пойнт. И все же... > нафиг упаднические настроения и фэйловый миндсет, я буду жить вечно, ведь, > пока что, все идет по плану Лучший бэкап - который никогда не понадобился. А то я разок на почтовую базу отхреначил старый бэкап. А более нового и не было. Ну и продолбал мегов 200 почты. Обидно было. На самом деле назначением лоханулся, должно было в альтернативное пойти, чтобы вынуть вооон то. А попало в исходное - и это был фэйл. А поскольку тогда я магию снапшотов и cow не практиковал еще, оно in-place базы перетерло, и вот это - таки облом! Конечно кому было что-то сильно надо - письма перепослали еще разок, но... снапшоты не замена бэкапов. А бэкапы не замена снапшотов. > К тому же, действительно, часто данные не так уж и важны, > и на длинном промежутке времени суммарные усилия по их бекапу будут превышать > усилия по маловероятному восстановлению данных Самое странное во всей этой истории то что я достаточно хорошо понимаю как это работать и попадаю "в десятку". Т.е. рекавери обычно очень близок к 100% плюс-минус то что вынесено бэдами или дестроем невосстановимо. Ну т.е. я в курсе как правильно строить образа, итеративным чтением, и в лине для этого тулсы есть, а потом итеративно догоняю образ до кондиции. И btrfs в этом оказался полезен. >  Но механизмы, вроде CoW, dedup, сжатие - только увеличивают область повреждения _данных_. Когда как. А возможность сунуться в разные состояния - пока их GC не подгреб - повышает шанс что хоть одно из - прокатит. Тогда таки распарсится на автомате. И все сильно проще. В обычной ФС все хуже - если куска метаданных нет, его уж нет. И мы идем медленно и печально юзать testdisk+photorec. Оно, конечно, зачастую катит, и даже очень здорово, но, времени требует дочерта а имен файлов можно и не получить, раз уж метаданных вон там нету. > К тому же у нас разногласия по термину данные. Вы в данные > по видимому включаете также метаданные файловой системы. До некоторой степени. Там 1) размеры, имена. 2) В случае btrfs мелкие файлы. Так что такой взгляд на вещи имеет определенные причины. > btrfs действительно имеет множество механизмов для сохранности и восстановления метаданных. Btrfs примерно одинаково трактует блоки данных и метаданных. Это забавно но там нет глобальных отличий. Что так chunks с энной схемой, что так. Специфичный дизайн деревьев позволяет ему cow'ать и данные, и метаданные, в конце концов это одна и та же механика ворочает. Схемы хранения могут быть разные (очевидно что выживание метаданных критичнее, из соображений масштаба урона, а т.к. они не очень большие, DUP или RAID1 можно позволить для них много где). Более того - могут быть чанки с типом хранения отличным от того что ща юзают данные и метаданные. Как продукт "частичной конверсии схемы" или "новой дефолтной схемы хранения". Сам по себе этот дизайн мог бы назначать разные схемы хранения разным файлам если бы кто-то логику решений аллокатору накодил. Кроме всего прочего он в результате прекрасно переживает крах при конверсии схемы райда. Просто продолжает конвертить формат чанков дальше после перезагрузки. Попробуйте так вообще с вашим LVM, кули. > И у LVM есть множество недостатков относительно btrfs, которые приведут к потере > метаданных У него 1 ключевой недостаток: В ВОПРОСАХ МЕНЕДЖМЕНТА ЭТО - БРЕЙФНФАК. В btrfs я просто добавлю или выну девайс. Увеличу или убавлю ФС. Сменю схему хранения. И проч. Нонстоп. А еще вот снапшот ОС и хомяка на случай фэйлов. И если мне апгрейд системы не понравился, вот моя машина времени. Которая на минималках заводится аж из grub, указанием другого назначения монтирования. Это менеджмент систем XXI века. А вон то - #$%ный стыд и миндфак. И именно по этой причине bcachefs тоже следует этим паттернам дизайна. В отличие от такпривыкших дино кентушка в состоянии понять что так рулить ФС и ОС намного круче и неизмеримо эффективнее. Это как пересесть с кукурузника на небольшой звездолет с гипердвигателем и машиной времени. Вместо десятков циферблатиков и дергания ручек - указываешь назначение - опа - уже там. Да, если аллоцировано 100 мегов из 10Тб - ворочать будет 100 мегов. И тайминги операции будут - вот такие. > - можно наворотить вложенных LVM, тонких снимков так, что будет аналогично или > хуже, чем в btrfs (относительно восстановления _данных_). Моя основная претензия ко всему этому - в том что оно многократно сложнее по уровню менеджмента прежде всего. Интегрированный с машиной времени и гипердрайвом звездолет навигирует в 4 измерениях нативно, совершенно прозрачно гоняя между разными вариантами развития событий и не делая мозг. Кукурузник для этого не сохдавался. И попытка сделать что-то такое на нем - весьма болезненный экспериенс. > - по умолчанию LVM не хранит несколько копий своих метаданных > - сложннее настройка, где неосторожным движением кривых рук можно все поломать Имерно поэтому его место там же где ipsec когда уже есть wireguard :). Именно поэтому кент дизайнит свой некстген так как дизайнит. Мир никогда уже не будет прежним. И я не буду скучать по вон тому жуткому трешу. Вообще совсем. > К тому же, как вы понимаете слабые компетенции (о которых я специально упомянул)? > Доступно ли слабым компетенциям: 1) Слабые компетенции всегда будут искать помощь сильных. 2) Меня прежде всего волнуют мои проблемы, а я наверное скорее уже взял средний уровень или выше среднего. 3) Для знакомых и друзей я обеспечиваю некий саппорт на минималках как респект технологии и "спасибо" ее создателям. А вот LVM пусть его фанаты трахаются. И его уродливые недо-снапшоты тоже для них. А чтоб еще чексумы там были? И починить фэйлящую копию из исправной? В btrfs оно само это сделает. А в LVM что-то такое добиться - убьешься нахрен. Поэтому у меня на одноплатниках btrfs с схемой DUP. Прозрачно. Просто. Минимум допущений и мануальщина. А таки переживает редкие единичные бэды. Под хоть чем. Ему не важно данные там или метаданные, если схемой хранения и тем и другим DUP сделан. Так теорвер намного лучше. Если бэд раз в месяц, какая вероятность что две разные копии получат бэд одновременно? И вот так теорвер намного лучше ощущается. А с LVM вы его так в свою сторону вообще осилите крутануть? Поэтому у меня оно будет работать до последнего. А вы можете если хотите разэмбедовывать и бэкапы накатывать, объясняя кастомеру что нагибон его техпроцессов которыми эта штука рулила - ничего так, нормально. У меня на этот счет иные идеи как-то. Лучший data recovery это тот который делать не пришлось. > Я, для слабых компетенций, максимум допускаю >> у btrfs в ее утилсу встроена офлайн-читалка типа того что для нтфс в коммерческом >> софте бывает, которая _умеет сама_ парсить ФС без монтирования и скидывать >> найденое файло на другой носитель Слабым компетенциям лучше всего 1) RTFM 2) прийти к девам. Они подскажут что и как в нетривиальных случаях. Или если не получается, 3) нанять кого-то или дать денег кому-то кто не настолько лох и таки решит системные аспекты нормально. По этой причине интеграторы и образовались как направление. > При этом команда для ее запуска будет скопирована из какого-то форума, без > внятного понимания, что она сейчас будет делать. Если кто-то решил включить режим идиота на своих данных, занявшись тем чем не умеет, чтож, все уважающие себя эксперты по восстановлению данных не забудут вкатить поправочный коэффициент на самодеятельность. Но вон та читалка, если что, подразумевает чтение на ДРУГОЕ назначение - с немонтированой файлухи. Поэтому записать что-то на оригинал и попортить его сильнее таки у казуала врядли получится вообще. Так что если он смолчит в тряпочку - даже избежит вон той участи. Потому что оригинал не пострадает. > А понимание структур данных файловой системы и методов их хранения и распределения > в них не входит Ну как бы в случае btrfs лучше основные концепции понять. Пилотирование звездолета с машиной времени и гипердрайвом подразумевает что вы таки в курсе азов этих концепций и не будете охреневать от альтернативных таймлайнов, параллельных историй развития событий и даже ОК с перспективой встретить "почти самого себя, но чуть другого". Со временем мир становится сложнее, а концепции CoW и альтернативных реальностей, размеров дельт и проч - актуальны и для допустим виртуализаторов. Без понимания этого вы и снапшотами в VM осмысленно ворочать не сможете. И компетенция оказывается уже не низкой - а пробивающей дно по современным меркам, когда вы и виртуализаторы нормально юзать тоже не умеете. Первыми кто всерьез полюбил CoW, снапщоты и проч - были они. А теперь так и на железе вот можно. Но если кто смотрел sci-fi, он давно понимает как это работает. Это именно оно.
	Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз ядра Linux 6.5"	+6 +/–
Сообщение от Минона (ok), 28-Авг-23, 14:31
Столько ФС наплодили, а ни одну до ума не довели.
Ответить | Правка | Наверх | Cообщить модератору

	71. Скрыто модератором	+4 +/–
	Сообщение от Аноним (-), 28-Авг-23, 15:41
	Вот Рейзер выйдет из тюрьмы и всем покажет как надо делать файловые системы!
	Ответить | Правка | Наверх | Cообщить модератору

	91. Скрыто модератором	–1 +/–
	Сообщение от Аноним (91), 28-Авг-23, 16:36
	Десантис не станет помиловать жёноубийцу, продемонстрировавшего неуважение к государству в виде попыток водит суд и следствие за нос.
	Ответить | Правка | Наверх | Cообщить модератору

	198. Скрыто модератором	+/–
	Сообщение от Минона (ok), 29-Авг-23, 07:22
	> Вот Рейзер выйдет из тюрьмы и всем покажет как надо делать файловые > системы! Шишкин пытался, а воз и ныне там.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	79. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от birdie (ok), 28-Авг-23, 15:57
	ext4 обслуживает без проблем больше 2 миллиардов устройств. Что такое "до ума"?
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	177. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Anon3 (?), 28-Авг-23, 23:11
	> ext4 обслуживает без проблем больше 2 миллиардов устройств. > Что такое "до ума"? КакВВенде старых версий. При установке Linux необходимо производить сеанс внушения (по другому "до ума" не доходит, отсутствует критическое мышление): ext4 новая уникальная инновационная файловая система С ней ваши файлы будут блестящими и шелковистыми и все в таком духе
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Admino (ok), 29-Авг-23, 05:45
	В винде старых версий была FAT32. Спасибо, не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 30-Авг-23, 01:39
	> КакВВенде старых версий. Это типа имена 8.3, где более длинные уже за счастье и лимит в 4..32 гига на диск? Не говоря о том что скорость работы фата с большой иерархией это просто позор. Да и у нтфс не сильно лучше, если с нормальными ФС сравнивать. Представляете, btrfs спокойно своротит 250К файлов на вон той иерархии. Допустим компил ядра. А если с такой иерархией в винде работать удумать все будет медленно и печально. С клином на холодную чуть не минуты, перфомансом в РАЗЫ хуже и все такое прочее. > При установке Linux необходимо производить сеанс внушения Я померял - в линухе один и тот же проект собрался почти втрое быстрее. На этом сеанс внушения и завершился, я как раз и переехал на линух. А что я МакЛауд втрое дольше билдовки туповэйтить?
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	201. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Минона (ok), 29-Авг-23, 07:25
	> ext4 обслуживает без проблем больше 2 миллиардов устройств. А точно без проблем?
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	101. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Фанат (?), 28-Авг-23, 16:55
	Деньги платят за исправления.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	220. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от voiceofreason (?), 29-Авг-23, 12:43
	Ext4 довольно стабильная, XFS тоже. Но вот как NTFS, чтобы не теряла данные при отключении компа из розетки - это в линуксе недоступная роскошь.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	223. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 13:17
	> это в линуксе недоступная роскошь. Используйте опцию монтирования sync. По крайней мере 10 лет назад, когда меня эта NTFS волновала, при отключении компа из розетки NTFS могла полностью поломаться
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (288), 31-Авг-23, 02:51
	> Столько ФС наплодили, а ни одну до ума не довели. А у кого-то с этим лучше? В винде античный тормоз NTFS да недоделаный ReFS. В бсдах вообще полный швах. Ну и равняться предлагается - на кого?
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	297. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 31-Авг-23, 10:44
	>> Столько ФС наплодили, а ни одну до ума не довели. > А у кого-то с этим лучше? В винде античный тормоз NTFS да > недоделаный ReFS. В бсдах вообще полный швах. Ну и равняться предлагается > - на кого? Сразу видно знатока ФС. 😏
	Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз ядра Linux 6.5"	+/–
Сообщение от InuYasha (??), 28-Авг-23, 14:34
Ни про NTFS, ни про ExFAT новостей нет. Жаль.
Ответить | Правка | Наверх | Cообщить модератору

	59. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от birdie (ok), 28-Авг-23, 14:57
	NTFS3 до кучи фиксов: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... В exfat минимум - там уже нечего фиксить: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Релиз ядра Linux 6.5"	+/–
	Сообщение от InuYasha (??), 30-Авг-23, 10:05
	Спасибо
	Ответить | Правка | Наверх | Cообщить модератору

	72. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 28-Авг-23, 15:42
	А зачем вам огрызки вантуза?
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

58. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Аноним (98), 28-Авг-23, 14:57
Ткните плз, в какой версии ядра Торвальдс вернул прокрутку консоли?
Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз ядра Linux 6.5"	+/–
	Сообщение от birdie (ok), 28-Авг-23, 14:58
	Ни в какой. Patches are welcome.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (98), 28-Авг-23, 15:16
	Была новость, в т.ч. на Оеннет, не могу найти.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (99), 28-Авг-23, 16:49
	Новости нет, потому что никто ничего не возвращал. У вас галлюцинации.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (112), 28-Авг-23, 17:16
	Это было в соседней временной линии. Оставайтесь на месте, наши специалисты уже выехали за вами.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	322. "Релиз ядра Linux 6.5"	+/–
	Сообщение от 4D NAV (?), 03-Сен-23, 19:11
	> Это было в соседней временной линии. Оставайтесь на месте, наши специалисты уже > выехали за вами. Добро пожаловать в навигацию по 4-мерному пространству. Оставайтесь на линии, сейчас мы снашот с вами откатим - и все снова будет зашибись.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (122), 28-Авг-23, 17:59
	>Была новость, в т.ч. на Оеннет, не могу найти. Тоже смутно помню. Общались по этому поводу.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	154. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (31), 28-Авг-23, 20:26
	Дальше разговоров дело не зашло по-моему. Дичь, как по мне.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (381), 08-Сен-23, 18:53
	Эффект Манделы?
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	178. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 28-Авг-23, 23:21
	> Ткните плз, в какой версии ядра Торвальдс вернул прокрутку консоли? Use Screen Luke
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	204. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 29-Авг-23, 07:38
	>> Ткните плз, в какой версии ядра Торвальдс вернул прокрутку консоли? > Use Screen Luke скрин не кошерно. Use tmux Luke.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 10:48
	Запустите tmux в initramfs для прокрутки консоли, чтобы посмотреть лог загрузки во время загрузки. Что, неполучается? То-то же Нравится tmux, не забывайте, что без screen тоже не обойдетесь, если есть потребность в аналоге ядерной прокрутки консоли
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (225), 29-Авг-23, 13:23
	Чтобы посмотреть лог загрузки - Use % journalctl --no-hostname -x -b | grep -i -n 'systemd\[1\]' Luke
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 17:41
	> Чтобы посмотреть лог загрузки - Use > % journalctl --no-hostname -x -b | grep -i -n 'systemd\[1\]' > Luke Так загрузка зависла в бесконечность на plumouth и systemd не выдал отладочную консоль. > journalctl... Может и journald еще не запустился, чтобы с dmesg-a слить себе лог загрузки ядра, а plumouth не нравится что-то в ядре, а ядру что-то не нравится, но не посмотреть потому что скрола ядерного нет
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 30-Авг-23, 01:42
	> Так загрузка зависла в бесконечность на plumouth и systemd не выдал отладочную консоль. Ну так сказать ему счерез командлайн ядра чтоб отвалил. В смысле plymouth'у конечно. > Может и journald еще не запустился, чтобы с dmesg-a слить себе лог > загрузки ядра, а plumouth не нравится что-то в ядре, а ядру > что-то не нравится, но не посмотреть потому что скрола ядерного нет Ну знаете у меня как-то и PCI не взлетал. От такого только вывод в UART и помогает (откуда я и узнал что это PCI). Представляете, видяха на невзлетевшем PCI - "почему-то" недоступна.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Anon3 (?), 30-Авг-23, 10:24
	> Ну так сказать ему счерез командлайн ядра чтоб отвалил. В смысле plymouth'у конечно. А можно просто: use 'screen', Luke. Тогда не надо выполнять перезагрузку и можно, с некоторыми удобствами, наживую выполнить отладку plymouth'а, и всего того, что будет после > Ну знаете у меня как-то и PCI не взлетал Если следовать вашей логике, то в вашем случае надо было не на UART выводить, а просто выпить водки. Разговор был о ядерном скроле и применении костыля в связи с его отсутствием
	Ответить | Правка | Наверх | Cообщить модератору

	290. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 31-Авг-23, 03:12
	> А можно просто: use 'screen', Luke. Тогда не надо выполнять перезагрузку Тем не менее, если что-то пошло не так, гарантий что "screen" будет работать примерно столько же сколько и для всего остального. А вот например снапшот btrfs с системой в чуть более раннем виде где все еще было ЗБС можно даже grub зацепить, с минимумом допущений. Шансы что grub сработает заметно выше чем шансы что сработает цепочка типа (grub, kernel, initrd, куч алиб/прог/скриптов и только потом за ними - screen). До того как система screen вообще сможет запустить - много чего может пойти не так. И в этом смысле как last resort для изучения совсем не стартанувшей системы может пригодиться вообще init=/bin/bash - и даже это может обломаться если были повреждены системные либы, например. > и можно, с некоторыми удобствами, наживую выполнить отладку plymouth'а, и всего того, > что будет после Мсье знает толк в извращениях :) > Если следовать вашей логике, то в вашем случае надо было не на UART выводить, Вообще, много где именно именно на UART и выводят. По дефолту. Потому что ядро умеет поднимать уарты очень рано ("early console"), это требует абсолютный минимум инита железа, и можно зацепить все это к более живой системе и посмотреть WTF. Так что шансы увидеть что-то осмысленное даже при жестком затыке, даже в самом начале - сильно возрастают. Если разуть глаза можно будет найти десятки железок у себя под боком с линухом, где, прицепив сериальный шнурок можно будет увидеть именно ЭТО. А когда проблема понята можно с ней уже прицельно разобраться. А если до взлета screen дело не дошло, что вы вообще делаете? :) > а просто выпить водки. Это еще почему? > Разговор был о ядерном скроле и применении костыля в связи с его отсутствием Ну вот в случае uart - можно смотреть вывод на другой системе, в любом удобном софте, и даже в файло залогить и разработчикам скинуть. Это конечно требует второй ноут или комп и немного подколючки проводов и возможно трансляции уровней, но COM на десктопах обычно до сих пор есть как гребенка на мамке, видимо в том числе и поэтому. А если и этого не хватило - останется только жытаг. Потому что если ядро не подало признаков жизни после инита железа - ну, до вашего скрина дело не дойдет. В упомянутом примере, если у вас не взлетел pci, то клавиатуру на вон том usb вы тоже не получаете, потому что usb контроллер на pci был. Так что скроллить вы ничего и никуда не сможете чисто технически. А поскольку видяхи на ее PCIe тоже нет - то и увидеть наскролленое вы тоже не сможете. И соответственно рецепт спасения не такой уж и универсальный как вы там вещаете.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 31-Авг-23, 13:15
	> И соответственно рецепт спасения не такой уж и универсальный как вы там вещаете. >> Anon3: и применении костыля в связи с его отсутствием Как то не похоже на пропаганду универсального рецепта спасения Вы просто проецируете, потому что uart действительно на это претендует (и что вы аргументированно обосновали) > Это конечно требует второй ноут или комп и немного подколючки проводов и возможно трансляции уровней,...  Если разуть глаза можно будет найти десятки железок у себя под боком с линухом,... Сидя в блиндаже возле разбомбленного зернового элеватора, когда вокруг рассыпано под открітім небом пару тісяч тонн свезенного и портящегося зерна, в ожидании скорого дождя. Эта гипербола сдесь просто потому, что отбрасываются любые черезмерные решения, а тут еще отсутвие ядерного скрола мешает плохому танцору танцевать > Мсье знает толк в извращениях :) Готовим много разных припарок (где проблемы ядерного скрола и screen являются просто маленькой частью хобби, вписывающейся в общую концепцию) для разных частей тела, в надежде что это если не воспрепятствует переходу в мертвое состояние, то по крайней мере множество припарок мертвому помогут > Тем не менее, если что-то пошло не так, Умозрительно вы правы. Но вот правильно приготовленная связка extlinux, kernel, initramfs, screen-static (или bash-static) достаточно надежна и гибка > А вот например снапшот btrfs с системой в чуть более раннем виде где все еще было ЗБС можно даже grub зацепить, с минимумом допущений. Наверное, действительно самое лучшее решение (я дейсвительно к нему присматриваюсь). Только вот методика сродная MS-style. Если винда не загружается, просто переставь ее (откатись на предыдущий btrfs snapshot). Хочется отладки наживую >> а просто выпить водки. > Это еще почему? Ядерного скрол (его отсутсвие) это для решения проблем, возникших после загрузки ядра и отсутвии как вы и упомянули: >> если у вас не взлетел pci, то клавиатуру на вон том usb вы тоже не получаете, .... А uart - это уже сильный выход вверх Можно выйти вверх еще более радикальным методом: водка. Тогда решаются проблемы не только pci устройств, но и компьютера, как такового, а также зернового элеватора, зерна и блиндажа
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (323), 03-Сен-23, 19:39
	> Как то не похоже на пропаганду универсального рецепта спасения Кажется я не верю в серебряные пули. > Вы просто проецируете, потому что uart действительно на это претендует (и что > вы аргументированно обосновали) Ну вот консоль на простом в инициализации интерфейсе с минимальными допущениями и правда относительно эффективный тул для разбирательства с самыми странными вещами. Хоть и требует еще 1 компьютерной системы. Хотя в случае виртуалки это может быть и всего лишь абстракция. Да и out of band дебагер, если вон того мало - в этом случае вам ничего не стоит. Абстракции забавная штука. > Сидя в блиндаже возле разбомбленного зернового элеватора, когда вокруг рассыпано > под открітім небом пару тісяч тонн свезенного и портящегося зерна, в ожидании скорого дождя. Кернел линукса не очень поможет вам с зерном сам по себе. А так кто сказал что я чужд минимальным допущениям? И в этом смысле, какой никакой сериальный шнурок бывает можно даже к мобилке зацепить, дрова для FTDI'ек там обычно у usb-host таки есть. Конечно 12V RS232 туда низя, угробите мобилку. > Готовим много разных припарок (где проблемы ядерного скрола и screen являются просто > маленькой частью хобби, вписывающейся в общую концепцию) для разных частей тела, Ну вот я тоже разруливаю куда более сложные системные проблемы. Вплоть до вот например невзлета PCI. А кто мне его еще разрулит? Ну не вы же, у вас моих конфигов нет. А многих из них и не будет. Т.к. я люблю всякую экзотику. > Умозрительно вы правы. Но вот правильно приготовленная связка extlinux, kernel, initramfs, > screen-static (или bash-static) достаточно надежна и гибка А заведомо работавший снапшот - это заведомо работавший снапшот. У него самого по себе просто нет причин чтобы перестать работать. > Наверное, действительно самое лучшее решение (я дейсвительно к нему присматриваюсь). Только > вот методика сродная MS-style. MS страшно далек от этого уровня технологий. Они ничего сравнимого в принципе не умеют в таком виде. И бутлоадеры у них бестолковые. > Если винда не загружается, просто переставь ее > (откатись на предыдущий btrfs snapshot). Хочется отладки наживую А тут надо определиться что мы хотим - по#$%ться или выполнить миссию (получить результат, сделать проект, закончить таск, или как сие в вашем словаре звучит). Впрочем одно другое не исключает. Если это было что-то интересное - ну, окей, я сделаю битое состояние системы снапшотом и потом когда время будет - неспешно, в фоне посмотрю а что там такое было. Может даже отврапив в виртуалку, что все сильно упростит. Там я могу подебажить суровее, с более удобными тулами. Зацепив какой GDB через out of band дебаг, не уповая на живость системы вообще. Если вы когда-то были Древним то знаете что такое монитор. И как это - быть уровнем выше остального. А когда это еще и абстракцией оформлено, не зависящей от основной системы - вообще красота. > А uart - это уже сильный выход вверх По крайней мере он от pci не зависит. Это позволяет увидеть что факап с PCI даже если тот совсем не подал признаков жизни. Что как бы аргумент. А вот обычную usb клаву и видяху я при этом не получаю, потому что это на PCI висело. > Можно выйти вверх еще более радикальным методом: водка. Тогда решаются проблемы не > только pci устройств, но и компьютера, как такового, а также зернового > элеватора, зерна и блиндажа Это не мой путь. Мой путь это путь разума.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 30-Авг-23, 13:58
	> Запустите tmux в initramfs для прокрутки консоли, чтобы посмотреть лог загрузки во > время загрузки. А месье знает толк в извращениях.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	255. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (255), 29-Авг-23, 18:39
	>скрин не кошерно. Это потому что тыскозал, пермисивщик?
	Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

	275. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 30-Авг-23, 13:59
	>>скрин не кошерно. > Это потому что тыскозал, пермисивщик? Разрабы из OpenBSD.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 04-Сен-23, 05:33
	>>>скрин не кошерно. >> Это потому что тыскозал, пермисивщик? > Разрабы из OpenBSD. Это те у которых кошерно - из гуеста в виртуалке сразу в кернелмод хоста прорубаться? Их ценное мнение очень важно для нас.
	Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз ядра Linux 6.5"	+/–
Сообщение от Аноним (92), 28-Авг-23, 16:32
Ну всё, теперь венде точно капец))))
Ответить | Правка | Наверх | Cообщить модератору

	102. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (98), 28-Авг-23, 16:56
	Ей сама Мелкософт капец устроит. С Десятки они свернули куда-то не туда.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (-), 28-Авг-23, 20:17
	Соглы. В десятке впервые появился облачный мусор, никому не нужный магазин с не_удаляемыми приложениями, планшетный дизайн. К тому же в десятке вместо одной control panel, их стало две, что бредово само по себе.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Анонимусос (?), 29-Авг-23, 11:16
	А также неотключаймые обновления
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 28-Авг-23, 20:23
	Если разработчики шиндовс не одумаются, то сами себя закапают. Одиннадцатка это просто провал как по дизайну и количеству встроенного облачного мусора, так и по глюкам, особенно в не_ынтерпрайз версиях. Несколько раз накатывал, пробывал изо всех сил привыкнуть и смириться - не выходит.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	159. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Алешка (?), 28-Авг-23, 20:59
	Какие такие аверпрайсные версии?! Нет их и не будет до 2024! А все то глиномесиво что щас происходит на десктопах дебилов, позарившихся на "саврименный" дизийн и удобцтво - собственно бета тест на хомяках-адиотах перед выпуском ltsb-ltsc редакций.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 28-Авг-23, 21:49
	Есть enterprise редакция 11 винды, но без ltsb. Там можно почти всё это безобразие отключить через групповые политики, но легально она недоступна для частных пользователей.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Релиз ядра Linux 6.5"	+2 +/–
	Сообщение от Минона (ok), 29-Авг-23, 07:51
	> Есть enterprise редакция 11 винды, но без ltsb. Там можно почти всё > это безобразие отключить через групповые политики, но легально она недоступна для > частных пользователей. Групповые политики есть в Pro версии, она доступна для физлиц.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 31-Авг-23, 03:24
	>> Есть enterprise редакция 11 винды, но без ltsb. Там можно почти всё >> это безобразие отключить через групповые политики, но легально она недоступна для >> частных пользователей. > Групповые политики есть в Pro версии, она доступна для физлиц. Как ни бсдшник - так эксперт по винде и лицензированию :). Свободному человеку вообще эти средства загона корпоративных винтиков в стойло должны быть ортогональны. Конечно это довольно декоративные и хлипкие цепи, но все же сделано оно для именно вон того.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 31-Авг-23, 10:23
	>>> Есть enterprise редакция 11 винды, но без ltsb. Там можно почти всё >>> это безобразие отключить через групповые политики, но легально она недоступна для >>> частных пользователей. >> Групповые политики есть в Pro версии, она доступна для физлиц. > Как ни бсдшник - так эксперт по винде и лицензированию :). Свободному > человеку вообще эти средства загона корпоративных винтиков в стойло должны быть > ортогональны. Конечно это довольно декоративные и хлипкие цепи, но все же > сделано оно для именно вон того. Ну да, я свободный корпоративный пользователь Windows, Linux, Solaris. 😎
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 04-Сен-23, 05:34
	>> ортогональны. Конечно это довольно декоративные и хлипкие цепи, но все же >> сделано оно для именно вон того. > Ну да, я свободный корпоративный пользователь Windows, Linux, Solaris. 😎 Оно и слышно по характерному позвякиванию цепями :P.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Анонимусос (?), 29-Авг-23, 11:18
	> " но легально она недоступна для частных пользователей" Написал так, как будто винду честно купил.
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	205. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Минона (ok), 29-Авг-23, 07:49
	> Какие такие аверпрайсные версии?! Нет их и не будет до 2024! > А все то глиномесиво что щас происходит на десктопах дебилов, позарившихся на > "саврименный" дизийн и удобцтво - собственно бета тест на хомяках-адиотах перед > выпуском ltsb-ltsc редакций. С добрым утром! первая LTSB версия вышла в 2015.
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	221. "Релиз ядра Linux 6.5"	+/–
	Сообщение от voiceofreason (?), 29-Авг-23, 12:47
	И вот эти люди [s]запрещают ковырятьcя в носу[/s] обзывают всех утятами. Цвета и панельку сделали похожими на KDE, ибо серая 10 всем надоела - и сразу истерика. Телеметрия и прочие гадости отрываются открытым-свободным скриптом с гитхаба в два клика. Нормальная поддержка новых CPU будет только там. Свидетели Первого Сервиспака могут подождать до 12, если вообще новую оффлайн-версию шинды будут выпускать.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

103. "Релиз ядра Linux 6.5"	+2 +/–
Сообщение от Tester (??), 28-Авг-23, 16:58
> В интерфейсе асинхронного ввода/вывода io_uring реализована возможность хранения кольцевых буферов ну наконец то.. вот здесь следующее повышение привелегий будет!
Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз ядра Linux 6.5"	+2 +/–
Сообщение от YetAnotherOnanym (ok), 28-Авг-23, 17:10
> Приложение теперь может самостоятельно выделить область памяти и передать её в io_uring Ждём новых порций веселья.
Ответить | Правка | Наверх | Cообщить модератору

161. "Релиз ядра Linux 6.5"	+/–
Сообщение от Аноним (161), 28-Авг-23, 21:16
Наконец-то я разгоню свою 7900XTX, а то без дела валяется).
Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Аноним (167), 28-Авг-23, 22:13
А что не сказали про наведение порядка в arch/*/boot/dts?
Ответить | Правка | Наверх | Cообщить модератору

	199. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 29-Авг-23, 07:22
	Поясни?
	Ответить | Правка | Наверх | Cообщить модератору

175. "Релиз ядра Linux 6.5"	+1 +/–
Сообщение от Аноним (175), 28-Авг-23, 23:00
> USB4 v2 (80 Gbps через USB Type-C). ну как же, как же без v2? никак не можно-с! USB4.5 v5.4.2.3.010-beta+fdkef*noTB x3.1415926^2.714281428 Type-C usb2.0 HiSpeed 2.0 mode 0.5Gbps!
Ответить | Правка | Наверх | Cообщить модератору

	183. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (183), 29-Авг-23, 01:18
	> USB4 v2 И много уже периферии поддерживают стандарт? Даже type-c считается лютой дичью, а большинство продаваемых устройств это типичный usb2.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (187), 29-Авг-23, 04:15
	> Даже type-c считается лютой дичью, а большинство продаваемых устройств это типичный usb2. Поздняк, уже пошел в массы. Он и правда диковат, особенно PowerDelivery переговариваемый по довольно скоростному и не удобному для generic реализации side channel. Никогда не видел мобилочный кирпич - с мощностью 65 ваттов?! Он конечно здорово крупнее обычного и вот именно typeC. И конечно в 5V он только 3A на порт грузит. Но может и 20V 3A выгрузить, так что среднего пошиба ноут потянет. А чтоб это стало возможно - там унутрях почти три питальника, от того и здоровое такое. APFC, т.к. более 50, чтоли ваттов без него низя, flyback за ним, выдающий вольтей так 22-25, а за ним - управляемый мелким процыком buck. Вот по согласованию с этим процыком он вам и выберет сколько грузить. И если этот процык в фирмвари рюхающей DCDC и TypeC облажается - ваше мягкотелое 5-вольтное нечто огребет все 20 вольт и догадайтесь что будет дальше. Ну, вы ж хотели заряжать ваши лопатники с 6-амперной батареей во всю крышку за час? Вот вам и сделали по вашим заявкам...
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 04:27
	> Даже type-c считается лютой дичью В смысле? Оно везде буквально, в каждом ноутбуке смартфоне и корпусе для ПК дороже 20 баксов. > И много уже периферии поддерживают стандарт? Его в компах то нет.
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	245. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (245), 29-Авг-23, 16:24
	Речь не про мобильники. Речь про масс маркет - бюджетные материнки и ноуты. Прикинь, у меня вот материнка, самая бюджетная, с чипсетом 600 серии под 12 поколение интела и на ней нет усб-с. Ровно как даже теоретически не представляю зачем мне такие скорости через усб.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноньимъ (ok), 29-Авг-23, 18:00
	Зашёл в магазин. Отфильтровал ноуты. У 1400 моделей усб тип ц есть. У 633 нет. Цена от 175$. Среди матплат всех в продаже. У 270 есть на задней панели. У 204 нет на заднице. Цена от 80$ > Ровно как даже теоретически не представляю зачем мне такие скорости через усб. Type-C никаких скоростей особых сам по себе не предполагает. Это просто разъем. Усб3.2 скорости нужны уже для внешних ссд например. Кроме того, на тех же ноутбуках это заодно возможность подключения монитора по DP. Если оно USB4 то можно подключать внешнюю видеокарту.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 30-Авг-23, 01:47
	> как даже теоретически не представляю зачем мне такие скорости через усб. Где-то в районе 4-й версии юсб - жирафли из USB-IF и прочих интелей наконец все же доползли до идеи что хост к хосту все же стало можно конектить. Ну а чо, 80Гбит линк по сравнительно ширпотребной меди не так уж плохо. Это ж не с экзотичной оптикой трахаться, которая в каждом ларе не продается, требует специфичный и весьма дорогой шмот и проч.
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	216. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (216), 29-Авг-23, 12:26
	Type-C это тип разъема, как и Type-A или Type-B Внутри у него может быть хоть 1.1, хоть 2, хоть 3.2, хоть 4 И, да, Type-C это стандарт де-факто, теперь везде только он и больше ничего На материнках сохраняются Type-A-гнезда, но все больше тоже Type-C
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	244. "Релиз ядра Linux 6.5"	–2 +/–
	Сообщение от Аноним (245), 29-Авг-23, 16:23
	Подучить бы вам, товарищ, матчасть и не позориться. Все же технический форум для инженеров.
	Ответить | Правка | Наверх | Cообщить модератору

	293. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 31-Авг-23, 03:36
	> Подучить бы вам, товарищ, матчасть и не позориться. Все же технический форум > для инженеров. А что он не так сказал? Вам дать апнуот от STMicro для инженеров, показывающий как дешево и сердито сделать usb full speed 2.0 девайс уже внезапно как type-C нечто? И будет у вас type-C нечто умеющее аж usb1.2/2.0 @ 12Mbit с той легаси парой D+/D- в режиме только девайса, только потребителя питания, только 5 вольт. Абсолютно валидное комбо по всем спекам, а если вы ожидали большего это сугубо ваши проблемы. По спекам так можно, и нии...т! Type-C это вообще весьма забавный тип разъема и стандарта. За ним в принципе что угодно может быть. Даже "тупой" чаржер без проца и линий для передачи данных. Что очень доставляет хомякам с обломаными ожиданиями. Да, технически вы можете делать очень странные комбо, типа конекта мыша к мышу. Работать конечно же не будет, что должно было случиться? Но вот воткнуть провода вот так - можете. Есть более валидные комбо различной степени работоспособности :). Скажем в usb традиционно не было конекта хост-хост. Потому что master-slave шина, где хост только 1 а остальные периферия. В этом он проигрывал тому же FireWire. Где-то к usb4 жирафли наконец отпустили ручник и все же сделали режим когда можно таки 2 хоста зацепить. И таки если в 2 хоста с typeC usb 4 зацепить кабель между ними - оно таки как минимум теоретически должно вон те гигабиты между ними обеспечить и это даже вроде как должно работать. Насколько по факту катит кто ж его знает, не очень частый конфиг а usb3 всякий так не умел, даже если его и вывели на type C.
	Ответить | Правка | Наверх | Cообщить модератору

185. "Релиз ядра Linux 6.5"	+/–
Сообщение от Аноньимъ (ok), 29-Авг-23, 01:38
>гибкого элемента-массива в структурах (Flexible Array Members Какая же эта сишка дичь просто неймоверная. Такие грязные, пошлые, развратные хаки.
Ответить | Правка | Наверх | Cообщить модератору

202. "Релиз ядра Linux 6.5"	+/–
Сообщение от Аноним (-), 29-Авг-23, 07:34
Пацаны, кто как, а я на Раст перейду только тогда когда он попадёт в коллекцию компиляторов GCC. Ещё надо чтобы Раст одобрил Столлман, без его одобрения тоже неправильно. Все библиотеки из Карго, и сам язык Раст в будущем просто обязаны стать копилефтными. Наша борьба против проприетарщиков и их союзников пермиссивщиков продолжается! Пользуясь случаем передаю пламенный привет программистам из латиноамериканского Фонда Свободного ПО! И знайте, что GNU - это не коммунизм. Торговать можно.
Ответить | Правка | Наверх | Cообщить модератору

	208. "Релиз ядра Linux 6.5"	+3 +/–
	Сообщение от Аноним (208), 29-Авг-23, 08:50
	Можешь переходить, он уже принят в GCC :-) https://www.opennet.ru/opennews/art.shtml?num=58278 https://www.opennet.ru/opennews/art.shtml?num=59038
	Ответить | Правка | Наверх | Cообщить модератору

226. "Релиз ядра Linux 6.5"	+/–
Сообщение от Ананоним (?), 29-Авг-23, 13:33
Оно заработает на моём AMD K6-2-450?
Ответить | Правка | Наверх | Cообщить модератору

	228. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 13:43
	> Оно заработает на моём AMD K6-2-450? Да. Но лучше разгоните его на 560МГц (5х112)
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананоним (?), 29-Авг-23, 14:27
	А чё, так можно было?
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Релиз ядра Linux 6.5"	+/–
	Сообщение от voiceofreason (?), 29-Авг-23, 16:07
	Можно, как и напругу поднимать чуть ли не до 5V без последствий. Техпроцесс толстенный, угробить такой CPU было трудновато. Ещё для лУчшего разгона в K6-3/K6-3+ отключали кэш, прирост в частоте не везде, но часто перевешивал.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Anon3 (?), 29-Авг-23, 17:04
	> Можно, как и напругу поднимать чуть ли не до 5V без последствий. > Техпроцесс толстенный, угробить такой CPU было трудновато. Ещё для лУчшего разгона > в K6-3/K6-3+ отключали кэш, прирост в частоте не везде, но часто > перевешивал. Ну жестить с напругой все таки не надо. Максимум, пунктов на 4 вверх. Если больше, то у меня проц перестал работать в стандартном режиме и требовал, для стабильной работы, минимум повышение напряжения на 2 пункта без разгона.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Anon3 (?), 29-Авг-23, 16:55
	> А чё, так можно было? Ну если у вас материнка на чипсете MVP3, то можно. Только частота шины 112МГц не стандартна и не описана в мануале к материнке, нужно на форумах искать как выставлять перемычки. Там частота шины и 125, 133 есть, но на них проц не заводится Ну и напряжение питания ЦПУ чуть повысить, чтобы добиться стабильности и не сильно превысить, когда уже виснет от перегрева при любом качестве охлаждения Именно 450-тые хорошо гонятся, уже 400-тые не каждые до 500 добираются
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	266. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 30-Авг-23, 01:49
	> А чё, так можно было? Там еще и так можно было. У меня как то 266 до 350 разогнался и работал стабильно как вкопаный. Оказалось - у амд вышел избыток 350 и они их перемаркировали вниз и скостили цену. Если забить на надпись, это обычный 350-й кристалл по факту был. А на крышке что угодно можно написать :)
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	253. "Релиз ядра Linux 6.5"	+/–
	Сообщение от коньюктивит (?), 29-Авг-23, 17:58
	У вас и рабочий элт-монитор поди? Жить в музее - это круто.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	299. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Ананоним (?), 31-Авг-23, 15:10
	> У вас и рабочий элт-монитор поди? Жить в музее - это круто. Ага, есть такие у меня, на трубе Мицубиши Даймондтрон. Супервещь!
	Ответить | Правка | Наверх | Cообщить модератору

248. "Релиз ядра Linux 6.5"	+2 +/–
Сообщение от Аноним (248), 29-Авг-23, 17:32
Такими темпами к новому году может выйти ядро 6.6.6 :-) . Хочу поставить себе just for fun.
Ответить | Правка | Наверх | Cообщить модератору

	267. "Релиз ядра Linux 6.5"	–1 +/–
	Сообщение от Аноним (267), 30-Авг-23, 03:05
	> Хочу поставить себе just for fun. Скучная у Вас жизнь. Может всё же стоит задуматься над своими жизненными приоритетами?
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Релиз ядра Linux 6.5"	+1 +/–
	Сообщение от Аноним (248), 30-Авг-23, 15:04
	Ну да, скучно. Всё работает, вот и хочется экспериментов. Естественно, не на рабочей системе.
	Ответить | Правка | Наверх | Cообщить модератору

282. Скрыто модератором	+/–
Сообщение от Аноним (-), 30-Авг-23, 16:39
лол, FreeSync включили ровно когда я купил FreeSync-монитор :D :D ну т.е. через 10 лет после появления FreeSync :D
Ответить | Правка | Наверх | Cообщить модератору

359. "Релиз ядра Linux 6.5"	+/–
Сообщение от cheburnator9000 (ok), 06-Сен-23, 05:43
Любой линукс на базе kernel 6.5 в vmware грузится примерно 10 минут или даже больше я честно хз ибо терпение кончается раньше чем загрузится графический стол. Капец полнейший.
Ответить | Правка | Наверх | Cообщить модератору

	382. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 09-Сен-23, 02:57
	вбокс пока не прикрутили, о чём ясно в последнем чейнджлоге дали понять ща как в деби тестинг подвезут - раздуплятся все, наверно
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Релиз ядра Linux 6.5"	+/–
	Сообщение от Аноним (-), 09-Сен-23, 03:04
	>я честно хз ибо терпение кончается раньше чем загрузится а вот терпения надо набираться)) там пока линус эти патчи первого дня не налепит и на табло мейнлайн не переключит - лучше себя предвкушением мучать хДДД
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема