Множественные уязвимости в Xorg-server

у меня вопрос к джава-кулпрограммерам, с предложениями переписпть код на этот язык: народ, вы кроме джавы знаете чего другое? си с плюсами, к примеру? задавались вопросом, почему дрова на джава не пишут?

Да успокойтесь вы, товарисч просто пошутил в контексте обсуждения из соседней новости про GPL жабу.

gentoo-sources-2.6.25-r5

ati-drivers-8.501

ВСЕ РАБОТАЕТ.

P.s. Когда ебилд на ати обновить успели?

я его ток вчера утром отправил...

>>Так что новость для тех кто обновляет дистр. вручную, ну там Патреги всякие.

Хе хе, повеселил. "Патреги", бугага, зачот. :D

Нехер делать, что ли, такие новости постить и подтверждать?

Это уязвимости для релиза 1.4.1, в то время как 1.4.2 давно как вышел.

Запостите новость о дырках в ядре 2.6.16.1 и обсасывайте, смакуйте.

Дебилы тупые, .ля!

что-то я не понял а как же все эти защиты памяти типа NX bit? Они же и нужны для обороны от таких ошибок!

Я знаю не только жабу

С другой стороны получается же на мобильной жабе писать быстрые приложения на совсем дохлом железе?

Ладно, признаюсь: я не прав. Хотя на самом деле не понятно зачем так небезопасно сделано.

X -version X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Есть подозрение на утечку памяти...

> А меня достал soft lockup с отваливанием fglrx и мертвым подвисанием. Причем этот soft lockup зависит от фаз луны, он то проявляется почти сразу после загрузки, то после недели безперебойной работы.

А винда с ATI работает быстро и недежно - вот она настоящая ОС, написанная профессионалами, а дырявое падучее глюкалово написанное американскими и финскими студентами. :)

> Это с чего она от рута работает? Я startx набираю от обычного юзера всегда. Или Вы просто всегда под рутом сидите?

Ламо, иди учи man suid у /usr/bin/X.

а чё, у иксов суид какой-то особенный? о_О

bash-3.2$ X -version

XFree86 Version 4.5.0
Release Date: 16 March 2005
X Protocol Version 11, Revision 0
Build Operating System:NetBSD/i386 3.1 - The NetBSD Foundation, Inc.

o_0

Xorg не нужно

на лоре день открытых дверей

XDirectFB наше фсио!

Ха-ха. Пишите дальше на Си. Мышки плакали, кололись... ;)

>Ха-ха. Пишите дальше на Си.

Это каким надо быть имбецилом, чтобы демоны писать на яве??? Даже в висте все системные службы на сях написаны.

>С другой стороны получается же на мобильной жабе писать быстрые приложения на совсем дохлом железе?

В мобильных устройствах виртуальная машина явы зашита в железе, с некоторой натяжкой можно сказать, что для них ява - это ассемблер.

>А винда с ATI работает быстро и недежно - вот она настоящая ОС,

Бывает что и винда медленно работает с некоторыми видеокартами.

>а дырявое падучее глюкалово написанное американскими и финскими студентами. :)

Xorg не студентами писАлся. Его разрабатывает консорциум из нескольки компаний.

>В мобильных устройствах виртуальная машина явы зашита в железе, с некоторой натяжкой можно сказать, что для них ява - это ассемблер.

anonymous (*) (22.06.2008 11:30:14)

А Вы ничего не путаете? Kvm для мобильников реализована в виде приложения и находится на флеш-памяти мобильника

Поддержу анонимуса с вопросом про NX-bit. Большинство современных процессоров поддерживают защиту от выполнения страниц памяти данных и от изменения страниц памяти кода программы. Но почему в X-сервер опять ошибки переполнения буфера? Неужели Linux-ядро не умеет пользоваться NX bit?

некоторый софт требует исполняемого стека для нормальной работы.

"А! Как страшно жить."

sudo telinit 3

Всё - уже не так страшно.

sudo telinit 0

Уже совсем не страшно.

> Это уязвимости для релиза 1.4.1

Это уязвимости для релиза 1.3.0... :)

> дырявое падучее глюкалово написанное американскими и финскими студентами.

Это ты о Catalyst aka fglrx? Думаю, там всё-же индусы... :)

> Это ты о Catalyst aka fglrx? Думаю, там всё-же индусы... :)

Да, индусы-линуксоиды ничего толком написать не могут, в о время как индусы-виндузятники написали нормальные драйвера. А может причина в другом - в кривой архитектуре линукса, который только ядро, умеет работать только с текстовой консолью, воплощая устаревшие принципы UNIX с полным забитием на планирование архитектуры(нестабильное API), и к которому графика и мультимедия прикручены через задницу дикими костылями(в итоге то звуковое приложение блокирует звуковую плату, то tvtime не может поделить xv с mplayer)?

До чего тупые тролли пошли, пездец просто. :( Поскорей бы новый учебный год начался..

>Но почему в X-сервер опять ошибки переполнения буфера? Неужели Linux-ядро не умеет пользоваться NX bit?

Он не во всех процессорах.

Не во всех, но в последние полгода-год - в 90% У AMD свой аналог, еще раньше появился

Linux или BSD Больше сцуко не пи*ди. Запускаешь ты Xorg И система сразу в морг!

> До чего тупые тролли пошли, пездец просто. :( Поскорей бы новый учебный год начался..

В школу, быдло. И не забывай повторять мантры "консоль рулит и ниипет" и "stable api is a nonsense".

Не знаю. Использую Xorg, никаких проблем. Правда 3х-мерные рабочие столы не использую

>Да, индусы-линуксоиды ничего толком написать не могут, в о время как индусы-виндузятники написали нормальные драйвера. А может причина в другом - в кривой архитектуре линукса, который только ядро, умеет работать только с текстовой консолью

Ядро никакой пользовательский интерфейс не должно предоставлять в принципе.

>, воплощая устаревшие принципы UNIX с полным забитием на планирование архитектуры(нестабильное API), >и к которому графика и мультимедия прикручены через задницу дикими костылями

Это давно придуманная и стандартизированная вещь

>(в итоге то звуковое приложение блокирует звуковую плату, то tvtime не может поделить xv с mplayer)? anonymous (*) (22.06.2008 13:46:32)

Ну и что? Блокирование звука встречал в виндоусХР. А другого варианта в принципе и не может быть - или звуковая система должна производить наложение звуков и воспроизведение получившегося, или занятие ресурса c последующей блокировкой процесса- так в любой оси. Ну не знаю , у меня в linux несколько приложений могут одновременно выводить звук.

> С другой стороны получается же на мобильной жабе писать быстрые приложения на совсем дохлом железе?

А теперь подумай, с какой скоростью будут работать приложения на этом же "совсем дохлом железе", написанные на C/асм. Накладные расходы на ява-машину очень большие. И тем ощутимее, чем меньше ресурсов в системе.

> Ядро никакой пользовательский интерфейс не должно предоставлять в принципе.

Жжошь. И интерфес syscall тоже? А вообще, речь о ядерном интерфесе из-за которого посл каждого обновления ядра отваливается fglrx и vmware и не собираются открытые драйвера и спецмодули для iptables , которые раньше собирались(а сейчас автор забросил разработку, но не смотря на это они могли бы работать, если бы у линупса было бы стабильное API).

> Это давно придуманная и стандартизированная вещь

DOS тоже

> Ну и что? Блокирование звука встречал в виндоусХР.

Я ни на одной из конфигураций с виндой(несколько сотен машин) не сталкивался за последние 10 лет с блокировкой звука. Видел проблемы блокировки звуковой в Win 3.x, на уровне которой сейчас и находится линух с зоопарком костылей-серверов звука. А вот под линукс пришлось покупать sound blaster live 5.1, потому что c fortemedia 801, cmedia и интегрированными ac97 realtek и ac97 soundmax были проблемы со звуком - то artsd блокирует звук приложений пытающихся юзать ALSA напрямую, то к кваке3 нет звука без танцев с бубном вокруг фулл-дуплекса, то приложения не могут поделить, помню еще были танцы с dmix. Одним словом п*дец.

>> Ядро никакой пользовательский интерфейс не должно предоставлять в принципе.

>И интерфес syscall тоже?

Онанизмус, научись сначала отличать пользовательский интерфейс (TUI, GUI) от интерфейса программного (API, ABI), а потом лезь в спор с умным видом.