VladD2 wrote: > _>Хм. Те кто работает со спец.железками не совсем в себе? > Та же виндовс разбирается на части без перекомпиляции. Даже есть > специальный соят для формирования специализированных встраеваемых > версий. Так что если в Линуксе это не делается, то это его личные > проблемы, а не идеологические.
Это просто ты со встраиваемыми устройствами не работал. В дистрибутиве
WinCE просто содержаться объектные файлы, скомпилированные для всех
поддерживаемых архитектур. Из них собирается готовый образ с нужной
функциональностью.
Точно так же можно делать и в Линуксе — но зачем заниматься сексом, если
есть исходники и проще их скомпилировать под целевую платформу?
Кстати, и отладка на уровне исходников тогда возможна.
Причем для этого MS пришлось полностью переписать все — у WinCE
полностью свое ядро, не имеющее ничего общего с NT.
> К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии > которые работают на куче разнообразных железок.
И которые не имеют ничего общего с NT.
> И формиловалась она под влиянием очень известного > человека в мире миникомпьютеров. NT изначально была архитектурно более > гибка чем Линукс. А линукс как раз послал к чертям все завоевания > научной мысли тех лет и породил монолитную архитектуру смело шагнувшую > на много лет назад.
Ага, но при этом сейчас Линукс является самым быстрым ядром для
десктопных ОС. А NT так и не стала микроядерной.
В OS X используют медленный Mach, а NT имеет "псевдомикроядерную"
архитектуру — часть Win32API работает в отдельном сервере. Но если этот
сервер падает — то падает и вся система (в Win2K при этом выдается
красивое окошко с обратным отсчетом).
M>>Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
VD>И что в статью можно из MySQL вынуть?
Почему бы и нет
Какой-нить связкой bash + vim + gettext + MySQL
VD>Да и верстка процесс творческий полностью не автоматизирвется.
Это увы..
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Cyberax, Вы писали:
>> Извини, но это руки. C>Спорим?
C>Правая синтетика — инкрементальная перестройка проекта BJam'ом на C>Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор C>- большая часть времени в Винде тратится на stat()'инг файлов.
Я не знаю что такое BJam и не знаю что такое stat(). Но я периодически обрабатываю большие объемы информции и знаю, что при грамотном подходе проблем в дисковой подсистеме нет.
C>Да? Вот покажи мне как в этих замечательных сменяемых FS добавить C>поддержку безопасности и возможность загрузки с них.
Загрузка происходит с МБР, а что до безопасности то тебе вроде скорость нужна была. В общем, тебе явно нужна пенисометрия не имеющая ничего общего с жизнью. А по жизни НТФС всем хватат за глаза. Потому никого твоя пенисометрия не колшит. В Линуксе 99.9% тоже ставя то что идет по умолчанию и не выпендриваются.
И вообще зря я стобой снова спорить влез. Речь шала о доступных под ОС возможностях. Сменяемые файловые системы это баловство для очень посвященных. А вот наличие МС Сиквела, Фаркрая, Винкомандера, Студии с дотнетом... она совсем не заменяет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: >> > Извини, но это руки. > C>Спорим?
На что спорим?
> C>Правая синтетика — инкрементальная перестройка проекта BJam'ом на > C>Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор > C>- большая часть времени в Винде тратится на stat()'инг файлов. > Я не знаю что такое BJam и не знаю что такое stat().
BJam — это Boost.Jam. Инструмент для постройки проектов, он при запуске
производит сканирование зависимостей.
stat()'инг — вызов функции stat(), которая берет информацию о файле
(даты изменения, размер, атрибуты).
> Но я периодически > обрабатываю большие объемы информции и знаю, что при грамотном подходе > проблем в дисковой подсистеме нет.
Как раз с большими файлами проблем у NTFS нет. Проблемы начинаются с
кучей мелких файлов.
Оказывается, что NTFS не очень-то умеет оптимизировать физическое
представление файлов на диске, из-за чего часто требуется передвижение
считывающих головок. Но даже если файл уже в кэше — алгоримты файловой
системы все равно намного медленнее аналогичных в Линуксе.
> C>Да? Вот покажи мне как в этих замечательных сменяемых FS добавить > C>поддержку безопасности и возможность загрузки с них. > Загрузка происходит с МБР, а что до безопасности то тебе вроде скорость > нужна была.
Как мне загрузить систему со своей FS? Даю наводку — это еще ни у кого
не получилось в полной мере.
Безопасность мне нужна ВМЕСТЕ со скоростью. Reiser4 в Линуксе мне дает
скорость, безопасность И транзакционную целостность FS (а NTFS этого,
кстати, не гарантирует).
> А по жизни НТФС всем хватат за глаза.
Так как 99% ничего кроме NTFS и FAT и в глаза не видели.
> Потому никого > твоя пенисометрия не колшит. В Линуксе 99.9% тоже ставя то что идет по > умолчанию и не выпендриваются.
Да ну? То-то идиоты разрабатывают Reiser4, XFS и прочие никому не нужные
вещи (кстати, Debian при установке по дефолту Reiser3 ставит).
> И вообще зря я стобой снова спорить влез. Речь шала о доступных под ОС > возможностях. Сменяемые файловые системы это баловство для очень > посвященных. А вот наличие МС Сиквела, Фаркрая, Винкомандера, Студии с > дотнетом... она совсем не заменяет.
Ага. Главное чтобы был .Net, Пасьянс и MS SQL. Больше никому ничего не
надо.
VladD2 wrote: >> > C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM. >> > В чем смысл этого ответа? > C>Чтобы сомнений в компетентности не возникало. > Ты мои сообщения, то в этой ветке читал?
Нет, только пишу.
> C>Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки > C>для Windows на него не ориентирована. > Это лож. Сред разработки для Явы под виндовс больше всего насвете.
Среды разработки для Java пишутся (обычно) на Java и работают из-за
этого везде.
> XPCOM просто самопальный клон КОМ-а который можно использовать в любом > компиляторе С++ при наличии соотвествующих библиотек.
А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу
ATLевских, всякие аналоги ATL/MFC Trace Tool?
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию >> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем >> C>случае в юниксах эта задача не решается). >> Читайте про VFS (виртуальная файловая система) и про интерфейс >> vnone/vfs, который чётко специфицирует организацию и функционирование >> любой произвольной файловой системы в UNIX. C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не C>как драйвер в ядро.
FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра 2.6.14-rc1, и во FreeBSD. Драйверы FUSE выполняются в пользовательском режиме и могут быть реализованы на языках программирования: C, C++, Java, Haskell, TCL, Python, Perl, Sh, Ocaml, Pliant, Ruby, C#.
На сегодня существует несколько десятков (больше 50) пользовательских файловых систем, реализованных на базе FUSE. Основные функции, такие:
шифрование и сжатие файлов "на лету";
SMB (монтирование при первом обращении, кэширование);
FTP, SSh, WebDAV, Gmail и т.д.;
монтирование содержимого архивов (rar, zip, tar, bzip2, gzip и др.);
монтирование специфических устройств (iPod, мобильные телефоны Siemens, Apple iPhoto DPAP и др.);
монтирование NTFS в режиме read&write (полноценная запись в отличие от той, что содежится в ядре по умолчанию);
хранение файлов в реляционной СУБД.
(по материалам печатного журнала "Системный администратор" №6 (июнь) 2006 года)
Так что, вопрос о компонентности файловой системы на *NIX может быть закрыт? Или есть ещё какие соображения?
Здравствуйте, VladD2, Вы писали:
VD>К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок. VD>Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад.
Выделенное — чистый, незамутнённый бред.
Первое упоминание о Linux датировано августом 1991 года, когда Линус Торвальдс опубликовал своё первое сообщение о начале разработки UNIX-подобного ядра в эхоконференции, посвящённой "правильному" Minix.
Newsgroups: comp.os.minix
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: What would you like to see most in minix?
Date: 25 Aug 91 20:57:08 GMT
Привет всем, кто тут пользуется minix'ом
Я делаю (свободную) операционную систему (просто хобби, ничего такого большого и профессионального, как GNU) для 386(486) клонов AT. Я вожусь с ней с апреля, и она уже скоро будет готова. Мне бы хотелось услышать мнению людей о том, что им нравится/не нравится в minix'е, поскольку моя ОС кое в чём похожа на него (помимо всего прочего, у неё такое же физическое расположение файловой системы (по практическим причинам)).
На данный момент я портировал bash (1.08) и gcc (1.40), и всё, похоже, работает. Это говорит, что через несколько месяцев я уже получу нечто применимое на практике, и мне хотелось бы узнать, какие возможности люди хотели бы найти в ней. Жду любых предложений, хотя обещать, что реализую их, я не могу. :-)
Linus (torvalds@kruuna.helsinki.fi)
Тогда ещё NT в проекте не стояло. OS/2 разрабатывалась совместно с IBM. Инженеры VAX/VMS начали подтягиваться в Microsoft в 1989 году с развалом бизнеса операционок DEC. И первая публичная версия NT 3.1 состоялась 27 июля 1993 года. Что было с Linux в 1993 году говорить нужно?
VD>Ага. Только недавно. Примерно в 1992-ом году. А в 2000-ном был вариант виндовс для встаеваемых систем вообще не имеющих GUI и управляемый исключительно из командной строки удаленно.
Опять же, любопытный источник: http://firedrake.org/paddy/images/non-unix_os_history_0.3.2.pdf
>>> _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным" >>> для винды. >>> Хм. Свежая мысль однако. >>> Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот >>> компонентная модель Явы и дотнета нравится куда больше. Хотя как >>> средство межязыковой интеграции КОМ пока что никем не превзойден. Назови >>> хотя бы одну компонентную технологию которая поддерживалась бы в >>> стольких языках. _>>Pure C (dll/so)?
VD>Это вообще не компонентные технологии.
_>>А что, модель компиляции исходников в линухе и иже с ними — вполне таки компонентная модель. Простая как швабра, дуб _>>дубом (в смысле крепкая).
VD>У тебя очень странные понятия о компонентых технологиях. Компоненты обязаны позволять стрить программу из поставляемых одтедьно модулей. При этом не должна требоваться компиляция или информация о модулях в текстовом виде.
Компоненты EJB имеет дескрипторы развёртывания в текстовом виде (в формате XML), но от этого EJB не перестали быть компонентами.
VD>Кроме того компонетная технология подразумевает наличие инфраструктуры. Ведь просто загрузка модулей мало интересна. Важно наличие фрэймворка позволяющего эффективно разработывать софт с его помощь. Ведь в принципе КОМ без проблем можно реализовать с нуля на С++. Вот только это огромный объем работы время на который изымается из времени отведенного на основные проекты.
Здравствуйте, Cyberax, Вы писали:
C>В OS X используют медленный Mach,
Mach НЕ медленный. Это ядро — красивое исключение из правила "все микроядра медленны".
C>а NT имеет "псевдомикроядерную" C>архитектуру — часть Win32API работает в отдельном сервере. Но если этот C>сервер падает — то падает и вся система (в Win2K при этом выдается C>красивое окошко с обратным отсчетом).
Было уже. Каунтдовн у MS вышел на славу: сохранись за одну минуту!
Здравствуйте, Cyberax, Вы писали:
C>Нет, только пишу.
Вот то-то и оно.
C>Среды разработки для Java пишутся (обычно) на Java и работают из-за C>этого везде.
И тем неменее есть работающие только на Виндовс. Причем на виндовс работают все доступные среды. И оно логично.
>> XPCOM просто самопальный клон КОМ-а который можно использовать в любом >> компиляторе С++ при наличии соотвествующих библиотек. C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу C>ATLевских, всякие аналоги ATL/MFC Trace Tool?
А что с Цигвином оно не работает?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
iZEN wrote: > C>В OS X используют медленный Mach, > Mach НЕ медленный. Это ядро — красивое исключение из правила "все > микроядра медленны".
Медленный, причем очень сильно. Это очень хорошо заметно на
многопоточных или серверных приложениях.
Кроме того, Mach устроен примерно так же как и NT — там есть один
большой Unix-сервер, внутри которого работают FS, драйвера и Unix-runtime.
iZEN wrote: > C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не > C>как драйвер в ядро. > FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра > 2.6.14-rc1, и во FreeBSD.
FUSE — это сравнительно недавнее появление, да еще и специфичное для
нескольких ОС. Классическая Unix-модель не предлагает никаких средств
расширения FS кроме именованых пайпов/сокетов.
> Так что, вопрос о компонентности файловой системы на *NIX может быть > закрыт? Или есть ещё какие соображения?
Есть, см. выше.
VladD2 wrote: > C>Среды разработки для Java пишутся (обычно) на Java и работают из-за > C>этого везде. > И тем неменее есть работающие только на Виндовс. Причем на виндовс > работают все доступные среды. И оно логично.
Можно пример таких сред? Я знаю, пожалуй, только OmniCore.
>> > XPCOM просто самопальный клон КОМ-а который можно использовать в любом >> > компиляторе С++ при наличии соотвествующих библиотек. > C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу > C>ATLевских, всякие аналоги ATL/MFC Trace Tool? > А что с Цигвином оно не работает?
XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что
кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не >> C>как драйвер в ядро. >> FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра >> 2.6.14-rc1, и во FreeBSD. C>FUSE — это сравнительно недавнее появление, да еще и специфичное для C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств C>расширения FS кроме именованых пайпов/сокетов.
Кто вам такое сказал?
vnode/vfs в UNIX давно придумали?
Вот структурная схема FUSE:
Здравствуйте, Cyberax, Вы писали:
C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore.
VS, например.
>> C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу >> C>ATLевских, всякие аналоги ATL/MFC Trace Tool? >> А что с Цигвином оно не работает? C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Это к чему сказано?
У меня орпределенно создается впечатление, что что ты разговариваешь не со мной, а с некими потусторонними силами. Если так будет продолжаться дальше, я буду вынужден просто игнорировать все твои сообщения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Как раз с большими файлами проблем у NTFS нет. Проблемы начинаются с C>кучей мелких файлов.
200-300 тыс. файлов с средним объемом 1 MB — это куча мелких файлов? Реальный пример в моей практике — голосовая почта. В 1MB вмещается около 1 минуты сообщения (PCM, 8KHz, 16 bit, mono). Если нет, то вопрос снят, если да, то задержки на поиск файла и его трансфер через плату IP телефонии можно считать равными нулю.
P.S. возможно, что ФС под никсы могут делать каждое обращение на 1-5 миллисекунды быстрее. А зачем, если с подобными задачами более чем справляется 600-й пень и 128 метров оперативки, который уже вряд-ли купишь в магазине?
VladD2 wrote: > C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore. > VS, например.
А разве в ней есть поддержка Java? Я видел только J#.
> C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что > C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет. > Это к чему сказано? > У меня орпределенно создается впечатление, что что ты разговариваешь не > со мной, а с некими потусторонними силами. Если так будет продолжаться > дальше, я буду вынужден просто игнорировать все твои сообщения.
Тебе вроде бы сказали, что формально в Винде можно использовать другие
компонентные архитектуры. Но реально используется практически только
один COM.
Anton Batenev wrote: > 200-300 тыс. файлов с средним объемом 1 MB — это куча мелких файлов? > Реальный пример в моей практике — голосовая почта. В 1MB вмещается около > 1 минуты сообщения (PCM, 8KHz, 16 bit, mono). Если нет, то вопрос снят, > если да, то задержки на поиск файла и его трансфер через плату IP > телефонии можно считать равными нулю.
Не тот пример. На единичных обращениях это неважно.
> P.S. возможно, что ФС под никсы могут делать каждое обращение на 1-5 > миллисекунды быстрее.
Вот именно это и важно. У меня при компиляции происходит обращение
примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении
— это 10 секунд в сумме.
А так как инкрементальную компиляцию я запускаю раз 100 в день — то
общая сумма сэкономленного времени получается очень неплохой.
> А зачем, если с подобными задачами более чем справляется 600-й пень и > 128 метров оперативки, который уже вряд-ли купишь в магазине
А может-таки есть другие задачи?
iZEN wrote: > C>FUSE — это сравнительно недавнее появление, да еще и специфичное для > C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств > C>расширения FS кроме именованых пайпов/сокетов. > Кто вам такое сказал? > vnode/vfs в UNIX давно придумали?
Вопрос на засыпку: я могу из под обычного пользователя в юниксах
добавить в ядро свой модуль и подмонтировать свою FS?
