Ivan
Дык мы же издательство спонсировали
Александр
на инглише где-то было, хз, искать надо
Lex
Александр
Только это, не помню она там полная или нет
Александр
я то сначала в инете качал, а там ознакомительная была, а потом купил
Lex
ну Я бы тоже купил в оригинале
Lex
но на амазоне оно конских денег стоит
Magistr
её емнип бесплатно выложил гугл
Ivan
Ты путаешь с SRE
Ivan
Ее гугл бесплатно выложил
Ivan
А это же не гугловая книга
Lex
её емнип бесплатно выложил гугл
https://play.google.com/store/books/details/Gene_Kim_The_Phoenix_Project?id=_An-CAAAQBAJ&hl=en
Magistr
а да точно
Ivan
Да ладно, 541 рубль кому-то жалко за книгу?
Ivan
В ней же квинтэссенция человеческой мудрости по поводу DevOps
Ivan
Жизнь делится на два этапа - до прочтения "Проекта Феникс" и после, когда уже ничего не будет таким, как раньше, и нельзя будет вернуться назад.
Александр
Имхо феникс нужно читать в 2 захода
Александр
через 3-5 месяцев перерыва
Александр
Становятся понятны свои косяки после начала изучения девопса
Lex
но хотет drm free
Lex
уже нашел
Lex
http://shop.oreilly.com/product/9780988262508.do
Oleksandr
Жизнь делится на два этапа - до прочтения "Проекта Феникс" и после, когда уже ничего не будет таким, как раньше, и нельзя будет вернуться назад.
это ты так шутишь или действительно стоит почитать? всё руки не дойдут
Александр
это ты так шутишь или действительно стоит почитать? всё руки не дойдут
Хорошая книга, показывает что нужны методологии
Александр
не именно девопс, а вообще
Александр
тот же itil
Oleksandr
ну отзывы самые ок
про SRE гугловый тоже норм отзывы были, но по факту куча воды ни о чём, как мне показалось )
Lex
про SRE гугловый тоже норм отзывы были, но по факту куча воды ни о чём, как мне показалось )
кому-то вода ниочем а кому-то откровение
Magistr
про SRE гугловый тоже норм отзывы были, но по факту куча воды ни о чём, как мне показалось )
SRE как справочник имхо читать надо
Александр
Ну Феникс больше как повесть, а не руководство к действию
Lex
Ну Феникс больше как повесть, а не руководство к действию
A Novel about IT, DevOps, and Helping Your Business Win
Lex
внезапно
Александр
Ну, я имел ввиду, что там нет готовых решений
Lex
Ну, я имел ввиду, что там нет готовых решений
ну да, она больше про культуру, подходы и комуникации
Pavel
имя процесса в линуксе это фундаментальная штуковина или нет?
Pavel
Думаю организовать что-то типа широковещательного IPC через изменение имени процесса
Magistr
Думаю организовать что-то типа широковещательного IPC через изменение имени процесса
oh god why, а зачем ?
Pavel
Это проще чем пайпы открывать друг другу
Pavel
Один процесс имеет состояния (работаю, жду), а другой процесс должен видеть в каком состоянии находится первый.
Pavel
Ну точнее там может быть дерево процессов и один контролирующий. Что может быть проще чем в названии эту инфу отображать? :)
Magistr
Pavel
Что зачем? другому процессу видеть?
Pavel
Он рисует дашборды для админов с этой инфой
Dmitrii
Сделай через очереди че как лох та
Pavel
Очереди для лохов
Magistr
Он рисует дашборды для админов с этой инфой
т.е дашбоард со списком процессов и их состоянием ?
Pavel
да типа того. Да это неважно на самом деле, как пример.
Pavel
Главное что один процесс должен уметь считывать кастомную информацию о других процессах.
Magistr
а другие могут генерировать эту информацию ? например в виде метрик ?
Pavel
Все сторонние системы недопустимы. Только хардкор и примитивные инструменты unix-ядра
Pavel
вот еще смотрю на named pipe как неплохой вариант.
Magistr
можно писать логи
Pavel
хм ну да
Pavel
Но тогда придется озаботиться с их ротатингом
Magistr
логротейт стандартен
Pavel
Что бы ни делать, лишь бы через название процесса не общаться ;)
Dmitrii
Паша, астанавись
Denis
Что бы ни делать, лишь бы через название процесса не общаться ;)
сделай мастера которы плодит детей и называет их по своему каждого
Denis
можешь ещё в сomm сходить и руками ёбнуть туда что нибудь
Denis
но это для слвсем повернутых и я хз будет ли это всегда работать и вобще будет ли работать
Pavel
Вот и мне интересно
Denis
но если серьёзно, я вобще редко плохо отзываюсь о идеях людей, но вот твоя идея ужасно дерьмовая.
Denis
почему нельзя ipc сделать на тех же сигналах
Denis
или через шаредмем
Pavel
Сигналы потому что не могут посылать доп. метадату, а с шаред мем будут вопросы с конкурентностью
Pavel
В общем остается только именованые пайпы. Или неименованые.
Denis
вопрос с конкуретностью решается семафорами
Denis
ебать, а ты в имени процесса джейсон держать будешь ? )
Denis
это достойно 2017го но боюсь деды встанут из могил когда ты напишешь это
Pavel
Про json отличная идея, но я хотел только 1 лексему держать
Pavel
А так можно имя процесса использовать в качестве маленькой БД, вот это поворот
Pavel
Следующий шаг после nosql
Vladislav
Главное что один процесс должен уметь считывать кастомную информацию о других процессах.
чем unix sockets не ок?
Vladislav
в n-1 раз меньше получится, чем пайпов
Vladislav
в comm можно напихать все, что угодно, при желании. список процессов будет прекрасен, а кое-что в юзерспецсе будет крэшиться от json-а в имени
Pavel
изверги вы доводите мои идеи до абсурда