Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Создан форк системы управления контейнерами LXD, opennews (??), 05-Авг-23, (0) [смотреть все] Скрыто модератором, Аноним (1), 09:04 , 05-Авг-23, (1) –1 Нужно изменить лицензию форка на несовместимую с родным проектом И спокойно мир, Аноним (2), 09:08 , 05-Авг-23, (2) –3 // Ага каждого коммитера спросить согласен ли он на это План надёжный , Аноним (5), 09:17 , 05-Авг-23, (5) +4 // Не так уж и много там коммитеров , Аноним (13), 10:11 , 05-Авг-23, (13) // И все согласятся Гарантируешь , YetAnotherOnanym (ok), 12:28 , 05-Авг-23, (30) +1 А зачем кого-то спрашивать https www gnu org licenses license-compatibility ru, Anon3 (?), 15:54 , 05-Авг-23, (70) Перевёл - и всё - это когда ты один Но не любой разработчик согласится замени, Vindex (?), 13:36 , 07-Авг-23, (200) Сейчас мы, конкретно, говорим о смене лицензии Apache 2 на AGPL 3 Что и где, ко, Anon3 (?), 15:36 , 08-Авг-23, (248) –1 текст лицензии Который ты конечно же ниасилил Единственное что ты мог бы - это , пох. (?), 18:36 , 09-Авг-23, (261) –1 1 Вы должны предоставить всем другим получателям Работы и Производных работ, ко, Anon3 (?), 01:55 , 10-Авг-23, (262) Скрыто модератором, C00l_ni66a (ok), 16:50 , 05-Авг-23, (75) +2 А это точно нужно делать, если оставить рядом доступной для скачивания старую ве, leap42 (ok), 08:26 , 06-Авг-23, (139) // Если код этих коммитеров продолжает использоваться в новой версии - да, надо спр, Аноним (186), 02:08 , 07-Авг-23, (186) +2 для apache можно не выкидывать а модифицировать Но все равно надо уметь кодить , пох. (?), 15:34 , 10-Авг-23, (265) кому нужно, тот пусть и меняет , Атон (?), 10:41 , 05-Авг-23, (20) +1 Ну и хорошо может сделают вид контейнера, который будет удобно работать и удобно, Аноним (5), 09:10 , 05-Авг-23, (3) // Контейнеры, вообще-то, стандартизированы https en m wikipedia org wiki Open_, Аноним (8), 09:50 , 05-Авг-23, (8) +2 // В том то и дело что это сбоку прикрученный костыль , Аноним (5), 09:54 , 05-Авг-23, (10) –1 // Докер добился куда большего, чем lxc Прежде всего, создал единый универсальный , Аноним (35), 13:00 , 05-Авг-23, (35) к сожалению Было бы просто прекрасно если бы этот убогий недоделанный формат сдо, пох. (?), 14:00 , 05-Авг-23, (53) –4 Рыночек порешал так, как сказли манагеры А манагерам сказали другие манагеры А, Аноним (55), 14:12 , 05-Авг-23, (55) ничего страшного, они и исполнителей подобрали себе подстать Будешь хрустеть н, пох. (?), 14:28 , 05-Авг-23, (56) –6 Хотелось бы, конечно, более развёрнутое объяснение получить Дождусь ли , Прохожий (??), 12:41 , 06-Авг-23, (153) Надоело, сто раз вам тут этот бисер уже метали Просто почитай логи моего любимог, пох. (?), 14:24 , 06-Авг-23, (156) –1 Видимо, ты всё-таки не бисер метал, а какую-то другую субстанцию, раз никто так , Прохожий (??), 15:24 , 06-Авг-23, (158) да нет, почему никто Просто они не комментируют, как правило - им-то и так поня, пох. (?), 16:20 , 06-Авг-23, (160) Расскажи это руководителям фирм, которые пострадали от хакеров, например понятн, Прохожий (??), 23:15 , 06-Авг-23, (168) –1 Внезапно - на оркестратор, который будет пинать в том числе СУБД рСУБД не умеет, User (??), 07:08 , 07-Авг-23, (188) Очень смелое заявление Уже меняет, хотя и не коренным образом Общее количество , Прохожий (??), 12:43 , 08-Авг-23, (242) Ну, у меня окрест ни одного проекта без какой-нибудь NoSQL лет несколько уже нет, User (??), 14:09 , 08-Авг-23, (245) Это не говорит никак о том, что РСУБД своё отжили, не правда ли Просто добавилс, Прохожий (??), 15:31 , 08-Авг-23, (247) Отжили - такое интересное понятие скорее вытесняются в определенную приче, User (??), 08:00 , 09-Авг-23, (260) Ещё как считает Хотя не только это, конечно Решающими факторами остаются удобс, Прохожий (??), 23:21 , 06-Авг-23, (169) Нету такой проблемы Вы ее выдумали Проблема если случится сценарий А, нас оштр, qrKot (?), 11:34 , 07-Авг-23, (197) Блин, ты хорошо понимаешь что рефакеры и те у кого есть суммы сравнимые с Б - ск, пох. (?), 20:23 , 07-Авг-23, (216) Конечно, есть Многие крупные производители софта платят белым хакерам зачем То, Прохожий (??), 12:46 , 08-Авг-23, (243) Я ещё немного поразмышляю Если решать постепенно ключевое слово решать пробле, Прохожий (??), 15:32 , 06-Авг-23, (159) Подтверждаю, так и было Докер был ощутимо хуже по многим параметрам да и сейча, Аноним2 (?), 15:14 , 05-Авг-23, (62) –2 Эта часть истории прошла мимо меня Можно рассказать какие были альтернативы, че, Аноним (80), 17:50 , 05-Авг-23, (80) +2 Ну вот выше некий непризнанный гений системного администрирования на полном серь, Аноним (35), 00:33 , 06-Авг-23, (116) Ощутимо хуже чего Если вы про сабж то его небыло Емли вы про формат файлов Та, Анончик (?), 00:51 , 06-Авг-23, (123) Но _не принуждает_ использовать этот золе учий tar, как вы не понимаете Жизнь тр, Аноним (35), 01:03 , 06-Авг-23, (129) А чего ты не сделал как надо Докер нормальный формат, не кати бочку , Аноним (71), 16:07 , 05-Авг-23, (71) +1 Он и делал как надо Далее - Далее - Далее - Готово И никакие контейнеры не нуж, Аноним (35), 00:35 , 06-Авг-23, (118) Опять альтернативно одарённые мешают жить непризнанным гениям от системного адми, Admino (ok), 16:11 , 05-Авг-23, (73) +5 Вот это прямо вопиющая некомпитентность Когда человек рассказывает как нужно сд, Легивон (?), 20:46 , 07-Авг-23, (222) в общем, дальше, собственно, мог бы и не продолжать КомпИтентный ты наш это и , пох. (?), 22:35 , 07-Авг-23, (228) Нечего по существу ответить, да Решил до правописания докапаться tar архив - хо, Легивон (?), 19:04 , 08-Авг-23, (253) да просто на такого интеллигентного собеседника время тратить - бестолку приятно, пох. (?), 00:19 , 09-Авг-23, (254) Железо того времени не потянуло бы контейнеризацию , Аноним (13), 10:00 , 05-Авг-23, (12) +1   // Конечно железо, отсутсвие доступной поддержки виртуализации процессоров Второй , Аноним (1), 10:23 , 05-Авг-23, (16) –7   // Представь себе мой юный друг сервера и датацентры существовали даже в 1995 году , Аноним (5), 10:38 , 05-Авг-23, (19) +5   СМ1420 мой любимый калькулятор, но довольно увесистый выпускался серийно с 84г, пох. (?), 10:57 , 05-Авг-23, (24)   Насколько я помню, у нее в рекомендованных спеках было 4 Мб оперативки , Аноним (35), 13:05 , 05-Авг-23, (39)   Вот вот, а тут товарищ думает что в 1995 все ходили в мамонтовых шкурах и у них , Аноним (5), 13:07 , 05-Авг-23, (40)   Как минимум, он где-то нолик потерял, если вспоминать высказывание Гейтса Кроме , Аноним (35), 13:09 , 05-Авг-23, (42)   Ну всё давай покопаемся в дебрях и вспомним что он такого не говорил и не подраз, Аноним (5), 13:14 , 05-Авг-23, (45)   Ну, так как это местный альтернативно одарённый, то разбор его гениальных высказ, Аноним (35), 00:36 , 06-Авг-23, (119) +1   Дорогой друкк В каком калькуляторе й985 года выпуска было 64 килобайта озу Зара, Аноним (94), 18:25 , 05-Авг-23, (94) +1   двк2 м, кажется - чем не калькулятор Вполне себе выпускался в 85м А так на, зн, пох. (?), 21:33 , 05-Авг-23, (113) –2   Ну и контейнер это не виртуализация, учи матчасть , Аноним (5), 10:42 , 05-Авг-23, (21) +1   Да, 64 как-то маловато А вот 640 кб, если верить билли нашему гейтсу, должно , Аноним (32), 12:57 , 05-Авг-23, (32)   Ядро UNIX-подобной системы мы конечно же не считаем И кучу сторонних драйверов и, Аноним (173), 00:35 , 07-Авг-23, (173)   Железо того времени во всю тянуло полноценную виртуализацию правда, почему-то , пох. (?), 10:34 , 05-Авг-23, (17) –5   // Ну вот мы и имеем что имеем кучу контейнеров чтобы запустить самый простой софт , Аноним (5), 10:44 , 05-Авг-23, (22)   был бы простой - работал бы тот же подход 85го года - если оно такое г-но, надо , пох. (?), 11:01 , 05-Авг-23, (25) –4   Да, пилить SOAP API на перле всяко веселее , Аноним (35), 13:11 , 05-Авг-23, (43)   Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работае, Аноньимъ (ok), 13:49 , 05-Авг-23, (51) +2   дыркер не умеющий возвращать коды ошибок - прекрасная иллюстрация вещей в себе, пох. (?), 14:31 , 05-Авг-23, (58) +1   Программу на FORTRAN-е можно написать на любом языке программирования С Дальше , _ (??), 19:31 , 05-Авг-23, (104)   но тут стабильно получается фортран, куды ни глянь И причину мы все знаем - ЭТИ , пох. (?), 19:59 , 05-Авг-23, (105)   Без сложного окружения Go - это мерзота, которая тащит как попало собранные ку, Аноним (115), 00:31 , 06-Авг-23, (115) –1   Хорошо что вам на Си ничего крупного не приходилось собирать , Аноньимъ (ok), 02:04 , 06-Авг-23, (131) +1   GNOME3 это считается за сложно Собирал и нормально Сам, а не через всякие Gent, Аноним (115), 02:47 , 06-Авг-23, (133)   Серьезно Расскажите как модулями управляли, систему сборки использовали, или ру, Аноньимъ (ok), 04:09 , 06-Авг-23, (137)   Раньше GNOME собирался через jhbuild, сейчас не знаю Это была гномовская управл, Аноним (115), 20:11 , 06-Авг-23, (166)   А еще давай я помогу разобраться с той кашей, которая у тебя в голове про веб пр, Аноним (115), 02:40 , 06-Авг-23, (132) +3   Мда Это конечно отлично что вы с кашей в голове пытаетесь разобраться, но мда Ч, Аноньимъ (ok), 03:55 , 06-Авг-23, (135)   Вы явно не работали со всей этой гадостью, раз пишете такое Вы правы в том и т, Аноним (115), 16:31 , 06-Авг-23, (161) +1   Да, не работал Про микросервисы вы странное пишите, совсем им сервер приложений , Аноньимъ (ok), 18:15 , 08-Авг-23, (249)   Я пишу про то, какими они задумывались, как архитектурное решение для замены ESB, Аноним (115), 03:27 , 09-Авг-23, (256)   Да, абстракции многократно дублирующие друг друга, я довольно давно обратил на э, Аноньимъ (ok), 18:36 , 08-Авг-23, (251)   Да, все так Что-то чего не хватает - это нормальное реализации суперсервера на , Аноним (115), 03:56 , 09-Авг-23, (257) +1   Просто оставлю это здесь https github com kubernetes enhancements issues 3545П, Легивон (?), 20:55 , 15-Авг-23, (268)   Контейнеры это не про безопасность вообще Это способ опакетить ПО с окружением и, Аноньимъ (ok), 04:03 , 06-Авг-23, (136) +1   Было бы неплохо если бы они ее хотя бы не снижали , Аноним (115), 16:32 , 06-Авг-23, (162)   Дядь, ты что опять таблетки пить перестал Участковый психиатор заругается Ты сл, Легивон (?), 20:21 , 07-Авг-23, (215) –2   Спешу расстроить, это не троллинг Архитектура UNIX Internet Daemon предполагает, Аноним (115), 03:12 , 08-Авг-23, (231) +1   Уф Прям хоть в статью Метание бисера в википедию пиши Жалко, что все это в, User (??), 14:16 , 08-Авг-23, (246)   А как в линуксе с картами типа Chelsio которые могут в TLS оффлоад Я их немного , Аноньимъ (ok), 18:31 , 08-Авг-23, (250)   Драйвер тот же самый работает также Вам потребуется только научить юзерспейсный, Аноним (115), 03:04 , 09-Авг-23, (255)   Многа букав, читал по диагонали Дядь, если Шindoшs такая хорошая, почему на ней , Легивон (?), 18:52 , 08-Авг-23, (252) –1   Научись говорить за себя Разворачивают и много Взять например https stackov, Аноним (115), 04:37 , 09-Авг-23, (258) +1   Спасибо Нет, серьезно Если не сложно, можно прояснить тему одну По поводу недо, Аноним (259), 07:32 , 09-Авг-23, (259)   А мы вот любим rest fuck апи который реализуется игогой Даже время появил, _ (??), 18:12 , 05-Авг-23, (89) –2   к счастью нам не грозит уже При мизерных ресурсах их выделяют чайной ложечкой в, пох. (?), 18:43 , 05-Авг-23, (96)   Нищий туземец, живущий впроголодь, не может понять, зачем белые люди в цивилизов, Аноним (35), 00:40 , 06-Авг-23, (120)   так ездит-то не туземец на службе у белых людей наш _ - в лучшем случае в ба, пох. (?), 12:14 , 06-Авг-23, (150)   Судя по вашим представлениям об информационных технологиях явно отдающими совко, Аноним (35), 01:27 , 07-Авг-23, (177) –1   А вы случайно не тот легендарный персонаж, который постоянно пишет про то, что н, Аноним (35), 00:55 , 06-Авг-23, (127)   даааа, пилить нескучные апи на игогошечке - любой вайтишник с тремя классами обр, пох. (?), 11:10 , 06-Авг-23, (146)   Знаете, такое ощущение, что за вами однажды действительно пришли Дяди в белых х, Аноним (35), 11:30 , 06-Авг-23, (148)   знаете, такое ощущение что вы проецируете И дядя в белом халате до вас вовремя , пох. (?), 11:54 , 06-Авг-23, (149)   Ты от ЧСВ там не лопнешь Фамильярность вкупе с невежеством вещь жуткая , Аноним (60), 14:47 , 05-Авг-23, (60)   выросло поколение дол ов не узнающих цитату Не, не лопну, глядя на таких вот- , пох. (?), 15:43 , 05-Авг-23, (65)   Строго говоря, она не такая уж и распространённая С другой стороны, строго, опят, Аноним (110), 20:18 , 05-Авг-23, (110)   The jail utility appeared in FreeBSD 4 0 Hierarchical extensible jails were int, Всем Анонимам Аноним (?), 13:19 , 05-Авг-23, (47) +1   // узнаем, узнаем экспертов опеннета, которым приходится цитировать history Должон , пох. (?), 15:49 , 05-Авг-23, (66) –4   Майнфреймы бородатых годов 70х вполне тянули виртуализацию Порой там гипервиз, Neon (??), 23:33 , 06-Авг-23, (170)   lxd - это не только про контейнеры, с флагом --vm запускаются виртуалки, использ, Аноним (74), 16:15 , 05-Авг-23, (74) Потому что во многом тогда не было в них потребности Писали тогда в подавляющем, Легивон (?), 21:09 , 05-Авг-23, (112) systemd-nspawn, mikhailnov (ok), 13:42 , 06-Авг-23, (155) А зачем Контейнеры 8212 это спасение для безответственных программистов и ме, Аноним (173), 00:39 , 07-Авг-23, (174) // других программистов у меня для вас - нет начинай , пох. (?), 22:19 , 07-Авг-23, (227) Так они и делались все эти годы под названием hurd , Аноним (-), 19:51 , 07-Авг-23, (211) Новости из мира Линукс , Ахаха (?), 11:06 , 05-Авг-23, (26) +4 // Новости из мира вантуза - санкции, срочно ищем замену- майнер в рутрекере- вирус, Аноним (28), 11:57 , 05-Авг-23, (28) +7 // это из другого мира, нижнего Для rhel вы точно так же ищете замену, как и для u, пох. (?), 15:53 , 05-Авг-23, (68) –3 Юзаешь свободный от майнеров и рекламы qbittorrentДля запуска подозрительных ехе, Вася (??), 11:33 , 07-Авг-23, (196) –1 // Поэтому у них шифруют редисы и монги - установленые как раз в виде докера в доке, пох. (?), 22:09 , 07-Авг-23, (226) Debian внутри своей сборочной инфраструктуры использует lxc, который, в свете по, Аноним (29), 12:26 , 05-Авг-23, (29) –1 // Учитывая, что LXC - это тонкая обвязка над ядерными фичами cgroups и namespaces,, Аноним (35), 12:55 , 05-Авг-23, (31) +1 // В lxc есть чему чахнуть, да и на текущий момент уже хватает проблем, особенно эт, Аноним (29), 13:17 , 05-Авг-23, (46) +1 // Гугл подхватил упавшее знамя апстарта, подхватит и lxc , Аноним (5), 13:41 , 05-Авг-23, (50) А ему оно - зачем , пох. (?), 15:54 , 05-Авг-23, (69) stgraber 1 day ago 124 root 124 parent 124 next 8211 The majority , Роман (??), 00:34 , 06-Авг-23, (117) Ну вроде ж ровно наоборот - на те, Боже, что нам негоже , и даже разговаривать , пох. (?), 11:02 , 06-Авг-23, (144) Где подхватил На официальном портале америконского правительства написано , Аноним (35), 00:49 , 06-Авг-23, (122) где где - в гугле Наверняка проблемы устраняются, баги затыкаются, а может и ме, пох. (?), 11:03 , 06-Авг-23, (145) Ты для чего lxc использовал что такой негатив Я использовал как замену VBOX пр, swarus (?), 02:36 , 08-Авг-23, (230) А lxc с чего чахнуть должна Ей от того, что там творится с LXD ни жарко ни холо, llolik (ok), 13:02 , 05-Авг-23, (38) // А lxc без lxd вообще часто используют Я вот на своей практике ни разу не видел, Аноним (35), 13:08 , 05-Авг-23, (41) // Кажется вот у этих собственная надстройка над LXChttps pve proxmox com wiki Li, Анонус (?), 13:21 , 05-Авг-23, (48) Учитывая, что lxc появились лет на 5-7 раньше, чем lxd твой вопрос не имеет смыс, Аноним (59), 14:31 , 05-Авг-23, (59) Я использую, потому что у LXD нет возможности развернуть кластер с общим хранили, Аноним (85), 18:03 , 05-Авг-23, (85) LXD изначально разрабатывался Canonical, нельзя забрать себе то, что тебе и так , Аноним (59), 18:09 , 05-Авг-23, (88) То есть, основной разработчик проекта - присосавшийся паразит , Аноним (35), 01:40 , 07-Авг-23, (181) конечно Зарплату же, наверное, получал Присосался к каноникловским бабкам, пар, пох. (?), 20:24 , 07-Авг-23, (217) –2 Он решил уйти самОни избавились от паразитов, изменили путь развития, то что реш, Аноним (59), 22:07 , 07-Авг-23, (225) использую, без lsd, ой, lxd, Аноним (103), 19:13 , 05-Авг-23, (103) Нет конечно, LXD это REST сервер для LXCLXD - это LX DeamonLXC - это LX Client, microcoder (ok), 08:54 , 06-Авг-23, (140) –2 images еще форкните, Alex (??), 15:18 , 05-Авг-23, (63) Надеюсь в форке таки выпилят SNAP и начнут поставлять бинарями или на худой коне, Аноним (76), 17:16 , 05-Авг-23, (76) +1 // В debian 12 поставляется https wiki debian org LXD, Тимофей (??), 09:10 , 07-Авг-23, (189) Я во всем этом пока еще нуб Объясните мне на пальцах разницу LXC, LXD, Docker и, Аноним (77), 17:20 , 05-Авг-23, (77) // LXD - это просто API над LXC Поэтому нужно искать по запросу LXC vs Docker Вот, Anonimouse (?), 17:43 , 05-Авг-23, (79) Docker запускает один процесс в контейнере, LXC - всю ОС с некоторыми ограничен, Аноним (85), 17:57 , 05-Авг-23, (83) // https linuxcontainers org lxc articles Прекрасная документация по LXC от St 2, Аноним (59), 18:15 , 05-Авг-23, (91) // Спасибо большое Уполз читать , Аноним (77), 18:59 , 05-Авг-23, (100) Не за чтоЯ продвигал lxc в массы с самого его появления и был крайне недоволен т, Аноним (59), 21:59 , 05-Авг-23, (114) На самом деле, причина проста lxc объективно жирнее -3И по объему, и по степен, Аноним (35), 00:59 , 06-Авг-23, (128) в чем именно какую ты положил, такая и будет не запускай lxc совершенно все ра, пох. (?), 15:23 , 06-Авг-23, (157) Если запускать в контейнере только одно приложение, то даже запущенный под LXC, , Аноним (35), 01:36 , 07-Авг-23, (179) Собственно, это к тому, что lxc для этого не нужен И докер тоже не нужен Докер , Аноним (35), 02:03 , 07-Авг-23, (185) я тебе показал - вполне себе докерный Но виновата почему-то lxc вообще совершен, пох. (?), 20:36 , 07-Авг-23, (218) О, понятно и доходчиво Благодарю , Аноним (77), 18:58 , 05-Авг-23, (99) +1 точно так же - один процесс Просто это процесс - инит хотя и необязательно Ч, пох. (?), 20:03 , 05-Авг-23, (106) –5 // Чаще всего, героические борцы с докером никогда его не видели , Аноним (35), 00:45 , 06-Авг-23, (121) +2 То есть, втюхать пользователю 100500 файлов и запустить несколько десятков проце, Аноним (35), 00:54 , 06-Авг-23, (126) +1 LXD это REST сервер, отвечающий на запросы в формате JSLXC это клиент к LXDLXD -, microcoder (ok), 09:01 , 06-Авг-23, (141) –2 // LXC это клиент к LXD нет, lxc замечательно работает без lxd, Аноним (103), 05:54 , 08-Авг-23, (235) +1 Почему нельзя просто поставить программу в систему и пользоваться ей Зачем пост, Всадник Апокалипсиса (?), 18:03 , 05-Авг-23, (86) –1 // потому что у генитального разработчика была другая система, несовместимая с твое, пох. (?), 20:06 , 05-Авг-23, (108) +1 Можно Я разрешаю , Аноним (109), 20:08 , 05-Авг-23, (109) +3 Запуск в docker сводиться к docker-compose upили docker runЕсли мне на один вече, Аноним. (?), 03:11 , 06-Авг-23, (134) +2 // что происходит дальше - васяну-с-опеннета знать без надобности И если тебе дорог, пох. (?), 12:31 , 06-Авг-23, (152) –3 // Разумеется необязательно Если у меня задача - собрать tensorflow с поддержкой р, Аноним. (?), 20:22 , 06-Авг-23, (167) Что-то мне лень копипастить сюда содержимое go mod проекта lxd Но там всего-то , Аноним (35), 01:49 , 07-Авг-23, (182) +1 экспертиза опеннета пробивает очередное дно давайте не будем им мешать и про, пох. (?), 10:55 , 07-Авг-23, (192) +1 Тебе не приходило в голову, что может быть просто пофиг У меня жизнь есть за пр, Аноним (204), 16:29 , 07-Авг-23, (204) тебе настолько пофиг что ты не поленился пересчитать зависимости программы котор, пох. (?), 19:15 , 07-Авг-23, (208) +1 Да даже если бы и было полезно, ты бы всё равно не смог Твои фантазии ничего об, Аноним (204), 22:00 , 07-Авг-23, (223) Это проблема мейнтейнеров дистрибутива А эта команда сколько дерьма поставит ap, Аноним. (?), 20:44 , 07-Авг-23, (221) нет, это проблема оверинжиниренной где не надо и недоделанной где надо хренион, пох. (?), 23:36 , 07-Авг-23, (229) Туда еще желательно изменения иметь возможность вносить, так что HTTP файл серве, Аноним. (?), 03:14 , 08-Авг-23, (232) Там говорить нечего Там учетки, дальше отредактировал конфиг добавил маску лок, Аноним. (?), 03:24 , 08-Авг-23, (233) Linux это лебедь рак и щюка в степени бесконечность И коперасты регулярно дона, Аноним (163), 19:02 , 06-Авг-23, (163) // Форк форкнул форк форка, который форком погонял форк , Аноним (163), 19:03 , 06-Авг-23, (164) Одна надежда на Devuan , Аноним (163), 19:04 , 06-Авг-23, (165) // Он ещё не утонул , Аноним (35), 01:38 , 07-Авг-23, (180) Все это классно Но расскажите в чем разница докера подмана и lxd В чем lxd луч, scriptkiddis (?), 20:27 , 05-Авг-23, (111) // Там где ты бы по общей логике выбрал использовать виртуалки, там же почти всегда, Роман (??), 00:53 , 06-Авг-23, (125) // Чем это лучше proxmox ve , хаха (?), 10:53 , 06-Авг-23, (142) // Работает в моем уютном wsl2 например , Роман (??), 11:17 , 06-Авг-23, (147) +1 Так бы и сказал что ничем А wls2 это многое о тебе говорит , мнда (?), 01:03 , 07-Авг-23, (175) не привязано к дебияну, Аноним (190), 09:23 , 07-Авг-23, (190) Изначально Proxmox работал только с виртуалками, поддержку контейнеров в нем дол, Аноним (59), 16:34 , 07-Авг-23, (205) Docker is cattle, LXC is pets Docker packages applications, and should only real, Роман (??), 01:09 , 06-Авг-23, (130) +1 // В общем это ничем не лучше proxmox ve или libvirt или virtualbox И никак не выи, хаха (?), 10:54 , 06-Авг-23, (143) –2 // экспертиза опеннета во всей красе Ему только что детально разжевали что это воо, пох. (?), 12:17 , 06-Авг-23, (151) Не обязательно Никаких ограничений на это по факту там нет и если очень надо то, BrainFucker (ok), 23:35 , 06-Авг-23, (172) // Ну поставите вы там полноценную систему, ну понапишете внутри контейнера руками , Аноним (35), 01:54 , 07-Авг-23, (184) Нужную конфигурацию можно описать в dockerfile А ещё образ докера можно создать, BrainFucker (ok), 05:41 , 07-Авг-23, (187) И потом уже никто не сможет распутать этот гадючий клубок Правильно, всегда так , пох. (?), 10:56 , 07-Авг-23, (193) А что, документацию по проекту писать уже не модно , BrainFucker (ok), 10:59 , 07-Авг-23, (195) ЧЁ , пох. (?), 12:41 , 07-Авг-23, (198) Скрыто модератором, Аноним (-), 20:06 , 07-Авг-23, (212) Скрыто модератором, пох. (?), 11:12 , 08-Авг-23, (240) Пользовался когда-то LXD, пока не начали форсировать snap, тогда и перешёл на до, BrainFucker (ok), 23:33 , 06-Авг-23, (171) –1 Сначала увидел в трендах 300 звёзд и 600 контрибюторов было LXD реально крута, Пряник (?), 09:36 , 07-Авг-23, (191) –1 // расскажите ему кто-нибудь, что его нае обманули и lxc не имеет отношения к вир, пох. (?), 10:58 , 07-Авг-23, (194) // Создан форк системы управления контейнерами LXD, Пряник (?), 12:44 , 07-Авг-23, (199) Да ладно А что тогда вот эта команда ниже делает не подскажешь На моём локалхос, Аноним (204), 16:14 , 07-Авг-23, (202) // оберточку для запуска qemu-kvm вызывает Если это virsh здорового человека - н, пох. (?), 19:18 , 07-Авг-23, (210) Я, конечно, извиняюсь, но qemu можно и без virsh вызвать Достаточно один раз со, Аноним (-), 20:08 , 07-Авг-23, (213) можно, и без lxc тоже Но в массовых масштабах несколько неудобненько И нескольк, пох. (?), 20:40 , 07-Авг-23, (219) б-ть, я рад за твой локалхост А теперь представь что у тебя ентих xyему штук та, пох. (?), 18:10 , 11-Авг-23, (267) А libvirt 8212 это не обёрточка для qemu-kvm, это другое, понимать надо Себе, Аноним (204), 22:01 , 07-Авг-23, (224) –1 Это бесполезно, слишком много неграмотных в этом ITT треде Но вообще в Linux э, Аноним (115), 04:05 , 08-Авг-23, (234) +1 // Если перед сном не дать мозгам отдохнуть 15 минут, а сидеть в телефоне или смотр, Пряник (?), 09:38 , 08-Авг-23, (236) –1 ну, а чо нетак то Вот и каноникалы туда же Только что-то пошло не так и они в, пох. (?), 09:59 , 08-Авг-23, (237) Так всё что было с ним связано не взлетело из-за того как и на чем он был постро, Аноним (115), 12:32 , 08-Авг-23, (241) ну то есть мелкие клиенты нам не нужны потому что причем мелкие это по-видимому, пох. (?), 12:58 , 08-Авг-23, (244) Я так пару лет назад совал статический qemu в докер Докер сам не любил, но нашё, Аноним (-), 10:44 , 08-Авг-23, (239) Я ничего не понял Кто кого Поясните кто-нибудь, Аноним (201), 15:17 , 07-Авг-23, (201) // тоже, очень интересно, yet not so another (?), 18:11 , 07-Авг-23, (206) Постоянно паникуют раньше времени, форки делают, а потом оказывается что основно, Аноним (238), 10:09 , 08-Авг-23, (238) 2,3,26,29,63,76,77,86,111,171,191,201,238

Сообщения

[Сортировка по времени | RSS]

	12. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (13), 05-Авг-23, 10:00
	Железо того времени не потянуло бы контейнеризацию?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Создан форк системы управления контейнерами LXD"	–7 +/–
	Сообщение от Аноним (1), 05-Авг-23, 10:23
	Конечно железо, отсутсвие доступной поддержки виртуализации процессоров. Второй момент это отсутсвие лишних ресурсов, операционных системы, 64 кб не хватало всем. На то время запустить на голом железе систему уже победа была. Апач вышел в 1995, что контейнеризировать, doom запускать в докере? Автор настолько не понимает сути, что очевидно находится на уровне неоконченного среднего образования поворского коледжа
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Создан форк системы управления контейнерами LXD"	+5 +/–
	Сообщение от Аноним (5), 05-Авг-23, 10:38
	Представь себе мой юный друг сервера и датацентры существовали даже в 1995 году. Твои 64кб были в калькуляторе 1985 года. В 1995 году уже была даже Windows 95 прикинь, сынок.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 10:57
	СМ1420 (мой любимый калькулятор, но довольно увесистый) выпускался серийно с 84го. 128k слов (двухбайтовых) в процессорной стойке и до двух мегабайт в дополнительной (правда, она наверное попозже появилась) PDP 11/70 с которой ее сдирали, подозреваю лет на десять постарше будет.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:05
	> В 1995 году уже была даже Windows 95 прикинь, сынок. Насколько я помню, у нее в рекомендованных спеках было 4 Мб оперативки.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	40. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 13:07
	Вот вот, а тут товарищ думает что в 1995 все ходили в мамонтовых шкурах и у них было 64 килобайта оперативы.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:09
	Как минимум, он где-то нолик потерял, если вспоминать высказывание Гейтса. Кроме того, оно явно датируется еще эрой MS DOS и Norton Commander.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 13:14
	Ну всё давай покопаемся в дебрях и вспомним что он такого не говорил и не подразумевал.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (35), 06-Авг-23, 00:36
	Ну, так как это местный альтернативно одарённый, то разбор его гениальных высказываний стал доброй традицией.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (94), 05-Авг-23, 18:25
	Дорогой друкк. В каком калькуляторе й985 года выпуска было 64 килобайта озу? Заранее благодарен. Ps всегда нравится, когда какое-нито существо вылупившееся в 21-м веке начинает втирать про калькуляторы 1980-х годов, при том что еще не вымерли те, кто в 1980-е годы на них калькулировали.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	113. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от пох. (?), 05-Авг-23, 21:33
	> В каком калькуляторе й985 года выпуска было 64 килобайта озу? двк2(м, кажется) - чем не калькулятор. Вполне себе выпускался в 85м. А так на, знакомься с достижениями загнивающего запада: https://en.wikipedia.org/wiki/TI-92_series кто ж вам виноват что для вас это - фантастика была...
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (5), 05-Авг-23, 10:42
	Ну и контейнер это не виртуализация, учи матчасть.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	32. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (32), 05-Авг-23, 12:57
	> 64 кб не хватало всем Да, 64 как-то маловато. А вот 640 кб, если верить билли нашему гейтсу, должно.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	173. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (173), 07-Авг-23, 00:35
	Ядро UNIX-подобной системы мы конечно же не считаем. И кучу сторонних драйверов из серии "авось хоть с ним заработает" — тоже. Работать будем без GUI, исключительно в командной строке. И, конечно же, каждый пользователь ПК должен уметь пересобирать ядро, чтобы выгадать несколько КБ ОЗУ.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Создан форк системы управления контейнерами LXD"	–5 +/–
	Сообщение от пох. (?), 05-Авг-23, 10:34
	Железо того времени во всю тянуло полноценную виртуализацию (правда, "почему-то", получалось только виртуализировать дос, но тогдашний "дос" работающий наполовину в protected mode ты еще потрахайся-ка виртуализировать) - именно на нее тогда и был спрос. Это я тебе, голуба, говорю как краевед - у меня оно дожило такое до осени 98го и умерло не своей смертью. А на тяпляпаные контейнеры к великому счастию спроса тогда не было. Считалось что если софт нельзя запустить без прослоек и прокладок и трижды обмотав скотчем по периметру - надо поискать или самому написать нормальный, а это просто выбросить.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	22. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 10:44
	Ну вот мы и имеем что имеем кучу контейнеров чтобы запустить самый простой софт.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Создан форк системы управления контейнерами LXD"	–4 +/–
	Сообщение от пох. (?), 05-Авг-23, 11:01
	был бы простой - работал бы тот же подход 85го года - если оно такое г-но, надо быстренько написать нормально (или хотя бы г-но попатчить как можешь). Но увы, софт перестал быть простым, а бесконечного времени у тебя нет. Поэтому жрем чодали и стараемся держаться подальше от моднявых трендов на игого и с нескучными rest(fuck) апи.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:11
	Да, пилить SOAP API на перле всяко веселее.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноньимъ (ok), 05-Авг-23, 13:49
	Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного окружения. А вот например чтобы что-то на питоне развернуть, нужно тащить сложное и жирное окружение которое не больно то между системами переносится. С джавой всё тоже непросто. Ну и сишный софт завязанный на тысячи зависимостей в каждом пакетном менеджере под каждую систему своих. Сейчас ещё модно стало тащить виртуальную машину, к ней сервер приложений, а в нём уже запускать программы, привет нода и всякие АСП.нет руби на рельсах и прочее.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	58. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от пох. (?), 05-Авг-23, 14:31
	> Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного > окружения. дыркер (не умеющий возвращать коды ошибок) - прекрасная иллюстрация вещей в себе. И от того что ты все окружение слинковал в полгиговый статический бинарник, лучше никому не стало, только вот проблемы очередного лефтапада придется решать теперь снова отдельно в каждом бинаре.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от _ (??), 05-Авг-23, 19:31
	>> Гошка [...] отличная вещь, можно написать сервис который вещь в себе [...] >дыркер (не умеющий возвращать коды ошибок) - прекрасная иллюстрация вещей в себе. Программу на FORTRAN-е можно написать на любом языке программирования.(С) Дальше мысль расскрывать? Но дыркер да - убер шЫт, всё прогрессивное человечество должно осудить и расстрелять :( >И от того что ты все окружение слинковал в полгиговый статический бинарник, лучше никому не стало, Дык - мне стало луДше! /thread :) Или ты любитель "странных танцев" с Ансиблем и дыркером ? 8-о Как посмотришь "чо-нить на ноде" плэй и мой "игогошный" - сразу станет понятно. >только вот проблемы очередного лефтапада придется решать теперь снова отдельно в каждом бинаре. Ну чинить тупо _всё_ когда очередной пЫонер уберёт лок с апдейта к примеру на openssl и оно в ночь на выходной таки реально обновится! - оно конечно _гораздо_ приятнее ;-DDDD Но тут - каждому - своё, согласен.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 19:59
	> Программу на FORTRAN-е можно написать на любом языке программирования.(С) но тут стабильно получается фортран, куды ни глянь. И причину мы все знаем - ЭТИ разработчики сидят под виндой. (В винду они разумеется тоже не умеют, коды ошибок были и там. Они вообще ни во что кроме очередного фреймворка не умеют. Но раньше от них-то и не требовалось.) > Ну чинить тупо _всё_ когда очередной пЫонер уберёт лок с апдейта к примеру на openssl мой лок - пЫoнер не уберет. Ну и я-то выводы про подобных делаю и хотя бы выбираю поделки где это наименее вероятно и свои отдельные локи ставить приходится редко. Это все же лучше чем получить миллион дырявых лефтпадов/log4j разных версий намертво вкомпиленых в прожекты. Так их хотя бы всего четверть миллиона. Причем разгребать это все придется, разумеется, не давно свалившему в туман разработчику.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (115), 06-Авг-23, 00:31
	> Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного окружения. Без сложного окружения?! Go - это мерзота, которая тащит как попало собранные куски кода внутрь единого бинарника. Все "окружение" у него внутри, потому что снаружи оно вообще не имеет никакого окружения, не имеет логики бинарного модулей, и как следствие не имеет взаимодействия между модулями. А еще они логику сборки меняют чаще чем нижнее бельё. Вот неплохая статья про Go с его "модульностью": https://maelvls.dev/go111module-everywhere/ "Гошка" - это где разрабы не умеют делать релиз и не знают что это такое. Её управление "модулями" и зависимости, привязывающиеся к хэшу коммита на github или еще в какой-то другой системе управления версиями. При этом _релиза_ как такового в Go нету. Есть 100500 модулей, которые в общем случае зафризены по последнему комиту в общей кодовой базе, которая в свою очередь даже тегов может не иметь. Все в кучу свалено. При сборке они выкачивают это барахло по сети и собирают себе в единый бинарь. Проблема отсутствия релизов и проблема отсутствия бинарных модулей - 2 разные проблемы. Отсуствие бинарных модулей делает этот язык весьма ограниченным и нишевым (нет жизни вне микросервисных проектов от слова "совсем"). Отсутсвие концепции релиза на проект, опциональность релиза напрочь меняет ворос управления разработкой проекта на Go. Если в нормальное экосистеме разработчики вынуждены: - делать релиз, - сопровождать релиз -- исправлять ошибки в релизе -- исправлять уязвимости в релизе - следить за обратной совместимостью API внутри релиза (бинарным требуется еще и ABI) То тут абсолютная помойка. КОНЕЧНЫЙ проект грузит в себя код модулей из гитхаба. И все его модули и зависимости это просто 1001 срез текста, который никто не сопровождает. И у каждого такого модуля есть еще модульные зависимости, которые никто толком не сопровождает и так влоть до N вложенных зависимостей. То есть сопровождает это всё погромист на гошке, то есть ТЫ! Допустим твой проект хочет 2 модуля: - mega-lib-2-5-blablahash1, ты выбрал актуальную версию в которой исправлены уязвимости и ошибки - ultra-lib-1-4-blablahash2, ты выбрал актуальную версию И второй модуль гвоздями привязан к mega-lib-2-4-blablahash3, потому что иди нафиг. И всё это сливается в единый бинарь в одну кодовую базу, которую поддерживаешь ТЫ, потому что релиз - не барское дело для гошников. Если npm и pip это формы рака, то модули go - это уже СПИД.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	131. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 02:04
	Хорошо что вам на Си ничего крупного не приходилось собирать.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 02:47
	GNOME3 это считается за сложно? Собирал и нормально. Сам, а не через всякие Gentoo. Причем собирал в префикс подключался через Xserver Xephyr. Но это было давно, когда я был энтузиастом Linux и много было свободного времени... А что собственно вы хотели сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 04:09
	> GNOME3 это считается за сложно? Собирал и нормально. Сам, а не через > всякие Gentoo. Причем собирал в префикс подключался через Xserver Xephyr. Но > это было давно, когда я был энтузиастом Linux и много было Серьезно? Расскажите как модулями управляли, систему сборки использовали, или руками в консоль вводили команды? Но самое интересное конкретно про модули и зависимости зависимостей. > свободного времени... А что собственно вы хотели сказать? Хотел проверить понимаете ли вы то, что пишите.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 20:11
	> Расскажите как модулями управляли, систему сборки использовали, или руками в консоль вводили команды? Раньше GNOME собирался через jhbuild, сейчас не знаю. Это была гномовская управляшка модулями, которая собирала разные куски GNOME. Каждый модуль мог при этом иметь свою систему сборки. jhbuild как раз и выправлял множественные зависимости. У нее там были свои метапакеты/метамодули, не помню. Суть в том, что в Linux для нативной линоковки вам нужны заголовки на С, а в случае с С++ могут потребовать еще и биндинги к С ради переносимости библиотеки, потому что С++ некроссплатформенный язык со всеми вытекающими последствиями. Часть модулей связывается друг с другом через dbus. GNOME как проект следил за всеми своими зависимостями, чтобы не возникало проблем вроде тех, которые я писал выше, когда 2 модуля зависят от разных версий третьего модуля. GNOME это делает, потому что это они авторы своих же модулей. В Go ситуация иная. Там речь не про модули, заголовки и линковку. Там именно что всё сваливается в общий бинарь, код соединяется статически со всеми. И вот вопрос to vendor or not to vendor. Ты либо сам решаешь проблемы совместимости в других проектах, от которых ты зависишь, форкнув их, потому что оно попадёт к тебе в общий бинарь, либо надеешься на апстрим, авось и ходишь к попам на воскресную молитву. Гошники просто кидают сорцы в Git. Из-за отсутствия возможности динамической линковки им незачем заниматься бинарной сборкой модулей, не за чем поддерживать совместимость самих с собой. Учитывая что большая часть разработчиков на Go не имеет даже такой концепции, как "релиз модуля" и распространяют свой код через систему контроля версий в публичном интерене, иногда без тегов и как попало, то те кто занимается сборкой и доставкой Go в дистрибутивах вынуждены городить инфраструктуру релиза своими средствами. Почитайте https://docs.fedoraproject.org/en-US/packaging-guidelines/Go.../ Для сборки программы на Go меинтейнеры должны: 1. Отключить при сборке загрузку сорцов с гитхабов и гитлабов авторов-игогошников, потому что им веры нет 2. Опакетить сорцы каждого модуля приложения, сделав релиз за этих бомжей 3. Самостоятельно решить проблему зависимостей зависимостей внутри сборочной системы Go силами дистрибутива с использованием RPM 4. Самостоятельно сопровождать форки кодовой базы и перепакечивать и обновлять Весь этот язык придумал Google для запуска многопоточных клиент-серверных приложений в форме монолитных блобов внутри Kubernetes. Причем он специально сделан процедурным языком с АЛГОЛ-образным синтаксисом, чтобы людям было привычно и не нужно было использовать erlang. Go - это замена erlang в его нише, ни больше, ни меньше. И вся его простая экосистема создана для этой задачи быть запущенным в контейнере под управлением кубика.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Создан форк системы управления контейнерами LXD"	+3 +/–
	Сообщение от Аноним (115), 06-Авг-23, 02:40
	А еще давай я помогу разобраться с той кашей, которая у тебя в голове про веб приложения. Обычное веб приложение требует: - сервера приложений, который управляет рабочими процессами, пайплайнами обработки запросов и возможно маршалингом (тогда оно ни разу не микросервисное), если там один модуль подтягивает другой в общую память. - само приложение, которое либо выполняется внутри инегрированного интерпретатора с JIT, вроде JVM (для java), CLR (.NET Framework) либо локальном интерпретаторе, вроде .net 5+, python, php, perl, ruby, либо выполняется нативно через API сервера приложений CGI Популярные сервера приложений: 1) Apache Tomcat, JBoss/Wildfly и прочие сервера приложений полностью или частично реализующие Java EE. Они запускают JVM, внутри которой поднимают приложения-сервлеты. Java EE стандартизирует логику взаимодействия этих веб-приложений друг с другом и логику написания своего сервера приложений для Java. Java полностью изолирована от работы с железом и рулит своими ресурсами на уровне JVM. Рабочие процессы на стороне ОС отсутствуют, но есть сервлеты, их классы и их потоки исполнения. 2) Internet Inforamtion Services (IIS) и другие сервера приложений повторяющие архитектуру UNIX Internet Daemon Этот сервер приложений приложений ровным слоем размазан по ОС. Каждый тип запроса реализует своя подсистема. За HTTP отвечает соответсвующий модуль, отдельный модуль для аутентификации и авторизации, отдельный для шифрования TLS. В случае с Windows - это драйверы ядра. Информация передаётся через сокеты и в общем случае вы можете привязками сделать всё что угодно и сцепить с любым интерпретатором. Странно что inetd не популярен в UNIX-подобных ОС для той самой блин задачи, для которой он был спроектирован... но это лирика. Главное то, что супер-серверы на стороне ОС. Внутри IIS, например, запускаются экземпляры службы публикации, которая кроме обслуживания статики может: - прицепить к себе модуль ISAPI - прицепиться к другому вебсерверу, вроде kestrel ( встроен .NET 5+), Node.JS - использовать интегрированный пайпалайн .NET Framework 2.0/4.0 и .NET 5+ (но там всё равно внутрипроцессный kestrel) - прицепиться к службам ОС, если они написаны по стандарту WCF - прицепиться к отдельному серверу реализации рабочих процессов через CGI и работать как обычный вебсервер, вроде nginx. Из-за того что Windows имеет драйверы ядра под это всё - IIS сейчас это единственный из живых серверов приложений, который реально способен работать с железом напрямую. Он управляем утилизацией процесса и памяти. Фиксирует приложения на разных ядрах если надо. Работает с топологией NUMA и умеет распределять ресурсы между теми рабочими процессами, которыми управляет. 3) Apache HTTPD и другие аналогичные ему с особенным API Это максимально урезанная реализации inetd, чтобы не размазывать из по ОС. Apache HTTPD вообще сейчас не используется почти что как сервер приложений, только разве что в энтерпрайзе для обслуживания старых APR-модулей. Его пайплайны мало соотносятся с нынешним железом, поэтому он почти всегда виртуален и почти всегда веб-сервер (ради например SSI, который хорошо работает, но это не про сервера приложений). Вот тут мы вспомним про Passenger и про то что Ruby on Rails рекомендовано использовать с ним. Логика там +/- такая же. 4) Юзерспейсные сервера приложений такие работающие через FastCGI Есть реализации серверов приложений специально сделанных под интерпретатор, которые отдаются на вебсервер по через CGI. Те же известные php-fpm, uwsgi и прочие PSGI Вообще большая часть интерпретаторов имеет свою логику работы с рабочими процессами и потоками. ASP.NET Core (не Framework), Node.JS, Java. Для доставки приложения перед ними ставят реверспрокси вроде HAproxy или nginx (в роли прокси). Другие же используют отдельно стоящий сервер приложений обычно на базе FastCGI и имеют внутри интерфейсы *GI. Так работают php, python, perl. Перед ними ставят любой вебсервер поддерживающий CGI/FastCGI. nginx или HAproxy (в роли вебсервера) и потом доставлять наружу через реверспрокси. А третьим нужен специальный модуль к специальному вебсерверу. ASP.NET Framework (через IIS), Ruby on Rails (через passenger) и можно пользоваться php, perl, python через Apache mod_*, но лучше не надо. 5) Kubernetes Оно пожрало и уничтожило своих предшественников docker swarm и openstack magnum (для задачи). У этого логика в том, что всё вышесказанное упрощается и мы работаем с воркерами кубернетиса, которые работают с контейнерами. Внутри контейнера находится та самая инфраструктура специяичная для приложения и его интерпретатора/бинарника. Единственное, что кубернетис делает хорошего - позволяет хоть как-то управлять и обслуживать микросервисный проект, который писали мартышки на 5 разных языках в разное время. В остальном он скорее привносит проблемы, нежели их решает. > Сейчас ещё модно стало тащить виртуальную машину, к ней сервер приложений, а в нём уже запускать программы, привет нода и всякие АСП.нет руби на рельсах и прочее. Вот теперь после всего вышесказанного я могу объяснить, как мы до этого докатились. ОС и её ядро умеют работать с железом. ОС умеет работать с сетевой подсистемой сервера. ОС имеет реализацию сервисов, в ядре есть планировщик процессов и много чего еще. ОС пишут для того, чтобы приложения работали на железе. Есть архитектура UNIX Internet Daemon, которая очень успешная и проверенная временем. Ирония в том, что всё это активно применяется только в Windows и это позор. То есть как сервер приложений IIS работает. Java никогда в своей жизни не хотела работать на железе. Она максимально абстрагирует приложение от железа, и JVM выступает в роли ОС. Это тоже работает и Java делает это вполне успешно. Apache HTTPD как сервер приложений скорее мертв, чем жив. Вся его оптимизация под железо и оптимизация его модулей под железо в далёком прошлом. Интегрироваться с ОС он при этом никогда не мог. Это юзерспейсный сервер не способный рулить железом и разделением ресурсов. NGINX Unit и Passenger такие же. Равно как и проекты, которые реализуют на коленке сервера приложений имени одного интепретатора, который потом отдаётся по FastCGI. И вот у нас есть 4-х процессорный сервер с террабайтом RAM. И что по вашему произойдет если одно приложение разорвется по разным процессорам и разным блокам памяти? Правильно, оно будет тупить нищадно. А ничего что на современных процессорах по нескольку контроллеров памяти, которые по разному могут примапится к разным ядрам. А что такое Xeon Scalable? Весь этот зоопарк железа нативно поддерживает сейчас только IIS. Для всех остальных случаев - виртуализация. Сервера приложений имени интерпретатора слишком глупы, чтобы это понять и с этим работать, поэтому мы поставим гипервизор, который часть ОС. Он умный, он нарежет нам виртуальный сервак так, как надо. Пофигу что мы потеряли от 15-50% производительности приложения. А что с SMT/HyperThreading? Там вообще мрак! Вот окажется ваш воркер на псевдо ядре и что дальше? И если вы думаете что Kubernetes и его контейнеры вас спасут от этой проблемы - то вы горько ошибаетесь. Поддержка железа в кубике всё еще в зачаточном состоянии. Ну то есть теоретически если вы: - поставите однопроцессорные блейды на compute - поставить отдельный от них сторадж в отдельной сети - поднимите CLOS eBGP Undelay в топологии Spine Leaf - начнете роутить Overlay-сети кубика через ECMP - поставите сетевки, которые поддерживают Hardware SDN Offloading - внутрь запихаете микросервисные приложения, которые: -- строго-настрого стейтлесс -- либо все однопоточные с одним рабочим процессом, либо вы отключите SMT/HyperThreading на железе То вы получите вменяемую производительность. И если вас мучает вопрос, причем тут сеть, не удивляйтесь. Сами себе контейнеры придумали, будьте любезны правильно сеть настраивать и оффлоадить. Много видели barebone-кубиков? То-то же! Реальность такова, что чтобы пользоваться даже кубиком вам нужно его воркеры виртуализовать и правильно назначить ресурсы через тот же KVM или другой гипервизор. То есть и там виртуалки. Кроме того безопасность ванильного кубика - это такая несмешная шутка, особенно когда нет виртуализации. Сейчас контейнеры на железе массово не используются, потому что со стороны контейнерной оркестрации нет поддержки работы на разномастном железе. Безопасность изоляции не выдерживает никакой критики. При этом внутри контейнеров сервера приложений юзерспейсные и слишком глупые, чтобы реализовать это самим. Любой кто говорит о приросте производительности от использовании докерообразных контейнеров по сравнению с виртуализацией - теоретик, фантазёр и админ локалхоста. Есть попытка у Red Hat сделать OpenShift (OKD) как barebone решение. Они там и kubevirt прикручивают и root запрещают и SELinux вменяют. Даже RHEV (oVirt) выкинули на мороз. Вон cgroups2 развивается тоже. Ну посмотрим как им это поможет, рано пока. Может лет через 10. В общем, что только не придумают, чтобы не юзать inetd-архитектуру. P.S. Кстати LXD сабж из новости старается работать именно на железе в отличии от остальных контейнерных систем. И у него получается сильно лучше. Вот только у него с безопасностью еще большие проблемы, потому что Ubuntu c Apparmor и её тягой запускать всякую бяку от root.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	135. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 03:55
	> Обычное веб приложение требует: >- сервера приложений Мда. Это конечно отлично что вы с кашей в голове пытаетесь разобраться, но мда. Что там за проблемы с многопроцессорными системами не в хайлоаде непонятно вообще. Запускать приложение в границах NUMA ноды, и будет счастье. Если ваше приложение больше 256 потоков успешно грузит, и вот никак не масштабируется горизонтально вообще, то очень плохо конечно. Нужно делать его тогда с оглядкой на нелокальность ресурсов, но в таком случае странно что не масштабируется. Иначе забить остаётся и строить многопроцессорные системы/кластеры.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 06-Авг-23, 16:31
	Вы явно не работали со всей этой гадостью, раз пишете такое... Вы правы в том и только в том, что если ни монолитное приложение не умеет в поддержку многопроцессорного железа, ни сервер приложений, нужно просто всё ограничить в рамках одной нума ноды. Теоретически вы абослютно правы, но на практике это ни разу не тривиальная задача. По факту это сейчас достижимо на сервере приложений IIS или с контейнерами LXD, или у вас там Java EE/Jakarta EE экосистема. Остальные сервера приложений сами не способны на такие привязки от слова "совсем". Для микросервисных веб-приложений, их интерпретаторов и серверов это сложная задача. И даже если хайлоада нет, то вам все равно придется назначать границы, если вы этого не сделаете то работа приложений будет не определена и не стабильна. Для дурацких серверов приложений можно сделать привязку средствами ОС сверху, но тогда теряется вообще всякий смысл пользоваться сервером приложений для разделения физических ресурсов. Весь сервер приложений тогда окажется на одной NUMA-ноде. А если есть N приложений, которые нужно разместить по M нодам NUMA, задача опять нетривиальна. Что тогда делать? Порождать несколько экземпляров серверов приложений. И вот чтобы удобно ими управлять это всё виртуализируют. Получается так: - Есть веб-приложение, обрабатывающее запросы, в доме, который построил Джек. - Есть дурацкий сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть виртуальная машина с одним узлом NUMA, в которой запущен сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть гипервизор, который назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть инфраструктура виртуализации, которая предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть сервер оркестрации, который управляет несколькими инфраструктурами виртуализации (тест и прод), которые предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. Ну как? Тошнит? Это применяется для внутренних корпоративных продуктов какой-нибудь логичтической фирмы. Ничего особенного. И вот вся эта пресловутая контейнеризация призвана, якобы, упростить архитектуру крупных корпоративных веб-проектов. Однако, на 2023-й год она не способна выкинуть виртуализацию. > Если ваше приложение больше 256 потоков успешно грузит, и вот никак не масштабируется горизонтально вообще, то очень плохо конечно. Есть 2 типа приложений микросервисные и остальные. Микросервисное приложение - это стетлесс сервис, который получает запрос и отдает ответ. Они функциональны в том смысле, что на если поступило два запроса, то приложение корректно ответит на оба вне зависимости от порядка обработки запросов. Состояния вынесены в сторадж подсистему, которая отделена от микросервиса. А еще микросервисное приложени не использует маршалинг. Каждый функциональный модуль, к которому хочет обратиться такое приложение оформлен в виде другого микросервисного приложения, а не разделяемой библиотеки/класса/ассембли, которая подгружается в общую кучу этого приложения. Сама идея использования микросервисных приложений заключается в том, что есть: 1. Оркестрация серверов приложений 2. Сервера рабочих процессов управляют экземплярами приложений 3. Приложение "простое", желательно однопоточное, без стейтов на нем, работающее в режиме вопрос-ответ и общением с источником стейтфул-данных на бекенде (база, файловый сторадж, итд) Микросервисные приложения не управляют своими ресурсами и своей многозадачностью. Это вынесено на сервер приложений, который за это отвечает. Другие "остальные" большие приложения по "256 потоков" - это монолитные приложения. И они ничем не хуже микросервисов. Просто они сами управляют своей многопоточностью, потенциально грузят внутрь себя другие куски кода и возможно держат на себе стейты так, что запрос 2 может быть обработан только после запроса 1 и только на том же самом экземпляре мнололитного приложения. Собственно микросервисные приложения хорошо масштабируются, но тратят больше ресурсов на сопровождающую инфраструктуру и имеют издержки на сетевое нелокальное взаимодействие. Монолитные приложения в общем случае быстры, но развитие их кодовой базы проблематично, горизонтальное масштабирование, в общем случае, - нетривиальная задача, решение которой зависит от самого приложения. Диалектика шила и мыла. При этом вопрос виртуализации не снимает ни один подход к написанию веб-приложений. Для микросервисных приложений, которые работают на железе, нужно чтобы _сервер приложений_, который порождает экземпляры (рабочие процессы) и перенаправляет на них поток запросов умел работать с железом и ОС. Для микросервисных приложений, которые работают на железе, нужно чтобы _само приложение_, умело работать с железом и ОС. Сервера приложений устроены так, что могут запускать и микросервисные приложения и монолитные. Просто контроль за ресурсами будет в разных местах. То есть в общем случае все сводится к одному к поддержке железа и ОС. И вот если оно (монолитное приложение  или сервер микросервисных приложений) дурацкое, то вам нужны виртуалки, чтобы правильно решить задачу с размещением этого всего на NUMA. Причем в реальности для "больших" монолитных веб-приложений, например, как вы пишете про "256 потоков", ситуация усугубляется тем, что их интерпретатор должен понимать железо, быть интегрирован в ОС, или это бинарное приложение на С, что по сути даст то же самое. Отсюда и появляется требование к inetd-архитектуре IIS, который предоставляет такую интеграцию средствами ОС. Или Java EE, которая построена на этих принципах, только не в рамках стандартных библиотек ОС, а средствами JVM. Ваши "простые" теоретические решения запускать все в рамках нуманоды понятны и правильны. Я же просто описываю практическую сторону вопроса, развернуто отвечая на вопрос причем тут виртуализация. Я могу дать лаконичный и краткий ответ: "либо используйте виртуализацию, либо ставьте нормальную ОС с нормальной реализацией UNIX Internet Daemon (Windows с IIS)", но такой ответ местной публике не понравится. Начнутся эмоции, ответ сочтут за троллинг, потому что многие тут не видели крупных веб-проектов и не понимают реальную проблематику их написания и дальнейшего сопровождения. Есть 3 многообещающих продукта, которые в перспективе следующих 10 лет способны потеснить гегемонию IIS на поприще высоконагруженных внутрикорпоративных порталов: - NGINX Unit, если они начнут наконец работать с железом. Снйчас оно очередное "дурацкое". - LXD, если у него появится инфраструктура, но судя по новости там форк на форке и запираемся в каноникал. - Потуги Red Hat вокруг Barebone OpenShift.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:15
	Да, не работал. Про микросервисы вы странное пишите, совсем им сервер приложений ненужен, пишут на той-же гошке успешно, и вполне себе сами управляют ресурсами. Про отсутствие стейта то-же неверно, это не то что делает микросервисы микросервисами. Например видел такое как сервис управления транзакциями, потому что использовать для этого реляционную БД(которая есть в виде постгри) это не модно. Ну и конечно сейчас мало кто понимает что это такое вообще и зачем нужно, поэтому зачастую просто жесть получается. Но в целом спасибо, узнал много нового.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 09-Авг-23, 03:27
	> Про микросервисы вы странное пишите, совсем им сервер приложений ненужен > Про отсутствие стейта то-же неверно, это не то что делает микросервисы микросервисами Я пишу про то, какими они задумывались, как архитектурное решение для замены ESB с их проблемами масштабирования и отказоустойчивости. Причем исключительно для решения Enterprise Master Data Management, то есть работа с НСИ, документами, остатками, деньгами и другими данными, которые по определению считаются бизнес-критичными. У таких приложений всегда есть понятие первоисточника мастердаты, поэтому они избегают хранения данных на разных кусках и модулях приложения и борются с этим ради отказоустойчивости и горизонтального масштабирования. А еще у таких приложений есть отчетность OLAP, чтобы смотреть за динамикой формируя срезы отчетов по кубам. То есть они вручную следят за изменениями данных складывают это в Data Warehouse. И там очень много разных микросервисов, часть отвечает за обработку данных, а часть следит за их изменениями и пишет отчетность. Чтобы всем этим управлять, обновлять, мигрировать и нужны сервера приложений, даже если внутри многопоточный код на Go. > Например видел такое как сервис управления транзакциями, потому что использовать для этого реляционную БД(которая есть в виде постгри) это не модно. Хммм... а это точно те транзакции, которые в базе? Может это транзакции в бизнесс-смысле или это просто была реализация координатора распределенных транзакций, когда один кусок приложения (источник) формирует набор инструкций в транзакцию, а микросервис-получатель должен распределить это на несколько назначений сразу так, чтобы либо все выполнились успешно, либо вся транзакция провалена. Это реализация ACID на программном уровне и такое часто нужно. Я не видел проекта, могу только гадать, но раз вы пишите про PostgreSQL и если кому-то требуется видеть не только нынешние данные, но еще и видеть всю историю их изменений с начала времен в соседней базе, да так, чтобы можно было строить кубы... PostgreSQL не может в OLAP, если я правильно помню, она строго OLTP. Вы не можете просто так взять и построить на ней многомерную аналитику, это не Oracle DB и даже не MSSQL.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:36
	>Ну как? Тошнит? Это применяется для внутренних корпоративных продуктов какой-нибудь логичтической фирмы. Ничего особенного. И вот вся эта пресловутая контейнеризация призвана, якобы, упростить архитектуру крупных корпоративных веб-проектов. Однако, на 2023-й год она не способна выкинуть виртуализацию. Да, абстракции многократно дублирующие друг друга, я довольно давно обратил на это внимание и с тех пор прибываю в некотором недоумении. По идее, ОС - и есть сервер приложений, который как бы ими управляет и, и получается чего-то серьезно не хватает. Ну допустим сделали виртуализацию, должно по идее хватать этого, или не должно? То есть какой смысл в контейнерах если есть нормальная виртуализация и можно приложения по виртуалкам распихать?
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	257. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 09-Авг-23, 03:56
	> По идее, ОС - и есть сервер приложений, который как бы ими управляет и, и получается чего-то серьезно не хватает. Да, все так. Что-то чего не хватает - это нормальное реализации суперсервера на стороне ядра популярных UNIX-подобных и не хватает еще тонны модулей реализующих протоколы на стороне ядра и вот, когда данные вынули, нужна еще сервисная модель на стороне ОС, чтобы можно было быстро принять в приложение запросы не запуская их каждый раз заново. И привязки одного к другому нужны и инструментарий для управления этим из пространства пользователя... Много чего нужно, на самом деле. > Ну допустим сделали виртуализацию, должно по идее хватать этого, или не должно? Я писал в одном из своих постов, что не каждая нагрузка легко виртуализируется. На некоторых задачах высочайший оверхед. Если отвлечься от темы веб и поговорить чисто про виртуализацию, то попробуйте взять 4-х ядерный компьютер с частотой хотя бы 2.2 и обычным локальным диском SSD, и поставьте на него какой-нибудь особенно проблемный для виртуализации софт, например asterisk. Измерьте какое количество одновременных звонков он будет держать, а потом на тот же компьютер поставьте виртуалку с такими же параметрами как он сам и оцените деградацию производительности. Так вот на серверах виртуализации еще и оверкоммит CPU почти всегда. Или сравните производительность SQL-сервера, причем абсолютно любого. Там тоже осязаемая деградация от факта применения виртуализации. Так вот, приложение тоже можно так написать. Например, если оно порождает огромное количество параллельных потоков и как следствие переключения контекстов. По моему опыту, если у вас 14000 переключений контекстов в секунду на ядро вашему сервису конец. Уберете виртуализацию и полегчает. Там же еще виртуальные сетевые адаптеры, если они не заведены через SR-IOV они выполняются на том же процессоре. Виртуализация - это гарантированная потеря производительности от 15%. Эта технология нужна только для того, чтобы уплотнить размещение серверов в стойках, сэкономить энергию и деньги. Если есть 10 приложений, которым нужен 4-хядерный сервер 16ГБ RAM и 500ГБ диска то, что вы поставите 1 сервер на 40+ ядер или 10 серверов на 4 ядра? Вопрос риторический. В остальном виртуализация мешает. Контейнеры - это попытка придумать изоляцию для приложений друг от друга без накладных расходов на виртуализацию, причем они популярны только в Linux, потому что они там решают тонну других задач: - используются вместо setup.exe, чтобы была переносимость между 9000-ми несовместимых друг с другом и со своими прошлыми версиями - используются как средство конфигурирования при для автонастройки - для распространения проприетарного софта и особенно его обновления, когда компания покупает услуги подрядчика, а подрядчик выкатывает новые версии и патчи своим корпоративным клиентам Был бы стандартизированный юзерспейс не было бы таких ухищрений. По назначению их используют сравнительно редко.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Легивон (?), 15-Авг-23, 20:55
	Просто оставлю это здесь https://github.com/kubernetes/enhancements/issues/3545 Пока Вы писали стены текста про **NEMOJET**, поддержка NUMA появилась в 1.28 релизе. Придется теперь перекрывать только неподдержкой tls offload карт, которые используюся в 0.0001% инсталяций. Действительно очень большая проблема. Пойду из-за неё переустановлю k8s на такой хороший Шindoшs, настрою isis и ftp. И буду по последнему туда релизы загружать консольным ftp клиентом, как хакир, а затем автоматизирую это все на cmd и visualbasic сприптах. Как тебе такое Илон Маск?
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	136. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 04:03
	>Безопасность изоляции не выдерживает никакой критики. Контейнеры это не про безопасность вообще. Это способ опакетить ПО с окружением или связку некоего ПО.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	162. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 16:32
	Было бы неплохо если бы они ее хотя бы не снижали...
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от Легивон (?), 07-Авг-23, 20:21
	>Есть архитектура UNIX Internet Daemon, которая очень успешная и проверенная временем. Дядь, ты что опять таблетки пить перестал? Участковый психиатор заругается! Ты слышал такую вещь как производительность? Где производительность и где inetd запускающий по экземплярую программы на запрос? Какой ужос! Не верится даже что это может оказаться не троллингом. >Поддержка железа в кубике всё еще в зачаточном состоянии. Это концентрированный бред. Поддержка железа кубером = поддержке железа Linux. За исключением тех архитектур на которых не собираются "5 go бинарников". Не понял ваш пример железа. Я использую кубиры на обычных виртуалках без каких бы то ни было аппаратных излишеств. И у меня все работает. >Реальность такова, что чтобы пользоваться даже кубиком вам нужно его воркеры виртуализовать Неправильно. Реальность такова, что на практике аппаратные сервера настолько мощные (100+ ядер, 500+ RAM), что никто не готов выделять под типичные задачи небольшого проекта 7 аппаратных серверов (3 etcd + 2 control plane + 2 worker). Даже самый маленький сервер который имеет смысл приобретать будет иметь ресурсов на порядок (10 раз) больше чем нужно 1 инстансу. Поэтому с кубиром виртуализация и используется практически всегда. Плюс кубер это динамичная система. Надо воркеров - добавил, не надо - убавил. С этом случает удобнее привязываться к инстансам невысокой производительности. >Кроме того безопасность ванильного кубика - это такая несмешная шутка Он гораздо безопаснее за счет какой-никакой изоляции в namespaces, которую на голом хосте, в сравнении с этим, как правило никто не настраивает. >Сейчас контейнеры на железе массово не используются, потому что со стороны контейнерной оркестрации нет поддержки работы на разномастном железе. Чего? Что за бред я читаю? Примеры будут? >Безопасность изоляции не выдерживает никакой критики. На порядки выше изоляции процессов чем на обычном хосте, на котором как правило не настраивают namespaces... Ведь если начать настраивать namespaces - так ведь можно и до докера дойти. А это не true! А по факту уже давно имеется стабильный qemu-kvm runtime реализующий стандарный интерфейс контейнеров - kata-containers называется. Можете использовать его в k8s посредством изменения 1 строчки. >Любой кто говорит о приросте производительности от использовании докерообразных контейнеров по сравнению с виртуализацией - теоретик, фантазёр и админ локалхоста. Рассказывай как ты скейлишь свой highload... Или погодите, на локалхосте же нет хайлоада. >root запрещают и SELinux вменяют Хорошее решение, переспективное, в духе Red Hat. Думаю root можно будет открывать по подписке.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	231. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 08-Авг-23, 03:12
	> Где производительность и где inetd запускающий по экземплярую программы на запрос? > Какой ужос! Не верится даже что это может оказаться не троллингом. Спешу расстроить, это не троллинг. Архитектура UNIX Internet Daemon предполагает наличие суперсервера, который перенаправляет запросы на другие демоны. На примере реализации в IIS: 1. Запросы поступают по сети, которую обслуживает ядро (драйверы адаптеров и сетевой стек) 2. К каждому IP и порту есть привязка HTTPS, HTTP, HTTP2 или QUIC 3. Если соединение предполагает наличие криптографии, то она обслуживается модулем по работе с TLS опять на стороне ядра 4. Аутентификации (Basic, Kerberos, X.509) обслуживается как ядром, так и юзерспейсом, если требуются особые формы делегирования 5. Далее мы получили запросы по HTTP, которые обслуживает HTTP.sys на стороне ядра (кроме запроса PATCH, он в юзерспейсе) 6. Поступившие запросы попадают на сокет службы согласно правилам привязок и определения пулов приложений. 7. Каждый пул — это запущенный с пониженными привилегиями экземпляр службы публикации, который реализует пайплайн по работе с запросами. Пулы и есть многопоточные рабочие процессы для ряда интерпретаторов (.NET, Node.JS) или связываются с дочерними процессами по CGI Реализация этой классической UNIX-архитектуры в Linux — это полное фиаско и несмываемый позор. Учитывая, что во времена ядра 2.6 предпринимались попытки реализовать это средствами ядра, как в Windows, но получилось, как всегда. Проект по реализации обработки HTTP тогда появился в ядре и благополучно сдох. А что с TLS на уровне ядра? Зачатки Kernel TLS появились в районе 4.13, а в 5.1 оно только-только стало экспериментально работоспособным. Но мало кто пользуется им еще, все по-прежнему линкуют всё в дистрибутивах к OpenSSL. Я это всё к тому, что реализация inetd убогая, медленная и мёртвая, работает как попало и чисто в юзерспейсе. В Windows реализация inetd есть очень давно, и она называется IIS. Ей полностью меняли реализацию 3 раза (1995-2000, 2001-2005, 2006-наст. время) из-за того, что она размазана по всей ОС и меняется с мажорным апдейтом. Но пользователи видели только 3 инкарнации. И вот она работает очень быстро. > Поддержка железа кубером = поддержке железа Linux. Нет не равно! Кубик — это планировщик. У него есть назначение приоритетов, но не ресурсов железа. Вы понимаете, как они работают со своими 0.5 CPU? Это веса планировщика. Чем выше цифра, тем выше приоритет контейнера. Но с реальным железом они не мапятся. Linux с железом работает, а кубик нет. Кубик не может назначить такие-то процессоры и ядра с таким-то уровнем утилизации на такой-то ноде NUMA. Есть вот эта бетка, но она все еще экспериментальная: https://kubernetes.io/docs/tasks/administer-cluster/memory-m.../ А еще там нужно шейпить сеть в ядре и много чего еще делать по фильтрации запросов/пакетов в ядре. Вам (контейнерщикам) для этого годами eBPF разрабатывают, а я всё как не гляну, всё равно узко. Динамическая фильтрация пакетов работает в ядре Windows c года так с 2001-го. Говорить надо или сами узнаете что такое WFP и как он соотносится с NDIS. Оно там всё либо не доделано на стороне Linux, либо на стороне Kubernetes, либо брошено всеми, и все забили. > Не понял ваш пример железа. Я использую кубиры на обычных виртуалках без каких бы то ни было аппаратных излишеств. И у меня все работает. Правильно, потому что с физической инфраструктурой не работали. Конечно, у вас все работает на виртуалках. Я же пишу, что оно ТОЛЬКО ТАК работает. А теперь соберите кубик на многопроцессорном железе без грамма виртуализации, я посмотрю на вас. У вас будут несколько проблем: 1. NUMA, её разные формы на разных физических хостах, особенно Xeon Scalable вас удивит своей гибкостью. Так как кубик всё это не умеет пока, то придётся брать однопроцессорные блейды и игнорировать наличие NUMA. При этом у вас все равно по нескольку контроллеров на проц, которые мапятся к разным ядрам, но там не так страшен вариант расползания разных потоков на разные ядра с разными контроллерами RAM, чем если это расползание одного приложения между разными сокетами. 2. Сеть на стороне хоста. Вам нужен DPDK, пойдите еще поднимите его: https://www.dpdk.org/wp-content/uploads/sites/35/2020/11/DPD... Причем, чтобы завести всё это так, чтобы у вас там Overlay оффлоадилась на сетевые карты, вам проще поставить сетевки NVIDIA (Mellanox), потому что только они нормально работают в Linux. А если вам нужен еще и сторадж в контейнерах, то проще перейти на использование S3-образного объектного стораджа, отказавшись от всего остального, потому что там будет тонна проблем либо с производительностью, либо с подбором железа. Если вы попытаетесь подать в контейнеры локальный сторадж, то вы упретесь в геометрическую проблему серверной платформы. Однопроцессорные блейды имеют мало дырок на диски, может не хватить в зависимости от... и тогда хана. Если вы попытаетесь подать сетевой сторадж, то запустить его с поддержкой RDMA и оффлоадить сторадж на сетевой карте та еще задачка. - NFSv4+ в Linux опять частично работает в userspace, Linux вам не Solaris и не FreeBSD, чтобы иметь нормальные драйверы, но кое-как RDMA запустить можно. Вся проблема в NFSv4 ACL, которые в Linux медленные. - SMB, насколько я знаю пока не вышел в прод и находится в состоянии PDF-презентаций разной степени красивости. - iSER (iSCSI over RDMA) вроде бы работает и даже с поддержкой Multipath, но менеджить LUN-ы как контейнерный сторадж... уффф. Ну так вот, когда вы радостно поставили свой Ceph-кластер или купили проприетарную хранилку вам нужно сцепить его с физическими нодами кубика так, чтобы заработал оффлоадинг по RDMA и чтобы сеть была построена так, чтобы multipath работал. Единственный рецепт для Linux - построить это всё исключительно на L3 и вот почему! В ядре Linux просто омерзительный драйвер бондинга и кошмарный драйвер виртуального свитча. Обоим место в музее. Все современные модули ядра Linux и все новые фишки работают только через мосты (Linux Bridge). Для вас (убежденного в том, что Kubernetes нормально работает на железе и в Linux всё хорошо с железом) придется настроить выделенный сегмент сети в топологии Spine-Leaf в режиме L3, который будет выполнять роль Underlay. Забудьте про MLAG, стеки, фабрики и прочий LACP. Вам придётся построить eBGP CLOS, настроить ECMP и настроить Border-свитчи для стыка сегмента с основной сетью датацентра, пусть даже по OSPF, но в отдельной Area. Если вы любите Linux берите NVIDIA (Cumulus Linux), они работают. > Реальность такова, что на практике аппаратные сервера настолько мощные (100+ ядер, 500+ RAM), что никто не готов выделять под типичные задачи небольшого проекта 7 аппаратных серверов (3 etcd + 2 control plane + 2 worker). Даже самый маленький сервер который имеет смысл приобретать будет иметь ресурсов на порядок (10 раз) больше чем нужно 1 инстансу. Поэтому с кубиром виртуализация и используется практически всегда. Ах, эти знаменитые аргументы про "не нужно", какая прелесть =) То, что у тебя нету больших задач и тебя до них не допустили, совсем не значит, что их нет ни у кого вообще и у меня в частности. Я знаю, что я говорю, потому что я это делал и оно работало на стенде так как надо именно с железом, потом поставил поверх OpenStack. Передо мной стояла задача развернуть Kubernetes as a Service быстрее по производительности, чем у некоторых конкурентов. Как раз на серверах с 96 ядер и 1ТБ RAM. Но без виртуализации оно именно что неюзабельно, от слова "совсем". Всё что там необходимо сделать по мультитеннантности, по изоляции по разграничению ресурсов на данном этапе сыро. Это решает Red Hat в OpenShift, который тоже еще сырой для barebone и не особенно то в фаворе у дурачков, которые докеры крутят, там же root нельзя. А без отжима root никакой изоляции в Linux не добиться. А оборудование нужно изолировать от дурачков, оно от них тупеет. Развертывание железного кубика не сложнее чем OpenStack свой собрать... но и не проще. И вот это всё от вас прячет инфраструктура виртуализации в датацентре. Вы пользуетесь виртуалками, потому что изнутри них не знаете сколько очередной VMware ESXi и VMware NSX делает для таких вот пафосных "знатоков" Kubernetes. > Он гораздо безопаснее за счет какой-никакой изоляции в namespaces, которую на голом хосте, в сравнении с этим, как правило никто не настраивает. Во-первых, научись говорить за себя. У меня нет ни одного хоста Linux с выключенным мандатным контролем. Во-вторых, "какая-никакая изоляция в namespaces" это в тебе говорит культ карго и суеверность. Вся эта чешежопица с namespaces и контекстами SELinux существует исключительно потому, что в ядре Linux исторически: - нет нормальных ACL. Вместо них POSIX ACL, которые мусор, они опциональны, и применяются только к ограниченному типу объектов, особенно нет ACL для процессов юзерспейса - нет нормального понимания сессии, вместо этого есть Linux PAM, который ничего ни от кого не изолирует и все запущенные процессы входы в систему считает локальными и равными друг другу - нет способа динамически менять привилегии процесса без его перезапуска - Capability в ядре Linux — это вообще шутка очередная. Вот они годами и правят 1001-у архитектурную ошибку, которая была допущена. Замечаешь, как Linux с каждым годом становится всё больше и больше похож на Windows... хмм... интересно, почему так происходит, не правда ли? > Примеры будут? Мой изначальный тезис в том, что высоконагруженные корпоративные приложения, если нужно избежать виртуализации, сейчас применяются только на Windows с IIS и это суровая реальность. Если же компания реально огромная и их не устраивает Windows и её лицензирования, IIS и сложность его оркестрации, то они радостно форкают BSD. Некоторые типы задач настолько чувствительны к той паразитной нагрузке, которую порождает виртуализация, что там просто выбора нет. Почти всё реалтаймовое, всё что имеет высокий параллелизм, все что работает по принципу "ссылка->данные" (такая задача не кэшируется на процессоре), всё с со сложными многопоточными математическими вычислениями - тонна отраслей и задач. Это ты мне должен привести примеры массового использования докерообразной контейнеризации без грамма виртуалок сразу на железе, раз ты убежден что она активно используется. Сам-то заявляешь, что сидишь с виртуальным кубиком, думая, что те кто покрупнее используют его без виртуалок. А вот нифига! > А по факту уже давно имеется стабильный qemu-kvm runtime реализующий стандарный интерфейс контейнеров - kata-containers называется. > Хорошее решение, переспективное, в духе Red Hat. > Думаю root можно будет открывать по подписке. Ты окончательно запутался, как мне кажется. Именно Red Hat трудится над запихиванием KVM в Kubernetes. Они строят новый OpenShift с поддержкой KVM внутри контейнеров, с поддержкой мультитеннантности с поддержкой изоляции и с возможностью работать на железе. Всё чем ты перечислил — это куски GPL-кода в апстриме, находящиеся под полным контролем Red Hat и выкинутыми наружу частями OpenShift/OKD. Они закрыли oVirt, чтобы разрабатывать это. Я не знаю, за что ты так ополчился на Red Hat, но именно они пытаются решить проблему, о которой я тут распинаюсь и которую ты не видел в виду собственной ограниченности кругозора. Да KVM это ненастоящий (type2) гипервизор. Его виртуальные машины — это процессы в ОС. И весь юзерспейсный инструментарий управления KVM страдает от того, что в нем нет… барабанная дробь… автоматизаций вроде NUMA Spannig для виртуальных машин и гранулярной работой с SMT. И вместо того, чтобы писать и развивать инфраструктуру виртуализации для type2 гипервизора они решили сделать наоборот, сделать уже наконец-то barebone-контейнеризацию, внутри которой можно пихать виртуалки. Вот ты мне говоришь, KVM, будто это что-то хорошее… У него проблемы с уровнем оверкоммита CPU, если его виртуалки слишком разношерстны по ресурсам. Сейчас реальность с KVM такова, что на крупном развертывании KVM можно стабильно жить с overommit 2-4 по CPU. Если нужно выше то нужно: - создавать пресеты виртуалок (понятие flavor в OpenStack) - создавать привязку flavor к образу ОС (в OpenStack Glance) - поставить группу кластеров под каждый flavor<->image - настроить placement api, чтобы оно разносило типы виртуалок по нужным кластерам - использовать только конвергентный сторадж, гиперконвергентные решения не работают от слова "совсем" (Red Hat, конечно, предлагал раньше ставить oVirt на GlusterFS, но там по подписке и они это все закрыли). Вот тогда можно добиться стабильного оверкоммита 4-6. Amazon активно занимается решением этих проблем и по-прежнему продолжает заносить бабло в Citrix, потому что Xen просто работает. Равно как и его младшая сетричка Hyper-V, которая держит оверкоммит 6-8 со стандартными настройками и 8-10 если выключить балунинг и использовать процессоры исключительно одинаковых моделей. VMware близка к этим показателям, и у нее своя специфика. Причем KVM еще и памяти требует больше, чем Hyper-V и VMware, но это уже из-за специфики реализации страничного кэширования в ядре Linux. Я это знаю из опыта работы на хостинг-провайдеров и, да, я работал со всеми кластерами, на высоких провайдерских хайлоадах. Так кот, все эти проблемы на стороне KVM +/- те же самые, что и в кубике, и выражаются они прежде всего в большей степени в косорылых автоматизациях в юзерспейсе, но также и в ущербности самого ядра. KVM-у, как Type2 гипервизору реально место в кубике, потому что нормальную виртуализацию шапка так и не запилила, свой флагманский овирт выкинула. Со стораджем там тоже беда-беда, грозятся новый сторадж писать опять. И всё это опять в OpenShift. > Дядь, ты что опять таблетки пить перестал? Участковый психиатор заругается! Он заругается скорее на то, что я пытаюсь научить очередного хамовитого юнца, как пользоваться компьютером, вместо того чтобы послать его на йух.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от User (??), 08-Авг-23, 14:16
	Уф. Прям хоть в статью "Метание бисера..." в википедию пиши. Жалко, что все это в недрах комментов пропадет - я процентов 60% описанного цеплял, (не) приятно узнавать, что там еще примерно столько же граблей лежит. До чего ж проще "Моя контейнеромэ таскай, кубера кнопка назимай - все работает, насяльнике! А если плёха работает - твая еще виртуалка нарезай и все-все будит!"
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:31
	>А что с TLS на уровне ядра? Зачатки Kernel TLS появились в районе 4.13, а в 5.1 оно только-только стало экспериментально работоспособным. Но мало кто пользуется им еще А как в линуксе с картами типа Chelsio которые могут в TLS оффлоад? Я их немного под фрёй тыкал, там правда свои смешные баги есть...
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	255. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 09-Авг-23, 03:04
	> А как в линуксе с картами типа Chelsio которые могут в TLS оффлоад? Драйвер тот же самый работает также. Вам потребуется только научить юзерспейсный софт это использовать. Nginx точно может. Ну и вам нужно сравнительно свежее ядро (5.1+). Mellanox работает, значит и эти будут, но я непробовал именно Chelsio, потому что мы их давно не покупаем. Они реализуют iWarp, а не RoCEv2. И это не потому что один хуже другого, они +/- одинаковые, а потому что они не совместимы в рамках одной сторадж-инфраструктуры, и при проектировании сети мы делаем выбор и потом придерживаемся используемого протокола для RDMA. Выбор делается по следующему принципу: - Если нужно спроектировать мультипротокольную сторадж сеть, в которой бизнесу нужно по-разному шейпить разные протоколы, например, нарезать SMB от NFS от iSCSI и прочее, то у вас и так будет много веселья с QoS, и вам придется рулить PAUSE-фреймами в рамках VLAN-ов. Вывод: берите RoCEv2, OFED-прекрасный драйвер и хорошо работает и на Windows и на Linux и на FreeBSD. - Если у вас есть и Infiniband и Ethernet в датацентре, делайте RoCEv2 - Если у вас там что-то маленькое однопротокольное, нет бюджета на нормальные коммутаторы и нужно выдать что-то быстро, и вы готовы потом докупать, исправлять, настраивать, отлаживать. iWarp - ваш выбор. Оно сильно сэкономит время на первичной настройке, но потом придётся настраивать на сетевом железе всё то же самое, что нужно для RoCEv2 изначально. И вот у меня везде RoCEv2.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Легивон (?), 08-Авг-23, 18:52
	Многа букав, читал по диагонали. Дядь, если Шindoшs такая хорошая, почему на ней не разворачивают сервера? Практика - критерий истины! Весь твой поток недостатков Linux на практике и близко не приближается к недостатком Шindoшs. Именно поэтому она такая "совершенная" (если не забывать переустанавливать раз в неделю) и не нужна никому кроме "домохозяйки". Ну и кроме может быть лютого дремучего кровавого ынтерпрайза с тормозящими монолитами, которым чтобы они чуть меньше тормозили приходится выделять процессоры сокетами, а отсюда и разбираться со всеми нумами, бондингами и большей частью того что ты излил выше. В k8s мирке решили иначе: приложения должны быть маленькими и их нужно запускать сразу на большом количестве ненадежных инстансов и скейлить горизонтально. Даже если ненадежные инстансы падаю - большой проблемы не возникает. Оно и близко не сравнится с проблемой когда дремучий монолит самопроизвольно перезагрузится, потому что ваш господин решил за вас, что ему нужно устанавливать обновления.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	258. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 09-Авг-23, 04:37
	> Дядь, если Шindoшs такая хорошая, почему на ней не разворачивают сервера? Практика - критерий истины! Научись говорить за себя. Разворачивают и много. Взять например: https://stackoverflow.com/ На бекенде у него кластеры с физическим IIS на Windows без виртуализации. И ты не поверишь, но оно микросервисное. Это прекрасно делается и без кубика. Кстати, о кубиках. Если Windows такая никому не нужная, зачем Kubernetes умеет работать поверх Hyper-V и зачем Kubernetes полностью поддерживает работу с контейнерами Windows с IIS внутри: https://kubernetes.io/docs/concepts/windows/intro/ Как ты сказал, "Практика - критерий истины!" > чтобы они чуть меньше тормозили приходится выделять процессоры сокетами, а отсюда и разбираться со всеми нумами, бондингами и большей частью того что ты излил выше Со всем этим разбирается и знаком каждый системный и сетевой администратор, который развернул инфраструктуру виртуализации на предприятии. Это их работа. А тем временем унылые девопсы: 1) не имеют достаточной компетенции, и мозгов чтобы её поднять и научиться работать с железом 2) их контейнеризация не способна жить без виртуализации. Первый тезис доказывают твои же слова: "Многа букав, читал по диагонали." А второй тезис подробно расписан, в том посте, который ты не осилил. Кубик не способен ничего запускать на голом железе, хотя столько крику про то, что контейнеры заменяют виртуализацию. Ложь. Девопсы не способны ничего сделать без бородатого дяденьки админа, который выделил им виртуалку и зарезал права везде, чтобы не лазили. А запускать софт на голом железе без виртуализации всё равно нужно. Виртуализация съедает производительность фактом своего существования. Причем на некоторых типах приложений так сильно, что их обязательно ставят только на железо. И вообще, я не понимаю, почему у тебя так адски бомбит от Windows? Мне кажется, что ты СТАЛ ЖЕРТВОЙ ПОДДЕЛКИ ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ MICROSOFT? Её политика обновлений настраивается на WSUS, а переустанавливать её нужно, только если у тебя полетел системный диск и нет резервной копии. Если ты не понимаешь, как с ней работать, попробуй ОБРАТИТЬСЯ К СИСТЕМНОМУ АДМИНИСТРАТОРУ.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (259), 09-Авг-23, 07:32
	Спасибо. Нет, серьезно. Если не сложно, можно прояснить тему одну. По поводу недостатков ограничений и прочего понятно. С частью сталкивался либо предполагал что там такие проблемы. И http.sys в своё время удивил в хорошем смысле. А что использовать то? Сейчас и в ближайшем будущем. Какие хранилища вменяемые, что на замену vsan и похожего можно смотреть, какие фс можно применить, что из виртуализации брать, что из контейнеризации вменяемое либо в теории допилят до вменяемого?
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от _ (??), 05-Авг-23, 18:12
	>Но увы, софт перестал быть простым, а бесконечного времени у тебя нет. Поэтому жрем чодали и стараемся держаться подальше от моднявых трендов на игого и с нескучными rest(fuck) апи. А мы вот любим "rest(fuck) апи" который реализуется игогой :)  Даже время появилось, хоть и не бесконечное. spoiler Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	96. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 18:43
	> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... к счастью нам не грозит уже. При мизерных ресурсах их выделяют чайной ложечкой вручную, чтоб ни одна капля не протекла мимо. А все эти сасы пасы в кривых руках менеджера - это даже не ведро, это труба двухметрового диаметра.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:40
	Нищий туземец, живущий впроголодь, не может понять, зачем белые люди в цивилизованных странах ездят на майбахах. Спойлер: им так нравится.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 12:14
	> Нищий туземец, живущий впроголодь, не может понять, зачем белые люди в цивилизованных > странах ездят на майбахах. > Спойлер: им так нравится. так ездит-то не туземец на службе у белых людей (наш '_') - в лучшем случае в багажнике. Ездят белые. Он им просто вместо ковровой дорожки к майбаху - траволатор стелит, чтоб их величества ножкой могли даже и не шевелить. На фсе деньги. Ну и действительно - дорого, красиво, им-так-нравится и KPI растет. А я как копался с другой стороны того же здания в затроившем движке того майбаха, по уши в масле и дерьме, так и копаюсь дальше (он тоже, но - теперь только в свободное от ремонта траволатора время). Только несколько огорчает что в новых сериях чтоб добраться до клапанов надо сначала снять двигатель, что еще бы пол-беды, но почему-то разборка начинается с откручивания левого переднего колеса, казалось бы нахрен не нужного в этом процессе.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (35), 07-Авг-23, 01:27
	Судя по вашим представлениям об информационных технологиях (явно отдающими совковым НИИ) - майбахи вы даже за километр не видели. Но, тем не менее, рассуждаете об их ненужности.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:55
	> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть. А вы случайно не тот легендарный персонаж, который постоянно пишет про то, что нельзя учить джунов, а то вырастут и работу отнимут?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	146. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:10
	>> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть. > А вы случайно не тот легендарный персонаж, который постоянно пишет про то, > что нельзя учить джунов, а то вырастут и работу отнимут? даааа, пилить нескучные апи на игогошечке - любой вайтишник с тремя классами образования осилит. (кстати, знаю такую историю успеха. Там не то чтобы совсем вайтишник, но прям совсем-совсем ничего общего с прошлой деятельностью и без в.о., кодить в гугле учился. Сбер-клауд, далее везде.) Правда, такую работу я бы с удовольствием им и отдал. Все равно когда навернется - за мной придут.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 11:30
	Знаете, такое ощущение, что за вами однажды действительно пришли. Дяди в белых халатах. И теперь вам приходится выходить в интернет тайком, чтобы доктор телефон не отобрал.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:54
	> Знаете, такое ощущение, что за вами однажды действительно пришли. знаете, такое ощущение что вы проецируете. И дядя в белом халате до вас вовремя не доехал, к большому сожалению. Иначе я ничем не могу объяснить идиотские комментарии под текстами, которые вы, очевидно, даже не понимаете.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (60), 05-Авг-23, 14:47
	>>Это я тебе, голуба, говорю как краевед Ты от ЧСВ там не лопнешь? Фамильярность вкупе с невежеством вещь жуткая.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	65. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 15:43
	выросло поколение дол..ов не узнающих цитату. Не, не лопну, глядя на таких вот- разьве что повесишься с тоски.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (110), 05-Авг-23, 20:18
	Строго говоря, она не такая уж и распространённая. С другой стороны, строго, опять же, говоря: по стилю вполне можно и заподозрить цитату. Сам так и сделал.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Всем Анонимам Аноним (?), 05-Авг-23, 13:19
	The jail utility appeared in FreeBSD 4.0.    Hierarchical/extensible    jails were introduced in    FreeBSD    8.0. FreeBSD 4. 4.0-RELEASE appeared in March 2000
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	66. "Создан форк системы управления контейнерами LXD"	–4 +/–
	Сообщение от пох. (?), 05-Авг-23, 15:49
	узнаем, узнаем экспертов опеннета, которым приходится цитировать history. Должон тебя разочаровать - тем которое появилось в 4.0 ты и подобные тебе пользоваться бы не сумели - просто ни один привычный параметр не подходит. Оно было для совсем другой цели - для той самой, где S in Docker stands for. Оно не создавало странный аналог виртуальной машины, а просто изолировало от системы ровно настолько, насколько тебе в конкретном случае казалось уместным и без лишних трудозатрат. И увы, история доказала что это был в целом кривой и совсем г-енный подход (потому что опять вместо решения проблемы ее обмотали изоленточкой).
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Neon (??), 06-Авг-23, 23:33
	Майнфреймы бородатых годов (70х) вполне тянули виртуализацию. Порой там гипервизор гипервизором погонял.)))
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема