Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Проблема может быть и существует. Но кто вам мешает подправить ядро и написать как надо? Вы вполне можете решить проблему сами.
Просто разоблачение ядра Linux.
Всё пойду форматировать сервера linux, правда как теперь жить с этим багом :(
Взял бы да исправил, раз добрался до этой ошибки…
Всё пойду форматировать сервера linux, правда как теперь жить с этим багом :(
Взял бы да исправил, раз добрался до этой ошибки…
>Баг открыт в августе 2010 года, относится к ядру версии 2.5.
2.6.35?
2.6.35?
Вы молодец, умеете читать багзиллу.
Суть то поста в чем?
Ошибка программиста — не проблема архитектуры и платформы.
Суть то поста в чем?
Ошибка программиста — не проблема архитектуры и платформы.
Конечно нет. Новая найденная 64-битная ошибка не проблема архитектуры и платформы. Это проблема восприятия мира. Люди упорно не хотят осознавать, что факт, что 64-битному Linux много лет, вовсе не эквивалентен надежности 64-битного Linux уже много лет.
P.S. Ох сейчас меня линуксойды минусовать здесь будут! Я богохульствую о их священном золотом пингвине. :)
P.S. Ох сейчас меня линуксойды минусовать здесь будут! Я богохульствую о их священном золотом пингвине. :)
А кто об этом говорит? Видимо сарказм автора вам не понятен или вы топик невнимательно читали.
И что? Я тут недавно родил код, который работает на amd64 системах и сегфолтится на 32х битных.
интересно было бы посмотреть на приложение, написанное так, что посылает в сеть больше 4Гб за раз… send блокирующая функция и thread будет замирать на часы (в зависимости от скорости сети).
Любую синхронную функцию можно запихнуть в асинхронную оболочку и наоборот.
send блокирующая функция
Не всегда. Зависит от сокета — он может быть как блокирующим, так и неблокирующим. Также сокет используется не только для взаимодействия с сетью вида кампутер-модем-интернет-модем-кампутер, но и для межпроцессных взаимодействий внутри одного компьютера :).
Ну вбросил, так вбросил :)
Только Хабр тут причем?
Ну есть такая ошибка, есть она в багзилле, починят. Если не хотите ждать, сами почините, раз уж лезете разбираться.
Нет, только криков и махания руками тут не хватало.
Возможно проблема не на столько критична, как вы тут хотите ее представить.
А про то что готова или нет, вопрос решенный. И где пруфы, что проблем нет? Если человек работает с системой и говорит, что нет проблем с прикладным софтом на этой платформе, то это так и нужно воспринимать. А не так, что система на 100% идеальна.
Тут у вас с восприятием проблема. Нечего на других пенять.
Вы бы еще баги с 32-разрядностью повыискивали, а потом кричали на каждом углу, что Линукс не готов к 32-бит. Смешно же слушать.
Только Хабр тут причем?
Ну есть такая ошибка, есть она в багзилле, починят. Если не хотите ждать, сами почините, раз уж лезете разбираться.
Нет, только криков и махания руками тут не хватало.
Возможно проблема не на столько критична, как вы тут хотите ее представить.
А про то что готова или нет, вопрос решенный. И где пруфы, что проблем нет? Если человек работает с системой и говорит, что нет проблем с прикладным софтом на этой платформе, то это так и нужно воспринимать. А не так, что система на 100% идеальна.
Тут у вас с восприятием проблема. Нечего на других пенять.
Вы бы еще баги с 32-разрядностью повыискивали, а потом кричали на каждом углу, что Линукс не готов к 32-бит. Смешно же слушать.
>> а разве компилятор не должен ругаться на присвоение size_t к int?
Должен, конечно. И ругается. Полагаю в том случае проблема в большом количестве warnings, из-за которых важный «просмотрели».
>> что только не выдумывают чтобы не использовать size_t: int, DWORD, uLongf… убил бы:)
Тех ребят тоже можно понять. В дискуссии по багу приводятся аргументы в пользу того, почему нельзя просто взять и поменять на size_t.
Должен, конечно. И ругается. Полагаю в том случае проблема в большом количестве warnings, из-за которых важный «просмотрели».
>> что только не выдумывают чтобы не использовать size_t: int, DWORD, uLongf… убил бы:)
Тех ребят тоже можно понять. В дискуссии по багу приводятся аргументы в пользу того, почему нельзя просто взять и поменять на size_t.
Как я понял, там основной аргумент в том, что править слишком много придётся и не тольок в этой функции. А делать это и проверять никому не хочется.
Правильно, только не то чтобы не хочется, а сложно убедиться в отсутсвии проблем. То есть так как есть сейчас — проблема ясна и понятна. А если «тупо» на size_t поменять, то проблема полностью не уйдет, а спрячется глубже в коде.
Конечно не хочется. Это ведь не как выше сказали «Взял бы да исправил, раз добрался до этой ошибки…» и пойти дальше спокойно хабр читать… :)
Для того, чтобы такой ситуации не было, существует и успешно применяется -WError. После него ваши волосы будут гладкими и шелковистыми. Хотя поначалу может захотеться их повырывать. Сие заклинание лучше всего применять на начальном этапе разработки совмещая его с -WAll, -WExtra и далее по вкусу.
А он и ругается. Просто в больших проектах на warning мало обращают внимания или они на низком уровне выставлены. Подобное урезание типа кстати вполне обычное дело: Problems of 64-bit code in real programs: FreeBSD.
Спасибо что заглянули в багзиллу ядра Linux. Плохо, что верите всему, что написано и не проверяете факты самостоятельно (например, про версию 2.5, которая уже давным-давно не разрабатывается).
Баг-репорт от августа 2010! Это давным-давно?
Ядро 2.5 давно не разрабатывается. Если в багзилле в поле «версия» написана ерунда, то это совершенно другой вопрос. Вы ещё раз показываете, что не в теме разработки ядра Linux и не хотите даже зайти на Википедию [1] и посмотреть красивую картинку.
[1] en.wikipedia.org/wiki/Linux_kernel#Development
[1] en.wikipedia.org/wiki/Linux_kernel#Development
www.theregister.co.uk/2010/09/15/linux_kernel_regression_bug/
SECURITY (EoP) баг 2007-го года с рабочим эксплоитом, как раз таки связанный с x64 исправили в 2010-м. Good job
SECURITY (EoP) баг 2007-го года с рабочим эксплоитом, как раз таки связанный с x64 исправили в 2010-м. Good job
Ах, да небольшая заметка на тему реакции «сообщества». LinuxIsPerfect™, apparently
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы 64-битного кода в реальных программах: а что же Linux?