форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от opennews on 23-Мрт-14, 09:00
По информации (http://www.phoronix.com/scan.php?page=article&item=amd_catal...), полученной на проходившей недавно конференции Game Developer's Conference, компания AMD рассматривает достаточно интересную стратегию развития драйвера Catalyst. Общая идея состоит в том чтобы избавиться от собственного модуля для ядра, использовав вместо него DRM-инфраструктуру (Direct Rendering Manager) ядра Linux и модуль открытого драйвера Radeon. При этом функциональность специфичная для проприетарного драйвера останется только в компонентах, выполняемых в пространстве пользователя, так что для драйвера не будет требоваться проприетарный модуль ядра. Ожидается, что подобный подход может устранить множество проблем с поддержкой различных дистрибутивов Linux и разных версий ядер. В том числе реализация драйвера Catalyst  целиком в пространстве пользователя снимет ограничения (http://www.opennet.me/opennews/art.shtml?num=35067) на использование интерфейсов ядра Linux, доступных только для модулей под лицензиями, совместимыми с GPL (группа EXPORT_SYMBOL_GPL), так как они не распространяются на user-mode компоненты, работающие через свободный модуль ядра. Кроме этого, для установки драйвера не будет требоваться работоспособный компилятор, способный собрать модуль ядра. Тем не менее, отмечается, что данные планы весьма предварительны, так как на пути к реализации данной идеи могут возникнуть многочисленные трудности: -  Компоненты Catalyst (реализация OpenGL и DDX драйвер) нуждаются в существенном рефакторинге для того чтобы использовать открытый модуль ядра вместо проприетарного. -  Линус Торвальдс отрицательно относится к изменениям, которые ломают совместимость интерфейсов с существующим кодом. Поэтому маловеероятно, что в ядро будут приняты изменения, которые нарушают работу драйверов R300/R600/RadeonSI. Это означает, что большинство изменений должно делаться на стороне драйвера Catalyst. -  В данный момент управление памятью в открытом драйвере работает медленнее, чем хотелось бы, поэтому чтобы избежать потерь производительности при переходе на новую архитектуру придется существенно переработать код управления памятью в ядерных модулях открытого драйвера. -  В открытом модуле пока не реализованы некоторые возможности, которые нужны Catalyst. Наиболее проблемными считаются CrossFire / Dual Graphics, поддержка OpenGL stereo, реализация улучшенных режимов AA/AF, OverDrive / overclocking и прочие возможности, которые предоставляет Catalyst Control Center. Кроме того, поддержка OpenCL также в данный момент не полная. С другой стороны, Catalyst например не умеет предоставлять интерфейс к блоку аппаратного кодирования видео в новых GPU (VCE - Video Coding Engine). Это является результатом того, что 2 команды работают достаточно независимо и поэтому принимали разные решения о том, какие интерфейсы они предоставляют. -  Возможны юридические проблемы с некоторым кодом. Например, ставится под вопрос возможность реализации DRM (средства защиты авторских прав) в виде открытого кода. DRM можно реализовать через дополнительный проприетарный модуль ядра, выполняющий дополнительные функции и не являющийся обязательным, однако это все-равно аннулирует ранее упомянутые плюсы, проявляющиеся при избавлении от проприетарного модуля. -  Если некоторые интерфейсы/ioctl используются только закрытым драйвером, апстрим может отвергнуть такие патчи. Ранее в ядре Linux уже применялась практика при которой патчи в ядро отвергались в случае когда данным кодом пользовались только проприетарные компоненты в пространстве пользователя (наиболее ярким примером является VIA Chrome 9 DRM). -  Для драйвера Catalyst достаточно приоритетен корпоративный рынок. Это означает, что довольно много изменений придется портировать в старые ядра. -  Опасения вызывает необходимость требовать обновления ядер при существенном дополнении функциональности драйвера, когда старый открытый модуль не будет предоставлять всех нужных функций. -  Исторически, открытые драйверы появлялись только после появления оборудования на рынке, что приводило к некоторой задержке в появлении поддержки новых моделей GPU в открытых драйверах, особенно при существенном изменении архитектуры. Упомянутый подход потребует заметно пересмотреть подобную практику, перейдя к добавлению поддержки в открытый модуль до выпуска новых моделей видеокарт на рынок. Дело усложняется тем, что новый код в ядро Linux принимают только во время окна приема изменений. Это означает необходимость учитывать даты, связанные с разработкой ядра Linux, и синхронизировать свои рабочие процессы с этими датами. Ситуация усугубляется еще и тем, что юридический отдел достаточно долго рассматривает выпуск исходных текстов. Также отмечается, что многие пользователи интересуются почему AMD не открывает драйвер целиком. Наиболее вероятной версией называлась собственность третьих фирм. Однако, утверждается, что это не самая значительная проблема. Более того, драйвер был лицензирован неназванным третьим сторонам. Из наиболее проблемных моментов выделяются опасения что конкуренты смогут использовать трюки и оптимизации в реализации OpenGL. URL: http://www.phoronix.com/scan.php?page=article&item=amd_catal... Новость: http://www.opennet.me/opennews/art.shtml?num=39380
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Компания AMD рассматривает возможность более открытой разраб..."	+9 +/–
Сообщение от ананим on 23-Мрт-14, 09:00
> Линус Торвальдс отрицательно относится к изменениям, которые ломают совместимость интерфейсов с существующим кодом. Поэтому маловеероятно, что в ядро будут приняты изменения, которые нарушают работу драйверов R300/R600/RadeonSI. Линусу Торвальдсу будет всё-равно, если эти изменения будут согласованы с разработчиками (открытых) драйверов R300/R600/RadeonSI и/или ими же и будут продвигаться. Зыж Вот этого же бы от невидиа. Было бы не плохо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 09:04
	> Упомянутый подход потребует заметно пересмотреть подобную практику, перейдя к добавлению поддержки в открытый модуль до выпуска новых моделей видеокарт на рынок. Дело усложняется тем, что новый код в ядро Linux принимают только во время окна приема изменений. Это вообще не проблема, посмотрите как это делает интел и делайте также. Конечно, подход к разработке придётся менять, но на скорости это не скажется никак (или увеличится и придётся соответствовать так сказать). Всё равно дрова пишутся для ядра, а не наоборот.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от anonymus on 23-Мрт-14, 09:14
	> Это вообще не проблема, посмотрите как это делает интел и делайте также. Вот так лучше не делать. Когда глючит размазанная видюха - это нормально, от неё примерно этого и ожидают. Но когда дискретная видюха не получает поддержки со стороны дров по полгода, а иной раз эта поддержки и вовсе нет, как это у интела случилось с атомами, то закономерным становится вопросам, а зачем она вообще нужна?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Компания AMD рассматривает возможность более открытой разраб..."	+9 +/–
	Сообщение от ананим on 23-Мрт-14, 09:42
	Во-первых — этого уже нет. В тот период у интела не было ни стабильных дров, ни методов работы с сообществом. Глюки и ляпы были и там, и там (а как они пульсбо выложили, а суб-подрядчик возмутился, вообще забавно). Сейчас в ядро уже запилили дрова для карт, которые ещё даже не производятся (новость была тут). Во-вторых — а кто сказал, что с дискретной видюхой это сейчас (как минимум!) не так же? Что, каталист что ли поддерживает самое последнее ядро? Хорошо если предпоследнее. Или невидимский оптимус заработал без опенсорсного костыля — примус? Вы пытаетесь ввести в заблуждение (сознательно или нет, х/з), но интеловские видюхи — это единственное что сейчас работает из коробки намного чаще, чем у конкурентов. И они опять же едиственные открытые. Если ваша легаси (как купили, так она всё больше и больше легаси) работает (без особых. С блобами вооще "без" не бывает) бубнов, это ещё не значии что и у других так же. Иначе павлин тут не кидал бы патчи "как пропатчить хы под ху" (и остался бы без пищи).
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	24. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от анончик on 23-Мрт-14, 11:26
	> Во-вторых — а кто сказал, что с дискретной видюхой это сейчас (как > минимум!) не так же? > Что, каталист что ли поддерживает самое последнее ядро? Хорошо если предпоследнее. http://pastebin.ru/pRs2KJIl
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	27. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от ананим on 23-Мрт-14, 11:45
	Чего это за хрень с левого ресурса? Зыж А ещё поддержка последних иксов, вяленого, этк.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	66. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от анончик on 23-Мрт-14, 13:21
	c xorg-server тоже нет проблем : http://pastebin.ru/DXtDcQTo насчёт wayland  .. когда будет готов тогда и поговорим :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	78. "Компания AMD рассматривает возможность более открытой разраб..."	–12 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:18
	> c xorg-server тоже нет проблем : А 3.14 RC с этим драйвером можно погонять? Нет? Ну ой, тогда не интересно.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	95. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от анончик on 23-Мрт-14, 16:56
	а ты уверен что нельзя ?
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	96. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Карбофос (ok) on 23-Мрт-14, 17:04
	можно. если благородный дон в силах погонять 3.14-rc, конечно
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	106. "Компания AMD рассматривает возможность более открытой разраб..."	–8 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:06
	> можно. если благородный дон в силах погонять 3.14-rc, конечно А вы проверяли? А то нвидия вон недавно мыкалась с тем что в новых ядрах отломали нужные им фичи. Что там еще у нас отвалится следующим?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	131. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от VecH (ok) on 23-Мрт-14, 20:44
	пистон
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	142. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Карбофос (ok) on 23-Мрт-14, 21:29
	демагогию разводите, милейший
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	164. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 03:15
	> демагогию разводите, милейший Кроме демагогии юзеры нвидии с 3.13 кернелом тут носились как ужаленные. Но у них я так смотрю память довольно короткая когда надо.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	174. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Карбофос (ok) on 24-Мрт-14, 10:30
	об чем и речь. то он предполагает, что драйвера с новым ядром не работает, то за него еще и тесты проведи, да непременно докажи, что оно на rc безукоризненно работает. напоминает анекдот про маленькую серенькую птичку
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	182. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от Аноним (??) on 24-Мрт-14, 16:03
	Ну а что, проблемы регулярно бывают. Нвидия с ее отсутствием поддержки новых ядер как свежий пример. Я что, должен все такие плюхи лично проверять? А вы потраченное на это время оплатите?
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	185. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Карбофос (ok) on 24-Мрт-14, 16:40
	ну прям как маленькая серая птичка, не иначе. сначала заикнулся про одно, потом про другое, потом - про третье, теперь ему еще и время его оплачивай. это так типично для маленьких сереньких птичек месье, хватит уже сопли по монитору размазывать!
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	196. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Аноним (??) on 24-Мрт-14, 19:52
	> ну прям как маленькая серая птичка, не иначе. Не, вот извините. То что проприетарные драйвера периодически тормозят с поддержкой новых ядер - таки факт, и факты штука упрямая. Очередной пример с нвидией был на примере как раз 3.13 ядра, насколько я помню. А для амд это вообще является мотиватором к сабжу, если что.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	250. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Карбофос (ok) on 29-Мрт-14, 01:12
	не извиню. так как выражение "погонять 3.14-rc" входит в конфликт с выражением "заплатите мне за потраченное на тесты время"
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	146. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Led (ok) on 23-Мрт-14, 22:08
	ядро 3.13 и xorg-1.15 поддерживается. Что ещё надо?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

3. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
Сообщение от ананим on 23-Мрт-14, 09:07
> Если некоторые интерфейсы/ioctl используются только закрытым драйвером, апстрим может отвергнуть такие патчи. Ранее в ядре Linux уже применялась практика при которой патчи в ядро отвергались в случае когда данным кодом пользовались только проприетарные компоненты в пространстве пользователя Благодаря этому и имеем сабж! :D
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Компания AMD рассматривает возможность более открытой разраб..."	+5 +/–
Сообщение от Sluggard (ok) on 23-Мрт-14, 09:22
Лишь бы открытые дрова не ломали. А в общем и целом — молодцы, раз стараются сделать драйвер более открытым, думают, ищут пути решения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от Fracta1L (ok) on 23-Мрт-14, 09:45
	А толку-то. Столько лет "сотрудничества с сообществом" (тм), а качество едва за плинтус поднялось, и то - в последний год-полтора.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "Компания AMD рассматривает возможность более открытой разраб..."	+6 +/–
	Сообщение от ананим on 23-Мрт-14, 10:04
	Высо-о-окий такой плинтус. 80-90% от блоба. При этом в стиме на некоторые игры рекомендуют именно открытые дрова. При этом mesa всё больше и больше играет роль, как эталонная реализация opengl. Опять же, как бы тебе не хотелось передёрнуть, а сотрудничество (пока?) не стало для них апстримом. И, соответсвенно, ресурсов на сотрудничество тратится гораздо меньше, чем на тотже каталист. Зыж По сабжу пока можно сказать следующее — сотрудничество приносит плоды и будет расширяться.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "Компания AMD рассматривает возможность более открытой разраб..."	–7 +/–
	Сообщение от Fracta1L (ok) on 23-Мрт-14, 10:31
	> 80-90% от блоба Вы так говорите, будто блоб сам блещет качеством. > При этом в стиме на некоторые игры рекомендуют именно открытые дрова Какой-нибудь шлак, наверное? > При этом mesa всё больше и больше играет роль, как эталонная реализация opengl Пруфы где? > ресурсов на сотрудничество тратится гораздо меньше, чем на тотже каталист Я представляю сколько это, если Каталист пилят три с половиной индуса.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	17. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 23-Мрт-14, 10:47
	>> 80-90% от блоба > Вы так говорите, будто блоб сам блещет качеством. Хм. Так же как и вантузе. Один в один. Что и логично — кодовая база на 99% одна и для вантуза, и для линуха. При этом в открытых дровах нет тех патентованых оптимизаций (что указаны в последнем абзаце). Да и не до них пока. Пока набирается функционал, повышаются версии стандартов и т.д. И да, этот функционал стал работать стабильно и хорошо. Зыж >> При этом mesa всё больше и больше играет роль, как эталонная реализация opengl > Пруфы где? Все игры валв идут на меса. И именно меса является критерием, что работа по портированию завершена (говорю как купивший валве мега-пак, и участник соответсвующих форумов там же). Ззыж >Я представляю сколько это, если Каталист пилят три с половиной индуса. Вряд ли ты это представляешь. Иначе эти индусы бы вот тут не засветились: >С другой стороны, Catalyst например не умеет предоставлять интерфейс к блоку аппаратного кодирования видео в новых GPU (VCE - Video Coding Engine). Это является результатом того, что 2 команды работают достаточно независимо и поэтому принимали разные решения о том, какие интерфейсы они предоставляют. ..
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	70. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 13:53
	>Все игры валв идут на меса. Все игры Valve морально устарели, ничего удивительного что они идут на mesa. Кроме того, производительность в 80-90% от проприетарного драйвера показывают только некоторые из старых карт AMD, в сериях 7000 и 8000 и в совсем новых сериях карт - производительность сильно ниже.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	83. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:26
	> совсем новых сериях карт - производительность сильно ниже. В последнее время и их подтянули очень неплохо. Проблемы еще есть, конечно, но прогресс радует глаз. А т.к. они гораздо мощнее интелского интеграта, очень мило получается: можно получить неплохую производительность в 3D и без блобья.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	114. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от Проходящий on 23-Мрт-14, 19:28
	купи игровую дискретную видеокарту, и получи производительность чуть выше интеловского интеграта(или ещё хуже, в некоторых местах). Налетай!
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	128. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 20:37
	> интеграта(или ещё хуже, в некоторых местах). Налетай! У меня HD5770, расскажи мне про свой интеграт, угу. Этот может xonotic в fullhd гонять с FPS=60 без просадок, с настройками = high. С открытым драйвером. Интеловскому интеграту такое, мягко говоря, не грозит.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	173. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 24-Мрт-14, 10:23
	>> Все игры валв идут на меса. > Все игры Valve морально устарели, ничего удивительного что они идут на mesa. Глупое утверждение. Серьёзно. Тоже метро не на движке соурс (который в свою очередь тоже не стиот на месте). Но дело даже не в этом. А в том, что правятся баги не только в играх, но и баги в меса. Совместно. И это офигенное преимущество опен-сорсного подхода по сравнению с клозет-сорсом.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	18. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от commiethebeastie (ok) on 23-Мрт-14, 10:49
	>Вы так говорите, будто блоб сам блещет качеством. По производительности обыкновенная венда. >Какой-нибудь шлак, наверное? painkiller же >Пруфы где? Ну например недавний фикс для Метро говорит о том, что нвидиа говна кусок и вешает лапшу лохам на уши. >Я представляю сколько это, если Каталист пилят три с половиной индуса. 500 человек не хочешь. Просто пилят его выпускники российских и украинских говновузов с купленными дипломами.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 10:59
	> Просто пилят его выпускники российских и украинских гoвнoвyзoв с купленными дипломами. Да-да, и общающиеся между собой на английском! Куда там индусам! :D
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	31. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от commiethebeastie (ok) on 23-Мрт-14, 12:14
	Это менеджеры, а дрова пишет на оутсорсе российская компания.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	61. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 12:47
	угу. А технические задания, техническая документация, отчётность,... да даже комменты. С русско-украинским акцентом (стихи в мсо забыли уже?)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	62. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от commiethebeastie (ok) on 23-Мрт-14, 12:58
	> угу. > А технические задания, техническая документация, отчётность,... да даже комменты. > С русско-украинским акцентом (стихи в мсо забыли уже?) Естественно документация на английском. В MS тоже всё на английском, а не хинди.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	68. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 13:25
	Не путайте документацию документацию для конечного пользователя и техническую документацию (и техническую переписку сотрудников). А то даже в msdn ляпов было (не помню когда уже она мне была нужна. ресурсов слава Богу сейчас есть предостаточно) навалом. Особенно в локализованных (смесь русско-индо-и_ещё_не_понятно_чего, угу, помню) версиях.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	181. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Anonym2 on 24-Мрт-14, 15:58
	> Не путайте документацию документацию для конечного пользователя и техническую документацию > (и техническую переписку сотрудников). > А то даже в msdn ляпов было (не помню когда уже она > мне была нужна. ресурсов слава Богу сейчас есть предостаточно) навалом. > Особенно в локализованных (смесь русско-индо-и_ещё_не_понятно_чего, угу, помню) версиях. Автоперевод. Обычно с английского...
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	187. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 17:07
	И "на" тоже. Плавали, знаем.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	63. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от koblin (ok) on 23-Мрт-14, 12:58
	amd _уже_ работает на открытых драйверах из коробки, управление питанием запилили, производительность на уровне 80% от блоба. Включаешь и оно просто работает...
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	71. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 14:01
	>производительность на уровне 80% от блоба. На некоторых картах серий 4000-6000, на остальном производительность в глубокой ж*пе.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	74. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 15:17
	врешь ты все. Вопервых до 76хх во вторых на новых картах половина производительности проприетарного. Не густо конечно, но вполне неплохо.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	77. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:01
	> врешь ты все. Вопервых до 76хх Это ты врёшь - начиная с серии 7000 карты AMD работают с драйвером RadeonSI, который находится в сильно недопиленном состоянии. Нет там половины.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	91. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:40
	Смотрите новые тесты, там и больше половины бывает. И что касается фич, у них уже паритет с r600g.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	100. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 17:50
	> Это ты врёшь - начиная с серии 7000 карты AMD работают с драйвером RadeonSI, Таки до 7600 - с R600, правильно вам говорят. GCN - начиная с HD77xx. > который находится в сильно недопиленном состоянии. Уже вполне сравнимо с R600. А GL 3.3 там даже чуть ранше R600 реализовали. > Нет там половины. Например, чего? А например VCE только там и есть - он только в новых GPU, чисто технически.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	85. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:28
	> тормозов и сегфолтов. Вот что-что а открытый драйвер стабильностью весьма радует. Так, для сравнения: - Каталист вис раз в неделю. Набрал бэктрейсы, зарепортил. Толку - буй! Прошло 4 года. Все-равно виснет. - Открытый драйвер вис. Мало того что он диагностику лучше выдавал, так еще и багтрекер нормальный есть + понятно где выцепить разработчиков, если они нужны. Баг просто пришибли и теперь драйвер стабильно работает *месяцами*.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	79. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:19
	> Вы так говорите, будто блоб сам блещет качеством. Вот кстати идея пропихнуть его через DRM/KMS очень здравая на самом деле.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	133. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 23-Мрт-14, 21:00
	> Я представляю сколько это, если Каталист пилят три с половиной индуса. Не, не представляете.  Вот дорастёте до того, чтоб самому хоть отдалённо браминский код кропать, а не в каментах отмечаться -- тогда не исключено. В смысле хорош флудить. PS: коллеги, ну взрослые же люди -- не тратьте время на тех, кто сюда набегает понавбрасывать без какой-либо конструктивной цели.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	148. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Led (ok) on 23-Мрт-14, 22:11
	> ресурсов на сотрудничество тратится гораздо меньше, чем на тотже каталист. Может потому, что кодовая база каталиста - общая для всех поддерживаемых ОС?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	150. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 22:28
	да. и поэтому тоже. вывод то какой из этого факта?
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	26. "Компания AMD рассматривает возможность более открытой разраб..."	+10 +/–
	Сообщение от Sluggard (ok) on 23-Мрт-14, 11:35
	Фрактал, ты как был неадекватным, так и остался. И обсуждать что-то с упёртым человеком, который считает себя умнее всех, просто бессмысленно.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	195. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-14, 19:37
	> Фрактал, ты как был неадекватным, так и остался. И обсуждать что-то с > упёртым человеком, который считает себя умнее всех, просто бессмысленно. есть специальная поговорка: "не спорьте с идиотами"
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

8. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от Аноним (??) on 23-Мрт-14, 09:54
Это только от линуксового блоба планируют избавляться, или на остальных системах тоже будут делать также?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 10:04
	на каких остальных? Больше свободных ос их драйвер не поддерживает
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 10:07
	Добавлю — а на вантузе их opengl (см. окончание сабжа), из-за чего сыр-бор, тоже не приветствуется. Там мс решила всё в пользу своего dx.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok) on 23-Мрт-14, 10:20
	> Добавлю — а на вантузе их opengl (см. окончание сабжа), из-за чего сыр-бор, тоже не приветствуется. Там мс решила всё в пользу своего dx. Windows NT4, в своё время, была сильная поддержка OpenGL — о чём писал Евгений Козловский в бумажной "Компьютерре". А в Windows 9x/ME была отличная поддержка DirectX, так, что DX в Win9x/ME опережал таковой в WinNT4 на несколько версий, и игры, соответственно, писались для хомячков с Win9x/ME. Потом "тестовую" платформу выбросили, оставили WinNT и до сих пор продолжают развивать только её. Никуда хомячки не денутся с подводной лодки, и MS тоже, кстати. Так что одно другому делает пинок под зад: развивает родной API, что двигает игры и качественную визуализацию 2D/3D-сцен в отрыве от "генеральной линии партии" — комитета по разработке стандартов OpenGL. С другой стороны, это задел идей на будущее для OpenGL.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	19. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 10:56
	Гораздо бОльший пинок дало развитие смартфонов/планшетов/этк вообще и от гугла с яблоком в частности, где по очевидным причинам dx нет как класса. Зыж А воовще знатно мс нагнуло производителей видео-карт, раз они согласились поставлять дрова с выпеленным opengl. Сколько работы в мусорный бак (см. последний абзац новости)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	81. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:21
	> Никуда хомячки не денутся с подводной лодки, Вот только на мобилах и планшетах повально OpenGL, этот рынок растет и отдавать его никто не собирается. Поэтому выучат GL как миленькие. А еще веб с его WebGL. Ну в общем если долго давиться жабой - получается как-то так...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	12. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 23-Мрт-14, 10:10
	> Это только от линуксового блоба планируют избавляться, или на остальных системах тоже будут делать также? Кстати, если в бздях запилят аналоги kms/drm/.., то есть шанс, что блоб в юзер-спейсе заработает и у них. Бздишнеги, можете линуксоидов не благодарить! :D
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	112. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:23
	Под FreeBSD пилили KGI, но забросили 2года назад, а drm/kms и так портируют/есть.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	117. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:39
	> Под FreeBSD пилили KGI, но забросили 2года назад, Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение. Они уже давно не делают погоду в отрасли. Климат давно уже задает пингвин и его разработчики. > а drm/kms и так портируют/есть. Да, несколько лет поупирались рогом, мол да ну его, etc. А как жареный петух укусил, что драйверов вообще совсем нет - тут прозрели резко. Только отставание на годы - оно никуда не денется.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	118. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok) on 23-Мрт-14, 19:48
	> Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение. Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами. > Они уже давно не делают погоду в отрасли. Всё делают проприетарщики для Linux, но что-то воз и ныне там, в далёком 2006 году. Как было, так и осталось по большому счёту. Концептуально только Android — серьёзное решение. > Климат давно уже > задает пингвин и его разработчики. >> а drm/kms и так портируют/есть. > Да, несколько лет поупирались рогом, мол да ну его, etc. А как > жареный петух укусил, что драйверов вообще совсем нет - тут прозрели > резко. Только отставание на годы - оно никуда не денется. Intel написал KMS/DRM специально для Linux. Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды? Что, должны были подлизывать зад Intel, как это делали линуксятники?
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	125. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 23-Мрт-14, 20:23
	> Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды? Угу. Вот только иксы под мит, а рулит там Аарон из оракла в основном. А бздуны просто нифига не делали и сами самоустранились. Как и во всём.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	130. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok) on 23-Мрт-14, 20:43
	>> Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды? > Угу. Вот только иксы под мит, а рулит там Аарон из оракла в основном. Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников и BSD'шников: http://www.opennet.me/opennews/art.shtml?num=33375 //-- 16.03.2012 21:32  Завершены выборы управляющего совета проекта X.Org Из не прошедших в совет можно отметить Marc Balmer из компании Micro Systems, предвыборная программа которого касалась улучшения поддержки BSD-систем, и Jeremy Huddleston из компании Apple, мэйнтейнер проекта XQuartz и разработчик расширения XQuartz DDX. Члены совета, не участвовавшие в выборах, так как их срок истекает только в следующем году: Alan Coopersmith (Oracle), Eric Anholt (Intel), Stuart Kreitman (Oracle), Bart Massey (университет Портлэнда). --// > А бздуны просто нифига не делали и сами самоустранились. Как и во всём. "Нифига" не сделали: https://wiki.freebsd.org/Graphics Нужно говорить Intel'у спасибо за это или нет? ;)
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	143. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 23-Мрт-14, 21:31
	> Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников и BSD'шников А! Так ты про макосников! Тю. Бздишники то, как Таббаки испарились вслед. Зыж Вот только кварцев там и не хватало. А главное — бзде бы как помогло-о-о!!!
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	151. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 22:55
	> Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников У макоси своя графическая подсистема, так что этим там вообще делать нечего, имхо. Работа на мусорный бак. > и BSD'шников: А эти сами устранились из процесса разработки. И процесс пошел без них. А что, они думали что интел будет делать что что надо им? Мечтайте. > Из не прошедших в совет можно отметить Marc Balmer из компании Micro Чтобы голосовать, надо разрабатывать. А интел и остальные не будут голосовать за удобство бсдельников. А оно им зачем? Пусть бсдельники разрабатывают и тогда голосуют. А как ты хотел? Указывать другим что они должны для тебя делать? Ишь, размечтался. Участники процесса будут делать только то что надо им. А тебе в этой схеме - "как повезет". > "Нифига" не сделали: https://wiki.freebsd.org/Graphics > Нужно говорить Intel'у спасибо за это или нет? ;) Я бы сказал - KMS+DRM выглядит могучей, фичастой и современной низкоуровневой "подложкой", которая в курсе устройства современных GPU и их возможностей. А если бы мы слушали все эти бздения дальше - оно и дальше работало через пень-колоду. Если кто хочет идти на свалку истории, флаг им в руки, но зачем же топить всех остальных? Вот линь тонуть не пожелал, там предпочитают сделать нормальный низкоуровневый бэкэнд к которому можно прикручивать разные фронтэнды, например иксы с DDX, вяленд, MESA всякие и кто там еще. Это все логично и естественно. Логично что вещами типа управления памятью и реклока должен рулить кернел. Логично если ядро сможет по минимуму рисовать в нечто типа фреймбуфера, коли уж оно есть ("CRTC"). Они пошли чуть дальше, развязав сие на отдельные компоненты. Так что теперь может быть и "безголовый" рендерер, у которого нет CRTC, так и "безмозглый" CRTC, не подпертый рендерингом/вычислениями и просто плюющий буфер кадра на экран. Это хорошо укладывается в современные реалии, от глупых контроллеров дисплея в эмбедовке до могучих числокрушилок-GPU и странных экспонатов в ноутах не снабженных своим видеовыходом вообще. Оно такое уже более-менее готово к встрече с реалиями наблюдаемыми в железяках XXI века.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	206. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 21:36
	nvidia.ko и модуль ядра из Каталиста почему-то лучше знают о GPU, чем KMS с DRM - так как на вид работают тупо быстрее и лучше. ;)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	211. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 24-Мрт-14, 21:54
	Пиндишь. Консоль загрузки с кмс сразу после начала распознаёт и родное разрешение, и количество мониторов. Мне как-то приятнее даже в консоль попасть на 27"-мониторе, чем таращиться (в веса!!!) щель на 14". Зыж Ты не практолог случаем?
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	221. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 25-Мрт-14, 10:06
	#>> работают тупо быстрее > Пиндишь. Нет, ну в чём-то он прав. В этом чём-то он собаку съел. Он дока, профессор и чемпионище!
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	216. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 25-Мрт-14, 01:42
	> nvidia.ko и модуль ядра из Каталиста почему-то лучше знают о GPU, Ну так "это не ваша заслуга, а наша недоработка" (c) ФЭД. Вот у амд модуль в линухе начал работать довольно хорошо. Умеет динамический реклок, ускорение декодирования видео и прочая. Так что как видишь, у них на полном серьезе возникла логичная идея - дедуплицировать работу и убить проприетарный модуль в ядре как таковой. > чем KMS с DRM - так как на вид работают тупо быстрее и лучше. ;) Знаешь, мне такие рассуждизмы очень напоминают ситуацию в природе, когда волки сожрали всех зайцев и ... положили зубы на полку и сдохли от голода, т.к. жрать через некоторое время стало нечего.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	136. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 21:10
	> Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами. Сапожник! Кому это было реально надо - уже много лет использовали. Со сшапшотами. В линухе. Может оно чуть сложнее, но в конечном итоге засчитывается все-таки результат. И, кстати, вон зюзя уже начинает btrfs по умолчанию пихать. Оракл и зюзя коммерческую поддержку оказывать начинают. Ну а что, основные фичи вроде работают. Кстати, если на то пошло, ZFS писали санки. Так что это вообще не разработка бздюков. Сами бздельники смогли родить лишь такой ущербный выпердыш как UFS2. Устройство которого выглядит жалко даже на фоне обычного EXT4. Ничем не примечательного, на секундочку. EXT4 - обычный такой "улучшенный классик", где экстенты и ускоренное индексирование дир более-менее довели до ума. > Всё делают проприетарщики для Linux, но что-то воз и ныне там, в > далёком 2006 году. Как было, так и осталось по большому счёту. Уж не знаю что там у тебя осталось, а у меня теперь с открытым драйвером (раз уж мы о сабже) работают даже достаточно требовательные игрушки, показывая FPS вполне сравнимый с катаглистом. > Концептуально только Android — серьёзное решение. Я уж не знаю какие там концепции, но пингнвин на меня работает. Я благодаря оному $$$ получаю. Мне, наверное, странно жаловаться на несерьезность - пингвин обслуживает все мои нужды. Роутер - пингвин. Смарт - тоже. Дексктоп. Ноут. Сервера. Что я там еще забыл? Вроде всерьез обслуживает, без всяких скидок. Поиграться с ним прикольно, но кроме поиграться он и в местах где внеплановый отвалбашки может стоить мне $$$, опять же. И мне как-то вот не требуется грузиться в максималки. У меня и так все работает. > Intel написал KMS/DRM специально для Linux. Ясен пень. Интел делает ту работу, результат которой им нужен. > Всех бздунов выкинули из комитета Xorg. Так они самоустранились из разработки и по сути спустили процесс на тормозах, по принципу "нас и так все устраивает". Ну и получили то что за этим следует. > Ну и причём тут бзды? Что, должны были подлизывать зад Intel, > как это делали линуксятники? Ух ты, совместно работать над проблемами теперь оказывается называется "подлизывать зад".
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	138. "Компания AMD рассматривает возможность более открытой разраб..."	–5 +/–
	Сообщение от iZEN (ok) on 23-Мрт-14, 21:20
	> EXT4 - обычный такой "улучшенный классик", где экстенты и ускоренное индексирование > дир более-менее довели до ума. dump(8)/restore(8) на подмонтированной с -o rw EXT4 хотя бы работает? >> Ну и причём тут бзды? Что, должны были подлизывать зад Intel, >> как это делали линуксятники? >> Всех бздунов выкинули из комитета Xorg. > Так они самоустранились из разработки и по сути спустили процесс на тормозах, по принципу "нас и так все устраивает". Ну и получили то что за этим следует. "Не давать работать" != "Самоустраниться" > Ух ты, совместно работать над проблемами теперь оказывается называется "подлизывать зад". По-моему, проблемы были только у Intel. У всех остальных разработчиков видеокарт и операционных систем 2D/3D работало замечательно. Потом Intel совместно с Linux-девелоперами объяснили совету X.org, что UMS устарело и нужно делать X.org для Linux KMS, чтобы графическая картинка появлялась сразу, минуя текстовую консоль. Комитетчики на этом вау-эффекте конкретно заморочились и автоматом отсекли другие операционные системы как неподходящие под идеологию Intel. Сейчас ситуация такая же, как и была 7 лет назад: блобы от NVIDIA и AMD ставятся модулями ядра (фактически, работая по преждней UMS-схеме), а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD, надеясь, что AMD поддержит их, портируя Каталист в эту бесперспективную схему.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	144. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Michael Shigorin (ok) on 23-Мрт-14, 22:05
	> dump(8)/restore(8) --- Dump was a stupid program in the first place. Leave it behind. --- http://lwn.net/2001/0503/a/lt-dump.php3 Это правда.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	158. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 00:14
	>> dump(8)/restore(8) > --- > Dump was a stupid program in the first place. Leave it behind. > --- http://lwn.net/2001/0503/a/lt-dump.php3 > Это правда. В Linux своя исключительная "правда", которая в Unix зовётся кривдой. :)) ///--- 17.12.7. Какая программа резервного копирования самая лучшая? dump(8) Точка. Elizabeth D. Zwicky протестировала все программы резервного копирования, обсуждаемые здесь. Беспроигрышным вариантом для сохранения всех ваших данных и особенностей файловых систем UNIX® является dump. Элизабет создала файловые системы, содержащие большое количество необычных элементов (и некоторых не так уж необычных) и тестировала каждую из программ, выполняя резервное копирование и последующее восстановление этих файловых систем. В число необычных элементов входили: файлы с дырами, файлы с дырами и блоком пустого места, файлы с необычными символами в их именах, нечитаемые и незаписываемые файлы, устройства, меняющие свой размер во время резервного копирования, файлы, создаваемые и удаляемые во время копирования и тому подобное. Она представила результаты на конференции LISA V в октябре 1991 года. Посмотрите ссылку на сайте torture-testing Backup and Archive Programs: http://www.coredumps.de/doc/dump/zwicky/testdump.doc.html ---/// http://www.freebsd.org/doc/ru/books/handbook/backup-basics.html
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	160. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 24-Мрт-14, 01:04
	>> Dump was a stupid program in the first place. Leave it behind. > В Linux своя исключительная "правда", которая в Unix зовётся кривдой. :)) [...] > 17.12.7. Какая программа резервного копирования самая лучшая? > dump(8) Точка. Elizabeth D. Zwicky [...] > Она представила результаты на конференции LISA V в октябре 1991 года. Занавес. Когда что-то было изначально криво спроектировано (например, идея доставать данные мимо активной ФС -- фактически реализовывать ФС в юзерспейсе плюс обеспечивать когерентность в блочном уровне/VFS, насколько понимаю) -- оно рано или поздно вылезло.  Интересно, поддерживаются ли dump/restore в нынешних Solaris/AIX. В очередной раз не знаю, с какой стороны Вам начинать на пальцах разжёвывать элементарные вещи -- да, в юниксе были плохие решения.  И помимо обсуждаемого безобразия это ещё и uid==0 с world writable /tmp.  Их немного, но лучше знать.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	166. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-14, 04:15
	>> Она представила результаты на конференции LISA V в октябре 1991 года. > Занавес. У них там походу всегда полшестого и всегда пора пить чай...
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	207. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 21:44
	>>> Она представила результаты на конференции LISA V в октябре 1991 года. >> Занавес. > У них там походу всегда полшестого и всегда пора пить чай... У линуксоидов, походу везде кривизна прослеживается, кроме них самих, поэтому и NIH-синдром развился. В конечном итоге цель более-менее стала ясна: SystemD потихоньку будет перенимать "нужные" функции ядра, и настанет такой момент, что linux kernel можно будет удалить...  :))
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	210. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 21:51
	Я б поспорил, если бы не выглядел так жалко.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	218. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 25-Мрт-14, 04:37
	> NIH-синдром развился. У NIH есть и положительные стороны - иногда софт полезно улучшать. Иначе мы бы так и цеплялись за CP/M и multics. Ну а что, как-то работало же. > В конечном итоге цель более-менее стала ясна: SystemD потихоньку будет > перенимать "нужные" функции ядра, и настанет такой момент, что linux kernel > можно будет удалить...  :)) Это вообще феерическое по уровню ламерства заявление.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	186. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Stax (ok) on 24-Мрт-14, 16:50
	Нет, dump/restore в Solaris 11 нет в принципе. Бэкап fs - zfs dump/restore, бэкап файлов - рекомендован cpio, для более избирательных случаев в комплекте идут rdiff-backup и areca. Из сторонних инструментов превосходно работает dar свежих версий. В AIX dump/restore сомневаюсь, что еще есть. Судя по документации, IBM рекомендует совсем другие инструменты (для файлов - tar и cpio, для всей ОС - специфичные для тамошней системы томов mksysb и savevg): http://www.ibmsystemsmag.com/aix/administrator/backuprecover.../ В любом случае, dump/restore настолько непереносим (между разными ОС, разными архитектурами процессора в одной ОС, иногда даже разными ФС в одной ОС), что очень хорошо, что он сдох...
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	194. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Michael Shigorin (ok) on 24-Мрт-14, 19:36
	> Нет, dump/restore в Solaris 11 нет в принципе. Спасибо. > В любом случае, dump/restore настолько непереносим (между разными ОС, > разными архитектурами процессора в одной ОС, иногда даже разными ФС в одной ОС), > что очень хорошо, что он сдох... Вот и пытался объяснить гостю с windows 8...
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	204. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 21:04
	XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо?
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	209. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 21:49
	XFS — единственное что и использую на серверах (не под ораклом пока). Но дамп/ресторе не пользуюсь. Она (как и все) кэши не учитывает. А не_консистентный дамп я могу получить и банальным копированием файлов плюс редологи.
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	223. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 14:50
	Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	229. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 25-Мрт-14, 15:35
	> Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. А зачем тебе "консистентный набор блоков ФС"? Консистентный набор блоков != консистентное состояние файлов с точки зрения софта. Человеков по идее интересует консистентный набор файлов в бэкапе. Т.е. некое состояние, которое можно раскатать и чтобы это потом еще и работало, желательно без спецэффектов. А вот тут возможны варианты. В конечном итоге все упирается в то, что софт понятия не имеет о том что его бэкапят, поэтому он делает с файлами все что хочет. Бэкап "на горячую" подхватывает файлы в состоянии "как есть" и это весьма зависит от логики работы программ. Никаких гарантий что для произвольной софтины такой набор файлов будет рабочим - нет! В местах где это реально критично, типа баз данных - делают отдельные программные интерфейсы через которые можно отсигналить движку о бэкапе, чтобы он на время угомонился и/или получить выгрузку заведомо консистентных данных для бэкапа "сбоку".
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	230. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 16:01
	> Консистентный набор блоков != консистентное состояние файлов с точки зрения софта. Видишь ли, традиционно софт в Unix работает с файлами, сокетами, каналами (pipe). И на нормальных классических ФС dump/restrore сохраняют/восстанавливают на бэкапный/новый носитель их в том же виде, в котором их ожидают увидеть Unix-программы, которые с ними работают непосредственно. В ZFS аналог такого механизма — send/receive. > Человеков по идее интересует консистентный набор файлов в бэкапе. И это тоже в том числе. > Т.е. некое состояние, которое можно раскатать и чтобы это потом еще и работало, желательно без спецэффектов. Похоже, на неотмонтированной Ext4, в отличие от XFS и UFS2, не может работать dump/restore без "спецэффектов" (если вообще может). >  А вот тут возможны варианты. dd, например. Вам больше ничего не остаётся, похоже, для переноса ФС точь-в-точь на новый носитель, с последующим обязательным fsck. > Бэкап "на горячую" подхватывает файлы в состоянии "как есть" и это весьма зависит от логики работы программ. Никаких гарантий что для произвольной софтины такой набор файлов будет рабочим - нет! Я вам не предлагаю делать dd RAW-носителя живой СУБД — ничего, кроме лапши, вы не получите от этого. СУБД должна иметь собственные механизмы бэкапа с учётом запуска/остановки своих транзакций. Конкретно в POSIX/Unix для ЗРЕЛЫХ файловых системы разработан и действует стандартный механизм бэкапа метаданных, файлов, сокетов, каналов — утилиты dump/restore. А что-то другое — это именно что-то другое, которое работает на тех ФС, которые не поддерживают dump/restore, например, это FAT32.
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	240. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-14, 23:03
	> Видишь ли, традиционно софт в Unix работает с файлами, сокетами, каналами (pipe). Спасибо, капитан. > И на нормальных классических ФС dump/restrore сохраняют/восстанавливают на > бэкапный/новый носитель их в том же виде, в котором их ожидают увидеть > Unix-программы, которые с ними работают непосредственно. Как бы это сказать? Dump/restore довольно специфичная штука, реально нужная только в экзотических случаях. Если надо просто бэкап файлов без лишних заморочек - tar хватит выше крыши и он в сто раз удобнее и умеет уйму всего, к тому же от системы и ФС не зависит. Некузяво данные привязывать к 1 конкретной ФС и ОС. Иногда, если вопрос на миллион, надо "вон тот документ" позарез и прочая - будет очень кстати если бэкап, ну или хотя-бы его часть раскатается "на том что под руку попалось". Есть разные варианты бэкапирования и восстановления, знаешь ли. Гвоздить безбашенно одним случаем во все дырки - глуповато, знаешь ли. > В ZFS аналог такого механизма — send/receive. И в btrfs. Только вот это не средство для ежедневного бэкапа документиков из /home, если что :). >> Человеков по идее интересует консистентный набор файлов в бэкапе. > И это тоже в том числе. Я не вижу - где в твоих увещеваниях это обеспечивается. > Похоже, на неотмонтированной Ext4, в отличие от XFS и UFS2, не может > работать dump/restore без "спецэффектов" (если вообще может). Честно говоря - без понятия. Ты мне объяснишь нафига именно так бэкапаться? > dd, например. Вам больше ничего не остаётся, похоже, для переноса ФС точь-в-точь > на новый носитель, с последующим обязательным fsck. Этот метод делает довольно много допущениий о носителе в пункте назначения и не является типовым/практичным способом бэкапа. > Я вам не предлагаю делать dd RAW-носителя живой СУБД — ничего, кроме > лапши, вы не получите от этого. СУБД должна иметь собственные механизмы > бэкапа с учётом запуска/остановки своих транзакций. Как ни странно, риск получить черти-какие данные в файле есть и в иных случаях. > Конкретно в POSIX/Unix для ЗРЕЛЫХ файловых системы разработан и действует стандартный механизм > бэкапа метаданных, файлов, сокетов, каналов — утилиты dump/restore. А что-то другое > — это именно что-то другое, которое работает на тех ФС, которые > не поддерживают dump/restore, например, это FAT32. Попробуй своим зрелым перезрелым забэкапать диск-в-файле у виртуалки, подивись вермишели.
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	232. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 25-Мрт-14, 17:49
	>Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck. Окуенный плюс. А то, что этот дамп будет с битыми данными и нафиг не нужен — это что, мелочи? Ты случаем не маркетинговом отделе мс работаешь?
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	237. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 19:34
	>>Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck. > Окуенный плюс. > А то, что этот дамп будет с битыми данными и нафиг не нужен — это что, мелочи? Это другой уровень задач. ФС в общем случае не решает задачи сохранения транзакционности пользовательских данных, она следит только за целостностью метаданных и отдельных файлов. Файлы не есть синоним данных, как же вы это никак не поймёте?! "Данные" — это осмысленная сущность в тех механизмах, в которых они обрабатываются. Для ФС "данными" являются файлы, метаинформация. Для пользователя "данными" являются, к примеру: каталог почтового клиента с файлами почтовой базы, набор реляционных таблиц с информацией в файловой РСУБД, Web-документы (*.html, *.jpeg, *.js, *.css), документы текстового процессора, проекты среды программирования, проекты фото- и видео-редакторов, состоящих из нескольких согласованных между собой файлов — этими сущностями должны управлять соотвествующие инструменты. Если пользовательские данные во время бэкапа открыты для редактирования, то dump не виновата, что сохранила "не то".
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	241. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 25-Мрт-14, 23:26
	> Это другой уровень задач. ФС в общем случае не решает задачи сохранения транзакционности пользовательских данных Именно. И именно поэтому она также не играет роли в создании бэкапов и архивов. Если ты этого до сих пор не понял, то мне жаль твоих работодателей (будь ты админом. И вообще, с какого перепуга ты тут админов "учить" начал?) Зыж > Файлы не есть синоним данных, как же вы это никак не поймёте?! Идиотское утверждение. Для ФС — это данные. Были, есть и будут. И не более.
	Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

	244. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от цирроз (ok) on 27-Мрт-14, 12:17
	в интернетах так заведено: кто меньше всех знает - старается давать советы, или учить ;)
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	217. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-14, 04:34
	> XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо? Не то чтобы "плохо", просто нишевая хрень, носиться с которой как с писанной торбой - совершенно нет причин, имхо.
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	224. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 15:00
	>> XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо? > Не то чтобы "плохо", просто нишевая хрень, носиться с которой как с > писанной торбой - совершенно нет причин, имхо. Что, альтернатива лучше? Сколько этих альтернатив, которые имеют свои кривые стороны? И зачем они нужны, если dump/restore — это решение бэкапа ФС в Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо. Если в Linux такое не приветствуется, то это, считай, вторая винда с "многообразием разнообразных".
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	233. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 25-Мрт-14, 17:54
	> И зачем они нужны, если dump/restore — это решение бэкапа ФС в Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо. Вот поэтому и есть tar. Или pax. А фс-зависимые утилиты идут лесом. зыж >app-arch/pax >     Available versions:  3.4.12.16 >     Installed versions:  3.4.12.16(16:35:58 07.08.2013) >     Homepage:            http://www.openbsd.org/cgi-bin/cvsweb/src/bin/pax/ >     Description:         pax (Portable Archive eXchange) is the POSIX standard archive tool Опенбздишники с тобой не согласны.
	Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

	236. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 19:23
	>> И зачем они нужны, если dump/restore — это решение бэкапа ФС в Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо. > Вот поэтому и есть tar. tar работает гораздо медленнее dump.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	242. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 25-Мрт-14, 23:28
	А рсинк нет. И? К тому же tar'ом я могу бэкапить избирательно, что и делается в подавляющем большинстве случаев. Так что враньё.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	243. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 26-Мрт-14, 04:47
	> tar работает гораздо медленнее dump. Ну тогда бэкап в /dev/null - по любому чемпион.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	247. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 27-Мрт-14, 17:53
	> tar работает гораздо медленнее dump. А автомобиль ездит медленнее чем летает ракета. Но назвать ракеты стандартным средством передвижения я бы не рискнул.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	249. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 27-Мрт-14, 18:44
	> Что, альтернатива лучше? Сколько этих альтернатив, которые имеют свои кривые стороны? > И зачем они нужны, если dump/restore — это решение бэкапа ФС в > Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо. Изя, Вы хоть сами-то поняли, что спорите с самим собой? dump/restore дублируют реализацию ФС в ядре по определению. EOT
	Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

	152. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 22:58
	>линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD Intel вроде бы еще отказался пилить Gallium3D для своих интеграшек.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	197. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 19:56
	> Intel вроде бы еще отказался пилить Gallium3D для своих интеграшек. Да. У них свое собственное добро. Как бы их право. Есть мнение что за счет этого оверхед ниже.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	161. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 24-Мрт-14, 01:05
	> а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD Надо же, главное -- не рассказывать ноуту, с которого и пишу.  А то тут как раз fullhd и немножко на порядок больше.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	225. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 15:03
	>> а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD > Надо же, главное -- не рассказывать ноуту, с которого и пишу. А вы с ноутом общаетесь, что-то ему рассказываете? Ну надо же.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	227. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 25-Мрт-14, 15:08
	>>> c 5-6 FPS в 3D на Full HD >> не рассказывать ноуту, с которого и пишу. > А вы с ноутом общаетесь, что-то ему рассказываете? Ну надо же. В Новости на Главной! iZEN нипонял сарказма, направленного на него.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	235. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Карбофос (ok) on 25-Мрт-14, 19:21
	а зачем обыденное событие отмечать в новостях?
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	162. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 03:11
	> dump(8)/restore(8) на подмонтированной с -o rw EXT4 хотя бы работает? Без понятия. Ты лучше скажи какая цель этого? У меня нет цели в жизни "запустить программу dump на EXT4 в rw". Я предпочитаю какие-то осмысленные цели, понятные мне и ведущие к каким-то практически полезным результатам. Нельзя ли озвучить цель этой возни в человекочитаемом формате? Ну, чтобы иметь дело с проблемой - надо для начала понимать в чем она состоит. Что мы хотим получить. Что получается по факту. Какие отличия имеются и что надо изменить. > "Не давать работать" != "Самоустраниться" Пришел интел и отобрал у бсдшников редакторы и компиляторы? Прислали надзирателей, обещающих расстрелять за использование BSD? Или как это выглядело? Ах, интел и прочие всего лишь не пожелали чтобы пингвин вылетал на обочину прогресса и вместо этого стали актуализировать состояние графической системы? Вот гады. > По-моему, проблемы были только у Intel. У всех остальных разработчиков > видеокарт и операционных систем 2D/3D работало замечательно. А мне нравится идея KMS+DRM. Нечто такое давно напрашивалось. Вырисовывается логичная и стройная подсистема, компоненты логично расположены в соответствии с своими задачами и устройством современного железа. > объяснили совету X.org, что UMS устарело и нужно делать X.org для > Linux KMS, чтобы графическая картинка появлялась сразу, минуя текстовую консоль. Такое понятие как "текстовая консоль" не присутствует у половины устройств, а там где есть - эмуляция для легаси. Так что если уж мы о том чтобы рулить видеокартой из открытых драйверов - про VGAшные сущности пора забыть. > Комитетчики на этом вау-эффекте конкретно заморочились и автоматом > отсекли другие операционные системы как неподходящие под идеологию Intel. Да вообще удоды, хотят нормальную графическую систему, а не "как у бсд и замшелых *никсов" > Сейчас ситуация такая же, как и была 7 лет назад: блобы от NVIDIA и AMD > ставятся модулями ядра (фактически, работая по преждней UMS-схеме), Блобмейкеры в ядре Linux и остальных частях открытого графического стека никому не интересны. Пусть у них голова и болит. У амд вот видимо начали зачатки здравого смысла прорезаться. > а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD, Уж не знаю какой ты там кактус жуешь, а у меня стабильные 60FPS в FullHD в xonotic, на настройках high. Да, это - с открытым драйвером от AMD. Ну подумаешь, соврал на порядок. Это ж изя. > надеясь, что AMD поддержит их, портируя Каталист в эту бесперспективную схему. Ну то-есть, ты хочешь сказать что бздельники лошпеды и работают на мусорный бак, портируя себе "эту бесперспективную схему"?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	205. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 21:11
	>> dump(8)/restore(8) на подмонтированной с o rw EXT4 хотя бы работает? > Без понятия. Ты лучше скажи какая цель этого? Делать бэкап файловой системы, не отмонтируя или предварительно отмонтируя - неважно - главное, однообразно и очевидным образом. > У меня нет цели > в жизни "запустить программу dump на EXT4 в rw". Я предпочитаю > какие-то осмысленные цели, понятные мне и ведущие к каким-то практически полезным > результатам. Нельзя ли озвучить цель этой возни в человекочитаемом формате? Ну, > чтобы иметь дело с проблемой - надо для начала понимать в > чем она состоит. Что мы хотим получить. Что получается по факту. > Какие отличия имеются и что надо изменить. А сейчас ты как делаешь бэкапы корневой ФС?
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	214. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 22:10
	> А сейчас ты как делаешь бэкапы корневой ФС? Таром я делаю. Потом загоняю в черут (вообще-то сразу через пайп), устанавливаю нужный сервис и вот, новая виртуалка для ксена готова. Овер 50 в продакшене уже таких.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	215. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 25-Мрт-14, 00:28
	> главное, однообразно и очевидным образом. Гланды паяльником дальней дорогой.  Если Вы до сих пор не поняли уже сказанного -- спросите кого-нибудь, кто понимает в администрировании юниксообразных и кому доверяете.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	219. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-14, 05:01
	> Делать бэкап файловой системы, не отмонтируя или предварительно отмонтируя - неважно - Из простейших вариантов - tar, например. Если этого мало - вариантов есть. На ремотную машину, с передачей только дельты можно просто rsync делать. Бывают более навороченные бэкапные софтины, на все вкусы, запросы и умения. Что опенсорсные, что всякие монстрики от всяких проприерасов типа симантека. Если надо нечто крутое, типа горячего бэкапа БД без остановки сервиса, и чтобы база при этом еще и консистентрая была - у баз обычно есть какие-то свои интерфейсы для таких вещей. Без влезания в специфику ты все-равно корректно бэкапать базы "онлайн" не сможешь. Ну то-есть ты можешь попытаться, но когда ты заметишь что бэкап неконсистентный и с тебя снимут стружку за факапнутую базу - ты сам себе баклан. > главное, однообразно и очевидным образом. Одной большой кнопкой "сделайте мне за...сь"? Мечтать не вредно. Тем не менее, при минимальном понимании семантики работы с файлами ты можешь вдруг внезапно осознать пару простых истин. 1) Софт может менять файлы во время бэкапа, если ты живую систему бэкапишь в rw. 1.1) Следствие: отнюдь не факт, что софт будет счастлив получить половину старых и половину новых файлов, которые в таком бэкапе образовались. 1.2) Борьба с этим явлением - отдельное приключение. Можно в принципе заморозить запись на ФС и бэкапать без помех. Но I/O на некоторое время встанет колом, это уже "не совсем онлайновый" бэкап и не совсем rw, в общем нишевая хрень для специальных случаев. 2) А с чего ты взял что софт вообще в курсе что его файлы бэкапают? И кто сказал что "сию секунду" файлы у этого софта вообще были в консистентном состоянии на диске? Кто это гарантировал и как это было обеспечено? Глобального общесистемного сигнала "чуваки, мы тут ща все бэкапать будем, а ну все дружненько приведите свои файлы в консистентное состояние и не трогайте следующие 5 минут!" - нету! Для софта где это реально критично и чревато факапами, типа СУБД - лепят отдельные интерфейсы, специфичные для такого софта. В таких случаях придется RTFMать весьма отдельно как оно у них сделано и кто умеет все это использовать в человеческом виде. > А сейчас ты как делаешь бэкапы корневой ФС? Например, tar'ом иногда бэкаплю нужные диры оттуда. Но это в допущении что это более-менее обычные файлы которые большую часть времени в консистентном состоянии. Если ты так будешь БД какую-нибудь на горячую бэкапать - ну извини, получшиь то что и должен.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	222. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 25-Мрт-14, 11:58
	> Бывают более навороченные бэкапные софтины, на все вкусы, запросы и умения. О чём можно говорить про бэкап с человеком, который ссылается на 1991 год и не понимает разницы в скорости роста пропускной способности и объёма носителей с тех пор?.. Хорошая метрика "на глазок" -- время полного чтения одного носителя.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	226. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 15:07
	>> Бывают более навороченные бэкапные софтины, на все вкусы, запросы и умения. Бывают бэкапилки Windows... > О чём можно говорить про бэкап с человеком, который ссылается на 1991 год и не понимает разницы в скорости роста пропускной способности и объёма носителей с тех пор?.. А что с тех пор изменилось в классических файловых системах? Они разве не отмасштабировались на современные требования пропускной способности, многоядерности процессоров, большого объёма данных? Тогда, простите, как вы с ними работаете, если у вас до сих пор нет подобной ZFS в продакшене, а только "классика"?! > Хорошая метрика "на глазок" -- время полного чтения одного носителя. У вас носитель "однозадачный" и/или требует монопольного доступа при бэкапе данных?
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	231. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 25-Мрт-14, 16:22
	> Бывают бэкапилки Windows... Бывают. И даже простой ntbackup выделяет известные ему виды баз данных из общей массы, например. Разумеется только MSовские. А что не выделяет... ну ... "какой-то" бэкап тебе сделали! А дальше проблемы индейцев шерифа не волнуют, эхехе. > если у вас до сих пор нет подобной ZFS в продакшене, Изя, выкинь саночный маркетинговый булшит из головы. > У вас носитель "однозадачный" и/или требует монопольного доступа при бэкапе данных? Нет. В этом то как раз и проблема - софт может делать там все что пожелает. Откуда вытекает что в общем случае корректность бэкапа вообще не гарантирована.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	228. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 15:29
	>[оверквотинг удален] > Что опенсорсные, что всякие монстрики от всяких проприерасов типа симантека. Если > надо нечто крутое, типа горячего бэкапа БД без остановки сервиса, и > чтобы база при этом еще и консистентрая была - у баз > обычно есть какие-то свои интерфейсы для таких вещей. Без влезания в > специфику ты все-равно корректно бэкапать базы "онлайн" не сможешь. Ну то-есть > ты можешь попытаться, но когда ты заметишь что бэкап неконсистентный и > с тебя снимут стружку за факапнутую базу - ты сам себе > баклан. >> главное, однообразно и очевидным образом. > Одной большой кнопкой "сделайте мне за...сь"? Для любой файловой системы в терминах операционной системы — ДА! > Мечтать не вредно. Почему нет, если любая файловая система для пользователя выглядит однообразно благодаря механизму монтирования и POSIX-операциям с ней? >[оверквотинг удален] > при минимальном понимании семантики работы с файлами ты можешь вдруг внезапно > осознать пару простых истин. > 1) Софт может менять файлы во время бэкапа, если ты живую систему > бэкапишь в rw. > 1.1) Следствие: отнюдь не факт, что софт будет счастлив получить половину старых > и половину новых файлов, которые в таком бэкапе образовались. > 1.2) Борьба с этим явлением - отдельное приключение. Можно в принципе заморозить > запись на ФС и бэкапать без помех. Но I/O на некоторое > время встанет колом, это уже "не совсем онлайновый" бэкап и не > совсем rw, в общем нишевая хрень для специальных случаев. Что мешает остановить софт, который меняет файлы? > 2) А с чего ты взял что софт вообще в курсе что > его файлы бэкапают? И кто сказал что "сию секунду" файлы у > этого софта вообще были в консистентном состоянии на диске? Кто это > гарантировал и как это было обеспечено? Глобального общесистемного сигнала "чуваки, мы > тут ща все бэкапать будем, а ну все дружненько приведите свои > файлы в консистентное состояние и не трогайте следующие 5 минут!" - > нету! Открой для себя Single User Mode. Или у вас оно давно не работает? Ну тогда прибивай процессы, которые активно пишут в бэкапируемую ФС, чтобы действительно получить консистентный бэкап данных (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт). Ещё один способ: отмонтировать ФС и снимать данные dd — линуксоиды так обычно поступают, не зная вообще про dump/restore. Когда им рассказываешь, что некоторые классические ФС *nix поддерживают dump/restore вместо посекторного снятия информации с носителя, внезапно удивляются такой возможности. > Для софта где это реально критично и чревато факапами, типа > СУБД - лепят отдельные интерфейсы, специфичные для такого софта. В таких > случаях придется RTFMать весьма отдельно как оно у них сделано и > кто умеет все это использовать в человеческом виде. Бэкапить сложные СУБД — не входит в свойства файловой системы, так как ФС ничего не знает о структуре баз и не умеет управлять метаинформацией и запущенными транзакциями СУБД. Это "внутриконтейнерная" задача — задача самой СУБД, которая тоже, в свою очередь, может и не иметь никакого понятия о ФС, располагаться на RAW-томе. Задача администратора разграничивать области ответственности механизмов хранения и управления данными: - ФС должна заботиться о целостности и консистентности собственной метаинформации и файлах; - dump/restore должны работать с ФС, не делая из неё лапши; - СУБД должна обеспечить сохранность собственных данных и данных пользователей, которые под её управлением; - вообще, пользовательские процессы ответственны за данные пользователя, с которыми они работают, независимо от того, какой носитель они используют. >> А сейчас ты как делаешь бэкапы корневой ФС? > Например, tar'ом иногда бэкаплю нужные диры оттуда. dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на ленточные носители и в файлы.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	234. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 25-Мрт-14, 17:59
	> Что мешает остановить софт, который меняет файлы? Дурость айзена мешает. зыж Ты понимаешь, что только что договорился до single-mode? Ну не кретин ли.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	238. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-14, 21:00
	>> Одной большой кнопкой "сделайте мне за...сь"? > Для любой файловой системы в терминах операционной системы — ДА! Ну, мечтай. Даже крЮтые коммерческие решения обычно подразумевают что за монитором компетентный в своей области человек, понимающий как бэкапать/ресторить и какие проблемы могут быть. > Почему нет, если любая файловая система для пользователя выглядит однообразно благодаря > механизму монтирования и POSIX-операциям с ней? Потому что нет никакого универсального механизма информирования софта на горячую что "а сейчас мы будем тебя бэкапать, приведи-ка свои файлы в консистентное состояние, с которым ты потом точно сможешь работать, и ничего не трогай до зеленого свистка вверх". Проводя бэкап RW файловой системы с работающим софтом этот момент следует четко понимать. > Что мешает остановить софт, который меняет файлы? А тут мы приближаемся к оффлайновому бэкапу/RO, только сами педалируем корректность состояния файлов на свой страх и риск. В смысле, прерывание сервиса - имеет место быть. Значит бэкап уже не онлайновый. И одной кнопки уже не получается. Получается что надо более-менее компетентного "оператора бэкапов", который убедится в корректности бэкапа наиболее ценных вещей. Понимая как подшефный софт работает и как его сбэкапать корректно. Ну это я про нормальный энтерпрайз, а не твою супер-инсталляцию о трех ноутбучных дисках в ZFS пуле. > Открой для себя Single User Mode. С таким успехом можно и в r/o монтировать и не париться - так уж точно никто не запишет. Ни 1 юзер, ни много юзеров. Только вот прерывание сервиса имеет место быть. > Или у вас оно давно не работает? Ну тогда прибивай процессы, которые активно > пишут в бэкапируемую ФС, чтобы действительно получить консистентный бэкап данных Иногда как-то так и приходится делать. Ну вот например, есть виртуалка. С диском-в-файле. Как бы удачи сбэкапать во время работы виртуалки диск-в-файле в консистентном виде. У него понятие консистентности - очень сложный вопрос. Даже если прямо сейчас host записал все что хотела VM на диск, у VM может быть кэш в памяти. И то что она через минуту захочет его скинуть на диск - мы про это не знаем. Даже если мы заморозим I/O поставив виртуалку на паузу, это предотвратит лишь изменение файла прямо во время копирования, но еще вовсе не означает что ФС внутри этого файла была в консистентном состоянии по мнению guest OS. Ну как, ты еще хочешь поговорить о консистентности данных при горячем бэкапировании? Ну попробуй. > (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт). Угу, щаз. Вон я тебе пример с виртуалкой и диском-в-файле привел. Попробуй диск-в-файле таким макаром корректно сбэкапать, не останавливая виртуалку. Не забудь доложить как получилось :). > Ещё один способ: отмонтировать ФС и снимать данные dd Можно просто ремоунт в ридонли, если уж на то пошло. Вот только поблочный бэкап носителя - штука нишевая, нужная в сильно некоторых случаях. Без специальных приседаний это к тому же нерационально расходует место на бэкапном носителе. > — линуксоиды так обычно поступают, не зная вообще про dump/restore. > Когда им рассказываешь, что  некоторые классические ФС *nix поддерживают > dump/restore вместо посекторного снятия информации с носителя, > внезапно удивляются такой возможности. Я скорее удивляюсь тому что изя пытаетсся меня удивить "крутыми фичами", при том тушуясь объяснить чего такого крутого и необычного в этих фичах есть, собственно :). Впрочем, это же изя... > Бэкапить сложные СУБД — не входит в свойства файловой системы, так как > ФС ничего не знает о структуре баз и не умеет управлять > метаинформацией и запущенными транзакциями СУБД. Более того - ФС ничего не знает о формате файлов и логике работы и всех остальных программ. Прикинь, какая подстава?! А кто вообще гарантирует что в произвольно взятый момент времени содержимое файла вообще осмысленное? Для программ которые не запущены это еще можно предположить, из соображений что они как-то намеревались стартовать с этим набором данных. А в остальных случаях... > Это "внутриконтейнерная" задача — задача самой СУБД, которая тоже, > в свою очередь, может и не иметь никакого понятия о ФС, располагаться на RAW-томе. Самое забавное что такие рассуждения можно применить к практически всем программам. > - ФС должна заботиться о целостности и консистентности собственной метаинформации и файлах; В этом месте даже изя начинает догадываться, что консистентность ФС, ее метаданных и блоков данных ... ничего не говорит о консистентности данных в файлах. Хе-хе. > - dump/restore должны работать с ФС, не делая из неё лапши; Что ты к ним привязался? И кому должны? Они что-то у кого-то занимали? Или чего? > работают, независимо от того, какой носитель они используют. Ясен перец. Поэтому в общем случае бэкап на горячую требует понимания чего бэкапается и насколько это будет (не)консистентным. Вон я тебе пример с диском виртуалки привел. Это не база. Но это не значит что ты его сбэкапаешь на горячую корректно. > dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на > ленточные носители и в файлы. Честно говоря я просто не понимаю что ты хочешь достичь используя dump/restore и почему для этого надо использовать именно их. А бэкапаются на ленты нынче в основном махровые энтерпрайзники, которые могут потратить туеву хучу денег на современный стример и кассеты к нему. Остальным проще на жесткие диски бэкапаться по моим наблюдениям. Так что tar давно уже не только про "tape".
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	239. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от iZEN (ok) on 25-Мрт-14, 22:06
	>[оверквотинг удален] > софтом этот момент следует четко понимать. >> Что мешает остановить софт, который меняет файлы? > А тут мы приближаемся к оффлайновому бэкапу/RO, только сами педалируем корректность состояния > файлов на свой страх и риск. В смысле, прерывание сервиса - > имеет место быть. Значит бэкап уже не онлайновый. И одной кнопки > уже не получается. Получается что надо более-менее компетентного "оператора бэкапов", > который убедится в корректности бэкапа наиболее ценных вещей. Понимая как подшефный > софт работает и как его сбэкапать корректно. Ну это я про > нормальный энтерпрайз, а не твою супер-инсталляцию о трех ноутбучных дисках в > ZFS пуле. Ну, не знаю. Лично у меня Запущенный Firefox с X'ами не крашатся, когдя я их перекомпилирую и обновляю используя для этого терминал Xfce. При этом идёт вполне реальная подмена занятых/работающих файлов приложений на их новые версии. ;) >> Открой для себя Single User Mode. > С таким успехом можно и в r/o монтировать и не париться - > так уж точно никто не запишет. Ни 1 юзер, ни много > юзеров. Только вот прерывание сервиса имеет место быть. Хомячку открыли глазки и показали, а ему этого не надо, так как достаточно rsync и dd (и tar) в большинстве его невыразительных случаях. Ничего — линукс можно ведь просто переустановить — хуже точно не будет! > Ну вот например, есть виртуалка. С > диском-в-файле. Как бы удачи сбэкапать во время работы виртуалки диск-в-файле в > консистентном виде. А если электричество вырубится, виртуалке всё, кранты? :)) >> (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт). > Угу, щаз. Вон я тебе пример с виртуалкой и диском-в-файле привел. Попробуй > диск-в-файле таким макаром корректно сбэкапать, не останавливая виртуалку. Не забудь доложить > как получилось :). Я, как последовательный в своих действиях админ, внутри виртуалки средствами её же утилит сделаю dump/restore её ФС (конечно, если она это поддерживает), файлы дампов заберу из неё. Разрешаешь? Я ж не лазаю с hex-эдитором по файлам СУБД, редактируя неверные с моей точки зрения пользовательские данные. Так и тут. ;) >> Ещё один способ: отмонтировать ФС и снимать данные dd > Можно просто ремоунт в ридонли, если уж на то пошло. Вот только > поблочный бэкап носителя - штука нишевая, нужная в сильно некоторых случаях. > Без специальных приседаний это к тому же нерационально расходует место на > бэкапном носителе. Да, да. Я привёл почти все варианты решения проблем с несуществующим dump/restore на Ext4. Очевидно, лично для тебя ни один из них не имеет смысла, потому как ты даже не задумывался о такой возможности, существующей ШТАТНО в немногих классических (да и новых) ФС, используемых в продакшене даже под Linux. ;) >> - dump/restore должны работать с ФС, не делая из неё лапши; > Что ты к ним привязался? И кому должны? Они что-то у кого-то занимали? Или чего? Речь зашла о крутости Ext4, которая не имеет фич, присущих классическим промышленным ФС. >> dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на >> ленточные носители и в файлы. > Честно говоря я просто не понимаю что ты хочешь достичь используя dump/restore и почему для этого надо использовать именно их. Прости пожалуйста. Я всю дорогу талдычу о такой пустяковине, как быстрый, простой и очевидный бэкап файлов и метаинформации ФС стандартными средствами. > А бэкапаются на ленты нынче в основном махровые энтерпрайзники Бэкапиться на ленты совсем необязательно. Можно забэкапить дамп файловой системы в файл. Кстати, файлы можно пометить флагом "nodump", если их не нужно включать в дамп — так будет сохраняться только то, что нужно. > Так что tar давно уже не только про "tape". tar работает медленнее dump.
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	245. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 27-Мрт-14, 17:43
	> Ну, не знаю. Лично у меня Запущенный Firefox с X'ами не крашатся, > когдя я их перекомпилирую и обновляю используя для этого терминал Xfce. Казалось бы, при чем тут бэкапы и даже ФС? > При этом идёт вполне реальная подмена занятых/работающих файлов приложений на их > новые версии. ;) Софт обычно или вгружает данные в RAM и ему до лампочки стирание файла, или файл остается открытым пока он используется. Если стереть открытый файл, он не уничтожается. У него пропадет имя, новый файл может занять имя. Но старый файл продолжит существовать пока его не закроют все, он будет доступен по существующим дескрипторам. Деаллокация занимаемого файлом места будет отложена до момента когда файл перестанут использовать. Поэтому глюков меньше чем можно ожидать: старая копия удержит старые используемые файлы, ставшие невидимыми, а новая будет использовать новые копии. Тем не менее, если ты думаешь что на глюки при этом совсем невозможно нарваться - а фиг тебе. Я иногда по мелочи выигрывал в такие лотереи, хотя ничего особо ужасного не случалось. Но это в принципе рандом. За корректность работы произвольной программы при таких фокусах никто не поручится головой. >> Только вот прерывание сервиса имеет место быть. > Хомячку открыли глазки и показали, а ему этого не надо, Ты немного путаешь ситуацию ;). Корм тут - ты. Не кошачий, а троллиный. Почему? Я не стану настаивать что я гуру: есть куда более крутые специалисты. Но я понимаю базовые основы семантики работы с файлами, почему они такие, как это трансформируется в активность ФС, ОС и железа, etc. Поэтому для меня оно как раз вполне логично и предсказуемо, в отличие от изенов и нагуалов. И уж поверь, я в состоянии правильно сбэкапать мои данные без твоих подсказок из разряда "долбани в бубен 3 раза, потом камлай шибко". Мои действия осмысленны и обоснованы. Этим мы и отличаемся. Я компоную мои действия не на основе чтения какого-то древнего шита 1991 года, а на основе моего понимания того как все это работает. > так как достаточно rsync и dd (и tar) в большинстве его невыразительных случаях. А какие у меня должны быть выразительные случаи? Ты ожидал увидеть у меня крутую СУБД? Или чего? Ну я тебе пример с диском виртуалки подогнал. > Ничего — линукс можно ведь просто переустановить — хуже точно не будет! Это изен пытается троллить, чтоли? Или просто тупит, как обычно? > А если электричество вырубится, виртуалке всё, кранты? :)) Примерно на том же уровне что и обычному компьютеру, если не наглеть с unsafe буферизацией диска-в-файле. > Я, как последовательный в своих действиях админ, внутри виртуалки средствами её же > утилит сделаю dump/restore её ФС (конечно, если она это поддерживает), Честно говоря, в именно этом случае мне проще бэкапнуть виртуалку целиком - в отличие от основной системы диск VM относительно небольшой. А рестор состояния виртуалки в нормальной ситуации делается за несколко секунд, путем отката на снапшот. Бэкап надо лишь на случай когда диск побился, etc. Нужно не чаще чем запасной парашют. Только вот фигово если запасной парашют потребовался, а его нет. > по файлам СУБД, редактируя неверные с моей точки зрения пользовательские данные. > Так и тут. ;) Флаг в руки. Как на мой вкус - многовато возни с одним хостом. Если системный 80Гб раздел с SSD дампить целиком меня ломает, то бэкапнуть 2Гб диск-в-файле виртуалки я могу. И рестор займет в случае чего разумное время. Хотя в VM большинство факапов откатывается снапшотной механикой, бэкап лишь на случай если это не получилось. В данном случае я считаю что минимизация сущностей ("один файл = бэкап всей VM") перевешивает некую неэффективность. К тому же бэкапаются и все снапшоты, что позволяет быстрый рекавери виртуалки в нужное состояние из любой позы. > Я привёл почти все варианты решения проблем с несуществующим dump/restore на Ext4. А самый очевидный, логичный и универсальный tar почему-то забыл. > имеет смысла, потому как ты даже не задумывался о такой возможности, > существующей ШТАТНО в немногих классических (да и новых) ФС, используемых в > продакшене даже под Linux. ;) Если честно, при бэкапировании чего либо я не очень хочу себе греть голову вопросом какая там ФС и на какую ФС это потом можно будет отресторить без головняка. Если ты в танке, мои требования к бэкапам: 1) Простота бэкапа/рестора. Эти операции не должны требовать много моего внимания. Я не full-time бэкап-оператор. Поэтому вот так. 2) Разумная эффективность. Я не гоню на пожар, но рестор 10Гб в течение 2 часов меня не устроит. И размер одного бэкапа по 80Гб на машину - тоже. Так что влобовую dd SSD я делать не буду. А вот 2Гб диск-в-файле виртуалки могу и целиком бэкапнуть. 3) Доступность данных. Если все умерло и вообще выгорело синим пламенем, я должен иметь возможность вынуть файл на соседнем компе, etc, используя то что там есть за минимальное время. Вдруг там вопрос на миллион? > Речь зашла о крутости Ext4, которая не имеет фич, присущих классическим промышленным ФС. Твой UFS2 так работает, что ему никакие фичи не помогут. Тормозилово без экстентов? В 2014 году? В номинации дисковых технологий фрибздюкам присуждается EPIC FAIL. Делать настолько похабно устроенные ФС в 2014 году - инженерный позор в чистейшем, рафинированном виде, господа. > Прости пожалуйста. Я всю дорогу талдычу о такой пустяковине, как быстрый, простой > и очевидный бэкап файлов и метаинформации ФС стандартными средствами. Я никогда не буду считать это "стандартными средствами" для бэкапов. Просто потому что оно зависит от ФС и ОС. Вот tar, который не парится относительно типа ФС и ОС - на стандартное средство уже может претендовать. Если прижало - вынуть файл из tar'овского бэкапа можно даже на какой-нибудь, простите, винде, если все умерло, файлик надо срочно, а ничего лучше под рукой нет. Или там с использованием ливфлехи какого-то дистра, попавшейся под руку. Может с ограничениями, чихая, коптя и на одном крыле, но миссия будет выполнена. Это - первый приоритет. А расовая вернота может катиться к бздюкам в берлогу. Бжкапы делаются не для того чтобы расовую верноту прокачивать, а для того чтобы в пиковой ситуации не словить большой факап. > Бэкапиться на ленты совсем необязательно. Можно забэкапить дамп файловой системы в файл. Вот только дамп файловой системы - штука весьма нишевая. Я такое практикую только для VM, бэкапя целиком диск-в-файле, сугубо потому что так минимизируется сущность ("1 файл на виртуалку"). Для более жирных сущностей типа ФС хоста - tar. > Кстати, файлы можно пометить флагом "nodump", если их не нужно включать > в дамп — так будет сохраняться только то, что нужно. А уж сколько у tar фич есть для включения и исключения файлов... > tar работает медленнее dump. А автомобиль ездит медленнее чем ракета летает. Но если мне надо в супермаркет в 2 километрах от дома - я таки не буду готовить стартовую площадку для ракеты. Даже если время в пути можно сократить.
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	180. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Nicknnn (ok) on 24-Мрт-14, 15:11
	>> Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение. > Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами. В BSD с фатальным недостатком. Её не писали ребята из BSD.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	208. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от iZEN (ok) on 24-Мрт-14, 21:47
	> В BSD с фатальным недостатком. Её не писали ребята из BSD. Неудачная попытка пошутить.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

13. "Компания AMD рассматривает возможность более открытой разраб..."	–7 +/–
Сообщение от iZEN (ok) on 23-Мрт-14, 10:10
Да они [AMD] бабки Каталистом стригут с Dell, HP, Apple и Samsung. А те, в свою очередь, отбивают их на продажах ноутбуков и рабочих станций.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от ананим on 23-Мрт-14, 11:07
	Да и пусть себе. Как сабж случиться, так забуду слово невидиа, как ноклу. Зыж А ты говоришь, что гпл не даёт зарабатывать. :D
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

29. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
Сообщение от gimrock (ok) on 23-Мрт-14, 12:05
>>> Более того, драйвер был лицензирован неназванным третьим сторонам. Microsoft, Apple, Oracle?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	156. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Pop on 24-Мрт-14, 00:03
	Не Факт, На Apple драйвер AMD работает так же быстро как и в линуксе.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	157. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Pop on 24-Мрт-14, 00:05
	*сарказм* разработчикам драйверов AMD
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

64. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
Сообщение от commiethebeastie (ok) on 23-Мрт-14, 13:07
И вообще закопайте наконец-то эти катаклизмические дрова. Ведь поддержку FirePro можно добавить через плагины для галлиума и микрокоды для ядра.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

69. "Компания AMD рассматривает возможность более открытой разраб..."	–6 +/–
Сообщение от Аноним (??) on 23-Мрт-14, 13:38
>При этом функциональность специфичная для проприетарного драйвера останется только в компонентах, выполняемых в пространстве пользователя, так что для драйвера не будет требоваться проприетарный модуль ядра. Ну вот компания AMD и показала своё настоящее лицо - проприетарная часть останется в любом случае, хотя куда проще открыть весь драйвер. А всё потому что проприетарность - это основополагающий принцип в компании AMD, как бы они не хотели казаться поборниками свободы лицемерно открывая спеки, но при этом всегда оставляя проприетарную часть, выдумая всякие нелепые причины почему же они якобы не могут отказаться от проприетарной части полностью и навсегда. Так что AMD-фанбои кричавшие что всё идёт к тому что AMD откажется от проприетарного драйвера и будет развивать только свободный драйвер и что он хотя бы сравняется по производительности с проприетарным могут отдыхать (сравняется взаправду на всём спектре задач и игр, а не в каких то там левых тестах с фороникса для старых карт и на никому не нужной горстке открытых игр). А мыслящим людям лицемерность действий AMD была очевидна уже давно, ну а теперь они оказались настолько глупы что открытым текстом сказали - мы будем тянуть проприетарную часть насколько бы нелепо, неэффективно и бессмысленно это не выглядело, потому что проприетарность - это главный, системообразующий принцип функционирования компании AMD.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	72. "Компания AMD рассматривает возможность более открытой разраб..."	+3 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 14:13
	Вот это залп! Неуч, AMD развивает свободный драйвер не один год. И проприетарный, который никуда не денется, поскольку из-за лицензий невозможно его просто взять, открыть и внедрить в ядро. А лучше всего разберись с проблемами в своем больном представлении и воображении.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	89. "Компания AMD рассматривает возможность более открытой разраб..."	+3 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:37
	> Ну вот компания AMD и показала своё настоящее лицо - проприетарная часть > останется в любом случае, хотя куда проще открыть весь драйвер. Это не мешает им держат команду работающую над открытым драйвером, а мысль дедуплицировать усилия, делая единый кернелмод - достаточно здравая, или где? > А мыслящим людям лицемерность действий AMD была очевидна уже давно, Что нам предложит гуру мыслительного процесса? Дохлятину от интела? И сколько FPSов оно выдаст на 2560х1440? Целых 5? Спасибо, но иногда надо что-то помощнее. Ну а там у нас только амд и нвидия. Поскольку нвидия к сообществу вообще ж...й, а кантоваться с блобьем в открытой системе нравится не всем - выбор очевиден.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	97. "Компания AMD рассматривает возможность более открытой разраб..."	+3 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 17:05
	Мыслящим людям лицемерность интернет-тролей очевидна уже давно
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	184. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Anonym2 on 24-Мрт-14, 16:37
	> А мыслящим людям лицемерность действий AMD была очевидна уже давно, ну а > теперь они оказались настолько глупы что открытым текстом сказали - мы > будем тянуть проприетарную часть насколько бы нелепо, неэффективно и бессмысленно это > не выглядело, потому что проприетарность - это главный, системообразующий принцип функционирования > компании AMD. Да вообще любопытно. Вся эта AMD графика на самом деле производства ATI. Которое когда-то практически разорилось, но так и не открыло драйвер, было куплено AMD, после чего AMD занялся проблемами ATI видео и драйверов...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

73. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
Сообщение от Аноним (??) on 23-Мрт-14, 14:35
>Неуч, AMD развивает свободный драйвер не один год. Ну как же, мегакорпорация AMD аж сподвиглась потратить неимоверное количество денег чтобы нанять целого одного человека - Алекса Дейчера на полный рабочий день для пиления открытых дров, неимоверный подвиг. Но только тем кто умеет думать очевидно, что это просто показуха. >И проприетарный, который никуда не денется, поскольку из-за лицензий невозможно его просто взять, открыть и внедрить в ядро. Можно просто перестать его разрабатывать и только поддерживать обновления безопасности и совместимости с версиями ОС, а весь штат разрабов перевести на открытый драйвер. Кроме того открытый драйвер уже написан и работает, необходима только доработка, и кто узнает что какие-то там небольшие куски кода из проприетарного драйвера перекочуют в открытый? Код же закрыт и является собственностью AMD. Да даже если те кому AMD лицензировала проприетарный драйвер имеют на руках его код, всё равно можно с нуля быстро написать код если вся команда что сейчас пилит проприетарный драйвер перейдёт на пиление открытого. Весь этот бухтёж про лицензии, невозможность отказаться от проприетарного драйвера - это всё и есть то что я называю лицемерием компании AMD, очевидно блюдущей проприетарность как зеницу ока. И да, если кому то непонятно, я вовсе не сторонник NVidia, в новостях про NVidia я их тоже поливаю г*вном за Optimus. Единственные нормальные открытые драйвера есть только у одной компании - Intel, и то что AMD не хочет быть как Intel в этом вопросе весьма красноречиво свидетельствует об их отношении к открытости.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	87. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Sluggard (ok) on 23-Мрт-14, 16:31
	> Единственные нормальные открытые драйвера есть только у одной компании - Intel Видеокарт хотя бы уровня середняков от АМД и Нвидиа у них нет. Вполне возможно потому и драйвер могут себе позволить открыть целиком, что у них не задействуются какие-то запатентованные, лицензированные и прочие технологии.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	92. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:40
	Да, так и представляю себе как интель будет рисовать на мой 2560x1440 в его нативном разрешении. Он с хоть каким там драйвером загнется. Потому что интеграт. И потому что нету у него дофига быстрого GDDR5 на широкой выделенной шине, чтобы обсчитывать сцены не покладая этим системную оперативку.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	103. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 18:51
	>Потому что интеграт. Intel Iris Pro Graphics 5200 оценивается не только, как полновесная среднепроизводительная видеокарта (по примеру GeForce GT 640M), но и превосходящая по скорости работы самый быстрый интегрированный графический адаптер AMD Radeon HD 8650G.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	119. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:49
	> Intel Iris Pro Graphics 5200 оценивается не только, как полновесная > среднепроизводительная видеокарта Если вы не поняли: для полноценного обсчета сцен на такой экран в его нативном разрешении надо как минимум нечто из начала топового сегмента (HDx8xx и выше). А для 4K - даже самых забористых видеокарт мало, прикиньте? Объем вычислений vs разрешение растет квадратично. > (по примеру GeForce GT 640M), но и превосходящая по скорости > работы самый быстрый интегрированный графический адаптер AMD Radeon HD 8650G. При таком мониторе ваш чемпионат задохликов смотрится довольно жалко. Мне такая радость что будет не 5FPS а целых 6, вы себе не представляете. И да, дискретный адаптер я могу добавить в свой могучий системник за 150-250 баксов. Это будет крутая и могучая числокрушилка. А интел вообще где? И как насчет цена/производительность, etc?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	105. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 18:57
	Интелы поддерживают 4K.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	120. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:50
	> Интелы поддерживают 4K. Вот только их вычислительных мощностей хватит лишь на жалкие пару кадров в секунду. Ну, получите вы слайдшоу в 4K вместо 3D сцены. Много вам с этого радости?
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	124. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 23-Мрт-14, 20:19
	> Да, так и представляю себе как интель будет рисовать на мой 2560x1440 в его нативном разрешении. Он с хоть каким там драйвером Вообще-то отлично рисует и на маке, и на лине (тут даже лучше). При чём на 2-а мониторах (второй правда full hd). Так что не нужно инсинуаций (да и макбуки с ретиной и с интелом выпускаются).
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	165. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 03:28
	> Вообще-то отлично рисует и на маке, и на лине (тут даже лучше). Рисует != обсчиткывает 3D сцену в данном разрешении. Ну да, выгрузить из буфера кадра картинку на экран автоматической долбилкой ума много не надо, покуда бандвиза памяти хватает. А запустим 3D гамезу - и получим слайдшоу на полтора FPS. Потому что обсчитывать сколь-нибудь сложную 3D сцену в таком разрешении оно не сможет.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	171. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от ананим on 24-Мрт-14, 09:16
	>> Вообще-то отлично рисует и на маке, и на лине (тут даже лучше). > Рисует != обсчиткывает 3D сцену в данном разрешении Пофигу на эти теоритезирования — в cs:s на full hd отлично вешаются хэдшоты и никаких тормозов. Hd4000, если что.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	183. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 16:11
	> Пофигу на эти теоритезирования — в cs:s на full hd отлично вешаются > хэдшоты и никаких тормозов. 1) Это довольно древнее двигло. А как насчет хотя-бы xonotic с более-менее приличными настройками качества? 2) FPS все-таки у вас какой? Хотя-бы стабильные 60 без просадок - будут? А то очень не прикольно когда тебе надо прицелиться, а тут FPS просел. 3) Если обратить внимание - я вообще-то упоминал разрешение выше FullHD. > Hd4000, если что. Ну да, вообще никаких технических сведений, даже по минимуму. Зато попиарился. "Каждый кулик свое болото хвалит", да? :)
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	188. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от ананим on 24-Мрт-14, 17:14
	> 1) Это довольно древнее двигло. А как насчет хотя-бы xonotic с более-менее приличными настройками качества? В ксонотик не играю, а метро идёт. И комменты других это подтверждают — Вас что, каждого по отдельности в это надо тыкать. Зыж Да-да, пальцы гните больше. На фулхд я играю, потому что внешний монитор 27". На нём бошки видны лучше. Владельцы феррари и то скромнее будут (есть опыт общения)
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	198. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 19:57
	> Владельцы феррари в чём должны являться эталоном, раз вы их приводите в пример?
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	212. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 21:58
	Ты/вы вот это о чём? Метро не примере?!! Ну дык минусуй больше! Вдруг прав окажешься.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	202. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 20:54
	> В ксонотик не играю, Ну а вот тот же фороникс, например, может забенчить. Без левых отмазок. И указать конкретику: параметры тестов и результаты. У них и xonotic, и много чего еще. С разными настройками. Для сравнения производительности разных GPU - весьма информативно. И вот там прекрасно видно где находится 4000. Соревнуется он с удешевленными "затычками для слотов". А, например, стобаксовым HDx7xx из среднего сегмента он проигрывает в несколько раз при равных параметрах тестов. Впрочем, 4000 даже APU проигрывает. > а метро идёт. Да там и unigine heaven "пойдет". А чего б ему, GL 3.3 есть -> куда он денется с подводной лодки?! Но рендерить будет в режиме слайдшоу. А как насчет человеческого желания получить хотя-бы 30FPS в приличном качестве на 2560х1440, даже с относительно тяжелыми 3D движками? А лучше 60FPS. Ну вот такие мониторы выпускают. Раз выпускают - логично пользоваться. И видеокарту хотеть под возможности монитора, а не "затычку для слота". Все-таки конфиг желательно более-менее балансировать, чтобы не мумукаться потом с кучей странных ограничений на ровном месте. > это надо тыкать. Я сам могу потыкать в результаты бенчей на том же форониксе. Там прекрасно видно, где 4000 относительно прочих. Он по сей день в несколько раз дохлее моего 5770, который 3 поколения назад выпущен. > Да-да, пальцы гните больше. На фулхд я играю, потому что внешний монитор > 27". На нём бошки видны лучше. Сразу видно "оптимальную" конфигурацию. Ну я то себе не враг. Играть на 27" мониторе на интеловском интеграте да еще ноуте можно только от большого мазохизма, имхо. И если что - мой немолодой 5770, попавшийся несколько лет назад по оказии за ~80 баксов - до сих пор обставит этого 4000 в несколько раз. Но даже его маловато будет для обсчета 3D сцен в 2560х1440 с нормальным качеством. Там скорее что-то типа x8x0 просится уже, если балансировать конфигу по нормальному, чтобы не надо было обрубать возможности монитора под хилость GPU. > Владельцы феррари и то скромнее будут (есть опыт общения) Мне кажется, у вас просто не хватило наглости попробовать обучать их вождению или сказать что "фигня этот ваш феррари, у моего фордфокуса мотор ничуть не хуже!"
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	213. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от ананим on 24-Мрт-14, 22:03
	> Ну а вот тот же фороникс, например, может забенчить. Без левых отмазок. И указать конкретику: параметры тестов и результаты. Да похеру на ваши бечи. Чел "боялся" как у него интел "картинку" будет выдавать. Теперь что? Бенчи и писюны? Картинку значит уже выдаёт? Или ещё нет? Зыж Давайте, натягивайте ноут за $500 на бенчи карты (одной!!!) за $1500. Один вопрос — Губа не треснет?
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	220. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от Аноним (??) on 25-Мрт-14, 05:22
	> Да похеру на ваши бечи. А это кому как. Слайдшоу вместо сложной сцены нравится не всем. > Чел "боялся" как у него интел "картинку" будет выдавать. А это тоже зависит от. Если уж на то пошло, GL 3.3 у интеля реализован только для самых последних чипов. А для более старых 3.1 и все тут. А у амдшников 3.3 и для прошлых поколений уже есть, если что. > Картинку значит уже выдаёт? Или ещё нет? Картинку выдавать можно по разному. 5FPS - формально, картинка. Реально - назойливое и бесполезное слайдшоу. И чем фичастее двигун и выше разрешение, тем чаще дохлая видеокарта вместо картинки демонстрирует слайдшоу. Конечно можно поотрубать все настройки.... но если уж на то пошло, я могу в игры поиграть и при помощи игральных кубиков, например, на бумажной карте. Вообще без компьютеров. Сугубо вопрос в том насколько далеко мы пойдем в "отрубании фич". > Давайте, натягивайте ноут за $500 на бенчи карты (одной!!!) за $1500. Не понял этой мысли. У меня немолодая видеокарта купленная за 80 баксов несколько лет назад до сих пор обставляет этот ваш хваленый 4000 в несколько раз по производительности. По поводу чего я имею нескромность заметить что для 27" монитора это безобразие не лучший выбор, если есть хоть какие-то планы играть на этом. > Один вопрос — Губа не треснет? Тоже не понял этой мысли. Если я могу купить монитор 2560х1400 - довольно странно если я при этом буду мудохаться с обрубочным интегратом.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	192. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Anonym2 on 24-Мрт-14, 19:01
	>> Единственные нормальные открытые драйвера есть только у одной компании - Intel > Видеокарт хотя бы уровня середняков от АМД и Нвидиа у них нет. > Вполне возможно потому и драйвер могут себе позволить открыть целиком, что > у них не задействуются какие-то запатентованные, лицензированные и прочие технологии. Да это вообще какие-то не видео карты (невидиа есть невидиа). Это какие-то отдельные можно сказать компъютеры под видом видеокарт со своими процессорами, закрытыми "прошивками" (они же в традиционном именовании операционные системы) и т. п... История игровых приставок.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	90. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 16:39
	> нанять целого одного человека - Алекса Дейчера на полный рабочий день А как насчет Marek Olsak, Tom Stellard, Christian Konnig (надеюсь правильно написал) и еще ряда человек? У вас с математикой хреново. Подтяните оценки по арифметике и попробуйте еще раз.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	104. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 18:54
	Их недавно взяли до этого там был несколько лет только один Алекс.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	121. "Компания AMD рассматривает возможность более открытой разраб..."	+2 +/–
	Сообщение от Аноним (??) on 23-Мрт-14, 19:50
	> Их недавно взяли до этого там был несколько лет только один Алекс. "Это было давно и неправда" в инверсной версии? :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	135. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 23-Мрт-14, 21:05
	> Ну как же, мегакорпорация AMD аж сподвиглась > это всё и есть то что я называю лицемерием > И да, если кому то непонятно, я вовсе не сторонник NVidia, в > новостях про NVidia я их тоже поливаю г*вном за Optimus. Есть предложение судить больше по делам, чем по словам.  Вас -- тоже.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

75. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от pavlinux (ok) on 23-Мрт-14, 15:20
Когда будет AMD Dynamic Switchable Graphics, задолбали уже, блобятина кревая!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

76. "Flying pig moment"	–3 +/–
Сообщение от Аноним (??) on 23-Мрт-14, 15:32
Flying pig moment. Думал не доживу до этого феерического момента. Вот зачем было делать 2 драйвера?! Кому эта идея пришла в голову?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	108. "Flying pig moment"	+/–
	Сообщение от sorrymak (ok) on 23-Мрт-14, 19:08
	> чего? Приблизительно можно перевести как "рак на горе свистнул".
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	246. "Flying pig moment"	+/–
	Сообщение от Аноним (??) on 27-Мрт-14, 17:45
	> Приблизительно можно перевести как "рак на горе свистнул". "Слышишь, там на горе рассвистелся вдруг рак? Да и дождь пошел в четверг, как дyрак".
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

134. "Компания AMD рассматривает возможность более открытой разраб..."	–2 +/–
Сообщение от Аноним (??) on 23-Мрт-14, 21:02
очень комичное замечание про Линуса, который, внезапно - всегда прогибает свою ТЗ под свои потребности. в прошлом он не раз высказывался во многих рассылках и дискуссиях в том ключе что "ну и что что ABI тут поменяется и API, тоже. Linux развивается и стабильность ценой застоя - Нам не нужна". те про гибкость подхода и эволюционность развития ОС - как первичную ценность - он буквально кубометры кирпичей навалил )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	248. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Michael Shigorin (ok) on 27-Мрт-14, 18:42
	> очень комичное замечание про Линуса Вопрос на засыпку: Вы про внутриядерный ABI это сейчас или про kernel/userspace?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

154. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от lucentcode (ok) on 23-Мрт-14, 23:47
Логичное решение. И правильное. Кроме прочего, позволит сэкономить на разработке драйвера под Linux(вместо двух абсолютно разных модулей ядра будут пилить один). Понятно, что часть, что торчит у юзерспейс они не откроют, ведь хорошо оптимизированная реализация OpenGL - это их конкурентное преимущество.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

155. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от Аноним (??) on 23-Мрт-14, 23:58
Так и не понял, что там останется в этом каталисте (какая функциональноть) кроме drm? А если только дрм, ну вы поняли...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	179. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 14:48
	Непосредственно реализация OpenGL, OpenCL и т.д.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

170. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
Сообщение от Потерпевший on 24-Мрт-14, 07:40
Героический шаг, если подумать. Они хотят сменить процесс производства видеокарт ради упрощения поддержки linux. То есть сначала реализовать поддержку будущей видеокарты, а только потом начать ее продавать. Им эта реформа дорого обойдется. Надеюсь выйдет. Емнип, intel так и работает. Надеюсь это пойдет на пользу катаглисту, т.к. использовать это глюкалово имхо не возможно нигде, в отличии от.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	176. "Компания AMD рассматривает возможность более открытой разраб..."	–1 +/–
	Сообщение от svsd_val (ok) on 24-Мрт-14, 11:52
	Согласен =)
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	177. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от erera22 (ok) on 24-Мрт-14, 13:16
	Все равно это больше напоминает ситуацию: "а что же делать с железками, если у нас никто не умеет писать дрова?"
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	189. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от ананим on 24-Мрт-14, 17:15
	Для идиотов разве что.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	191. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-14, 18:57
	> Героический шаг, если подумать. Они хотят сменить процесс производства видеокарт ради > упрощения поддержки linux. Ничего они менять не собираются: блободрайвера так и пишутся. И открытые в последнее время - тоже. Вот их и посетила мысля дедуплицировать усилия. > То есть сначала реализовать поддержку будущей видеокарты, Вообще, выпускать на рынок железку без драйвера - затея в высшей мере странная: а что с ней делать то без драйверов предлагается?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

200. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
Сообщение от Аноним (??) on 24-Мрт-14, 20:25
В своё время повёлся на болтовню АМД об открытых драйверах для линукса..., натерпелся изрядно, настроение подпорчено, но процессоры данной компании использую до сих пор)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	203. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-14, 20:57
	> В своё время повёлся на болтовню АМД об открытых драйверах для линукса..., > натерпелся изрядно, настроение подпорчено, А чего там для порчи настроения? В последнее время их драйвера как раз очень позитивно себя показывают.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема