<<<предыдущий список следующий>>>

Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer.


6 Сентября

А всё ж Intel невзлюбил FireWire. Apple явно переборщил с претензиями и лишился Intel-овской поддержки. В итоге 1394 не получил подкрепления в виде присутствия в чипсетах от Intel, не стал повсеместно распространён, как USB, и вдобавок вот-вот лишится одного из последних преимуществ - скорости. Останутся неиерархичность и поддержка производителями видеокамер, но вытянет ли одно это... Дополнительный 1394-й контроллер стоит дорого, сравнимо со SCSI.

Я уже говорил, что готовится стандарт USB 2.0, который будет высокоскоростным. Но придётся повторить. Если ранее рассматривалось увеличение скорости в 10-20 раз, то есть максимум до 240 Мбит/сек, то нынче аппетиты возросли, и заявлено, что USB должон стать быстрее в 30-40 раз!

Это в корне меняет дело. Ускорение до 240 Мбит/сек - это, конечно, здорово, но всех проблем не решает - шина с такой скоростью как-то непонятно, к чему: для мышки многовато, а для винта... ну, внатяг. Можно, но будешь чувствовать себя чуток обманутым.

Вот 480 - это совсем иной коленкор. Это быстрее, чем стандартная, "неразогнанная" 1394 (400 Мбит/сек) и вполне пригодно для всех бытовых применений, от подключения быстрых винчестеров до передачи видеопотока в реальном времени.

Другой момент. Если доселе предполагалось, что Device Bay будет содержать два порта - USB и FireWire, то теперь для подключения того же диапазона периферии достаточно первого. По крайней мере, в теории.

Впрочем, в любом случае с объявлением USB 2.0 на 480 Мбит/сек позиции 1394 в очередной раз пошатнулись. Очередной, но самый серьёзный. Рассмотрим два оставшихся плюса 1394. Равнозначность узлов и поддержку в видеоаппаратуре.

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

На практике же, если нам нужна связь двух периферийных устройств без компьютера, то минимум одно из них должно эту функцию поддерживать - инициировать соединение. В 1394 для этого требуется только программная поддержка, в USB - ещё и наличие второго порта: одного - "в сторону" компьютера, другого - "в сторону" подчинённого периферийного устройства.

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

Короче, по этому пункту (ненаправленности связей) преимущество у 1394 есть, но вес его - под вопросом.

Второе преимущество 1394 - реальное присутствие этого порта во всех поголовно бытовых и полупрофессиональных цифровых видеокамерах - нельзя победить иначе как вытеснением, и возможно это не ранее чем с середины будущего года. Более того, это сложная задача, и Intel года на два с ней опоздал. Тут всё будет зависеть от того, какие чипсеты будут поддерживать USB 2.0, сколько они будут стоить, и дорого ли в итоге обойдётся добавка во все видеокамеры второго порта - от установки 1394 они вряд ли легко откажутся.

Но, с другой стороны, если поставить USB 2.0 будет стоить не дороже $10-20, успех его предрешён - сначала в камеры будут ставить оба порта, а потом, вероятно, останется лишь USB.

Но это не раньше чем года через 2-3.

Интел нашёл нетривиальный ход в плане поддержки USB: предлагается стандартизовать (де факто) USB как периферийный порт для автомобильного компьютера - с тем, чтобы таскать периферию из дому в машину при необходимости. Для принтера это сегодня не слишком актуально, а вот цифровой фотоаппарат слить на автомобильный компьютер - это уже придётся кстати.

Кстати, Интел вообще как-то "заметил" существование автомобиля и связанного с ним рынка. Правда, ещё раньше его заметил Микрософт, подвинув в сторону авторынка свой WinCE, который переносимый. Это создало угрозу возникновения широкого не x86-совместимого рынка. Интел тут же отреагировал. Ну или почти тут же.

Предъявлен концепт-кар (Форд Экспедишн) - кар как кар, только вот установлен в него Пентиум-166 (не II и не III - просто MMX) со специальным температурным диапазоном - держит -40. Держит ли -40 экран LCD - не сказано.

Функциональность - от глобальной навигации до просмотра DVD-фильмов и игры в игрухи. Цена не названа - это концепт. А жаль. Уровень хардвера таков, что это надо срочно на рынок, пока не подпортилось.

Разные люди разные вещи зовут по-разному. Даже в пределах одного языка. Взять хоть питерский поребрик, северного брата московского бордюра. Это нормально, и наличие интеллекта, а значит, способность решать незапланированные задачи, позволяет нам общаться, даже имея не совсем совпадающие "словари".

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

Но это вообще. В частности существует проблема разных названий одного объекта. Одно из наиболее известных проявлений сей проблемы - имена файлов в сети. Очевидно, что с разных компьютеров они зачастую разные. У одного этот файл - C:\docs\public\mytext.doc, у другого - X:\mytext.doc. Теперь пусть одна программа передаёт другой имя файла для того, чтобы та тоже могла насладиться его содержанием. Ну, например, путём помещения этого имени в иной, совместно используемый файл. Если вторая программа работает на том же компьютере, что и первая - проблем нет, имя подойдет. А коли нет? Пусть вторая программа работает на сервере или просто на иной рабочей станции. С её точки зрения, предложенное первой программой имя файла или просто неправильное, или, хуже того, соответствует какому-либо иному файлу.

Windows предлагают метод решения этой проблемы - преобразовывать все имена доступных с сети файлов в формат UNC. Метод неплох, но только для Windows. А есть же и другие ОС, другие сети (кроме Microsoft Network), соответственно, другие правила именования. Кроме того UNC базируется на Windows-имени компьютера, а оно в масштабах вселенной (да и даже пары этажей хорошего офисного здания) не уникально ни в какую. А значит применимость его ограничена по определению.

Нужно что-либо более глобальное, чем UNC - системонезависимое, абсолютное и всепланетное. Есть такое?

А есть. Давайте использовать URL как имя файла. А? Префикс (то, что перед двоеточием) пусть обозначает как и раньше имя протокола - нужно только добавить несколько имён к известным, и будут:

win://relay.dz.ru/store/Quake3_diskt.zip - сеть MS Net, машина relay.dz.ru, ресурс store.

nfs://nfs.freebsd.org/security/socks5-v1.0r8.tar.z - NFS

Ну и так далее. Соответственно, доступ к файлам по этим именам должен поддерживаться ядром ОС. Идёт?

На Прописях - новый принтер от Lexmark - Z51 и "В поисках утраченных слов" - рассказ об обучающем английскому языку диске.