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

Никогда не замечал за тобой порывов к демагогии. Я где-то говорил, что это относится к ядру? Я где-то говорил, что это единственное новшество?

Нет. Просто выше фраза была именно про то, что виста на дяерном уровне сильно превзошла икспю. Затем единственное отмеченное новшество - вот ента вещь... Ну... просто немного странно выглядит с моей стороны. Сорри, раз не прав (думаю без обид обойдёмся  ).

Да и кстати, именно это я причислю к UI. Это не украшательства UI, это юзабиллити UI 

К тому же я, в принципе, "за" украшательства. Composite extension, введённый действительно именно в висте - да, это нововведение. Не обалденное, но нововведение. А вот все эффекты можно было бы даже не включать в большинство редакций. В какую-нибудь мультиммедийно-украшательно-ориентированную - да, но не более. Отдельный пакет, конечно, был бы доступен всем. Лично мне здесь (как и всегда, пожалуй) не нравиться именно политика МС.

В техническом плане висту толком не юзал. Но, как уже говорил, у меня тормозило прилично (с Аэро). P4 3.0GHz, 512 DDR2, Intel 82945G Integrated Graphics Controller.

Да и количество и нелогичность многих официально (в МС) зарегенных багов меня пугает. Не-не, я не против них - то, впрочем, отдельный разговор. Но (как я и говорил выше) нефиг это называть релизом. Макисмум, RC какой-нибудь.

Добавлено через 4 минуты и 17 секунд

Не знаю. У меня работают нормально. Впрочем из явовских гуишных приложений пользуюсь мало чем... Оценить сложно. Azareus-ом раньше пользовался - вполне нормально работал. Эклипс, конечно, юзаю, но причём тут АВТ?  Плюс, замечу у меня берил. Впрочем, по идее дело в composite. Фиг его. Тут много важных моментов (всмысле что за версия сего): XOrg, XGL/AIGLX, Compiz/Beryl, MToolKit.

Добавлено через 4 минуты и 50 секунд

Если не секрет - что за приложение столь важное?

Я не специалист по Windows kernel-level. Я читал ряд обзорных статей на технических ресурсах. Из того что запомнилось: transactional NTFS, изменения в async I/O. В изменениях в системе драйверов я даже не пытался разобраться.

Проехали 

И которое, по-моему скромному мнению, не менее, а то и более важно всего остального  Конечно, эта юзабельность должна быть юзабельна  по совокупности performance etc.

Не секрет  jedit. Преимущества compiz не перевешивают удобства этого замечательного редактора.

Стоп. А раньше как было?   Или я что-то не догоняю...


Тем более не понятно - про что конкретно речь.


Ага. Я, конечно, тоже. Но половина интерфейсов из DDK были выкинуты, о чём говорит MSDN. Со звуком много чего-то напортачили... Знаю реальных людей у кого из-за этого проблемы. Самое интересное, что некоторые функции оставили заглушками. Раньше было наоборот - в Win 9x чтой-либо не реализовано, а в нормальных виндах вроде как есть. А в Висте (именно про дровяной АПИ речь) решили наоборот. Я, конечно, понимаю: "мы круты, у нас новые интерфейсы для устройств...". Но людям от этого явно лишь минус. Да и драйвер-девелоперам больше мину, чем плюс.


Да важно-важно. Не спорю, ибо факт. Но не это есть новая операционка  Тем более, что именно о юзабиллити висты в начале этой темы как-то так не добрым словом говорили.


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

Раньше было как раньше  А сейчас, как в БД, можно начать транзакцию, содержащую произвольные операции с файлами и каталогами, которые будут либо все закоммичены, либо произойдёт откат. Полный ACID.
Вот серия из трёх статей Марка Руссиновича о нововведениях в ядре Висты (ссылка уже была на форуме):
Часть 1, 2, 3.

Добавлено через 1 минуту и 27 секунд
P.S. Про неудобства с дровами согласен. Опять приходится ждать всем, пока устаканиться переход. Но ситуация с драйверами везде плачевная (кроме Apple разве что, но они это по-своему решают  )

Насколько я знаю в NTFS свегда именно так и было. Мож я туплю...

Насчёт ссылок - может они раньше и были, я на споры Vista vs NoVista редко обращаю внимание. Уж такой я  Сейчас почитаю, пожалуй 

Нет. Просто гарантировалась целостность метаданных в случае сбоя. О том, чтобы делать что-то с несколькими файлами одновременно транзакционно, речи не было.

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

MAKCim, было, конечно было. Но гарантировалась именно что только непротиворечивость на уровне ФС (соответствии данных и метаданных). О непротиворечивости с т.з. прикладной логики ФС знать не могла.
Речь о другом. Теперь стало возможно такое:

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

В MSDN всё достаточно подробно описано.

Void, 
это конечно хорошо, но вот мне сразу на ум пришло следующее
действия между

и

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

памяти не хватит для выполнения записи, произойдет откат на все уже выполненные операции
т. е откат произойдет не по причине напрямую связанной с действиями над файлами (директориями), а из-за внешней причины, что плохо

MAKCim, с чего вдруг? Ведь в БД объём транзакций не ограничен объёмом свободной памяти.
Я не знаю подробностей реализации transactional NTFS, но, скорее всего, как и в БД, используется лог транзакции, который накатывается по коммиту. Не думаю, что дойдёт до

К сожалению, у меня сейчас нет Висты, чтобы поэкспериментировать с большими транзакциями.

ты немного не так понял

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

Откат и будет. Точно так же как и в БД, если нехватает памяти на транзакцию, идет ошибка и откат. Только вот почему именно память, мы можем взять на диске свободную область и писать туда, а по завершению транзакции скзать, что эта область и есть файл А.

LSD, 
OK, здесь проблему решили
тогда еще один момент: удаление файла
удаление также должно быть фиктивным, т. е сектора диска, где физически расположен файл, до завершения всех операций не должны помечаться как свободные
допустим, что диск забит под завязку
мы начинаем группу транзакций, а именно: 
1. Удаление большого числа маленьких по размеру файлов или малого числа больших файлов (этих действий, допустим, 100)
2. Создание 100 файлов и запись в них
проблема в следующем: после п. 1 реального места на диске нет, значит,  LSD, твой вариант с записью на диск не прокатит, остается память, но, как я уже сказал, памяти может не хватить, итого - откат   
т. е теоретически вышеприведенные операции - взаимоисключающиеся, но на практике возникает проблема


Это сообщение отредактировал(а) MAKCim - 25.6.2007, 17:23

MAKCim, сломать можно всё что угодно. С тем, что транзакционная ФС — это хорошо, ты вроде согласился. А ты можешь представить такую ФС, которая поведёт себя в этой ситуации по другому? Reiser4 вроде поддерживает транзакции. Как там пройдёт такая операция?

По крайней мере, в этом сценарии не пострадают имеющиеся данные. Это лучше, чем удалить 100 файлов, а потом обнаружить, что для 99-го нового не хватает места.