На прошедшей на прошлой неделе виртуальной конференции "Open Source Summit and Embedded Linux" Линус Торвальдс...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53292
>Jul 2020 Jul 2019 Change Programming Language Ratings Change
>1 2 change C 16.45% +2.24%В десятке? ну ну.
а что ? к 2030-му году может много чего поменяться
или вы думаете что - Си жил, Си жив, Си будет жить вечно.
Все люди разные, даже хотя бы по синтаксису, кому-то Rust нравится, кому-то C, так что при свободе выбора C будет существовать всегда, просто потому что он уже есть.Компании конечно могут препятствовать и затруднять использование какого-либо языка на своей платформе, как google например, но тут мы уже переходим больше к гаданию будет ли вообще в 2030 году свободные платформы, будет ли возможность писать для них на языке, отличном от выбранного владельцем платформы.
Лошади, паровозы, машины, электрокары... прогресс заставит двигаться и учиться всех. C# хитро делают - ты приходишь такой, пробуешь писать концептами как c/c++ и вроде даже ок. Позволяется. Но потом читая примеры, осознавая над нужности плюшками, ты и сам не замечаешь как мутируется сознание и код уже под правильную стилистику подстраивается. И ты понимаешь, что так удобнее и быстрее ... Go не умрёт, они правильно делают - они медленно и аккуратно прогрессируют, без истерик.
C# не кактит для написания дров уровня ядра. Раст еще имеет шансы потрепыхаться, но синтаксис у него мерзотный и он порой создает больше проблем чем решает. А хайповать - это круто, но вот поливать сишников - желающих сколько угодно, а сделать что-то лучше - ноль. Как максимум на расте есть какие-то редоксы, которыми даже их авторы вроде не пользуются.
катит, но пока только для винды, но он принципиально не для этого сделан и использовать его так неправильно.
> катит, но пока только для виндыи для винды не катит
Даже UMDF юзерспейсный драйвер там пишут максимум на С++. Настоящие драйверы уровня ядра на С. Вон том огрызке, который поддерживает MSVC compiler.
> но он принципиально не для этого сделан и использовать его так неправильно.
Не "неправильно", а не возможно! Неправильно использовать С++ для таких задач.
Есть концептуальная проблема. Устройства не работают в этих красивых и прекрасных ООП-моделях. Компьютеры и устройства работают не с объектами и всяким поведением, они работают с данными и состояниями. И это не какая-та там особенность конкретного языка мешает. Это речь о том, что объектно ориентированная абстракция не может быть транслирована в машинный код, пригодный для выполнения сразу. Для того чтобы ООП работало, нужно его переделать в некое промежуточное представление (структуры, процедуры и конечные автоматы) то есть избавить его от ООП-требухи и вот полученный структурный (тоже жесткое условие на самом деле, может быть и частично неструктурный) код промежуточного языка уже можно конвертировать в машинный под нужную платформу. Естественно, некоторые языки свой промежуточный байткод не компилируют, а исполняют на лету, а некоторые компилируют, а в некоторых можно и так и сяк.
Все ООП-языки имеют промежуточное представление. Исключений нет. Так вот, если ты программируешь драйверы, тебе нужно знать точно, что делает твой код на самом деле, а не полагаться что компилятор сгенерирует правильное промежуточное представление, которое подойдет под устройство под которое ты пишешь драйвер. Другая проблема - это работа с памятью. Нужно уметь ею управлять. Все языки где присутствуют GC (сборщики мусора) работающие с промежуточными представлениями и/или компилируют на лету (JIT) не подходят для написания драйверов.
Исключением могут быть так называемые драйверы пространства пользователя. В Linux их мало, вон FUSE, например. С другой стороны это всего-лишь библиотеки, которые подключаются через специальное API и работают с теми подсистемами, которые можно размещать в юзерспейсе. Но лучше так не делать и для них. C++ тут как раз и прикидывается нормальным решением, хотя таковым не является. Его принципиальным отличием является не наличие указателей, возможности прямой работы с памятью в режиме С с классами, нет... Его отличие от нормальных ООП-языков в том, что С++ - это инвалид детства у которого нет стандарта на промежуточное представление. То есть промежуточное представление есть (компиляторы работают в 2 этапа), но стандарта нет. Именно поэтому он не просто не кросплатформенный, в нем бинарные библиотеки нормально не линкуются, если были собраны в другом компиляторе или в очень старой версии. И вот вопрос, зачем такое для драйверов, даже юзерспейсных в винде разрешают для меня вопрос... видимо один фреимворк в одном компиляторе с кучей специфичных параметров для сборки решает эту проблему. Героическое решение, для проблемы, которая была создана на пустом месте от факта разрешения писать на С++ для части драйверов. Там по-любому что-то исторически сложилось...
C# в свою очередь работает поверх CLR, как Java поверх JVM. Это вообще ортогонально любым низкоуровневым задачами.
Rust, с другой стороны, я сильно не копал. Синтаксис у него - имхо, фу. Но оно там как раз памятью управляет жестко, GC не имеет, ручное педалирование памяти умеет и не может в ООП, что, в принципе, не исключает его как возможность писать какие-то юзерспейсные дровишки сбоку, если в Linux их побольше завезут. Но, опять же, агрессивный маркетинг Rust тут сам себе противоречит.
Адепт Раста: Rust - замена C/C++ они такие-сякие и дальше по тексту...
Программист: Но ведь Rust не может... (перечень 100500 ООП-специфичных подходов)
Адепт Раста: Ты просто решаешь задачу на ООП, ООП - не задача (это правда, кстати) перерешай задачу по-другому
Программист: Но ведь есть же проект, куча народу 100500 тысяч строк зависимого кода от моей либы
Адепт Раста: Перепиши на растишку всё, весь проект, все смежные, всю экосистему, дом, квартиру, машину, дачу, контрольную, домашку, небо и Аллаха.
Программист: И в чем же тогда замена С++... Ой всё...И они бесят со своей рекламой. "Не найдётся ли у вас минутки поговорить о великом языке программирования Расте, прогрессивно заменяющем отсталые С/С++".
> Для того чтобы ООП работало, нужно его переделать в некое промежуточное
> представление (структуры, процедуры и конечные автоматы) то есть избавить его от
> ООП-требухи и вот полученный структурный (тоже жесткое условие на самом деле,
> может быть и частично неструктурный) код промежуточного языка уже можно конвертировать
> в машинный под нужную платформу. Естественно, некоторые языки свой промежуточный байткод
> не компилируют, а исполняют на лету, а некоторые компилируют, а в
> некоторых можно и так и сяк.Ну вот кстати прогеры на с++ показывали что даже на atmega их нечто с классами не так уж сильно и сливает лобовому си и даже асму - оптимизатор иногда может нехило скостить. Другое дело что оптимизатору подваливает здорово больше работенки сразу на старте и достичь такого результата наобум не получится совершенно, только долгим методом проб и ошибок и RTFMом понять как сделать оптимизатору удобно - c риском что в новой версии или от очередного изменения все это отвалится.
Синтаксис это всё же вкусовщина.
Если бы изначально существовал rust вполне вероятно, что вы бы плевались на С
> Синтаксис это всё же вкусовщина.Кроме вкусовщины есть еще тупо "больше клаву топтать". А синтаксис крайне нестабильный и оброс костылями уже почти до уровня плюсов.
интересно в 2030 хоть кто нибуль вспомнит о Rust или Go?
> интересно в 2030 хоть кто нибуль вспомнит о Rust или Go?За 10 лет гугл забросит Го и все забудут, ага.
Но вот сра^W обсуждения вида "Коболь все еще востребован и он будет востребован, пока нужно писать серьезные бизнес-приложения, а не ваши хипстерские поделки на С и Дельфях!" в 96 вполне себе в юзнете были.
Кстати, очень (по смыслу) напоминают современные сентенции местных вида "Си жил, Си жив, Си будет жить вечно, и вообще, вы все просто хипстеры-вебмакаки!" ;-)
https://groups.google.com/forum/#!msg/alt.cobol/UlEF9JgaqgE/...
(это то, что более-менее осталось. Гугл, зараза, как обычно, сначала перевел альтернативные хранилища архивов в разряд "нинужно! теперь мы будем хранить старые базы!", а потом, через пару лет, убрал из доступа).
COBOL - в 96 ? Не смешите. Реализации на ПК COBOL-а я не упомню ... Конечно может в какой нибудь эхе ru.cobol И были такие споры и то вряд ли ...А вот где-нибудь на конференциях конца 80х - да ... вполне были такие ораторы.
> COBOL - в 96 ? Не смешите. Реализации на ПК COBOL-а я
> не упомню ... Конечно может в какой нибудь эхе ru.cobol И
> были такие споры и то вряд ли ...Хм, верно -- ссылки в комментарии я добавляю исключительно в виде декораций и смеха ради 🙄
> alt.cobol ›
> 21.11.96
> The "Cobol is Dead" phrase is the biggest Urban Legend of them all. I've been hearing it now for 20 years. It is the dominant language. There is almost as much Cobol code in the world as there is all the other languages put together..
> Sure it's outdated, sure it's cluncky, and certinly it is old, but there are more lines of COBOL in the world right now than anything else. It will not go away. I would rather see Delphi running on networked PC's to keep up with everything but too many COBOL progs.
> 80% of all code out there is COBOL, its portable, open systems, scalable, ODBC Complient, it talks to all those.
> programming languages don't die. And with all the millions of cobol lines that exist, and all the new development being made in it, dead is not avery good descriptor.
> We actively educate new people in the language, and our business is hot like never before..
.> может в какой нибудь эхе ru.cobol
Вы льстите опеннету -- публика здесь тоже весьма ... специфичная.
>Реализации на ПК COBOL-а я не упомнюТа я вас умоляю - в свои 14 лет ты его и не должен помнить.
А у вражин US Gov - был в фаворе, по крайней мере в начале 2000-х оне во всю юзали ACU-COBOL на писюках и Санах.
если еще до 2030 года гугла не повторит судьбу Yahoo...
> если еще до 2030 года гугла не повторит судьбу Yahoo...С чего бы это?
> За 10 лет гугл забросит Го и все забудут, ага.Они забросили пикасу, гугл+ и даже пресловутый google code, чего им там какой-то ЯП? Придут через 10 лет новые хипстеры решившие что go не круто - и гудбай. Судьбя проектов с 1 корпорацией такая.
>> За 10 лет гугл забросит Го и все забудут, ага.
> Они забросили пикасу, гугл+ и даже пресловутый google code, чего им там
> какой-то ЯП? Придут через 10 лет новые хипстеры решившие что go не круто - и гудбай.И заодно сотрут большей части современников память, плюс уговорят выбросить go из gcc (это при том, что gcj оттуда аж лет через 9-10 после заморозки разработки удалили)?
10 лет довольно малый срок, особенно если речь не о маргинальщине типа Nim или Vala.> Судьбя проектов с 1 корпорацией такая.
Это да.
Кхе.
Кто еще помнит проект из AT&T/Белл Лабс, от некого Бьярна С. который сначала расширил не менее курьезный проект (ЯП названный одной буквой, Z или S или что-то в этом роде!) некого Денниса Р. из той же конторы, а затем создал новый ЯП и чей единственный компилятор был много лет "стандартом"?
Или этот маргинальный островно-кафейный ЯП от некой Sun? Или язык (начинался на F, кончался кажись на ortran, а остальное не помню :( ) от IBM?
Никто.
Такова судьба проектов с 1 корпорацией.
Кхе.
> И заодно сотрут большей части современников память, плюс уговорят выбросить go из
> gcc (это при том, что gcj оттуда аж лет через 9-10 после заморозки разработки удалили)?Ну так кто этим gcj всерьез пользовался последние 10 лет? Был чисто для галочки.
> 10 лет довольно малый срок, особенно если речь не о маргинальщине типа Nim или Vala.
Для хайпанутых вебмакак - это дофига. У них типовой период полураспада проекта = 2 года.
> Кто еще помнит проект из AT&T/Белл Лабс, от некого Бьярна С. который
> сначала расширил не менее курьезный проект (ЯП названный одной буквой, Z
> или S или что-то в этом роде!) некого Денниса Р. из
> той же конторы, а затем создал новый ЯП и чей единственный компилятор был
> много лет "стандартом"?Ну так си пошел в массы после .. совсем другого гражданина, с фамилией Столлман, которому вот было западло быть придатком к корпорации. И вот с тех пор все как раз и завертелось. А именно классический K&R C нынче не используют даже самые утонченные из некрофилов. Да что там, он к 1989 году из фавора выпал чуть более чем совсем, C89 уже не этсамое - K&R'овский синтаксис там как раз и - того.
Ну а на яве или фортране дельных проектов полторы штуки и есть. В основном энтрепрайзный крап (жаба) да научная лабуда, пардон, но ученые не больно какие вообще програмеры по жизни.
>> И заодно сотрут большей части современников память, плюс уговорят выбросить go из
>> gcc (это при том, что gcj оттуда аж лет через 9-10 после заморозки разработки удалили)?
> Ну так кто этим gcj всерьез пользовался последние 10 лет? Был чисто для галочки.И при этом его не спешили выкидывать эти 10 лет.
Go на вид как ЯП, по дизайну куда проще и уж продолжить ковырять и развивать его при желании можно без особых технических проблем.> Ну так си пошел в массы после .. совсем другого гражданина, с фамилией Столлман, которому вот было западло быть придатком к корпорации. И
> вот с тех пор все как раз и завертелось.Раньше. Тем более, gcc -- проект 1987 года (причем я сомневаяю, что версии до 1990 были конкуренто-юзабельны), это аж 15 лет после появления Си. 15 лет проект был с "1 корпорацей".
Но так как мне лень было копать историю всех компиляторов Си, я взял в качестве примера Бьерна Страуструпа с его С++.
> Ну а на яве или фортране дельных проектов полторы штуки и есть.
> В основном энтрепрайзный крап (жаба) да научная лабуда, пардон, но ученые
> не больно какие вообще програмеры по жизни.Во-первых - фортран разработка IBM 50х годов (объемы кода тогда были весьма скромными) и то, что он все еще используется, немного намекает на инертность.
Во-вторых: жаба все еще повседневна вне тырь-прайзов -- в тех же андроидах.
В-третьих: к "на яве или фортране дельных проектов полторы штуки и есть. " мне лень что-то писать - пальцы с трудом пробивают слой жЫра из монитора. Особенно когда сначала вопрос шел об "использовании" и "забрасывании", а не о "дельных проектах" 🙄
> И при этом его не спешили выкидывать эти 10 лет.Таскали по привычке, номинально. Реально им что-то скомпилять... потому и удалили :).
> Go на вид как ЯП, по дизайну куда проще и уж продолжить ковырять и развивать
> его при желании можно без особых технических проблем.Только при наличии такого желания у такой корпы. Желания у гугла порой меняются. Остальные не смогут, а альтернативных экосистем по сути и нет. Все завязано на 1 корпу.
> Раньше.
Да ща. Тогда компов у народа толком не было, узкая группа бородатых хипстаков в датацентре с дорогими игрушками - нифига не массово.
> Тем более, gcc -- проект 1987 года (причем я сомневаяю, что версии до 1990 были
> конкуренто-юзабельны), это аж 15 лет после появления Си. 15 лет проект
> был с "1 корпорацей".Ну так и линух появился в начала 90х как раз. А до этого момента IT вообще был мягко говоря весьма не массовой штукой. В том числе и по причине конских ценников и условий на базовые инструментарии. Так что до того момента сие было довольно маргинальным развлеченьицем. А студень смог попробовать только потому что вот такой пререквизит подогнали.
> Но так как мне лень было копать историю всех компиляторов Си, я
> взял в качестве примера Бьерна Страуструпа с его С++.Ранние компиляторы си были, конечно. Но достаточно чудесатые и не похожие даже на C89 который сейчас минимальное что за именно си считается. Все что до него современные сишники тупо не сжуют/будут лажать в синтаксисе.
> Во-первых - фортран разработка IBM 50х годов (объемы кода тогда были весьма
> скромными) и то, что он все еще используется, немного намекает на инертность.Ну так код на нем есть. И даже работает. Но гугол - это не айбиэм по своим парадигмам и подходам :P.
> Во-вторых: жаба все еще повседневна вне тырь-прайзов -- в тех же андроидах.
Ога, ява которая типа не ява но немного ява, и гугл по судам задолбался бегать :). И как бы эта ява бесполезна без вон того сишного кернела вон того студента, кста.
> слой жЫра из монитора. Особенно когда сначала вопрос шел об "использовании"
> и "забрасывании", а не о "дельных проектах" 🙄И все же я глядя на гугл вижу что они не испытывают проблем с сливом в утиль ударными темпами чего угодно, как только это перестает отвечать их интересам или просто надоедает их хипстоте. Это вообще совсем не айбиэм.
>фортран разработка IBM 50х годов (объемы кода тогда были весьма скромными) и то, что он все еще используется, немного намекает на инертность.Современный фортран только называется фортраном, а по сути это уже не тот первоначальный фортран, а алголоподобный язык.
эти проекты стали живыми как только перестали быть проектами одной корпорации, го до этого ещё не дорос, он хоть и лучший в своей нише имеет все шансы потерять актуальность однажды, а переходить с го на его лучшую замену должно быть ещё проще чем переходить сейчас на го..
> За 10 лет гугл забросит Го и все забудут, ага.Учитывая что Go уже 11 лет существует только с релиза (а если с момента разработки считать или того-же Plan9 и того больше), забросят они его, ага.
Если бараны в руководстве Гугла или M$ возьмутся за D, есть реальный шанс подвинуть все эти неуклюжие си-сипипишечки и заменить современным языком. Если большой финансовой поддержки не будет, даже хороший язык рискует кануть в лету.
ты хоть понимаешь что все что можно уже написано на крестах и сях, переписывать предлагаешь? ты псих парень
> или вы думаете что - Си жил, Си жив, Си будет жить вечно.Двигатели внутреннего сгорания без каких-то радикальных изменений уже эдак полтора века. И ничего, ездят. Да и электромобили не сильно новее, и то их до ума только-только доводят.
Пока нет замены С. Go и Rust это просто хайп. Rust страдает той же болезнью что C++ - перемудреный синтаксис. А Go хоть и позиционирует себя как системный язык таковым не является, ну или пока нет компилятора который гвоздями не прибивает runtime который нужно откручивать ручками путем подстановки хитрых коментарий-макросов чтобы обхитрить линкер и засунуть свою точку вхождения а не ту которая в рантайм, потом еще кучу других вызовов таким образом переписать... Ну и компилятор конечно любит вставлять инструкции из всяких не стандартных instruction set extansions от intel (у гугла на серверах работает, а на остальных плевать), И, в итоге, приходится отказаться от большинства плюшек самого языка или писать свое ноу-хау на их ассемблере, в итоге ты получаешь те же проблемы что и С - а именно ручное управление памятью, ассемблерные вставки, и вся безопасности языка капут. Хотя если сделать микро-ядро и часть системы на С и asm писать, а часть на go, ну или внедрить WebAssembly VM в ядро то да можно на сегодняшнем go и официальном компиляторе писать дравав и части системы...
Вроде как первые релизы компилятора Го могли компилировать "чистый код" без рантайма совершенно. Тогда были еще проекты Golang OS, еще задолго до Redux. Потом решили убрать эту фичу, так как почуяли нишу для языка: прикладной серверный софт. Вроде так было.
В любом случае Го прекрасный язык по написанию, в отличие от Раста. Однако возможности раста в го - в подходе управления памяти, обработки ошибок - были бы просто шикарны. Имхо.
Да, Go хорош для впихивания во всякие контейнеры и написания всякого разного аля микросервисы. Только вот писать дрова на нем это жуть затея. Я вот думаю а не взять ли мне и написать свой диалект на основе go и Ownership MM как в rust. Выкинуть от туда их затею с урезанием управления потоков, сделать корутинки как отдельную библиотеку, добавить нормальные макросы а не через попорукие комментарии в коде в магических местах, добавить в пакеты метаданные с номером версии и т.д.
https://tinygo.org/
Tinygo воде как был заброшен, разве нет?
Не слежу внимательно, но коммиты есть
aykevl authored and deadprogram committed a9ba6eb Apr 21, 2020
но речь то не о конкретном проекте, а о том можно ли использовать гоу для системного программирования, ну вот тут взяли и сделалм и для вполне популярного железа
https://tinygo.org/microcontrollers/machine/stm32f4disco/
https://tinygo.org/microcontrollers/machine/nucleo-f103rb/есть и другие заходы для работы с железом на гоу
https://godoc.org/github.com/kidoman/embd
Control GPIO pins on the RaspberryPi / BeagleBone Black:
import "github.com/kidoman/embd"
...
embd.InitGPIO()
defer embd.CloseGPIO()
...
embd.SetDirection(10, embd.Out)
embd.DigitalWrite(10, embd.High)хотя лично я особой нужды в этом не вижу, подмножество с++ было бы вполне разумным выбором, ну если бы разум был бы конечно
> есть и другие заходы для работы с железом на гоуЗапрыги. На грабли. Чего в игого для этого хорошего? :)
> хотя лично я особой нужды в этом не вижу, подмножество с++ было
> бы вполне разумным выбором, ну если бы разум был бы конечноНу тады ардуина с serial.begin() твое все...
"Си не умрет никогда, так и знай!"
Переход на какой-нибудь rust может быть лавинообразным. Если rust в ядро допустят и он действительно покажет какие-то *существенные* преимущества в безопасности и/или скорости написания, то никто уже не захочет писать на C и весь новый код будет писаться на нем.
Сейчас разговоры только о том, чтобы разрешить разработку драйверов на расте. А кроме драйверов там еще куча всего. Поэтому очень сомневаюсь, что раст станет основным языком ядра в ближайшее десятилетие.
а если никто не захочет писать и поддерживать говнокод на русте?
> то никто уже не захочет писать на C и весь новый код будет писаться на нем.Ну во первых вы так лихо расписались за всех...
Во вторых, а кто перепишет вон те сотни кода?
BSD системы и с меньшим числом справляются с релизами.
Сравнил... По количеству кода разница огромная.
И тут мы плавно перешли к теме раздутости Linux ядра.
Нет, к теме отсутствия драйверов (даже с учётом их тыринга).
Занятно. Каких Вам драйверов не хватает?
Не хватает на ТВ тюнер и плату видео захвата.
Михаил про поддержку значительно меньшего количества железа в xBSD по сравнению с Linux. Взять, например, SoCи и SBC на ARM, MIPS.
Ну так уговорите или заставьте китайца или корейца писать и под bsd - возможно даже, его патчи туда примут, в отличие от л@п4атых, заставляющих вечно гнаться за механическим зайцем со своим форком, потому что не так подано.Или вы думали, эту поддержку писал последние лет двадцать для линyпса кто-то, кроме самих авторов тех soc?
> для линyпса?
Так и что ты сказать-то хотел? Что эти китайса и корейца тоже в числе того большего количества разработчиков, что пилят модули для Linux? Ну тогда всё правильно, xBSD не могут меньшим числом человеческих ресурсов сделать столько же драйверов.
А почему их не надо так уговаривать писать поддержку их девайсов для Linux, как для xBSD, то это уже другая история.
> Так и что ты сказать-то хотел? Что эти китайса и корейца тоже в числе того большего количества
> разработчиков, что пилят модули для Linux?угу. "В числе" хорошо оплачиваемых разработчиков фирм и фирмочек, выпускающих эти SoC. К линуксу имеющих только то отношение, что насяльника приказал хэрачить под линyпсь - "мы поставим туда ведроид!"
Прикажет насяльника хэрачить под фикцию или как там ее - твое "большое количество разработчиков" на следующий же день будет разработчикам-под-фиксию, а кто не все - того кнутом выпорют, чтоб казенное время зря не транжирил.
> xBSD не могут меньшим числом человеческих ресурсов сделать столько же драйверов.
никто не может. Драйвера пишут в "2k20" - производители железок. Если они пишут их только под винду - значит, будет работать только под виндой.
>[оверквотинг удален]
> угу. "В числе" хорошо оплачиваемых разработчиков фирм и фирмочек, выпускающих эти SoC.
> К линуксу имеющих только то отношение, что насяльника приказал хэрачить под
> линyпсь - "мы поставим туда ведроид!"
> Прикажет насяльника хэрачить под фикцию или как там ее - твое "большое
> количество разработчиков" на следующий же день будет разработчикам-под-фиксию, а кто не
> все - того кнутом выпорют, чтоб казенное время зря не транжирил.
>> xBSD не могут меньшим числом человеческих ресурсов сделать столько же драйверов.
> никто не может. Драйвера пишут в "2k20" - производители железок. Если они
> пишут их только под винду - значит, будет работать только под
> виндой.Согласен, что производители, меня тут весной убеждали в обратном
И спустя сотню таких драйверов, принятых в ядро фич, мы платно перейдём к теме раздутости кода xBSD...
Бесит, что в ядре слишком много незадействованных драйверов? Собери без них. Лучше пусть будет безопасная совместимость, чем армагеддон для корпоративного клиента и обычного юзера.
Linux, при прочих равных система, на которой работает огромное количество разных устройств. Не хотите пользоваться заранее кем-то собранным ядром - пересоберите под своё устройство, дел на пол часа. С другой стороны Вас никто не заставляет им пользоваться. За Вас написали код, протестировали, опубликовали релиз, далее разработчик используемого Вами дистрибутива взял исходники ядра, собрал из них пакет, выбрал ещё много различного программного обеспечения, которое тоже кто-то написал, выбрал не скучыне обои на рабочий стол, всё это протестировал (как смог), опубликовал релиз уже готового дистрибутива, только после этого глубокоуважаемый пользователь опеннета соизволил скачать бесплатный образ, установить на свой компьютер, потом используя труд вышеупомянутых коллективов открыл свой любимый бесплатный браузер, зашёл на сайт и написал как же его бесит, что там столько незадействованных драйверов...
у меня есть вопроса как обновлять ядро?
ведь дыра в ядре требует билдить заново с патчами
а это не то же самое что dnf update
возможно в арче это как-то решено, но я точно не знаю.. поэтому и спрашиваю
>а как обновлять ядро?Просвещаться. Инфы на эту тему полно.
>ведь дыра в ядре требует билдить заново с патчами
Можно скачать последний минорный релиз LTS-ядра. Это и есть последнее пропатченное от известных на данный момент уязвимостей. И его собрать.
> Занятно. Каких Вам драйверов не хватает?На видеокарты, например. Свежие gpu не работают, с нвидиями только проприетарный позор какой-то. Использовать открытую систему для того чтоюы ее блобами загадить? А смысл?
Больше функций — больше кода, в чём вопрос?
Четыре драйвера NTFS, три драйвера exFAT, зоопарк файлух и гора драйверов для экзотики - это не "больше функций", а "помойка".
> экзотики - это не "больше функций", а "помойка".Тем не менее, по состоянию на сейчас драйвер exFAT допустим тот же что самсунь на свои телефоны поставляет. А у бздюков, извините, чего?
А у бздюков всё самое нужное и протестированное на бесплатных пингвинистраторах. Не забудь поставить арч, так ты привнесешь много отлаженного кода в FreeBSD!
>> экзотики - это не "больше функций", а "помойка".
> Тем не менее, по состоянию на сейчас драйвер exFAT допустим тот же
> что самсунь на свои телефоны поставляет.Кто о чем, а пингвиноиды о проприетарной запатентованной FS Платинового Партнера?
> А у бздюков, извините, чего?exfat-utils
fuse-exfat
Читать и писать внешние флешки и SD карты хватает за глаза, а для чего-то иного оно как-то и не нужно, цитируя анонима выше "Использовать открытую систему для того чтобы ее проприетарным запатентованным хламом загадить? А смысл?"
> Кто о чем, а пингвиноиды о проприетарнойА уже и опенсорсной...
> запатентованной FS Платинового Партнера?
Ну так они на патенты раскрутились. Видимо стрижка купонов не перевешивала урон репутации в этом случае.
> exfat-utils
> fuse-exfatНу, блин, fuse это конечно здорово, но ресурсы он жрет как не в себя.
> Читать и писать внешние флешки и SD карты хватает за глаза
Фэйл в том что обычно это надо мелочи типа смартфонов и прочих гаджетов. Впрочем, у бздюков и с этим облом.
>> Кто о чем, а пингвиноиды о проприетарной
> А уже и опенсорсной...Еще и года с открытия спеков не прошло. А дрова писались и включались значительно раньше.
>> запатентованной FS Платинового Партнера?
> Ну так они на патенты раскрутились. Видимо стрижка купонов не перевешивала урон репутации в этом случае.Да-да, 13 лет раздумывали и когда уже Google с Apple собирались послать в Ж, решили проявить великодушие.
Похоже, отмазывать Платиногово Партнера - для пингвиноидов святое.>> exfat-utils
>> fuse-exfat
> Ну, блин, fuse это конечно здорово, но ресурсы он жрет как не в себя.100500%, не меньше?
>> Читать и писать внешние флешки и SD карты хватает за глаза
> Фэйл в том что обычно это надо мелочи типа смартфонов и прочих гаджетов. Впрочем, у бздюков и с этим облом.Фейл в том, что ипользовалось и используется оно, в основном, в закрытой проприетарщине, с которой перепончикам обычно перепадает дырка от бублика и код для загрузки проприетарных блобиков.
Не ври.
В ядре один драйвер NTFS, и один драйвер exFAT.
Для FUSE так же по одному.
Грустно однако про мейнтейнеров((
Кмк снизился порог входа и стало много временных молодёжных, модных, неособо развитых.В общей массе стала меньше доля людей университетского уровня.
И искать стало сложнее.
А как же инклюзивность и толерантность? Неужели гендерно-, расово- и умственноальтернативные не могут писать код?
Пусть пишут альтернативный линукс
И имя ему будет Калукс ))
> И имя ему будет Калукс ))Это вы Редокс так? Или реактос?
Вот в том и проблема, что все инклюзивные и толерантные, а мэйнтейнер должен на говно говорить говно.
Официант! Бутылку чаю этому анониму за то, что зрит в корень.
Если он толерантен то не должен отклонять код, ведь это оскорбит его автора! А за оскорбление людей, особенно состоящих в меньшинствах, нынче можно получит волчий билет.
А за это его потом епут, а ведь не должны. Должны уважать и почитать.
Пусть лучше свой отдельный форк форкают - Linuximple. И там хоть на Расте, хоть на Брейнфаке.
Давно известно как проблему с мэйнтейнерами можно решить, причем отказ от Си будет чревато усложененим всего процесса, но никто этим сейчас не занимается (по крайней мере нет данных про это в публичном доступе).
Заменить C на JS для привлечения инклюзивных мейнтейнеров-макак?
вчитайся> причем отказ от Си будет чревато усложененим всего процесса
то есть от Си отказываться крайне не желательно
ваш вариант
> Заменить C на JS
то есть ваш вариант противоречит тому что подразумевалось. Значит ваш вариант ошибочный. Вот ведь могли же свою гиоптезу оттестировать оффлайн у себя в мозгу прежде чем сюда постить? Или не могли...
Тогда как можно проблему с мэйнтейнерами можно решить?
Ответ не дам, но дам направление где можно найти ответ: аналитики к решению в теории пришли в конце 60х - начале 70х годов. К настоящему времени "прогресс" сбился с пути и идет по другой дороге.// минусуйте :)
Haskell?
> Тогда как можно проблему с мэйнтейнерами можно решить?Ну, блин, редоксы и прочие фуксии и так уже есть. Только ими пользоваться никто не хочет почему-то, пока сишные майнтайнеры есть.
Главное, чтобы на опеннете было поменьше инклюзивных комментатор как ты.
Не поддерживаю инклюзивность в отношении таких значимых проектов, как ядро.
То ли дело раньше: деревья были выше, трава - зеленее, люди - умнее.
> люди - умнееРаньше выборка и окружение (технологии) были другими, некорректно сравнивать вчерашнюю выборку с сегодняшним днём.
А так и было. И трава зеленей, и люди -- умней. Только бабы сейчас лучше, потому что новее.
жжешь
Просто разработчик может не подразумевать полную занятость - и соответственно оплату.
А мантейнером трудно быть в свободное от остального время, о чем Линус и сказал. Поэтому нахаляву редко кто пашет.
Ничё, вон запреты мастер-слейв в именах недавно ввели, сейчас заживут. Желающие толпами попрут.
Драйверы на Go и Rust - эх... Не хочется, чтобы C канул в лету.
Да не канет он никуда. Не в нашей жизни как минимум. Языка, реально способного его заменить, еще не придумали.
Ужe https://github.com/ziglang/zig
зиг-шмиг... Я вот впервые об этой шняге слышу. Но раз в несколько лет кто-то обязательно выложит очередного убийцу С. А С тем не менее живее всех живых.
> лет кто-то обязательно выложит очередного убийцу С. А С тем не
> менее живее всех живых.При том такая фигня уже лет 30. Еще вон в колибри какой-то си-- сделали. Интересно чем им просто си не угодил? То что они на асме кодить заколебались все уже догадались :)
А как же BitC?
Сколько раз повторять: есть кнопка "исправить". Нажми её и сделай вычитку. Это опенсорц, детка.
Ну не платят мне за вычитку чужих статей. У меня своей работы навалом, детка.
> Ну не платят мне за вычитку чужих статей. У меня своей работы
> навалом, детка.Навалом работы, значит навалом денег? Найми человека, который будет вычитывать статьи, до того, как ты прочитаешь их. Или найди ресурс, где такой человек уже нанят.
И правда, столько веселухи вокруг переполненных буферов пропадёт
Если код будет работать и буферы не будут переполняться - то что будут кушать программисты? Сейчас на C регулярно есть, что мейнтейнить. Тут CVE, там CVE. А на Rust написал - и всё, деньга уже не падает, пишешь другое, а старое в сопровождении и починке уязвимостей не нуждается.
Так тонко, что аж толсто.
>на Rust написал - и всё, деньга уже не падает, пишешь другое, а старое в сопровождении и починке уязвимостей не нуждаетсяЭто фантастика, детка.
>Если код будет работать и буферы не будут переполняться - то что будут кушать программисты?Так это - вообще без работы сидеть не будут.
Сделали буффер на 4К - строки длиннее не принимаем. Захотели 4K + 1байт - с вас стоточка и т.д.Все почему-то думают, что "управляемая память" она же "унутре у ней думатель" работает максимально эффективно. А на самом деле робот не дурак - все делает на отеб.сь.
Да-да, у олигофренов сразу отрастут мозги. Тот кто не понимает как софт работает изнутри, что разработка софта это инженерная задача, не поймёт ни барроу-чекер, ни лайфтаймы. Точно также как он не понимает как работать с памятью в Си. В расте, он намучившись с ошибками компиляции, найдёт ансейф и сишную-либу и всё пойдёт по-старому. Самый оптимальный вариант, если он перейдёт на джс или гоу, питон, а вдруг и правда работа с памятью единственное непреодолимое для него припятствие. Самое интересное, что это никак не зависит от того сколько лет человек работает с языком. Сишники с 10-15-летним стажем пишут такие же какашки, как будто бы они поколение Z. Когда указываешь на это - "Да я вижу, я знаю, я хотел потом изменить и т.д.". Это говорит о том, что человек не способен к решению инженерных задач и лучше от него избавиться. Иначе придётся это "я знаю" слышать каждый раз. Такие люди не понимают, что прежде чем что-то писать, нужно это спроектировать, даже мелочь. Если в Си проблемы с памятью, нужно выделить эту работу в отдельный изолированный модуль, обложить детальными проверками и диагностикой. Доступ на изменение к этому модулю только ответственным за него, остальным - выставить наружу стабильный, документированный ЭйПиАй к нему. Все изменения в нём только через реквесты, никакой самодеятельности. Ой, к чему же мы пришли? А к разработке софта как к инженерной задаче, а не как к охоте стаей макак за бананами.
Дальше первой строки даже не читал, сорян, нытьё локальной илитки неинтересно
Тогда шагай в своё зaднee oтвepстие со своим мнением.
Драйвера на Rust и Go будут в Unsafe всё-равно, так как прямого доступа к памяти у Rust и Go нет. Так что опять те же грабли. Может растовики поменяют архитектуру современных компьютеров полностью тогда, вместо того, чтобы костыли выдумывать?
известные мне попытки "поменять архитектуру" в угоду языку (Пролог и японские 5го поколения, Модула-2, Оберон) кончились пшиком.
Лисп-машины были прекрасны
> Лисп-машины были прекрасныну и где те лисп-машины ?
а i386 и amd64 до сих пор с нами.
> известные мне попытки "поменять архитектуру" в угоду языку (Пролог и японские 5го
> поколения, Модула-2, Оберон) кончились пшиком.Зато у системщиков получилось - современное железо удобнее всего программить из си. Потому что mem-mapped регистры. Из сей с этими их указателями как раз очень удобно все это обтяпывать. А вы сцыте в штаны от указателей? Ну тогда и железо себе придумайте заодно. Очень интересно получится ли такой же пшик как с прологом и чем там еще.
> Зато у системщиков получилось - современное железо удобнее всего программить из си. Потому что mem-mapped регистры.А ветер дует, потому что деревья качаются!
> А вы сцыте в штаны от указателей
EXAMPLE 2C: ==> Modula-2:
typedef T1 *T; TYPE T = POINTER TO T1;
EXAMPLE 4
The define directive for ptr_t translates to a Modula-2 address type:
C: ==> Modula-2:
#define ptr_t void * TYPE ptr_t = SYSTEM.ADDRESS;
Ох уж эти опеннетные Знатоки!
> Очень интересно получится ли такой же пшик как с прологом и чем там еще.
>> "поменять архитектуру" в угоду языку (Пролог и японские 5го поколения, Модула-2, Оберон)
>> Prolog. Warren's Abstract Machine,
>> SLD-resolution, (Selective Linear Definite clause resolution)
>> SLD resolution implicitly defines a search tree of alternative computations,"поменять архитектуру"
рукалицо.бмп
Мне вот интересно, откуда вы такие "красивые и экспертные" беретесь?
Да ладно уж сразу модулу-2, специалистам по указателям надо еще до нее было не прогуливать занятия по паскалю в школе
> было не прогуливать занятия по паскалю в школеВ паскале указатели очень уж паск...удные :). В смысле, они там конечно, есть, но пользоваться ими там крайне мучительно. Вот никто ими там и не пользуется. Особенно в школе. Конечно особые чудаки даже саундбластер напрямую прогали, но очень уж мучительно это на паскале, так что надолго таких джеди не хватало.
Туда же и чудные упражнизмы на модула чотатам. Сами так и програмьте, если вам это нравится :). Мощь сей в том что можно САМОМУ сделать себе все врапперы/имплементации. А когда какое-то УГ навязывает свою имплементацию прибитую на гвозди, и это вдруг оказалось в конкретном случае допустим неудобно или неэффективно - сишник то чертыхнется и накодит себе свой вел с кадратными колесами, отлично подходящий для заездов по именно вот таким вот лестницам. Паскалист спятит, а програмер на модуле - пойдет ныкаться в подземном марсианском городе дальше.
> Драйвера на Rust и Go будут в Unsafe всё-равно, так как прямого доступа к памяти у Rust и Go нет.https://github.com/rust-embedded-community/pc-keyboard/searc...
https://github.com/lizhuohua/linux-kernel-module-rust/search...
З-знатоки-и-и опеннета.
Что хотели сказать-то? Во втором проекте куча unsafe. Кроме того, в описании проекта прямым текстом в Roadmap'e: Minimize the use of unsafe Rust.
> Драйвера на Rust и Go будут в Unsafe всё-равно ... Так что опять те же грабли
> Что хотели сказать-то?/0
> Во втором проекте куча unsafe.
8 code results
pub extern "C" fn cleanup_module() {
unsafe {
-
unsafe extern "C" fn smsc9512_bind
-
unsafe impl GlobalAlloc for KernelAllocator {
unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
-
unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) {
kernel::kfree(ptr as *const c_types::c_void);
/0
> Кроме того, в описании проекта прямым текстом в Roadmap'e: Minimize the use of unsafe Rust.То ли дело один сплошной unsafe ...
Где в этом куске кода вообще хоть какая-то работа с оборудованием? То что вы сумели переизобрести сишные приколы с памятью на расте - ну, круто, а нафига тогда вперся раст? :)
> Где в этом куске кода вообще хоть какая-то работа с оборудованием?Причем тут оборудование, когда речь о якобы "куче unsafe"?
Или как обычно, анон нихрена не понял, но увидел знакомые слова и решил высказать ценное мнение?
> То что вы сумели переизобрести сишные приколы с памятью на растеКакие-какие? А точно сишные? Зуб даешь? Или окажется как обычно - «не в лоторею, а в карты, не выиграл, а проиграл».
> ну, круто, а нафига тогда вперся раст? :)Нафига луддитам вперся станок с ЧПУ, если у них есть кузница с наковальней?
оиuse std::env;
fn main() {
let args: Vec<String> = env::args().collect();
let mut i: usize = 0;
if args.len() > 1 {
i = args[1].parse::<usize>().unwrap();
};// Fixed-size array (type signature is superfluous)
let xs: [i32; 5] = [1, 2, 3, 4, 5];println!("N element of the array: {}", xs[i]);
}
И?./main 5
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', main.rs:16:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
./main
N element of the array: 1
а то что это ничем не отличается от полюсов.#include <iostream>
#include <string>
#include <array>int main(int argc, char *argv[]) {
size_t i = 0;
if (argc > 1)
i = std::stoul(std::string (argv[1]));
std::array<int, 5> a = {1, 2, 3, 4, 5};
try {
std::cout << a.at(i) << std::endl;
} catch (...) {
std::cout << "out of range" << std::endl;
}
}
а если случайно вместо a.at(i) написать a[i], то все рассыпается.
а если в раст использовать unsafe то тоже
Это как бы разные вещи. В случае С++ очень многое "unsafe" или провоцирует очень плохие(опасные) практики программирования (как, например, try ... catch). Человеку как бы говорят - вся ответственность лежит на тебе. (Ты же проштудировал 1000+ страничный талмуд Страуструпа и знаешь все подводные камни стандарта.)В случае Rust, если ты пишешь unsafe, то говоришь я знаю, что я делаю, всю ответственность беру на себя.
Есть разница между
1)вся ответственность лежит на тебе по умолчанию, т.к. должен знать
2)всю ответственность беру на себя в данном конкретном случае, т.к. знаю, что делаю
В этом и опасность раста. От кривого кода компилятор не спасёт, от необходимости думать не избавляет. Но фанатики раста про это забывают. Особенно молодые, свято веря что великий компилятор их спасёт.Но нет, от быдло кода компилятор не спасёт. Ни больше чем ни меньше чем современные плюсы. И в этом проблема, люди то верят.
> Но нет, от быдло кода компилятор не спасёт. Ни больше чем ни
> меньше чем современные плюсы. И в этом проблема, люди то верят.Более того - более сложный рантайм и компилер дают больше точек непредсказуемости и факапов. Что довольно плохо для низкоуровневых вещей. Особенно если компилер выкатывают раз в месяц и старый тут же выносится в obsolete. Это может и катит для браузера, но полный шыт для кернела, бутлоадеров и тем более эмбедовки.
>> Но нет, от быдло кода компилятор не спасёт. Ни больше чем ни
>> меньше чем современные плюсы. И в этом проблема, люди то верят.
> Более того - более сложный рантаймС фига ли?
> и компилер дают больше точек непредсказуемости и факапов. Что довольно плохо для низкоуровневых вещей.Очередные Теоретические Размышлизмы Анонимов Опеннета,
которые в код gcc ни разу не смотрели, регулярные матерные тирады Линуса в LKML по этому поводу не читали?
> С фига ли?Яп сложнее, больше фич по дефолту втуливает.
> которые в код gcc ни разу не смотрели, регулярные матерные тирады Линуса
> в LKML по этому поводу не читали?Читали, читали. И могут представить себе что будет с кодом если матерные тирады завернет какой-нибудь убуханый корпоративный растаман-затейник.
Зачем у тебя int main, если main ничего не возвращает?
> Зачем у тебя int main, если main ничего не возвращает?Вообще, операционкой от программы код возврата ожидается...
интересно сколько ещё стильных модных молодёжный систем сборки под этот зоопарк ЯП потянется.наверное, чтобы собрать простейший модуль с исходкком в 2 килобайна придётся тянуть среду разработки и рантайм в пару гигабайт
profit
VS Code, никак не меньше.
> VS Code, никак не меньше.да не, сразу VisualStudio
но тк она официально работает только в MacOS и Windows, то и способа собарть модулья ядра Linux из-под Linux не будет
Profit!
Драйверов на го не будет никогда, го коммунити целиком и полностью состоящее из вебмакак не в состоянии писать сколько-нибудь сложный код.Раст не взлетит потому что мозилла слишком маленькая, чтобы толкать этот язык в массы.
> Драйверов на го не будет никогдаВ фуксии попробовали. Лулзов откушали знатно. И видимо именно поэтому оно и останется toy os для вебмакак.
Вы можете сколь угодно много хвалить Си. Это хороший язык. Но не язвите, говоря на другие языки, оправдывая это тем, что некогда давно написанный проект не перенести с Си на что-то иное, только потому что это убьёт проект. Парадигмы раста убивают многие ребяческие проблемы С/С++. Да, это молодой проект, но вы ошибаетесь, если ставите на нем крест только из-за этого, попутно молясь рудиментарным вещам
Раст хороший и мы его любим. Но анонимы, бегающие с ним в каждый тред и сам не написавшие ничего сложнее хелловорлда, поддостали.
А было бы микроядро и всё могло бы сложиться иначе!
Как, например?
раньше
Как у Хурд. Он же сказал "иначе", а не "лучше".
Как у BSD.
> Как у BSD.Вполне рабочая ОС, несмотря на меньший на порядок бюджет и ресурсы?
GNU/Linux тоже вполне рабочая, и что?
> GNU/Linux тоже вполне рабочая,Ох уж эти опеннетные Знатоки ...
С каких это пор GNU окружение разрабатывается в рамках ядра Линукс?
> и что?Ох уж эти опеннетные Читатели ...
Читать не только первые слова, а все предложение целиком не пробовали?
У того анонима чётко написано ОС, а не просто ядро. А раз ОС, то на десктопах и серверах ОС с ядром Linux это GNU/Linux.
>>>>> А было бы микроядро и всё могло бы сложиться иначе!
>>>> Как, например?
>>> Как у BSD.
>> Вполне рабочая ОС
> У того анонима чётко написано ОС, а не просто ядро.А не просто читать, выдергивая удобные слова и выражения, но и осмысливать прочитанное аноним не пробовал?
У анонимов по теме линукса - речь о ядре. Потому что проект Linux, как бы - ядро.
У анонима (меня) BSD - "рабочая ОС", потому что в BSD окружение разрабатывается вместе с ядром, в рамках одного проекта. В отличие от.> А раз ОС, то на десктопах и серверах ОС с ядром Linux это GNU/Linux.
На десктопах предложил бы WSL/Linux в качестве убойного аргумента - чего мелочиться-то? Тоже ведь разрабатывается в рамках другого проекта, так что хоть GNU/Linux, хоть WSL/Linux - абсолютно без разницы, т.к. будет натягивание совы на глобус.
Раз ты про ОС, то и я про ОС. А то чего тогда сравнивать тёплое и мягкое?
> Раз ты про ОС, то и я про ОС.Скажи, каки буквы в словах "GNU coreutils и софт не разрабатываются в рамках проекта Linux" тебе не понятны? И почему именно GNU/Linux, а не WSL/Linux или Google/Linux?
Заодно, продолжи свою мысль из #74, потому что про "рабочую ОС" было только первой частью исходного предложения.
Или вся мысля была в увиденном "BSD упомянуто как ОС, GNU/Linux не упомянуто - непорядок!"?> А то чего тогда сравнивать тёплое и мягкое?
А кто ж вас, анонимов знает - с чего это вы решили выше то микроядра с BSD сравнить, то абсолютно посторонее окружение плюс ядро пингвина с (абстракной) BSD, когда речь шла о "сложиться иначе"?
А где в ней микроядро?
В макоси!(Хотя это не точно.)
микроте мейнтейнеры не нужны, а если драйвер упадёт, то заводится с кривого
> Как, например?Схлопнуться, как черная дыра, на комбинаторном взрыве взаимодействя абстракций. Операционка занялась бы одним сплошным переключением контекстов из абстракции в абстракцию, а выполнять юзерский код - да кого в академических проектах интересуют такие глупости? :)
>> Как, например?
> Схлопнуться, как черная дыра, на комбинаторном взрыве взаимодействя абстракций. Операционка
> занялась бы одним сплошным переключением контекстов из абстракции в абстракцию, а
> выполнять юзерский код - да кого в академических проектах интересуют такие глупости? :)Чуваки из интеля (и заодно миллионы пользователей микоядерной ОС Minix) об этом слышали?
> Чуваки из интеля (и заодно миллионы пользователей микоядерной ОС Minix) об этом слышали?Так оно большую часть времени ничего ж не делает, да еще и имючи в своем распоряжении отдельный независимый проц. Менеджит вас оно лишь эпизодически. Если вас такое использование ОС устроит, то, конечно, вариант. Но это уже ни нагруженный сервак не поставить, ни 100500 файлов на флеху скинуть, ни в гамезу зарубиться, уж пардон. Потому что все это провалится в разы.
Ну зачем безголовому Трольвадсу слушать каких-то взрослых Танненбаумов! Линус запилил своё говнецо, чем был непомерно горд. Тщеславие и сыграло с ним (и с нами) злую шутку.
> Ну зачем безголовому Трольвадсу слушать каких-то взрослых Танненбаумов! Линус запилил
> своё говнецо, чем был непомерно горд. Тщеславие и сыграло с ним
> (и с нами) злую шутку.Вы интервью с Таненбаумом случайно не читали? Профессор значительно скромнее и трезвее в оценке ситуации чем вы.
Интересно, зачем Линусу рабочая станция с мощным 32ядерным процессором, если он только почту читает?
нынче программы такие, что только 32 ядра и тянут... а были времена...
32 ядра это только для почты. Для ютуба, особенно в линуксе, где с аппаратным ускорением траблы, нужно что-то из Top500.
Изволите рофлить? В каком месте и под какой железкой у вас ютубус жрёт?
4K50FPS ролики на одном из моих ноутов неплохо так лагают.
Купи себе уже что-нибудь новее мобильного пентиума из прошлого десятилетия
новее == more DRM
> Изволите рофлить? В каком месте и под какой железкой у вас ютубус
> жрёт?NVIDIA 9600GT, INtel E5400.
> где с аппаратным ускорением траблыНу вот же буквально пару новостей назад в FF завезли VA-API под X-ы.
И да, у меня i5-2540m (мобильный sandy) 720р вполне комфортно вывозит. На 1080 уже заметны подлагивания в динамичных сценах, но в VLC (где VA-API есть и работает) всё красиво. Так что если завести VA-API в FF, то думаю и FHD будет без проблем.Проц, для справки, 2012г. издания.
Естьтолько такая проблема, что Ютуб сейчас на AV1 переходть думает, который нигде не скоряется. Кроме того, через VA-API пока ускоряют только H264, поэтому те кто тестируют ускорение вынуждены выключать поддержку WebM\VP*. Правда ускорение VP в планах.
> Естьтолько такая проблема, что Ютуб сейчас на AV1 переходть думаетНу декодироваться av1, в принципе, должен легко и быстро, но да аппаратных декодеров ещё ждать и ждать, как я понимаю. Так-то вот сейчас попробовал и этого плейлиста (https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZ...) запуститься. Вот результат - https://imgur.com/a/DhBaR1p.
Визуально тоже самое, что и раньше - на 1080 легкие глитчи на шибк динмичных сценах, но смотреть можно, а на 720 - картинка отличная. Проц тотже мамонтовый i5 (это мой основной ноут), FF крайний из реп Mint-а.
VP8/VP9 может декодироваться на новых интеграшках/видеокартах. Ну как новых, 2015-2016+. А Интол на новейших интеграшках может ещё и кодировать.С разморозкой.
А вот AV1 пока впролёте.
> VP8/VP9 может декодироваться на новых интеграшках/видеокартах. Ну как новых, 2015-2016+.
> А Интол на новейших интеграшках может ещё и кодировать.
> С разморозкой.
> А вот AV1 пока впролёте.Firefox в данный момент поддерживает через VA-API ТОЛЬКО H264. VP8/VP9 декодируются самим ФФ софтово. Работы над поддержкой VP8/VP9 через VA-API пока только в планах.
Так что с заморозкой вас.
> Firefox в данный момент поддерживает через VA-API ТОЛЬКО H264. VP8/VP9 декодируются самим
> ФФ софтово. Работы над поддержкой VP8/VP9 через VA-API пока только в
> планах.
> Так что с заморозкой вас.В Firefox не было никакого VAAPI до недавнего времени вообще. И в chromium он тоже присутствует на уровне downstream патча, пока гугл пинает баклуши в этом плане.
Но сам VAAPI умеет VP8/VP9 уже давно. Т.е. это проблема сугубо браузеров и отношения к десктоп-аудитории на Линуксах. Не VAAPI.
Я может неправильно понял изначально, что имелось ввиду. Но печальности ситуации не отменяет :(
> ... а были времена...Когда Линус брал кредит и покупал 386 по цене не сильно подержанной легковушки?
Чтобы больше не жаловался на тормозные программы
Думаешь, что к нему пришли и сказали "Hi, Linus, meet your new PC, you will use it instead of your old one since now"? Линус не производит впечатление чела, которому можно новый комп задвинуть в принудительном порядке c целью устроить worksforme.
Ну так не на одной вкладке же читает
Да. По одному тредриперовскому ядру на одну вкладку. Тормознуто, но жить можно.
Для компиляции чужого кода, вестимо.
> Интересно, зачем Линусу рабочая станция с мощным 32ядерным процессором, если он только
> почту читает?Ну так чтобы писать "this code haven't even seen compiler, CoC, CoC, CoC, CoC!" надо наверное компилер запустить...
Не ради холивара, а почему закрыли доступ к 12309 в багзилле?
Линус купил мощный комп, у него не воспроизводится =)
Суть 12309 в том, что для любого компа с любым наперёд заданным количеством количеством RAM он воспроизведётся с помощью одной маленькой программы в несколько строчек на си.
bfq scheduler + ограничение dirty bytes решает проблему
Неа, BLK_MQ решает проблему, но это не точно, в прошлый раз, когда я копировал файл с ssd на hdd, всё зависло. Твой вариант совершенно точно не рабочий, с bfq я увидел что такое постоянные зависания интерфейса при обычной работе.
ionice -c 3 cp .... решает.
Купи нормальное оборудования, драйвера к которому не страдают этой проблемой.
Пожалуйста код в студию - буду воспроизводить и изучать проблему. Не обещаю что быстро, но мне это действительно интересно.
int main(){
while(true){
new char[4096 * 1024 * 8];
}
return 0;
}
1.c: In function ‘main’:
1.c:3:9: error: ‘new’ undeclared (first use in this function)
new char[4096 * 1024 * 8];
^~~
Сохранить в файл с расширением .cc
g++ 1.cc -o 1
>> Сохранить в файл с расширением .cc
>> g++ 1.cc -o 1так это ужо не Си, а экскременты какие-то...
Предложивший забыл сказать, что это C++
>>> Сохранить в файл с расширением .cc
>>> g++ 1.cc -o 1
>> так это ужо не Си, а экскременты какие-то...
> Предложивший забыл сказать, что это экскрементыспасибо, капитан анонимность!
это инкременты!
new и malloc не выделяют физическую память, они резервируют место в виртуальном адресном пространстве процесса, а физическая память выделяется ядром при первом обращении к странице.
> new и malloc не выделяют физическую памятьДа ну?
Ну да, учите матчасть.
В винде физическую память хотя бы резервиют, хотя до обращения, она вполне себе может быть забита кешем. Программа всегда сможет обратится к памяти, если new не вернул nullptr. В Linux не так?
https://serverfault.com/questions/606185/how-does-vm-overcom...
Причем тут ядро - используя 100/500 разных комбинаций компилятор/линковщик и разные ключи к ним плюс архитектуры - ты получишь 100/500 исполняемых файлов из которых вероятно процентов 10% будут себя не стабильно ....
Только на чипсете от intel
>Суть 12309 в том, что для любого компа с любым наперёд заданным количеством количеством RAM он воспроизведётся с помощью одной маленькой программы в несколько строчек на си.Так вы уж определитесь, в чём суть этой 12309: проблема блочного ввода-вывода или исчерпания памяти? А то это напоминает проблему эфира в физике 19 века. Он одновременно и газообразный, и абсолютно твёрдый; и разреженный, и с огромной плотностью.
> Суть 12309 в том, что для любого компа с любым наперёд заданным
> количеством количеством RAM он воспроизведётся с помощью одной маленькой программыПоказывал тут один чудик такую прогу. Она и скопытилась за аж 5 секунд от oom killer'а при тестовом забеге.
> Суть 12309 в том, что для любого компа с любым наперёд заданным
> количеством количеством RAM он воспроизведётся с помощью одной маленькой программы в
> несколько строчек на си.В Windows всё прекрасно.
> В Windows всё прекрасно.Говорят что тоже уже сломали.
Вплоть до того самого - мертвого взвисания всей системы в конечном итоге.И рецепты предлагаются удивительно похожие - "просто добавьте вчетверо больше памяти" (ничего что до 2016 ничем в ровно этой же не воняло?) , включите io limit'ы в вашем azure instance (ничего что у меня железо?) и т д.
Поколение альтернативно-одаренных программистов под управлением кумаров копчоных :-(
порно невоспроизводится?
Выше уже ответили, если же смотреть архив
http://web.archive.org/web/20190810022442/https://bugzilla.k...
то ответ сформулирован в комментах 663-665
> Не ради холивара, а почему закрыли доступ к 12309 в багзилле?Потому что баг починен дохрена лет назад. Если у вас какой-то похожий баг - создайте новый. Потому что это другой баг. Постоянный гадеж в один баг десятками разных проблем может задолбать кого угодно - ну вот потому и.
>> Не ради холивара, а почему закрыли доступ к 12309 в багзилле?
> Потому что баг починен дохрена лет назад.
> Если у вас какой-то похожий баг - создайте новый.Сэр посоветует подходящую версию либастрала, чтобы прочитать описание бага без регистрации и СМС?
> Потому что это другой баг. Постоянный гадеж
> в один баг десятками разных проблем может задолбать кого угодно -
> ну вот потому и.Полностью закрыть доступ конечно "отличное решение" (сарказм), как-то неуловимо напоминает "прозрачность разработки" одной мелкософтной фирмочки (и по совместительству Платинового Партнера).
Теперь икспириенс "как венда, только нахаляву!" еще полноценнее, что, судя по активной защите, только радует современных линуксоидов ))
> Сэр посоветует подходящую версию либастрала, чтобы прочитать описание бага без регистрации и СМС?Используйте версию 666, она отправит вас в правильное место и время, где вы сможете побатхертить вволю.
> Теперь икспириенс "как венда, только нахаляву!" еще полноценнее, что, судя по активной
> защите, только радует современных линуксоидов ))Кроме нахаляву - там еще в сорце можно поковыряться, да и собрать как мне нравится. В винде такого не дождешься.
>>> https://bugzilla.kernel.org/show_bug.cgi?id=12309
>>> Kernel.org Bugzilla – Bug Access Denied
>>> You are not authorized to access bug #12309. To see this bug, you must first
>>> log in to an account with the appropriate permissions.
>> Сэр посоветует подходящую версию либастрала, чтобы прочитать описание бага без регистрации и СМС?
> Используйте версию 666, она отправит вас в правильное место и время, где вы сможете побатхертить вволю.Узнаю классического опеннетного почтитрехсотого - когда стало нечего возразить по существу, решительно перевел стрелки и написал про "батхерт".
Вот только интересно, с чего бы именно мне батхертить - разве что от смеховых колик в животе?
Но это все же не до такой степени смешно, забавнее сама реакция местных "Военов Свет^W Линукса", пытающимися оправдать решение партии отмазками вида "Потому что баг починен дохрена лет назад", "Потому что анонимы с лора и опеннета надоели комментировать древний и давно исправленный баг" и "Просто у тебя БАМБИТ!1!" ))
Потому что анонимы с лора и опеннета надоели комментировать древний и давно исправленный баг.Если внешние симптомы похожи - это еще не значит, что баг тот же.
"Поиск новых мэйнтейнеров отмечается как большая проблема"Платить не пробовали? Причем и за поиск тоже
Платить нужно за обучение, а мигрантов нанять проще.
Какой же опенсорс если за него еще и надо платить.
Опенсорс дословно открытые исходники, а не бесплатно.
Кого Вы обманываете, с правом форнуть и продавать, продать ПО возможно ровно 1 раз. Что совершенно неприемлемо, если в разработку вложены многие миллионы долларов инвесторов. Поэтому все и продают поддержку чужого кода или код необходимый для продажи чего либо другого. Google Chrome например нужен для продажи гугло-услуг. Microsoft коммитит в ядро поддержку Hyper-V для продажи Windows Server и Azure и т.д. А если Photoshop открыть под GPL, то немедленно появится OpenPhotoshop и компания разорится.
Опен-что угодно ни как не влияет на продажи неОпен-что угодно. Потому что продажи это не про продукт и потребление, а про искусство впаривания, которому наличие чего угодно аналогичного бесплатного совершенно не помеха, а даже, чаще всего, подспорье.
Нужно быть великим мошенником чтобы продать большому числу людей и предприятий, что то, что рядом можно получить совершенно бесплатно. Можете попробовать сделать форк Ubuntu и продать её хотя бы за $50, миллиону клиентов.
Однако, это никак не отменяет того, что даже GPLv3 не запрещает продавать софт.
Red Hat-у это объясните:)
>Поэтому все и продают поддержку чужого кода или код необходимый для продажи чего либо другогоRed Hat не разрабатывает собственное ПО на продажу, только допиливает чужое по требованию крупных клиентов. А те кто разрабатывал само ПО не получили ни цента прибыли.
Ну да, то есть systemd и прочие радости Linux-мира -- это не Red Hat, да?
А они его продают? SystemD это политический инструмент.
> Кого Вы обманываете, с правом форнуть и продавать, продать ПО возможно ровно 1 раз.Вы тут обманываете сами себя. То что вы говорите справедливо для продажи All-in-one-super-converter 2020 глупому потребителю, который это покупает это в розницу. Если бизнесмодель предполагает розничные продажи консьюмерам, то вам нужна проприетарная система лицензирования. Если вы принесёте в крупный бизнес программу, которая считает лицензии и устройства поштучно, мешает работать и больше занята доказательством легальности использования продукта нежели реальной работой, то кто вы после этого? 1С какой-нибудь печальный. Сама-то 1С вполне себе нормальное решение для своей ниши (бейсик+фокспро 2020) но на международном рынке не катируется и не будет пока не научится работать с облачными развертыванием и не выпилит свою сессионно-устройственную систему лицензирования. Крупный клиент такое ПО не покупает или просит сразу предоставить ему версию без всех этих ненужных функций. Терпилы только тут в СНГ.
Техническое сопровождение, оплата обновлений, доработка функционала, услуги распределенных вычислений, облачные хранилища - вот это хлебно. Там прибыли больше чем дрожать за каждую лицензию ритейл-пользователя.
> Microsoft коммитит в ядро поддержку Hyper-V для продажи Windows Server и Azure и т.д.
И уже много лет как начхал на лицензирование Retail-копий. Отказался от идеи перепродажи обновлений-апгрейдов (XP->7; 7->10) теперь всем десяточка с бесплатными апгрейдами. И продаёт предприятиям лицензии на новую версию + все старые в рамках класса продукта.
В 2020-ом году компании переходят на продажу услуг и отказываются от модели ритейла+франчей для малого среднего бизнеса.
> немедленно появится OpenPhotoshop и компания разорится.
Наличие GIMP-а не разорило Adobe И не разорит. Вы видимо совсем-совсем технарь и ничего не понимаете ни в людях, ни в бизнесе. Те люди которые которые не хотели покупать фотошоп и так его украли и Adobe не разорилась. И никто не борется с пиратством в ритейл-сегментах, потому что увеличение пиратских копий даёт прирост пользователей лояльных бренду, вместе с ним прирост профессионалов и рост оборотов в абсолютных, а не в относительных величинах.
>[оверквотинг удален]
> В 2020-ом году компании переходят на продажу услуг и отказываются от модели
> ритейла+франчей для малого среднего бизнеса.
>> немедленно появится OpenPhotoshop и компания разорится.
> Наличие GIMP-а не разорило Adobe И не разорит. Вы видимо совсем-совсем технарь
> и ничего не понимаете ни в людях, ни в бизнесе. Те
> люди которые которые не хотели покупать фотошоп и так его украли
> и Adobe не разорилась. И никто не борется с пиратством в
> ритейл-сегментах, потому что увеличение пиратских копий даёт прирост пользователей лояльных
> бренду, вместе с ним прирост профессионалов и рост оборотов в абсолютных,
> а не в относительных величинах.Автодеск борется: поставил в каждом регионе россии партнера-представителя, тот уголовно преследует, взыскивая ущерб, оставляя суммы оного большую часть себе. И вообще сумма лицензии на одну маину у него по прежнему достаточно велика и значительно больше сопутствующих облачных услуг
Пробовали, получилась винда
> Пробовали, получилась виндаА еще раньше SysV
Мы тут за поиск разработчиков платить пробовали. Приводят таких, что ни один не может рекурсивный обход написать. Итог - выброшенные деньги.И это в принципе понятно, те, кто хоть что-то умеет, резюме в кадровые агентства не шлет
Рекурсивный обход дерева?
Да, и кроме того, мало кто из мыслящих согласен вообще отвечать на глупые высосанные из пальца личные вопросы кадровички рекрутера, итп, а вот задачки - раз плюнуть, это приятно
> способных рецензировать чужой код
> стареют и становятся седымиСкоро рецензировать будут CoC и мигранты.
> если не считать сильно шумящего кулера.
Ноут нужно приподнять или в столе дырок насверлить.
Проц скальпировать, припаять.
В случае свиста у кулера крышку приподнять.
> НоутТредриперы в ноуты не ставят.
какую крышку, какая пайка, ты о чём вообще
А я вот у старого MacBook (грелся) пластиковое покрытие с задней крышки оторвал и ножки от свича приклеил. Стало лучше.
Во-первых, с каких пор в MacBook ставят AMD? Штеуд там, потому и греется. Ибо вместо припоя сопли, которые тепло не проводят.Во-вторых, как уже сказали выше, Threadripper'ы в ноуты не ставят. У Линуса стационарник с 32-ядерным тредриппером. Почему все эксперты с opennet'а, даже не прочитав новость, пытаются давать советы наперебой, как ему справиться с выделяемым процем теплом?)
Скальпировать и паять нужно твои штеуды, у которых под крышкой эякулят вместо припоя. А в Ryzen'ах и Threadripper'ах припой.
Скальпирование это необходимость только для интелов. Нормальные процессоры идут с хорошим припоем. А у Торвальдса видимо неудачный выбор кулера.
...что только лишний раз говорит о его способностях. Почему у меня машина тише воды? Потому что надо покупать тихие кулеры. Как мой пример, Thermalright TY-150. Страшные, зелёные, но работают тише поступи кота.
Потыкай кота палкой, возможно его срок годности вышел...
>А у Торвальдса видимо неудачный выбор кулера.Неужели у него обычная башня? Я то думал, что к тредрипперам СВО покупают - а там можно и почти без шума обойтись.
После смерти Линуса проект возглавит Мартинг Лютер Кинг. Скриньте.
не не это к BSD
Линусу всего 50 лет. Дейву Каттлеру вообще 78 лет и до сих пор над ядром WNT работает. Здесь больше проблема кодовой базы Linux ядра
Можно искусственно довести Линукс до состояния когда его надо будет переписать с нуля.
Уже. И Линус это признавал, но проблема как всегда в драйверах, на переписывание которых уйдёт ещё лет 20.
Не "всего" а "уже" 50! Для зелёных смузихлёбов: это когда жизненные приоритеты меняются и даже вопрос "заработать лишнюю тыщу баксов" уже не так однозначен и люди всё чаще предпочитают отдых.
Линус уже практически сдулся: не ровен час, обьявит, что "я устал, я - мухожук!" и свалит от всей этой нудной рутины.Программист начинает с кода, с интересных библиотек, идей, проектов, пишет сам свою ОС, редактор, ГУЙ, СУБД и т.п. Когда прогер перестаёт писать и вообще теряет интерес к проектам, он уже мёртв. Линус уже практически на грани того, чтобы бросить бессмысленное латание кучи г***вна под названием "линукс-ядро". Оно не вывозимо и его точно заменят. Даже сейчас взять QNX - и то будет стократ больше пользы. А то и того мельче - экзоядра.
Твой коммент как раз отдаёт "зелёным смузихлёбством".> Программист начинает с кода, с интересных библиотек, идей, проектов, пишет сам свою ОС, редактор, ГУЙ, СУБД и т.п. Когда прогер перестаёт писать и вообще теряет интерес к проектам, он уже мёртв.
А я-то думал, программист должен быть прагматиком и не тратить время на то, что тысячи раз написано до него. Так как смысл существования программиста как профессии - решать поставленные задачи наиболее оптимальным способом. А разноцветным буковкам в редакторе и унылым велосипедикам можно радоваться только на уровне джуна.
> Линус уже практически сдулся
Не "сдулся", а "имеет право уйти на заслуженный отдых".
вы правы когда дело касается прикладников
но есть ведь еще системщики
прогеры в целом делятся на 3 категории
1 ая начинает прогать на бейсике паскале лого яваскрипт - и заканчивает написанием своих программ для своей профессии увлечений или малых сайтов ( их правильнее называть программирующими профессионалами чем программистами )
2 ая те кто пишет для всяких банков или большие прикладные программы - сайты - вот им действительно не надо писать то что написано до них
3 я - собственно системщики. у них нет того что написано до них. они все должны писать сами - причем максимально близко к железу - они не электронщики в прямом виде - но понятие системотехники - понимают. и да им доступна инфа от производителей - которую вы найдете (если) только для снятых с производства моделей
> для неосновных подсистем, таких как драйверы устройств,
> рассматривается возможность предоставления привязок
> для разработки на таких языках как RustИнтересно, что о С++ и речи не идёт, хотя привязки там не особо нужны.
Его же в этот раз про C++ и не спрашивали, его спросили про Go и Rust, он про них и ответил.
В том что и дело, что даже не спрашивали. Зато Rust уже обещают, несмотря на "доведение языка Rust до паритета с языком Си в области системного программирования". https://www.opennet.ru/opennews/art.shtml?num=51401
Ржа - мёртворождённый проект без конкретных целей. Поиграются и бросят.
Полагаете, Линус пообещал просто из вежливости? Или уверен, что у реализующих ничего не выйдет?
> Или уверен, что у реализующих ничего не выйдет?Хипстеры не любят пахать 30 лет к ряду, поддерживая свое барахло, особенно с правилами типа "мы не ломаем юзермод". Это невыгодно отличает их от торвальца.
Видите ли это оказывается много вджоба, багфиксинга и майнтенанса и даже рутины, а не так что за полчаса накодил - и весь мир у твоих ног, трепещите, дескать, жалкие червяки. А червяки не трепещут - торвальц видите ли круче в разы.
Если действительно так и окажется, значит Линус грамотно поступил. Формально не отказал, не запретил, а в итоге вышло... что вышло.
> В том что и дело, что даже не спрашивали.Это ни о чём не говорит, есть 100500 причин почему он не спросил про C++.
Например, какие?
> Например, какие?Торвальдс однажды очень конкретно высказался по этому поводу, например.
Таки привязки нужны. Хотя бы для обработки символов загружаемых модулей, написанных на C++.
Вот тут https://bosslinux.in/boss-mool индусы что-то в направлении поддержки модулей на С++ запиливают.
По ссылке запиливают "ОО абстракцию", что бы "увеличить сопровождаемость". Нужно ли оно - это другой вопрос. Необходимо ли - третий.В частном случае, если использовать некоторое подмножество С++, собрать рабочий модуль возможно. Для поддержки ряда возможностей языка, например, исключений (если их кто-то рискнёт допустить в ядро) потребуются дополнительные телодвижения.
Разработка линукса уже вызывает туннельный синдром?
> Разработка линукса уже вызывает туннельный синдром?Печатаешь по нескольку часов в день - вот и получи его в запястьях. Профессиональная больезнь машинисток, же, ещё до всяких компьютеров.
Чушь собачья! Написание кода стократ медленнее любой машинистки. Это в сумме кода много, но реально в день печатается крайне мало, чтоб вообще это замечать. Пишу код без малого 25 лет - НОЛЬ проблем. Разве что шея немного затекает от чтения форумов. :)
> Чушь собачья! Написание кода стократ медленнее любой машинистки.Это зависит не от объёма, а от времени нахождения запястья в "вывернутом" положении. А это печать, если клавиатура специально не заточена, работа с мышью и т.д. Есть даже такой мем "укус мыши", когда от работы с мышью стреляет в запястье.
> без малого 25 лет - НОЛЬ проблем
Ну я рад за Вас. Хотя наступить может внезапно, так что я бы не зарекался, всё-таки.
У меня стаж поменьше, но от мышки уже отказался, т.к. долбше часа/двух - запястье ломит. Печать на ноуте позволет руки расположить как удобно, но всё равно раз в час/два делаю лёгкую гимнастику для рук.
Есть вертикальные мыши, вполне удобно и никакого туннельного синдрома.
> Есть вертикальные мышиНу они есть, но я вот только сейчас из это коммента о них узнал. Штука прикольная, на вид. Я на тачпад переключился. Вполне удобно. Мышью пользуюсь, разве что, изредка поиграть.
Есть даже пространственно-ориентированные мыши с гироскопом внутри. У меня она еще и с мини-клаиватурой. Клаву использовать в поседневе - это тот еще секс, но мышью вполне себе можно пользоваться после того как ваш мозг откалибруется и научиться пользоваться этой штукой.
>Это зависит не от объёма, а от времени нахождения запястья в "вывернутом" положении.Это от стола зависит. И от того, какая мышь используется. Лет 12 Logitech выпускала не мышей, а настоящих крыс, которые нормально подходили под руку разве что какого-нибудь финского двухметрового мужика. И популярны были столы, где рука не лежит на столе (как должна), а постоянно в подвешенном состоянии. Вот если такой набор у пользователя есть, то и туннельный синдром тоже у него будет.
> Лет 12 обратно.
Наверно его в емаксе разрабатывают.
В emacs -е тунельный синдром куда сложнее, чем в других редакторах. Но это, если им уметь пользоваться. Очевидно, что вы не умеете.
В смысле, заработать туннельный синдром куда сложнее.
Этот Линус сломался тащите нового.
>сообщество разработчиков ядра теперь не может позволить себе некоторые безумные изменения, которые делались раньшеСтареем?
>что в 2030 годах Си-разработчики превратятся в нынешнее подобие разработчиков на COBOL
Си не умрёт никогда пока есть Unix-like systems.
При чём тут старость? Он же ясно пишет что это ответственность перед пользователями ядра, раньше распространения и вариантов использования было меньше и ответственности меньше.
Да всё просто. Надо сделать так, хотя так оно по факту и есть...Для "ответственных или трусливых", корпорасо-говно-мамонто-энтерпрайзных - LTS ветка. Сюда сразу запишем всех РетГадовцев, Демьяно-Дебилианщиков и т.д. и т.п.
Для молодых, прогрессивных ветка mainline или stable.
Си не умрёт никогда пока есть - железо
си единственный язык настолько низкого уровня - что ниже его тока ассемблер
забываете что си и был разработан как в первую очередь переносимый ассемблер
и такой язык один
в отличие от всяких лиспов прологов смоллтоков и прочих концептуально отличных
си в - первую очередь максимально быстрый метаассемблер для железа
все что выше - хоть питон хоть брейнфак
раст и го - выше по уровню - поэтому си не заменят
может где то потеснят с++
потому что изначально с++ - это смесь ежа с ужом
Лучший мэйнтэйнер - это же одноногий гей негр трансвестит с дефектами речи. Разве трудно такого найти?
Ток одноногий гей негр трансвестит это обычный гетеросексуальный гражданин с позиции нормального человека. Выбирай, ты либо ненавидишь инвалидов (которые ничем от тебя не отличаются), либо расист (черные люди практически ничем от белых не отличаются), либо сам из этих (ну, это врождённое, конечно).
в видео Линус чем-то похож на пингвина
На Водяного из ссср-ного мультика :)
Кокая-то печаль от этого. Ладно бы хренов хруст только, мне это не нужно, но проблемка-то пошире видать.
Вобщем линукс уже не торт, пора откапывать Hurd
Там же каждый ядерный сервис это отдельный процесс. Поэтому там ещё проще поддержку писания компонент ядра на разных ЯП сделать.
Тухло как-то Видео от пятого мая...
Сейчас т.н. "проблема с управляющими" вылезла не потому, что "нужно проверять патчи", а потому что само ядро - наитухлейший пример монолитного г****вна, где миллионы строк кода уже просто невозможно проверять обычному человеку, поэтому всё принимается на авось.
СПАСИБО тебе, глупый "неожиданный революционер", что стал перечить Танненбауму и запилил своё го*вённое ведро, с которым теперь мучаются тысячи разрабов! Покойся уже с миром.
Не драматизируй. Древний Юникс был монолитным. Линукс - модульный, если надо можно сконфигурировать маленькое килобайтное ядро (быстрое и монолитное), под своё железо.Если Линукс разбить на Танненбаумовское микроядро с часами + мультисерверы, то оно по своей струтуре будет сложнее чем сегодняшнее ядро.
За годы пользования Линуксом я ни разу не видел чтобы моя система зависала, конкретно из-за ядра. Тормозило и зависало как правило X Window окуружение, то есть программы с графической мордочкой.
Все эти микроядра, микросервисы, микромашинки это для тех, у кого микрочлен.
Скорее микромозг. Выше можно прочесть творчество страдальцев.
Наоборот же? Всё большое существует для тех, у кого комплексы по этой части. Я так понял у тебя тоже они есть. Не расстраивайся, есть ещё пальцы.
> ...рассматривается возможность предоставления привязок для разработки на таких языках как Rust.А на C++ даже не рассматривается?
Нет конечно, все мы знаем к чему приводит разработка драйверов на плюсах. Благо есть живой пример.
> Нет конечно, все мы знаем к чему приводит разработка драйверов на плюсах.
> Благо есть живой пример.А на расте будет лучше?
Пример в студию можно?
На с++ уже давным-давно написаны и широко используются разные оси реального времени для микроконтроллеров, но для линукса на нем ничего конечно написать невозможно
19 различных способов инициализировать int в C++:int i1; //undefined value
int i2 = 42; //note: inits with 42
int i3(42); //inits with 42
int i4 = int(42); //inits with 42
int i5{42}; //inits with 42
int i6 = {42}; //inits with 42
int i7{}; //inits with 0
int i8 = {}; //inits with 0
auto i9 = 42; //inits with 42
auto i10{42}; //C++11: std::initializer_list<int>, C++14: int
auto i11 = {42}; //inits std::initializer_list<int> with 42
auto i12 = int{42}; //inits int with 42
int i13(); //declares a function
int i14(7, 9); //compile-time error
int i15 = (7, 9); //OK, inits int with 9 (comma operator)
int i16 = int(7, 9); //compile-time error
int i17(7, 9); //compile-time error
auto i18 = (7, 9); //OK, inits int with 9 (comma operator)
auto i19 = int(7, 9); //compile-time errorИ это только начало:
https://youtu.be/h-zy1hBqT74Спасибо, не надо.
> 19 различных способов инициализировать int в C++:
> И это только начало:
> https://youtu.be/h-zy1hBqT74
> Спасибо, не надо.И где Ваша логика?
P.S. Можно != Нужно
На C способов выстрелить себе в ногу гораздо больше!
>На C способов выстрелить себе в ногу гораздо больше!Дело не в этом.
У Си давно сформированы идиомы. И когда системщик пишет соблюдая правила безопасности и всем известные идиомы, тогда код на чистом Си хорошо чистается. Си хорош тем, что он прост, он проще чем Си++ и Раст.
Технически нет непреодолимых проблем с использованием C++. Ну повозиться придётся, навскидку: оверрайды new/delete на kmalloc, аргументы через регистры, исключения запретить, ещё пунктов 20 наверное, но принципиально нет ничего невозможного. Тот, кто знает кресты на таком уровне, что ему можно доверить писать драйвера, разберётся.
И будет следующее:1. Оверхед в разработке, соответственно, сложнее его будет читать обычным программистам на С++. Надо будет думать не только о чем пишете, но и как пишете.
2. Еадо будет следовать определенной модели в разработке исключая определенное подмножество языка, иначе оверхед в рантайме.
3. Оверхед в рантайме даже если выполнен п.2.Конечно можно ввести дополнительные ключевые слова, сделать транслятор/компилятор и тогда получим вполне адаптированный С++ под разработку драйверов, например подобный проект для Perl существует в виде RPerl, но он не для драйверов, хотя...:))
К чему речь: С++ несет высокоуровневые абстракции которые не нужны в разработке драйверов, это лишнее. Чтобы получить оптимальное решение - требуется выборка подмножества языка С++, то есть С++ "спустить на землю" чтобы не летал высоко в своих абстракциях. Но раз так, может легче дотянуть Си до нужного уровня абстракции, тем более что это будет и проще и быстрее. Ой, забыл, обильное использование макросов (в крупных прокетах) на Си как раз закрывает недостаток в уровне абстракции на Си. Так что в Си все хорошо, за исключением того что из-за небольшого недостатка языка в плане абстрации, во-первых, проект обрастает целым лесом макросов и, во-вторых, среднего уровня Си-программистов утопают в макросах.
Недостатки Си закрыты в Vala, но они закрыты "с лихвой" (хотя "лихву" использовать не обязательно).
> Линус Торвальдс о проблемах с поиском мэйнтейнеровНадо начинать с того, как он их ищет. Всё дело в том, что никак. Он ждёт, когда они сами к нему придут с блюдечком и каёмочкой. А он будет слушать, что ему нашепчут на ушко его полностью разложившиеся дружки (Виро, Тс'о и иже с ними). Вся эта пирамида с некомпетентным одиночкой наверху давно уже сгнила.
КБ АЛЬТ, не пораженное толерастией, сможет продолжить дело Линукса, когда там все на западе сгниет.
Сообщество может, говорили они.
"Поиск новых мэйнтейнеров отмечается как большая проблема. В сообществе много активных разработчиков, которые рады писать новый код, но мало кто готов посвятить своё время на сопровождение и проверку чужого кода"А что тут такого, это логично, одно дело самому гомнокодить, а другое - парсить и разгребать чужие гомны?
Иногда думаешь, что проще было бы самому написать, чем вкуривать, иногда в такую наркоманию, что не знаешь как это чудо вообще живёт, и кто был тот инопланетянин на веществах, который это всё произвёл.
Linux скоро будут пилить только Microsoft
> Linux скоро будут пилить только MicrosoftПока там только 1 чувак с @microsoft.com замечен в активном кодинге. На удивление - полезном :). "И в г@вне встречаются жемчужины"
Ещё сложнее будет найти мэйнтейнегров
Rust гораздо хуже и опаснее Си так как в нем есть unsafe блоки
Пусть научатся на Си писать, а не выдумывают недоязыков.
>На вопрос о переработке ядра на таких языках как GoДавайте уж на Java сразу - она и быстрее будет, и экосистема у неё гораздо лучше, и дженерики в ней есть.
iZEN, залогинься.
В Яве нет "дженериков".
>На прошедшей на прошлой неделеТак на прошедшей или на прошлой? Куда торопился писака?
> На вопрос об экспериментах в ядре Линус высказался, что сообщество разработчиков ядра теперь не может позволить себе некоторые безумные изменения, которые делались раньше. Если раньше разработка ни к чему не обязывала, то теперь от ядра Linux зависит слишком много систем.Накнец-то сам Линус объявил о начале конца того, что мы знали под названием Линукс.
> По поводу своего нового ПК на базе процессора AMD Линус упомянул, что всё работает нормально, если не считать сильно шумящего кулера.
У него же было самое главное требование к ПК: бесшумность!
Неужели не нашлось 1,5+ кг радиатора, чтобы кулеру не приходилось перетруживаться? А, он же там в солнечной Калифорнии, т.к. Линус любит тепло.