Проект openSUSE опубликовал релиз атомарно обновляемого дистрибутива openSUSE Leap Micro 6.1, предназначенного для создания микросервисов и для использования в качестве базовой системы для платформ виртуализации и контейнерной изоляции. Для загрузки доступны установочные сборки для архитектур x86_64 и ARM64 (Aarch64), а также готовые системные образы для систем виртуализации...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62359
Размеры совсем не микро. Даже в 700 Мб не влазит.
Да уж, настоящие алхимики ассемблерного кода умудряются впихнуть на дискету целую полнофункциональную ос с кучей приложений
И все конечно нею пользуются
Они уже браузер кстати написали?
в настройках добавили галку "использовать джаваскрипт"
джаваскрипта нет
какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в себе, за гранью юзабилити.
> какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при
> помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в
> себе, за гранью юзабилити.Не знаю как у сусёвых, пробовал атомарщину от федорки и никсось, никсось субективно быстрее и меньше занимает после чистки мусора.
Но это так, наблюдение, боже упаси не топлю за никсось с её необходимостью чистать талмуды текста и искать порой альтернативные решения на фоне с беглым ознакомлением с федоркиной атомарщиной! Сам хочу попробовать что-то сусёвое, но руки не доходят, ленивый стал.
> но руки не доходят, ленивый стал.а я пойду самым простым путем. попробую вручную root на BTRFS сделать. "снапшоты для бедных, как в ZFS". если ФС похожие, то должно получиться.
>Добавлена возможность включения сжатия раздела подкачки при помощи модуля zRAM, размещающего сжатое блочное устройство в ОЗУ.вот это даа, осилили man zramctl прочитать?
есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное поделие
> есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное
> поделиеЕсли оно позволяет относительно экономно без пердолинга запускать инстансы с GUI-софтом, то почему нет-то?
А если не позволяет, то тогда я не понимаю зачем оно нужно, ещё один велосипедный огород из-за NIH-синдрома?
Объясните, плиз, в чем суть микросервисов? Я помню в середине десятых годов был прям жуткий хайп по ним, на том же хабре статьи сотнями на эту тему писали
Клиент сервер это мне понятно, а микросервисы что такое? Это чем то отличается от традиционного подхода? Откуда такая популярность, интересно просто
Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много маленьких программ, каждая из которых делает одну задачу, но делает её хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая идея, существующая с 1970 года, была открытием.По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели юниксвей, только вместо IPC через пайпы или sunrpc у них теперь IPC через HTTP.
Как бэ, есть разница.
Юниксвейная утилита написана раз и работает, обновляясь раз несколько месяцев, а то и лет.
Микросервис пишется второпях, выкатывается в продакшон срочно-обморочно, с перспективой переписывания и редеплоя через неделю. Соответственно, фишка микросервисов с точки зрения бизнеса - возможность поправить что-то, не рискуя обрушить всю систему.
Иными словами, юниксвейные утилиты и микросервисы - это как байкеры в кожаных косухах на харлеях и байкеры в красных черепашках на ямахах.
> Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много
> маленьких программ, каждая из которых делает одну задачу, но делает её
> хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая
> идея, существующая с 1970 года, была открытием.
> По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели
> юниксвей, только вместо IPC через пайпы или sunrpc у них теперь
> IPC через HTTP.Умпутун из Radio-t вроде как не из этих, но микросервисы использует.
Разрешаю вам пить фруктовый молочный коктейль когда вам захочется :).Нет же ничего плохого в микросервисах. Главное, чтобы дизайн был ортогональным и взаимодействие между компонентами как-нибудь разумно сделано.
это когда вот ту самую серверную часть приложения разбирают на несколько приложений и все это крутится в бекенде взаимодействуя между собой по необходимости (HTTP, gRPC и тд)смысла в этом особо нет, но "одаренным" это позволяет хоть что-то разнести по серверам, сделав систему распределенной (потому что по-другому не умеют или никогда не делали), хапнув проблем, о которых они изначально и не подозревали, но это будет сильно позже, когда проект пропишется в проде значительно
у такой архитекутуры есть реально пару стоящих кейсов, когда это может быть понадобиться, но большинство разрабатываемых приложений сделаны как раз по принципу micro-services for the sake of micro-services
по-хорошему тебе нужны микросервисы только тогда, когда тебе нужно изолировать часть твоего приложения и масштабировать ее отдельно, вот прям вынужден это делать по тем или иным причинам, во всех остальных случаях это в лучшем случае самообман, и микросервисы нахрен не нужны
Systemctl микросервис менеджер над сустемд д нужен , а мир отрицающих чужие наработки обезличенные и не инвестируемые из за мира обезьян и даунов захвативших власть над чужими транзакциями не нужен пока не станут человеками , накоа им вообще дали нфс оборудование пусть бы типографировали себе бумагу , аналоговым механическим методом.
Про то что микросервисы дают изоляцию, гибкость разработки, тестирования. Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь. Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь. В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
> Про то что микросервисы дают изоляцию, гибкость разработки, тестирования.изоляцию - да
гибкость разработки - нет
гибкость тестирования - нет> Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь.
прямое следствие изоляции, но нужная ли эта фрагментация? должна быть веская причина так делать (о чем я и говорил), а не просто микросервисы ради микросервисов (о чем я тоже говорил)
> Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь.
о сразу видно все знающего индюка с зашкаливающим ЧСВ, без коментариев ))
> В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
абсолютно нет, это всего лишь означает, что несколько калек не смогли организовать процесс разработки
с каких это пор архитектура определяется структурой команд, а не наоборот? при таком подходе у тебя будет нагажено, что в монолитной системе, что в микросервисах, где бы там ни было...
более того качество интеграции отдельных модулей у тебя определяется степенью слаженности команды, а мы уже поняли, что в этом вопросе уровень - дно
и никто не мешает делать приложение модульным, но без микросервисов
О да в твоём мире все упирается в компетенцию каких то Васянов, которых ты не знаешь. Они уйдут и всё развалится. Или даже просто постареет или заболеет. Слаженность команды ещё больший бред и что кто-то сверху её должен контролировать. Человек в среднем работает у тебя 2 года. Какая слаженность, какие калеки. Новый человек придет и сразу должен приступить к работе, а не разбираться в баш лапшах и прочей архитектуре. И выслушивать всяких токсиков типа тебя про такая у них компетенция.
ты ничего не понял из написанного, спрыгнул от архитектуры к процессу разработки, описывая своей унылый кейс и текучку ресурсов на вашем проектеа ты кстати не думал, что отчасти эта текучка из-за состояния проекта, потому что он представляет из себя кусок субстанции? у вас смердит дилентанством во всем, вот и не задерживаются, и ни с чем не разбираются
ты пишешь про каких-то васянов, компетенции, я не понимаю этот бред, какое отношение это имеет ко мне?
а то что для работы микросервисов необходимо согласовывать версии API, данные, инфракструктуру тебя не смущает? притом у тебя нет ничего из раннего связывания, ни типов, ни проверок во время компиляции, ни сквозного тестирования, все что у тебя есть, твое согласование полностью зависит от эффективности взаимодействия команд, где текучка 50% в год, и само это взаимодействие ущербное с твоих же словт.е. то от чего зависят микросервисы в твоем случае самое проблемное место, фактически у тебя не микросервисы, а просто наколенные поделия, код которых тебе кажется проще сопровождать потому что они в разных кодовых базах, когда очередную наколенку можно изолировать в виде микросервиса...
по сути своей это проект костылей, а не микросервисов
Не знаю. Раньше было все то же самое: большое приложение, его серверная часть, делилась на несколько отдельных процессов, которые держали связь между собой либо по сокету, либо по какому-нибудь именованносу пайпу, если так сильно хочется... И по сети всё это разносилось без проблем. Сейчас зачем-то решили все это обвязать кучей надстроек и изобрести новую профессию девопса. Или как оно там называется. Ну и, конечно, платить за это всяким амазонам. Так вижу
Да, а документация как эти процессы у вас взаимодействуют была? Я знаю что не было, а то что вы называли документацией это смех. Процесс взаимодействия должен быть стандартизован и воспроизводим, а не тут gprc, тут у нас баш скрипты, тут Вася помнит как работает и взаимодействует, только он в отпуске и выгорел. Выделить человека, который будет разбираться в этом цирке это вполне взвешенное решение. Ну или даже так если этот человек не в состоянии разобраться что весь этот цирк наворотил переписывайте чтобы было понятно. Так ясно?
Микросервисы это и есть традиционный подход уже давно.
> Объясните, плиз, в чем суть микросервисов?зарабатывать деньги на лошках. нормальные люди как писали unix-way-ные демоны, так и пишут
> Объясните, плиз, в чем суть микросервисов?Если совсем коротко, то когда пишется сложная система, в которой есть больше пяти взаимодействующих друг с другом блоков, то к этому всему нужна некая управлялка этими блоками, запуск, логи, распределение памяти и прочих ресурсов.
Микросервисы несут идею, что эту управлялку некты напейсали до тебя, и можно ея взять и пользоваться, ну там в конфигах девопсы поиграют и всё отлично будет.
Проблема в том, что блоки в системе практически всегда друг с другом бизнес-логически связаны и, условно, если один блок упал, то и вся система тоже упала, а не просто какой-то кубер в докере передёрнул какой-то сервис и пляши дальше.
Несомненно, есть какая-то часть задач, которые можно решить микросервисным подходом. Но их немного.
while [ true ]; do ./a | ./b | ./c > log ; doneдарю бесплатно перезапуск, модульность и логи
Но только на одной машине.Можно, конечно,
while [[ true ]]; do ./a | ssh user@server:~/b | ./c > log ; done
но тоже, ну так... стартовать процесс на каждого клиента плохо.