LINUX.ORG.RU
ФорумTalks

[nvidia][noveau][ЖП] Линуса призывают выбросить noveau из ядра

 


0

0

Жареная новость! У Линуса просят удалить noveau из ядра!

Adam Jackson, человек причастный к разработке драйвера, прямо просит удалить ядерную его часть: http://lkml.org/lkml/2010/3/5/196

Конфликт возник после того, как Линус применил патч Ben Skeggs на тему «drm/nouveau: new gem pushbuf interface, bump to 0.0.16» и на собственном опыте выяснил, что это приводит к неработоспособности графической системы его F12 с новым ядром. В [относительно мягкой форме] он указал, что недопустимо менять ядро таким образом, что нарушается работоспособность пользовательских программ, в частности libdrm, поставляемой с широко распространенной версией дистрибутива Fedora.

Эти высказывания вызвали протест в среде разработчиков драйвера noveau, не согласных с такой политикой разработки ядра, которая ограничивает их свободу творчества и право изменять интерфейс по собственному усмотрению. Также они указывают, что разрабатываемый ими драйвер не может быть признан стабильным и изменения его ABI неизбежны. И что они не могут отвечать за руководство дистрибутива Fedora, выпустившее версию использующую драйвер с неустоявшимся интерфейсом.

Вопрос о нахождении драйвера noveau в ядре остается открытым. Следите за новостями.

А серьезно: Неужели это оно? Неужели Линус кардинально меняет политику и теперь во главу угла будет ставиться стабильность ABI?

★★★★★

Обьесняю, жди. Только потом не делай вдоль пожалуйста от осознания, что ты тупое быдо никогда нормально не учившее яву. Я такие задачки на собеседованиях по пять штук даю.

kklauzd
()
Ответ на: комментарий от kklauzd

Я такие задачки на собеседованиях по пять штук даю.

Деточка, у тебя комплекс маленького хвостика, что ты не применул всем соврать про свое крутое коленнолоктевое положение в родной конторе? Так вот, детка, на собеседовании вопросы задают люди которых ценият настолько низко что почитают их направлять общаться с амозгликами, лишь бы не пускать в проект.

wfrr ★★☆
()
Ответ на: комментарий от kklauzd

>Ну допустим, слово «Ява» ты слышал

Любое допущение должно иметь хоть какие-то основания, а уж тем более если допущение подразумевает исключительность сказанного.

man Java.

И зачем мне сдалась эта интерпрайзная поделка?

vkos ★★
()

>Integer a = 1000, b = 1000;

Происходит упаковка примитива в объект. Значения целочисленного примитива не попадают в предел -128..127. Поэтому примитивы упаковываются в разные объекты. Соотвественно == дает фалсе.

a = 10; b = 10;

Попадает в интервал значений -128..127 для целочисленного литерала. Упакорвывается в один и тот же обьект для ускорения работы. Можешь считать это таким хаком для улучшения производительности. Соответсвенно == дает true.

ссылки на JLS где это разжовано исчи сам, мне лень тебя за тебя самого учить.

kklauzd
()
Ответ на: комментарий от a3

Язык просто не должен быть кривым, тогда при прочтении документации не будет возникать недоразумений по поводу странности языка. Можно выучить, что for означает if, только вот зачем делать такой язык?

vkos ★★
()
Ответ на: комментарий от wfrr

>Гуглить умеешь

Я хотел тебя ткнуть носом в JLS, но быстро найти там ничего не смог.

Признайся, ты ущербен и об этом свойсвте явы ты никогда не слышал. Книжек по ней ты конечно же никогда не читал. А сиюминутную надрочку ты считаешь куда важнее элементарного рассудительного изучения предмета. Таких как ты отсеивают еще на стадии просмотра резюме.

kklauzd
()
Ответ на: комментарий от kklauzd

Дорогой закомплексованный самчик

Ты за местами куда тебя другие носом погружают следил, лучше 8)

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

Вот еще рассказывай отчего так и где логика:

radws% cat Test.java

public class Test{

  public static void main(String args[]){
    Test t = new Test();
    System.out.println("Щас будет ClassCastException!");
    Object o = cast(t, Integer.class);
    System.out.println("Почему нету?");
    Integer i = (Integer)o;
  }

  private static <T> T cast(Object o, Class<T> clazz){
    System.out.println("cast to " + clazz);

    return (T)o;
  }
}
radws% java Test
Щас будет ClassCastException!
cast to class java.lang.Integer
Почему нету?
Exception in thread "main" java.lang.ClassCastException: Test cannot be cast to java.lang.Integer
        at Test.main(Test.java:9)
wfrr ★★☆
()
Ответ на: комментарий от kklauzd

Так, ты детка кроме митана ничего не производишь, а он напильником будет производить «продукт» и тем самым поднимать экономику. Да, офисный планктон вроде тебя напильник то и в руках поди держать не умеет.

wfrr ★★☆
()
Ответ на: комментарий от kklauzd

>Есть релиз

С какого момента -git стал релизом?
И да, если линус принял кривой патч к себе - то он ССЗБ.

devl547 ★★★★★
()
Ответ на: комментарий от kklauzd

Детка ты опять взбзданула.

Вполне логичное поведение.

И теперь потупя глазки пытаешься похудевшей тушкой прикрыть причиненные луже разрушения. Попробуй сказатьт правду и только правду. 8)

wfrr ★★☆
()
Ответ на: комментарий от vertexua

Дык, студиозика приняли в конторку на работу жабкакодером, а он с фанатизмом вантузиода превозносит яву. Макнуть его носом в говнецо — закон лора. В принципе после этих примеров C++ выглядит верхом логичности 8)

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Вы слишком мрачно смотрите на вещи. Есть нарочно выдуманные примеры. Java поражает своей пригодностью, хотя и имеет недостатки. Просто ее нужно знать как любой язык. И на любом языке можно такое накодить, что плохо будет.

С++? Хотите я 5 раз разыменую NULL? А в сферу утечек памяти вообще лучше не заходить - не вылезем. И конечно же молча падающие с SEGFAULT программы.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Есть нарочно выдуманные примеры.

Может, и есть, но то что я приводил встречается очень часто и алогично. Есть еще фееричный фокус когда класс не равен самому себе, но то чуть ли не единственная логичная «фишка», кстати многие на него попадались.

С++? Хотите я 5 раз разыменую NULL? А в сферу утечек памяти вообще лучше не заходить - не вылезем. И конечно же молча падающие с SEGFAULT программы.

Яж не про отстрелл собственных яиц ружжом.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Ну просто никто не может претендовать на то, что он писал много на С++ без утечек памяти и без SEGFAULT. Такое бывает.

А что там будет если заменить все на .equals? Я просто обычно так пишу

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

все нормально будет 8) ибо сравнивается по getValue, да и кастинг можно докрутить если использовать clazz.cast() только это требует всегда передавать класс (и еще type erasure), за что емнип давно пинали сан. Так что за 29 лет эти квалифицированные инженеры стольк гомна пооставляли в яве что диву даешься, как оно еще популярно.

wfrr ★★☆
()
Ответ на: Это он. от Camel

Слишком толсто, это вопрос организационный, к технике ни какого отношения не имеет. Кто-то кого-то недопонял и всё.

ixrws ★★★
()
Ответ на: комментарий от kklauzd

Расскажи мне суперспец по яве, почему у тебя до сих пор не нашлось денег на wind7?

linux4ever
()
Ответ на: комментарий от kklauzd

То есть, человек для явы должен мозг переделывать? Первый раз такое было в бейсике... После этого всех, кто на нём кодил, стали называть просто потерянными. Кажется, Кнут травлю начал? :)

В общем, вон быдлоязыку из этого мира!

alexmaru
()

> теперь во главу угла будет ставиться стабильность ABI?

_только_ для кода, написанного не Линусом.

pv4 ★★
()
Ответ на: комментарий от devl547

[ 5.376650] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 195.36.03

uname -a Linux tom 2.6.33 #1 SMP Sun Feb 28 17:13:22 EET 2010 x86_64

azure ★★
()
Ответ на: комментарий от kklauzd

>Посмотрите хотя бы на Java. То что спроектировали высококлассные высокооплачиваемые инженеры почти двадцать лет назад - живо до сих пор и никто ничего не поломал.

/me вспомнил type erasure... В гробу я такую стабильность видел%)

Sectoid ★★★★★
()
Ответ на: комментарий от Sectoid

>/me вспомнил type erasure... В гробу я такую стабильность видел%)

Разорались... Да, Java не подарок, но:

- про сравнение объектов через equal не знает только дебил, а со своими ожиданиями^W^W своим незнанием языка пытаться доказать ущербность оного - доказывать свою собственную ущербность;

- про каст: при вызове <T> T cast(Object o, Class<T> clazz) как cast(t, Integer.class) параметрический тип T не указан, и соответственно T==Objeсt, так что (T)o проходит «на ура»;

- type erasure - я уже писал, не знаю как в 6-ке (лень проверять), в 7-ке расширенные сигнатуры классов/методов/полей сохраняют всю информацию о «параметризации». Компилятор не использует? Пишите патчи или свой компилятор =)

yyk ★★★★★
()
Ответ на: комментарий от kklauzd

> двадцать лет назад - живо до сих пор и никто ничего не поломал.

В целом да, но есть исключения.

Например, при переходе к java 1.6 расширили интерфейсы, касающиеся JDBC, и поэтому некоторые старые вещи невозможно скомпилировать под 1.6 - приходится их переписывать.

sign
()
Ответ на: комментарий от vertexua

А что там будет если заменить все на .equals?

С .equals тоже проблема

Если левый объект будет Null - то сгенерируется исключение.

Если же Null передать в качестве аргумента - то исключения не будет.

Получается что equals не симметричен.

Из-за этого рождаются мозгоразрываные конструкции вида

"true".equals(param)

И вообще уже давно пора делать Java++ ;)

sign
()

И вообще, если уж про недостатки java говорить, то предлагаю следующее:

1. Убрать checked exceptions в их теперешнем виде, которые заставляет поддерживать компилятор sun от java. Ведь на самом деле checked exceptions в jvm нет. Не должно быть загрязнения всех методов бесконечными throws.

2. Нужна возможность перехватить и обработать исключение в момент возникновения с возможным, но не обязательным, доступом к фрейм-стэку, к сигнатурам методов (и особенно к сигнатурам конструкторов) и к значениям параметров. В частности это должно позволять ускорять обработку исключений, при отмене сбора информации о всех фрейм-стэках.

3. Концепция const на уровне языка. Должна быть возможность передать mutable объект в метод, но иметь при этом гарантию, что объект не будет изменен.

4. Добавить переопределяемые операции. Чтобы можно было писать для bigdecimal : a + b.

5. Изменить все базовые библиотеки на работу только с интерфейсами. Например, во всех вызовах заменить string на charsequence. В частности, это позволит использовать свои (например экономно использующие память) релизации строк.

6. Добавить возможность возвращать несколько объектов из метода.

7. Сделать null объектом, чтобы для него можно было вызывать методы. Чтобы можно было писать null.equals(«true»). Возможно ввести операцию проверки идентичности объектов === . В случае вызова операции == вызывать метод equals.

8. Запретить finalize. Сейчас если finalize вызывает исключение во время сборки объекта, то это исключение молча проглатывается сборщиком мусора и объекта остается живым навсегда, что приводит к утечке памяти.

9. Ввести понятие освобождения ресурсов (собственно это уже делается для Java 7).

sign
()
Ответ на: комментарий от sign

1. Ваше имхо. Люди постоянно пишут код ничего не проверяя. Особенно С и С++

2. Как то неочевидно что вы хотите

3. Можно ввести, минорая фича. Мало что дает, усложняет проэктирование

4. Scala

5. Не усложнит ли это все? Просто в STL похожие абстракции, и что? Там много всяких синтаксически non-straightforward вещей.

6. Scala

7. Groovy, кажется Scala

8. Перехватывайте исключения в finalize. Мне кажется что это связано с первым пунктом. Есть вариант заствить обрабатывать исключения в финализаторах. Это конечно минус платформы, но ваше решение «запретить» ужасно

9. O_o. Выражаться надо яснее. Что вы имеете ввиду?

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.