The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Дискуссия об использовании языка C++ для разработки ядра Linux, opennews (??), 14-Янв-24, (0) [смотреть все]

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


11. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +3 +/–
Сообщение от Аноним (11), 14-Янв-24, 21:59 
> "Now, "why not Rust"? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax

Это он ещё очень дипломатично выразился относительно этого нагромождения сокращений и спецсимволов.

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

81. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –5 +/–
Сообщение от Аноним (81), 15-Янв-24, 00:13 
А какая тебе разница, какие там спецсимволы? Тебе алгоритмы писать, а не буковки разглядывать. Так что пофиг какой в языке синтаксис, это вопрос десятый. Если уж так хочется - можно и DSL написать с другим синтаксисом.
Ответить | Правка | Наверх | Cообщить модератору

100. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +8 +/–
Сообщение от Витюшка (?), 15-Янв-24, 01:35 
Синтаксис очень очень важен именно для алгоритмов, сложного нетривиального кода.

Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.

Это как раз для передачи json по http синтаксис не столь важен, "можно потерпеть", не критично.

Попробуй разобрать алгоритм на brainfuck.

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

573. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (573), 16-Янв-24, 18:57 
> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.

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

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

575. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 16-Янв-24, 19:09 
>> Код должен ясно передавать намерения (высокоуровневые) и идеи алгоритма.
> Нет. Код должен реализовывать алгоритм, который описан обычным человеческим языком в комментарии
> прямо перед ним, а реализация должна быть обязательно аннотирована ссылками на
> это описание и, по необходимости, прокомментирована. В случаях когда реализация использует
> оптимизации (например, специфические для ЯП или аппаратной платформы), они обязательно
> должны быть прокомментированы с описанием оснований для принятия решения об оптимизации,
> списком рассмотренных альтернатив, результатами бенчмарков и снабжены тестами, эти самые
> бенчмарки реализующими. В противном случае действительно можно и на brainfuck писать
> с тем же успехом.

Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных прав по лицензиям типа GPL. Потому имеем, что имеем.

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

648. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 19-Янв-24, 18:50 
> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
> прав по лицензиям типа GPL. Потому имеем, что имеем.

В каком месте GPL лишает кого-то имущественных прав? Цитату?

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

659. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 20-Янв-24, 08:36 
>> Это верно, но есть нюанс. Идея "самодокументированного кода" позволяет автору сохранить
>> хоть какой-то контроль за проектом. Что важно, когда он лишается имущественных
>> прав по лицензиям типа GPL. Потому имеем, что имеем.
> В каком месте GPL лишает кого-то имущественных прав?

В месте замены "право" на "лево".

> Цитату?

"copyleft"

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

661. Скрыто модератором  +/–
Сообщение от Аноним (-), 20-Янв-24, 11:26 
Ответить | Правка | Наверх | Cообщить модератору

669. Скрыто модератором  +/–
Сообщение от n00by (ok), 20-Янв-24, 15:36 
Ответить | Правка | Наверх | Cообщить модератору

170. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +3 +/–
Сообщение от Аноним (170), 15-Янв-24, 07:22 
Код гораздо чаше нужно читать, чем писать. Поэтому, чем удобнее его читать, тем лучше. Си в этом плане кстати тоже не идеал, но определённо лучше Rust и C++.
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

197. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Советский инженер (ok), 15-Янв-24, 09:55 
>... но определённо лучше Rust и C++

с этим тоже можно поспорить, т.к. на читиаемость влияет и количество строк и goto всякие.

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

582. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от adolfus (ok), 16-Янв-24, 20:33 
В С++ есть большая проблема -- ссылки в перечне параметров функции. Это препятствует использованию там r-value. А как известно, любое l-value в программе добавляет +1 к пулу потенциальных проблем безопасности и программных ошибок.
Что касается goto, то без него вы даже из вложенного цикла не выйдете. Вернее, выйдете, но через виртожопу.
Ответить | Правка | Наверх | Cообщить модератору

609. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (609), 17-Янв-24, 08:27 
>Что касается goto, то без него вы даже из вложенного цикла не выйдете.

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

>Вернее, выйдете, но через виртожопу.

Из через жопу написанного кода любой выход только такой. И с помощью goto в первую очередь.

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

614. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от adolfus (ok), 17-Янв-24, 12:04 
Ну так пройдитесь просто по двумерному массиву. Когда-нибудь изображения обрабатывали? А гиперспектральные, которые трехмерные массивы?
Парсер простой напишите без goto для какого-нибудь примитивного языка, например, для джейсона. Все без исключения FSM-алгоритмы, коими и являются эти самые синтаксические анализаторы, работают на goto безальтернативно.
Ответить | Правка | Наверх | Cообщить модератору

610. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (609), 17-Янв-24, 08:32 
>Что касается goto, то без него вы даже из вложенного цикла не выйдете.

"Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных циклов... А главное, писать вложенные циклы.

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

616. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от adolfus (ok), 17-Янв-24, 12:34 
>>Что касается goto, то без него вы даже из вложенного цикла не выйдете.
> "Cache-friendly программирование? Не, не слышали." И продолжили выходить из вложенных
> циклов... А главное, писать вложенные циклы.

"Каше-френдли" программирование начинается прежде всего с безальтернативного использования статических библиотек вместо динамических и минимизации длинных переходов. Причем прежде всего это касается вызовов процедур, поскольку каждый call сопровождается еще и ret'ом. Итого два сброса всех кешей кода в одном вызове.
А короткие переходы, которые в основном и генерируются из goto, кеши кода не портят, поскольку все это происходит в пределах одной страницы. Причем и кеши данных не сбрасывают тоже, поскольку к памяти данных/стека, в отличие от call/ret не обращаются.
Кстати, обращение к любой функции в .so несколько раз сбрасывает все кеши, что есть. Сначала дальняя ссылка на GPT, потом дальний переход на процедуру и потом возврат из дальнего вызова.

Есть несколько постулатов, используемых, в том числе, и в программировании, следование которым позволяет серьезно повысить качество программ. Это:
1) явное всегда лучше неявного;
2) административные проблемы плохо решаются техническими средствами, а технические -- административными, поэтому "Каждому свое", как было написано на воротах одного гуманитарного заведения.
Эти два пункта относятся прежде всего к стилям програмирования, в том числе и к goto. Смысл состоит в том, что проблемы, проистекающие из-за хреновых навыков программирования (это всегда у нас и у них тоже называлось "логические ошибки"), невозможно адекватно решать с помощью каких-то особых и "безопасных" языков программирования. Все эти якобы "безопасные" парадигмы и языки поголовно работают поверх кода, написанного на сях, да и сами в 99% случаях написаны на них же, представляя просто фреймворк. Питон, например, один из них. Второй момент -- их использование не дает прграммисту расти. Он просто скачет от одной "технологии" к другой, оставаясь на уровне своего лучшего курсового проекта. Умение работать с памятью приходит только с опытом работы с ней и никак не иначе.

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

622. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 17-Янв-24, 14:45 
Предсказание и предвыборка команд работают для call/ret начиная с NetBurst (и для far call/ret работают, но эти команды не используются в плоской модели памяти). Но это не повод отказываться от статического связывания.

Calls and returns are expensive; use inlining for the following reasons:

• Parameter passing overhead can be eliminated.
• A mispredicted branch can lead to performance penalties inside a small function that are larger than
those that would occur if that function is inlined.
• In a compiler, inlining a function exposes more opportunity for optimization.
• If the inlined routine contains branches, the additional context of the caller may improve branch
prediction within the routine.

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

397. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от warlock66613 (ok), 15-Янв-24, 19:53 
И Rust и C++ более выразительные языки чем C, и именно поэтому код на них гораздо проще читать.
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

585. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 16-Янв-24, 22:07 
Оба языка позволяют как написать очень выразительно, так и нечитаемо, или понимаемо, но не так. ;)
То есть, в плане оформления исходника, позволяют "прострелить себе ногу".


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

635. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от wyry (?), 18-Янв-24, 18:20 
Несмотря на то, что я топлю за C++, не могу не придраться, что C++ ОЧЕНЬ опасен в плохих руках и там легко допустить плохие решения (как по семантике, так и по читаемости кода). Но преимущество C++ в том (и об этом говорили многие задолго до китов), что C++ напрямую связан с C и всё можно переписывать плавно не боясь что-то сломать.
Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

490. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от scriptkiddis (?), 16-Янв-24, 10:01 
Ну и че ты не переписал еще все ядро на brainfuck?
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

248. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +4 +/–
Сообщение от Аноним (248), 15-Янв-24, 11:47 
Так сокращения это норма для линукса. cp, mv, dd, rm, ls, df, du, pz
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

258. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (258), 15-Янв-24, 12:45 
Это объясняется легаси.
Ответить | Правка | Наверх | Cообщить модератору

316. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +2 +/–
Сообщение от Аноним (313), 15-Янв-24, 15:05 
Могу назвать ещё минимум две причины, по которым
ls -l
Лучше, чем
list-files-and-directories --show-as-much-details-as-possible
Ответить | Правка | Наверх | Cообщить модератору

382. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +2 +/–
Сообщение от Аноним (-), 15-Янв-24, 18:59 
> Могу назвать ещё минимум две причины, по которым
> ls -l
> Лучше, чем
> list-files-and-directories --show-as-much-details-as-possible

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

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

393. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (341), 15-Янв-24, 19:24 
Наоборот же, powershell показывает, что можно всем угодить изкоробочными алиасами и parameter name matching'ом (-def ниже, как одна из недвусмысленных подстрок, с которых начинается параметр -Definition).

> get-alias ls

Alias           ls -> Get-ChildItem
> get-alias -def get-childitem

Alias           dir -> Get-ChildItem
Alias           gci -> Get-ChildItem
Alias           ls -> Get-ChildItem

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

446. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (446), 15-Янв-24, 23:57 
> Наоборот же, powershell показывает, что можно всем угодить
> изкоробочными алиасами и parameter name matching'ом

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

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

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

476. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (341), 16-Янв-24, 02:54 

> Какую задачу решает это индусское месиво я не понимаю.
> брейнфак с типизацией (в шелле!!!)

Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно быть понятно, зачем линуксоиды делают свой powershell в виде nushell.

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

479. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 16-Янв-24, 03:04 
> Ну жирноват-тяжеловат он, но вот идея типизированного шелла должна быть понятна. Должно
> быть понятно, зачем линуксоиды делают свой powershell в виде nushell.

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

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

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

546. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (546), 16-Янв-24, 15:53 
Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с PSReadLine ты оппрыгаешься с башем. Алиасы давно по умолчанию сделаны и выглядят практически как в баш. Если ты в пайплайны не умеешь в ps - иди в дворники.
А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же в 5 раз быстрее сделаешь в лине. Покажи примеры.
Ответить | Правка | Наверх | Cообщить модератору

649. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 19-Янв-24, 19:03 
> Тебя опять что-ли шиза долбает, 294й? То что по умолчанию идёт с
> PSReadLine ты оппрыгаешься с башем.

Ну во первых я вобью проблему в поискарь и скопипащу 90% решения. Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся.

> Алиасы давно по умолчанию сделаны и выглядят практически как в баш.

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

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

> Если ты в пайплайны не умеешь в ps - иди в дворники.

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

> А ещё, для автоматизации быстрой, жду аналог PowerCLI для vmware. Ты же
> в 5 раз быстрее сделаешь в лине. Покажи примеры.

Ну так я себе ряд операций с виртуалками прекрасно оптимизнул. Конечно для KVM и QEMU, нахрен мне вмварь? Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями. У вас там уровень сцаного эксплуатанта. А я кастомдев, мне больше надо. На баше я это забацал минут за 10. А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?!

А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)

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

684. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (684), 23-Янв-24, 19:00 
> Ну во первых я вобью проблему в поискарь и скопипащу 90% решения.

У тебя как 294й, с способностью понимать тексты? Проблема?
Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в баш это круто.

> Во вторых я не собираюсь бузинесс-логику или что там еще на шелле бжад наворачивать. Поэтому в 95% случаев мне вон то просто не приболело, а вот минусы - икнутся.

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

> А внутрях все равно летающий спагетти монстр с километрами макарон, норовящий типизацией куснуть и чего там еще. И время старта этой байды такое, что у меня в ряди случаев скрипты отработают быстрее чем ЭТО вообще только стартануть расчехлится на VM.

Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой же аргумент приводят на тему системд и другой системы инициализации. Только там лапша в баше у них.
Ты про алиас то в поисковик можешь вбить болезный? Ну и показать насколько букв команда в баше cd больше цмдлета в пауршеле cd?
Хотя у кого хаотическое мышление им действительно не понять - как это правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы.
Ну про телегу разных шелов и разное поведение в разных ОС вообще промолчу. Переносимость это не про тебя. Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих.
Проще в несколько команд прогнать объект и вытащить нужный процесс по тому же показателю памяти. Чем писать десятки строк под каждую ОС и шел. Мне своё время дороже. Но твоё ничего не стоит, поэтому пиши партянки с макаронинами под мак-вин-лин и разные шелы.

> Я пошел в пингвина вместо этого - там с пайплайнами ноу проблем, и вообще, все как-то сильно проще и ненапряжнее.

Ну так все и поняли что ты не умеешь в пайплайны. Сейчас в куче мест ушли все в курьеры. Мест для дворников полно. Сходи - пособеседуйся. Там твоё место.

> Ну так я себе ряд операций с виртуалками прекрасно оптимизнул.

Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с ардуинками, мелкими виртуалочками и прочим компостом. Нужна "плаформа" для возможности быстро решить задачу. Давай наналог PowerCLI для kvm. Тебя больного с баш-портянками в комплекте к сервису нормальным людям не надо.

> Более того - я себе _генерацию_ дебутстрапом наваял - с моими кастомизациями.

Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь.

>  У вас там уровень сцаного эксплуатанта.

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

>  А на этой повар-щели я бы часами долбался с тем же самым, воюя с не теми типами данных мля, и чем там еще. Оно мне надо?!

Да все уже поняли что ты головка от патефона. Не пробовал это сделать но мнение имеешь.

> А, да, ваш коллега пох (или нах?) таки - вот - плакался что вмварь сожрали. Вас ждут интересные времена! И хорошо что все это - не у меня :)

Ты не поверишь. powershell от этого никуда не денется. Как и модули к остальным виртуальным средам.

Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост павлиний распушил.

Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?

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

685. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 23-Янв-24, 21:48 
> Скопипасть в поискарь и найди что делает PSReadLine, потом рассказывай как в
> баш это круто.

Меня от шелла интересует 2 сценария: oneliner руками на 1 раз, "here and now". Либо batch mode штука, управляемок параметрами командлайна. Зачем мне вон то я хз.

Пытаться из шелла крутую среду программирования? Бессмысленно и беспощадно.

> Во вторых примудил мифические минусы. Которые кроме тебя никто не наблюдает.

Я и смотрю, аж виндузеры WSL что-то полюбили.

> Это любители башпорятнок рассказывают? Ну те что в соседних треда точно такой
> же аргумент приводят на тему системд и другой системы инициализации.

Странно что я ненавижу спагетти код независимо от яп? Но у баша в целом команды и параметры лаконичнее в разы. Печатать меньше -> трабл решается быстрее.

Системд приветствуется ... по той же причине. У меня даже есть гибриды, где шелл и systemd играют в унисон, на пару. Скрипт прописывает и активирует юнит. Юнит потом тоже запускает скрипт. Я использую плюсы тулсов оставляя минусы за бортом. А в целом оркеструется забавное действо бутстрапа VM с минимумом возни.

> Только там лапша в баше у них.

А я ей ТАМ и не хочу пользоваться, если можно это урезать. Но кастом это кастом, там скрипт пригодится уже. Просто точек кастомизации 1-2, а остальное из фич системды и сделано.

> Ты про алиас то в поисковик можешь вбить болезный? Ну и показать
> насколько букв команда в баше cd больше цмдлета в пауршеле cd?

Ага, костыли фичой объявить. Это в духе MS.

> правила именования команд сделать и их соблюдать. А поверх сделать просто алиасы.

Шелл создан для автоматизации хаоса. Он хаотичен в 95% случаев. А концептуальную архитектуру проекта, клевые апи и структуры уместнее разводить где-то еще.

> промолчу. Переносимость это не про тебя.

Я могу в стандартный "posix shell" уложиться если это принципиально. А ps нигде кроме винды нет по сути. Но винда и мак для меня не в приоритете. Я инструментирую R&D линуха, это уместнее из линуха.

> Как же ты лохов обувать будешь, если подпиливать твои портянки не надо будет под каждый чих.

Майнтайнить шеллскрипты? Мсье знает толк...

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

Я не хотел крутое програмирование в шеле, я хотел мелкую автоматизацию по месту и быстрое решение насущных проблем. Если вам то проще, вы это и делайте. Мне это не надо от шелла.

> Чем писать десятки строк под каждую ОС и шел.

Я могу писать под posix shell, если надо. А ps на осях отличных от винды не в ходу вообще.

> пиши партянки с макаронинами под мак-вин-лин и разные шелы.

Пишу либо "под posix shell" - максимального компат, либо "под баш", 2 конфиги максимум.

> Ну так все и поняли что ты не умеешь в пайплайны.

У меня нет цели изобразить фантомаса в очках на аэроплане любой ценой из той кривули.

> Сходи - пособеседуйся. Там твоё место.

У кого что болит, видимо.

> Опять передерг. Никого тут и в мире не интересуют твоё пердольнье с
> ардуинками, мелкими виртуалочками и прочим компостом.

Оно меня интересует. А так в баш и позиксшелл многократно больше народа могет, есчо.

> Нужна "плаформа" для возможности быстро решить задачу.

Кому нужна - тому и карты в руки! С фига меня ваши задачи должны волновать больше моих хз. Для меня мои задачи приоритетнее, збс должно быть - там.

> Да понятно что ты с пердуинками там балуешься, но тут ты этим никого не удивишь.

Дреппера vs arm напоминает. И вот где дреппер а где арм теперь? :)

> пишет письмо сатья-наделле, картина маслом.

Мне от этих раджа-насреддинов к счастью ничего не надо.

> Не пробовал это сделать но мнение имеешь.

Я много чего еще не пробовал, в этом мире много странной хни.

> Ты не поверишь. powershell от этого никуда не денется. Как и модули
> к остальным виртуальным средам.

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

> Резюмируя. Ни одного ответа на вопрос ты не дал, только попередергивал. Хвост
> павлиний распушил.

А я и не собирался играть по вашим правилам. Поздравляю с прозрением.

> Скажи а вот твоё инфоцыганство здесь помогает тебе дуриков находить?

Оно помогает мне находить единомышленников. Вместе мы надерем ваши задницы по полной программе. Есть такое ощущение.

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

690. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (690), 24-Янв-24, 06:18 
Резюмируя два.
Инфоцыган 294й забыл сам с чего начал(автодополнения нет, коротких команд нет и т.д.). Определенные решения системы становятся плюсами или минусами в зависимости от того по какие системы сравниваются. Лапша шела vs системд конечно в плюс системд. Лапша шела vs пауршел конечно в плюс шела. Алиасы в шеле vs алиасы пауршела конечно в плюс шела. Короткие ничерта не понятные команды в шеле vs длинные опции в системд конечно плюс системд. Короткие ничерта не понятные команды в шеле vs длинные команды по стандартам в пауршел конечно плюс шела.
Ну и дальше портянки художественного свиста. В конце не преминул рассказать про свои латентные потребности. Как же 294й да про орган которым думает не расскажет.
Инфоцыган, тебе самому позориться не смешно? Ты же не тянешь в дискуссию. На работу тебя подрядить нельзя - это же по комментам видно что ты за работник.

Ты так и не рассказываешь. Что у тебя с повреждениями головного мозга была? Чего скрывать то?

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

586. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 16-Янв-24, 22:10 
> автодополнение в том уродце не работает по сути никак,

А когда пишешь скрипт в любимом редакторе, то  никакого автодополнения для этого чудовища вовсе нет.

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

322. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (115), 15-Янв-24, 15:23 
Это объясняется тем, что всё это нужно постоянно набирать. Что касательно rust, то сокращения норм, но не норм | и '. Если с ' ещё как-то можно понять зачем пришлось так сделать, то накой хер взяли | понять уже сложно, ровно как и для чего напичкали ЯП вредными элементами функциональщины. В совокупности падает читабельность кода.
Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

439. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от fuggy (ok), 15-Янв-24, 23:35 
То-то наверно лучше в C++ когда звёздочка обозначает сразу 4 разных операции. А без функциональщины, лямбд современный язык уже не язык. В Rust итераторы более читабельные, чем императивная возня с указателями. В C++ между прочем тоже лямбды есть со своим специфическим синтаксисом.
Ответить | Правка | Наверх | Cообщить модератору

406. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от Аноним (-), 15-Янв-24, 20:25 
> First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax

Или это значит "мои старческие мозги скатываются в деменцию, новых символов отличных от 'в С/С++' я запомнить не могу; пожалейте старичка"

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

499. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +2 +/–
Сообщение от Аноним (499), 16-Янв-24, 11:14 
Или это значит, что разработчики Раста не смогли осилить нормальный синтаксис, а сейчас уже поздно.
Ответить | Правка | Наверх | Cообщить модератору

574. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (573), 16-Янв-24, 19:03 
Это значит лишь то, что Линус, будучи взрослым человеком, способен определить что является его персональным мнением, а что объективной реальностью, о чём и пишет («in my opinion»). Опеннету бы поучиться у него.
Ответить | Правка | К родителю #406 | Наверх | Cообщить модератору

691. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Stellarwind (?), 25-Янв-24, 15:39 
Линуса просто уже ранее настойчиво попросили быть повежливее..

Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

и про ядро:

In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

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

692. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от n00by (ok), 25-Янв-24, 17:02 
> Линуса просто уже ранее настойчиво попросили быть повежливее..
> Странно что еще никто не запостил: http://harmful.cat-v.org/software/c++/linus
> C++ is a horrible language. It's made more horrible by the fact
> that a lot of substandard programmers use it, to the point
> where it's much much easier to generate total and utter crap
> with it. Quite frankly, even if the choice of C were
> to do *nothing* but keep the C++ programmers out, that in
> itself would be a huge reason to use C.

На это я отвечал в #211

> и про ядро:
> In fact, in Linux we did try C++ once already, back in
> 1992.
> It sucks. Trust me - writing kernel code in C++ is a
> BLOODY STUPID IDEA.

И на это тоже. Правда, не на цитату Линуса, а на изложенный экспертом похожий смысл. Подсказывать не хочу -- думайте сами над очевидным ляпом, если считает себя знатоком С++.

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

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

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




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

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