… на мой программерский взгляд, systemd — это одно из лучших, что случилось с Linux за последние 10 лет.
очевидно же, что ваш программерский взгляд, к сожалению, ограничился исключительно поделками шляпы (и тех, кого она продавила).
позволю себе озвучить мнение, что система старта FreeBSD божественна своей простотой и при этом гибкостью.
как и система портов + pkg, кстати.
Написание постоянно работающих служб ешё никогда не было настолько простым и приятным.
да, да.
особенно приятно когда эти службы начинают просто драться между собой :)
t2.nano, t3.nano — о чём-то говорит?
полёт нормальный.
ядро — не GENERIC (для себя ведь старался).
t3.micro — keycloak (openjdk8 под капотом).
А.
ну, и замена NAT Gateway (там где в нём есть необходимость) на t?.nano рулит по деньгам. разворачивается автомагически из Auto Scaling Group. где можно — на спотах.
P.S. по поводу community.
не представляю, куда бы я пошёл, направь e-mail не Colin Percival, а кому-нибудь a-la мьсе о-Торвальдс… то ли вопрос оказался для него плёвый, но с мёртвой точки в правильном направлении столкнул...
… даже нормально настроенная Убунта вряд ли будет тормозить и сбоить.
ню-ню, мсье Аптимизт..
Но, должен сказать, есть какой-то юмор в том, что во времена, когда для пересборки ядра фряхи требовалось часа три
не надо ля-ля ради красного словца: никогда за >20 лет моей памяти ядро не собиралось три часа.
сейчас на древнющем одноядерном ноуте (Samsung R60) ядро FreeBSD 12.0 штатным clang'ом собирается чуть меньше часа. и да — на zfs :)
и не снапшотами едиными… xfs — это вообще каменный век в купе с ext*, jfs, ntfs, hpfs… я вот на zfs ~10 лет храню данные своих серверов и рабочих станций (zfs volumes only). а вы btrfs так используетете?
вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.
по-моему, я предельно ясно выразился, что *BSD в более правильном направлении развивается потому, что там нет системды :)
а линух прикончит системда, когда оно "срастётся" с кёрнелом и гномом в [практически] монолит: отсутствие вариантов — плохо для системы.
и да, я знаю о слухах, что во FreeBSD тоже рассматривается вариант разработки launchd. но как это уже было неоднократно, резкого и безальтернативного перехода a-la linux (а теперь — капец), полагаю, не будет: хочется верить, что мудрости у дядек из беркли больше, чем у горячего финского студента...
Весьма субъективно, с Вашей стороны [что лучше]…
И непоследовательно: голанг нонче пихают во все щели, а gcloud (страмота!) — на пихоне с бото3…
Слабо [им] оказалось?
n.b. слава богам, что у автора в подписи не devops…
непонятно, как такая проблема вообще может возникать (что совершенно не значит, что похожее не приходилось решать — но это было сознательное погружение в дебри).
Immutable Infrastructure.
EC2 instance — расходный материал: прибили, развернули terraform'ом, всё.
по желанию — накатили нужное "горячо любимым" ansible'ом.
А есть те, кто собирает болид из основных агрегатов разных производителей, и в последнее время они ничего не показывают, кроме как нижние строчки чемпионата.
неправда ваша: Force India, Haas.
сравнить с McLaren (самостроитель).
Какие бы не были «заоблачные» эти облачные технологии, которые помогают выигрывать в Формуле-1 всё, но плохой двигатель от Хонды…
болельщик McLaren detected ;)
Toro Rosso в аккурат за McLaren'ом.
несмотря на разницу в РАЗЫ в бюджетах.
Red Bull тоже будет с Honda — вот и посмотрим в следующем году.
P.S. всё, по факту, оказалось не так плохо с силовой установкой Хонда и не всё оказалось так хорошо, как ожидалось, с силовой установкой Рено в МакЛарен...
при этом обратите внимание, что пост — от инженера (не стажёра!) из компании, занимающейся информационной безопасностью… да, прав был Meteo в своё время об этой конторе...
он просто не столкнулся или поленился искать...
очевидно же, что ваш программерский взгляд, к сожалению, ограничился исключительно поделками шляпы (и тех, кого она продавила).
позволю себе озвучить мнение, что система старта FreeBSD божественна своей простотой и при этом гибкостью.
как и система портов + pkg, кстати.
да, да.
особенно приятно когда эти службы начинают просто драться между собой :)
извините, но это ваши линусячьи проблемы ;)
зато докер [через stdio] работает :)
каждому — своё...
тёплое с мягким не надо путать, пожалуйста — некоторые бекапы восстанавливаются полдня...
t2.nano, t3.nano — о чём-то говорит?
полёт нормальный.
ядро — не GENERIC (для себя ведь старался).
t3.micro — keycloak (openjdk8 под капотом).
А.
ну, и замена NAT Gateway (там где в нём есть необходимость) на t?.nano рулит по деньгам. разворачивается автомагически из Auto Scaling Group. где можно — на спотах.
P.S. по поводу community.
не представляю, куда бы я пошёл, направь e-mail не Colin Percival, а кому-нибудь a-la мьсе о-Торвальдс… то ли вопрос оказался для него плёвый, но с мёртвой точки в правильном направлении столкнул...
ну, авантюризм, в общем случае, присущ некоторому количеству человеков.
остаётся только пожелать удачи вам и вашим данным :)
а как без RAID данные будут в сохранности?
ню-ню, мсье Аптимизт..
не надо ля-ля ради красного словца: никогда за >20 лет моей памяти ядро не собиралось три часа.
сейчас на древнющем одноядерном ноуте (Samsung R60) ядро FreeBSD 12.0 штатным clang'ом собирается чуть меньше часа. и да — на zfs :)
и не снапшотами едиными… xfs — это вообще каменный век в купе с ext*, jfs, ntfs, hpfs… я вот на zfs ~10 лет храню данные своих серверов и рабочих станций (zfs volumes only). а вы btrfs так используетете?
вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.
по-моему, я предельно ясно выразился, что *BSD в более правильном направлении развивается потому, что там нет системды :)
а линух прикончит системда, когда оно "срастётся" с кёрнелом и гномом в [практически] монолит: отсутствие вариантов — плохо для системы.
и да, я знаю о слухах, что во FreeBSD тоже рассматривается вариант разработки launchd. но как это уже было неоднократно, резкого и безальтернативного перехода a-la linux (а теперь — капец), полагаю, не будет: хочется верить, что мудрости у дядек из беркли больше, чем у горячего финского студента...
*BSD идёт более правильным путём, чем *Linux хотя бы потому, что не превращает OS в kernel+systemd...
Весьма субъективно, с Вашей стороны [что лучше]…
И непоследовательно: голанг нонче пихают во все щели, а gcloud (страмота!) — на пихоне с бото3…
Слабо [им] оказалось?
n.b. слава богам, что у автора в подписи не devops…
непонятно, как такая проблема вообще может возникать (что совершенно не значит, что похожее не приходилось решать — но это было сознательное погружение в дебри).
Immutable Infrastructure.
EC2 instance — расходный материал: прибили, развернули terraform'ом, всё.
по желанию — накатили нужное "горячо любимым" ansible'ом.
стильно/модно/молодёжно — vnc консоль…
по COM-порту что трудно было сделать?
ан нет: вывод в COM-порт дают, ввод — балалайка...
Не знаю, а чего вы [с амазоном] решили, что user-data будет исполняться НЕ первый бут?
неправда ваша: Force India, Haas.
сравнить с McLaren (самостроитель).
болельщик McLaren detected ;)
Toro Rosso в аккурат за McLaren'ом.
несмотря на разницу в РАЗЫ в бюджетах.
Red Bull тоже будет с Honda — вот и посмотрим в следующем году.
P.S. всё, по факту, оказалось не так плохо с силовой установкой Хонда и не всё оказалось так хорошо, как ожидалось, с силовой установкой Рено в МакЛарен...
поверю, когда с таким подходом будете эксплуатировать свой кардио-стимулятор.
а до тех пор — это КОЛХОЗ.
doctor'а обидеть может каждый… :)
при этом обратите внимание, что пост — от инженера (не стажёра!) из компании, занимающейся информационной безопасностью… да, прав был Meteo в своё время об этой конторе...
… с кучей питонячего го#@ища кол-вом ~72 единицы и необходимостью наличия питона на сервере. даже не знаю: плакать или смеяться от такого "vpn"....