"можно ли заставить работать новое или нестандартное железо"
А зачем нужно новое или нестандартное железо? Мне вот хватает того, которое есть.

Я предлагаю производителям оного либо выработать краткий список стандартных протоколов, либо убить себя об своё железо. Задолбали уже плодить проприетарные какашки. Именно из-за них, зараз, IT и топчется на месте.

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

Ваши ответы подтверждают предположение,
которое у меня закралось, когда я писал свои вопросы.

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

Поверьте, программирование значительно шире.
Есть многое, Горацио, в программировании,
что и не снилось нашим мудрецам.

Теперь пару слов в ответы.

Я предлагаю производителям оного (оборудования) либо выработать краткий список стандартных протоколов, либо убить себя об своё железо. Задолбали уже плодить проприетарные какашки. Именно из-за них, зараз, IT и топчется на месте.

К сожалению,
стандартные протоколы в данном случае стали бы гораздо большим тормозом.
Если у устройства нет новых возможностей по сравнению с уже существующими,
его вообще незачем производить, не так ли ? Бывают, конечно, устройства,
лучше реализующие уже существующую функцию, и они могут прикидываться
чем-то более старым, так что софт даже не заметит подмены. Но большинство
устройств делает нечто, чего до того не было. И для управления этим чем-то,
как ни крути, придется расширять программный интерфейс и писать
специализированный софт. К слову, это касается
и "революционной" оптимизации ранее существующих функций, к примеру:
видеопроцессоры, устройства шифрования или ускорители других специальных
вычислений. Я, например, сталкивался с адаптерами нетрадиционных
(для мира персональных компьютеров) сетевых протоколов.

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

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

Мне всегда больше нравилось шарашить по регистрам и обрабатывать прерывания от железа.
Там такие загадки встречаются, "вам и не снилось" :) (это я не лично о Вас, это цитата)
А когда мне надо сделать формочку с кнопочками, я беру Delphi или Qt,
с помощью которых это можно сделать не за полдня, а за пять минут.

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

Для того, чтобы через стандартные интерфейс GUI можно было нарисовать на экране
форму, нужно, чтобы сначала на этом экране кто-то научился рисовать точки.
Особенно если это экран нового типа, на принципиально новом физическом
принципе, и - соответственно - с совершенно новыми методами управления.
Конечно, кто-то уже написал драйвер или интерпретатор метафайлов или
что-то другое, что позволяет рисовать эти точки и даже целые формы...
Ну так ведь этот КТО-ТО тоже программист, и если мы хотим говорить
за всю отрасль, его тоже надо сосчитать. Кто сказал, что его работа
менее интересная или менее достойная ? Если считать по числу распространяемых
копий, автор любого драйвера переплюнет подавляющее большинство прикладных программистов :) Чем не "максимальный" результат ?

Я хотел бы, чтобы экран нового типа работал как экран старого типа, только лучше.

Никаких новых методов управления, никаких новых низкоуровневых протоколов, уже угомонитесь.

Напишите один ёмоё драйвер под один, с запасом, протокол обмена данными, и придерживайтесь.

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

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

Во-вторых, хочу Вам напомнить, что только для обмена данными,
безотносительно их природы, придумали аж 7 уровней протоколов...
типа неспроста. А нам надо бы учесть и природу данных и цели обмена ими.

В-третьих, универсальный протокол, о котором Вы говорите, уже давно
есть (и не один, это Sun RPC, Java RMI, COM/DCOM и еще парочка на эту тему).
Действительно универсальные, в них можно вложить любую функциональность.
К несчастью, эти протоколы настолько универсальные, что для использования в
конкретных приложениях нужно разрабатывать специальный софт,
обеспечивающий "специализацию". Функциональную сложность нельзя уничтожить,
можно только "выдавить" ее из одного места в другое (в данному случае -
в прикладные программы). Это может и "крайний" пример, но он подчеркивает
общую закономерность. Универсальные протоколы бывают, а чудес - не бывает :)

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

Если я Вас не убедил или хотя-бы не заставил усомниться,
то у меня больше нет слов

"В-третьих, универсальный протокол, о котором Вы говорите, уже давно
есть"
И он называется HTTP.

А вот у железячников такого нету. Кроме того, даже в случае USB, где протоколы есть, всё равно пишется по десять драйверов на один протокол.

"любой современный видеопроцессор исправно работает в режиме VGA, но чтобы включить его наиболее вкусные функции, нужен специальный драйвер и специальный софт."
Это и плохо. Пусть он исправно работает в режиме VGA, только с произвольным разрешением и частотой обновления, со стандартным драйвером; в таком случае его "вкусные" функции нам и вовсе не нужны.
А если нужны (hardware scaling, например), то есть много лет, чтобы внести эти функции в стандарт, которого и придерживаться.

Мне сомневаться не в чем. Я вижу, что софт в среднем работает на четверку по пятибальной, но только там, где дело не доходит до железа. Где доходит, там софт в среднем работает на два балла. Я боюсь, что неспроста!

> "В-третьих, универсальный протокол, о котором Вы говорите, уже давно
> есть"
> И он называется HTTP.

Меня несколько удивил Ваш выбор...
Поверьте, протокол TCP гораздо более универсальный! :)))

> А вот у железячников такого нету. Кроме того, даже в случае USB, где протоколы
> есть, всё равно пишется по десять драйверов на один протокол.

Это неправда.
ISA, EISA, PCI, VME...
USB, Bluetooth, WiFi...

А драйвера пишутся не на протокол, а на устройства,
чтобы учесть специфику того, что с другой стороны
провода. И, думается, это неспроста

> в таком случае его "вкусные" функции нам и вовсе не нужны...

Это неправда.
"Вкусные" функции видеопроцессоров, как правило, связаны визуализацией
трехмерного мира (или 2,5-мерного - потому что жульничают, конечно),
что ни через какой стандарт VGA не пролезает. Вам они не нужны, а детям,
которые любят игрушки - нужны (целая категория потребителей!). Для серьезных
людей оно тоже может быть полезно - в различных тренажерах. (Надо ли обсуждать
вопрос, почему наиболее ресурсоемкие вычисления выгодно производить непосредственно
в графической карте, а не на ЦП ?)

> ...А если нужны (hardware scaling, например), то есть много лет, чтобы внести
> эти функции в стандарт, которого и придерживаться.

Дык, что можно, то уже давно внесено (в какой-нибудь DirectX или OpenGL...).
Фишка в том, что "вкусные" функции являются свеженьким изобретением,
которое невозможно заранее внести в стандарт. Кроме того, я догадываюсь,
производителям не всегда этого хочется, чтобы не плодить клонов и хоть
какое-то время побыть монополистом в отношении этих вкусных функций.
Лишите их такого стимула - и прогресс тут же прекратится. (Ну, не весь
конечно, а тот, который стимулировался желанием выиграть за счет новых
фишек в девайсе).

> Где доходит, там софт в среднем работает на два балла. Я боюсь, что неспроста!

Конечно. Работа с железом значительно сложнее, не для китайцев и индусов.

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

"ISA, EISA, PCI, VME...
USB, Bluetooth, WiFi..."
Херовые это стандарты, когда для двух разных карт wi-fi (двух разных видеокарт PCI, двух разных контроллеров ISA) требуются разные драйверы.
Совсем никакие.
Оно и понятно - они вольты регламентируют и диаграмы передачи, а не как это всё должно работать.

"А драйвера пишутся не на протокол, а на устройства, чтобы учесть специфику того"
Вот пусть железячники выкинут свою специфику, и мы все вздохнём с облегчением.
Зачем мне в моей wi-fi карте специфика? Она петь и плясать будет?
Зачем мне специфика в видеокарте? У меня что, пиксели на мониторе треугольные?
Да, 3D не берем в данный момент. Почему нельзя сделать хороший универсальный 2D без этих дурацких специфик??

"Фишка в том, что "вкусные" функции являются свеженьким изобретением,которое невозможно заранее внести в стандарт."
Не нужны мне ваши ядовитые свеженькие, вы мне 2D без драйверов сделайте, наконец.

"Ну, не весь, конечно, а тот, который стимулировался желанием выиграть за счет новых
фишек в девайсе"
А мне не нужны ваши фишки, мне надо, чтобы оно работало из года в год и везде.

"Работа с железом значительно сложнее, не для китайцев и индусов."
Хо-хо! А то я и думаю, почему это китайцы делают 95% железяк?
А оно воно как. Не может, а делает.

"На мой вкус, весь коммерческий софт работает на троечку, что с железом, что без."
Меня не очень интересует коммерческий софт; меня интересует обычно свой софт.
Хотя на стороне сервера с железом и получше (драйверы обычно есть; нет свежих фишек в стиле "я идиот, убейте меня, кто-нибудь"), но всё равно на твёрдую двойку.

Ситуация аховая на самом деле.
Софт работает, работает, работает, а как с железом надо что-то сделать - ступор и коллапс.
А разгадка одна - безблагодатность.
В железе каждую минуту что-то меняется и копошится, тогда как язык C никуда не убегает уже очень много лет, POSIX тоже весьма стабилен.

"ISA, EISA, PCI, VME...
USB, Bluetooth, WiFi..."
Херовые это стандарты, когда для двух разных карт wi-fi (двух разных видеокарт PCI, двух разных контроллеров ISA) требуются разные драйверы.
Совсем никакие.
Оно и понятно - они вольты регламентируют и диаграмы передачи, а не как это всё должно работать.

че-то я не пойму...
Вы вроде за стандарт передачи данных ратовали,
а теперь за хотите стандарт чего-то другого.
Чего ? Интерфейса устройства такого-то класса (назначения)
с процессором и программным обеспечением ?

Хочу стандарт интерфейса между совтом и возможностью пользоваться Wi-Fi.
Передачи данных между совтом и чёрным ящиком "Wi-Fi".

Не понял, на фиг.
Поверх WiFi все равно идет TCP/IP,
который и поверх WiFi, и поверх Ethernet,
и поверх ATM, и даже поверх телеграфных
проводов - все тот же TCP/IP, и здорово-консервативному
софту годится на все случаи жизни.

"Что за задачи, предположить сложно, но зато понятна среда - это"
Машина Тюринга.

Вы поймите, всё это железо, это суета сует.

"Если у устройства нет новых возможностей по сравнению с уже существующими,
его вообще незачем производить, не так ли ?"
Какие "новые возможности" большего жесткого диска, более крупного модуля памяти, более быстрого процессора требуют курочить их поведение? А ведь курочат.

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

"Мне всегда больше нравилось шарашить по регистрам и обрабатывать прерывания от железа."
Я вам мешаю, что ли? Играйтесь в своих солдатиков.

"с помощью которых это можно сделать не за полдня, а за пять минут."
Давайте без цирка.
За пять минут вы нос высморкать не успеете.

Вы поймите, всё это железо, это суета сует.

Это просто Ваш выбор. А я здесь причем ?

Какие "новые возможности" большего жесткого диска, более крупного модуля памяти, более быстрого процессора требуют курочить их поведение? А ведь курочат.

Хотя бы и так. В свое время (к концу века MS-DOS) были ограничения на объем
(адресного пространства) жесткого диска, помните, как вставалось на уши для
его обхода. Некоторые следы этого и сейчас есть (не все ОС умеют грузиться
не из первого раздела). Недавно снова встала подобная проблема - долго казалось,
что 32битных слов хватит для адресации на дисках (это всего 4Гб), ан нет, теперь
нужно 64 бита. Надолго ли хватит ? Подобные казусы случались и с оперативной
памятью. И с IP-адресами. И еще будут случаться.

Однако зачем же оставаться в рамках одной плоскости диск-ПО-процессор.
А если надо подключить не просто "более быстрый", а другой процессор?
Нейропроцессор, квантовый (если сделают когда-нибудь), криптоаналитический,
да хрен знает еще какой... Обмены по стандартным протоколам (типа TCP/IP) -
это сразу потеря эффективности, к тому же эти протоколы не учитывают специфическую
функциональность другого процессора, и ее придется учитывать где-то еще
(в прикладной программе?). Так что правильнее какой-то другой путь. Например,
прозрачный функционально-ориентированный API, за которым скрыты все подробности
коммуникаций и управления. Дык этот компонент тоже будет делать какой-то
программист, и если Вы получите доступ к новым функциям в привычной форме,
то это удобство для Вас... но вовсе не характеристика всего мира программирования.

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

Если говорить про адаптеры Ethernet, Token-Ring и иже с ними,
то... ммм... в каком-то смысле - да. В общемировом.
У производителей не принято драть друг у друга программные интерфейсы.
Это как-то связано с конкурентной борьбой. Опять же, засудить могут
за использование чужой интеллектуальной собственности. Так что это
не чья-то глупость, а объективное несовершенство мира на данном этапе
его развития.

Что касается карт, с которыми я сталкивался,
то - да, они пакетики по-другому передают,
и то, что годится для Ethernet, не подходит здесь.
Есть многое, Горацио, на свете...

За пять минут вы нос высморкать не успеете.

Я за базар отвечаю.
Не только высморкаться, но и форму нарисовать.
Другое дело - поведение, функциональность... но это уж от задачи зависит.
Бывают такие, что можно и в те же 5 минут уложиться :)

"В свое время (к концу века MS-DOS) были ограничения на объем
(адресного пространства) жесткого диска"
Причина этих ограничений: железячники не умеют проектировать протоколы.
Причём этот EPIC FAIL ничем их не научил, и они потом его раза три повторили на бис.

"А если надо подключить не просто "более быстрый", а другой процессор?"
А зачем мне другой процессор, когда мне и нынешнего много?
Серьезно, ну нет таких новинок: x86 как была x86, так и осталась; а драйверы почему-то и меняются и меняются и меняются.

"У производителей не принято драть друг у друга программные интерфейсы."
Их надо заставить, конечно же, придерживаться одного интерфейса.
А то они уже зае

"Не только высморкаться, но и форму нарисовать."
Не-не.
Я вполне уверен, что единица измерения времени в программировании - полдня.
Исходя из того, что в любой (новой особенно по сравнению с предыдущим днём) деятельности всегда может открыться Засада, которая как раз полдня и потребует.

> Причина этих ограничений: железячники не умеют проектировать протоколы.

Железячники умеют проектировать протоколы. Например, Ethernet. До сих пор работает.

Причина этих ограничений, в том, что любой проводник на плате, на шинном
разъеме - это маленькая доля в себестоимости устройства. И закладываться
на 32-битные и 64-битные адреса, когда больше 1 Мб RAM "в обозримой перспективе
не просматривается" как-то невыгодно. Конечно, надо заглядывать вперед,
но прогресс идет такими зигзагами темпами, что любые оценки
необходимой величины адресного пространства - это волюнтаризм, более-менее
подкрепленный правдоподобными рассуждениями.

При переходе с TCP/IP ver. 4 на TCP/IP ver. 6 длина IP-адреса увеличивается
с 32 до 128 бит. Кажется, что теперь навсегда хватит... Интересно, долго ли
продержится эта иллюзия ? С другой стороны, если мы даже понимаем, что это -
иллюзия, где все-таки остановиться ? На 256 ? На 1024 ? ...

> А зачем мне другой процессор, когда мне и нынешнего много?

Вам, возможно.
Но Вы не один на планете.
Некоторым не хватает.

Собственно, Вы подтверждаете мои подозрения,
из-за которых я и начал задавать эти вопросы (см. выше).

> Серьезно, ну нет таких новинок: x86 как была x86, так и осталась;

Думаю, Вы просто не в курсе.

Кроме того, x86 не такая уж и хорошая архитектура.
А держаться за нее не потому, что очень нравится,
а потому, что под нее много софта понаписано, и очень
дорого переделывать под другие процессоры. Т.е. софт,
а вовсе не отсутствие фантазии и таланта у разработчиков харда,
является фактором инерции в прогрессе хардвера.

Да и в рамках линейки x86 тоже происходили драматические изменения.
Из моей практики: в 90-х одна программа отлично работала на 286 и
отказывалась работать на 386. Конечно, это была "шибко хитрая" программа,
которая выжимала из процессора все, что только можно (нужно было очень быстро
произвести некоторые вычисления). Можно сказать, что она "работала с аппаратурой",
хотя никакая внешняя аппаратура не использовалась - зато ЦП использовался и в
хвост, и в гриву. Выяснилось, что у 386-го - упреждающая подкачка в кэш, и потому
некоторые обновления не достигают процессора. Разобраться было сложно, исправить -
просто. Это пример, когда от программы требуется некоторая "особая эффективность",
и этим он близок к случаям "работы с оборудованием". Возможно, Вам такие задачи
не попадались, или Вы инстинктивно их избегаете... Это, опять же Ваш выбор. А вот
мне такие задачи как раз нравятся, я, можно сказать, специалист по ним :)

Я не хочу сказать, что в "высокоуровневом" (в смысле - высоко приподнятом над
аппаратурой) программировании нет сложных и интересных задач. Есть, конечно,
и много. Я только не согласен с тем, что именно это "высокоуровневое"
программирование является неким основным, ударным направлением, а все остальное -
ерунда. На мой вкус, это несколько ограниченный взгляд :(

"Причина этих ограничений, в том, что любой проводник на плате, на шинном
разъеме - это маленькая доля в себестоимости устройства. И закладываться
на 32-битные и 64-битные адреса, когда больше 1 Мб RAM "в обозримой перспективе
не просматривается" как-то невыгодно."
Конечно! Давайте каждые два года добавлять один бит в ширину шины, а программисты пусть мучаются?
Вы понимаете, что это перекладывание с больной головы на здоровую?
Железячники экономят два цента, программисты переписывают тонну критического софта каждые два года, пользователи десять лет живут с крайне нестабильным ПО, которое всё время в процессе переписывания.

"При переходе с TCP/IP ver. 4 на TCP/IP ver. 6 длина IP-адреса увеличивается
с 32 до 128 бит. Кажется, что теперь навсегда хватит... Интересно, долго ли
продержится эта иллюзия ?"
Я слабо представляю, как кому-то может не хватить 128 бит.
Они что, каждому атому солнечной системы айпишник выдать хотят?
Сдуру, конечно, можно много чего сломать, растащив куски адреса на технические нужды.

Но вообще ipv6 - это навсегда.

64-битное адресное пространство, кстати, тоже. И это меня очень радует, не представляете, как. Никакого больше цирка.
Вот так все дырки заплатать, и не через что будет железу ломать и корявить код.

"Кроме того, x86 не такая уж и хорошая архитектура."
Да всем давно пофиг, честно говоря, главное, чтобы шустрая была.
JVM вообще по барабану, на чём свой байт-код исполнять; с другой стороны, больше высокоскоростных процессоров общего назначения, вроде, архитектур нет.
PPC как-то подсдохла, хотя она получше.

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

Понимаете, есть фиксированные точки: в процессе разработки софта все точки, кроме одной, должны быть зафиксированы.

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

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

Так вот, в треугольнике железо - ОС - софт железячники нагло, безосновательно совершенно прихватизировали изменения. Просто по факту.
Поэтому ОС вынуждена не меняться ни в коем случае - если она будет меняться с одновременным изменением железа, качество работы всего этого комплекса так улетит, что не поймаешь уже.
То есть вы своими протокольчиками и драйверками каждой из сотни идентичных Ethernet-карт нам всю картину портите и радуетесь.

> Они что, каждому атому солнечной системы айпишник выдать хотят?

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

> Сдуру, конечно, можно много чего сломать, растащив куски адреса на технические
> нужды.

Это, несомненно, будет сделано,
"и делается уже" (c) :)

> Но вообще ipv6 - это навсегда.

Вы просто повторяете Била Гейтса,
который в 198Х-м году сказал,
что 1 Мб оперативки хватит навсегда.

Знаем мы цену таким прогнозам.

> 64-битное адресное пространство, кстати, тоже.

Кстати, тоже

> Так выпьем же за инерцию в прогрессе хардвера!

Да, давайте все будем работать на первом пне...

Хотя, мне лично всегда больше нравилось 486DX :)
Одна только фигня с ней - не успевала подхватывать
прерывания от карты 100Мб Ethernet. Впрочем, рост
скоростей передачи данных тоже можно законодательно
заморозить.

Да, двух- и более-ядерные процессоры надо немедленно отменить!
Или, по крайней мере, запретить ОС их замечать...

> Так вот, в треугольнике железо - ОС - софт железячники нагло, безосновательно совершенно прихватизировали изменения.

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

Вообще, тут смешаны две совершенно разные проблемы:
1) усовершенствования в хардвере (которые хоть и напрягают, но их игнорирование
приводит к гарантированному отставанию).
2) зоопарк устройств, связанный с множеством конкурирующих производителей.

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

Конечно, я мог бы мечтать вместе с Вами, что "все будет хорошо",
но я знаю, что не будет и знаю, почему, так что что уж тут...

Почему. Двухядерные процессоры - это SMP, это штука достаточно старая и стабильная, чтобы не иметь против нее ничего.

"Нет, всего-навсего каждой кофеварке, холодильнику, проигрывателю и мобильному телефону."

2^128 - это вообще-то 3.4^38.
Я понимаю, конечно, потребительская революция в китае, но нет у нас столько кофеварок.

"Мне кажется, все находится в развитии, и быстрее всего все-таки прикладной софт."
Прикладной софт не общается с железом! А когда общается, то это у него получается плохо.
А вот ОС вынуждена стоять на месте, пока железо ползает и копошится.

Вот это-то и ужасно!

# Я отчетливо помню время, когда SMP было новым и нестабильным.
А на подходе многоядерные (n > 2), так что форс-мажор еще впереди.
И ваще, надо немного больше смотреть назад и вперед.

# Возможно, в кофеварке понадобится не один ip-ник :)

# ОС не так уж и стоят на месте.
Например, Linux довольно ловко подхватила 64-битные архитектуры.
Да и в самой ОС какие-то подвижки постоянно происходят,
а если и медленно - у меня нет ощущения, что это из-за
аппаратуры, скорее причина - внутренняя. То же могу сказать
про FreeBSD. Впрочем, я не варился внутри этих проектов,
сужу только по внешним признакам.

А в чём форс-мажор от многоядерности?

Вот у меня сейчас два. Приятно: можно собирать -j3, флеш-плагин, когда тупит, отъедает всего одно ядро. Минусов не заметил :)

а если их будет 4 ?
софт новых просто не заметит.
а переделанный софт (в данном случае - ОС) -
это, как всегда, новые ошибки :)

"софт новых просто не заметит."
?? Какой софт?

У меня сейчас на машине запущен сто пятьдесят один процесс.
Они отлично смогут поочередно скакать на всех четырёх ядрах. Пока флешка терзает одно ядро, остальные ядра продолжают отрисовывать браузер, X11ить X11 и качать торрент.

Ну и да, make -j5 давно уже.

отлично!
но ведь в какой-то недавний момент это было проблемой :)

какой софт ? планировщих ОС за это отвечает, вроде-бы

кстати, что такое make -j5 и причем оно тут ?

Планировщик моей ОС умеет многопроцессорность лет на десять дольше, чем мне это понадобилось.
Твоей - тоже, кстати.

-j [jobs], --jobs[=jobs]
Specifies the number of jobs (commands) to run simul‐
taneously. If there is more than one -j option, the
last one is effective. If the -j option is given
without an argument, make will not limit the number of
jobs that can run simultaneously.

Распараллеливание компиляции, работает сто лет.

Простите, коллега, но это к SMP не имеет никакого отношения
и появилось значительно раньше.

jobs запускаются как отдельные процессы.
мотивация: использование ресурсов процессора,
пока другой процесс ожидает завершения ввода-вывода
(при компиляции и сборке ведь много ввода-вывода)

Конечно, как разные процессы!

Я ж тебе говорю. У меня на машине сейчас 124 процесса запущены, вот они-то и будут параллельно работать на этих четырёх ядрах.

Вопросы? Предложения?

они будут работать на 4х ядрах, если планировщик ОС
умеет размещать процессы на 4х ядрах. а умеет ?
и давно ли ?

Умеет. Лет 15 как.
make -j3 работает тоже лет 20, как.

> Умеет. Лет 15 как.

Какая именно ОС ?

> make -j3 работает тоже лет 20, как.

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

"Какая именно ОС?"
Linux?

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

Сначала восклицаешь:
jobs запускаются как отдельные процессы.
Потом спрашиваешь:
если планировщик ОС умеет размещать процессы на 4х ядрах. а умеет ?

Сам же себе ответил.

>> Умеет. Лет 15 как.
>"Какая именно ОС?"
>Linux?

Хм... ты прав. Linux - c 1996, WinNT - c 1993.
Не думал, что так давно.

> Выяснили мы, что ты путаешься в трёх соснах.

Вовсе нет.
Псевдопараллельные процессы имеют смысл и на 1 процессоре.
Читай меня внимательней :)

Имеют :) Но вот.

Даже с x86 не все так гладко.

x86-64 is a superset of the x86 instruction set architecture.
(отсюда: http://en.wikipedia.org/wiki/X86-64 )
т.е. чтобы воспользоваться этими возможностями, надо что-то поправить
в консерватории

софтвере.

А тем временем Intel сделал попытку уйти от х86 ( http://en.wikipedia.org/wiki/IA-64 ),
но массовый рынок игрушку не принял. Зато в высокопроизводительных вычислениях она
вроде-бы на месте.

> Да всем давно пофиг, честно говоря, главное, чтобы шустрая была.

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

IA-64 не интересна.
В первую очередь потому, что под нее очень сложно писать виртуальные машины/JIT.

Ну и в принципе - оно медленное и при этом сложное. За такие-то деньги!

А x86-64 на сервере - уже реальность, на клиенте всё равно, что происходит, там вообще только браузер нужен.

> Их надо заставить, конечно же, придерживаться одного интерфейса.

Знаете способ ?

Мне как-то ближе крещения огнём и мячом, "умрём за единый аз" и прочий сталинизм.

Как спрашивал один варвар у Пратчетта, "так, кто ещё скорее умрет, чем предаст императора?"

я бы сказал, это несколько старомодно.
в смысле: сейчас (у них) другое общество и в нем другие стимулы
для деятельности и другие способы разрешения конфликтов
(есть ведь конфликт, да ?).

а в сталинско-имперско-феодальном обществе, - есть такое предположение, -
не могли бы развиваться информатика и ВТ в современном понимании.

С одной стороны, ты прав.
С другой стороны, а что делать, если они такие кинестетики?

смиряться...
(или воздействовать на чувства ? физически :)))) )

если только это правда (про кинестетиков).
насколько я понимаю, в пресвитерианстве успех в бизнесе
рассматривается как подтверждение благочестия и даже
богоизбранности. так что не все так просто :)

> "Что за задачи, предположить сложно, но зато понятна среда - это"
> Машина Тюринга.
> Вы поймите, всё это железо, это суета сует.

Вы помните "теорему Донды" ?

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

:)

Бесконечно большая программа работает без оборудования вообще. Это наша вселенная.
Причём мне кажется, что она конечного размера, кроме того - достаточно кратка.

А у меня есть другая теория. Если в программе что-то поменять для ее ускорения, что-нибудь сломается; соответственно, можно ускорить программу в бесконечное количество раз, сломав в ней всё.

и это тоже правда.

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

короче,
не трогай, пусть работает! (с)