| |
| |
| |
| 4.27, Xenia Joness (ok), 19:43, 14/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > продуктовой (с) тех-лид ВТБ
> В проде (с) тех-лид Сбера
Продолжу дальше:
В проде (с) тех лид Гугла
В проде (с) тех лид Мелкософта
В проде (с) тех лид НАСА
В проде (с) тех лид "Рога и копыта"
| | |
|
|
|
| |
| 2.3, Аноним (3), 09:54, 14/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
А чего там восстанавливать? Только с видеокартами были сложности. Лучше расскажи, какое практическое применение есть? Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление.
| | |
| |
| 3.7, Жироватт (ok), 10:29, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
 На старых версия не всегда корректно работал с большим количеством JNI-вызовов, ведь должны захватываться и они.
> Лучше расскажи, какое практическое применение есть?
Рендер, расчеты.
На билдферме может выполняться сборочный процесс.
Иногда просто нежелательно тушить процесс
| | |
| 3.30, Lamerok (?), 03:24, 15/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
ты же тот самый техлид выше? и не знаешь применения для этой технологии?! ну тогда я рассказывать точно небуду)
| | |
| 3.32, Аноним (-), 05:38, 15/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление.
Перенос процесса на другую машину, потому что эта барахлит.
| | |
| 3.33, Аноним (33), 12:37, 15/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Какое практическое применение есть?
Чтоб можно было реализовать восстановление игр без повторного запуска, как на консолях
| | |
|
|
| 1.4, Шарп (ok), 09:54, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 >без разрыва уже установленных сетевых соединений
Это невозможно. Другая сторона в сетевом соединении увидит разрыв. Если есть данные прикреплённые к сессии, то они сбросятся.
| | |
| |
| 2.6, Аноним (3), 10:18, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Другая сторона только отвалится по таймауту. Если не успеет, то всё будет как будто у нас тут небольшой свопинг приключился.
| | |
| 2.9, Аноним (9), 10:33, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Там специальные подпорки в ядре, позволяющие реконструировать внутреннее состояние сокета без использования вызовов сокетного апи, поэтому сокет будет восстановлен точно в том же состоянии, и если удалённая сторона не затаймаутилась - то она ничего не заметит, закрытия сокета и посылки FIN не происходит, а после разморозки трафик едет дальше, как ни в чём не бывало.
| | |
| |
| 3.13, Аноним (13), 12:16, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> после разморозки трафик едет дальше, как ни в чём не бывало.
даже через неделю?
| | |
| |
| 4.15, Аноним (16), 12:28, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Через неделю-то тайаут произойдёт. Но если только та сторона тоже решила заморозиться, то и через месяц.
| | |
| 4.25, Аноним (25), 18:50, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хоть через год, если настроишь тайм-ауты на обеих сторонах. Компьютеру без разницы.
| | |
|
|
| 2.31, Аноним (-), 05:35, 15/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Это невозможно. Другая сторона в сетевом соединении увидит разрыв.
Да ладно? Что действительно невозможно скрыть факт перезагрузки? /s
До тех пор, пока ты (или что-то там ниже по сетевому стеку) не отправил другой стороне сообщения о том, что ты разрываешь соединение, другая сторона ничего не заподозрит. Единственное, что может выдать Штирлица -- это таймаут: если ты долго не будешь отправлять ACK пакеты в ответ на принятые оттуда, то сетевой стек на той стороне решит, что соединение оборвалось.
Единственное что в этом мне интересно, как они перезагружают, не теряя пакетов. Полагаются на способности сетевой карты буферизировать, и быстро-быстро подменяют ядро и инициализируют новое, пока буферы не переполнились?
Впрочем, несколько потерянных пакетов, наверное, не так важно, соединение потупит немного, но со временем вернётся в норму.
| | |
|
| 1.5, trolleybus (?), 09:59, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
> Устранено целочисленное переполнение в функции pagemap_len()
А вот это типично сишная проблема. Многие тупо не парятся и везде пишут int, когда даже стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent. Про знаковые/беззнаковые вообще молчу. А использовать всякие uint32_t не хотим, это ненужное ненужно.
Даже в расте такой номер не пройдет, если только специально не поиздеваться.
| | |
| |
| 2.8, Пыщь (?), 10:32, 14/11/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
Понравилась цитата защищавшего расто-операторов, суну сюда: "Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания и удовольствие."
| | |
| 2.11, Медведь (ok), 11:43, 14/11/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > А вот это типично сишная проблема.
Бред сивой кобылы. Такое возможно в любом ЯП, где целые занимают фиксированный размер в памяти. Ржа тоже вполне себе подвержена ошибкам из-за выхода за допустимый диапазон значений.
Забавно, ржавозависимые при каждом баге в растокоде упрекают всех, что от их драгоценной ржи требуют чего-то, чего ржа не обещала, но сами не могут определиться с тем, чего же она все-таки обещала ;)
| | |
| |
| 3.14, morphe (?), 12:21, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ржавчина использует для подобных вещей везде isize/usize, и не позволяет неявных конверсий между ним и int
В то время как в сишке для совместимости везде int и грабли
| | |
| |
| 4.18, Медведь (ok), 13:25, 14/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
И теперь usize::MAX + 1 не приведет к переполнению, да-да-да. Вот откуда вы лезете?
| | |
| |
| 5.22, morphe (?), 15:40, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
> И теперь usize::MAX + 1 не приведет к переполнению, да-да-да. Вот откуда
> вы лезете?
Если что-то может переполниться, в Rust можно явно это обрабатывать через checked_add/saturating_add/strict_add/wrapping_add/overflowing_add, а не делать проверки вида a + b < a и надеяться что компилятор тут поймёт что это проверка на переполнение, а не UB (Потому что по стандарту это UB)
| | |
| |
| 6.28, _ (??), 22:12, 14/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Если что-то может переполниться, в Rust можно явно это обрабатывать через checked_add/saturating_add/strict_add/wrapping_add/overflowing_add,
Ыыыы :) А такое-же в Си сделать по твоему - технически не возможно, да? ;)))))))
| | |
|
| 5.23, trolleybus (?), 15:53, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> И теперь usize::MAX + 1 не приведет к переполнению, да-да-да
Штука в том, что в расте тоже можно много чего натворить, но только если ты этого очень сильно захочешь. А в сишке ты можешь натворить, даже если очень не хочешь.
| | |
|
|
|
| 2.20, Медведь (ok), 15:15, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent
В рже, внезапно, размер usize и isize тоже зависит от архитектуры. Сюрприз!
| | |
| |
| 3.24, trolleybus (?), 16:00, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Так это и документировано. На 32 битах - 32 бита, на 64 - 64. И никаких сюрпризофф.
А в сишке внезапно в одной и той же архитектуре может в разных ABI отличаться (например, размер лонга на линуксе 64 бита, на винде 32).
| | |
| |
| 4.26, Аноним (3), 19:21, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это пока майкрософт и прочие не написали свой компилятор раста для 128 битных процессоров. Ну хотя у раста нет ABI, думать об этом и не придётся.
| | |
|
|
|
| 1.19, Аноним (19), 14:52, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Когда сделают live миграцию LXC контейнеров в Proxmox VE как это было ранее когда были OpenVZ контейнеры?
| | |
| 1.29, Аноним (29), 00:26, 15/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Просто criu писали виртуоззники, у них под миграцию контейнеров между хостами все было заточено, так как виртуозза для хостеров и их shamand автоматом мигрировал контейнеры с проблемных хостов. В комплекте с виртуоззо сторадж это была довольно удобная вещь. Проксмокс скорее про небольшие внедрения, и фича эта была в нем просто из комплекта от openvz, чего видимо в lxc не доделали, потому что похоже коммерческого интереса хостить на lxc клиентов особо нет. Виртуозза к сожалению помирает, 7 версия была ох как давно, а 9я нововыпущенная - это совсем другой продукт, и даже без контейнеров вовсе. Но с другой стороны щас всем куб подавай.
| | |
|
