Safari for Windows -- это не только ещё один браузер для Windows, но и первый настоящий опыт Apple по портированию своих библиотек на эту платформу. iTunes такой масштабной разработкой, к примеру, не является, достаточно зайти в настройки iTunes и в настройки Safari, чтобы увидеть разницу.
Why Did Apple Port its Core OS X Libraries to Windows?
Porting Safari to Windows using .Net would have certainly resulted in a more Windows-like browser. That provides more evidence to suggest that Apple wasn’t simply interested in putting its browser on Windows to grab Google revenue or displace Firefox. It appears that Apple ported these extra libraries to do two other things:
First, delivering Core Graphics and Core Foundation on Windows enabled Apple to deliver a more Mac-like browser experience. Safari on Windows quite purposely feels like a Mac. If Apple wanted to deliver a browser that felt like Windows, it could have saved a lot of effort or even contracted it out to an external developer.
This brands Safari with a Mac-like feel, exposes Windows users to Apple’s own user interface conventions, and shows off the capacity of Core Graphic’s features, including translucent sheets and built-in color management.
Second, delivering Core Graphics and Core Foundation on Windows provides Apple with the option of later expanding Xcode to enable developers on the Mac to deliver their own Cocoa applications cross-platform on Windows.
Cuckoo for Windows Cocoa.
Having the essential frameworks of Cocoa embedded within Safari for Windows strongly suggests that Apple not only wanted a Mac-like browser, but may also soon offer Xcode developers a tested and refined mechanism for building and delivering their own apps on Windows, too.
Of course, the testing and refining of this mechanism is necessary, and that appears to be in part what Safari on Windows will be doing for Apple.
While the company is unlikely to port the rest of its own apps to Windows, offering a cross-platform build option to third party developers will make Cocoa an even more compelling alternative to Microsoft’s .Net, with the extra free feature of being supported on the Mac platform, and perhaps even the iPhone.
Нет никаких сомнений в том, что Apple откроет SDK для разработки Cocoa приложений под Windows. Это лишь вопрос времени.
Таким образом, когда это случится, на один кроссплатформенный движок в этом мире станет больше. Причём, даже в пределах Windows Cocoa может соревноваться с .NET GUI.
I have experience with both Objective-C/OpenStep and C#/.NET. I've built applications with both (as well as Python/PyQT, C++/Delphi, C++/QT, and various and sundry UNIX command line applications in C and C++ with STL).
I think most of the comments here miss the point. This isn't about Java vs. C#. It's about Cocoa vs. .NET (and perhaps slightly less about C# vs. Objective-C). Now that I've developed with C# and .NET, I can seriously say that I much prefer Cocoa.
It seems to be much more consistent to me. For instance, a .NET text box control has a BackColor property. So does a combobox. Great, fine. But why doesn't a date time picker (which looks to be a textbox with a special dropdown chooser) have this property? There's no good reason. Cocoa seems to me to have a much more consistent and unified design approach.
Second, the static compile-time approach of C# ensures that I cannot assume certain facts that I already know about my program at runtime. To someone who has developed with Python, Objective-C, or Smalltalk, such an approach is tiring and tedious. Yes, if you're writing system software static typing and early binding make a lot of sense. Not so for application software. And the lack of Categories from Objective-C really annoys me. It's extremely useful at times.
The Windows Forms designer generates code instead of an XML description or serialized objects. Yuck. It's extremely brittle and I have encountered incomprehensible problems when the designer decided to change something in the code and fooled itself into a corner, making it impossible to get back into design mode for no good reason.
Finally, the .NET design approach seems awfully "heavy". Cocoa has more of a "just do it" feel. .NET wants you to run through an obstacle course of inter-related structural behemoths. It just feels like mountains upon mountains of architecture that isn't necessary.
Sadly, I have a feeling that Cocoa (and Objective-C) will die in the marketplace because it doesn't fit the preconceived notions that most developers have about how programming languages and development work. Which is a shame, because once you get into it, it's much more comfortable to work in.
.Net vs Cocoa for Developers.
Despite being an expert in .Net but brand new to the Cocoa platform, Hoffman said the time to complete his project was much faster on Cocoa. The same project took only one third the time, despite his having far more experience with Vista's .Net frameworks than Apple's Cocoa. He also noted:
The user experience developed was better by default on Mac OS X. As a programmer and “not a designer,” Hoffman says he approached user interface development with some trepidation, needing to seek out help from professional designers on the Vista end.
Under Cocoa however, Hoffman says he found Apple's visual development tools very accessible, while Microsoft's visual interface builder tool in Visual Studio was “so poor I turned it off.”
A specific example related to Cocoa's Core Animation, which allows developers to create rich, animated interfaces with very little code. Vista offers tools to accomplish similar feats, but requires developers to explicitly build every step of their animations using far more code, even to do simple things like fade out a view on a transition.
Another example was the developer support for giving users undo and redo features. Hoffman said .Net's INotifyPropertyChanges “is not enough,” requiring pre and post-change notifications to implement undo and redo. It's “not pretty,” he says, particularly in comparison to the Cocoa framework, which offers undo and redo functionality to developers “or free,” using zero code, with NSUndoManager.
Also noted was a comparison between Apple and Microsoft's desktop data stores. Core Data in Cocoa, introduced with Mac OS X Tiger, offers developers rich, flexible options for storing an application's data using XML, binary files, or an SQLite desktop database.
Isolated storage in an object relational system won't be offered for .Net until later this year, forcing developers to use XML flat files, or jump up to full blown SQL Express work, a large burden to put upon desktop application developers.
PPPPPS 20 minutes later: The more I run Safari on Vista, the faster it launches. Am I hallucinating? Is there a cosmic force that means just when I complain about Safari taking 57 seconds to launch, as soon as that complaint is made public, it launches much more quickly? Am I going insane? Or is someone playing a clever prank on me? It's this kind of epistemological, reality-shifting shit that makes me not want to blog any more. We are at war with Eastasia. We were always at war with Eastasia. 2+2=5, and I love Steve Jobs.
Это не первые и не последние программисты и пользователи, которые предпочтут Cocoa. Очень хитрый ход со стороны Apple. Некогда OS/2 испытала потерю родных приложений, потому что хорошо поддерживала Windows. На этот раз синдром OS/2 используется против Windows. Не знаю, как для вас, а для меня искушение перейти на Cocoa очень велико.
1. Как вы относитесь к интерфейсу Safari for Windows с точки зрения Windows пользователя? Сейчас это только Safari, но будут и другие программы, и не только Apple. Нравится ли вам факт, что таких программ будет больше?
На Mac OS X, скажем, пользователи очень чутко реагируют, если интерфейс программы отличается от принятого в системе. Яблочникам вообще трудно угодить. Тот же Qt, который передаёт лук, но не передаёт фил, забракован, в том числе мною. На Windows такого стремления к унификации интерфейса я не замечал, пока был её постоянным пользователем. Иметь собственный, уникальный интерфейс в порядке вещей. Winamp не похож, mail.ru агент не похож, NOD32 не похож. Да и сам iTunes, сколько я им пользовался, воспринимался без всякого отторжения. Я сейчас сижу в Safari, и он тоже не вызывает отторжения, скорее даже наоборот. Но это потому что я последний год провёл в Mac OS X. Так что я могу судить только по своим ощущениям ДО того, как я перешёл на Mac OS X. И, насколько, я себя помню, мне интерфейс iTunes нравился, даже было жалко, что на аудиоплеере всё и заканчивается. Так что, как ни крути, я двумя руками за.
2. А как программист? В приведённых цитатах высказано недвусмысленное предпочтение Cocoa.
Я пока что не прилагал руки ни к тому, ни к другому из-за приоритета кроссплатформенности. Но писать программы на движке, родном для моей OS, и бесплатно получать эту самую кроссплатформенность, соблазнительно.
3. И, наконец, как *NIX пользователь GNUStep?
Потому что в не-Windows/Mac OS X среде, если делать такие версии, придётся сделать откат на GNUStep. Я-то могу поставить что-нибудь из GNUStep. Собственно, у меня все три основных OS всегда под рукой. Проблема в том, что у меня нет чувства "духа" именно графических оболочек Linux. Я не знаю, как выглядят GNUStep приложения в глазах постоянных пользователей никсовых систем. Я могу только предположить, что для Linux пользователя к разношёрстности не привыкать. Были, есть и будут GTK+ и Qt программы. И, хотя лук можно подогнать, фил будет отличаться. Но как относиться к GNUStep, я не знаю. К популярным движкам GNUStep не относится. Но и забытым его не назовёшь (см. Etoile).
Здравствуйте, OCTAGRAM, Вы писали:
OCT>1. Как вы относитесь к интерфейсу Safari for Windows с точки зрения Windows пользователя? Сейчас это только Safari, но будут и другие программы, и не только Apple. Нравится ли вам факт, что таких программ будет больше?
Жуть уродская, а не интерфейс. Начиная от рендеринга шрифтов, и заканчивая поведением.
iTunes тоже мне лично не нравится, хотя не из-за интерфейса — просто он большой, жрет память и тормозит.
OCT>2. А как программист? В приведённых цитатах высказано недвусмысленное предпочтение Cocoa. OCT>Я пока что не прилагал руки ни к тому, ни к другому из-за приоритета кроссплатформенности. Но писать программы на движке, родном для моей OS, и бесплатно получать эту самую кроссплатформенность, соблазнительно.
Я лично Cocoa трогать не буду, пока она не будет зарелизена в исходниках под LGPL/BSD-лицензией для Windows и Linux (пофиг на Мак).
Если уж зависеть от проприетарной системы — выберу уж лучше Microsoft. На них, по крайней мере, можно надеяться, что они никуда в ближайшее время не исчезнут — а Apple как раз может вдруг решить, что им надоело поддерживать пользователей Windows.
OCT>3. И, наконец, как *NIX пользователь GNUStep?
В морг, минуя реанимацию. Авторам GNUStep видимо медведь наступил на эстетическое чувство. Ну и еще какое-то у них навязчивое желание все время сделать свой desktop environment, который нафиг никому кроме самих авторов не нужен.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>1. Как вы относитесь к интерфейсу Safari for Windows с точки зрения Windows пользователя?
Не хватает кнопки "Новая вкладка", как это сделано в SeaMonkey.
OCT> Сейчас это только Safari, но будут и другие программы, и не только Apple. Нравится ли вам факт, что таких программ будет больше? OCT>На Mac OS X, скажем, пользователи очень чутко реагируют, если интерфейс программы отличается от принятого в системе. Яблочникам вообще трудно угодить. Тот же Qt, который передаёт лук, но не передаёт фил, забракован, в том числе мною. На Windows такого стремления к унификации интерфейса я не замечал, пока был её постоянным пользователем. Иметь собственный, уникальный интерфейс в порядке вещей. Winamp не похож, mail.ru агент не похож, NOD32 не похож. Да и сам iTunes, сколько я им пользовался, воспринимался без всякого отторжения. Я сейчас сижу в Safari, и он тоже не вызывает отторжения, скорее даже наоборот. Но это потому что я последний год провёл в Mac OS X. Так что я могу судить только по своим ощущениям ДО того, как я перешёл на Mac OS X. И, насколько, я себя помню, мне интерфейс iTunes нравился, даже было жалко, что на аудиоплеере всё и заканчивается. Так что, как ни крути, я двумя руками за.
Лично мне не нравится цветовая схема интерфейса Safari. Она отвратительна и не сочетается с интерфейсом неродной ОС.
Кстати, SeaMonkey тоже имеет свою тему интерфейса: одну "топорную" под родную операционку, другую "Modern" — тоже ничего общего с интерфейсом графической оболочки ОС. Но приходится использовать SeaMonkey, так как он работает быстрее, чем Firefox, и отображает весь контент, в отличие от наполовину недогруженных картинок с сайта Тёмы Лебедева в Safari.
OCT>2. А как программист? В приведённых цитатах высказано недвусмысленное предпочтение Cocoa.
Как Java-программист не заметил особой разницы между работой Java-апплетов в Safari (Windows), SeaMonkey (Windows, FreeBSD) и Firefox (Windows, FreeBSD).
OCT>Я пока что не прилагал руки ни к тому, ни к другому из-за приоритета кроссплатформенности. Но писать программы на движке, родном для моей OS, и бесплатно получать эту самую кроссплатформенность, соблазнительно.
Это заманчивая мнимая кроссплатформенность нативных языков программирования...
OCT>3. И, наконец, как *NIX пользователь GNUStep? OCT>Потому что в не-Windows/Mac OS X среде, если делать такие версии, придётся сделать откат на GNUStep. Я-то могу поставить что-нибудь из GNUStep. Собственно, у меня все три основных OS всегда под рукой. Проблема в том, что у меня нет чувства "духа" именно графических оболочек Linux. Я не знаю, как выглядят GNUStep приложения в глазах постоянных пользователей никсовых систем. Я могу только предположить, что для Linux пользователя к разношёрстности не привыкать. Были, есть и будут GTK+ и Qt программы. И, хотя лук можно подогнать, фил будет отличаться. Но как относиться к GNUStep, я не знаю. К популярным движкам GNUStep не относится. Но и забытым его не назовёшь (см. Etoile).
Чё такое GNUStep? (В Wiki не отсылать — не пойду )
Firefоx и SeaMonkey в UNIX используют Gtk2. Opera использует Qt.
Мне нравится идея. Может, теперь эппл столкнется с массой непредвзятой критики по отношению к Obj-C и будет вынуждена вылечиться от своего убеждения, будто это совершенный язык.
OCT>1. Как вы относитесь к интерфейсу Safari for Windows с точки зрения Windows пользователя? Сейчас это только Safari, но будут и другие программы, и не только Apple. Нравится ли вам факт, что таких программ будет больше?
Их не станет больше. Заслуга приятности программ в Mac OS — в дизайнерах Эппл. Разработчики для Мак берут пример с программ от Apple, для Windows — с программ от Microsoft. Есть здравый смысл в системе в целом — и в приложениях будет. Если его недостаток — и в приложениях будет недостаток. Майкрософт сама для своих программ разноцветные скины выдумывает — и все разработчики под Windows туда же.
Я бы на их месте опасался, как бы благодаря портированной Cocoa всяческие дурные или просто другие традиции с Windows не перекочевали на мак, отчего он быстро потеряет свой шарм.
OCT>2. А как программист? В приведённых цитатах высказано недвусмысленное предпочтение Cocoa.
Язык — уже точно отвратит. Пара серъезных достоинств его не спасёт. Представьте динамический язык без привычных приятностей типа функций высшего порядка, туплов, синтаксиса для словарей, паттерр матчинга, сборки мусора в конце концов (!). А просто такой же тупой и прямолинейный, как допустим, Паскаль. Управление памятью — reference counting. Любители экзотики могут включить консервативный GC (как для чистого C сделаны). Нравится?
В эппл есть ярые фанатики этого языка (а-ля СГ с Обероном). В стиле «если вам не нравится синтаксис Obj-C — вы тупой». Пусть вас не вводят в заблуждение письмена насчет того, как старый-престарый Obj-C более крут, чем самая новая версия C#. Не крут он.
И как программист, смотреть надо на язык, т.к. работать вы будете с ним, а Cocoa — просто библиотека с хорошей архитектурой и тулсами.
OCT>3. И, наконец, как *NIX пользователь GNUStep?
А им вообще хоть кто-нибудь пользуется?
Резюме: Эпплом рулят дизайнеры, умеющие программировать. Им определенно есть что предложить простым пользователям, но для разработчиков у них пока нет ничего, что стало бы айподом среди средств разработки Cocoa просто хороша, но не гениальна и не революционна. Без существенной доработки вряд ли подойдет для создания нативного интерфейса. Objective C, который единственный хорошо подходит для программирования на ней — примитивен и местами плох.
Здравствуйте, Кодёнок, Вы писали:
OCT>>2. А как программист? В приведённых цитатах высказано недвусмысленное предпочтение Cocoa.
Кё>Язык — уже точно отвратит. Пара серъезных достоинств его не спасёт. Представьте динамический язык без привычных приятностей типа функций высшего порядка, туплов, синтаксиса для словарей, паттерр матчинга, сборки мусора в конце концов (!). А просто такой же тупой и прямолинейный, как допустим, Паскаль. Управление памятью — reference counting. Любители экзотики могут включить консервативный GC (как для чистого C сделаны). Нравится?
Кё>В эппл есть ярые фанатики этого языка (а-ля СГ с Обероном). В стиле «если вам не нравится синтаксис Obj-C — вы тупой». Пусть вас не вводят в заблуждение письмена насчет того, как старый-престарый Obj-C более крут, чем самая новая версия C#. Не крут он.
Не крут. И C# не крут. Но Обж-С -- консистентен в отличие от. Через это на нём уже приятнее работать.
Кё>И как программист, смотреть надо на язык, т.к. работать вы будете с ним, а Cocoa — просто библиотека с хорошей архитектурой и тулсами.
Это да. Назовите еще одну. С архитектурой и тулсами.
Кё>Резюме: Эпплом рулят дизайнеры, умеющие программировать. Им определенно есть что предложить простым пользователям, но для разработчиков у них пока нет ничего, что стало бы айподом среди средств разработки Cocoa просто хороша, но не гениальна и не революционна. Без существенной доработки вряд ли подойдет для создания нативного интерфейса. Objective C, который единственный хорошо подходит для программирования на ней — примитивен и местами плох.
Хорошесть Cocoa проявляется во время работы на ней. Ну, тут дальше о вкусе устриц
Лично для меня Objective C стоит сразу после C# по приятности.
Но с Cocoa приложениями под Windows есть трудности:
— ObjectiveC хорошо интегрируется с C. С С++, насколько я помню, уже не очень. Соответственно, интеграция с виндовыми приложениями (ну там с Excel сделать RTD, COM какой-нибудь заюзать или такой интерфейс выдать) — уже сложности, которых нет ни в MFC ни в .NET
— Предыдущая их версия этого дела (WebObjects) была полным отстоем. Тут вроде все сильно лучше выглядит, но одно дело свои собственные два приложения спортить, другое — сделать framework для других. Тут и проблемы у людей совсем другие полезут etc. Среда разработки их нативная (XCode) два года назад была полным дерьмом по сравнению с Visual Studio. Ну, билды параллелить умела — это да. Я вообще не верю в способность Apple сделать что-то уровня Microsoft не для consumer сегмента. Xcode, Bonjour — это выглядит очень странно. Хорошие идеи, недоведенность до enterprise-продукта. Конечно, все ресурсы нужно бросать туда где лучше всего получается — в consumer-сегмент.
— Reference counting там гораздо проще чем в COM из-за наличия autorelease pool. С ним вообще в реальности ни у кого проблем не возникало.
Плюсы для сторонних разработчиков есть только в том что можно портировать приложения, написанные под MacOS. Вот в прошлой жизни именно такая ситуация была. Или для тех кто хочет делать консумерские приложения И под Мак. Но тут нужно понимать что там очень важен user experience (там это есть везде) и уже продавать такой остой, который можно продавать в виндовом мире гораздо сложнее
Скорее всего Apple уже видит что скоро исчерпает сегмент, забытый Microsoft и чтобы развиваться надо будет что-то делать и под Windows. Тот же Aperture.
Кодёнок пишет: > Здравствуйте, OCTAGRAM, Вы писали: > > Мне нравится идея. Может, теперь эппл столкнется с массой непредвзятой > критики по отношению к Obj-C и будет вынуждена вылечиться от своего > убеждения, будто это совершенный язык.
Я думаю, там не дураки сидят, которые верят в то, что другим говорят.
Мне они представляются людьми прагматичными и хитрыми. Если иметь с ними
дело, то надо тоже быть хитрыми и прагматичными. Либу мы возьмём, а на
Obj-C писать не будем. Ибо нефиг.
> Представьте динамический язык без привычных приятностей типа функций > высшего порядка
нуу... множество простых смертных живут и не отвращаются
> туплов
а это принципиально?
> синтаксиса для словарей
в Obj-C 1.0 специального синтаксиса не было, в 2.0 не знаю, не смотрел.
> паттерр матчинга,
аналогично
> сборки мусора в конце концов (!).
в 2.0 есть
> Пусть вас не вводят в > заблуждение письмена насчет того, как старый-престарый Obj-C более крут, > чем самая новая версия C#. Не крут он.
Меня, допустим, не вводят. Мне новость запостить надо было. Да и языки я
рассматриваю не с точки зрения крутости, а с точки зрения решений,
сделанных на этапе проектирования. Скажем, объектная модель в Obj-C мне
нравится, если сравнивать её с COM или XPCOM, скажем. В COM нельзя так
просто отнаследовать класс от другого COM класса.
All problems in computer science can be solved by another level of
indirection, и indirection, присутствующий в Obj-C, по своему ценен. Но
писать на чистом Obj-C я бы не стал, потому что ненавижу сегфолты и
прокисания памяти, а сишная природа Obj-C к этому располагает.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Я думаю, там не дураки сидят, которые верят в то, что другим говорят. OCT>Мне они представляются людьми прагматичными и хитрыми. Если иметь с ними OCT>дело, то надо тоже быть хитрыми и прагматичными. Либу мы возьмём, а на OCT>Obj-C писать не будем. Ибо нефиг.
С ней больше не на чем писать. У нее специфика имен методов как в SmallTalk — подойдет только немного языков. Писать для Cocoa на Java/Python/C еще неудобней.
>> сборки мусора в конце концов (!). OCT>в 2.0 есть
Да, обычный консервативный GC для C. Причем нельзя взять исходник, работающий с подсчетом ссылок, и включить в проект с GC — у меня почти всегда следуют креши, которые приходится исправлять.
>> Пусть вас не вводят в >> заблуждение письмена насчет того, как старый-престарый Obj-C более крут, >> чем самая новая версия C#. Не крут он. OCT>Меня, допустим, не вводят. Мне новость запостить надо было. Да и языки я OCT>рассматриваю не с точки зрения крутости, а с точки зрения решений, OCT>сделанных на этапе проектирования. Скажем, объектная модель в Obj-C мне OCT>нравится, если сравнивать её с COM или XPCOM, скажем. В COM нельзя так OCT>просто отнаследовать класс от другого COM класса.
Тут я полностью согласен. Он не только удобнее чем COM, он прозрачно интегрируется с Си и скриптовыми языками (не считая проблемы имен методов — для неё в скриптовый язык надо спец. поддержку добавлять).
Кодёнок пишет: >> > сборки мусора в конце концов (!). > OCT>в 2.0 есть > > Да, обычный консервативный GC для C.
Нет, не обычный. И не для обычного C. Он даже включается через -fobjc-gc > Причем нельзя взять исходник, > работающий с подсчетом ссылок, и включить в проект с GC
Следуя тому, что на сайте Apple написано, если в процессе включён
objc-gc, то методы для работы со счётчиком ссылок не оказывают никакого
эффекта.
OCTAGRAM пишет: > Кодёнок пишет: >> > > сборки мусора в конце концов (!). >> OCT>в 2.0 есть >> >> Да, обычный консервативный GC для C. > Нет, не обычный. И не для обычного C. Он даже включается через -fobjc-gc
Посмотрел ещё. Значит, там всё–таки boehm. Но всё равно это на более
высоком уровне, нежели в чистом C/C++ сделано. Скажем, есть __weak и
__strong
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Следуя тому, что на сайте Apple написано, если в процессе включён OCT>objc-gc, то методы для работы со счётчиком ссылок не оказывают никакого OCT>эффекта.
На практике оказалось не так все просто. Включение GC имеет неожиданные эффекты, у меня всегда случается доступ к удаленному объекту или что-то в этом роде.
Вообще, современная тенденция верить, что достаточно иметь GC и о проблемах с памятью можно забыть — просто наивна. В Obj-C довольно тупо встроен довольно тупой GC. Правда я и не пытался с ним подружиться — просто игрался.
Cyberax пишет:
> iTunes тоже мне лично не нравится, хотя не из-за интерфейса — просто он
> большой, жрет память
Глянул, всего 37 Mb, в медиатеке 21Гб. Нормально. Не экономить же на музыке. > и тормозит.
у кого как
> а Apple как раз может вдруг решить, что им надоело > поддерживать пользователей Windows.
Ах да, они же из чистого альтруизма этим занимаются
> OCT>3. И, наконец, как *NIX пользователь GNUStep? > В морг, минуя реанимацию. Авторам GNUStep видимо медведь наступил на > эстетическое чувство.
А по скринам Etoile не сказать.
> Ну и еще какое-то у них навязчивое желание все > время сделать свой desktop environment, который нафиг никому кроме самих > авторов не нужен.
Ну–ну
Здравствуйте, OCTAGRAM, Вы писали:
>> большой, жрет память OCT>Глянул, всего 37 Mb, в медиатеке 21Гб. Нормально. Не экономить же на музыке.
Appolo — сам занимает 5Mb. Плюс настраиваемый буффер ещё на 5Mb.
>> и тормозит. OCT>у кого как
Тормозит, тормозит.
>> а Apple как раз может вдруг решить, что им надоело >> поддерживать пользователей Windows. OCT>Ах да, они же из чистого альтруизма этим занимаются
Именно в этом и проблема. Apple может решить, что им выгоднее заставлять пользователей покупать Mac'и.
>> OCT>3. И, наконец, как *NIX пользователь GNUStep? >> В морг, минуя реанимацию. Авторам GNUStep видимо медведь наступил на >> эстетическое чувство. OCT>А по скринам Etoile не сказать.
Жжжжжуть.
Сравни хотя бы с:
>> Ну и еще какое-то у них навязчивое желание все >> время сделать свой desktop environment, который нафиг никому кроме самих >> авторов не нужен. OCT>Ну–ну
Ну что я могу сделать, если так и есть.
)
