Маководам

с быдла в гламурного метра...?

Это толстый троллинг? Иди проспись.

> Поставил тут себе в ХР стиль Мака - очень нравится. Скажите, действительно ли удобна МакОС, или только красива?

Особой какой-то отличительной красоты в OS X не замечал, сейчас похожим образом каждая ось приукрашивается, а удобна -- да, после нее, любой другой интерфейс кажется поделкой сбежавших из псих-больницы. Маковский интерфейс рисовали и продумывали гуру GUI Design-а, в то время как виндовый -- рисовали те, кого в Apple на работу не взяли, а кеды -- так вообще, программисты, которые по определению не могут сдизайнить интерфейс, т.к. мозги у нас, кодеров, совершенно в другую сторону заточены.

> Особенно было бы интересно услышать мнения об XCode,

Среда как среда, в меру глючная. в 3.1 beta-ах очень обертка вокруг gdb глючит, так что часто приходится брать "шашку в руки", т.е. с консоли софт отлаживаемый в gdb запускать, а в целом -- вполне себе среднестатистическая IDE.

> ну и вообще, насколько хорошо мак подходит для программиста.

Это уже "кому что", кому-то нравится для RTOS расширения писать, кому-то интерфейсы, а кому-то для той-же OS X драйвера писать (IOKit кстати в Mac OS X-е -- хороший пример для подрожания, "как реализовать хороший интерфейс для драйверов в ядре").

// Mac кодер с > 3х летним стажем.

Ясно... То есть глюков так же, как и в Линуксе много? Просто и от мак-юзеров слышал, и просто по логике - стандартное железо, стандартный API - глюков должно быть куда меньше...

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

МакОСь - Ъ.

> Поставил тут себе в ХР стиль Мака

повесить, расстрелять и четвертовать

> Маковский интерфейс рисовали и продумывали...

man hig

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

>> Маковский интерфейс рисовали и продумывали...

> man hig

Вот как раз без этих гуру, которые "рисовали и продумывали" не было бы ни самого интерфейса, ни h. interface guideline-а, благодаря которому "простые смертные" могут делать тоже хороший интерфейс.

> IOKit кстати в Mac OS X-е -- хороший пример для подрожания, "как реализовать хороший интерфейс для драйверов в ядре"

Буэээ...

> Просто и от мак-юзеров слышал, и просто по логике - стандартное железо, стандартный API - глюков должно быть куда меньше...

С одной стороны -- верно, глюков, из-за не очень большого разнообразия железа, может и поменьше. Но! Apple таким ошадиными шагами скачет, когда ПО разрабатывает, что неизбежны глюки, зато "впереди планеты всей", все фичи той-же cфисты на 3-4 года раньше сделали (большая часть уже в Тигре была).

>> IOKit кстати в Mac OS X-е -- хороший пример для подрожания, "как реализовать хороший интерфейс для драйверов в ядре"

> Буэээ...

Буээ, буэээ, а где вы под linux-ом видели, что-бы драйвер выпущенный для ядра 2.0.x работал бы без перекомпиляции на 2.6.x? А с IOKit-ом подобное прокатывает, и между тем, он имеет весьма красивый стройный и стабильный дизайн, который весьма помогает при разработке драйверов.

В сами можете похвастатся тем, что писали что-то, посложнее hello world-а для ядра?

те. драйвер для MacOS-7 должен работать на MacOS-10.5 ?

> а где вы под linux-ом видели, что-бы драйвер выпущенный для ядра 2.0.x работал бы без перекомпиляции на 2.6.x?

Кстати говоря, у вас есть превью Snow Leopard-а? Так вот, если вы не в курсе, то там появились 64-битные драйвера. Вот веселуха-то будет с переходом.

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

Ага, поэтому hallo world получается на несколько сотен строк. Модель service/client слишком громоздка, да и вообще мне не понятно нафига использовать в ядре С++ (причем сильно порезанный). А про красоты интерфейса не надо -- в IOKit-е бывает что нужного функционала просто нет. Зато красиво, да! :D

> В сами можете похвастатся тем, что писали что-то, посложнее hello world-а для ядра?

О, мы уж и на личности перешли? :) Драйвера для макоси -- это часть моей работы.

А есть kde4 MAC style?

> Поставил тут себе в ХР стиль Мака - очень нравится. Скажите, действительно ли удобна МакОС, или только красива?

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

Интересно, винда с включёнными темами до сих пор, даже на современном железе тормозит?

> насколько хорошо мак подходит для программиста

Для такого программиста, как ты, мак отлично подходит. Но винда тебе всё же подходит лучше.

> Вот как раз без этих гуру, которые "рисовали и продумывали" не было бы ни самого интерфейса, ни h. interface guideline-а, благодаря которому "простые смертные" могут делать тоже хороший интерфейс.

Тут кому-что. Либо ты дизайнер, либо ты программист. Мне как-то более приятно пользоваться функциональными инструментами с HIG-ом, чем HIG-ом с кое-как притороченым сбоку функционалом. (это в общих чертах)

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

P.S. А HIG без них бы не было, да :)

А правда, что ,как утверждал quarck от 27.06.2008 10:46:01,
драйвер для MacOS-7 работает на MacOS-10.x без перекомпилляции ?

> Кстати говоря, у вас есть превью Snow Leopard-а? Так вот, если вы не в курсе, то там появились 64-битные драйвера. Вот веселуха-то будет с переходом.

Пока еще не было такой надобности. Конечно понятно, полным переходом на 64 бита, с дровами будет потуже, кстати говоря, с переходом на Intel, Apple под шумок в Intel версии IOKit-а тоже внесла ряд изменений, в частности касательно работы со SCSI стеком, и по мелочи, с DMA.

> Ага, поэтому hallo world получается на несколько сотен строк. Модель service/client слишком громоздка, да и вообще мне не понятно нафига использовать в ядре С++ (причем сильно порезанный). А про красоты интерфейса не надо -- в IOKit-е бывает что нужного функционала просто нет. Зато красиво, да! :D

Зато полиморфно. Например мне захотелось iSCSI на базе транспорта из RFC 1217 реализовать, -- пожалуйста, вышестоящий стек заведется сам, нужно реализовать только соответсвующие сервисы для транспортного уровня.

>> В сами можете похвастатся тем, что писали что-то, посложнее hello world-а для ядра?

> О, мы уж и на личности перешли? :) Драйвера для макоси -- это часть моей работы.

Ну тогда вам видимо следует поменять работу, если вам так не нравится IOKit :)

> А правда, что ,как утверждал quarck от 27.06.2008 10:46:01, > драйвер для MacOS-7 работает на MacOS-10.x без перекомпилляции

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

Если вас забанили везде, скопирую:

'The I/O Kit framework was originally introduced as part of Apple's Rhapsody operating system that later became Mac OS X, and shared no similarities with either Mac OS 9's device driver framework, or that of BSD.'

Утверждали:

Буээ, буэээ, а где вы под linux-ом видели, что-бы драйвер выпущенный для ядра 2.0.x работал бы без перекомпиляции на 2.6.x?

>>>А с IOKit-ом подобное прокатывает,

2.0->2.2->2.4->2.6 - четыре поколения ядра

Из чего следует, что драйвер для MacOS-10.x должен работать для MacOS,
которая на четыре поколения старше 10 - 10->9->8->7

Сам драйверов не писал, но могу оценить их работоспособность.

Таr из 9-ки хотябы можно заставить работать драйвер под 10.x

> Зато полиморфно. Например мне захотелось iSCSI на базе транспорта из RFC 1217 реализовать, -- пожалуйста, вышестоящий стек заведется сам, нужно реализовать только соответсвующие сервисы для транспортного уровня.

У меня другая специика. :) В частности меня добивает невозможность средствами IOKit забиндить тред на определенный процессор или залочить много памяти. Причем это ведь умышленные ограничения.

> 2.0->2.2->2.4->2.6 - четыре поколения ядра

10.0 -> 10.1 -> 10.2 -> 10.3 -> 10.4 -> 10.5 -- 5 поколейний OS X (изменения в ядре происходили весьма неплохие).

OS 9 сюда никаким раком не этносится, это совершенно другая операционка, все равно что требовать от Linux-а поддержки дров, хоть на source уровне, написанных для Unix SysVr4

ну, вы поняли, 6 поколейний OS X

>10.0 -> 10.1 -> 10.2 -> 10.3 -> 10.4 -> 10.5

понятно - это , наверное, как изменения ветки 2.6.x

> В частности меня добивает невозможность средствами IOKit забиндить тред на определенный процессор или залочить много памяти. Причем это ведь умышленные ограничения.

но это не архитектурные ограничения, а функциональные. Так-же на маке бонально нельзя прибить чужое окно, или перечислить открытые окна, не пользуясь глючным, и обычно задизейбленным, Accessibility API, но это же не ограничения Cocoa архитектуры, это политика apple: никому ни**я, кроме чисто прикладного API. (Что актуально и для ядра, например с выходом 10.4 все BSD-ное API пошло под ножницы, осталось только очень узкая оебртка, предоставляющая NKE/VFS "разрешенный" интерфейс, куда более скудный, чем "полновесное BSD-ядерное API" из 10.3).

> понятно - это , наверное, как изменения ветки 2.6.x

гм, ну как вам сказать. XNU (ядро OS X и Darwin-а) от 10.0 и 10.1 было по функциональность весьма сравнимос 2.0: эксклюзивное исполнение ядреного кода: только 1 процессор мог выполнятся в режиме ядра, остальные ждали, если кто-то делал syscall, и прочие прелести. А нынешний XNU это весьма неплохо чуствующий сябя на кернел, избавившийся от всех глобальных/долгих локов, с кучей прочих улучшений в коде планировщика/управления памятьи/итп.

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

> насколько хорошо мак подходит для программиста.

Mono есть, переходи.