![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
История требований Виндовса к памяти от Гостомысла до наших дней. Наглядно примерно так:
Если дела пойдут в таком же духе и дальше, то к 2015-му виндовс будет требовать 20Г памяти минимум. Впрочем, никто не гарантирует, что дела пойдут так - так что может и 200 будет :)
Если дела пойдут в таком же духе и дальше, то к 2015-му виндовс будет требовать 20Г памяти минимум. Впрочем, никто не гарантирует, что дела пойдут так - так что может и 200 будет :)
Tags:
no subject
no subject
На этот счет есть разные мнения.
И Ваше представляется неверным.
no subject
Вы поддерживали на протяжении 10 лет программу для чтения офисных форматов, отслеживая их эволюцию?
Вы общались на профессиональные темы c ключевыми разрабочиками русской локализации?
Вы в конце концов читали утекшие в сеть исходники Windows?
То что Windows и офис при тех требованиях, которые выставляет маркетинговый департамент Microsoft, вообще удается выпускать и оно хоть как-то работает, это чудо, сравнимое даже не с тем что Аполлон-11 долетел до Луны, а с тем, что Аполлон-13 вернулся на Землю с живым экипажем.
no subject
no subject
no subject
no subject
Это, вообще говоря, деволюция.
Вы общались на профессиональные темы c ключевыми разрабочиками русской локализации?
Big Hairy Fucking Deal, русская локализация.
Если русская локализация представляет собой нетривиальную проблему, это само по себе диагноз.
На каком основании представляется?
Например, на основе неспособности сделать работоспособный OpenGL. В конспиративную теорию что OpenGL был специально загублен что бы дать дорогу DirectX, я тихо не верю.
Например, на основе монструозности OLE/COM.
Например, на основе халтурно сделанного интерфейса .NET/native code.
И т.д.
no subject
Разработка локализации предполагает доступ к репозиториям исходников, buld farm, внутреннему bug tracking, тесное взаимодействие с основными командами соответствующих продуктов. То есть руководителю команды локализаторов вся внутренняя кухня прекрасно видна.
Соответственно, когда потом этот человек ставит процесс разработки в команде, где участвую я, мне тоже более-менее понятно, какие именно вещи он вынес из работы на Microsoft.
А у кого он есть? У Silicon Graphics? Где та Silicon Graphics? Тут как-то человек, имеющий большой опыт работы с IRIX делился со мной впечатлениями о том, как оно внутри устроено. Вообще задача у Apple или SGI, которые ориентируются на узкий спектр железа, спецификации которого им по определению доступны, куда проще, чем у Microsoft, которым надо сделать общий framework, наполнить который конкретным содержанием смогут криворукие индусы, работающие на Nvidia или ATI. Тут засада в самой концепции, когда драйверы для closed source OS пишут производители оборудования, не имеющие доступа к исходникам этой ОС. В принципе, даже доступ к исходникам вообще говоря, не спасает. Нужен доступ к неформализованному знанию о концепциях, нужен опыт разработки ОС. Короче, драйвера должны писать разработчики ОС, а не разработчики железа. А железо - выпускаться с открытыми спецификациями. Но это не укладывается в бизнес-модель Microsoft.
А что, кто-то сделал десктопную компонентную архитектуру лучше? kparts и bonoboo не предлагать.
Ну, надо сказать что у .NET (как и у Java) задумка изначально кривая - сделать нормальный язык на котором сможет работать масса существующий enterprise-программистов. А интерфейс между managed кодом и nativе это вообще задачка ещё та. Я довольно неплохо знаю лучшие из имеющихся образцов - Tcl API и Perl/XS. Так там тоже все не слишком прямо. Это при том что у их разработчиков не стояла задача "чтобы с этим мог работать самый криворукий индус".
no subject
Бу-га-га! Bug tracking у них налажен!
Патцтолом!
А у кого он есть?
Вы заблуждаетесь. Поддерживать OpenGL не по меньшей мере не сложнее чем глючный и непродуманный интерфейс DirectX.
А что, кто-то сделал десктопную компонентную архитектуру лучше?
Что значит - лучше? С точки зрения дизайна, хуже чем OLE/COM, вообще ничего быть не может.
А интерфейс между managed кодом и nativе это вообще задачка ещё та.
Ничего сверхъестественнно сложного в это задаче нет. Ява, Питон и все другие языки так или иначе ее решают, и кривость интерфейса .NET/native code свидетельствует не о сложности этой задачи, а о неприличной некомпетентности инженеров Микрософта.
no subject
Ну приведите пример операционной системы со сравнимым с Windows HCL, в которой OpenGL поддерживается и работает. Нет такой системы (вообще говоря система GUI со сравнимым HCL есть ровно одна - X.org, и там с OpenGL не лучше).
Я ведь не утверждаю что Microsoft обладает инженерной культурой ДОСТАТОЧНОЙ для решения поставленных амбициозным менеджментом задач. Я утверждаю только, что она обладает САМОЙ высокой инженерной культурой во всей отрасли proprietary software (да и из OpenSource команд мало кто из крупных команд может потягаться).
И переплюнуть её в рамках данной бизнес-модели НЕВОЗМОЖНО.
Предъявить существующий пример софтверной фирмы сравнимых размеров с более высокой инженерной культурой Вы не сможете. Потому что его не существует. Вообще крупных софтверных фирм наперечет - Adobe да Oracle. Sun Microsystems - уже с натяжкой. ESRI и AutoDesk - это уже совсем другая весовая категория (и с культурой у них, прямо скажем, не лучше, несмотря на то, что при меньшем размере компании обеспечить высокую культуру проще).
Добиться инженерной культуры существенно выше, чем у MS могут только маленькие команды, вроде той команды, с которой Пол Грэм Yahoo Store делал.
no subject
Это вообще не важно, хотя все юниксовские рабочие станции конца 90-х годов поддерживали OpenGL без особых проблем.
Наверное, Вы не понимаете в чем тут дело: DirectX не сильно проще поддерживать чем OpenGL; просто уродство и глючность его интефейса лучше подходит для некомпетентных разработчиков и product manager'ов Микрософт. Всякий раз когда возникает проблема, они не думают о том как решить эту проблему в рамках существующей архитектуры, а вместо этого добавляют к системе очередное уродство.
Я утверждаю только, что она обладает САМОЙ высокой инженерной культурой во всей отрасли proprietary software
Это ни на чем не основанное утверждение представляется мне результатом психологической компенсации: раз уже мы вынуждены жить с горбом и бельмом на глазу, давайте думать что это и есть идеал красоты.
Вообще крупных софтверных фирм наперечет
А почему это вообще аргумент?
no subject
Как я уже писал выше - это была другая бизнес-модель - разработка ОС под конкретное железо. В рамках той бизнес-модели это было возможно реализовать. В рамках нынешнего рынка видеоакселераторов (хотя и чипов-то там в общем-то всего два) это не удалось никому. И не удастся, пока не изменятся правила игры на этом рынке. Хотя AMD в нужную сторону уже движется.
Я-то слава богу, с этим бельмом не живу и не жил никогда. Linux у меня на рабочей станции был и есть, BSDI была, Solaris был. А Windows последний раз была 3.1. Благо тогда это была не ОС, а что-то вроде прикладной программы-интегратора других приложений. У меня даже на наладоннике ни разу не WM. Хотя Windows Mobile много прямее десктопной Windows - там нет необходимости тащить такой груз совместимости, да и разрабатывалась система сразу под несколько процессоров.
Потому что окружающая среда в которой существуют инженеры в крупной фирме, и среда, в которой они существуют в средней или мелкой фирме - принципиально различается (средняя от мелкой, впрочем, тоже. Поэтому я недавно отказался идти в среднюю фирму). И в рамках крупной фирмы инженеры, сколь бы высококультурными они ни были, сделать ничего лучше Windows/Office не смогут никогда.
Тут бизнес-модели менять надо, а не инженерную культуру.
no subject
Нет принципиальной никакой разницы, поддерживать ли на разных адаптерах OpenGL или DirectX, и то и другое требует развитой системы драйверов, способных встраиваться в различные участки графического конвеера ( pipeline'а ). Поэтому успех DirectX и провал OpenGL свидетельствует именно о низкой инженерной культуре. На упомянутых юникс-станциях тоже были уродцы, подобные DirectX, например, HP StarBase.
Потому что окружающая среда в которой существуют инженеры в крупной фирме, и среда, в которой они существуют в средней или мелкой фирме - принципиально различается
Вполне возможно что низкая инженерная культура Микрософта как-то связана с его размерами. Это уже второй вопрос, но означает ли эта фраза Ваше согласие с утверждением о низкой инженерной культуре, свойственной продукции Микрософта?
no subject
Но не в Microsoft. А в Nvidia и ATI с одной стороны и у всяких там Blizzard-ов и кто еще этим DirectX пользуется - с другой.
Нет. Я утверждаю что только с крайне высокой ИНЖЕНЕРНОЙ культурой можно в рамках той бизнес-модели и той структуры менеджмента, которая имеется в Microsoft, выпускать хоть как-то, хоть криво, но работающие продукты.
Обвинять инженеров Микрософт в низкой инженерной культуре - это все равно что обвинять в незнании тактики лейтенанта, который положил половину роты в лобовой атаке на высотку, имея прямой приказ генерала взять эту высотку именно лобовой атакой. (поскольку менее компетентный командир положил бы всю роту, и высотки бы не взял)
Правда, я не уверен, что можно обвинять в профессиональной некомпетентности тех, кто отдает подобного рода приказы в Microsoft. Своих стратегических целей - увеличения прибыли или биржевой стоимости корпорации они до недавнего времени успешно достигали. А что поставляемый клиенту продукт - говно, не их проблемы. Пипл хавает.
no subject
Это как-то совсем непонятно.
Если и для OpenGL, и для DirectX нужна сложна система hook - points для драйверов, то при чем здесь производители карточек? И тем более разработчики софта?
Можно подумать что разработчики софта предпочитают глючный API DirectX.
Обвинять инженеров Микрософт в низкой инженерной культуре - это все равно что обвинять в незнании тактики лейтенанта, который положил половину роты в лобовой атаке на высотку, имея прямой приказ генерала взять эту высотку именно лобовой атакой. (поскольку менее компетентный командир положил бы всю роту, и высотки бы не взял)
Эта аналогия от меня ускользает. К тому же мне кажется что подобные приказы характерны для армий в которой лейтенаты вообще ни к чему не пригодны и на чьи донесения нельзя полагаться.
(no subject)
(no subject)
no subject
У тикля, как я смутно помню (лет 10 назад было), дело было полегче, но тикль как язык не очень совместим с жизнью по-моему. Он, собственно, где-то еще существует в качестве индустриального инструмента?
no subject
Ну судя по тому что в Camel Book все примеры из Толкиена, Ларри это дело любит.
А вообще это типичный пример того, какие грабли лежат в интеграции динамически типизируемого языка с менеджментом памяти с "портабельным ассемблером".
У Tcl проще, но в основном потому что Остерхут его специально затачивал под встраивание. А perl/XS рассчитаны именно на расширение языка, интерфейс с native code. Поэтому простота написания интерфейса принесена в жертву эффективности внутренностей интерпретатора.
Впрочем в Tcl с тех пор пошли на некоторые компромиссы и завели dual representation некоторых вещей. Как раз примерно 10 лет назад - в 8.1. Правда, если не хочешь изобретать собственных внутренних представлений, все остается достаточно просто.
Индус-триального - это когда за инструмент можно посадить индуса на испытательном сроке? А в mission-critical приложениях вполне себе используется.
no subject
no subject
no subject
не все йогурты одинаково полезны
Re: не все йогурты одинаково полезны
Re: не все йогурты одинаково полезны
Re: не все йогурты одинаково полезны
Re: не все йогурты одинаково полезны