f_evgeny wrote:Мы из разных миров. Не договоримся. Базовые понятия различные. Поэтому продолжать не стоит.
кстати, open source и undicumented API не являются совершенно несовместимыми понятиями. к примеру погуглите на тему недокументированных констант в Android
Not everyone believes what I believe but my beliefs do not require them to.
I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
офигеть...
Not everyone believes what I believe but my beliefs do not require them to.
f_evgeny wrote:Мы из разных миров. Не договоримся. Базовые понятия различные. Поэтому продолжать не стоит.
кстати, open source и undicumented API не являются совершенно несовместимыми понятиями. к примеру погуглите на тему недокументированных констант в Android
adb wrote:Скорее потому, что продумать API не сумели и вынужденны лепить временные заплатки для своих приложений.
Если программа использует только stdin/stdout, то этот API продуман давно. Как насчет продуманного API для доступа к, например, CUDA в Linux 1.0?
А так, M$ идет и дальше - есть целый C:\Windows\AppPatch каталог, который есть способ заставить старое глючное, но популярное, ПО работать с новыми версиями ОС. И как раз поддержка обратной совместимости ОС - это один из самых жирных козырей в мелкософтовском кармане, из-за которого выгнать их из корпоративного сектора в ближайших лет 10 просто нереально.
Ну если интерфейс ядра ОС - это не в тему, ну и ладно.
В Windows - весьма хорошо документированный и очень долго поддерживаемый API. И в том числе Kernel API. Написать двоичный драйвер работающий без перекомпиляции и трех тысяч #define под несколькими версиями Windows - вполне реальная и несложная задача.
Там только внутриядерные вызовы постоянно меняются, а вызовы программ к ядру неизменны и описаны.
The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. That interface is the one that users and application programmers can count on being stable.
Это всё больше волнует писателей модулей для ядра. Некоторые пытаются лабать закрытые, уже скомпилированные модули для своих простейших железок. Но тогда им приходится делать модули для каждой версии ядра.
Неужели крутой раутер с функцией N сдох?
Можно посочувствовать.
все же поразительно как живуче желание увидеть соседскую корову сдохшей
Не корову увидеть, а получить ваше личное мнение о новоприобретённом раутере.
Согласно мнению других, D-Link раутеры подвержены постоянным зависаниям. Но производитель, естественно, об этом умалчивает.
Да, в России Microsoft проводит успешную компанию против пиратских пользователей Windows.
После этих милицейских проверок интерес к Linux растёт всё больше и больше.
А и то, Windows 7 Ultimate стоит в России 14390 рублей или $500. Билл совсем охренел. http://www.mvideo.ru/price/lvl_108/class_277/
Last edited by Frank on 18 Nov 2009 20:47, edited 1 time in total.
Frank wrote:Там только внутриядерные вызовы постоянно меняются, а вызовы программ к ядру неизменны и описаны.
Многие программы включают драйвера, поэтому неплохо бы иметь и там совместимость.
А так и в Windows стандартные вызовы вроде NtCreateFile давно описаны и работают прям как в NT3.5. Если новые флажки и параметры добавляются, то старые поддерживаются ничуть не хуже.
Zombie416 wrote:
А так и в Windows стандартные вызовы вроде NtCreateFile давно описаны и работают прям как в NT3.5. Если новые флажки и параметры добавляются, то старые поддерживаются ничуть не хуже.
В Linux просто подключаешь <stdio.h> и о низкоуровневых вызовах ввода-вывода не беспокоишься.
Frank wrote:Не корову увидеть, а получить ваше личное мнение о новоприобретённом раутере.
Согласно мнению других, D-Link раутеры подвержены постоянным зависаниям. Но производитель, естественно, об этом умалчивает.
мне про это ничего не известно роутер как был куплен, так и работает как Карло. Вот WRT54G даже с super-puper-DDWRT иногда просто пропадал, видно "железо" барахлило.
Not everyone believes what I believe but my beliefs do not require them to.
Frank wrote:Не корову увидеть, а получить ваше личное мнение о новоприобретённом раутере.
Согласно мнению других, D-Link раутеры подвержены постоянным зависаниям. Но производитель, естественно, об этом умалчивает.
мне про это ничего не известно роутер как был куплен, так и работает как Карло. Вот WRT54G даже с super-puper-DDWRT иногда просто пропадал, видно "железо" барахлило.
D-Link в целом барахло, но работает. В то же время если через него не пролезет какой нибудь там SIP или PPTP, то я не удивлюсь.
На тему - снова ловушка с этими окошками - в Windows 7 не работают очень многие принтеры в том числе и очень дорогие (снят мол с производства год назад). Объясните мне адиоту - принтеры включаются через UCB или через сетку, то есть собственно драйвер как таковой принтеру вообще не нужен, а нужен лишь фильтр - какого ляда в Микрософте оные фильтры вдруг обозвали драйверами да еще и сделали несовместимыми между Win Vistа и Win 7? (Кстати, аналогичный вопрос, почему во всех системах кроме микрософта я могу делать multipath просто настраивая конфиг файлы, а в микрософте это можно сделать лишь купив драйвер у производителя железа а потом долго с ним трахаясь - с НетАппом скажем у нас так до конца от глюков мультипассовского драйвера для мелкомягких и не избавились. Для сравнения - в линуксе оно работает просто по умолчанию.)
Zombie416 wrote:
В Windows - весьма хорошо документированный и очень долго поддерживаемый API. И в том числе Kernel API.
О, да! Простейшая операция которая в линуксе делается одной строчкой, там занимает две страницы писанины. Плавали, сравнивали (был тут двух платформенный проект - сравнение впечатляло! Насколько же в виндоузе на нижнем уровне все неудобно сделано. Только лог послать - употеть можно!)
StrangerR wrote:О, да! Простейшая операция которая в линуксе делается одной строчкой, там занимает две страницы писанины.
Уже давно наоборот. Простейшая операция которая в PowerShell занимает одну строчку, с shell scripting займет две страницы писанины, пяток вызванных парсеров, и будет глючить с Unicode.
StrangerR wrote:На тему - снова ловушка с этими окошками - в Windows 7 не работают очень многие принтеры в том числе и очень дорогие (снят мол с производства год назад).
Да, с драйверами до смешного доходит - драйвер для древнего струйного принтера, снятого с производства лет 5 назад как минимум, в Windows Vista и Windows 7 драйвера есть. Со всеми делами и color management. Для XP/2003 x64 нет. Для Висты x64 есть и в W2003 их приходится ставить через виртуальную машину с Vista (после чего ее можно снести). Чудеса.
Для Линукс, понятно, этих драйверов нет, никогда не было и не будет.
StrangerR wrote:О, да! Простейшая операция которая в линуксе делается одной строчкой, там занимает две страницы писанины.
Уже давно наоборот. Простейшая операция которая в PowerShell занимает одну строчку, с shell scripting займет две страницы писанины, пяток вызванных парсеров, и будет глючить с Unicode.
StrangerR wrote:На тему - снова ловушка с этими окошками - в Windows 7 не работают очень многие принтеры в том числе и очень дорогие (снят мол с производства год назад).
Да, с драйверами до смешного доходит - драйвер для древнего струйного принтера, снятого с производства лет 5 назад как минимум, в Windows Vista и Windows 7 драйвера есть. Со всеми делами и color management. Для XP/2003 x64 нет. Для Висты x64 есть и в W2003 их приходится ставить через виртуальную машину с Vista (после чего ее можно снести). Чудеса.
Для Линукс, понятно, этих драйверов нет, никогда не было и не будет.
ну не знаю - у меня все принтеры в линуксах работают, причем я даже в cli не ходил, вызвал настройку в ясте и настроил без проблем. Но там это не драйверы - зачем принтеру драйвер - а фильтры печати. А драйвер нужен лишь для UCB и TCP/IP так эти драйверы есть что в линуксе что в виндузе - зачем фильтр печати было обзывать драйвером, для меня огромная загадка. (Я понимаю, драйвер АЦПУ-128 на Бэсм-6 который по прерываниям выставлял битики для молоточков... и так 128 раз на 1 строку - это ДРАЙВЕР, а преобразовать текст в набор команд - это вообще то фильтр а не драйвер).
Простой пример: позвать веб-сервер с query, получить с него XML, выдрать из него нужные части через XPath, и напечатать в консоль. Или получить с любого компьютера в сети список всех установленных third-party приложений отсортированных по производителю, и выдать полный список с именами и версиями в виде аккуратной таблицы, причем имена приложений могут содержать любые Unicode символы.
А все почему? Потому что есть нормальная, полнофункциональная runtime библиотека (ака .NET framework), и pipe передает объекты и группы объектов вместо каждой поделки парсящей текстовые файлы.
Простой пример: позвать веб-сервер с query, получить с него XML, выдрать из него нужные части через XPath, и напечатать в консоль. Или получить с любого компьютера в сети список всех установленных third-party приложений отсортированных по производителю, и выдать полный список с именами и версиями в виде аккуратной таблицы, причем имена приложений могут содержать любые Unicode символы.
А все почему? Потому что есть нормальная, полнофункциональная runtime библиотека (ака .NET framework), и pipe передает объекты и группы объектов вместо каждой поделки парсящей текстовые файлы.
Ну и какие проблемы? На том же перле все это получится даже короче, и юникод он поддерживает насколько я помню, и парсеры там есть. Я вот xml в мониторинге опрашиваю, так эта опрашивалка написана на шелле и занимает примерно 20 или 30 строк простого текста (даже и без перла).
StrangerR wrote:Ну и какие проблемы? На том же перле все это получится даже короче, и юникод он поддерживает насколько я помню, и парсеры там есть. Я вот xml в мониторинге опрашиваю, так эта опрашивалка написана на шелле и занимает примерно 20 или 30 строк простого текста (даже и без перла).
На перле получится примерно столько же. Но, что, интересно - перл работает и под Windows аналогичным образом. Речь была о шеллах.
Речь лишь о том что "Простейшая операция которая в линуксе делается одной строчкой, там занимает две страницы писанины. " давно утратило какой-то смысл и поменяло на обратный.
офигеть...
