Яду? Ну вообще старался воздерживаться. Даже колпачки резиновые на клыки надевал (шутка). Может разьве что кислинки чуть чуть добавил, чтоб читать было интереснее.
А при ответах в списке рассылок, вообще взял за правило отвечать только на следующий день. Токсичность там вообще ни к чему.
Картинка — работа наших дизайнеров — так что наверное будет собственностью. Хотя лично меня зелёные губы немного пугают.
Виртуалка конечно хорошо разграничит приложения, но есть и Docker, вроде как Snappy и Flatpak решают задачу разграничения приложений, запуская их в песочнице?
Сам я этот вопрос не копал глубоко.
Поверьте, проблем и так достаточно, так что сознательно их никто не делает, ну мне так кажется, по крайней мере для Linux.
Техподдержка нужна для организаций, бизнес которых зависит от этого ПО. И лицензия — типа страховка, чтобы в случае чего обратиться, чтобы «тебе сделали чтоб работало».
Альтернативный есть вариант — набирать и оплачивать штат специальстов, чтоб поддерживали твоё ПО. Этот вариант как правило выходит дороже.
Если продукт работает плохо, требуется большой штат тех.поддержки, программистов на поддержке, а это затраты. Так что делать плохо не выгодно никому, так что все вроде как стараются сделать хорошо, но не у всех получается.
На счёт модулей я бы сказал так: чем он проще и примитивнее, тем лучше. Если есть возможность переложить что-то на user space код, то это нужно делать.
Но увлекаться тут тоже нельзя, так как если для обработки каждого события из модуля дёргать обработчик в user space, то сильно просядет performance.
В общем драйвера — это отдельная область программирования с кучей ограничений, если сравнивать с user space.
Ну именно для Veeam Agent for Linux для всех дистрибутивов с dpkg один пакет veeam под каждую платформу (i386 и amd64) и один пакет veeamsnap (общий, так как в сорцах). Всплыли проблемы с поддержкой именно Debian 10 в скриптах запуска сервиса, но в бэте мы это уже поправили. А пока версия 3.0 не ставится нормально только на Debian 10.
Ну Debian 6 не поддерживается его создателями, так что и мы в следующей версии откажемся от её официальной поддержки. А вот Red Hat 6.0 всё ещё жив и поддерживается, и наши пользователи не обрадуются, если мы его зарежем.
Enterprise пользователи очень не любят кардинально менять свою инфраструктуру. Это десктопы и ноуты живут лет по 5-7, а серваки живут десятилетиями. Им меняют процессоры, накопители, но система с данными продолжает жить.
Божеш-мой. Ещё и nix. Ох уж эта вариативность…
«Ядро за кадром» — ну для большинства аппликух конечно можно его оставить за бортом.
«Линус с нами, проблем не будет» — проблемы будут всегда, больше или меньше. Я думаю, пока у ядра есть коммерческое применение — над ним будут работать. Большая удача, что оно появилось на значительной доле смартфонов, которые продают с предустановленным ядром. Я помню как работал Linux 15 лет назад… Это была боль.
Прям призыв в очередному holywar-у! Придумывать ничего не надо. Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива. Работа эта сложная, и не всегда окупается, потому реально живых дистрибутивов не так-то и много. Ну и потом, некоторое разнообразие всё равно нужно. К примеру в Германии предпочитают SUSE, в США — Red Hat. В последнее время хорошо поднялась Ubuntu, подвинув конкурентов. Они деньги на поддержке зарабатывают, а потому и вкладывают в развитие. Реально на фанатах держится может только Arch, но это явно не ширпотреб.
Почему именно эти решения для резервного копирования выбирались для сравнения?
Продукты значительно различаются по функциональности. Veeam Agent for Linux позволяет восстанавливать тома машины целиком, так как делает резервную копию именно тома. Bacula, как и большинство opensource средств для резервного копирования, делают резерную копию файлов с живой машины.
Инкрементальный режим у Veeam Agent for Linux тоже есть. Его тоже было бы не плохо сравнить. Данные для инкрементального режима тоже было бы хорошо привести.
На каких аппаратных и программных средствах проводились эксперименты? Это обязательно указывать!
Я считаю, что статья, как минимум, требует значительной доработки.
P.S. Режим файлового бэкапа Veeam Backup for Linux на множестве маленьких файликов — это боль. Большие файлы бэкапяться нормально. Так что если надо бэкапить только к примеру базу, то скорость должна быть хорошей. Над оптимизацией режима файлового бэкапа работаем.
Да уж. Статья шибко злая получилась. Прям наболело у автора. Заминусуют… А жалко, потому что, некоторые вопросы подмечены довольно верно, хоть и довольно грубо. Как минимум статья заставляет задуматься.
И на самом деле не важно как именно устроен процесс разработки в команде: некомпетентность помноженная на завышенную самооценку всегда себя проявит в виде проблемы.
Людьми нужно оставаться независимо от того, тестировщик ты или ПМ или кодер. При благоприятном эмоциональном климате в команде многие проблемы решаются в разы быстрее.
И тут фокус вопроса смещается на проблему подбора персонала. Девочки из отдела кадров тебе понабрали МУД-ов, или ты их тоже собеседовал, брал на испытательный срок и решал: вписывается новый человек в команду или нет? А руководитель должен быть психологом и уметь мотивировать, указывать на ошибки и при этом способствовать созданию позитивного эмоционального климата в команде.
И ещё интересно, RHEL 8 планируется распространять для двух архитектрур x86_64 и ARM 64.
Вопрос: MS SQL на rhel 8 будет работать под ARM 64?
В этом случае появляется вариант сэкономить на хостинге, как я понимаю.
Мне лично интересен вопрос: «Зачем?».
Зачем запускать mssql на red hat. С таким же успехом можно поднять виртуалки с виндой или контейнер какой нибудь. Последнее время Microsoft позволяет перемешать Linux и Windows приложения в компот. Зачем? Чтобы добавить проблем администратору? Подскажите, может я не в курсе чего?
Подобного комментария я ждал. Самого когда-то укачивало от отечественных разработок. Однако, реальность такова, что работать приходится не с тем с чем хочется, а с тем что дают.
На самом деле книги есть, но часто они довольно поверхностны. Отметить могу разьве что Robert Love «Linux Kernel Development». Есть на русском.
Есть статьи с примерами. Нужно искать. Про block layer точно помню, читал. Однако, довольно часто они оказываются несколько устаревшими. Собственно именно поэтому и была написана статья, которая позволила актуализировать этот вопрос.
Есть сайты с описанеми Linux Kernel API. Тут www.kernel.org/doc/htmldocs/kernel-api к примеру. Тут linux-kernel-labs.github.io/master тоже хорошо пишут.
Такая документация часто бывает не актуальна, иногда попадаются ошибки (как и для проприетарного кода), но всегда есть исходник. Исходник ядра в принципе хорошо читается, если привыкнуть.
Так что всё есть — нужно искать.
Возможно, я сам не берусь судить об этом, но вот Paolo Valente старательно доказывал что его планировщик очень даже нужен. Кому интересно вот ссыль с LinuxPiter (недавно выложили): www.youtube.com/watch?v=Ea5vHdQgXpw
Ну если исключительно для тренировки навыков программирования — то да. Для этого любой asm подойдёт. Qemu получается как эмулятор старого проца, причем за даром. Можно ещё пробросить виртуальный LPT, на стороне хост-машины сделать эмулятор лифта или пульта или дисплея или поливалки или… и можно писать лабораторки.
А при ответах в списке рассылок, вообще взял за правило отвечать только на следующий день. Токсичность там вообще ни к чему.
Картинка — работа наших дизайнеров — так что наверное будет собственностью. Хотя лично меня зелёные губы немного пугают.
Сам я этот вопрос не копал глубоко.
Техподдержка нужна для организаций, бизнес которых зависит от этого ПО. И лицензия — типа страховка, чтобы в случае чего обратиться, чтобы «тебе сделали чтоб работало».
Альтернативный есть вариант — набирать и оплачивать штат специальстов, чтоб поддерживали твоё ПО. Этот вариант как правило выходит дороже.
Если продукт работает плохо, требуется большой штат тех.поддержки, программистов на поддержке, а это затраты. Так что делать плохо не выгодно никому, так что все вроде как стараются сделать хорошо, но не у всех получается.
Но увлекаться тут тоже нельзя, так как если для обработки каждого события из модуля дёргать обработчик в user space, то сильно просядет performance.
В общем драйвера — это отдельная область программирования с кучей ограничений, если сравнивать с user space.
Не пробовал такое, можно поресёрчить.
Модуль ядра — классический Makefile. User space код собирается с помощью CMake.
Enterprise пользователи очень не любят кардинально менять свою инфраструктуру. Это десктопы и ноуты живут лет по 5-7, а серваки живут десятилетиями. Им меняют процессоры, накопители, но система с данными продолжает жить.
«Ядро за кадром» — ну для большинства аппликух конечно можно его оставить за бортом.
«Линус с нами, проблем не будет» — проблемы будут всегда, больше или меньше. Я думаю, пока у ядра есть коммерческое применение — над ним будут работать. Большая удача, что оно появилось на значительной доле смартфонов, которые продают с предустановленным ядром. Я помню как работал Linux 15 лет назад… Это была боль.
Почему именно эти решения для резервного копирования выбирались для сравнения?
Продукты значительно различаются по функциональности. Veeam Agent for Linux позволяет восстанавливать тома машины целиком, так как делает резервную копию именно тома. Bacula, как и большинство opensource средств для резервного копирования, делают резерную копию файлов с живой машины.
Инкрементальный режим у Veeam Agent for Linux тоже есть. Его тоже было бы не плохо сравнить. Данные для инкрементального режима тоже было бы хорошо привести.
На каких аппаратных и программных средствах проводились эксперименты? Это обязательно указывать!
Я считаю, что статья, как минимум, требует значительной доработки.
P.S. Режим файлового бэкапа Veeam Backup for Linux на множестве маленьких файликов — это боль. Большие файлы бэкапяться нормально. Так что если надо бэкапить только к примеру базу, то скорость должна быть хорошей. Над оптимизацией режима файлового бэкапа работаем.
Всех с релизом RHEL 8!
Однако это не совсем ответ на вопрос.
Да уж. Статья шибко злая получилась. Прям наболело у автора. Заминусуют… А жалко, потому что, некоторые вопросы подмечены довольно верно, хоть и довольно грубо. Как минимум статья заставляет задуматься.
И на самом деле не важно как именно устроен процесс разработки в команде: некомпетентность помноженная на завышенную самооценку всегда себя проявит в виде проблемы.
Людьми нужно оставаться независимо от того, тестировщик ты или ПМ или кодер. При благоприятном эмоциональном климате в команде многие проблемы решаются в разы быстрее.
И тут фокус вопроса смещается на проблему подбора персонала. Девочки из отдела кадров тебе понабрали МУД-ов, или ты их тоже собеседовал, брал на испытательный срок и решал: вписывается новый человек в команду или нет? А руководитель должен быть психологом и уметь мотивировать, указывать на ошибки и при этом способствовать созданию позитивного эмоционального климата в команде.
Вопрос: MS SQL на rhel 8 будет работать под ARM 64?
В этом случае появляется вариант сэкономить на хостинге, как я понимаю.
Зачем запускать mssql на red hat. С таким же успехом можно поднять виртуалки с виндой или контейнер какой нибудь. Последнее время Microsoft позволяет перемешать Linux и Windows приложения в компот. Зачем? Чтобы добавить проблем администратору? Подскажите, может я не в курсе чего?
Подобного комментария я ждал. Самого когда-то укачивало от отечественных разработок. Однако, реальность такова, что работать приходится не с тем с чем хочется, а с тем что дают.
Есть статьи с примерами. Нужно искать. Про block layer точно помню, читал. Однако, довольно часто они оказываются несколько устаревшими. Собственно именно поэтому и была написана статья, которая позволила актуализировать этот вопрос.
Есть сайты с описанеми Linux Kernel API. Тут www.kernel.org/doc/htmldocs/kernel-api к примеру. Тут linux-kernel-labs.github.io/master тоже хорошо пишут.
Такая документация часто бывает не актуальна, иногда попадаются ошибки (как и для проприетарного кода), но всегда есть исходник. Исходник ядра в принципе хорошо читается, если привыкнуть.
Так что всё есть — нужно искать.
Ну если исключительно для тренировки навыков программирования — то да. Для этого любой asm подойдёт. Qemu получается как эмулятор старого проца, причем за даром. Можно ещё пробросить виртуальный LPT, на стороне хост-машины сделать эмулятор лифта или пульта или дисплея или поливалки или… и можно писать лабораторки.