Comments 37
UFO just landed and posted this here
Проблема может быть и существует. Но кто вам мешает подправить ядро и написать как надо? Вы вполне можете решить проблему сами.
+7
Просто разоблачение ядра Linux.
Всё пойду форматировать сервера linux, правда как теперь жить с этим багом :(
Взял бы да исправил, раз добрался до этой ошибки…
Всё пойду форматировать сервера linux, правда как теперь жить с этим багом :(
Взял бы да исправил, раз добрался до этой ошибки…
+12
>Баг открыт в августе 2010 года, относится к ядру версии 2.5.
2.6.35?
2.6.35?
+4
Вы молодец, умеете читать багзиллу.
Суть то поста в чем?
Ошибка программиста — не проблема архитектуры и платформы.
Суть то поста в чем?
Ошибка программиста — не проблема архитектуры и платформы.
+6
Конечно нет. Новая найденная 64-битная ошибка не проблема архитектуры и платформы. Это проблема восприятия мира. Люди упорно не хотят осознавать, что факт, что 64-битному Linux много лет, вовсе не эквивалентен надежности 64-битного Linux уже много лет.
P.S. Ох сейчас меня линуксойды минусовать здесь будут! Я богохульствую о их священном золотом пингвине. :)
P.S. Ох сейчас меня линуксойды минусовать здесь будут! Я богохульствую о их священном золотом пингвине. :)
-1
А кто об этом говорит? Видимо сарказм автора вам не понятен или вы топик невнимательно читали.
0
И что? Я тут недавно родил код, который работает на amd64 системах и сегфолтится на 32х битных.
+1
Ды крик души это у человека был. Достали уже линкусойды-фанаты, c остекленевшими глазами зачитывающие мантру, что Linux священен и в отличии от Windows там с 64-битностью уже давно все как хорошо и отлажено. Да и тут они уже отметились. По голосам видно.
0
интересно было бы посмотреть на приложение, написанное так, что посылает в сеть больше 4Гб за раз… send блокирующая функция и thread будет замирать на часы (в зависимости от скорости сети).
+1
Любую синхронную функцию можно запихнуть в асинхронную оболочку и наоборот.
+1
send блокирующая функция
Не всегда. Зависит от сокета — он может быть как блокирующим, так и неблокирующим. Также сокет используется не только для взаимодействия с сетью вида кампутер-модем-интернет-модем-кампутер, но и для межпроцессных взаимодействий внутри одного компьютера :).
+2
Ну вбросил, так вбросил :)
Только Хабр тут причем?
Ну есть такая ошибка, есть она в багзилле, починят. Если не хотите ждать, сами почините, раз уж лезете разбираться.
Нет, только криков и махания руками тут не хватало.
Возможно проблема не на столько критична, как вы тут хотите ее представить.
А про то что готова или нет, вопрос решенный. И где пруфы, что проблем нет? Если человек работает с системой и говорит, что нет проблем с прикладным софтом на этой платформе, то это так и нужно воспринимать. А не так, что система на 100% идеальна.
Тут у вас с восприятием проблема. Нечего на других пенять.
Вы бы еще баги с 32-разрядностью повыискивали, а потом кричали на каждом углу, что Линукс не готов к 32-бит. Смешно же слушать.
Только Хабр тут причем?
Ну есть такая ошибка, есть она в багзилле, починят. Если не хотите ждать, сами почините, раз уж лезете разбираться.
Нет, только криков и махания руками тут не хватало.
Возможно проблема не на столько критична, как вы тут хотите ее представить.
А про то что готова или нет, вопрос решенный. И где пруфы, что проблем нет? Если человек работает с системой и говорит, что нет проблем с прикладным софтом на этой платформе, то это так и нужно воспринимать. А не так, что система на 100% идеальна.
Тут у вас с восприятием проблема. Нечего на других пенять.
Вы бы еще баги с 32-разрядностью повыискивали, а потом кричали на каждом углу, что Линукс не готов к 32-бит. Смешно же слушать.
+3
UFO just landed and posted this here
>> а разве компилятор не должен ругаться на присвоение size_t к int?
Должен, конечно. И ругается. Полагаю в том случае проблема в большом количестве warnings, из-за которых важный «просмотрели».
>> что только не выдумывают чтобы не использовать size_t: int, DWORD, uLongf… убил бы:)
Тех ребят тоже можно понять. В дискуссии по багу приводятся аргументы в пользу того, почему нельзя просто взять и поменять на size_t.
Должен, конечно. И ругается. Полагаю в том случае проблема в большом количестве warnings, из-за которых важный «просмотрели».
>> что только не выдумывают чтобы не использовать size_t: int, DWORD, uLongf… убил бы:)
Тех ребят тоже можно понять. В дискуссии по багу приводятся аргументы в пользу того, почему нельзя просто взять и поменять на size_t.
+2
Как я понял, там основной аргумент в том, что править слишком много придётся и не тольок в этой функции. А делать это и проверять никому не хочется.
0
Правильно, только не то чтобы не хочется, а сложно убедиться в отсутсвии проблем. То есть так как есть сейчас — проблема ясна и понятна. А если «тупо» на size_t поменять, то проблема полностью не уйдет, а спрячется глубже в коде.
0
Конечно не хочется. Это ведь не как выше сказали «Взял бы да исправил, раз добрался до этой ошибки…» и пойти дальше спокойно хабр читать… :)
-3
Для того, чтобы такой ситуации не было, существует и успешно применяется -WError. После него ваши волосы будут гладкими и шелковистыми. Хотя поначалу может захотеться их повырывать. Сие заклинание лучше всего применять на начальном этапе разработки совмещая его с -WAll, -WExtra и далее по вкусу.
+1
А он и ругается. Просто в больших проектах на warning мало обращают внимания или они на низком уровне выставлены. Подобное урезание типа кстати вполне обычное дело: Problems of 64-bit code in real programs: FreeBSD.
0
Спасибо что заглянули в багзиллу ядра Linux. Плохо, что верите всему, что написано и не проверяете факты самостоятельно (например, про версию 2.5, которая уже давным-давно не разрабатывается).
+1
Баг-репорт от августа 2010! Это давным-давно?
0
Ядро 2.5 давно не разрабатывается. Если в багзилле в поле «версия» написана ерунда, то это совершенно другой вопрос. Вы ещё раз показываете, что не в теме разработки ядра Linux и не хотите даже зайти на Википедию [1] и посмотреть красивую картинку.
[1] en.wikipedia.org/wiki/Linux_kernel#Development
[1] en.wikipedia.org/wiki/Linux_kernel#Development
+1
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
-2
Ах, да небольшая заметка на тему реакции «сообщества». LinuxIsPerfect™, apparently
-2
Sign up to leave a comment.
Проблемы 64-битного кода в реальных программах: а что же Linux?