| |
| 2.3, Аноним (3), 09:54, 14/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
А чего там восстанавливать? Только с видеокартами были сложности. Лучше расскажи, какое практическое применение есть? Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление.
| | |
| |
| 3.7, Жироватт (ok), 10:29, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
 На старых версия не всегда корректно работал с большим количеством JNI-вызовов, ведь должны захватываться и они.
> Лучше расскажи, какое практическое применение есть?
Рендер, расчеты.
На билдферме может выполняться сборочный процесс.
Иногда просто нежелательно тушить процесс
| | |
|
|
| 1.4, Шарп (ok), 09:54, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 >без разрыва уже установленных сетевых соединений
Это невозможно. Другая сторона в сетевом соединении увидит разрыв. Если есть данные прикреплённые к сессии, то они сбросятся.
| | |
| |
| 2.6, Аноним (3), 10:18, 14/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Другая сторона только отвалится по таймауту. Если не успеет, то всё будет как будто у нас тут небольшой свопинг приключился.
| | |
| 2.9, Аноним (9), 10:33, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Там специальные подпорки в ядре, позволяющие реконструировать внутреннее состояние сокета без использования вызовов сокетного апи, поэтому сокет будет восстановлен точно в том же состоянии, и если удалённая сторона не затаймаутилась - то она ничего не заметит, закрытия сокета и посылки FIN не происходит, а после разморозки трафик едет дальше, как ни в чём не бывало.
| | |
| |
| 3.13, Аноним (13), 12:16, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> после разморозки трафик едет дальше, как ни в чём не бывало.
даже через неделю?
| | |
| |
| 4.15, Аноним (16), 12:28, 14/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Через неделю-то тайаут произойдёт. Но если только та сторона тоже решила заморозиться, то и через месяц.
| | |
|
|
|
| 1.5, trolleybus (?), 09:59, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
> Устранено целочисленное переполнение в функции pagemap_len()
А вот это типично сишная проблема. Многие тупо не парятся и везде пишут int, когда даже стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent. Про знаковые/беззнаковые вообще молчу. А использовать всякие uint32_t не хотим, это ненужное ненужно.
Даже в расте такой номер не пройдет, если только специально не поиздеваться.
| | |
| |
| 2.8, Пыщь (?), 10:32, 14/11/2025 [^] [^^] [^^^] [ответить]
| +4 +/– |
Понравилась цитата защищавшего расто-операторов, суну сюда: "Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания и удовольствие."
| | |
| 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 [^] [^^] [^^^] [ответить]
| +2 +/– |
> И теперь usize::MAX + 1 не приведет к переполнению, да-да-да. Вот откуда
> вы лезете?
Если что-то может переполниться, в Rust можно явно это обрабатывать через checked_add/saturating_add/strict_add/wrapping_add/overflowing_add, а не делать проверки вида a + b < a и надеяться что компилятор тут поймёт что это проверка на переполнение, а не UB (Потому что по стандарту это UB)
| | |
| 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).
| | |
|
|
| 1.19, Аноним (19), 14:52, 14/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Когда сделают live миграцию LXC контейнеров в Proxmox VE как это было ранее когда были OpenVZ контейнеры?
| | |
|
