Смотрю вакансии на Rust — в 95% случаев там требуется знание Linux. Да и в С++ таких вакансий больше половины. Вопрос — что под этим подразумевается?
Я под разные платформы писал на С/С++: и OS/2, и HP UX, и FreeBSD. Ну и линукс/винда/мак конечно. И не скажу, чтобы столкнулся с большой разницей! В последнее время все равно многоплатформенные фреймворки использовались, типа Boost.
Но ведь эта разница есть?! Знаю, что сокеты слегка разные; и примитивы многопоточности. Плюс я подозреваю, что сейчас под знанием Unix подразумеваются Docker и Kubernetes (c ними пока не сталкивался). Поэтому вопрос:
Что обычно ходят от программиста, когда в вакансии заявляют Unix?
И где это лучше изучить (хотя бы на базовом уровне).
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
Как я полагаю, это значит быть уверенным пользователем, уметь что-то там администрировать и настраивать,
знать более-менее bash, уметь писать простые конфиги на баше. Если съумели настроить рабочее окружение для
себя и скомпилировать какие-нибудь свои программы или OS какой, то вполне знаете Unix.
Также, я бы добавил знание docker'а -- создание и управление образами и т.п.
Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
Как минимум posix api, его примитивы и особенности. Пайпы, доменные сокеты, разделяемая память и прочее.
Сверху типичное устройство и окружение линуксовой (как правило) ОС. Файловые системы, старт, стоп и интеграция сервисодемонов. Зависит от требуемой специфики.
Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
Я сам не знаю линукс и в свете последних событий вынужден его изучать, для минимального знания надо уметь отвечать на такие вопросы:
1) ориентироваться в файловой системе, понимать где лежат файлы приложений, библиотек, настроек
2) как управлять учетками
3) как раздать доступы к файлам разным учеткам
4) как удаленно подключиться к системе и управлять ей
5) как автоматизировать массовые операции, утилиты и язык командной строки
6) как устанавливать приложения на линукс
7) как управлять фоновыми слубами линукса и создавать, как запускать задачи по расписанию
8) как взаимодействуют процессы между собой (форк, пайп, сигнал итд) и с ОС
9) какие службы в сетях на базе линукс используются: Управление учетными записями в сети, почта, сетевые папки, миниторинг и управление
10) какие есть графические оболочки и как создавать gui
11) какие есть библиотеки\компоненты ОС для решения задач
B>И где это лучше изучить (хотя бы на базовом уровне).
Гугл, ютуб пока не закрыли
Все это пишут, но у всех разное понимание и разные требования.
Обычно, это спартанский минимум: открыть консоль, склонировать гит репозиторий, запустить cmake, запустить gcc. Для Rust — склонировать гит репозиторий, установить rustup, запустить cargo. Плюс apt install нужных зависимостей.
Возможно, зайти по ssh на другой хост и задеплоить проект туда. Очень редко — запустить lldb (gdb — в сад престарелых), редко — потому что линуксоиды не любят отладчики (потому что их у них нет хороших) и чаще полагаются на printf и логи. Но, по-хорошему, нужно уметь дебажить в линуксе. Или тоже полагаться на логи.
Всякие тонкости администрирования, что здесь перечисляют в соседних ответах — это либо закидоны линукс маньяков, либо конторы экономят на девопсах — типичного разработчика это не касается.
В общем, если умеешь клонировать гит репозиторий и собирать проект не только с помощью Проводника и TortoiseGit, то можешь смело забить на этот пункт в вакансиях, так как мелочи подучишь на ходу. А если им нужен девопс или админ — они скажут сами ещё на собеседовании.
Здравствуйте, gandjustas, Вы писали:
G>Я сам не знаю линукс и в свете последних событий вынужден его изучать, для минимального знания надо уметь отвечать на такие вопросы:
Ты говоришь как наниматель или как работник? Если первое — дело твоё, если второе — ты слишком заморочился.
G>1) ориентироваться в файловой системе, понимать где лежат файлы приложений, библиотек, настроек
Да
G>2) как управлять учетками
Нет
G>3) как раздать доступы к файлам разным учеткам
Нет
G>4) как удаленно подключиться к системе и управлять ей
Да
G>5) как автоматизировать массовые операции, утилиты и язык командной строки
Иногда, но гуглится
G>6) как устанавливать приложения на линукс
Да, гуглится
G>7) как управлять фоновыми слубами линукса и создавать, как запускать задачи по расписани
Редко, гуглится
G>8) как взаимодействуют процессы между собой (форк, пайп, сигнал итд) и с ОС
Да, но это и обычный виндузятник знает/слышал про линукс
G>9) какие службы в сетях на базе линукс используются: Управление учетными записями в сети, почта, сетевые папки, миниторинг и управление
Не распарсил
G>10) какие есть графические оболочки и как создавать gui
Не нужно, потому что разработка под линукс — не про гуи, в Rust — тем более.
G>11) какие есть библиотеки\компоненты ОС для решения задач
Да, но обычно это кросс-платформенное
В моём понимании это быть консольным пользователем линукса. Т.е. уметь по ssh зайти на сервер, посмотреть логи, залезть в докер-контейнер, там чего-нибудь посмотреть, погрепать, поискать, простой скрипт на баше написать, хотя бы и с гуглом.
Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
Умение запустить компилятор из командной строки, посмотреть логи, заскриптовать что-нибудь примитвно-однопроходное. Ну и основные концепции: пайпы, все есть файл, слэши не в ту сторону развернуты, как пакеты ставить, как маны читать, как права настроить, как демона изгнать. Короче, ничего запредельно сложного.
В идеале да, хочется чтобы и про интерфейсы ядра знал, и в сигналах разбирался, и лимиты понимал. Но где-ж такого найдешь?
B>И где это лучше изучить (хотя бы на базовом уровне).
Можно почитать что-то типа Linux Bible или Linux Complete Reference. Они толстые, но там свободно пропускать все, что касается настроек конкретного софта.
Здравствуйте, Basil2, Вы писали:
B>Баш же это командный интерпретатор, как я понимаю. Как на нем можно писать конфиги?
Наверняка имелось в виду "скрипты".
Здравствуйте, gandjustas, Вы писали:
G>Я сам не знаю линукс и в свете последних событий вынужден его изучать, для минимального знания надо уметь отвечать на такие вопросы: G>1) ориентироваться в файловой системе, понимать где лежат файлы приложений, библиотек, настроек
Спасибо. Откуда этот список? Опыт хождения по собеседованиям или что-то еще?
B>>И где это лучше изучить (хотя бы на базовом уровне). G>Гугл, ютуб пока не закрыли
Ну, этим программиста не напугать.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Basil2, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Я сам не знаю линукс и в свете последних событий вынужден его изучать, для минимального знания надо уметь отвечать на такие вопросы: G>>1) ориентироваться в файловой системе, понимать где лежат файлы приложений, библиотек, настроек
B>Спасибо. Откуда этот список? Опыт хождения по собеседованиям или что-то еще?
Я нанимаю. Это из тех задач, которые возникали за последний месяц, я только обобщил некоторые вещи.
Здравствуйте, flаt, Вы писали:
F>В общем, если умеешь клонировать гит репозиторий и собирать проект не только с помощью Проводника и TortoiseGit, то можешь смело забить на этот пункт в вакансиях, так как мелочи подучишь на ходу.
Да я так и говорил: что умею в ssh, gcc и gdb. Но было видно, как собеседователи сразу разочаровывались. Возможно, это специфика вакансий на Расте — там высоконагруженность, а это не про gcc/gdb...
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Basil2, Вы писали:
B>Здравствуйте, flаt, Вы писали:
F>>В общем, если умеешь клонировать гит репозиторий и собирать проект не только с помощью Проводника и TortoiseGit, то можешь смело забить на этот пункт в вакансиях, так как мелочи подучишь на ходу.
B>Да я так и говорил: что умею в ssh, gcc и gdb. Но было видно, как собеседователи сразу разочаровывались. Возможно, это специфика вакансий на Расте — там высоконагруженность, а это не про gcc/gdb...
Зависит от области и вакансий. Ты бы и спросил, а что именно им хочется? От этого и плясать — либо они хотят девопса на дурняка взять (особенно русскоязычные замечены в экономии), либо действительно область требует. С другой стороны, если озвучат свои хотелки, может, ты вполне подходишь. А нет — вакансий много, выбор большой.
Здравствуйте, Basil2, Вы писали:
B> Возможно, это специфика вакансий на Расте — там высоконагруженность, а это не про gcc/gdb...
"Высоконагруженность" — это специфика всего *nix (от языка не зависит). Т.е. умение собрать бинарник, который запустится в нужном окружении нужным образом и будет хоть как-то выполнять бизнес-логику, это обязательное минимальное условие (как раз те самые условные "ssh, gcc и gdb, почитать логи").
Дальше начинаются тонкости предметной области без знания/понимания которых ты просто не сможешь писать программы удовлетворяющие требованиям бизнеса. И вот как раз про эти предметные тонкости (для каждой предметной области свои) собеседующие и хотят поговорить. Условно, если это сетевые приложения, то про обеспечение отказоустойчивости, защиту от сбоев, контролируемую деградацию, согласованность и т.д. вплоть до банального "записать сетевую сессию через tcpdump и/или воспроизвести запрос через telnet/netcat/tcpreplay".
Здравствуйте, уважаемый gandjustas, Вы писали:
G>Я сам не знаю линукс и в свете последних событий вынужден его изучать, для минимального знания надо уметь отвечать на такие вопросы: G>1) ориентироваться в файловой системе, понимать где лежат файлы приложений, библиотек, настроек G>2) как управлять учетками G>3) как раздать доступы к файлам разным учеткам G>4) как удаленно подключиться к системе и управлять ей G>5) как автоматизировать массовые операции, утилиты и язык командной строки G>6) как устанавливать приложения на линукс G>7) как управлять фоновыми слубами линукса и создавать, как запускать задачи по расписанию G>8) как взаимодействуют процессы между собой (форк, пайп, сигнал итд) и с ОС G>9) какие службы в сетях на базе линукс используются: Управление учетными записями в сети, почта, сетевые папки, миниторинг и управление G>10) какие есть графические оболочки и как создавать gui G>11) какие есть библиотеки\компоненты ОС для решения задач
Я бы добавил ещё:
— как просмотреть зависимости Linux приложения — от каких библиотек оно зависит
Hint: применение утилиты ldd
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
M>Умение запустить компилятор из командной строки, посмотреть логи, заскриптовать что-нибудь примитвно-однопроходное. Ну и основные концепции: пайпы, все есть файл, слэши не в ту сторону развернуты, как пакеты ставить, как маны читать, как права настроить, как демона изгнать. Короче, ничего запредельно сложного.
И как своего демона — создать и запустить. И сделать перманентно запускаемым при старте OS.
M>В идеале да, хочется чтобы и про интерфейсы ядра знал, и в сигналах разбирался, и лимиты понимал. Но где-ж такого найдешь?
M>Можно почитать что-то типа Linux Bible или Linux Complete Reference. Они толстые, но там свободно пропускать все, что касается настроек конкретного софта.
Для программиста, понимающего простой Си, есть хорошая литература:
1) Linux API. Исчерпывающее руководство | Керриск Майкл.
2) UNIX. Профессиональное программирование | Раго Стивен А., Стивенс У. Ричард.
Здравствуйте, Anton Batenev, Вы писали:
AB>"Высоконагруженность" — это специфика всего *nix (от языка не зависит). Т.е. умение собрать бинарник, который запустится в нужном окружении нужным образом и будет хоть как-то выполнять бизнес-логику, это обязательное минимальное условие (как раз те самые условные "ssh, gcc и gdb, почитать логи").
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Anton Batenev, Вы писали:
AB>>"Высоконагруженность" — это специфика всего *nix (от языка не зависит). Т.е. умение собрать бинарник, который запустится в нужном окружении нужным образом и будет хоть как-то выполнять бизнес-логику, это обязательное минимальное условие (как раз те самые условные "ssh, gcc и gdb, почитать логи").
S>А чем логи читают -- cat, grep или что-еще?
Здравствуйте, Sharov, Вы писали:
S>А чем логи читают -- cat, grep или что-еще?
Смотря что ты хочешь с логами сделать.
cat — просто вывод в консоль, grep — найти строки, соответствующие шаблону (или не соответствующие, если запуск с параметром -v).
Просто посмотреть можно в любом текстовом редакторе или утилите просмотра текстовых файлов. В моей практике бывало, что писал скрипты для того, что бы из логов вытащить нужную информацию и систематизировать её.
Здравствуйте, Sharov, Вы писали:
S> AB>"Высоконагруженность" — это специфика всего *nix (от языка не зависит). Т.е. умение собрать бинарник, который запустится в нужном окружении нужным образом и будет хоть как-то выполнять бизнес-логику, это обязательное минимальное условие (как раз те самые условные "ssh, gcc и gdb, почитать логи"). S> А чем логи читают -- cat, grep или что-еще?
Ну, когда как и в зависимости от того, что тебе от них нужно. tail, sed, awk и другие утилиты работы с текстом в эту же копилку можно добавить.
Здравствуйте, Basil2, Вы писали:
B>Что обычно ходят от программиста, когда в вакансии заявляют Unix?
B>И где это лучше изучить (хотя бы на базовом уровне).
Требования всегда очень разные.
Как минимум хотят чтобы человек не впадал в ступор при виде коммандной строки и мог зайти на удаленный сервер, откомпилировать, запустить проект, посмотреть логи, снать зависший процесс, посмотреть coredump, посмотреть и отредактировать конфиги.
Еще всегда желательно бы понимать всякие мелочи про процессы, потоки сокеты, файлы всякие средства межпроцессного взаимодействия, сигналы и тд. даже если работа идет через кроссплатформенные фреймворки, дьявол всегда кроется в деталях.
Здравствуйте, Basil2, Вы писали:
B>Смотрю вакансии на Rust — в 95% случаев там требуется знание Linux.
Вот это "знание Linux"-это творчество девочек-hr-ок и не более. Знание какой части Linux им нужно? Ядра, юзерспайсового GNU софта? Какого и на каком уровне? На уровне умения grep-ануть или на уровне знкомства с исходниками glibc? В целом, если где такое пишут, то это скорее означает одно: работаем на линуксах, и те, кто кроме окошек MSVS больше ничего никогда не видели, могут не беспокоить.
Здравствуйте, smeeld, Вы писали:
S>В целом, если где такое пишут, то это скорее означает одно: работаем на линуксах, и те, кто кроме окошек MSVS больше ничего никогда не видели, могут не беспокоить.
ИМХО опытному человеку, хорошо владеющему разработкой в MSVS (прежде всего — на C и C++), обычно не составит большой сложности освоиться с GCC и командной строкой Linux.
Ну а кроме окошек студии, если человек владеет QtCreator, и самой разработкой на Qt — то и за Linux-ом дело не станет.
P.S. Владение обычным Си, базируемом на POSIX, ИМХО must have для успеха в теории и практике Linux API.
G>>3) как раздать доступы к файлам разным учеткам F>Нет
Тут все же скорее Да, чем Нет.
Т.к. при отладке программы и при выяснении почему же оно не пашет — под линуксом гораздо чаще, чем под виндой, разгадка оказывается в том, что не хватает прав на такой-то файл/директорию.
G>>>3) как раздать доступы к файлам разным учеткам F>>Нет
K>Тут все же скорее Да, чем Нет.
K>Т.к. при отладке программы и при выяснении почему же оно не пашет — под линуксом гораздо чаще, чем под виндой, разгадка оказывается в том, что не хватает прав на такой-то файл/директорию.
Видимо потому что в linux everithing is a file, в отличие от винды, где есть свои права на файлы, пайпы, сокеты, ветки реестра, процессы, примитивы синхронизации, службы. Прав в виндовом ACL гораздо больше, чем в линуксе.
А еще есть привилегии процессов в огромном количестве.
Здравствуйте, AlexGin, Вы писали:
AG>ИМХО опытному человеку, хорошо владеющему разработкой в MSVS (прежде всего — на C и C++), обычно не составит большой сложности освоиться с GCC и командной строкой Linux.
Это мелочи. Конечно не составит труда. Только вот Linux-это прежде всего среда разработки. Вся ОС. Так же, как и винда. Это разные миры. И вот из мира винды в мир линукса за пару дней не переползёшь.
Здравствуйте, gandjustas, Вы писали:
K>>Т.к. при отладке программы и при выяснении почему же оно не пашет — под линуксом гораздо чаще, чем под виндой, разгадка оказывается в том, что не хватает прав на такой-то файл/директорию. G>Видимо потому что в linux everithing is a file, в отличие от винды, где есть свои права на файлы, пайпы, сокеты, ветки реестра, процессы, примитивы синхронизации, службы. Прав в виндовом ACL гораздо больше, чем в линуксе.
Нет. Потому что в виндах все работают администратором, а в линуксах бай дизайн (как правило бай дизайн инсталлятора) — обычным юзером. Вот и выходит что в виндах сильно реже встречаются проблемы доступа. Тупо потому что админу как правило можно.
Здравствуйте, AlexGin, Вы писали:
AG>Я бы добавил ещё: AG> — как просмотреть зависимости Linux приложения — от каких библиотек оно зависит AG>Hint: применение утилиты ldd
+1. И до кучу rpath и
ldoconfig -p
S>Это мелочи. Конечно не составит труда. Только вот Linux-это прежде всего среда разработки. Вся ОС. Так же, как и винда. Это разные миры. И вот из мира винды в мир линукса за пару дней не переползёшь.
Категорически СОГЛАСЕН
Много вещей, от которых СРЕДНИЙ разработчик на винде не подозревает.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
ИМХО, это сборка (нет, не умение в gcc из командной строки, хоть и не повредит)
что-то типа configure + make или cmake
концепция toolchain, cross-compile, sysroot и вот это вот все
нюансы компилера, линкера
опции компилятора gcc, clang ..., в случае использования cmake как эти опции выставить правильно, а не тупое set (CMAKE_CXX_FLAGS -fpic)
__attribute__ и т.д.
опции линкера (-Wl и прочие радости)
symbols visibility, versioning, концепция linker-name, soname, real-name ...
ldd/objdump/readelf/nm
зависимости
установка — yum, apt, make install ...
поиск — find_package (cmake), pkg_config ...
смирится что GUI — не юзабельно, привыкать к vim или VS Code + ssh на винде ssh — must have, без него линукс не нужен
дальше доменная специфика, типа сокетов, kqueue, epoll, uring ...
Здравствуйте, Basil2, Вы писали:
B>Смотрю вакансии на Rust — в 95% случаев там требуется знание Linux. Да и в С++ таких вакансий больше половины. Вопрос — что под этим подразумевается?
0) как выйти из vi...
1) что такое форк-бомба?
2) как остановить форк-бомбу?
3) что нужно сделать заранее, чтоб форк-бомба не обрушала систему?
4) почему/где в open() нужно число зверя?
5) почему несмотря на число зверя файлы создаются с правом записи только у пользователя?
6) что случается когда окно терминала закрывается, как завершаются процессы?
7) как выйти из программы не реагирующей на Ctrl-C ?
8) как приостановить и продолжить вывод бесконечно выпечатывающей программы?
9) как переключаться между разными программами в одном терминале?
10) как сменить сочетание клавиш Ctrl-C на другое?
11) как запустить внешнюю программу из вашей программы и перенаправить ввод-вывод в сеть (сокет),
и далее на терминал на удалённой машине, какие действия по запуску программы нужны (дан открытый уже сокет).
12) как в своей программе реализовать ввод любых клавиш Ctrl-<что-угодно> ?
13) как убить одной командой группу разных процессов принадлежащую одному шеллу (запускали как: sh -c "program1 & program2 & program3...")
14) как превратить программу в демона?
15) как выполнить программу без прерывания даже если терминал закроется (например, при удалённом подключении через ssh) ?
16) почему/как некоторые программы пишут в терминал если stdin/stdout/stderr у них перенаправлены?
(как ядро различает разные терминалы у разных программ в этом случае?)
