В споре Линуса с Дреппером вокруг memcpy я на стороне

> Грубо говоря, разработчики glibc могут оказаться в том же самом положении, в какое они поставили adobe и компанию

1. Т.е. тот факт, что рарзабы глибцы сменили реализацию именно ради «разработчика процессора» до твоего затуманенного сознания не дошел?

2. То, что «в положение» «адоб и компания» поставила себя сама, до тебя, похоже, никогда не дойдёт. Тут уж медицина бессильна.

>Вы так ничего и не поняли - проверка непосредственно на пересечение не нужна. Необходимо и достаточно лишь выбрать правильное направление копирования, а это направление уже выбирается и именно этим условием
Да ничего. Проверка определяет взаимное положение блоков, а не пересечение. То что эту проверку можно использовать для решения сабжевой проблемы это безусловно. Но интеловцы используют её для оптимизации. Невозможно одну и туже проверку использовать и для оптимизации и для решения сабжа. Это взаимоисключающие вещи. Вот если бы опредлить ещё и пересечение и в случае его..., то тогда...

Невозможно одну и туже проверку использовать и для оптимизации и для решения сабжа. Это взаимоисключающие вещи.

Я же говорю, всё достаточно просто...
Если хорошо подумать, конечно

Вы бы объяснили что-ли на пальцах. Ну не доходит.

Вы сейчас всё правильно поняли

>Вы сейчас всё правильно поняли
Троллите.

Троллите

А я ведь мог и порвать...

Ну так эта проверка сделана в целях оптимизации. То есть без дополнительной проверки, в данном случае уже на пересечение, не обойтись всё равно.

>А я ведь мог и порвать...
Сори, недопонимание произошло. ^)

VMWare перестала выпускать свой продукт VMWare Server для Linux
Не было такого. Они потом его перестали выпускать, но перестали совсем, в том числе и для Windows.

Самое разумное это адобовцам открыть багзиллу и перестать играть с причинным местом.
https://bugs.adobe.com/jira/browse/FP-5739

А в ADOBE баг запостили? У меня поиск не нашел его на https://bugs.adobe.com.
> А то может живут ребята и не знают какой раскол внесли?
https://bugs.adobe.com/jira/browse/FP-5739

А вообще, есть такая фигня что Майкрософт в 90-е годы обложил винду воркараундами для того чтобы обеспечить работоспособность под ней всех популярных DOS-программ. Даже для SimCity 2000 там сделан специальный аллокатор памяти в встроенном ДОС-е, поскольку игра неправильно работает с памятью, но в ДОС-е это не проявляется. В результате Винда была на коне, а все остальные sosnooley.
А был ли в той истории стандарт на MS-DOS (речь ведь идёт о приложениях, совместимых именно с MS-DOS?) и его (MS-DOS) сторонние реализации? И, если были, насколько ухудшил бы ситуацию Microsoft тот путь, который они спустя годы избрали для Висты и Семёрки - возможность выбора режима совместимости (в котором на полную катушку включаются реактивные костыли) в свойствах ярлыков?

> А был ли в той истории стандарт на MS-DOS

Нет, не было. На него все забили.

насколько ухудшил бы ситуацию Microsoft тот путь, который они спустя годы избрали для Висты и Семёрки - возможность выбора режима совместимости

MS с самого начала сделала режим полной эмуляции, но, для этого приходилось полностью выгружать саму систему. В этом режиме всё работало идеально. И да, в этот режим можно было включить в свойствах ярлычков.

:3

Забыл ответить. В этой истории я на стороне Qingyan zhu - сотрудника Adobe, который будет фиксить баг во Флеше.

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

Кстати, а кроме Adobe Flash найдётся хотя бы пять программ, работа которых серьёзно нарушается из-за изменений в memcpy. А то похоже весь крик из-за массовости Flash, но ведь 64-разрядный Flash для Linux пока бета, к релизу (а релиз 64-разрядных версий Flash будет одновременным для Windows и Linux) этот баг будет исправлен.

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

Хм, не знал.