Ссылка с методиками взлома контейнера для меня выглядит высосанной из пальца. Может я что не понимаю, но для доступа к openssl уже должна быть RCE в приложении или утечка доступа к exec контейнера - как при таких проблемах сможет помочь способ сборки image. На этот момент песенка уже спета, разве нет? Все что можно сделать - усложнить поиск payload, что и делает distroless подход
Эх, а администрация хабра то и не подозревает. Им не до этого, они трекер чинят 24/7. Вот бы кто им сообщил. Надо позвонить на горячую линию или письмо написать, пусть выпустят указ какой.
В общем, все ваши пиринговые хостинги красивые, но спасибо, не надо.
С Filecoin понятно, спасибо за обзор. Но зачем на все остальные проекты экстраполировать? С тем же Storj что вы упоминаете вскользь вроде бы все более-менее нормально
Как вы себе представляете вообще ходить между вкладками/папками кнопкой для удаления последнего символа. Особенно в местах, где может быть input и случайные нажатия.
Полностью согласен с вами. Ничего не имею против go и rust, выбор между ними зависит от ТЗ и ресурсов. Но мне отвратительно видеть в тексте про "Ошибки, которые не ловит rust" текст, который должен был называться "Ошибки, которые не ловит go, но ловит rust". Заголовок и подача отдают запашком пропаганды, которая меня дико раздражает
Сразу учуял что автор по стелсу хейтит go. Нужно было больше примеров глупых ошибок.
Про js не к месту в начале только для легитимности сравнения добавил. Про go race детектор забыл. То что тип нуля int, а не выводится - плохо, но чую был бы это rust - это было бы очередное явное лучше неявного. То что в go основная модель разделения данных между потоками через каналы, а не мутексы, поэтому они и минималистичные - упоминать не будем. То что есть sync.Map - нет. То что в 1.18 есть библиотека constraints, чтобы не перечислять все типы - нет. Вообще вся статья будто эксперимент "если обезьяне дать две бомбы, какая взорвется быстрее?", что имеет мало общего с работой программиста.
В общем чел долго изучал теорию rust чтобы писать безопасный код. ЗП оказалась такая же что и у golang. Про безопасность спросили разок на атомной электростанции, оказалось что все остальные перезапускают упавшие контейнеры. Вот у него от грусти и включилась пропаганда. Другого объяснения этому странному сравнению желтого с коричневым объяснить я не могу
Там вроде удаляют реализации memcpy и аналоги ускоренные с помощью 3dnow внутри ядра. Я так понял инструкции в userspace продолжат работать. В коммите есть описание проблемы что не захотели фиксить https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=c6dbd3e5e69cf3ca47a3864115d4cbdd44619243 Есть разница между "dropping of the AMD 3DNow! code within the kernel." и "прекратилась поддержка SIMD-набора инструкций 3DNow! для процессоров AMD", так что спасибо переводчику
GPT-4 (кстати, материал о новой языковой модели можно прочитать здесь)
Ссылка с методиками взлома контейнера для меня выглядит высосанной из пальца. Может я что не понимаю, но для доступа к openssl уже должна быть RCE в приложении или утечка доступа к exec контейнера - как при таких проблемах сможет помочь способ сборки image. На этот момент песенка уже спета, разве нет? Все что можно сделать - усложнить поиск payload, что и делает distroless подход
Эх, а администрация хабра то и не подозревает. Им не до этого, они трекер чинят 24/7. Вот бы кто им сообщил. Надо позвонить на горячую линию или письмо написать, пусть выпустят указ какой.
Такие вещи около университетов вижу заметно реже, чем в среднем по больнице
Первое апреля? Правда смешно! Особенно когда увидел что это в хабах "Совершенный код" и "Клиентская оптимизация"
Интересно, может кто знает, в хроме для "правильных" сайтов есть исключения?
С Filecoin понятно, спасибо за обзор. Но зачем на все остальные проекты экстраполировать? С тем же Storj что вы упоминаете вскользь вроде бы все более-менее нормально
Самое важное забыли
i3 US$812.00
i7 US$1,167.00
ну и по хорошему эти префиксы должны быть в стандартной либе, чтобы наверняка
Ох уж эти бессердечные манагеры Google, так и пытаются род человеческий стереть с лица земли.
XP: https://forums.tomshardware.com/threads/shortcut-key-for-back-in-windows-explorer.1007268/
IE6: http://www.keyxl.com/aaa29c1/29/Microsoft-Internet-Explorer-6-Browser-keyboard-shortcuts.htm
Windows 95/98: https://www.oocities.org/emgares/articles/001.html (They work in windows generated by the Windows Explorer, including those generated from My PC and the Internet Explorer)
Как вы себе представляете вообще ходить между вкладками/папками кнопкой для удаления последнего символа. Особенно в местах, где может быть input и случайные нажатия.
Интересно какие аргументы они использовали. "Может ли написать симфонию?"
alt+left, alt+right логичнее и поддерживаются более повсеместно (windows explorer, slack, vscode)
США не рассматривается как военная угроза цивилизованным странам в отличии от РФ
А что там делать? Это хотя бы role-play? А сам макрон туда зайдет? Глупая акция действительно, но факт попытки похвалить можно
Полностью согласен с вами. Ничего не имею против go и rust, выбор между ними зависит от ТЗ и ресурсов. Но мне отвратительно видеть в тексте про "Ошибки, которые не ловит rust" текст, который должен был называться "Ошибки, которые не ловит go, но ловит rust". Заголовок и подача отдают запашком пропаганды, которая меня дико раздражает
Сразу учуял что автор по стелсу хейтит go. Нужно было больше примеров глупых ошибок.
Про js не к месту в начале только для легитимности сравнения добавил. Про go race детектор забыл. То что тип нуля int, а не выводится - плохо, но чую был бы это rust - это было бы очередное явное лучше неявного. То что в go основная модель разделения данных между потоками через каналы, а не мутексы, поэтому они и минималистичные - упоминать не будем. То что есть sync.Map - нет. То что в 1.18 есть библиотека constraints, чтобы не перечислять все типы - нет. Вообще вся статья будто эксперимент "если обезьяне дать две бомбы, какая взорвется быстрее?", что имеет мало общего с работой программиста.
В общем чел долго изучал теорию rust чтобы писать безопасный код. ЗП оказалась такая же что и у golang. Про безопасность спросили разок на атомной электростанции, оказалось что все остальные перезапускают упавшие контейнеры. Вот у него от грусти и включилась пропаганда. Другого объяснения этому странному сравнению желтого с коричневым объяснить я не могу
Согласен, runtime.LockOsThread мог бы помочь.
Тут было много текста, но я его удалил, т.к. понял что написал херню
Метка перевода и ссылка на оригинал в сделку не входили
Там вроде удаляют реализации memcpy и аналоги ускоренные с помощью 3dnow внутри ядра. Я так понял инструкции в userspace продолжат работать.
В коммите есть описание проблемы что не захотели фиксить https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=c6dbd3e5e69cf3ca47a3864115d4cbdd44619243
Есть разница между "dropping of the AMD 3DNow! code within the kernel." и "прекратилась поддержка SIMD-набора инструкций 3DNow! для процессоров AMD", так что спасибо переводчику
Этому человеку нельзя верить