1-2-3 Techno це ТОП! Підрубрика це ТОП в ТОПі! Коли слухаю ці подкасти, то ніби сиджу з другом за кавою і ми теревенимо про круті історії з життя та роботи 👍
Шкода що не зʼясували до кінця, в чому саме була проблема. Проте дякую за розповідь. Початок війни й таке - дуже високий стрес. А під час стресу приймати зважені рішення значно складніше. Ви мололець.
Побачив Олександра і Передивився то шедевральний відео з fwdays 2013 року. Цікавий момент, ще тоді Олександр сказав що не любить лапшинова бо той прихильник путіна (40+ хвилина). І за це респект :) Фейл гітлаба - це прям вже історія. Ще б розказав як ключі ссш від доу віддавали бо в країні було зле…. Дякую! Крутий контент! Продовжуйте
36:12 не згоден в ведучим, а навпаки з гостем. довгі транзації це гемор в будьякій скбд, особливо важко в locker (не mvcc як postgresql), але якщо це жива людина що випадково забула закомітити, це завжди така проблема. в принципі в pci-dss для живих людей є вимога щоб строк сесій живих людей які нічого не роблять обмежувати в часі до 15 хвилин. але не всі скбд це вміють, можна зовнішніми скриптами-ватчдогами що ходять перевіряють-кіляють, але це з'являється після того як знайшли причину - незрозумілу помилку, що залишає за собою сесії з відкритими транзакціями, або просто нормальні але довгі і термнійнути їх це прям зараз необхідний подорожник. але для постгреса я використовую patroni (primary-secondary реплікація), і для такого сетапу має сенс прокся яка буде перекидувати конекти на примарі-ноду. я використовую хапроксі, і там є дефолтне налаштування скільки tcp-сессія буде жити якщо по ній не бігають дані, timeout server, timeout client, наприклад 30хв, для oltp це достатньо. щодо обмеження взагалі до бд з "персональних ноутбуків", це вже не про те, це про безпосередньо інформаційну безпеку.
11:25 коли кажуть маленькі сервачки це про джаву та її модель heap, якщо heap меньше 32 гб, то можливо використовувати compressed-покажчики, і це може суттєво зекономити пам'яті. А щойно зробити більше 32гб памя'ті, то стає гірше,... Збільшуємо, і десь на рівні гігабайт 45-50, виходить на рівень 32 з компрессед опс. Але ж є зворотний бік, чим більше шкаф тім він гучніше падає
Може на це питання відповідь буде далі, але завжди цікаво як люди/компанії прийшли саме до такої моделі бізнесу - чому саме грантові агенства, а не умовні VC? Як відбувся перший контакт з таким агенством
Дуже гарне питання! В відео відповіді нема, хоча варто було б його обговорити. Про таку нішу майже неможливо дізнатись, якщо ти не в темі. А якщо ти розробник - то ти не темі 98-99% можливих B2B ніш. Як можна легко здогадатись, то початкова ідея бізнесу не моя. Мої два кофаундера - професори фізики (темна матерія, CERN, оце все), пишуть статті, отримують гранти, бувають panel member'ами в грантових агентствах, тощо. Перший контакт з таким агентством - на особистих зв'язках, якщо я правильно пам'ятаю, то на якійсь науковій конференції.
@@antonpopov3127 На роботі, лол. У мене немає якогось супер-перевіреного рецепту, як шукати кофаундерів у якихось цікавих нішах, нажаль. Вважаю, що нам просто пощастило. Але як завжди, щастить більш підготовленим людям, щоб був більший шанс такого "пощастило" - варто мати великий нетворк
не економте на девопсах і буде вам еластік працювати. для апдейт поля використовуте скріпти. еластік не зберігає старі документа (може тримати деяке сміття на видалення щоб потім підчистити автоматично).
Прям зараз в одному з індексів: docs: 165,437,198 (617,527,759). 165 * 3 (бо три копії) = 495 мільйонів. Ще 120 мільйонів - це "деяке сміття"? Скрипт для апдейта одного поля допомогає так само. Так, можна не слати весь документ. Ні, це не допомагає, і еластік буде реіндексувати весь документ, це і в документації написано.
@@VsevolodSolovyov elasticsearch- partial update. по кількості документів якщо _cluster/stats не збігається з потріьбним тотало документів = delayed refresh, deleted documents, shard allocation or index errors. в нас в еластіку 5 млрд документів. ми б давно б вилетіли при такі поведінці.
@@VsevolodSolovyov сколько м записей не решает. решает оптимизация запроса, уменьшение внутреннего паразитного трафика, и качественное шардирование. но вот так спорить это как на свечку пукать. если есть трабла выложи архитектуру с конфигами, типовые запросы и прочее и тогда можно будет предметно обсудить. без этого это "у меня них не работает", "а на мое компе все работает". но вот с хецнера однозначно рекомендую сваливать и делать бекапы вне хецнера хоть на локалку(я так когда то спас всю компанию)
Проблема была в том что это хецнер на котором стабильно проебы с железом. У нас как то в один день ушел весь архивный кластер из 6 распределенных машин. Оцените вероятность такого чудесного события. а то что пропадал коннект тоже стандартная тема их глючных свитчей. Даже если в стойке одной будут стоять есть не малые риски все просрать. Там хоть и дешего, но общий урон от такого гавностроя и оплата людей для его фикса не стоит всего этого. Посему хецнер больше никогда ни для чего не юзаю. Лучше переплатит парк баксов чем схватить инфаркт в 30 лет. А эластик серч хоть и не самая стабильная тема иза Явы, но все же вполне ок решение и может обрабатывать терабайты инфы при правельной настройке как софта так и железа.
Немного не понятно раскрыты проблемы эластика. 1. Название подкаста - Эластик не надежная скотина. Насколько я понял из разговора, когда поменяли машины на другие с ECC памятью, все стало работать норм. Так может это не Эластик скотина а старые инстансы?) По ECC памяти, насколько я вычитал, ещё в 2013 у aws все было на ECC так как это необходимость. Никогда не работал с Hetzner, но это немного удивило. 2. По поводу пересоздания индекса. Эластик не транзакционная база, она не может быть source of truth. Возможность пересоздания индекса без даунтайма это там must have по моему) Скорость создания индекса часто можно оптимизировать - сделать меньше шарды, поиграться с parallelism/batch size и тд. По другому писать индексы чтоб вместо одного индекса на терабайт было несколько по годам или авторам. 3. Как это удалить весь шард? Сколько было реплик шарда, все реплики погибли что-ли которые были на разных инстансах?) Было ли настроено snapshot lifecycle policy? 4. Segments merging logic довольно неплохо работает. Оно старается держать количество marked as deleted документов до 30% и периодически их чистит полностью. Падение производительности я замечал когда полностью перезаписываем 100% документов в эластике. В этой ситуации конечно раз в неделю пересоздаем индекс заново. Все это без даунтайма, просто переключаем алиас на новый индекс. Этот индекс специально разделён на два (hot и cold) и пересоздание занимает 30 мин. 5. По добавлению инстансов в кластер. Всегда можно сделать blue-green деплой и просто покопировать шарды в новый кластер) Так может даже правильнее с прод релизом где постоянно большая нагрузка. 6. Честно говоря, так и не понятно почему переезжают на Vespa. Всеволод сказал что последние 2 года все работает норм на эластике. Александр сказал что пока не делал полноценные прод тесты с Vespa. Отсутствие шардов в Vespa это ж может быть и минус. Если например в индексе эластика 2 миллиарда документов и 20 шардов, там можно заюзать роутинг который пойдёт в конкретный шард и не будет искать среди 2 миллиардов доков. Я про Vespa ниче не знаю, но интересно как это реализовано там) Было бы очень интересно послушать про ваши прод use cases где Vespa работает лучше. Время поиска для разных типов кверей, cpu/memory utilization дата нод, время индексирования, падение производительности при увеличении updated documents. Не у конечно для полноты картины, было б цікаво добавить деталей про текущий эластик - размер индексов, количество шардов и документов и тд) Так было бы больше понятно почему эластик все-таки скотина)
1. Назву для випуску вибирають продюсери, нічого сказати не можу. У Хецнера серваки є з ECC, є без, як бажаєш. Це bare metal, в їхньому клауді все ECC. 2. Це ж не логи, мені індекси по рокам не допоможуть. Більшість запитів на пошук йде без обмеження на роки, а якщо вони і є - то це типу "останні 10-15 років". Наскільки зручно працювати, коли треба один запит слати в кілька індексів, і потім об'єднувати результати? Це точно не той шлях, який я буду розглядати першим, другим чи п'ятим. По авторам це просто неможливо зробити, у наукової статті не один автор. Можуть бути і сотні, і тисячі. 3. Якщо чесно, я не пам'ятаю точно, який саме API виклик тоді допоміг. Я зараз полистав їх API хвилин п'ятнадцать, і можливо це був неочікуваний результат викликів cluster reroute. Три копії даних. Поки листав доки, згадав, що деякі репліки шардів випадали в UNASSIGNED, і можливо це була комбінація випадіння в unassigned і того, що одна з "живих" копій згнила. Супер-детального постмортему з усіма деталями на початку війни не робив, вибачайте. Lifecycle policy не було. 4. Так, звісно, перестворення нового індексу це переключення аліасу без даунтайму. Для основного індексу я навіть з БД всі свої дані не витягну за півгодини, вже не кажучи про те, щоб будь-який індекс встиг за цей час побудуватись, заздрю вашим півгодинам. 6. Взагалі не планував нічого про Веспу казати, тут ніяких веселих історій немає. Переїжджаємо по причинам, які не пов'язані з надійністю чи операційною складністю еластіка. У веспи дуже класна підтримка векторних полів, запитів, комбінація цього зі звичайним full-text пошуком, фільтрами, тощо. Це важливо для мого продукту, дозволяє зручно зробити те, що іншими способами незручно, дає калічні результати, або дуже довго працює. У восьмому еластіку теж з'явилась базова підтримка векторів, але порівняно з веспою воно прям базове. Всі інші речі - приємні бонуси. Про роутинг, який не буде ходити в інші шарди - як я вже сказав, це не мій випадок. 7. У мене є наполовину написаний пост про те, як ми переїжджаємо з еластіка на веспу, але не схоже, щоб я його дописав найближчим часом. Розмір основного індексу (статті) в еластіку десять терабайт, 165 мільйонів документів (з копіями та оверхедом видалених - 620 млн).
Коли CTO сам займається серверами, то це вирок Наймайте девопсів, читайте документацію та вмикайте моніторінг Про повреждение данные от неисправной сетевой карты это какой-то фейк Сетевая карта всегда одни и те же поля коверкала - ну это уже как байка Опять же, нужно мониторить сервера, нанимать девопсов То что верхний уровень начинает колбасить когда неисправен нижний это нормально. Это и есть сигнал к тому что что-то не так Судя по вашим рассказам вы что-то делаете с эластиком, а потом не понимаете почему и что происходит Т.е. вы не читаете документацию, логи, не делаете мониторинг Сделайте тег "1 апреля"
Ви десь почули, що я сам займаюсь серверами? Я навіть там кажу прямим текстом «не люблю це робити», в контексті того, що людина, яка займається серверами, на той момент була без звʼязку. Мережева карта не портила одні і ті самі поля, це теж ви додумали. Що відбувається з еластіком я зазвичай чудово розумію. Змоги розбиратись в причинах проблеми саме 24 лютого 2022 року в мене не було.
@@asolovyov Так а інфра ж не з одного LVM мабуть. І він міг там щось нахерячити в скопійованій. Короче, це нормально довіряти більше тому "бекапу", який автоматизований
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
А ви теж помітили, що у гостя та ведучого однакові прізвища?
Мабуть співпадіння.
Ідеальне співпадіння! Випуск - 🔥
енівей
Світ тісний:)
Я помітив однакові фамілії і довго очікував цей випуск
1-2-3 Techno це ТОП! Підрубрика це ТОП в ТОПі! Коли слухаю ці подкасти, то ніби сиджу з другом за кавою і ми теревенимо про круті історії з життя та роботи 👍
Такий самий вайб
Шкода що не зʼясували до кінця, в чому саме була проблема.
Проте дякую за розповідь.
Початок війни й таке - дуже високий стрес. А під час стресу приймати зважені рішення значно складніше. Ви мололець.
Дякую :)
Дякую за розмову! цікаво було б ще більше само про Data Science .
Завжди цікаво! Так тримати
третя історія в саме серденько. респект.
топова рубрика 🔥
дуже цікаво, дякую
Соловйови, запускайте власний подкаст. Дуже круто вийшло
"Солов'їною про IT"?
Побачив Олександра і Передивився то шедевральний відео з fwdays 2013 року.
Цікавий момент, ще тоді Олександр сказав що не любить лапшинова бо той прихильник путіна (40+ хвилина). І за це респект :)
Фейл гітлаба - це прям вже історія.
Ще б розказав як ключі ссш від доу віддавали бо в країні було зле….
Дякую!
Крутий контент!
Продовжуйте
Ключі ссх від доу? Шо за тема?
@@asolovyov в гуглі Что с главной страницей DOU?
56:36 доречі правда) треба перевірити s3 бекапи :-D
Як завжди кайфонув від всіх кулсторі. Хоч якась розпайка посеред всратійшого робочого циклу
36:12 не згоден в ведучим, а навпаки з гостем. довгі транзації це гемор в будьякій скбд, особливо важко в locker (не mvcc як postgresql), але якщо це жива людина що випадково забула закомітити, це завжди така проблема. в принципі в pci-dss для живих людей є вимога щоб строк сесій живих людей які нічого не роблять обмежувати в часі до 15 хвилин. але не всі скбд це вміють, можна зовнішніми скриптами-ватчдогами що ходять перевіряють-кіляють, але це з'являється після того як знайшли причину - незрозумілу помилку, що залишає за собою сесії з відкритими транзакціями, або просто нормальні але довгі і термнійнути їх це прям зараз необхідний подорожник.
але для постгреса я використовую patroni (primary-secondary реплікація), і для такого сетапу має сенс прокся яка буде перекидувати конекти на примарі-ноду. я використовую хапроксі, і там є дефолтне налаштування скільки tcp-сессія буде жити якщо по ній не бігають дані, timeout server, timeout client, наприклад 30хв, для oltp це достатньо.
щодо обмеження взагалі до бд з "персональних ноутбуків", це вже не про те, це про безпосередньо інформаційну безпеку.
Здається я навіть пам'ятаю той стрім Гітлаба😅
11:25 коли кажуть маленькі сервачки це про джаву та її модель heap, якщо heap меньше 32 гб, то можливо використовувати compressed-покажчики, і це може суттєво зекономити пам'яті. А щойно зробити більше 32гб памя'ті, то стає гірше,... Збільшуємо, і десь на рівні гігабайт 45-50, виходить на рівень 32 з компрессед опс.
Але ж є зворотний бік, чим більше шкаф тім він гучніше падає
Пробував гратися з цим.. різниця не така велика, може пару Гб.. принаймні на наших данних
Так, точно, це теж тоді в 2020-му був аргумент за сервачки поменше.
Може на це питання відповідь буде далі, але завжди цікаво як люди/компанії прийшли саме до такої моделі бізнесу - чому саме грантові агенства, а не умовні VC? Як відбувся перший контакт з таким агенством
Дуже гарне питання! В відео відповіді нема, хоча варто було б його обговорити. Про таку нішу майже неможливо дізнатись, якщо ти не в темі. А якщо ти розробник - то ти не темі 98-99% можливих B2B ніш. Як можна легко здогадатись, то початкова ідея бізнесу не моя. Мої два кофаундера - професори фізики (темна матерія, CERN, оце все), пишуть статті, отримують гранти, бувають panel member'ами в грантових агентствах, тощо.
Перший контакт з таким агентством - на особистих зв'язках, якщо я правильно пам'ятаю, то на якійсь науковій конференції.
@@VsevolodSolovyov А де ти познайомився з ко-фаундерами?
@@antonpopov3127 На роботі, лол. У мене немає якогось супер-перевіреного рецепту, як шукати кофаундерів у якихось цікавих нішах, нажаль. Вважаю, що нам просто пощастило. Але як завжди, щастить більш підготовленим людям, щоб був більший шанс такого "пощастило" - варто мати великий нетворк
подивіться на who's co-founder... І все зрозумієте
@@antonpopov3127 на роботі, за пару років до. У мене нема якогось перевіреного надійного підходу, де знаходити класних кофаундерів.
зайти з CLI і почати транзакцію (ручками, не скрипт )на прод бд ??? Це на якому році проекту це трапилось?
А контакти з приводу мілтек - до кого постучатись?
не економте на девопсах і буде вам еластік працювати. для апдейт поля використовуте скріпти. еластік не зберігає старі документа (може тримати деяке сміття на видалення щоб потім підчистити автоматично).
Прям зараз в одному з індексів: docs: 165,437,198 (617,527,759). 165 * 3 (бо три копії) = 495 мільйонів. Ще 120 мільйонів - це "деяке сміття"?
Скрипт для апдейта одного поля допомогає так само. Так, можна не слати весь документ. Ні, це не допомагає, і еластік буде реіндексувати весь документ, це і в документації написано.
@@VsevolodSolovyov elasticsearch- partial update. по кількості документів якщо _cluster/stats не збігається з потріьбним тотало документів = delayed refresh, deleted documents, shard allocation or index errors. в нас в еластіку 5 млрд документів. ми б давно б вилетіли при такі поведінці.
тут суть не в эластике а в системе и очень сильно в бажном железе
@@VsevolodSolovyov150м логов в день.
@@VsevolodSolovyov сколько м записей не решает. решает оптимизация запроса, уменьшение внутреннего паразитного трафика, и качественное шардирование.
но вот так спорить это как на свечку пукать. если есть трабла выложи архитектуру с конфигами, типовые запросы и прочее и тогда можно будет предметно обсудить. без этого это "у меня них не работает", "а на мое компе все работает".
но вот с хецнера однозначно рекомендую сваливать и делать бекапы вне хецнера хоть на локалку(я так когда то спас всю компанию)
Проблема была в том что это хецнер на котором стабильно проебы с железом. У нас как то в один день ушел весь архивный кластер из 6 распределенных машин. Оцените вероятность такого чудесного события.
а то что пропадал коннект тоже стандартная тема их глючных свитчей. Даже если в стойке одной будут стоять есть не малые риски все просрать.
Там хоть и дешего, но общий урон от такого гавностроя и оплата людей для его фикса не стоит всего этого. Посему хецнер больше никогда ни для чего не юзаю. Лучше переплатит парк баксов чем схватить инфаркт в 30 лет.
А эластик серч хоть и не самая стабильная тема иза Явы, но все же вполне ок решение и может обрабатывать терабайты инфы при правельной настройке как софта так и железа.
а як же ті адміни, що перевіряють що бекапи розгортаються?)
Немного не понятно раскрыты проблемы эластика.
1. Название подкаста - Эластик не надежная скотина. Насколько я понял из разговора, когда поменяли машины на другие с ECC памятью, все стало работать норм. Так может это не Эластик скотина а старые инстансы?) По ECC памяти, насколько я вычитал, ещё в 2013 у aws все было на ECC так как это необходимость. Никогда не работал с Hetzner, но это немного удивило.
2. По поводу пересоздания индекса. Эластик не транзакционная база, она не может быть source of truth. Возможность пересоздания индекса без даунтайма это там must have по моему) Скорость создания индекса часто можно оптимизировать - сделать меньше шарды, поиграться с parallelism/batch size и тд. По другому писать индексы чтоб вместо одного индекса на терабайт было несколько по годам или авторам.
3. Как это удалить весь шард? Сколько было реплик шарда, все реплики погибли что-ли которые были на разных инстансах?) Было ли настроено snapshot lifecycle policy?
4. Segments merging logic довольно неплохо работает. Оно старается держать количество marked as deleted документов до 30% и периодически их чистит полностью. Падение производительности я замечал когда полностью перезаписываем 100% документов в эластике. В этой ситуации конечно раз в неделю пересоздаем индекс заново. Все это без даунтайма, просто переключаем алиас на новый индекс. Этот индекс специально разделён на два (hot и cold) и пересоздание занимает 30 мин.
5. По добавлению инстансов в кластер. Всегда можно сделать blue-green деплой и просто покопировать шарды в новый кластер) Так может даже правильнее с прод релизом где постоянно большая нагрузка.
6. Честно говоря, так и не понятно почему переезжают на Vespa. Всеволод сказал что последние 2 года все работает норм на эластике. Александр сказал что пока не делал полноценные прод тесты с Vespa. Отсутствие шардов в Vespa это ж может быть и минус. Если например в индексе эластика 2 миллиарда документов и 20 шардов, там можно заюзать роутинг который пойдёт в конкретный шард и не будет искать среди 2 миллиардов доков. Я про Vespa ниче не знаю, но интересно как это реализовано там)
Было бы очень интересно послушать про ваши прод use cases где Vespa работает лучше. Время поиска для разных типов кверей, cpu/memory utilization дата нод, время индексирования, падение производительности при увеличении updated documents. Не у конечно для полноты картины, было б цікаво добавить деталей про текущий эластик - размер индексов, количество шардов и документов и тд) Так было бы больше понятно почему эластик все-таки скотина)
1. Назву для випуску вибирають продюсери, нічого сказати не можу. У Хецнера серваки є з ECC, є без, як бажаєш. Це bare metal, в їхньому клауді все ECC.
2. Це ж не логи, мені індекси по рокам не допоможуть. Більшість запитів на пошук йде без обмеження на роки, а якщо вони і є - то це типу "останні 10-15 років". Наскільки зручно працювати, коли треба один запит слати в кілька індексів, і потім об'єднувати результати? Це точно не той шлях, який я буду розглядати першим, другим чи п'ятим. По авторам це просто неможливо зробити, у наукової статті не один автор. Можуть бути і сотні, і тисячі.
3. Якщо чесно, я не пам'ятаю точно, який саме API виклик тоді допоміг. Я зараз полистав їх API хвилин п'ятнадцать, і можливо це був неочікуваний результат викликів cluster reroute. Три копії даних. Поки листав доки, згадав, що деякі репліки шардів випадали в UNASSIGNED, і можливо це була комбінація випадіння в unassigned і того, що одна з "живих" копій згнила. Супер-детального постмортему з усіма деталями на початку війни не робив, вибачайте. Lifecycle policy не було.
4. Так, звісно, перестворення нового індексу це переключення аліасу без даунтайму. Для основного індексу я навіть з БД всі свої дані не витягну за півгодини, вже не кажучи про те, щоб будь-який індекс встиг за цей час побудуватись, заздрю вашим півгодинам.
6. Взагалі не планував нічого про Веспу казати, тут ніяких веселих історій немає. Переїжджаємо по причинам, які не пов'язані з надійністю чи операційною складністю еластіка. У веспи дуже класна підтримка векторних полів, запитів, комбінація цього зі звичайним full-text пошуком, фільтрами, тощо. Це важливо для мого продукту, дозволяє зручно зробити те, що іншими способами незручно, дає калічні результати, або дуже довго працює. У восьмому еластіку теж з'явилась базова підтримка векторів, але порівняно з веспою воно прям базове. Всі інші речі - приємні бонуси.
Про роутинг, який не буде ходити в інші шарди - як я вже сказав, це не мій випадок.
7. У мене є наполовину написаний пост про те, як ми переїжджаємо з еластіка на веспу, але не схоже, щоб я його дописав найближчим часом. Розмір основного індексу (статті) в еластіку десять терабайт, 165 мільйонів документів (з копіями та оверхедом видалених - 620 млн).
Всмисле не треба глубоко ниряти? Тут ваш колега топ контент на 5+ годин робить, а ви шо :)
Колега дуже сміливий, а ми, бач, стараємося попасти в рамки фільмів 90-х 🤣
Коли CTO сам займається серверами, то це вирок
Наймайте девопсів, читайте документацію та вмикайте моніторінг
Про повреждение данные от неисправной сетевой карты это какой-то фейк
Сетевая карта всегда одни и те же поля коверкала - ну это уже как байка
Опять же, нужно мониторить сервера, нанимать девопсов
То что верхний уровень начинает колбасить когда неисправен нижний это нормально. Это и есть сигнал к тому что что-то не так
Судя по вашим рассказам вы что-то делаете с эластиком, а потом не понимаете почему и что происходит
Т.е. вы не читаете документацию, логи, не делаете мониторинг
Сделайте тег "1 апреля"
Ви десь почули, що я сам займаюсь серверами? Я навіть там кажу прямим текстом «не люблю це робити», в контексті того, що людина, яка займається серверами, на той момент була без звʼязку.
Мережева карта не портила одні і ті самі поля, це теж ви додумали.
Що відбувається з еластіком я зазвичай чудово розумію. Змоги розбиратись в причинах проблеми саме 24 лютого 2022 року в мене не було.
перепрошую за питання не по темі, але ось цю чорочку з хвилями - то де таку можна придбати? Може хтось знає.
Чорочку?
З посиланням ютуб заблочить комент, тому йдіть на yiume крапка ком, і там чоловічі гавайські сорочки, "japanese ukiyo-e".
Yiume крапочка ком.
@@VsevolodSolovyov Оу! Дякую!
@@asolovyov Хтось стукає. То напевно мовний патруль. Краще не буду відчиняти.
6-ти годинний бекап був зроблений ад-хок розробником для своїх пропріентарних потреб, і там було не все
Хм, але ж він просто LVM склонував, як може бути не все?
@@asolovyov Так а інфра ж не з одного LVM мабуть. І він міг там щось нахерячити в скопійованій. Короче, це нормально довіряти більше тому "бекапу", який автоматизований
@@OlegMarchuk згоден, просто що їх пост цей момент проскакує, а я за давністю років дещо подробиці з інших місць підзабув вже
Цікаво.