И кстати прикинем, во что выливается собственная доработка чего-либо. Тут чуть ниже я привел расчет, что содержание одного-единственного (!) разработчика в течение года обойдется в 64-88K$. За такие деньги совершенно реально заключить контракт на индивидуальную доработку ПО со специализированной компанией, которая занимается нужным Вам ПО. Имея близкую к 100% вероятность успеха. Своя же команда - даже маленькая, обойдется Вам вообще в пол миллиона баксов (!) и больше - несколько программистов, их руководитель технический, менеджер по административной линии, секретарь. :)
2 килобакса???!!!
Один-единственный (!) программист, способный дорабатывать исходные коды open source продуктов на C/C++, стоит порядка 3-4K в месяц на свою зарплату, плюс 2-3K уйдет на налоги с его з/п и на выплаты во всякие социальные и пенсионные фонды. Еще ~4K уйдет на организацию ему рабочего места, если считать, что все средства разработки у него бесплатные. И проработает он, скажем, всего 1 год - пока будет заниматься своей разработкой и отладкой/поддержкой изменений на начальном этапе. Уже за этот единственный год он сожрет у Вас от 64 до 88 КИЛОБАКСОВ. А теперь прикиньте, СКОЛЬКО коммерческого ПО можно купить на 88 килобаксов! Да за такие деньги уже можно заключить контракт на индивидуальную доработку с известной компанией, имея гарантию успеха. Ведь Ваш программист может деньги потратить, а затем сказать: "извините - у меня не получилось..." :)
Есть еще одна очень важная для бизнеса разница - если они заказывают разработку/доработку специализированной компании, присутствующей своими продуктами на рынке, то они имеют подкрепленную фактами уверенность в успешном завершении проекта. И так как эта внешняя компания - профессионалы в своем деле, то они могут адекватно оценить время разработки, а цену сильно завышать не будут.
А вот доработка программного продукта "своими силами" для компании, которая не специализируется на разработке ПО - это практически гарантированный провал и растрата средств. Почему на рынке существует куча даже специализированных компаний, но только единицы из них по-настоящему успешные? Потому, что очень сложно:
- Собрать хорошую команду программистов-исполнителей,
- Найти им хорошего архитектора/постановщика задач,
- Найти менеджеров, которые будут эффективно управлять процессом разработки,
- Добиться того, чтобы весь этот коллектив "сработался" вместе.
Соответственно это вообще не путь для компании, которая сама на разработке не специализируется. Такие игры могут позволить себе разве что огромные монстры, обладающие бездонными закромами набитыми баксами и не имеющие ограничений во времени.
Абстракции хороши, когда они продуманные с самого начала, а не стихийно сложившиеся и ориентированные на прошлый век. Вот, например, в системе IBM/360+ был хорошо продуманный абстрактный механизм ввода-вывода (канальные программы), который поддерживал все виды устройств через единый набор базисных команд и где был предусмотрен изначально и отлично работал асинхронный ввод-вывод (еще в 60-е годы прошлого века!). Еще из низкоуровневых интерфейсов красив по своей архитектуре SCSI. Но API unix как абстрактная модель ввода-вывода... Как бы сказать... Он убог и примитивен, находится на уровне мышления рубежа 60-х и 70-х годов, когда он был придуман. Тогда главными устройствами ввода-вывода были магнитная лента и телетайп. Этим устройствам и был отдан приоритет при выборе архитектуры API ввода-вывода. Но с тех пор представления о вводе-выводе даже на низком (!) уровне ушли далеко вперед, и назвать абстракцию unix современной язык не поворачивается.
Уважаю Ваше мнение, но сам считаю сейчас, что эти API в итоге примерно равноценные по удобству или неудобству. Для меня *nix имеют только два преимущества, перед Windows:
- Они идут на всех аппаратных платформах, имеющих практическое значение,
- Использовав бесплатный Linux/FreeBSD не нужно платить деньги, сопоставимые со стоимостью железа, при развертывании своей серверной инфраструктуры.
Так я же не отрицаю, что unix имеет такое преимущество в своем API перед Windows. Но его значение Вы сильно преувеличиваете! И это преимущество нивелировано отсутствием унификации API для работы с частными видами sockets и API для асинхронного I/O.
Если Вы пишите VoIP, то Вам не нужно работать со звуковой картой, как с файлом - так как это СЕМАНТИЧЕСКИ НЕ ФАЙЛ НА ДИСКЕ, а совсем другой объект, со своими фундаментально отличными свойствами.
Если Вы пишите сетевое приложение с UDP-сокетом, то Вам не нужна его унификация с файлом, потому, что UDP-дейтаграммы это СЕМАНТИЧЕСКИ иные объекты, чем записи в файле и Вам нужно другое API (sockets API), чтобы эффективно оперировать ими.
Если Вы пишите интерактивное графическое приложение, например игру, то Вам не нужна унификация экрана с файлом, звуковой картой или сокетом, потому, что экран - это СЕМАНТИЧЕСКИ иной объект, чем файл или звуковая карта или сокет.
Конечно, если кто-то дает Вам универсальный API для элементарного I/O серии байтов для этих объектов - то часто (не всегда) это будет полезно. Но отсутствие такой возможности - абсолютно не та проблема, от которой у Вас будет болеть голова при программировании.
Во-первых, исходные коды старых версий ядра уже давно уперли.
Во-вторых, если Вы думаете, что сможете поддерживать и развивать эти исходные коды эффективнее, чем сам Microsoft, то я говорю без ирони - дерзайте, у Вас большое будущее. :)
В-третьих, не только учебные организации, но и многие коммерческие партнеры Microsoft по разработке ПО имеют возможность изучать исходные тексты ядра Windows.
Мне приходилось раньше программировать воспроизведение и запись звука для VoIP приложений как в Windows, так и в *nix, поэтому я хорошо знаю, какие реальные сложности возникают при этом. Наличие отдельного API для работы со звуком меня совершенно не тормозило в Windows. А вот отсутствие единого стандартного API для работы со звуком в unix мешало. Кроме того, при всем желании я НИКАК не мог бы реализовать нужную мне функциональность в *nix только на файловом read/write. Под Linux жестко необходимо было использовать API OSS, а затем ALSA, и не было абсолютно никакой пользы от унификации хендлов в read/write.
Конечно, если бы я сам лично занимался разработкой собственной новой ОС, то я попытался бы унифицировать API для работы со сходными объектами. Но мы говорим не об абстрактных философских идеях, а про реализацию API реальных живых систем, данных нам в ощущениях.
И я берусь на основании большого опыта программирования разных приложений в разных областях утверждать, что, не смотря на наличие отдельных абстрактных преимуществ (типа стандартизации handles в select), в реальности API *nix создает кучу своего траха и в целом не удобней, чем API Windows. К тому же оно менее стандартизовано и еще хуже исторически наслоено само на себя. Например, я могу подать любой handle в select - но для достижения предельного быстродействия в HTTP-сервере сайта СЕЙЧАС мне придется использовать poll, epoll, kqueue. Которые между собой не стандартизированы.
Мне легче было бы не смешивать в одном select файловые и сокетные handles, чем писать через #ifdef кучу кода для разных API и выдумывать абстрактную внутреннюю архитектуру, которая одинаково хорошо ляжет на все виды юниксовского async i/o.
Что в итоге имеем? И там, и там хватает своих проблем. В *nix очень просто сделать простые вещи, зато сложные, типа асинхронного ввода-вывода, приходится делать извращаясь неимоверным образом, причем для разных систем совсем по-разному. Тут тебе и select, и poll, и epoll, и kqueue, и asio и сигналы, и черт знает что еще, все со своей архитектурой, куча кода по #ifdef... А где он этот абстракный read/write теперь, в серьезных приложениях?
А реально в Apache с сокетами работают через обыкновенный read/write и все? Или там задействовано практически все специфическое TCP-сокетное API, чтобы добиться асинхронности и производительности? :)
Я не спорю, что абстракция - приятна. Но это не главное для приложений реального мира.
А теперь сделайте тоже самое, но для 5.1 звука, регулируя громкость в каналах и выставив 24-битный формат семплов БЕЗ использования ioctl и дополнительных API (кстати своих для разных видов *nix). А так же сделайте запись с микрофона с АРУ и главное так, чтобы приложение получало уведомление о заполнении каждого 10 ms фрейма в реальном времени (для VoIP, например), но запись не останавливалась бы между ними - средствами стандартного read/write, без дополнительных API. Если такие вещи сделать нельзя, то IMHO в современном мире унификация хендлов полезна в основном абстрактно. Кто сейчас в реальности пишет или воспроизводит звук так, как Вы написали? Если реально user хочет интерактивное приложение с кучей форматов, ручек-регуляторов и красивой мордой, а не cat xxx > yyy.
Или вот Вам другой пример - в unix формально можно воспроизвести звук на звуковой карте с помощью write. Но нахрена это нужно - выводить туда данные с помощью write в реальных приложениях? Если при этом мы не можем ни настроить громкость без ioctl/других API отличающихся от системы к системе и от версии к версии, ни установить параметры канала, ни отслеживать в реальном времени состояние буферов вывода для интерактивного приложения... В результате унификация handles во write на практике не нужна для современных приложений.
Возможность работать с сокетами файловым API (или наоборот) это в основном чистое эстетство. А зачем оно нужно на практике? Вы же не будете спорить, что семантически есть ОГРОМНАЯ разница между файлом на диске, и сокетом и логика их обработки в РЕАЛЬНОМ приложении очень отличается, не говоря уже о том, что они СЕМАНТИЧЕСКИ не взаимозаменяемы. Вырожденные случаи типа древнего Telnet не в счет.
Так вот - на практике файловый API Windows намного более удобен для того, для чего он реально создан - для работы с файлами - если брать именно СЛОЖНЫЕ и СОВРЕМЕННЫЕ приложения. Где интенсивно используется асинхронный ввод-вывод.
1С объективно силен не только маркетологами. Разве есть альтернативная им (по качеству) свободная бухгалтерия, например? Но не буду спорить с тем, что реклама вносит большой вклад в популярность продукта.
Один-единственный (!) программист, способный дорабатывать исходные коды open source продуктов на C/C++, стоит порядка 3-4K в месяц на свою зарплату, плюс 2-3K уйдет на налоги с его з/п и на выплаты во всякие социальные и пенсионные фонды. Еще ~4K уйдет на организацию ему рабочего места, если считать, что все средства разработки у него бесплатные. И проработает он, скажем, всего 1 год - пока будет заниматься своей разработкой и отладкой/поддержкой изменений на начальном этапе. Уже за этот единственный год он сожрет у Вас от 64 до 88 КИЛОБАКСОВ. А теперь прикиньте, СКОЛЬКО коммерческого ПО можно купить на 88 килобаксов! Да за такие деньги уже можно заключить контракт на индивидуальную доработку с известной компанией, имея гарантию успеха. Ведь Ваш программист может деньги потратить, а затем сказать: "извините - у меня не получилось..." :)
А вот доработка программного продукта "своими силами" для компании, которая не специализируется на разработке ПО - это практически гарантированный провал и растрата средств. Почему на рынке существует куча даже специализированных компаний, но только единицы из них по-настоящему успешные? Потому, что очень сложно:
- Собрать хорошую команду программистов-исполнителей,
- Найти им хорошего архитектора/постановщика задач,
- Найти менеджеров, которые будут эффективно управлять процессом разработки,
- Добиться того, чтобы весь этот коллектив "сработался" вместе.
Соответственно это вообще не путь для компании, которая сама на разработке не специализируется. Такие игры могут позволить себе разве что огромные монстры, обладающие бездонными закромами набитыми баксами и не имеющие ограничений во времени.
- Они идут на всех аппаратных платформах, имеющих практическое значение,
- Использовав бесплатный Linux/FreeBSD не нужно платить деньги, сопоставимые со стоимостью железа, при развертывании своей серверной инфраструктуры.
Если Вы пишите VoIP, то Вам не нужно работать со звуковой картой, как с файлом - так как это СЕМАНТИЧЕСКИ НЕ ФАЙЛ НА ДИСКЕ, а совсем другой объект, со своими фундаментально отличными свойствами.
Если Вы пишите сетевое приложение с UDP-сокетом, то Вам не нужна его унификация с файлом, потому, что UDP-дейтаграммы это СЕМАНТИЧЕСКИ иные объекты, чем записи в файле и Вам нужно другое API (sockets API), чтобы эффективно оперировать ими.
Если Вы пишите интерактивное графическое приложение, например игру, то Вам не нужна унификация экрана с файлом, звуковой картой или сокетом, потому, что экран - это СЕМАНТИЧЕСКИ иной объект, чем файл или звуковая карта или сокет.
Конечно, если кто-то дает Вам универсальный API для элементарного I/O серии байтов для этих объектов - то часто (не всегда) это будет полезно. Но отсутствие такой возможности - абсолютно не та проблема, от которой у Вас будет болеть голова при программировании.
Во-вторых, если Вы думаете, что сможете поддерживать и развивать эти исходные коды эффективнее, чем сам Microsoft, то я говорю без ирони - дерзайте, у Вас большое будущее. :)
В-третьих, не только учебные организации, но и многие коммерческие партнеры Microsoft по разработке ПО имеют возможность изучать исходные тексты ядра Windows.
Конечно, если бы я сам лично занимался разработкой собственной новой ОС, то я попытался бы унифицировать API для работы со сходными объектами. Но мы говорим не об абстрактных философских идеях, а про реализацию API реальных живых систем, данных нам в ощущениях.
И я берусь на основании большого опыта программирования разных приложений в разных областях утверждать, что, не смотря на наличие отдельных абстрактных преимуществ (типа стандартизации handles в select), в реальности API *nix создает кучу своего траха и в целом не удобней, чем API Windows. К тому же оно менее стандартизовано и еще хуже исторически наслоено само на себя. Например, я могу подать любой handle в select - но для достижения предельного быстродействия в HTTP-сервере сайта СЕЙЧАС мне придется использовать poll, epoll, kqueue. Которые между собой не стандартизированы.
Мне легче было бы не смешивать в одном select файловые и сокетные handles, чем писать через #ifdef кучу кода для разных API и выдумывать абстрактную внутреннюю архитектуру, которая одинаково хорошо ляжет на все виды юниксовского async i/o.
Я не спорю, что абстракция - приятна. Но это не главное для приложений реального мира.
Так вот - на практике файловый API Windows намного более удобен для того, для чего он реально создан - для работы с файлами - если брать именно СЛОЖНЫЕ и СОВРЕМЕННЫЕ приложения. Где интенсивно используется асинхронный ввод-вывод.