Здравствуйте, 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 у них перенаправлены?
(как ядро различает разные терминалы у разных программ в этом случае?)
