Думаю все дело в естественно отборе. Опытный админ с хорошим резюме это один из сотни выживших, поскольку админов наказывают по сути за каждый прокол и их зарпалата напрямую связана со стабильностью и качеством их работы. Программистов, во-первых, на порядок больше, во-вторых, они обычно непосредственно ни за что не отвечают, для этого есть прослойка менеджеров и тимлидов, а в-третьих, вмененые им ключевые показатели имеют очень слабое отношение к эксплуатационным качеством, за это обычно отвечает опять таки, кто-то другой.
Да и с железом в нормальных ЦОДах ездить не надо. Заказываешь железку, отправляешь транспортной компанией, на том конце её принимают и ставят. Вполне распространеная услуга. Хотя обычно платная.
Лучше вообще не писать на баш с расчетом на кросиспользование с Freebsd, поскольку там будет куча проблем c совместимостию gnu и bsd утилит, а расчитывать на установленные порты это рисковано. Поэтому только голый sh, и максимально древние спеки sed, awk, grep.
Ну и во-вторых, ну ребят, ну все уже. Мне конечно ещё приходится иногда писать с учетом Unix/Aix/Solaris, но для большинства вопросы совместимости уже не стоят. Linux захватил Unix сервера прочно.
Python очень многословен на фоне bash. Не надо забывать, что сам по себе шелл довольно плох, но его в здравом уме и не используют для написания серьёзных программ. Он нужен как клей в unix среде и с этой ролью он справляется лучше чем python, поскольку имеет специально заточенные под это примитивы, типа перенапрвления потоков, опроса выходных параметров и управления фоновыми задачами. На python все это разумеется есть, но не на уровне примитивов.
Наличие оптики внутри интересно, но внушает опасение. Что будет с механической прочностью и пылью на этих коннектах? Или там есть какая-то хитрая механика прикрывающая порт в отстутсвии сервера.
Это и есть обертка по типу shorewall или ещё чего подобного. Сделана она, в принципе, с благой целью, чтоб создать нечто подобное виндовому десктопному файрволу.
Да кто же его знает. Вот ты лучше скажи зачем он в принципе на сервере? Для сложного файрвола он не годится: его концепции вводят слишком много ограничений, которые будут мешаться. А для простого серверного случая комбайн с управлением по DBUS это какой-то оверкилл. Если в нем будет какая-то непонятка то дебажить придется все через тот же iptables trace, а куча паразитных цепочек нагенереных firewalld будут мешать.
Да нету здесь в статье никакой оптимизации. Не преждевременной, не какой-либо другой. Вот если бы он написал код поиска картинки на C или ASM, добавил бы "full kernel bypass", чтоб не нарываться на тормоза ядра операционки, ну и CUDA/OPENCL, для быстрого ресайза картинок. Вот это была бы оптимизация.
А догадаться не хранить картинки в базе данных это не оптимизация, это просто нормальный инженерный подход, который да, почти не распространен из-за крайне низкого уровня "программистов".
Эта статья конечно полезная, но лично для вас. Фишка в том, что паттерны, повторяющеся в вашей работе не факт что будут полезны для других. Например для многих задача вспомнить что он тут делал будет комбинацией команд git status; git show HEAD;
Для привыкания к новым патернам требуется время, а главное не всегда надо их сохранять. Часто можно прям в консоли набить функцию которая нужна вам прям сейчас, но врятли понадобится когда-нибудь ещё.
Например прям сейчас у меня есть функция:
$ type get_console
get_console is a function
get_console ()
{
curl $1 | grep --color=auto -v '| +'
}
Это сиюминутная фишка необходимая мне для того, что я просматриваю кучу логов от Jenkis и они засраны спамом от set +x. Думаю понятно, что без этой функции мне приходилось бы подставлять url, куда-то в средину команды, а так стрелка вверх, ctrl+w, shift-insert. Но нет я не делаю скрипт, не правлю .bashrc, просто набиваю эту функцию прям в командной строке.
Ну и не надо забывать про alias. Класика жанра:
alias ll='ls -alF'
Ну или ваши пять последних файлов (правда не больше 2^15 файлов):
alias ltr5='find . | xargs ls -tr | tail -5'
Косательно вашего репозитория могу сделать вам несколько подсказок, возможно они вам понадобятся.
Имена ваших хелперов неплохо начинать одинаково. Я например предпочитаю префикс hlp_. В этом случае, даже если подзабыл как называлась функция, то нажав на таб получишь список (если пользоваться zsh, то можно и список с пояснениями вывести)
Если расширяете известные команды или делаете по ним шорткаты, то проще называть созвучной с оригнальным именем командой. Опять таки классика ls и alias ll.
Нет никакой необходимости "инсталировать" это дело. Гораздо проще написать один sh файл с функциями и делать source из .bashrc. Это позволятет просто соурсить из вашей рабочей папки с гитом. Ну или в вашем случае можно прописать PATH на эту директорию.
Надо писать толковый readme. Со временем патерны работы поменяются и разобраться что вы писали год или два назад будет очень сложно. Написать для себя man вообще бесценно.
Вы похоже совсем не разбираетесь в вопросе, раз считаете, что клон на современной СХД, это полная копия. Copy-on-Write придумали так давно, что никто это уже новостью не считает. Размер каждого клона соответствует дельте изменений между основым образом и клоном. Стоит это копейки, во многих банглах современных СХД это присутствует вообще бесплатно.
Поэтому да, экономии здесь нет от слова совсем. Есть совершенно идиотская ситуация, которая была в у клиента до вас и не самое оптимальное решение с вашей стороны.
Мда, что-то я не понимаю в этих ваших Ингострахах. Для того чтобы обслуживать одну СХД c синпровижененгом и одну железную машину с виртуалками на ней нужен отдел? Т.е. там не автоматизирована развертка приложухи? Жесть какая-то. А разработчики тоже ваши, Кроковские?
Странное решение, хотя очень прямолинейное. Во-первых, как выше сказали не ясно почему не использовать thin provisioning на СХД или операционной системе? Во-вторых, зачем вам копии полной базы? Да, для произоводительности и расследования это необходимо, но тогда выгоднее делать моментальные снепшоты, или временно открывать стендбай (у вас же Oracle?) Но для разработки это не надо. Для нормальной разработки, по крайне мере.
Сдается мне, что весь накал борьбы с рекламой слабо связан собственно с ней. Тут скорее проблема баланса чувства «брезгливости» и ценности контента (или услуг) на сайте.
Есть ли ценность в вашем сайте? Для меня особо нет, но если бы я был вашим пользователем, то я бы нашел простое решение отблагодорить, без выключения adblock. Я имею ввиду кнопочку купить билет. Наверняка вы с этой кнопки процент имеете, и это более чем нормально. Пришел, почитал, купил — это норма для такого сайта.
Я не ханжа, и понимаю, что хотя билет у вас может быть дороже, чем в самом кинотеатре, но я готов потратить немного больше за то, что получаю удобную услугу. Я привык слегка переплачивать: продавцу в ларьке с фруктами, за то что они свежие и рядом с домом, курьеру магазина, за то что не надо никуда ехать и т.д. Ровно также, я готов подкидывать денег сайту, которым пользуюсь, если получают от него ответную услугу или уникальный контент. Я и википедию донатил, было дело, и на авторевью подписан, и пара молодых музыкантов получают от меня по баксу за каждую новую песню (patreon.com, если кому интересно). От создателя сайта мне нужно одно из двух: хороший контент или нужную услугу. И тогда я готов оплачивать собственную «брезгливость».
> добавлять альтернативный класс устройств в ядро.
Это ничего не изменит, поскольку будет переключение контекста для работы с устройством. Подход при котором инструменты ядра не используются совсем не нов, например для работы с сетью или тот же direct access к дискам, который используют базы данных.
И опять упераемся в задержки. Между релизом продукта, собиранием пачки, написанием ТЭО на пачку и собственно её отработкой пройдет существенный срок, за который можно и экспертизу растерять и дизлайк получить от бизнеса.
Думаю все дело в естественно отборе. Опытный админ с хорошим резюме это один из сотни выживших, поскольку админов наказывают по сути за каждый прокол и их зарпалата напрямую связана со стабильностью и качеством их работы. Программистов, во-первых, на порядок больше, во-вторых, они обычно непосредственно ни за что не отвечают, для этого есть прослойка менеджеров и тимлидов, а в-третьих, вмененые им ключевые показатели имеют очень слабое отношение к эксплуатационным качеством, за это обычно отвечает опять таки, кто-то другой.
Да и с железом в нормальных ЦОДах ездить не надо. Заказываешь железку, отправляешь транспортной компанией, на том конце её принимают и ставят. Вполне распространеная услуга. Хотя обычно платная.
Обычно и свичи свои покупают.
Лучше вообще не писать на баш с расчетом на кросиспользование с Freebsd, поскольку там будет куча проблем c совместимостию gnu и bsd утилит, а расчитывать на установленные порты это рисковано. Поэтому только голый sh, и максимально древние спеки sed, awk, grep.
Ну и во-вторых, ну ребят, ну все уже. Мне конечно ещё приходится иногда писать с учетом Unix/Aix/Solaris, но для большинства вопросы совместимости уже не стоят. Linux захватил Unix сервера прочно.
Python очень многословен на фоне bash. Не надо забывать, что сам по себе шелл довольно плох, но его в здравом уме и не используют для написания серьёзных программ. Он нужен как клей в unix среде и с этой ролью он справляется лучше чем python, поскольку имеет специально заточенные под это примитивы, типа перенапрвления потоков, опроса выходных параметров и управления фоновыми задачами. На python все это разумеется есть, но не на уровне примитивов.
Наличие оптики внутри интересно, но внушает опасение. Что будет с механической прочностью и пылью на этих коннектах? Или там есть какая-то хитрая механика прикрывающая порт в отстутсвии сервера.
Это и есть обертка по типу shorewall или ещё чего подобного. Сделана она, в принципе, с благой целью, чтоб создать нечто подобное виндовому десктопному файрволу.
Да кто же его знает. Вот ты лучше скажи зачем он в принципе на сервере? Для сложного файрвола он не годится: его концепции вводят слишком много ограничений, которые будут мешаться. А для простого серверного случая комбайн с управлением по DBUS это какой-то оверкилл. Если в нем будет какая-то непонятка то дебажить придется все через тот же iptables trace, а куча паразитных цепочек нагенереных firewalld будут мешать.
Впервые увидил, что кто-то пользуется firewalld. Обычно инструкции в интернете сводятся к тому как его выпилить.
Да нету здесь в статье никакой оптимизации. Не преждевременной, не какой-либо другой. Вот если бы он написал код поиска картинки на C или ASM, добавил бы "full kernel bypass", чтоб не нарываться на тормоза ядра операционки, ну и CUDA/OPENCL, для быстрого ресайза картинок. Вот это была бы оптимизация.
А догадаться не хранить картинки в базе данных это не оптимизация, это просто нормальный инженерный подход, который да, почти не распространен из-за крайне низкого уровня "программистов".
Ну если это тащить на сервер, то надо пакетировать однозначно, хотя можно и в хомяк положить.
Эта статья конечно полезная, но лично для вас. Фишка в том, что паттерны, повторяющеся в вашей работе не факт что будут полезны для других. Например для многих задача вспомнить что он тут делал будет комбинацией команд git status; git show HEAD;
Для привыкания к новым патернам требуется время, а главное не всегда надо их сохранять. Часто можно прям в консоли набить функцию которая нужна вам прям сейчас, но врятли понадобится когда-нибудь ещё.
Например прям сейчас у меня есть функция:
Это сиюминутная фишка необходимая мне для того, что я просматриваю кучу логов от Jenkis и они засраны спамом от set +x. Думаю понятно, что без этой функции мне приходилось бы подставлять url, куда-то в средину команды, а так стрелка вверх, ctrl+w, shift-insert. Но нет я не делаю скрипт, не правлю .bashrc, просто набиваю эту функцию прям в командной строке.
Ну и не надо забывать про alias. Класика жанра:
Ну или ваши пять последних файлов (правда не больше 2^15 файлов):
Косательно вашего репозитория могу сделать вам несколько подсказок, возможно они вам понадобятся.
Вы похоже совсем не разбираетесь в вопросе, раз считаете, что клон на современной СХД, это полная копия. Copy-on-Write придумали так давно, что никто это уже новостью не считает. Размер каждого клона соответствует дельте изменений между основым образом и клоном. Стоит это копейки, во многих банглах современных СХД это присутствует вообще бесплатно.
Поэтому да, экономии здесь нет от слова совсем. Есть совершенно идиотская ситуация, которая была в у клиента до вас и не самое оптимальное решение с вашей стороны.
Зачем тут плодить сущности? Чтоб продать дороже?
Есть ли ценность в вашем сайте? Для меня особо нет, но если бы я был вашим пользователем, то я бы нашел простое решение отблагодорить, без выключения adblock. Я имею ввиду кнопочку купить билет. Наверняка вы с этой кнопки процент имеете, и это более чем нормально. Пришел, почитал, купил — это норма для такого сайта.
Я не ханжа, и понимаю, что хотя билет у вас может быть дороже, чем в самом кинотеатре, но я готов потратить немного больше за то, что получаю удобную услугу. Я привык слегка переплачивать: продавцу в ларьке с фруктами, за то что они свежие и рядом с домом, курьеру магазина, за то что не надо никуда ехать и т.д. Ровно также, я готов подкидывать денег сайту, которым пользуюсь, если получают от него ответную услугу или уникальный контент. Я и википедию донатил, было дело, и на авторевью подписан, и пара молодых музыкантов получают от меня по баксу за каждую новую песню (patreon.com, если кому интересно). От создателя сайта мне нужно одно из двух: хороший контент или нужную услугу. И тогда я готов оплачивать собственную «брезгливость».
Это ничего не изменит, поскольку будет переключение контекста для работы с устройством. Подход при котором инструменты ядра не используются совсем не нов, например для работы с сетью или тот же direct access к дискам, который используют базы данных.
А Reply-To это часто используемый заголовок. Например для групповых рассылок.