forum.opennet.ru

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

Оглавление

Компания AMD рассматривает возможность более открытой разраб..., opennews (?), 23-Мрт-14, (0) [смотреть все]

Линусу Торвальдсу будет всё-равно, если эти изменения будут согласованы с разраб, ананим (?), 09:00 , 23-Мрт-14, (1) +9 //

Это вообще не проблема, посмотрите как это делает интел и делайте также Конечно,, ананим (?), 09:04 , 23-Мрт-14, (2) //

Вот так лучше не делать Когда глючит размазанная видюха - это нормально, от неё, anonymus (?), 09:14 , 23-Мрт-14, (4) //

Во-первых 8212 этого уже нет В тот период у интела не было ни стабильных дро, ананим (?), 09:42 , 23-Мрт-14, (6) +9

http pastebin ru pRs2KJIl, анончик (?), 11:26 , 23-Мрт-14, (24)

Чего это за хрень с левого ресурса ЗыжА ещё поддержка последних иксов, вяленого,, ананим (?), 11:45 , 23-Мрт-14, (27) –1

c xorg-server тоже нет проблем http pastebin ru DXtDcQToнасчёт wayland ко, анончик (?), 13:21 , 23-Мрт-14, (66)

А 3 14 RC с этим драйвером можно погонять Нет Ну ой, тогда не интересно , Аноним (-), 16:18 , 23-Мрт-14, (78) –12

а ты уверен что нельзя , анончик (?), 16:56 , 23-Мрт-14, (95) +1
можно если благородный дон в силах погонять 3 14-rc, конечно, Карбофос (ok), 17:04 , 23-Мрт-14, (96) +1

А вы проверяли А то нвидия вон недавно мыкалась с тем что в новых ядрах отломал, Аноним (-), 19:06 , 23-Мрт-14, (106) –8

пистон, VecH (ok), 20:44 , 23-Мрт-14, (131) –1
демагогию разводите, милейший, Карбофос (ok), 21:29 , 23-Мрт-14, (142)

Кроме демагогии юзеры нвидии с 3 13 кернелом тут носились как ужаленные Но у ни, Аноним (-), 03:15 , 24-Мрт-14, (164)
об чем и речь то он предполагает, что драйвера с новым ядром не работает, то за, Карбофос (ok), 10:30 , 24-Мрт-14, (174) –1
Ну а что, проблемы регулярно бывают Нвидия с ее отсутствием поддержки новых яде, Аноним (-), 16:03 , 24-Мрт-14, (182) –2
ну прям как маленькая серая птичка, не иначе сначала заикнулся про одно, потом , Карбофос (ok), 16:40 , 24-Мрт-14, (185) –1
Не, вот извините То что проприетарные драйвера периодически тормозят с поддержк, Аноним (-), 19:52 , 24-Мрт-14, (196) –1
не извиню так как выражение погонять 3 14-rc входит в конфликт с выражением , Карбофос (ok), 01:12 , 29-Мрт-14, (250)

ядро 3 13 и xorg-1 15 поддерживается Что ещё надо , Led (ok), 22:08 , 23-Мрт-14, (146)

Благодаря этому и имеем сабж D, ананим (?), 09:07 , 23-Мрт-14, (3) +1
Лишь бы открытые дрова не ломали А в общем и целом 8212 молодцы, раз стараютс, Sluggard (ok), 09:22 , 23-Мрт-14, (5) +5 //

А толку-то Столько лет сотрудничества с сообществом тм , а качество едва за , Fracta1L (ok), 09:45 , 23-Мрт-14, (7) –3 //

Высо-о-окий такой плинтус 80-90 от блоба При этом в стиме на некоторые игры рек, ананим (?), 10:04 , 23-Мрт-14, (9) +6 //

Вы так говорите, будто блоб сам блещет качеством Какой-нибудь шлак, наверное Пру, Fracta1L (ok), 10:31 , 23-Мрт-14, (16) –7

Хм Так же как и вантузе Один в один Что и логично 8212 кодовая база на 99 , ананим (?), 10:47 , 23-Мрт-14, (17) +1

Все игры Valve морально устарели, ничего удивительного что они идут на mesa Кро, Аноним (-), 13:53 , 23-Мрт-14, (70) –4

В последнее время и их подтянули очень неплохо Проблемы еще есть, конечно, но п, Аноним (-), 16:26 , 23-Мрт-14, (83)

купи игровую дискретную видеокарту, и получи производительность чуть выше интело, Проходящий (?), 19:28 , 23-Мрт-14, (114) –2

У меня HD5770, расскажи мне про свой интеграт, угу Этот может xonotic в fullhd , Аноним (-), 20:37 , 23-Мрт-14, (128) +1

Глупое утверждение Серьёзно Тоже метро не на движке соурс который в свою очере, ананим (?), 10:23 , 24-Мрт-14, (173) +1

По производительности обыкновенная венда painkiller жеНу например недавний фикс , commiethebeastie (ok), 10:49 , 23-Мрт-14, (18) +1

Да-да, и общающиеся между собой на английском Куда там индусам D, ананим (?), 10:59 , 23-Мрт-14, (20)

Это менеджеры, а дрова пишет на оутсорсе российская компания , commiethebeastie (ok), 12:14 , 23-Мрт-14, (31) –1

угу А технические задания, техническая документация, отчётность, да даже комм, ананим (?), 12:47 , 23-Мрт-14, (61)

Естественно документация на английском В MS тоже всё на английском, а не хинди , commiethebeastie (ok), 12:58 , 23-Мрт-14, (62) –1

Не путайте документацию документацию для конечного пользователя и техническую до, ананим (?), 13:25 , 23-Мрт-14, (68)

Автоперевод Обычно с английского , Anonym2 (?), 15:58 , 24-Мрт-14, (181)

И на тоже Плавали, знаем , ананим (?), 17:07 , 24-Мрт-14, (187)

amd _уже_ работает на открытых драйверах из коробки, управление питанием запилил, koblin (ok), 12:58 , 23-Мрт-14, (63) +2

На некоторых картах серий 4000-6000, на остальном производительность в глубокой , Аноним (-), 14:01 , 23-Мрт-14, (71) –1

врешь ты все Вопервых до 76ххво вторых на новых картах половина производительно, Аноним (-), 15:17 , 23-Мрт-14, (74) +2

Это ты врёшь - начиная с серии 7000 карты AMD работают с драйвером RadeonSI, кот, Аноним (-), 16:01 , 23-Мрт-14, (77) –1

Смотрите новые тесты, там и больше половины бывает И что касается фич, у них уж, Аноним (-), 16:40 , 23-Мрт-14, (91)
Таки до 7600 - с R600, правильно вам говорят GCN - начиная с HD77xx Уже вполне , Аноним (-), 17:50 , 23-Мрт-14, (100) +2

Вот что-что а открытый драйвер стабильностью весьма радует Так, для сравнения -, Аноним (-), 16:28 , 23-Мрт-14, (85) +1

Вот кстати идея пропихнуть его через DRM KMS очень здравая на самом деле , Аноним (-), 16:19 , 23-Мрт-14, (79)
Не, не представляете Вот дорастёте до того, чтоб самому хоть отдалённо браминс, Michael Shigorin (ok), 21:00 , 23-Мрт-14, (133) +2

Может потому, что кодовая база каталиста - общая для всех поддерживаемых ОС , Led (ok), 22:11 , 23-Мрт-14, (148)

да и поэтому тоже вывод то какой из этого факта , ананим (?), 22:28 , 23-Мрт-14, (150)

Фрактал, ты как был неадекватным, так и остался И обсуждать что-то с упёртым че, Sluggard (ok), 11:35 , 23-Мрт-14, (26) +10 //

есть специальная поговорка не спорьте с идиотами , Аноним (-), 19:37 , 24-Мрт-14, (195) +1

Это только от линуксового блоба планируют избавляться, или на остальных системах, Аноним (8), 09:54 , 23-Мрт-14, (8) //

на каких остальных Больше свободных ос их драйвер не поддерживает, Аноним (-), 10:04 , 23-Мрт-14, (10) //

Добавлю 8212 а на вантузе их opengl см окончание сабжа , из-за чего сыр-бор, ананим (?), 10:07 , 23-Мрт-14, (11) //

Windows NT4, в своё время, была сильная поддержка OpenGL 8212 о чём писал Евг, iZEN (ok), 10:20 , 23-Мрт-14, (15) –4

Гораздо бОльший пинок дало развитие смартфонов планшетов этк вообще и от гугла с, ананим (?), 10:56 , 23-Мрт-14, (19)
Вот только на мобилах и планшетах повально OpenGL, этот рынок растет и отдавать , Аноним (-), 16:21 , 23-Мрт-14, (81)

Кстати, если в бздях запилят аналоги kms drm , то есть шанс, что блоб в юзер-с, ананим (?), 10:10 , 23-Мрт-14, (12) +1 //

Под FreeBSD пилили KGI, но забросили 2года назад, а drm kms и так портируют есть, Аноним (-), 19:23 , 23-Мрт-14, (112) //

Собственно, процент фэйлов собственных наработок бздюков уже давно поражает вооб, Аноним (-), 19:39 , 23-Мрт-14, (117) +2

Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами Всё де, iZEN (ok), 19:48 , 23-Мрт-14, (118) –4

Угу Вот только иксы под мит, а рулит там Аарон из оракла в основном А бздуны пр, ананим (?), 20:23 , 23-Мрт-14, (125) +1

Товарищи из комитета X Org буквально вышвырнули из управляющего совета MacOS ник, iZEN (ok), 20:43 , 23-Мрт-14, (130) –4

А Так ты про макосников Тю Бздишники то, как Таббаки испарились вслед ЗыжВот то, ананим (?), 21:31 , 23-Мрт-14, (143) +1
У макоси своя графическая подсистема, так что этим там вообще делать нечего, имх, Аноним (-), 22:55 , 23-Мрт-14, (151) +1

nvidia ko и модуль ядра из Каталиста почему-то лучше знают о GPU, чем KMS с DRM , iZEN (ok), 21:36 , 24-Мрт-14, (206) –3

Пиндишь Консоль загрузки с кмс сразу после начала распознаёт и родное разрешение, ананим (?), 21:54 , 24-Мрт-14, (211) +1

работают B тупо B быстрееНет, ну в чём-то он прав В этом чём-то он собак, Andrey Mitrofanov (?), 10:06 , 25-Мрт-14, (221) +1

Ну так это не ваша заслуга, а наша недоработка c ФЭД Вот у амд модуль в лин, Аноним (-), 01:42 , 25-Мрт-14, (216) +1

Сапожник Кому это было реально надо - уже много лет использовали Со сшапшотами, Аноним (-), 21:10 , 23-Мрт-14, (136) +1

dump 8 restore 8 на подмонтированной с -o rw EXT4 хотя бы работает Не давать , iZEN (ok), 21:20 , 23-Мрт-14, (138) –5

---Dump was a stupid program in the first place Leave it behind --- http lwn , Michael Shigorin (ok), 22:05 , 23-Мрт-14, (144)

В Linux своя исключительная правда , которая в Unix зовётся кривдой ---1, iZEN (ok), 00:14 , 24-Мрт-14, (158) –3

Занавес Когда что-то было изначально криво спроектировано например, и, Michael Shigorin (ok), 01:04 , 24-Мрт-14, (160) +1

У них там походу всегда полшестого и всегда пора пить чай , Аноним (-), 04:15 , 24-Мрт-14, (166) +1

У линуксоидов, походу везде кривизна прослеживается, кроме них самих, поэтому и , iZEN (ok), 21:44 , 24-Мрт-14, (207) –4
Я б поспорил, если бы не выглядел так жалко , ананим (?), 21:51 , 24-Мрт-14, (210)
У NIH есть и положительные стороны - иногда софт полезно улучшать Иначе мы бы т, Аноним (-), 04:37 , 25-Мрт-14, (218) +1

Нет, dump restore в Solaris 11 нет в принципе Бэкап fs - zfs dump restore, бэка, Stax (ok), 16:50 , 24-Мрт-14, (186) +1

Спасибо Вот и пытался объяснить гостю с windows 8 , Michael Shigorin (ok), 19:36 , 24-Мрт-14, (194)
XFS поддерживает инкрементные dump restore на смонтированной системе Что, тож, iZEN (ok), 21:04 , 24-Мрт-14, (204) –1
XFS 8212 единственное что и использую на серверах не под ораклом пока Но да, ананим (?), 21:49 , 24-Мрт-14, (209)
Так смысл в том, что dump restore работают с консистентным набором блоков ФС По, iZEN (ok), 14:50 , 25-Мрт-14, (223) –2
А зачем тебе консистентный набор блоков ФС Консистентный набор блоков конс, Аноним (-), 15:35 , 25-Мрт-14, (229) +1
Видишь ли, традиционно софт в Unix работает с файлами, сокетами, каналами pipe , iZEN (ok), 16:01 , 25-Мрт-14, (230) –2
Спасибо, капитан Как бы это сказать Dump restore довольно специфичная штука, ре, Аноним (-), 23:03 , 25-Мрт-14, (240)
Окуенный плюс А то, что этот дамп будет с битыми данными и нафиг не нужен 8212, ананим (?), 17:49 , 25-Мрт-14, (232) +1
Это другой уровень задач ФС в общем случае не решает задачи сохранения транзакц, iZEN (ok), 19:34 , 25-Мрт-14, (237) –1
Именно И именно поэтому она также не играет роли в создании бэкапов и архивов Ес, ананим (?), 23:26 , 25-Мрт-14, (241) +1
в интернетах так заведено кто меньше всех знает - старается давать советы, или , цирроз (ok), 12:17 , 27-Мрт-14, (244)
Не то чтобы плохо , просто нишевая хрень, носиться с которой как с писанной тор, Аноним (-), 04:34 , 25-Мрт-14, (217)
Что, альтернатива лучше Сколько этих альтернатив, которые имеют свои кривые сто, iZEN (ok), 15:00 , 25-Мрт-14, (224) –3
Вот поэтому и есть tar Или pax А фс-зависимые утилиты идут лесом зыжОпенбздишник, ананим (?), 17:54 , 25-Мрт-14, (233) +1
tar работает гораздо медленнее dump , iZEN (ok), 19:23 , 25-Мрт-14, (236) –2
А рсинк нет И К тому же tar ом я могу бэкапить избирательно, что и делается в п, ананим (?), 23:28 , 25-Мрт-14, (242) +1
Ну тогда бэкап в dev null - по любому чемпион , Аноним (-), 04:47 , 26-Мрт-14, (243) +1
А автомобиль ездит медленнее чем летает ракета Но назвать ракеты стандартным ср, Аноним (-), 17:53 , 27-Мрт-14, (247) +1
Изя, Вы хоть сами-то поняли, что спорите с самим собой dump restore дублируют ре, Michael Shigorin (ok), 18:44 , 27-Мрт-14, (249) +1

Intel вроде бы еще отказался пилить Gallium3D для своих интеграшек , Аноним (-), 22:58 , 23-Мрт-14, (152)

Да У них свое собственное добро Как бы их право Есть мнение что за счет этого, Аноним (-), 19:56 , 24-Мрт-14, (197)

Надо же, главное -- не рассказывать ноуту, с которого и пишу А то тут как раз , Michael Shigorin (ok), 01:05 , 24-Мрт-14, (161) +1

А вы с ноутом общаетесь, что-то ему рассказываете Ну надо же , iZEN (ok), 15:03 , 25-Мрт-14, (225) –2

В Новости на Главной iZEN нипонял сарказма, направленного на него , Andrey Mitrofanov (?), 15:08 , 25-Мрт-14, (227) +2

а зачем обыденное событие отмечать в новостях , Карбофос (ok), 19:21 , 25-Мрт-14, (235)

Без понятия Ты лучше скажи какая b цель b этого У меня нет цели в жизни за, Аноним (-), 03:11 , 24-Мрт-14, (162)

Делать бэкап файловой системы, не отмонтируя или предварительно отмонтируя - нев, iZEN (ok), 21:11 , 24-Мрт-14, (205) –2

Таром я делаю Потом загоняю в черут вообще-то сразу через пайп , устанавливаю н, ананим (?), 22:10 , 24-Мрт-14, (214)
Гланды паяльником дальней дорогой Если Вы до сих пор не поняли уже сказанного , Michael Shigorin (ok), 00:28 , 25-Мрт-14, (215) +1
Из простейших вариантов - tar, например Если этого мало - вариантов есть На ре, Аноним (-), 05:01 , 25-Мрт-14, (219)

О чём можно говорить про бэкап с человеком, который ссылается на 1991 год и не п, Michael Shigorin (ok), 11:58 , 25-Мрт-14, (222) +1

Бывают бэкапилки Windows А что с тех пор изменилось в классических файловых си, iZEN (ok), 15:07 , 25-Мрт-14, (226) –3
Бывают И даже простой ntbackup выделяет известные ему виды баз данных из общей , Аноним (-), 16:22 , 25-Мрт-14, (231) +1

gt оверквотинг удален Для любой файловой системы в терминах операционной систе, iZEN (ok), 15:29 , 25-Мрт-14, (228) –2

Дурость айзена мешает зыжТы понимаешь, что только что договорился до single-mode, ананим (?), 17:59 , 25-Мрт-14, (234) +1
Ну, мечтай Даже крЮтые коммерческие решения обычно подразумевают что за монитор, Аноним (-), 21:00 , 25-Мрт-14, (238)
gt оверквотинг удален Ну, не знаю Лично у меня Запущенный Firefox с X ами не , iZEN (ok), 22:06 , 25-Мрт-14, (239) –1
Казалось бы, при чем тут бэкапы и даже ФС Софт обычно или вгружает данные в RAM, Аноним (-), 17:43 , 27-Мрт-14, (245)

В BSD с фатальным недостатком Её не писали ребята из BSD , Nicknnn (ok), 15:11 , 24-Мрт-14, (180)

Неудачная попытка пошутить , iZEN (ok), 21:47 , 24-Мрт-14, (208) –1

Да они AMD бабки Каталистом стригут с Dell, HP, Apple и Samsung А те, в свою , iZEN (ok), 10:10 , 23-Мрт-14, (13) –7 //

Да и пусть себе Как сабж случиться, так забуду слово невидиа, как ноклу ЗыжА ты , ананим (?), 11:07 , 23-Мрт-14, (22) +1

Microsoft, Apple, Oracle , gimrock (ok), 12:05 , 23-Мрт-14, (29) +1 //

Не Факт, На Apple драйвер AMD работает так же быстро как и в линуксе , Pop (?), 00:03 , 24-Мрт-14, (156) //

сарказм разработчикам драйверов AMD, Pop (?), 00:05 , 24-Мрт-14, (157) –1

И вообще закопайте наконец-то эти катаклизмические дрова Ведь поддержку FirePro, commiethebeastie (ok), 13:07 , 23-Мрт-14, (64) –1
Ну вот компания AMD и показала своё настоящее лицо - проприетарная часть останет, Аноним (-), 13:38 , 23-Мрт-14, (69) –6 //

Вот это залп Неуч, AMD развивает свободный драйвер не один год И проприетарный, Аноним (-), 14:13 , 23-Мрт-14, (72) +3
Это не мешает им держат команду работающую над открытым драйвером, а мысль дедуп, Аноним (-), 16:37 , 23-Мрт-14, (89) +3
Мыслящим людям лицемерность интернет-тролей очевидна уже давно, Аноним (-), 17:05 , 23-Мрт-14, (97) +3
Да вообще любопытно Вся эта AMD графика на самом деле производства ATI Которое, Anonym2 (?), 16:37 , 24-Мрт-14, (184) +1

Ну как же, мегакорпорация AMD аж сподвиглась потратить неимоверное количество де, Аноним (-), 14:35 , 23-Мрт-14, (73) –3 //

Видеокарт хотя бы уровня середняков от АМД и Нвидиа у них нет Вполне возможно п, Sluggard (ok), 16:31 , 23-Мрт-14, (87) +2 //

Да, так и представляю себе как интель будет рисовать на мой 2560x1440 в его нати, Аноним (-), 16:40 , 23-Мрт-14, (92) //

Intel Iris Pro Graphics 5200 оценивается не только, как полновесная среднепроизв, Аноним (-), 18:51 , 23-Мрт-14, (103)

Если вы не поняли для полноценного обсчета сцен на такой экран в его нативном р, Аноним (-), 19:49 , 23-Мрт-14, (119)

Интелы поддерживают 4K , Аноним (-), 18:57 , 23-Мрт-14, (105) –1

Вот только их вычислительных мощностей хватит лишь на жалкие пару кадров в секун, Аноним (-), 19:50 , 23-Мрт-14, (120) +1

Вообще-то отлично рисует и на маке, и на лине тут даже лучше При чём на 2-а мо, ананим (?), 20:19 , 23-Мрт-14, (124)

Рисует обсчиткывает 3D сцену в данном разрешении Ну да, выгрузить из буфера , Аноним (-), 03:28 , 24-Мрт-14, (165)

Пофигу на эти теоритезирования 8212 в cs s на full hd отлично вешаются хэдшот, ананим (?), 09:16 , 24-Мрт-14, (171) –1

1 Это довольно древнее двигло А как насчет хотя-бы xonotic с более-менее прили, Аноним (-), 16:11 , 24-Мрт-14, (183)

В ксонотик не играю, а метро идёт И комменты других это подтверждают 8212 Вас, ананим (?), 17:14 , 24-Мрт-14, (188) –2

в чём должны являться эталоном, раз вы их приводите в пример , Аноним (-), 19:57 , 24-Мрт-14, (198)

Ты вы вот это о чём Метро не примере Ну дык минусуй больше Вдруг прав окажешь, ананим (?), 21:58 , 24-Мрт-14, (212)

Ну а вот тот же фороникс, например, может забенчить Без левых отмазок И указат, Аноним (-), 20:54 , 24-Мрт-14, (202)

Да похеру на ваши бечи Чел боялся как у него интел картинку будет выдавать Т, ананим (?), 22:03 , 24-Мрт-14, (213) –1

А это кому как Слайдшоу вместо сложной сцены нравится не всем А это тоже зависи, Аноним (-), 05:22 , 25-Мрт-14, (220) –1

Да это вообще какие-то не видео карты невидиа есть невидиа Это какие-то отдел, Anonym2 (?), 19:01 , 24-Мрт-14, (192)

А как насчет Marek Olsak, Tom Stellard, Christian Konnig надеюсь правильно напи, Аноним (-), 16:39 , 23-Мрт-14, (90) +2 //

Их недавно взяли до этого там был несколько лет только один Алекс , Аноним (-), 18:54 , 23-Мрт-14, (104) –2 //

Это было давно и неправда в инверсной версии , Аноним (-), 19:50 , 23-Мрт-14, (121) +2

Есть предложение судить больше по делам, чем по словам Вас -- тоже , Michael Shigorin (ok), 21:05 , 23-Мрт-14, (135) +1

Когда будет AMD Dynamic Switchable Graphics, задолбали уже, блобятина кревая , pavlinux (ok), 15:20 , 23-Мрт-14, (75)
Flying pig moment Думал не доживу до этого феерического момента Вот зачем было , Аноним (-), 15:32 , 23-Мрт-14, (76) –3 //

Приблизительно можно перевести как рак на горе свистнул , sorrymak (ok), 19:08 , 23-Мрт-14, (108) //

Слышишь, там на горе рассвистелся вдруг рак Да и дождь пошел в четверг, как дy, Аноним (-), 17:45 , 27-Мрт-14, (246)

очень комичное замечание про Линуса, который, внезапно - всегда прогибает свою Т, Аноним (-), 21:02 , 23-Мрт-14, (134) –2 //

Вопрос на засыпку Вы про внутриядерный ABI это сейчас или про kernel userspace , Michael Shigorin (ok), 18:42 , 27-Мрт-14, (248)

Логичное решение И правильное Кроме прочего, позволит сэкономить на разработке, lucentcode (ok), 23:47 , 23-Мрт-14, (154)
Так и не понял, что там останется в этом каталисте какая функциональноть кроме, Аноним (-), 23:58 , 23-Мрт-14, (155) //

Непосредственно реализация OpenGL, OpenCL и т д , Аноним (-), 14:48 , 24-Мрт-14, (179)

Героический шаг, если подумать Они хотят сменить процесс производства видеокарт, Потерпевший (?), 07:40 , 24-Мрт-14, (170) //

Согласен , svsd_val (ok), 11:52 , 24-Мрт-14, (176) –1
Все равно это больше напоминает ситуацию а что же делать с железками, если у н, erera22 (ok), 13:16 , 24-Мрт-14, (177) //

Для идиотов разве что , ананим (?), 17:15 , 24-Мрт-14, (189)

Ничего они менять не собираются блободрайвера так и пишутся И открытые в после, Аноним (-), 18:57 , 24-Мрт-14, (191)

В своё время повёлся на болтовню АМД об открытых драйверах для линукса , натер, Аноним (200), 20:25 , 24-Мрт-14, (200) –4 //

А чего там для порчи настроения В последнее время их драйвера как раз очень поз, Аноним (-), 20:57 , 24-Мрт-14, (203) +1

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

8. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (8), 23-Мрт-14, 09:54

Это только от линуксового блоба планируют избавляться, или на остальных системах тоже будут делать также?

Ответить | Правка | Наверх | Cообщить модератору

10. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 23-Мрт-14, 10:04

на каких остальных? Больше свободных ос их драйвер не поддерживает

Ответить | Правка | Наверх | Cообщить модератору

11. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от ананим (?), 23-Мрт-14, 10:07

Добавлю — а на вантузе их opengl (см. окончание сабжа), из-за чего сыр-бор, тоже не приветствуется. Там мс решила всё в пользу своего dx.

Ответить | Правка | Наверх | Cообщить модератору

15. "Компания AMD рассматривает возможность более открытой разраб..." –4 +/–

Сообщение от iZEN (ok), 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.

Ответить | Правка | Наверх | Cообщить модератору

19. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от ананим (?), 23-Мрт-14, 10:56

Гораздо бОльший пинок дало развитие смартфонов/планшетов/этк вообще и от гугла с яблоком в частности, где по очевидным причинам dx нет как класса.
Зыж
А воовще знатно мс нагнуло производителей видео-карт, раз они согласились поставлять дрова с выпеленным opengl.
Сколько работы в мусорный бак (см. последний абзац новости)

Ответить | Правка | Наверх | Cообщить модератору

81. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 23-Мрт-14, 16:21

> Никуда хомячки не денутся с подводной лодки,
Вот только на мобилах и планшетах повально OpenGL, этот рынок растет и отдавать его никто не собирается. Поэтому выучат GL как миленькие. А еще веб с его WebGL. Ну в общем если долго давиться жабой - получается как-то так...

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

12. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 23-Мрт-14, 10:10

> Это только от линуксового блоба планируют избавляться, или на остальных системах тоже будут делать также?
Кстати, если в бздях запилят аналоги kms/drm/.., то есть шанс, что блоб в юзер-спейсе заработает и у них.
Бздишнеги, можете линуксоидов не благодарить! :D

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

112. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 23-Мрт-14, 19:23

Под FreeBSD пилили KGI, но забросили 2года назад, а drm/kms и так портируют/есть.

Ответить | Правка | Наверх | Cообщить модератору

117. "Компания AMD рассматривает возможность более открытой разраб..." +2 +/–

Сообщение от Аноним (-), 23-Мрт-14, 19:39

> Под FreeBSD пилили KGI, но забросили 2года назад,
Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение. Они уже давно не делают погоду в отрасли. Климат давно уже задает пингвин и его разработчики.
> а drm/kms и так портируют/есть.
Да, несколько лет поупирались рогом, мол да ну его, etc. А как жареный петух укусил, что драйверов вообще совсем нет - тут прозрели резко. Только отставание на годы - оно никуда не денется.

Ответить | Правка | Наверх | Cообщить модератору

118. "Компания AMD рассматривает возможность более открытой разраб..." –4 +/–

Сообщение от iZEN (ok), 23-Мрт-14, 19:48

> Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение.
Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами.
> Они уже давно не делают погоду в отрасли.
Всё делают проприетарщики для Linux, но что-то воз и ныне там, в далёком 2006 году. Как было, так и осталось по большому счёту. Концептуально только Android — серьёзное решение.
> Климат давно уже
> задает пингвин и его разработчики.
>> а drm/kms и так портируют/есть.
> Да, несколько лет поупирались рогом, мол да ну его, etc. А как
> жареный петух укусил, что драйверов вообще совсем нет - тут прозрели
> резко. Только отставание на годы - оно никуда не денется.
Intel написал KMS/DRM специально для Linux. Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды? Что, должны были подлизывать зад Intel, как это делали линуксятники?

Ответить | Правка | Наверх | Cообщить модератору

125. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 23-Мрт-14, 20:23

> Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды?
Угу. Вот только иксы под мит, а рулит там Аарон из оракла в основном.
А бздуны просто нифига не делали и сами самоустранились. Как и во всём.

Ответить | Правка | Наверх | Cообщить модератору

130. "Компания AMD рассматривает возможность более открытой разраб..." –4 +/–

Сообщение от iZEN (ok), 23-Мрт-14, 20:43

>> Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды?
> Угу. Вот только иксы под мит, а рулит там Аарон из оракла в основном.
Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников и BSD'шников: http://www.opennet.ru/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'у спасибо за это или нет? ;)

Ответить | Правка | Наверх | Cообщить модератору

143. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 23-Мрт-14, 21:31

> Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников и BSD'шников
А! Так ты про макосников!
Тю.
Бздишники то, как Таббаки испарились вслед.
Зыж
Вот только кварцев там и не хватало.
А главное — бзде бы как помогло-о-о!!!

Ответить | Правка | Наверх | Cообщить модератору

151. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 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), 24-Мрт-14, 21:36

nvidia.ko и модуль ядра из Каталиста почему-то лучше знают о GPU, чем KMS с DRM - так как на вид работают тупо быстрее и лучше. ;)

Ответить | Правка | Наверх | Cообщить модератору

211. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 24-Мрт-14, 21:54

Пиндишь.
Консоль загрузки с кмс сразу после начала распознаёт и родное разрешение, и количество мониторов.
Мне как-то приятнее даже в консоль попасть на 27"-мониторе, чем таращиться (в веса!!!) щель на 14".
Зыж
Ты не практолог случаем?

Ответить | Правка | Наверх | Cообщить модератору

221. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Andrey Mitrofanov (?), 25-Мрт-14, 10:06

#>> работают тупо быстрее
> Пиндишь.
Нет, ну в чём-то он прав. В этом чём-то он собаку съел. Он дока, профессор и чемпионище!

Ответить | Правка | Наверх | Cообщить модератору

216. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 25-Мрт-14, 01:42

> nvidia.ko и модуль ядра из Каталиста почему-то лучше знают о GPU,
Ну так "это не ваша заслуга, а наша недоработка" (c) ФЭД. Вот у амд модуль в линухе начал работать довольно хорошо. Умеет динамический реклок, ускорение декодирования видео и прочая. Так что как видишь, у них на полном серьезе возникла логичная идея - дедуплицировать работу и убить проприетарный модуль в ядре как таковой.
> чем KMS с DRM - так как на вид работают тупо быстрее и лучше. ;)
Знаешь, мне такие рассуждизмы очень напоминают ситуацию в природе, когда волки сожрали всех зайцев и ... положили зубы на полку и сдохли от голода, т.к. жрать через некоторое время стало нечего.

Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

136. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 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), 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 поддержит их, портируя Каталист в эту бесперспективную схему.

Ответить | Правка | Наверх | Cообщить модератору

144. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Michael Shigorin (ok), 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
Это правда.

Ответить | Правка | Наверх | Cообщить модератору

158. "Компания AMD рассматривает возможность более открытой разраб..." –3 +/–

Сообщение от iZEN (ok), 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

Ответить | Правка | Наверх | Cообщить модератору

160. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Michael Shigorin (ok), 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.  Их немного, но лучше знать.

Ответить | Правка | Наверх | Cообщить модератору

166. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 24-Мрт-14, 04:15

>> Она представила результаты на конференции LISA V в октябре 1991 года.
> Занавес.
У них там походу всегда полшестого и всегда пора пить чай...

Ответить | Правка | Наверх | Cообщить модератору

207. "Компания AMD рассматривает возможность более открытой разраб..." –4 +/–

Сообщение от iZEN (ok), 24-Мрт-14, 21:44

>>> Она представила результаты на конференции LISA V в октябре 1991 года.
>> Занавес.
> У них там походу всегда полшестого и всегда пора пить чай...
У линуксоидов, походу везде кривизна прослеживается, кроме них самих, поэтому и NIH-синдром развился. В конечном итоге цель более-менее стала ясна: SystemD потихоньку будет перенимать "нужные" функции ядра, и настанет такой момент, что linux kernel можно будет удалить...  :))

Ответить | Правка | Наверх | Cообщить модератору

210. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от ананим (?), 24-Мрт-14, 21:51

Я б поспорил, если бы не выглядел так жалко.

Ответить | Правка | Наверх | Cообщить модератору

218. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 25-Мрт-14, 04:37

> NIH-синдром развился.
У NIH есть и положительные стороны - иногда софт полезно улучшать. Иначе мы бы так и цеплялись за CP/M и multics. Ну а что, как-то работало же.
> В конечном итоге цель более-менее стала ясна: SystemD потихоньку будет
> перенимать "нужные" функции ядра, и настанет такой момент, что linux kernel
> можно будет удалить...  :))
Это вообще феерическое по уровню ламерства заявление.

Ответить | Правка | Наверх | Cообщить модератору

186. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Stax (ok), 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), 24-Мрт-14, 19:36

> Нет, dump/restore в Solaris 11 нет в принципе.
Спасибо.
> В любом случае, dump/restore настолько непереносим (между разными ОС,
> разными архитектурами процессора в одной ОС, иногда даже разными ФС в одной ОС),
> что очень хорошо, что он сдох...
Вот и пытался объяснить гостю с windows 8...

Ответить | Правка | Наверх | Cообщить модератору

204. "Компания AMD рассматривает возможность более открытой разраб..." –1 +/–

Сообщение от iZEN (ok), 24-Мрт-14, 21:04

XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо?

Ответить | Правка | Наверх | Cообщить модератору

209. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от ананим (?), 24-Мрт-14, 21:49

XFS — единственное что и использую на серверах (не под ораклом пока).
Но дамп/ресторе не пользуюсь. Она (как и все) кэши не учитывает.
А не_консистентный дамп я могу получить и банальным копированием файлов плюс редологи.

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

223. "Компания AMD рассматривает возможность более открытой разраб..." –2 +/–

Сообщение от iZEN (ok), 25-Мрт-14, 14:50

Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck.

Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

229. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 25-Мрт-14, 15:35

> Так смысл в том, что dump/restore работают с консистентным набором блоков ФС.
А зачем тебе "консистентный набор блоков ФС"? Консистентный набор блоков != консистентное состояние файлов с точки зрения софта. Человеков по идее интересует консистентный набор файлов в бэкапе. Т.е. некое состояние, которое можно раскатать и чтобы это потом еще и работало, желательно без спецэффектов. А вот тут возможны варианты. В конечном итоге все упирается в то, что софт понятия не имеет о том что его бэкапят, поэтому он делает с файлами все что хочет. Бэкап "на горячую" подхватывает файлы в состоянии "как есть" и это весьма зависит от логики работы программ. Никаких гарантий что для произвольной софтины такой набор файлов будет рабочим - нет! В местах где это реально критично, типа баз данных - делают отдельные программные интерфейсы через которые можно отсигналить движку о бэкапе, чтобы он на время угомонился и/или получить выгрузку заведомо консистентных данных для бэкапа "сбоку".

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

230. "Компания AMD рассматривает возможность более открытой разраб..." –2 +/–

Сообщение от iZEN (ok), 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 рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 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 +/–

Сообщение от ананим (?), 25-Мрт-14, 17:49

>Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck.
Окуенный плюс.
А то, что этот дамп будет с битыми данными и нафиг не нужен — это что, мелочи?
Ты случаем не маркетинговом отделе мс работаешь?

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

237. "Компания AMD рассматривает возможность более открытой разраб..." –1 +/–

Сообщение от iZEN (ok), 25-Мрт-14, 19:34

>>Так смысл в том, что dump/restore работают с консистентным набором блоков ФС. После их работы не нужна дополнительная проверка fsck.
> Окуенный плюс.
> А то, что этот дамп будет с битыми данными и нафиг не нужен — это что, мелочи?
Это другой уровень задач. ФС в общем случае не решает задачи сохранения транзакционности пользовательских данных, она следит только за целостностью метаданных и отдельных файлов.
Файлы не есть синоним данных, как же вы это никак не поймёте?! "Данные" — это осмысленная сущность в тех механизмах, в которых они обрабатываются. Для ФС "данными" являются файлы, метаинформация. Для пользователя "данными" являются, к примеру: каталог почтового клиента с файлами почтовой базы, набор реляционных таблиц с информацией в файловой РСУБД, Web-документы (*.html, *.jpeg, *.js, *.css), документы текстового процессора, проекты среды программирования, проекты фото- и видео-редакторов, состоящих из нескольких согласованных между собой файлов — этими сущностями должны управлять соотвествующие инструменты. Если пользовательские данные во время бэкапа открыты для редактирования, то dump не виновата, что сохранила "не то".

Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

241. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 25-Мрт-14, 23:26

> Это другой уровень задач. ФС в общем случае не решает задачи сохранения транзакционности пользовательских данных
Именно.
И именно поэтому она также не играет роли в создании бэкапов и архивов.
Если ты этого до сих пор не понял, то мне жаль твоих работодателей (будь ты админом. И вообще, с какого перепуга ты тут админов "учить" начал?)

Зыж
> Файлы не есть синоним данных, как же вы это никак не поймёте?!
Идиотское утверждение.
Для ФС — это данные. Были, есть и будут. И не более.

Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

244. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от цирроз (ok), 27-Мрт-14, 12:17

в интернетах так заведено: кто меньше всех знает - старается давать советы, или учить ;)

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

217. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 25-Мрт-14, 04:34

> XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо?
Не то чтобы "плохо", просто нишевая хрень, носиться с которой как с писанной торбой - совершенно нет причин, имхо.

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

224. "Компания AMD рассматривает возможность более открытой разраб..." –3 +/–

Сообщение от iZEN (ok), 25-Мрт-14, 15:00

>> XFS  поддерживает инкрементные dump/restore на смонтированной системе.  Что, тоже плохо?
> Не то чтобы "плохо", просто нишевая хрень, носиться с которой как с
> писанной торбой - совершенно нет причин, имхо.
Что, альтернатива лучше? Сколько этих альтернатив, которые имеют свои кривые стороны? И зачем они нужны, если dump/restore — это решение бэкапа ФС в Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо. Если в Linux такое не приветствуется, то это, считай, вторая винда с "многообразием разнообразных".

Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

233. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 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), 25-Мрт-14, 19:23

>> И зачем они нужны, если dump/restore — это решение бэкапа ФС в Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо.
> Вот поэтому и есть tar.
tar работает гораздо медленнее dump.

Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

242. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от ананим (?), 25-Мрт-14, 23:28

А рсинк нет. И?
К тому же tar'ом я могу бэкапить избирательно, что и делается в подавляющем большинстве случаев. Так что враньё.

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

243. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 26-Мрт-14, 04:47

> tar работает гораздо медленнее dump.
Ну тогда бэкап в /dev/null - по любому чемпион.

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

247. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 27-Мрт-14, 17:53

> tar работает гораздо медленнее dump.
А автомобиль ездит медленнее чем летает ракета. Но назвать ракеты стандартным средством передвижения я бы не рискнул.

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

249. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Michael Shigorin (ok), 27-Мрт-14, 18:44

> Что, альтернатива лучше? Сколько этих альтернатив, которые имеют свои кривые стороны?
> И зачем они нужны, если dump/restore — это решение бэкапа ФС в
> Unix, где каждая программа должна выполнять одну функцию, но делать это хорошо.
Изя, Вы хоть сами-то поняли, что спорите с самим собой?
dump/restore дублируют реализацию ФС в ядре по определению.
EOT

Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

152. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 23-Мрт-14, 22:58

>линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD
Intel вроде бы еще отказался пилить Gallium3D для своих интеграшек.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

197. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 24-Мрт-14, 19:56

> Intel вроде бы еще отказался пилить Gallium3D для своих интеграшек.
Да. У них свое собственное добро. Как бы их право. Есть мнение что за счет этого оверхед ниже.

Ответить | Правка | Наверх | Cообщить модератору

161. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Michael Shigorin (ok), 24-Мрт-14, 01:05

> а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD
Надо же, главное -- не рассказывать ноуту, с которого и пишу.  А то тут как раз fullhd и немножко на порядок больше.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

225. "Компания AMD рассматривает возможность более открытой разраб..." –2 +/–

Сообщение от iZEN (ok), 25-Мрт-14, 15:03

>> а линуксоиды продолжают жевать кактус с Intel KMS/DRM c 5-6 FPS в 3D на Full HD
> Надо же, главное -- не рассказывать ноуту, с которого и пишу.
А вы с ноутом общаетесь, что-то ему рассказываете? Ну надо же.

Ответить | Правка | Наверх | Cообщить модератору

227. "Компания AMD рассматривает возможность более открытой разраб..." +2 +/–

Сообщение от Andrey Mitrofanov (?), 25-Мрт-14, 15:08

>>> c 5-6 FPS в 3D на Full HD
>> не рассказывать ноуту, с которого и пишу.
> А вы с ноутом общаетесь, что-то ему рассказываете? Ну надо же.
В Новости на Главной! iZEN нипонял сарказма, направленного на него.

Ответить | Правка | Наверх | Cообщить модератору

235. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Карбофос (ok), 25-Мрт-14, 19:21

а зачем обыденное событие отмечать в новостях?

Ответить | Правка | Наверх | Cообщить модератору

162. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 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), 24-Мрт-14, 21:11

>> dump(8)/restore(8) на подмонтированной с o rw EXT4 хотя бы работает?
> Без понятия. Ты лучше скажи какая цель этого?
Делать бэкап файловой системы, не отмонтируя или предварительно отмонтируя - неважно - главное, однообразно и очевидным образом.
> У меня нет цели
> в жизни "запустить программу dump на EXT4 в rw". Я предпочитаю
> какие-то осмысленные цели, понятные мне и ведущие к каким-то практически полезным
> результатам. Нельзя ли озвучить цель этой возни в человекочитаемом формате? Ну,
> чтобы иметь дело с проблемой - надо для начала понимать в
> чем она состоит. Что мы хотим получить. Что получается по факту.
> Какие отличия имеются и что надо изменить.
А сейчас ты как делаешь бэкапы корневой ФС?

Ответить | Правка | Наверх | Cообщить модератору

214. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от ананим (?), 24-Мрт-14, 22:10

> А сейчас ты как делаешь бэкапы корневой ФС?
Таром я делаю.
Потом загоняю в черут (вообще-то сразу через пайп), устанавливаю нужный сервис и вот, новая виртуалка для ксена готова.
Овер 50 в продакшене уже таких.

Ответить | Правка | Наверх | Cообщить модератору

215. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Michael Shigorin (ok), 25-Мрт-14, 00:28

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

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

219. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 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), 25-Мрт-14, 11:58

> Бывают более навороченные бэкапные софтины, на все вкусы, запросы и умения.
О чём можно говорить про бэкап с человеком, который ссылается на 1991 год и не понимает разницы в скорости роста пропускной способности и объёма носителей с тех пор?..
Хорошая метрика "на глазок" -- время полного чтения одного носителя.

Ответить | Правка | Наверх | Cообщить модератору

226. "Компания AMD рассматривает возможность более открытой разраб..." –3 +/–

Сообщение от iZEN (ok), 25-Мрт-14, 15:07

>> Бывают более навороченные бэкапные софтины, на все вкусы, запросы и умения.
Бывают бэкапилки Windows...
> О чём можно говорить про бэкап с человеком, который ссылается на 1991 год и не понимает разницы в скорости роста пропускной способности и объёма носителей с тех пор?..
А что с тех пор изменилось в классических файловых системах? Они разве не отмасштабировались на современные требования пропускной способности, многоядерности процессоров, большого объёма данных? Тогда, простите, как вы с ними работаете, если у вас до сих пор нет подобной ZFS в продакшене, а только "классика"?!
> Хорошая метрика "на глазок" -- время полного чтения одного носителя.
У вас носитель "однозадачный" и/или требует монопольного доступа при бэкапе данных?

Ответить | Правка | Наверх | Cообщить модератору

231. "Компания AMD рассматривает возможность более открытой разраб..." +1 +/–

Сообщение от Аноним (-), 25-Мрт-14, 16:22

> Бывают бэкапилки Windows...
Бывают. И даже простой ntbackup выделяет известные ему виды баз данных из общей массы, например. Разумеется только MSовские. А что не выделяет... ну ... "какой-то" бэкап тебе сделали! А дальше проблемы индейцев шерифа не волнуют, эхехе.
> если у вас до сих пор нет подобной ZFS в продакшене,
Изя, выкинь саночный маркетинговый булшит из головы.
> У вас носитель "однозадачный" и/или требует монопольного доступа при бэкапе данных?
Нет. В этом то как раз и проблема - софт может делать там все что пожелает. Откуда вытекает что в общем случае корректность бэкапа вообще не гарантирована.

Ответить | Правка | Наверх | Cообщить модератору

228. "Компания AMD рассматривает возможность более открытой разраб..." –2 +/–

Сообщение от iZEN (ok), 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 +/–

Сообщение от ананим (?), 25-Мрт-14, 17:59

> Что мешает остановить софт, который меняет файлы?
Дурость айзена мешает.
зыж
Ты понимаешь, что только что договорился до single-mode?
Ну не кретин ли.

Ответить | Правка | Наверх | Cообщить модератору

238. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 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), 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.

Ответить | Правка | Наверх | Cообщить модератору

245. "Компания AMD рассматривает возможность более открытой разраб..." +/–

Сообщение от Аноним (-), 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), 24-Мрт-14, 15:11

>> Собственно, процент фэйлов собственных наработок бздюков уже давно поражает воображение.
> Собственно, в Linux до сих пор нет рабочей файловой системы со снапшотами.
В BSD с фатальным недостатком. Её не писали ребята из BSD.

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

208. "Компания AMD рассматривает возможность более открытой разраб..." –1 +/–

Сообщение от iZEN (ok), 24-Мрт-14, 21:47

> В BSD с фатальным недостатком. Её не писали ребята из BSD.
Неудачная попытка пошутить.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


	15. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok), 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.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


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


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


	130. "Компания AMD рассматривает возможность более открытой разраб..."	–4 +/–
	Сообщение от iZEN (ok), 23-Мрт-14, 20:43
	>> Всех бздунов выкинули из комитета Xorg. Ну и причём тут бзды? > Угу. Вот только иксы под мит, а рулит там Аарон из оракла в основном. Товарищи из комитета X.Org буквально вышвырнули из управляющего совета MacOS'ников и BSD'шников: http://www.opennet.ru/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'у спасибо за это или нет? ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	151. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (-), 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), 24-Мрт-14, 21:36
	nvidia.ko и модуль ядра из Каталиста почему-то лучше знают о GPU, чем KMS с DRM - так как на вид работают тупо быстрее и лучше. ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


	136. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Аноним (-), 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), 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 поддержит их, портируя Каталист в эту бесперспективную схему.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	144. "Компания AMD рассматривает возможность более открытой разраб..."	+/–
	Сообщение от Michael Shigorin (ok), 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 Это правда.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	158. "Компания AMD рассматривает возможность более открытой разраб..."	–3 +/–
	Сообщение от iZEN (ok), 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
	Ответить \| Правка \| Наверх \| Cообщить модератору


	160. "Компания AMD рассматривает возможность более открытой разраб..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 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. Их немного, но лучше знать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


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