Pull to refresh

Comments 37

UFO just landed and posted this here
Ну тык ведь Linux! Вот как в Windows или в программах под нее что-то находится, то криков… И ущербная ОС скажут, и пожелают, чтобы она быстрее загнулась, и что переходите на другую ОС. А Linux священное животное и о нем плохое писать нельзя. :)
UFO just landed and posted this here
Проблема может быть и существует. Но кто вам мешает подправить ядро и написать как надо? Вы вполне можете решить проблему сами.
Ох уж этот Linux с напильником… :)
Ну ну, а в винде вы вообще ничего(по этой теме) исправить не можете — что лучше?
Просто разоблачение ядра Linux.
Всё пойду форматировать сервера linux, правда как теперь жить с этим багом :(

Взял бы да исправил, раз добрался до этой ошибки…
>Баг открыт в августе 2010 года, относится к ядру версии 2.5.

2.6.35?
Вы молодец, умеете читать багзиллу.
Суть то поста в чем?
Ошибка программиста — не проблема архитектуры и платформы.
Конечно нет. Новая найденная 64-битная ошибка не проблема архитектуры и платформы. Это проблема восприятия мира. Люди упорно не хотят осознавать, что факт, что 64-битному Linux много лет, вовсе не эквивалентен надежности 64-битного Linux уже много лет.

P.S. Ох сейчас меня линуксойды минусовать здесь будут! Я богохульствую о их священном золотом пингвине. :)
По-моему вы просто бред несёте.
А кто об этом говорит? Видимо сарказм автора вам не понятен или вы топик невнимательно читали.
Да его тут кажется мало кто читал. Увидели рядом слова «Linux» и «ошибка». И давай писать комментарии. :)
Сарказм автора в виде «Надоели фанатики, пойду найду первую попавшуюся проблему с 64битами в линуксе и докажу им!» мне не понятен, да.
И что? Я тут недавно родил код, который работает на amd64 системах и сегфолтится на 32х битных.
Ды крик души это у человека был. Достали уже линкусойды-фанаты, c остекленевшими глазами зачитывающие мантру, что Linux священен и в отличии от Windows там с 64-битностью уже давно все как хорошо и отлажено. Да и тут они уже отметились. По голосам видно.
По-моему это нечто другое. Прищемить себе яйца дверью можно и в 32битном коде. Но факт говорит о том, что pure amd64 сборку Линукса без multilib'а можно сделать и она даже в целом будет жизнеспособна, а Виндовс нет.
интересно было бы посмотреть на приложение, написанное так, что посылает в сеть больше 4Гб за раз… send блокирующая функция и thread будет замирать на часы (в зависимости от скорости сети).
Любую синхронную функцию можно запихнуть в асинхронную оболочку и наоборот.
send блокирующая функция


Не всегда. Зависит от сокета — он может быть как блокирующим, так и неблокирующим. Также сокет используется не только для взаимодействия с сетью вида кампутер-модем-интернет-модем-кампутер, но и для межпроцессных взаимодействий внутри одного компьютера :).
Ну вбросил, так вбросил :)
Только Хабр тут причем?
Ну есть такая ошибка, есть она в багзилле, починят. Если не хотите ждать, сами почините, раз уж лезете разбираться.
Нет, только криков и махания руками тут не хватало.
Возможно проблема не на столько критична, как вы тут хотите ее представить.
А про то что готова или нет, вопрос решенный. И где пруфы, что проблем нет? Если человек работает с системой и говорит, что нет проблем с прикладным софтом на этой платформе, то это так и нужно воспринимать. А не так, что система на 100% идеальна.
Тут у вас с восприятием проблема. Нечего на других пенять.
Вы бы еще баги с 32-разрядностью повыискивали, а потом кричали на каждом углу, что Линукс не готов к 32-бит. Смешно же слушать.
UFO just landed and posted this here
>> а разве компилятор не должен ругаться на присвоение size_t к int?

Должен, конечно. И ругается. Полагаю в том случае проблема в большом количестве warnings, из-за которых важный «просмотрели».

>> что только не выдумывают чтобы не использовать size_t: int, DWORD, uLongf… убил бы:)

Тех ребят тоже можно понять. В дискуссии по багу приводятся аргументы в пользу того, почему нельзя просто взять и поменять на size_t.

Как я понял, там основной аргумент в том, что править слишком много придётся и не тольок в этой функции. А делать это и проверять никому не хочется.
Правильно, только не то чтобы не хочется, а сложно убедиться в отсутсвии проблем. То есть так как есть сейчас — проблема ясна и понятна. А если «тупо» на size_t поменять, то проблема полностью не уйдет, а спрячется глубже в коде.
Конечно не хочется. Это ведь не как выше сказали «Взял бы да исправил, раз добрался до этой ошибки…» и пойти дальше спокойно хабр читать… :)
Для того, чтобы такой ситуации не было, существует и успешно применяется -WError. После него ваши волосы будут гладкими и шелковистыми. Хотя поначалу может захотеться их повырывать. Сие заклинание лучше всего применять на начальном этапе разработки совмещая его с -WAll, -WExtra и далее по вкусу.
А он и ругается. Просто в больших проектах на warning мало обращают внимания или они на низком уровне выставлены. Подобное урезание типа кстати вполне обычное дело: Problems of 64-bit code in real programs: FreeBSD.
UFO just landed and posted this here
Мир Си++ программистов суров и странен. :)
По-моему варнинги не нужны, они сбивают с толку, я в этом вопросе полностью на стороне разработчиков D, поэтому ставлю -WError везде, где могу дотянутся
OpenSSL — это маленький проект. Ну в смысле не большой :-).
Спасибо что заглянули в багзиллу ядра Linux. Плохо, что верите всему, что написано и не проверяете факты самостоятельно (например, про версию 2.5, которая уже давным-давно не разрабатывается).
Баг-репорт от августа 2010! Это давным-давно?
Ядро 2.5 давно не разрабатывается. Если в багзилле в поле «версия» написана ерунда, то это совершенно другой вопрос. Вы ещё раз показываете, что не в теме разработки ядра Linux и не хотите даже зайти на Википедию [1] и посмотреть красивую картинку.

[1] en.wikipedia.org/wiki/Linux_kernel#Development
Sign up to leave a comment.

Articles