| |
| 2.16, Аноним (16), 02:38, 07/12/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да уж, настоящие алхимики ассемблерного кода умудряются впихнуть на дискету целую полнофункциональную ос с кучей приложений
| | |
| |
| |
| 4.40, Аноним (40), 23:31, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
в настройках добавили галку "использовать джаваскрипт"
джаваскрипта нет
| | |
|
|
| 2.36, crypt (ok), 18:31, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в себе, за гранью юзабилити.
| | |
| |
| 3.44, Аноним (44), 11:30, 12/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
> какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при
> помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в
> себе, за гранью юзабилити.
Не знаю как у сусёвых, пробовал атомарщину от федорки и никсось, никсось субективно быстрее и меньше занимает после чистки мусора.
Но это так, наблюдение, боже упаси не топлю за никсось с её необходимостью чистать талмуды текста и искать порой альтернативные решения на фоне с беглым ознакомлением с федоркиной атомарщиной! Сам хочу попробовать что-то сусёвое, но руки не доходят, ленивый стал.
| | |
| |
| 4.46, crypt (ok), 12:41, 12/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> но руки не доходят, ленивый стал.
а я пойду самым простым путем. попробую вручную root на BTRFS сделать. "снапшоты для бедных, как в ZFS". если ФС похожие, то должно получиться.
| | |
|
|
|
| 1.9, Аноним (9), 22:48, 06/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Добавлена возможность включения сжатия раздела подкачки при помощи модуля zRAM, размещающего сжатое блочное устройство в ОЗУ.
вот это даа, осилили man zramctl прочитать?
| | |
| 1.10, chdlb (?), 23:28, 06/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное поделие
| | |
| |
| 2.45, Аноним (44), 11:34, 12/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
> есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное
> поделие
Если оно позволяет относительно экономно без пердолинга запускать инстансы с GUI-софтом, то почему нет-то?
А если не позволяет, то тогда я не понимаю зачем оно нужно, ещё один велосипедный огород из-за NIH-синдрома?
| | |
|
| 1.17, Аноним (16), 02:43, 07/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните, плиз, в чем суть микросервисов? Я помню в середине десятых годов был прям жуткий хайп по ним, на том же хабре статьи сотнями на эту тему писали
Клиент сервер это мне понятно, а микросервисы что такое? Это чем то отличается от традиционного подхода? Откуда такая популярность, интересно просто
| | |
| |
| 2.19, Аноним (19), 04:13, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много маленьких программ, каждая из которых делает одну задачу, но делает её хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая идея, существующая с 1970 года, была открытием.
По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели юниксвей, только вместо IPC через пайпы или sunrpc у них теперь IPC через HTTP.
| | |
| |
| 3.31, YetAnotherOnanym (ok), 13:22, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Как бэ, есть разница.
Юниксвейная утилита написана раз и работает, обновляясь раз несколько месяцев, а то и лет.
Микросервис пишется второпях, выкатывается в продакшон срочно-обморочно, с перспективой переписывания и редеплоя через неделю. Соответственно, фишка микросервисов с точки зрения бизнеса - возможность поправить что-то, не рискуя обрушить всю систему.
Иными словами, юниксвейные утилиты и микросервисы - это как байкеры в кожаных косухах на харлеях и байкеры в красных черепашках на ямахах.
| | |
| 3.39, Анон1110м (?), 20:16, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много
> маленьких программ, каждая из которых делает одну задачу, но делает её
> хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая
> идея, существующая с 1970 года, была открытием.
> По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели
> юниксвей, только вместо IPC через пайпы или sunrpc у них теперь
> IPC через HTTP.
Умпутун из Radio-t вроде как не из этих, но микросервисы использует.
| | |
| |
| 4.41, Аноним (19), 04:38, 08/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Разрешаю вам пить фруктовый молочный коктейль когда вам захочется :).
Нет же ничего плохого в микросервисах. Главное, чтобы дизайн был ортогональным и взаимодействие между компонентами как-нибудь разумно сделано.
| | |
|
|
| 2.21, chdlb (?), 04:39, 07/12/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
это когда вот ту самую серверную часть приложения разбирают на несколько приложений и все это крутится в бекенде взаимодействуя между собой по необходимости (HTTP, gRPC и тд)
смысла в этом особо нет, но "одаренным" это позволяет хоть что-то разнести по серверам, сделав систему распределенной (потому что по-другому не умеют или никогда не делали), хапнув проблем, о которых они изначально и не подозревали, но это будет сильно позже, когда проект пропишется в проде значительно
у такой архитекутуры есть реально пару стоящих кейсов, когда это может быть понадобиться, но большинство разрабатываемых приложений сделаны как раз по принципу micro-services for the sake of micro-services
по-хорошему тебе нужны микросервисы только тогда, когда тебе нужно изолировать часть твоего приложения и масштабировать ее отдельно, вот прям вынужден это делать по тем или иным причинам, во всех остальных случаях это в лучшем случае самообман, и микросервисы нахрен не нужны
| | |
| |
| 3.22, Mir_daynov (?), 07:11, 07/12/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Systemctl микросервис менеджер над сустемд д нужен , а мир отрицающих чужие наработки обезличенные и не инвестируемые из за мира обезьян и даунов захвативших власть над чужими транзакциями не нужен пока не станут человеками , накоа им вообще дали нфс оборудование пусть бы типографировали себе бумагу , аналоговым механическим методом.
| | |
| 3.24, Аноним (35), 09:19, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Про то что микросервисы дают изоляцию, гибкость разработки, тестирования. Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь. Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь. В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
| | |
| |
| 4.25, chdlb (?), 10:27, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Про то что микросервисы дают изоляцию, гибкость разработки, тестирования.
изоляцию - да
гибкость разработки - нет
гибкость тестирования - нет
> Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь.
прямое следствие изоляции, но нужная ли эта фрагментация? должна быть веская причина так делать (о чем я и говорил), а не просто микросервисы ради микросервисов (о чем я тоже говорил)
> Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь.
о сразу видно все знающего индюка с зашкаливающим ЧСВ, без коментариев ))
> В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
абсолютно нет, это всего лишь означает, что несколько калек не смогли организовать процесс разработки
с каких это пор архитектура определяется структурой команд, а не наоборот? при таком подходе у тебя будет нагажено, что в монолитной системе, что в микросервисах, где бы там ни было...
более того качество интеграции отдельных модулей у тебя определяется степенью слаженности команды, а мы уже поняли, что в этом вопросе уровень - дно
и никто не мешает делать приложение модульным, но без микросервисов
| | |
| |
| 5.28, Аноним (35), 10:52, 07/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
О да в твоём мире все упирается в компетенцию каких то Васянов, которых ты не знаешь. Они уйдут и всё развалится. Или даже просто постареет или заболеет. Слаженность команды ещё больший бред и что кто-то сверху её должен контролировать. Человек в среднем работает у тебя 2 года. Какая слаженность, какие калеки. Новый человек придет и сразу должен приступить к работе, а не разбираться в баш лапшах и прочей архитектуре. И выслушивать всяких токсиков типа тебя про такая у них компетенция.
| | |
| |
| 6.32, chdlb (?), 14:09, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
ты ничего не понял из написанного, спрыгнул от архитектуры к процессу разработки, описывая своей унылый кейс и текучку ресурсов на вашем проекте
а ты кстати не думал, что отчасти эта текучка из-за состояния проекта, потому что он представляет из себя кусок субстанции? у вас смердит дилентанством во всем, вот и не задерживаются, и ни с чем не разбираются
ты пишешь про каких-то васянов, компетенции, я не понимаю этот бред, какое отношение это имеет ко мне?
а то что для работы микросервисов необходимо согласовывать версии API, данные, инфракструктуру тебя не смущает? притом у тебя нет ничего из раннего связывания, ни типов, ни проверок во время компиляции, ни сквозного тестирования, все что у тебя есть, твое согласование полностью зависит от эффективности взаимодействия команд, где текучка 50% в год, и само это взаимодействие ущербное с твоих же слов
т.е. то от чего зависят микросервисы в твоем случае самое проблемное место, фактически у тебя не микросервисы, а просто наколенные поделия, код которых тебе кажется проще сопровождать потому что они в разных кодовых базах, когда очередную наколенку можно изолировать в виде микросервиса...
по сути своей это проект костылей, а не микросервисов
| | |
|
|
| 4.27, verh010m (ok), 10:37, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Не знаю. Раньше было все то же самое: большое приложение, его серверная часть, делилась на несколько отдельных процессов, которые держали связь между собой либо по сокету, либо по какому-нибудь именованносу пайпу, если так сильно хочется... И по сети всё это разносилось без проблем. Сейчас зачем-то решили все это обвязать кучей надстроек и изобрести новую профессию девопса. Или как оно там называется. Ну и, конечно, платить за это всяким амазонам. Так вижу
| | |
| |
| 5.29, Аноним (35), 10:57, 07/12/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да, а документация как эти процессы у вас взаимодействуют была? Я знаю что не было, а то что вы называли документацией это смех. Процесс взаимодействия должен быть стандартизован и воспроизводим, а не тут gprc, тут у нас баш скрипты, тут Вася помнит как работает и взаимодействует, только он в отпуске и выгорел. Выделить человека, который будет разбираться в этом цирке это вполне взвешенное решение. Ну или даже так если этот человек не в состоянии разобраться что весь этот цирк наворотил переписывайте чтобы было понятно. Так ясно?
| | |
|
|
|
| 2.33, Аноним (33), 14:15, 07/12/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Объясните, плиз, в чем суть микросервисов?
зарабатывать деньги на лошках. нормальные люди как писали unix-way-ные демоны, так и пишут
| | |
| 2.37, beck (??), 18:58, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Объясните, плиз, в чем суть микросервисов?
Если совсем коротко, то когда пишется сложная система, в которой есть больше пяти взаимодействующих друг с другом блоков, то к этому всему нужна некая управлялка этими блоками, запуск, логи, распределение памяти и прочих ресурсов.
Микросервисы несут идею, что эту управлялку некты напейсали до тебя, и можно ея взять и пользоваться, ну там в конфигах девопсы поиграют и всё отлично будет.
Проблема в том, что блоки в системе практически всегда друг с другом бизнес-логически связаны и, условно, если один блок упал, то и вся система тоже упала, а не просто какой-то кубер в докере передёрнул какой-то сервис и пляши дальше.
Несомненно, есть какая-то часть задач, которые можно решить микросервисным подходом. Но их немного.
| | |
| |
| 3.38, Аноним (33), 19:04, 07/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
while [ true ]; do ./a | ./b | ./c > log ; done
дарю бесплатно перезапуск, модульность и логи
| | |
| |
| 4.42, Аноним (19), 05:03, 08/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Но только на одной машине.
Можно, конечно,
while [[ true ]]; do ./a | ssh user@server:~/b | ./c > log ; done
но тоже, ну так... стартовать процесс на каждого клиента плохо.
| | |
|
|
|
|
