LINUX.ORG.RU

Линус Торвальдс отверг изменения в MMC для Linux 7.0: «полный мусор»

 , ,


0

2

Перед выходом ядра Linux 7.0 планировались некоторые интересные изменения в подсистеме Linux MultiMediaCard «MMC», такие как идентификаторы устройств NXP IW61x для чипов Wi-Fi через SDIO, поддержка дат производства после 2025 года, оптимизация безопасного erase/TRIM для некоторых eMMC-карт Kingston, очистка кода DW_MMC, поддержка Mediatek MT8189 в mtk-sd и различные обновления драйверов SHDCI.

Но Линус Торвальдс, проверив предложенный запрос на слияние, отклонил его, прокомментировав:

Нет.
Эти изменения — полная ерунда, и они даже не компилируются. По-видимому, они никогда не были в linux-next и не тестировались при сборке.
Если мы собираем этот файл core.o при CONFIG_MULTIPLEXER=m:

obj-$(CONFIG_MULTIPLEXER) += mux-core.o

но в include/linux/mux/consumer.h у вас есть

#ifdef CONFIG_MULTIPLEXER

что не будет истинным (поскольку определено CONFIG_MULTIPLEXER_MODULE), поэтому мы получим длинный поток чего-то вроде

drivers/mux/core.c:312:14: error: redefinition of ‘mux_control_states’

потому, что в заголовочном файле mux/consumer.h будет определена фиктивная функция-обертка. Другими словами, коммит ad314348ceb4 («mux: Add helper functions for getting optional and selected mux-state») — это чистый, ничем не разбавленный, непротестированный мусор.
Я не хочу видеть от Вас «исправленный» запрос на слияние. Это совершенно неприемлемо, и я больше ничего от вас не буду принимать в течение ближайшего периода слияния (this merge window). Прекратите присылать мне непротестированный хлам, который не был включен в linux-next и даже не проходит самую поверхностную проверку на наличие проблем.
Вы можете попробовать еще раз для версии 7.1, но только после включения в linux-next и надлежащего тестирования.

Таким образом, изменения в Linux MultiMediaCard теперь придется отложить до начала периода слияния Linux 7.1 в середине апреля, после дебюта стабильной версии Linux 7.0.

>>> Источник



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 10)
Ответ на: комментарий от thesis

Сам местами юзаю шрифты с битмапами

А где берете растровые шрифты с хорошо прорисованным русским? Да еще чтобы позиции русских глифов соответствовали номерам в юникоде (для браузера например) а не виндовой кодировке 1251.

Хочу 22" или 24" с разрешением 4К

Хуже что там могут вылезти диспропорции элементов интерфейса в софте. Далеко не все авторы программ расчитывали что их творения будут запускать на мониторах с очень высоким dpi.

watchcat382
()
Ответ на: комментарий от seiken

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

watchcat382
()
Ответ на: комментарий от watchcat382

Довольствуюсь старыми добрыми шрифтами от MS, ну там arial-tahoma-verdana и т.д. со встроенными битмапами (или дотошным хинтингом? не знаю точно) для мелких размеров. И для быдлокодинга использую пару штук отсюда, там есть немножко с кириллицей, хотя и небогатые в плане покрытия уникода (да и хер бы с ним).

thesis ★★★★★
()
Ответ на: комментарий от seiken

CI/CD, мне кажется, имеет смысл для множества однотипных проектов. И то он будет очень жирный, непостоянный, местами непредсказуемый, требующий постоянных доработок и службы поддержки 24/7. И в любом случае будут те, кто будет обходить автоматизацию.

А в ядре, скорее всего, есть похожие процессы. Нужно было всего-лишь не обходить стадию linux-next.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 2)
Ответ на: комментарий от seiken

Ты что, не веришь в дело Торвальдса?

Я вообще не верующий. Агностик.

А Торвальдс конечно хорош тем что был первым и на практике доказал что в индустрии софтостроения можно что-то изменить к лучшему. С защищенным режимом х86 в начале 90х экспериментировали многие (даже я), но никому даже в голову не приходило что какая-то самоделка вообще может конкурировать с ОС от крупных корпораций. Поэтому доводить свои эксперименты до более-менее законченного вида и как-то распространять даже и не пытались. А он вот и сделал и распиарить смог. Почет и уважение!

watchcat382
()
Ответ на: комментарий от watchcat382

Не совсем, вполне объективное. В расте один из лучших доступных тулингов, дофига библитек и фреймворков. Даже в эмбедеде(как-то приходилось выбирать) у ады швах, надо велосипедить, хотя, казалось бы, её тема.

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

Для декомпозиции/композиции предметки и вообще архитектуры у раста есть алгебраические типы(охрененно удобные и красивые) + ФВП+ трейты(типы типов)+ параметрический полиморфизм. У ады что-то невнятное ООП-образное, тут она явно отстаёт и подзастряла где-то в 80-ых 90-ых. Ещё есть асинхронщина, замороченная, но опять же, для системщины лучше сейчас нет, и ещё продвинутая макросистема. У ады, вроде как, обе вообще отсутствуют.

А, ну ещё раст легче и быстрее, и вообще хорошо так заточен на оптимизацию в своей языковой основе

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от zurg

У ады что-то невнятное ООП-образное

Обычное ООП. С динамическим полиморфизмом. На счёт тулинга да, швах. Для раста хотя бы есть RustRover. Ада из тех времён, когда проприетарный софт распространялся на дискетках, готорые аккуратно охраняли от пыли и кофе, не было говно-опенсейсов, а клавиатура громко клацкала. А в офисе не кричали на средиземноморских языках. Променял бы те времена на все расты, гошки, JS’ы и линуксы.

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от X512

В ваших словах просматривается какой-то культ и преклонение к фигуре Линуса Торвальдса как будто каждое сказанное им слово истина в последней инстанции и вам надо обязательно придумать и написать аргумент критикам как они не правы.

Придумать за оппонента то, чего он не говорил – это днище, вообще-то. Вот уж от кого не ожидал.

Если действительно интересует моё отношение к Торвальдсу – я его уважаю, примерно за это:

Линус Торвальдс отверг изменения в MMC для Linux 7.0: «полный мусор» (комментарий)

Всем желающим сделать лучше я выше предложил – нет, даже не написать с нуля, а просто сделать форк и пылесосить непринятые в апстрим патчи. Если взлетит, можно предложить Линусу. Можно не предлагать.

Где тут культ-то?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от DrRulez

На самом деле я намеренно привел пример МФУ. Потому, как он, действительно работает через cups, который подарила apple.

подарила

А вот и переписыватели истории подъехали.

Разработка CUPS началась в 1997 году, а первая публичная бета-версия появилась через два года.

В марте 2002 года, корпорация Apple приняла CUPS как систему печати для своей операционной системы Mac OS X 10.2, а в феврале 2007 наняла главного разработчика CUPS и приобрела права на исходный код.

В декабре 2019 года, основатель проекта CUPS уволился из компании Apple.

Проект OpenPrinting, при поддержке организации Linux Foundation, приступил к развитию форка системы печати CUPS. Наиболее активное участие в разработке форка принимает Майкл Свит (Michael R Sweet), изначальный автор CUPS. Ввиду отсутствия интереса компании Apple к поддержанию системы печати CUPS, Проект OpenPrinting принял решение взять сопровождение кода CUPS в свои руки.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

По моему днище – это разводить истерику по любому поводу и организация разработки, где начальник должен сам вручную собирать каждый коммит.

Можно было спокойно объяснить что не так и наконец ввести CI.

X512 ★★★★★
()
Ответ на: комментарий от zurg

Даже в эмбедеде(как-то приходилось выбирать) у ады швах

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

А вот кто стоит за Растом и откуда взялись деньги чтобы сделать его таким хорошим как вы пишите - это вопрос. Если он конечно действительно такой хороший. Ибо порядок затрат на разработку Ады более-менее известен, а вы пишете что она в чем-то хуже.

ещё раст легче и быстрее

Ада, правда первого стандарта, Ада-83, у меня отлично работала когда-то на 286 машине с двумя мегабайтами памяти под дос-экстендером. Сейчас это по производительности уровень не самого мощного микроконтроллера. И я бы не сказал что рантайм у той Ады был какой-то особо толстый - я его вдоль и поперек излазал тогда дебагером.

Впрочем - я всё же считаю что в микроконтроллерах оптимально Си, именно из-за его максимальной близости к железу. «Переносимый ассемблер» как-никак. Тем более что под мелкие контроллеры приходится писать практически вообще без рантайма, прямо под bare metall.

А вот ядро ОС для ПК - вполне можно бы и на Аде. Наверно и на Расте можно - я просто его не настолько знаю чтобы иметь однозначное мнение. На Аде писал, на Расте - только чужие исходники видел и то поверхностно.

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

watchcat382
()
Ответ на: комментарий от X512

разводить истерику по любому поводу

Ну… Линус не прочь развести драму, это да.

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

hobbit ★★★★★
()
Ответ на: комментарий от X512

начальник должен сам вручную собирать каждый коммит.

Он не должен, он хочет. Это подчеркивает его значимость в проекте. Вопрос вообще ни разу не технический. Он - основатель проекта, имеет право рулить.

и наконец ввести CI

Тогда снизится его важность как начальника. Вполне логично что он этого не хочет.

watchcat382
()
Ответ на: комментарий от watchcat382

Нууу… тут я временно перебегаю на другую сторону… Это же зависит от того, как организовать рабочий процесс. Если условный былдбот сообщил, что патч по крайней мере собирается с разными флагами, его по крайней мере можно уже взять в ручную проверку. Вот если после ухода Линуса на пенсию оставшиеся кожаные вообще не будут анализировать патчи и свалят всё на автоматизацию – живые позавидуют мёртвым. :) Нет, я не говорю, что будет именно так.

Это не отменяет того факта, что Линус вправе делать так, как ему удобнее, привычнее, быстрее, наконец.

hobbit ★★★★★
()
Ответ на: комментарий от watchcat382

Впрочем - я всё же считаю что в микроконтроллерах оптимально Си именно из-за его максимальной близости к железу. «Переносимый ассемблер» как-никак. Тем более что под мелкие контроллеры приходится писать практически вообще без рантайма, прямо под bare metall.

Да, это так. Но уже и Rust туда пробуют «проталкивать», и кое-что другое... Экспериментируют люди, и не только на ядре Linux... ;))

А вот ядро ОС для ПК - вполне можно бы и на Аде. Наверно и на Расте можно - я просто его не настолько знаю чтобы иметь однозначное мнение. На Аде писал, на Расте - только чужие исходники видел и то поверхностно.

Когда-то, помнится, читал, что интерпретатор FORTH на каких-то компьютерах использовался, как замена ОС. Но «живьём"такое не встречал - видимо, до нас такие вещи не довозили.

А жаль, во времена DOS я был бы рад такой замене ОС... :)

Somebody ★★★★
()
Ответ на: комментарий от watchcat382

А вот кто стоит за Растом и откуда взялись деньги чтобы сделать его таким хорошим как вы пишите - это вопрос.

Да вроде не вопрос это - там копрораты скинулись, а дальше цепочку можно раскручивать, возможно и до правительственных органов отдельных стран можно докопаться… В любом случае РжавОй - это способ прихватизировать линукс, имхо…

Sm0ke85
() автор топика
Ответ на: комментарий от Somebody

Но уже и Rust туда пробуют «проталкивать», и кое-что другое…

Аду тоже пытаются. Например я облизываюсь вот на этот пример проталкивания Ады на STM32F103C8T6 (а не более старшие и менее доступные): http://www.hrrzi.com/2017/11/ada-on-2-ebay-bluepill-board.html Повторить у меня сходу не получилось (скачаное не собирается, надо глубоко копать).

Насчет Rust - я не могу сказать насколько он хорош или плох просто потому что на нем не писал и внутренности его не копал (в отличие от Ады).

интерпретатор FORTH на каких-то компьютерах использовался

Я тоже об этом читал, но живьем не видел. Хотя вроде даже на каких-то советских был.

во времена DOS я был бы рад такой замене ОС…

Под DOS хотябы были доступны готовые библиотеки для создания интерфейса(и не только). И под Си и под Паскаль. А под forth что? Самому с нуля писать что ли? Я в те времена пользовался библиотекой C-scape 3.2 от Oakland Group Inc, даже к Аде ее успешно прикрутил так как библиотека поставлялась в исходниках. Причем я эту библиотеку КУПИЛ! Специально в Тверь ездил в какую-то контору, название уже не помню, где мне ее и продали, причем с переведенной на русский документацией. Причем судя по директивам условной компиляции в исходниках - оно и под юниксовый текстовый терминал могло собираться, но каких-то файлов для этого не хватало. Была идея под «Демос» на СМ1600 собрать, но увы - облом.

watchcat382
()
Ответ на: комментарий от Sm0ke85

там копрораты скинулись

Если посмотреть затраты на разработку Ады и принять что Раст с ней сравним - то скидываться очень уж много пришлось. Тем более что время от объявленного начала разработки до выхода версии 1.0 как-то подозрительно небольшое.

РжавОй - это способ прихватизировать линукс

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

Кстати, мне было бы интересно почитать где-нибудь критику Раста - что в нем такого плохого что достаточно часто встречаю на форумах негатив в его сторону. На первый взгляд - ну язык и язык. Исходники довольно понятно выглядят, это не лисп какой-нибудь или хаскел.

watchcat382
()
Ответ на: комментарий от watchcat382

Под DOS хотябы были доступны готовые библиотеки для создания интерфейса(и не только). И под Си и под Паскаль. А под forth что? Самому с нуля писать что ли?

А я пописа́л на нём под DOS, а когда понадобились базы данных, пришлось «мигрировать» на Clarion Professional Developer v2.1, поскольку ни знаний по теории баз данных, ни литературы тогда в наших краях никакой не было... Даже «устройство» банального DBF годы спустя узнал...

А жаль... FORTH «в целом» и F-PC от Tom Zimmer, в частности, мне тогда очень так хорошо «на душу лёг», не хотелось бросать, да пришлось, ради заработка...

Somebody ★★★★
()
Ответ на: комментарий от watchcat382

Не могу понять как разработка очередного (из многих) языка программирования связана с «прихватизацией линукса».

Через централизацию: например, ты просто собрать не сможешь проект.

на форумах негатив в его сторону. На первый взгляд - ну язык и язык.

Это не просто язык, а язык, который Активно пихают корпораты - этим многое и объясняется… Например, до раста было куча языков, и всякие коре-утилы не спешили на них переписывать, а уж тем более в ядро тащить… но вот появился раст и вдруг на него начали все подряд переписывать, даже не оглядываясь на то, что данный ЯП, с точки зрения его применения в крупных проектах, очень «зеленый»… Это наводит на безрадостные мысли и только наивные простачки могут верить что это все «потому что чтобы всем было лучше»… Там и речовки, под которые он толкается - тоже вилкой на воде накарябали… Одно явно видно: раст может позволить монополизировать линукс, а также он упрощает применение нейронок, т.к. хоть какая-то защита от имбицила там присутствует, а избыточный код - это не великая потеря при применении нейронок…

Sm0ke85
() автор топика
Ответ на: комментарий от Somebody

FORTH «в целом» и F-PC от Tom Zimmer, в частности, мне тогда очень так хорошо «на душу лёг», не хотелось бросать, да пришлось, ради заработка…

А мне чуть позже пришлось бросать Аду - и по той же причине. Компилятор-то был, а вот библиотеки GUI которую можно было бы к нему хорошо подцепить - небыло.

Clarion Professional Developer v2.1

У меня под DOS был MDBS III v3.09 от Micro Database System. Пиратский и без исходников увы. Судя по документации - существовал для Xenix и Ultrix, но такого конечно у меня не было. Базоданное жутко интересное, оно вообще нифига не табличное, а иерархическое, что очень удобно во всяких например учетных задачах. Всё основано на отношениях owner/member между объектами данных. На 286 работало быстрее чем базы на основе dbf на 486.

watchcat382
()
Ответ на: комментарий от Sm0ke85

Например, до раста было куча языков, и всякие коре-утилы не спешили на них переписывать

Да ну, много что на что переписывали уже. От того что появится вариант cureutils на Расте - не исчезнет же никуда классический сишный. Ну хочется людям с новым языком поэкспериментировать - не запрещать же им это. Ибо запреты как-то не стыкуются с идеями свободного софта. Сделают что-то лучшее чем есть - можно будет пользоваться. Сделают фигню - никто кроме них пользоваться не будет. Просто надо понимать, что навязываемое коммерческой рекламой тождество «новое==лучшее» не является истинным. Может быть как лучше так и хуже. Но корпоратам не выгодно когда покупатели это начинают понимать.

монополизировать линукс

Ну будет два линукса - один от корпоратов, другой от всех остальных. Издержки свободы - любой может сделать свой вариант. Это винды бывают только от Микрософта. И это еще хуже.

упрощает применение нейронок

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

watchcat382
()
Ответ на: комментарий от watchcat382

Да ну, много что на что переписывали уже. От того что появится вариант cureutils на Расте - не исчезнет же никуда классический сишный

Уже исчезает, да и apt переписывать надумали и многое другое… А смысл си-шное поддерживать какой, если в дистрибутивы заедет растовый вариант?

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

Никто не против, пусть бы форкали любой дистрибутив и ваяли, а тут прям в дебиан и т.п. заезжает все сразу (дебиан - это достаточно консервативный дистриб, если что)

Ибо запреты как-то не стыкуются с идеями свободного софта.

Видимо стыкуются, т.к. большинство разработчиков в переписке недовольны переписыванием apt на раст, но один чудило-мэйнтейнер слал всех лесом (напоминаю, дебиан - это консервативный дистрибутив был…)

Но корпоратам не выгодно когда покупатели это начинают понимать.

Тут они прикрываются лозунгами о мифической «безопасности», и многие это проглотили…

Ну будет два линукса - один от корпоратов, другой от всех остальных. Издержки свободы - любой может сделать свой вариант. Это винды бывают только от Микрософта. И это еще хуже.

Вот тебе два линукса: один современный и поддерживает все технологии и игры, а второй Васян «пытается» держать «в актуальной форме» - какой выберешь?

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

Уже сейчас нейрослоп показал себя с худшей стороны, а «разобраться во внутренностях таких монстров как QT» - вполне человекам по силам, это практика показала, да и зачем нейронке человекоподобный язык, если уж на то пошло, пусть тогда в ассемблере ваяет, но она не может, т.к. в контекст не умеет… Таким образом, в худшем случае мы обречены платить за убогий, тормозной и глючный нейрослоп без возможности это исправить (или будем новое ядро юникслайк придумывать и лепить свой дистрибутив? а может на бсд пойдем?)

Sm0ke85
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.