The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Линус Торвальдс не исключил возможность интеграции поддержки Rust в ядро Linux 5.20, opennews (ok), 22-Июн-22, (0) [смотреть все]

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


76. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 22-Июн-22, 12:30 
Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер? Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.

Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго.

Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте? Чисто-сишное ядро и так раздуто, а с распространением языка Раст мы будем вынуждены в итоге скачивать гигабайтный архив исходных кодов?

Короче, в голову приходят страшные мысли. Ребята передайте Линусу пусть он пока не пускает Раст в ядро! А корпорасты, которые лоббируют продвижение Раста пусть идут лесом.

Ответить | Правка | Наверх | Cообщить модератору

83. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от Аноним (120), 22-Июн-22, 12:41 
Эх, даже если мы устроим краудфандинг, чтобы компенсировать Торвальдсу упущенную выгоду, вслествие отказа от включения Rust, мы не наберём столько.
Ответить | Правка | Наверх | Cообщить модератору

85. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –3 +/
Сообщение от n00by (ok), 22-Июн-22, 12:42 
> Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического
> алгоритма на чистом Си будет занимать меньше строк чем на Расте?

Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

258. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (258), 23-Июн-22, 11:22 
> Раст, внезапно, функциональный.

в расте функции - первоклассные объекты, можно ими жонглировать как душе угодно?

Ответить | Правка | Наверх | Cообщить модератору

260. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 23-Июн-22, 12:43 
>> Раст, внезапно, функциональный.
> в расте функции - первоклассные объекты,

Если верить Википедиям, то и Си++ они первоклассные https://en.wikipedia.org/wiki/First-class_function#Language_...

> можно ими жонглировать как душе угодно?

Он же компилируемый - так что есть нюансы с eval. Через пару лет можно будет оформить в виде llvm.ko.

Зато "переменные" иммутабельны по умолчанию, не требуется императивный return.

Вот обычные для ФЯ конструкции:

    let y = {
        let x = 3;
        x + 1
    };

fn five() -> i32 {
    5
}

https://doc.rust-lang.org/book/ch03-03-how-functions-work.html

Осталось прикрутить к этой безусловно полезной абстракции отображенные в память регистры контроллера...

Ответить | Правка | Наверх | Cообщить модератору

286. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (258), 23-Июн-22, 15:00 
> Вот обычные для ФЯ конструкции:

Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

Ответить | Правка | Наверх | Cообщить модератору

291. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 23-Июн-22, 15:34 
>Уровень детсада.

В системном программровании нужна только процедурщина.

>Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

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

Ответить | Правка | Наверх | Cообщить модератору

299. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 23-Июн-22, 16:25 
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)

Ответить | Правка | Наверх | Cообщить модератору

444. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 13:00 
> в реальном железе имеем const volatile. =)

Это что еще за порнография? Типа регистр RO для софта, но который может со своей стороны менять железо?

Ответить | Правка | Наверх | Cообщить модератору

455. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 26-Июн-22, 13:25 
>> в реальном железе имеем const volatile. =)
> Это что еще за порнография? Типа регистр RO для софта, но который
> может со своей стороны менять железо?

Это когда регистр железно выполнен как RO, софт может туда и писать, но ничего не изменит.

Ответить | Правка | Наверх | Cообщить модератору

470. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от Аноним (-), 26-Июн-22, 17:03 
> Это когда регистр железно выполнен как RO, софт может туда и писать,
> но ничего не изменит.

А, обычный RO регистр, что-то я тупанул тут. Вообще регистры логично референсить как адреса в памяти, то-бишь указатели, и там чуть сложнее получается - const'ов может быть ДВА. У указателя (как индикатор что адрес регистра прибит на гвозди, зачем нам баги если мы сдуру указатель сменим?!) - и потом у его типа. Как бы именно volatile const'ом регистр вообще не референсится, скорее указателем на него.

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

Интересно как хрустики кстати volatile делают и вот это самое, раз кудахчут про системность.

Ответить | Правка | Наверх | Cообщить модератору

442. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 12:58 
> В системном программровании нужна только процедурщина.

А ты уверен что даже просто ioctl какой попадает под именно такое определение? :)

А еще - в сях можно функции переназначать на лету, передавать как параметры и проч. Указателями на функцию, прикинь?! Это позволяет делать довольно забавные вещи.

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

>>Где передача функций, как объектов, каррирование, композиция функций
>>и прочая ненизкая математика?
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

Они половину этой порнухи так то сами умеют делать прямо из сей каких и проч.

Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

298. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 23-Июн-22, 16:07 
>> Вот обычные для ФЯ конструкции:
> Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций
> и прочая ненизкая математика?

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

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

301. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (258), 23-Июн-22, 16:30 
> Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.

Еще один невзрослый тезис. Не надо приравнивать некоторые элементы ФП и само ФП.
Функциональное программирование - это именно жонглирование функциями.

Как в расте передать композицию функций, особенно вернуть как результат, особенно с захватом локальных значений?

Ответить | Правка | Наверх | Cообщить модератору

339. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 24-Июн-22, 07:34 
> Функциональное программирование - это именно жонглирование функциями.

Поскольку "жонглирование" не формализовано, процитированное "определение" ФП - демагогическая чушь. Поскольку цирковой термин повторяется дважды - похоже на мантру для некоей секты.

Ответить | Правка | Наверх | Cообщить модератору

347. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 24-Июн-22, 10:01 
> "определение" ФП - демагогическая чушь

Вот именно, сегодня. Сегодня "определение" ФП - это "парадигма", что есть не формальное определение, а демагогия. Сегодня любой новый модный молодежный язык, в котором есть термин "функция" - это "язык ФП". А вот раньше трава была зеленее.

Ответить | Правка | Наверх | Cообщить модератору

353. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 24-Июн-22, 10:44 
То есть предмет спора выдуман автором сообщения №258.
Ответить | Правка | Наверх | Cообщить модератору

348. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 24-Июн-22, 10:04 
Вернемся к нашим баранам.
Так как вернуть композицию функций в расте?
Ответить | Правка | К родителю #339 | Наверх | Cообщить модератору

351. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 24-Июн-22, 10:40 
Ответьте, пожалуйста, отдельным сообщением, когда Вам удастся с Вашими баранами разобраться. Очень интересны вопросы животноводства.
Ответить | Правка | Наверх | Cообщить модератору

481. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (480), 26-Июн-22, 23:02 
Простите, ваша фамилия случайно не Головин?
Ответить | Правка | К родителю #348 | Наверх | Cообщить модератору

435. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 12:40 
> Он же компилируемый - так что есть нюансы с eval. Через пару
> лет можно будет оформить в виде llvm.ko.

Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

447. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 26-Июн-22, 13:12 
>> Он же компилируемый - так что есть нюансы с eval. Через пару
>> лет можно будет оформить в виде llvm.ko.
> Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет,
> за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.

Ответить | Правка | Наверх | Cообщить модератору

489. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 27-Июн-22, 17:37 
> Так это будет потом. Когда привыкнут, что Rust уже и так есть,
> выйдет версия 2.0. Окно Овертона же.

Скорее, научат хруст eBPF какой генерить и в юзермод вывесят :))). Но между нами, вон там LLVM или кто еще GPUшке в юзермоде шейдеры как-то так и компиляет.

Теоретически, это может быть безопасно. Практически, как-то наподобие трахнули xbox360, чтоли, поклав на многоэтажную систему DRMной секурити...

Ответить | Правка | Наверх | Cообщить модератору

104. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (104), 22-Июн-22, 13:07 
Си программы меньше размером, потому что динамическая линковка.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

259. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (258), 23-Июн-22, 12:35 
А в расте - больше, потому что динамическая линковка с libc.
Ответить | Правка | Наверх | Cообщить модератору

295. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Анончик (?), 23-Июн-22, 15:54 
ямеюсь
Ответить | Правка | Наверх | Cообщить модератору

436. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/
Сообщение от Аноним (-), 26-Июн-22, 12:40 
> А в расте - больше, потому что динамическая линковка с libc.

Господа, а вас не смущает что кернел с libc не линкуется, ни там ни там? :)

Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

149. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от Аноним (149), 22-Июн-22, 15:23 
> Если начнут писать модули на Расте каков их будет среднестатистический бинарный размер?

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

> Только не говорите мне, что надо каждый раз отключать включёные по умолчанию функции дебага.

А зачем у тебя по умолчанию включён дебаг?

> Если начать компилировать исходные коды на Расте, сколько ждать?

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

> Одинаковая реализация в процедурном стиле среднестатистического алгоритма на чистом Си будет занимать меньше строк чем на Расте?

Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно.

> Ребята передайте Линусу пусть он пока не пускает Раст в ядро!

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

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

174. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Андрей (??), 22-Июн-22, 18:31 
> Без разницы - конечные пользователи устанавливают готовый бинарь. Даже если захочется самому собрать - это разовая операция.

Особенно, когда тебе говорят попробовать найти баг с помощью git bisect.

Да и корректирующие релизы ядра выходят не раз в полгода. Так что далеко не разовая.

Ответить | Правка | Наверх | Cообщить модератору

226. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (226), 23-Июн-22, 00:04 
Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда бы ты знал что занимаешься его разработкой и не говорил что бинарно бисектить собрался. Короче мимо парень
Ответить | Правка | Наверх | Cообщить модератору

437. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 12:42 
> Ты модуль ядра решил компилировать что ли, раз тебе бисект потребовался? Тогда
> бы ты знал что занимаешься его разработкой и не говорил что
> бинарно бисектить собрался. Короче мимо парень

А в чем прикол стандартное стоковое ядро компилить? Bisect это как раз вполне валидная причина компилежки и время оного очень даже интересует.

Ответить | Правка | Наверх | Cообщить модератору

190. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/
Сообщение от Аноним (189), 22-Июн-22, 19:46 
> Прогресс в развитии языков наоборот, позволяет писать код менее громоздко, но при этом более понятно.

Ну все, Я понял, почему программы так пожирнели последнее время. ;) Это чтобы понятность не изменилась! ;) ;) ;)

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

227. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (226), 23-Июн-22, 00:08 
Очередной любитель оптимизаций по хдд. Прогрессу плевать на твои желания, адаптируйся или деприсируй 🤣
Ответить | Правка | Наверх | Cообщить модератору

230. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (138), 23-Июн-22, 00:24 
Сначала такой
>адаптируйся или деприсируй 🤣

а потом
>меня-то защооо?!!

Ответить | Правка | Наверх | Cообщить модератору

247. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (189), 23-Июн-22, 09:39 
Оптимизации люблю до определённого предела. Но, постоянная память и особенно ОЗУ они же не резиновые, что бы бросать туда всякий ненужный мусор. Но Вы же (ИМХО) гооооораздо выше таких мелочей (пока Вам этот мусор на голову не начнет сыпаться).

Дико извеняюсь, но...
Как же Я люблю это Но, оно как правило дремлет, но, как иногда бывает, вот заблудился человек в дебрях технического прогресса, потерялся, растерялся, запутался в чужой да и в собственной лжи, и тут о чудо, Но вдруг неожиданно просыпается, да как подпрыгнет как подскочит, надает заблудшему аплпеух да подзатыльников, повернет в сторону Истины и даст хорошего пинка, что бы Прогрессу было за кем гнатся! ;)
А бывает, Но не просыпается. И приходится Прогрессу плеваться и плестись, блудить и плеваться. Грустно?!? :(
НО, мы не будем, строить разлапистые теории заговоров, а просто спишем все на простую человеческую ... мудрость! ;)

Если под словом деприсируй Вы имели ввиду пресс, то мне больше нравится, элиминируй, в данном контексте.

О своих желаниях Я тайно поведал в предыдущем своем посте. Об остальных, скромно умолчу ;)

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

173. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Андрей (??), 22-Июн-22, 18:25 
> Если начать компилировать исходные коды на Расте, сколько ждать? Половину дня? Люди говорят, что исходники на Расте и C++  компилируются очень долго.

А до включения Раста ядро можно было скомпилировать прям на ходу при запуске с помощью tcc (Tiny C Compiler).

Не говоря уже про время сборки самого компилятора. Ведь Раст - это не только сам Раст, но ещё и монстр LLVM.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

228. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (226), 23-Июн-22, 00:10 
Можно, и можно будет, но зачем? И так и так всё равно нужно будет тюнить флаги компиляции… вот правда зачем тебе то дерьмо мамонта?
Ответить | Правка | Наверх | Cообщить модератору

235. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +4 +/
Сообщение от burjui (ok), 23-Июн-22, 03:08 
> Короче, в голову приходят страшные мысли.

А вот если будешь изучать язык, читать документацию и писать программы, будут приходить ещё и умные. На все твои вопросы есть очевидные ответы. Но тебе нужны не ответы, а солидарность таких же хейтерков, у которых других проблем нет в жизни, кроме Rust, который прямо-таки давит на мозги, покоя не даёт. Ну как же, придётся работать не с сырыми указателями, а со ссылками, думать, кто владеет памятью, у кого доступ на чтение, а у кого - на запись, а то же "буручекир заругаит", ещё всякие дженерики и трейты - того гляди, последняя извилина перегорит. А ещё скобочек много, глаза болят. То ли дело православная сишка, в которой скобок меньше и код красивый, как женская сися, накидал указателей, погонял немного (код, а заодно и лысого на код)... ну, раз не падает, значит багов нет. Статическая верификация - для слабаков, а настоящий программист не примет помощи от какого-то там компилятора, и вместо 100 строк unsafe кода будет читать столько кода, сколько потребуется. Заодно и наизусть выучит, чтобы потом зайти на сервер и набрать заново, потому что Git - тоже для слабаков.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

323. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Sw00p aka Jerom (?), 23-Июн-22, 22:15 
>А вот если будешь изучать язык,

совет на вес золота, С бы так изучали

Ответить | Правка | Наверх | Cообщить модератору

330. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от burjui (ok), 24-Июн-22, 01:21 
Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт. Если даже лучшие программисты на планете их совершают, то про опеннетных экспертов я вообще молчу. К тому же, готов поспорить, что большинство из последних не знает и половины ситуаций с undefined behaviour в их любимом языке, потому что компиляторы в большинстве случаев услужливо генерят вменяемый код, а не мусор, как могли бы, согласно стандарту. А в остальных случаях эксперты вынуждены запускать отладчик и с переменным успехом искать, из какой щели сыпется мусор. Заметь, я нигде не говорю, что С - говно и т.п., как здесь принято у местной элиты по отношению к другим языкам. Я просто перечисляю объективные недостатки языка.

Если вдруг непонятно, вездесущий undefined behaviour и полное отсутствие проверки указателей со стороны компилятора - это недостатки. Мы не в 80х живём, программы сейчас намного функциональнее, соответственно, их код намного больше, и уже только из-за этого становится практически невозможно писать код на C, лишённый багов, связанных с некорректным обращением к памяти. Чем больше компилятор предотвращает ошибок, тем лучше для всех - и разработчиков, и пользователей. По-моему, это очевидно. Поэтому разработчики ядра, наученные горьким опытом, и готовы включить поддержку Rust в ядро, коль уж сишные стандартизёры, мягко говоря, не очень торопятся улучшать свой ЯП.

А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия такая, секта? Это как если бы ты на городской улице сел перекусить бутербродом, а к тебе подбежал небритый косматый человек, одетый в шкуры, и стал бы учить, как разводить баранов и выращивать пшеницу - дескать, это азы выживания, и ты не можешь считаться мужиком, если не бегал полдня с копьём за будущим обедом.

Ответить | Правка | Наверх | Cообщить модератору

341. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 24-Июн-22, 07:50 
> А вот почему на техническом ресурсе ошиваются толпы луддитов-нарциссов с гипоманией и
> нездоровой фиксацией на C, мне совсем не очевидно. Может, это религия
> такая, секта?

Может им приходилось принимать участие в разработке ядра? Если они знают Си, это вероятный сценарий. Если это так, значит часть "луддитов" говорит о том, что их так или иначе касается (насколько они правы или ошибаются - это вопрос второй). А вот что делают остальные?

Ответить | Правка | Наверх | Cообщить модератору

349. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от burjui (ok), 24-Июн-22, 10:14 
> Может им приходилось принимать участие в разработке ядра? Если они знают Си,
> это вероятный сценарий.

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

Ответить | Правка | Наверх | Cообщить модератору

352. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 24-Июн-22, 10:41 
А у Вас есть коммиты в ядро?
Ответить | Правка | Наверх | Cообщить модератору

365. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от burjui (ok), 24-Июн-22, 20:43 
Нет. Но я и не указываю никому, на чём им писать ядрёный код. Если понадобится, буду писать на Rust, а на C - только если не будет байндингов к нужным API.
Ответить | Правка | Наверх | Cообщить модератору

384. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 25-Июн-22, 07:04 
Указания уже даны https://www.kernel.org/doc/html/latest/process/submitting-pa...

Одно из требований: Check your patches with the patch style checker prior to submission (scripts/checkpatch.pl).
https://www.kernel.org/doc/html/latest/process/coding-style....

По сути, "указывающие" лишь ссылаются на официальную документацию.


Другой момент, это приём пачтей. Их смотрят минимум двое. Сопровождающий драйвер и ответственный за подсистему. Эти люди далеко не вчерашние студенты и всю жизнь писали на Си. С возрастом растёт такая штука, как когнитивная ригидность. Стойкость убеждений, если по простому. Часть разработчиков ядра не могут принять Rust не потому что "синтаксис плохой", а потому что он непривычен. Эти люди будут вынуждены покинуть проект.

Ответить | Правка | Наверх | Cообщить модератору

392. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Sw00p aka Jerom (?), 25-Июн-22, 12:01 
>штука, как когнитивная ригидность. Стойкость убеждений, если по простому.

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

Ответить | Правка | Наверх | Cообщить модератору

445. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 13:02 
Черт его знает, но если болгарка будет маленькой и CNCшной, я могу попробовать забахать что-то прикольное. И в отличие от Микеланджело не обломлюсь повторить на бис 50 раз. Или 50 000 000 раз. Иногда это по своему прикольно.


Ответить | Правка | Наверх | Cообщить модератору

454. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Sw00p aka Jerom (?), 26-Июн-22, 13:20 
> и CNCшной

вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово) и получается, что мы придерживаемся строгих правил движения, это как черчение. Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство (графику к примеру, без красок), вопрос - почему.


Ответить | Правка | Наверх | Cообщить модератору

472. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 18:26 
> вот тут надо задуматься, ибо ЧПУшку надо программировать (пошагово)

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

> и получается, что мы придерживаемся строгих правил движения, это как черчение.

Зубилом тоже не любой объект сможешь. Попробуй им полость внутри сделать без изъянов? И не любой материал сможешь. Ну, отзубиль кусок титана, допустим. А какой-нибудь 3D принтер в принципе может это обойти, другая технология - другие лимиты. При том модель он сожрет в общем то ту же самую.

> Но ведь мы не "ценим" черчение так как "ценим" изобразительное искусство
> (графику к примеру, без красок), вопрос - почему.

С другой стороны, лично я вполне оценил ролик про "костюм железного человека" на ютубе. Из титана, выдерживает попадание пуль, и даже летает (хоть и оказалось что есть нюансы). И хотя его можно повторить, это дорого, возни много, а смысла мало, к тому же надо с правообладателем опять согласовывать. Поэтому он такой один на всю планету. Зачетный артефакт так то. В общем то ценим мы, имхо, талант, креативность, оригинальные идеи и что-то неординарное. Вот именно черчеба в чистом виде как и рутинная трансляция команд этим не является. А оригинальная модель и проект в целом - уже вполне. Ну и когда оно масспродакшн то оно просто приедается и начинает восприниматься как должное.

Ответить | Правка | Наверх | Cообщить модератору

356. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Sw00p aka Jerom (?), 24-Июн-22, 13:57 
>Участник 'burjui' запретил публикацию ответов

ожидаемо

>Можно его изучать хоть 40 лет, но от ошибок в работе с памятью это не спасёт.

если складывать все яйца в одну корзину, кто виноват? Продавец или курица которая несет ломающиеся яйца?

пс: все беды людские - от ума.

"""
В комедии «Горе от ума» кто умное действующее лицо? ответ: Грибоедов. А знаешь ли, что такое Чацкий? Пылкий, благородный и добрый малый, проведший несколько времени с очень умным человеком (именно с Грибоедовым) и напитавшийся его мыслями, остротами и сатирическими замечаниями. Все, что говорит он, очень умно. Но кому говорит он все это? Фамусову? Скалозубу? На бале московским бабушкам? Молчалину? Это непростительно. Первый признак умного человека — с первого взгляду знать, с кем имеешь дело и не метать бисера перед Репетиловыми и тому подоб.
"""

Свои критические замечания о произведении высказал А. С. Пушкин в конце января 1825 года в письме А. А. Бестужеву из Михайловского в Петербург.


Ответить | Правка | К родителю #323 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру