"Люди, которые думают, что файловые системы пространства пользователя могут быть чем-то большим, чем игрушки, просто введены в заблуждение" - так Линус Торвальдс прокомментировал (http://www.spinics.net/lists/linux-fsdevel/msg46078.html) сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных на FUSE, нельзя решить только за счет перемещения их кода в ядро. "Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально низкоскоростному устройству. Но для чего-то вроде корневой ФС ? Нет. Из этого ничего не выйдет." - добавил Линус.
Спор о файловых системах пространства пользователя начался после того, как Миклос Жереди (Miklos Szeredi) отправил (http://www.spinics.net/lists/linux-fsdevel/msg45779.html) в список рассылки linux-fsdevel письмо с просьбой добавить код драйвера OverlayFS в Linux-ядро версии 3.1. Эндрю Мортон (Andrew Morton) спросил его о причинах реализации ФС в виде драйвера ядра, вместо использования FUSE, на что М...URL: http://www.h-online.com/open/news/item/Torvalds-calls-usersp...
Новость: https://www.opennet.ru/opennews/art.shtml?num=31054
>Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально низкоскоростному устройству.Это он пусть разработчикам ntfs-3g скажет, тогда его сразу пользователи гетерогенных систем "поймут и одобрят". Линус становится всё большим неадекватом, не понимающим идеи гибридного ядра с чётким разделением пространств ядра и пользователя.
И - да: "редко используемый интерфейс к изначально низкоскоростному устройству" - это SATA III к гибридному (SSD+HDD) диску? Или NTFS/HFS+ на нём же?
Доступ к файлам внешнего устройства через COM-порт, например. Не?
А ничё так, что в таком случае пох, на каком уровне работает драйвер ФС вашего устройства? Узкое место - COM-порт, а не FUSE.
Об этом и разговор, на сколько я понимаю.
> Об этом и разговор, на сколько я понимаю.Просто когда об этом сказал Линус это бред зазнавшегося скандинава. :)
С получением гражданства США Линус поглупел.
> С получением гражданства США Линус поглупел.Чего такого глупого он сказал? Он лишь выступил Капитаном Очевидностью, напомнив лишний раз о НИКАКОЙ скорости работы FUSE-драйверов. Они и правда ОЧЕНЬ тормозные, что отлично видно на фоне ядерных. А вот вам бы не помешало поумнеть независимо от вашего гражданства.
А что рассказывать-то? Чувак просто указал на то, что через FUSE оно будет медленнее, он же не сказал "FUSE - говно, не пишите на нем ничего". Если автор OverlayFS хочет повысить быстродействие своей ФС за счет работы в режиме ядра - зачем ему запрещать это?И да, проблемы пользователей гетерогенных систем (дуалбутчиков), которые не могут купить ядерный NTFS, волнуют только им подобных.
Покупать проприетарный драйвер ядра для домашнего использования (масштабнее смотреть кругозор не позволяет, несчастный админ localhost'а? предприятий в этом мире не существует?) будет только разводящийся на деньги лох, вроде вас.
> Покупать проприетарный драйвер ядра для домашнего использования (масштабнее смотреть
> кругозор не позволяет, несчастный админ localhost'а? предприятий в этом мире не
> существует?) будет только разводящийся на деньги лох, вроде вас.ваше предприятие не может себе позволить ~$20 на драйвер если есть в нем необходимость? ну да, покупать софт - это не по-русски, можно же стыбрить или юзать home-level решения, заодно будет повод посрать на форумах...
для домашнего использования у вас есть ntfs-3g, чего ноешь-то?
Я не писал, что меня чем-то не устраивает NTFS-3G, я наоборот только "за" FUSE, тем более в домашних условиях. Предприятия себе и дополнительные лицензии на Windows легко могут позволить для работы с NTFS-разделами с критичными данными, ядерный NTFS от Tuxera без вменяемых NTFS-tools - самоубийство. Поверьте, многочасовые изменения размеров разделов и неторопливые проверки на ошибки даже ядерный драйвер не отменяет. И самый большой ужас - восстановление удалённых данных с помощью Photorec. Врагу не пожелаю делать это под *NIX.
> критичными данными, ядерный NTFS от Tuxera без вменяемых NTFS-tools - самоубийство.По-моему, использовать под *никсами NTFS на регулярной основе - это извращение. Например, EXT4 делает по скорости нтфсное тормозилово В НЕСКОЛЬКО РАЗ. Это фузевое хозяйство годится чтобы прочтать данные с тома, переформатить и забыть нтфс как страшный сон. Ext4 запросто уделает даже ядерную реализацию нтфс в винде, не то что фузевую в линуксе.
>Ext4 запросто уделает даже ядерную реализацию нтфс в виндеПруф или не было?
> Пруф или не было?Отформатьте диск в тои и другое да проверьте, не век же вам все разжевывать и в ротик класть? Я для себя побенчил и выводы сделал. NTFS идет к черту, особенно в виде FUSE.
Городской сумасшедший?
>Это фузевое хозяйство годится чтобы прочтать данные с тома, переформатить и забыть нтфс
> как страшный сон.Вы всегда так поступаете когда вам приносят флешку чтобы скинуть документ/фильм и т д?
Ну на своих то переносных девайсах вы точно сделали ext4. Осталось только написать драйвер под все эти неправильные операционки, которые его не поддерживают. Или неправильные ОС "не нужны"?
Скопировать с флешки фильм/документ - это одноразовая операция, для которой как раз лучше всего подходит именно NTFS-3g и FUSE.И не нужно всё валить в одну кучу - переносные устройства, компьютер с виндой и компьютер с линуксом. Переносные устройства не могут создать такую нагрузку, от которой задохнулся бы даже рейд-массив с ext4, поэтому медленной флешки с примитивной ФС там достаточно. На компьютере с виндой NTFS - это практически единственный выбор, просто других вариантов нет. На компьютера с линуксом есть масса разных ФС для самых разных задач. Для задач "скопировать документ в систему с флешки" возможностей NTFS-3g и FUSE в линуксе вполне достаточно.
> Переносные устройства не могут создать
> такую нагрузку, от которой задохнулся бы даже рейд-массив с ext4, поэтому
> медленной флешки с примитивной ФС там достаточно.NTFS нет, пришлось собственный swap переформатировать в NTFS.
На старом (древнем?) двухядернике загрузка 12-15%. Скорость копирования 25-27Мб/с, но никак не 15.
Может оно 190 и надо под Линукс с NTFS, но только здесь вот по-пунктам и подробно: зачем?
А не общими фразами.
А внятно так никто и не ответил.
Гетерогенные системы ≠ нищеброды-дуалбутчики. Шире надо мыслить, шире...
> он же не сказал "FUSE - говно, не пишите на нем ничего"Как-раз, таки, сказал, сравнив пользу от ФС в юзерспейчсах с пользой от игрушек. Не учитывая кейсы, в которых FUSE дает преимущество, пусть за счет скорости.
Неадекватами являются те, кто не разобравшись в мат. части лезет с такими заявлениями, называя неадекватом Линуса.. И при чем же здесь четкое отделения юзерспэйса от ядра?.. Лишь бы что-нибудь ляпнуть?.. То, что говнодрайвер ФС, как одного из самых критичных объектов, реализует свои механизмы в юзерспэйсе - вовсе не является панацеей, когда в составе ядра его можно куда более гибко контролировать..
> Это он пусть разработчикам ntfs-3g скажет,А там и говорить не надо - ядерная версия оного рвет FUSEвую на британский флаг, прекрасно доказывая тезис. Вылезаем из танка!
> Линус становится всё большим неадекватом
Не, не линукс а анонимные аналитики типа вас.
> Не, не линукс а анонимные аналитики типа вас.Сказал анонимный аналитик
> Сказал анонимный аналитикКапитан, перелогиньтесь!
> А там и говорить не надо - ядерная версия оного рвет FUSEвуюТолько где ее взять и как поставить? По-моему, он везде и есть ядерный и производительность просто никуда не годится, да и процессор грузит на 100%.
mount -t ntfs-3g это же не fuse?
>Линус становится всё большим неадекватом, не понимающим идеи гибридного ядра с чётким разделением пространств ядра и пользователя.Что в этом такого неадекватного? ФС в юзерспейсе для линукса действительно тормозная штука, сам ими пользуюсь это удобно, но это не бысто нифига. А про гибридные ОС вообще иди к своим мелкомягким, это их стиль когда не рыба не мясо, линукс монолитный, что-то менять уже поздно.
Осторожней с высказываниями. Линус же икона для всех этих фанатиков кругом.
Он не использует линукс как домашнюю пользовательскую ОС (он юзает мак). Линукс для него стал работой и только. Он может спокойно сказать, что линукс на декстопе - это не серьезно (игрушка и т д)
Из серии собрались как-то 3 капитана очевидность :-)
Я бы скорее сказал это из серии как его высочество любит обгадить чужой труд. Люди, которые усердно занимаются безопасностью - дрочащие обезьяны. Люди, которые разрабатывают дельные, но некритичные в производительности ФС - детишки, играющиеся в игрушки. Уже забыл как там он опустил разработчика подсистемы tty что тот ушёл, бросив код... Короче, Тролвальдс у нас один самый умный, брызжащий на всех свысока.
Деликатности ему времееами не хватает, это да. Но тем не менее он чаще прав чем нет.
> Деликатности ему времееами не хватает, это да. Но тем не менее он
> чаще прав чем нет.И доказательство его правоты - это ... ?
здравый смысл + опыт
Я правильно понял, что всех его оппонентов вы так лихо записали в неопытных неадекватов? Например, дедушку Танненбаума, куда уж ему профессоришке до его величества.
> Я правильно понял, что всех его оппонентов вы так лихо записали в
> неопытных неадекватов? Например, дедушку Танненбаума, куда уж ему профессоришке до его
> величества.Помнится все реформы обосновывались профессорами и академиками. Толку это не прибавило.
Кроме того Ноев ковчег построен любителем, а профессионалами построен Титаник.
И еще, на Украине "Проффесор" в президентах, толку с этого маловато.
ЗЫ Миникс уже много где используется, кроме обучательных целей? Нет? Ну нам не шашечки,нам ехать, а пока есть выбор и так, Линукс, *БСД, Соларис. Вот доведет до ума свою ОСь профессор, тогда и ее попользуем, а пока - сорри.
>Помнится все реформы обосновывались профессорами и академиками. Толку это не прибавило.уверен?
А то виллы на канарах с тех пор изрядно подорожали. :D
> уверен?
> А то виллы на канарах с тех пор изрядно подорожали. :DНу это какой-то слабый, негодный выхлоп.
> Кроме того Ноев ковчег построен любителем, а профессионалами построен Титаник.титаник построен алчными людьми, а не профессионалами. А Ноев(tm) ковчег пока что построен только на бумаге и пока он плавал с одного листа бумаги на другой успел вырасти из лодочки в Ноев(tm) ковчег.
> титаник построен алчными людьми, а не профессионалами. А Ноев(tm) ковчег пока что
> построен только на бумаге и пока он плавал с одного листа
> бумаги на другой успел вырасти из лодочки в Ноев(tm) ковчег.К тому же глупо винить создателей Титаника в ошибках команды моряков.
Чего бы это? Корабль утонул от столкновения с совсем небольшим куском льда, чего в общем то быть не должно, он даже не смог бы пережить сильный шторм. И все из-за того, что были нарушены технологии производства в спешке и погоней за "имиджем"
> Чего бы это? Корабль утонул от столкновения с совсем небольшим куском льда,
> чего в общем то быть не должно, он даже не смог
> бы пережить сильный шторм. И все из-за того, что были нарушены
> технологии производства в спешке и погоней за "имиджем"Ложь и провокация. Википедия негодуе: http://ru.wikipedia.org/wiki/%D0%A2%D0%B...
вы кроме википедии ещё что-нибудь читаете?
> вы кроме википедии ещё что-нибудь читаете?Ну конечно не читаю. Всегда читал только википедию, сколько себя помню. Это всё, что вас интересует? Ну тогда расходимся. Очевидно, по существу вам всё равно нечего сказать.
>> Чего бы это? Корабль утонул от столкновения с совсем небольшим куском льда,
>> чего в общем то быть не должно, он даже не смог
>> бы пережить сильный шторм. И все из-за того, что были нарушены
>> технологии производства в спешке и погоней за "имиджем"
> Ложь и провокация. Википедия негодуе: http://ru.wikipedia.org/wiki/%D0%A2%D0%B...Педивикия?, - фу какая чушь.
Бережных
Самые большие кораблиЛев Скрягин
"Последний SOS Вольтурно"Белкин
Голубая лента АтлантикиЗЫ
Лайнер "Олимпик"
>> ЗЫ
> Лайнер "Олимпик"И причем тут Олимпик? Теория заговора?
>>> ЗЫ
>> Лайнер "Олимпик"
> И причем тут Олимпик? Теория заговора?При чем тут теория заговора?
Однотипное судно.
После столкновения с плавучим маяком около Нью Йорка затонуло.Мне и дальше книжку с клавиатуры копипастить?
Однотипные суда Олимпик, Титаник и иже, по-определению не могли быть непотопляемыми.
Тут Скрягина надо читать. Толковый мужик. Хорошо пишет.
И "Голубая лента Атлантики" лишь довершила дело.
И лучше бы Титаник перед рейсом столкнулся бы с судном. У берега, рядом. И рейс бы отменили и люди бы остались живы. Мож и комиссия по техсостоянию заработала бы.
>>>> ЗЫ
>>> Лайнер "Олимпик"
>> И причем тут Олимпик? Теория заговора?
> При чем тут теория заговора?При том, что Олимпик в связи с Титаником чаще всего в контексте теории заговора вспоминают.
> Однотипное судно.
> После столкновения с плавучим маяком около Нью Йорка затонуло.А при чем тут это?
> Мне и дальше книжку с клавиатуры копипастить?
> Однотипные суда Олимпик, Титаник и иже, по-определению не могли быть непотопляемыми.При условии пробития борта у двух подряд отсеков суда таки непотопляемы. Н вот то, что на скорости айсберг/судно протаранят борт на большую длину проектировщики не подумали.
> Тут Скрягина надо читать. Толковый мужик. Хорошо пишет.
> И "Голубая лента Атлантики" лишь довершила дело.
> И лучше бы Титаник перед рейсом столкнулся бы с судном. У берега,
> рядом. И рейс бы отменили и люди бы остались живы. МожС чего бы отменять? Олимпик получил повреждения на ходовых испытаниях, столкнувшись с крейсером, а Титаник проблем не имел.
> и комиссия по техсостоянию заработала бы.
Ничего бы это не дало. Титаник погиб изза сочетания нескольких ошибок.
> При условии пробития борта у двух подряд отсеков суда таки непотопляемы. Н вот то, что на скорости айсберг/судно протаранят борт на большую длину проектировщики не подумали.У Титаника не было пробития корпуса в таких масштабах, был всего лишь небольшой удар в одном месте от которого лавинно разошлись хреново склёпанные швы на большой протяжённости. Он был обречён на скорую гибель при первой же серьёзной "встряске".
> При том, что Олимпик в связи с Титаником чаще всего в контексте
> теории заговора вспоминают.Там не в теории заговора дело.
Голубая лента Атлантики слишком большой куш.>> Однотипное судно.
>> После столкновения с плавучим маяком около Нью Йорка затонуло.
> А при чем тут это?При том, что для обеспечения живучести корабля, нужен не только двойной корпус, не только водонепроницаемые переборки, но и герметично задраиваемые палубные люки и шахты, чего не было.
Много из того, на что ссылается википедия, это официальный рекламный финт тех времён.
Скрягин об этом упоминает.>> Однотипные суда Олимпик, Титаник и иже, по-определению не могли быть непотопляемыми.
> При условии пробития борта у двух подряд отсеков суда таки непотопляемы. Н
> вот то, что на скорости айсберг/судно протаранят борт на большую длину
> проектировщики не подумали.Там было еще хуже. Наборщик из меня никакой, но если интересует:
"Последний SOS Вольтурно" (хардбук) стр53 со слов:
"Две носовые и пять кормовых" ...
Этот гроб просто не мог не затонуть.
"Олимпик" лишь повторил судьбу своего "кровного брата".
В Аквитании, спущенной годом позже, многое улучшили.
...как это знакомо: думать задним числом.>> И "Голубая лента Атлантики" лишь довершила дело.
>> И лучше бы Титаник перед рейсом столкнулся бы с судном. У берега,
>> рядом. И рейс бы отменили и люди бы остались живы. Мож
> С чего бы отменять? Олимпик получил повреждения на ходовых испытаниях, столкнувшись с
> крейсером, а Титаник проблем не имел.При столкновении судов идущих параллельным курсом это столкновение несущественно.
Эффект присасывания.
Титаник в Саутхемптоне разошелся с кормой "Нью Йорк"а тремя метрами.... "Хок" и U-103, - эти лайнеры буквально притягивали к себе неприятности.
>> и комиссия по техсостоянию заработала бы.
> Ничего бы это не дало. Титаник погиб изза сочетания нескольких ошибок.Угу. Он был обречён изначально...
Ходовые испытания Титаника провернули всего за восемь часов!
И да: "полный назад" - значительно снижает эффективность работы пера руля.И этих "если бы" настолько много, что поневоле можно поверить в мистику.
Морган Робертсон и его ранее (катастрофы) написанный роман "Тщетность", до мельчайших подробностей описавший катастрофу "Титан", был проклят и никогда потом не переиздавался.
Он того же проекта что и Титаник.
> Педивикия?, - фу какая чушь.Вы или приведите ссылку на материалы в сети, где на основании анализа фактов сделаны выводы в том, что в крушении Титаника виноваты его создатели, или приведите цитаты из книг (и пусть они опираются на что-либо, помимо отдельных мнений и домыслов). А то получается, что в википедии чушь, и доказательство тому - перечисление названий и авторов.
>> Педивикия?, - фу какая чушь.
> А то получается, что в
> википедии чушь, и доказательство тому - перечисление названий и авторов.Если быть более точным, там выжимка.
> Вы или приведите ссылку на материалы в сети, где на основании анализа
Да не читаю я материалы в сети кроме документации по ОСям. Поэтому ссылки не будет.
Книжки. В твердом и мягком переплёте. Включая раритеты.Ну новости ещё на bbc.co.uk/russian
> Чего бы это? Корабль утонул от столкновения с совсем небольшим куском льда,
> чего в общем то быть не должно, он даже не смог
> бы пережить сильный шторм. И все из-за того, что были нарушены
> технологии производства в спешке и погоней за "имиджем""В гибели Титаника виноваты евреи - Штурман, Боцман, Лоцман и Айсберг"(С)старый одесский анекдот.
Титаник не имел достаточного количества спасательных средств, шел в опасное время вдали от обычных маршрутов, пробития борта по длинне сразу нескольких отсеков никто не предусматривал. В результате сложения ошибок нескольких профессионалов имеем один утонувший корабель и один неутонувший фильм. так что на одни нарушения в технологии призводства списать катастрофу нельзя.
История кораблекрушений знает случаи когда судно брошенное командой и имеющее много бОльшие повреждения оставалось на плаву, но по воле обстоятельств (или провидения?) не могло быть отбуксированным в порт и ходило по морю как летучий голландец годами...
> Я правильно понял, что всех его оппонентов вы так лихо записали в
> неопытных неадекватов? Например, дедушку Танненбаума, куда уж ему профессоришке до его
> величества.А Вы внимательно читали его книгу про операционные системы? (напр.3-е издание).
Там очень интересно почитать про то, что он называет Windows операционной системой.
Я ничего не хочу сказать плохого, Вы сами почитайте...
Дедушка Танненбаум хардкорный теоретик и фантазёр. Здравый смысл в данном контексте = компромисс между теорией (фантазией) и фактической действительностью. Просто так напомню, мало кто из таких теоретиков смог свои идеи воплотить в жизнь и сделать при этиом нечто большее, чем мёртвый прототип или практически непригодную игрушку.Конечно, это не означает что Т. неадекват и его нужно закопать, просто он сам по себе со своим отношением к вопросу не самодостаточен без людей типа Л., которые могут рефлексировать на его теориях.
> Дедушка Танненбаум хардкорный теоретик и фантазёр. Здравый смысл в данном контексте =Хаха, теоретически фантазийные микроядерные ОС (QNX, LynxOS, vxWorks) работают там, куда линукс и на пушечный выстрел не подпустят. ;) Энергетика, ядерная энергетика, судоходство, авиация, оборонка, космос - отрасли теоретиков-фантазёров. ;)
> компромисс между теорией (фантазией) и фактической действительностью. Просто так напомню,
> мало кто из таких теоретиков смог свои идеи воплотить в жизньВсе идеи давно воплощены и работают. Их жизнеспособность - это факт, безразличный к расстановке беспомощных акцентов вида "мало кто из таких смог воплотить".
> и сделать при этиом нечто большее, чем мёртвый прототип или практически
> непригодную игрушку.Это вы кагбе намекаете на уровень вашей осведомлённости.
> Конечно, это не означает что Т. неадекват и его нужно закопать, просто
> он сам по себе со своим отношением к вопросу не самодостаточен
> без людей типа Л., которые могут рефлексировать на его теориях.Ха-ха. Торвальдс проигнорировал "теории" Таненбаума чуть более, чем полностью. В отличие от самого Таненбаума, который создал вполне реальную ОС со своей областью применимости. Не для хомячков и е-ынтерпрайза (во всяком случае, пока).
> Хаха, теоретически фантазийные микроядерные ОС (QNX, LynxOS, vxWorks) работают там, куда линукс и на пушечный выстрел не подпустят. ;)Все эти перечисленные ОС RT, имеют узкоспециализированное приминение (RT системы) и на обычных задачах сливают чему только можно. Думаю, дальше тут обсуждать нечего коли вы не понимаете чем RT ос отличается от ОС общего назначения.
> Ха-ха. Торвальдс проигнорировал "теории" Таненбаума чуть более, чем полностью.
беги смотреть что такое рефлексия
> Все эти перечисленные ОС RT, имеют узкоспециализированное приминение (RT системы) и на
> обычных задачах сливают чему только можно. Думаю, дальше тут обсуждать нечего
> коли вы не понимаете чем RT ос отличается от ОС общего
> назначения.Мне действительно нечего обсуждать с человеком, который либо не следит за ходом разговора, либо стремиться перейти на личности, обобщая и доводя мои высказывания до абсурда.
>> Ха-ха. Торвальдс проигнорировал "теории" Таненбаума чуть более, чем полностью.
> беги смотреть что такое рефлексияСбегал ещё когда ты пешком под стол ходил.
> Ха-ха. Торвальдс проигнорировал "теории" Таненбаума чуть более, чем полностью.Микроядро, по состоянию на 86-й год, это не "теория", это банальность. Если вы посмотрите на исследовательские ОС того времени, подавляющее их число - микроядерные. Просто для поддержки быстрого микроядра нужны немного доработанные ЦП - с быстрым переключением контекста. Но мы то работаем на диком старье - ОС конца 60-х, набор инструкций ЦП - 70-е, внутренняя архитектура (RISC) - 80-е.
Естественно при этом, что железо не очень "тянет" банальности 80-х - микроядро. :-)
А так, см., к примеру, http://citkit.ru/articles/1216/
> Хаха, теоретически фантазийные микроядерные ОС (QNX, LynxOS, vxWorks)Где, для начала, миникс, от мистера главного теоретика?
> работают там, куда линукс и на пушечный выстрел не подпустят. ;)
> Энергетика, ядерная энергетика, судоходство, авиация, оборонка,
> космос - отрасли теоретиков-фантазёров. ;)Да вообще-то как минимум в космосе обычно работают довольно примитивные и дубовые процессоры, где не то что RTOS, а так, максимально упрощенный микрокод (фирмваре), посвященный своей задаче. Аналогично с авиацией - в вике разжевано устройство бортового компьютера одного из Боингов и как там резервирование сделано. Там про микроядра - ни звука. Зато рассказано про 2 разные архитектуры процессоров, 2 разных языка и 2 независимые команды которые писали код. Чтобы ни в коем случае одна и та же ошибка не могла вылезти сразу в обоих компьютерах.
> Все идеи давно воплощены и работают. Их жизнеспособность - это факт, безразличный
> к расстановке беспомощных акцентов вида "мало кто из таких смог воплотить".Ну и как, у вас на десктопе уже стоит QNX, VxWorks или хотя-бы minix? Кстати а чего это производитель VxWorks не только быражит линуксом с реалтаймными расширениями собственного допила, но и активно сватает его вместо VxWorks, как бы намекая что Vx устарел и особо развиваться уже не будет?
> Это вы кагбе намекаете на уровень вашей осведомлённости.
Дык миникс вон - был игрушкой и остался таковым, что не мешало Таненбауму исходить слюной в адрес Торвальдса больше всех.
> Ха-ха. Торвальдс проигнорировал "теории" Таненбаума чуть более, чем полностью.
> В отличие от самого Таненбаума, который создал вполне реальную ОС со своей
> областью применимости. Не для хомячков и е-ынтерпрайза (во всяком случае, пока).И где вы видели _применения_ миникса? Я видел ровно одно - обучение студентоты тому как [не]надо делать ОС. Дальше этого почему-то не пошло ;)
>> Хаха, теоретически фантазийные микроядерные ОС (QNX, LynxOS, vxWorks)
> Где, для начала, миникс, от мистера главного теоретика?А где, по-вашему, он должен быть?
> Да вообще-то как минимум в космосе обычно работают довольно примитивные и дубовые
> процессоры, где не то что RTOS, а так, максимально упрощенный микрокодЭто не так. Вот пример с первой страницы гугла по запросу NASA RTOS:
http://edageek.com/2007/03/19/nasa-mro-threadx-rtos/> (фирмваре), посвященный своей задаче. Аналогично с авиацией - в вике разжевано
Тоже заблуждение. В самолётах много сложного оборудования, которое уже давно не обходится примитивными контроллерами и прошивками. Вот пример:
http://www.rtsoft.ru/press/product/detail.php?ID=571Или здесь, скупо, в последнем абзаце:
http://www.qnx.com/solutions/industries/defense.html> устройство бортового компьютера одного из Боингов и как там резервирование сделано.
> Там про микроядра - ни звука. Зато рассказано про 2 разныеПомимо бортовых компьютеров в самолётах много другого оборудования, со своими процессорами и ОС.
> Ну и как, у вас на десктопе уже стоит QNX, VxWorks или
Стоял QNX, когда нужен был по работе, но к упомянутым сферам применения микроядерных ОСРВ это отношения не имеет.
> хотя-бы minix? Кстати а чего это производитель VxWorks не только быражит
> линуксом с реалтаймными расширениями собственного допила, но и активно сватает его
> вместо VxWorks, как бы намекая что Vx устарел и особо развиваться
> уже не будет?Не знаю. Это вопрос маркетингового плана к VxWorks, которая, кстати, куплена интелом три года назад. У LynuxWorks есть (или был?) свой дистрибутив линукса, но от LynxOS они отказываться не спешат.
>> Это вы кагбе намекаете на уровень вашей осведомлённости.
> Дык миникс вон - был игрушкой и остался таковым, что не мешало
> Таненбауму исходить слюной в адрес Торвальдса больше всех.Давайте без физиологизмов.
> И где вы видели _применения_ миникса? Я видел ровно одно - обучение
> студентоты тому как [не]надо делать ОС. Дальше этого почему-то не пошло
> ;)Не удивительно. Миникс создавался именно с этими целями: обучение студентов, что никак не умаляет достоинств микроядерной архитектуры и применимости для решения некоторых классов задач. Перечисленные ОСРВ тому пример.
>> Деликатности ему времееами не хватает, это да. Но тем не менее он
>> чаще прав чем нет.
>И доказательство его правоты - это ... ?фюзе - тормоз. Будете возражать? :D
Зыж
ещё раз повторю - это не доказывает того, что фузе не применим и не имеет право на существование.
Что собственно Торвальдс и даказал включив дцать версий насад фюзе (и кузе) в ведро.
> И доказательство его правоты - это ... ?... то что ядерный модуль NTFS быстрее FUSE реализации, например. Ваш капитан. Ну что вы такие тупые, право?
>> И доказательство его правоты - это ... ?
> ... то что ядерный модуль NTFS быстрее FUSE реализации, например. Ваш капитан.
> Ну что вы такие тупые, право?С логикой у тебя проблемы, капитан. На основании того, что "ядерный модуль NTFS быстрее FUSE реализации", Торвальдс делает далеко идущие выводы, будто относительно низкая скорость работы драйвера ФС - единственный критерий оценки (по шкале "игрушечности", ха). Тракторы и внедорожники тоже игрушки, потому что медленнее спорткаров - не более абсурдное высказывание.
>С логикой у тебя проблемы, капитан.а у вас со знаниями.
Реализация фс в юзерспейсе всегда и по любым техническим показателям будет хуже ядерной, как и copy_to_user всегда будет медленнее memcpy.
Что не значит что фюзе нельзя применять в силу других, не технических причин.
>>С логикой у тебя проблемы, капитан.
> а у вас со знаниями.Ути-пути. :)
> Реализация фс в юзерспейсе всегда и по любым техническим показателям будет хуже
Реализация ФС в юзерспейсе как минимум не отягощает ядро (монолитное, прошу заметить) дополнительным кодом, ошибки в котором чреваты сбоями или компрометацией всей системы. В отличие от ошибок в юзерспейс-драйвере, который, к тому же, доступен непривилегированным пользователям. И я даже не касаюсь реализации специализированных псевдофайловых систем, которым в ядре делать нечего by design.
> ядерной, как и copy_to_user всегда будет медленнее memcpy.
> Что не значит что фюзе нельзя применять в силу других, не технических
> причин.Ха-ха. Все твои рассуждения, капитан, сводятся к скорости работы, а вовсе не к "любым техническим показателям". Садись, два.
для реализации всего этого хозяйства как минимум нужен ещё один доп-буфер для пересылки данных, не считая проблем с переключением контекста выполнения и ароматности операций.
см. copy_to_user в учебниках для старших классов.
>ошибки в котором чреваты сбоями или компрометацией всей системы.без разницы откуда будет записан троян, из юзерспейса или ядра.
У фюзе масса приемуществ, но не эта. :D
> Реализация ФС в юзерспейсе как минимум не отягощает ядро (монолитное, прошу заметить)
> дополнительным кодом,Во первых, это уже давно модульный монолит, да еще и половина подсистем которого развиваются независимо и лишь изредка мержатся в майнлайн. Гит все-таки крутая штука, он позволяет уташить код себе, независимо допилить, а потом без большого гемора вернуть апстриму в удобном виде и мержануть в основную ветку.
> ошибки в котором чреваты сбоями или компрометацией всей системы.
Ошибки в драйвере файловой системы в любом случае чреваты ф**апом всей системы.
> В отличие от ошибок в юзерспейс-драйвере, который, к тому же, доступен
> непривилегированным пользователям.Как ни странно, я могу читать/писать на том с EXT4 под непривилегированным пользователем. Мне доступен драйвер EXT4, надо же.
> И я даже не касаюсь реализации специализированных
> псевдофайловых систем, которым в ядре делать нечего by design.Не знаю как там насчет псевдо, а вот тормозные недо-драйвера в фузе - задолбали. На больших потоках данных они проц грузят просто дико, при том существенной частью этого являются бесполезные переключения контекста. Если по вашему надо все вынести в юзермод - что ж вы еще не свалили на микроядра тогда? Там все дрова в юзермоде сразу по задумке.
> Ха-ха. Все твои рассуждения, капитан, сводятся к скорости работы,
Потому что тормозные системы - мало кому нужны. Реальная ОС это всегда компромисс между совокупностью параметров. Да, можно построить бетонный бункер которому не страшно прямое попадание ядерной ракеты, но обычные дома почему-то будут более популярны, хоть и рассыпаются от ядерного взрыва в пыль.
> Если по вашему надо все вынести в юзермод - что ж вы еще
> не свалили на микроядра тогда?Банально железо не тянет быстрое переключение контекста. Хотя, казалось бы, в любом процессоре метра 2 кеша - памяти хватает даже на то, чтобы линуксовое ядро 2.4 внутри ЦП держать :-).
> процессоре метра 2 кеша - памяти хватает даже на то, чтобы
> линуксовое ядро 2.4 внутри ЦП держать :-).Собственно думается наиболее горячие куски ядра прекрасно оседают в кеше :). А вот если как микроядро - постоянно контекстами щелкать и мотаться между всевозможными процессами, не только пользовательскими но и драйверными - думается, кеш прилично потравится и будет юзаться не особо оптимально.
> Собственно думается наиболее горячие куски ядра прекрасно оседают в кеше :). А
> вот если как микроядро - постоянно контекстами щелкать и мотаться между
> всевозможными процессами, не только пользовательскими но и драйверными - думается, кеш
> прилично потравится и будет юзаться не особо оптимально.Речь о том, что при немного другой архитектуре процессора все эти контекстные данные (значения регистров, состояния конвеера и т.д.) преспокойно можно хранить в ЦП - памяти же навалом! Просто х86-е делались до перехода микроядер в область банальностей. И там этого не предусмотрели. Здесь на Opennet'е приводился пример ЦП, в котором переключение контекста делалось одной инструкцией - переставлял указатель внутреннего массива регистров.
А фирм, которые как DEC делают компьютеры и ОС, нет, поэтому подогнать железо под требования ОС сейчас не особо могут. Вот и получается, что в Windows по данным Microsoft примерно 80% выпадений в синий экран из-за драйверов (по Линуксу я таких данных не видел, но у меня - в основном выпадало из-за видео). То есть, полноценное микроядро улучшило бы ситуацию со стабильностью раз в 5!
> То есть, полноценное микроядро улучшило бы ситуацию со стабильностью раз в 5!Почему не в 4, не в 10, а именно в 5? Если ещё учесть что 100% ошибок возникает с определённой частотой. Пусть, например, на каждые 10 операций возникает ошибка и пусть уменьшим кол-во ошибок в 4 раза (на ваши 80%). Общая надёжность (стабильность) улучшится всего лишь на 8%. Если брать реальные цифры, то улучшение стабильности будет измеряться долями процентов. И это только оцена сверху. Давайте сразу скажем что тру ядро улучшает стабильность в 50 или 1000 раз.
Если драйвер относится к числу необходимых для работы целевой системы, то ошибка драйвера в любом случае фатальна независимот от места её возникновения и особенно это касается критически важных систем где недопустима порча данных или некорректный отклик. Микроядро в основном помогает _замаскировать_ некоторые детские ошибки.
Фактически вопрос нажёдности/стабильности системы лежит в другой плоскости.
> Почему не в 4, не в 10, а именно в 5? Если
> ещё учесть что 100% ошибок возникает с определённой частотой.Это справедливое замечание. В данном случае, поскольку мы не знаем, насколько часто используются какие подсистемы, поэтому строго говоря, частоту ошибок не знаем. Поэтому хорошо, уточню - кол-во фатальных для системы ошибок уменьшится в 5 раз. Это всё равно, очень много.
Почему микроядро позволяет "замаскировать"? Наоборот, сейчас если драйвер пишет не туда, но система не вылетела, это ему сходит с рук. А когда, как в микроядре, пространство памяти драйвера изолировано, он вылетит, ОС его перезапустит, отправит сообщение об ошибке в драйвере. Т.е. возможностей отлаживать драйвера будет больше.
----------------
Вы помните программирование под DOS? Там если что вылетело, то непонятно, где же, в каком месте программы, случился "Access violation", и отлаживать оказывается тяжелее, чем в системах с защитой памяти.
> Поэтому хорошо, уточню - кол-во фатальных для системы ошибок уменьшится в 5 раз. Это всё равно, очень много.Всё равно это незначимая цифра для ОС, т.к. исправление % 80-90 не меняет значительно общую стабильность. Можно потратить кучу $ на исправление и не получить видимого эффекта. Можно поменять архитектуру приложения/ОС и тоже не увидеть общего улучшения стабильности. Именно общая стабильность в конечном счёте важна в эксплуатации, а не кол-во погашенных ошибок.
> Почему микроядро позволяет "замаскировать"? Наоборот, сейчас если драйвер пишет не туда, но система не вылетела, это ему сходит с рук. А когда, как в микроядре, пространство памяти драйвера изолировано, он вылетит,
Чего это вдруг он вылетит? Испортит точно так же структуры, но не ядра, а свои. И если сильно не повезёт, то тогда только будет аналог сегфолта и драйвер будет перегружен.
Пусть даже драйвер вылетит, например, дравйвер видео. Можно ли его вот так вот просто перегрузить на рабочей системе и при этом не нарушить работу прикладного ПО? Нельзя.
Можно ли точно так же поступить с драйверами ФС? Здесь так тем более поступить нельзя и похожая ситуация с большей частью драйверов. Эффекты от сбоя на всю систему чаще непрогнозируемы.
Либо пишите всю систему в расчёте на такие события, либо не получаете профита от изоляции. Клепать узкоспециализированные системы так можно, а системы общего назначения нельзя хотя бы из-за больших объёмов различного прикладного ПО и железа.
> Вы помните программирование под DOS? Там если что вылетело, то непонятно, где же, в каком месте программы, случился "Access violation"
Получит ваш драйвер в микроядре неожиданное сообщение от другого компонента и будет тоже самое - будете долго искать кто нагадил.
Это всего лишь убирает основную массу детских ошибок которых большинство в прикладном ПО и тем самым улучшает стабильность, но для относительно отлаженного системного ПО стабильность уже изменится на доли процентов и эффект может быть незаметен.
> Всё равно это незначимая цифра для ОС,Это как это - незначимая? Это же в 5 раз! В инженерии бьются за 10%!
Блин, в науке 5 раз - значимая величина, а в инженерии - тем более.> Чего это вдруг он вылетит? Испортит точно так же структуры, но не
> ядра, а свои.Хе. Своих-то значительно меньше, чем ядерных! Размер одного драйвера раз в 10-ть меньше, чем размер всего монолита - ядро + другие драйвера. Поэтому тут тоже вероятность вылетания будет очень велика.
> И если сильно не повезёт, то тогда только будет аналог сегфолта и драйвер будет перегружен.
Вы знаете, аналогичнейшая проблема с access violation в обычных программах - тоже, вылетает далеко не всегда. Но есть методы увеличить "хрупкость" программы - например закрывать область памяти сразу за стеком. Их используют и очень успешно. Но зачастую и без них валится.
> Пусть даже драйвер вылетит, например, дравйвер видео. Можно ли его вот так
> вот просто перегрузить на рабочей системе и при этом не нарушить
> работу прикладного ПО?Практика показывает, что таки в современных оконных системах можно. GDI-то отдельно от драйверов.
> Можно ли точно так же поступить с драйверами ФС?
См. Minix - да, порча данных может быть, но вы более чётко знаете, что она произошла. А сейчас в Линуксе, если драйвер фс засирает пространство ядра, но не вылетает, то вы ничего не узнаете.
> Получит ваш драйвер в микроядре неожиданное сообщение от другого компонента и будет
> тоже самое - будете долго искать кто нагадил.Ну микроядро - это же не панацея от всего. Сейчас, собственно, всё выглядит ровно так же.
> Это всего лишь убирает основную массу детских ошибок которых большинство в прикладном
> ПО и тем самым улучшает стабильность, но для относительно отлаженного системного
> ПО стабильность уже изменится на доли процентов и эффект может быть
> незаметен.Опыт Microsoft говорит, что драйверописатели совершают массу детских ошибок. Конечно, если бы можно было заставить писать драйвера под GPL или аналогом, было бы совсем круто. Но сейчас их даже исправить-то не всегда можно. Впрочем, и драйвера с открытым кодом - это то ещё, например, я долго мучался с Интеловским видео - вывешивало мою OpenSuse исключительно ловко. С микроядром этого бы не было.
> Это как это - незначимая? Это же в 5 раз! В инженерии бьются за 10%!- Петька, приборы.
- Десять!
- Чего десять?
- А чего приборы?Ну просто вылитый анекдот :)
Никто не бъётся в инженерии за десять, вы что-то путаете. Если специалист будет биться за десять в инженерии, то он долго в специальности не задержится. Заказчики люто не любят когда их $ расходуются на борьбу с неведомыми показателями.
> Блин, в науке 5 раз - значимая величина, а в инженерии - тем более.
Откуда такие шаблоны берутся? Наука слишком обширная область, есть области где разница в тысячи раз не играет роли, а есть где важны миллионные доли.
> Хе. Своих-то значительно меньше, чем ядерных! Размер одного драйвера раз в 10-ть меньше, чем размер всего монолита - ядро + другие драйвера. Поэтому тут тоже вероятность вылетания будет очень велика.
Между микроядром и монолитом есть ещё промежуточные варианты, в зависимости от архитектуры процессора возможны различные варианты изолязий в ядре (на i386 их, например. 4 штуки), ну и в конце концов в ядре применимы многие подходы из юзерспейса - виртуализация адресов и sparse аллокаторы групп страниц. Всё это в совокупности снижает вероятность попасть "нитуда" в разы.
И от размера драйвера ничего не зависит, испортить можно только динамические данные, а их объём зависит от подсистемы. Сетевой стек, например, на нагруженных каналах будет иметь огромнейшие размеры по сравнению со всем остальным.
> Ну микроядро - это же не панацея от всего. Сейчас, собственно, всё выглядит ровно так же.
По крайней мере это не решение проблем стабильности, тезис которым я начал эту подветку.
> Опыт Microsoft говорит, что драйверописатели совершают массу детских ошибок.
Опыт M$ интересует меньше всего. M$ это M$, а мир юниксоподобных ОС это ... совсем другое, с разными целями, моделями и подходами.
> С микроядром этого бы не было.
С микроядром вы бы имели мёртвые иксы, карточку в нерабочем программном состоянии и необходимость перезагрузки ОС. Всё тоже самое, разве что успели бы корретно выключить систему.
>> Реализация ФС в юзерспейсе как минимум не отягощает ядро (монолитное, прошу заметить)
>> дополнительным кодом,
> Во первых, это уже давно модульный монолит, да еще и половина подсистемМодульный он лишь в смысле наличия функций подгрузки/выгрузки кода.
> которого развиваются независимо и лишь изредка мержатся в майнлайн. Гит все-таки
Это не имеет никакого отношения к архитектуре ядра.
> крутая штука, он позволяет уташить код себе, независимо допилить, а потом
> без большого гемора вернуть апстриму в удобном виде и мержануть в
> основную ветку.А в Киеве дядька. Я понимаю, вы в восторге после знакомства с DVCS, но дышите глубже - git здесь ни при чём.
>> ошибки в котором чреваты сбоями или компрометацией всей системы.
> Ошибки в драйвере файловой системы в любом случае чреваты ф**апом всей системы.FUSE-драйвер - пользовательский процесс. В чём же этот неуловимый нюанс, который ставит стабильность системы в зависимость от пользовательского процесса? Не поясните?
>> В отличие от ошибок в юзерспейс-драйвере, который, к тому же, доступен
>> непривилегированным пользователям.
> Как ни странно, я могу читать/писать на том с EXT4 под непривилегированным
> пользователем. Мне доступен драйвер EXT4, надо же.Доступен для монтирования без помощи setuid-root/capable программ? Продолжайте изливать чушь и победно развенчивать неправдоподобные глупости, которые вы от избытка ума углядываете в моих словах. Это забавно. :)
>> И я даже не касаюсь реализации специализированных
>> псевдофайловых систем, которым в ядре делать нечего by design.
> Не знаю как там насчет псевдоКто бы мог подумать.
> а вот тормозные недо-драйвера в фузе
> - задолбали. На больших потоках данных они проц грузят просто дико,А вы ножками поусерднее посучите - прибегут разработчики и бесплатно перепишут вам драйвер.
> при том существенной частью этого являются бесполезные переключения контекста. Если по
> вашему надо все вынести в юзермод - что ж вы ещеА то. Взять вот так всё и вынести разом. :) Я прямо устал повторять. ;)
> не свалили на микроядра тогда? Там все дрова в юзермоде сразу
> по задумке.Может быть потому, что не считаю микроядерность единственно верным критерием? ;)
> Потому что тормозные системы - мало кому нужны. Реальная ОС это всегда
Вы хотите сказать, что я на микроядра не свалил, потому что они тормозят? ;) Больше ничего не хотите сказать? ;)
> компромисс между совокупностью параметров. Да, можно построить бетонный бункер которому
> не страшно прямое попадание ядерной ракеты, но обычные дома почему-то будут
> более популярны, хоть и рассыпаются от ядерного взрыва в пыль.Что не отменяет полезности бункеров для решения некоторых задач и не говорит о том, что бункеры - игрушки, а их пользователи заблуждаются. ;)
> Модульный он лишь в смысле наличия функций подгрузки/выгрузки кода.Да как сказать, ряд подсистем относительно независимо разрабатывается.
> Это не имеет никакого отношения к архитектуре ядра.
Это еще как сказать. Одна большая работа пилится на много относительно небольших и независимых, что позволяет им вполне адекватно разрабатывать этого монстрика. Это не столько архитектура ядра, сколько архитектура распределенной разработки, но границы задач пролегают по подсистемам ядра. Поэтому насчет "никакого" вы загнули.
> DVCS, но дышите глубже - git здесь ни при чём.
Деление на задачи пролегает по неким вполне себе архитектурным границам :). Дело даже не столько в DVCS сколько в том что именно гит позволяет довольно удобно бранчить и мержить. Без него такой стиль работы был бы просто невозможен. А тут - пожалуйста, каждый пилит себе в своей норе свою подсистему и доволен жизнью.
> FUSE-драйвер - пользовательский процесс. В чём же этот неуловимый нюанс, который ставит
> стабильность системы в зависимость от пользовательского процесса? Не поясните?Капитан объясняет: если от доступа обрабатываемых этим драйвером данным зависела работа каких-то программ, они оставшись например без доступа к данным или получив что-то левое или обломавшись записать в файл, скорее всего просто испытают массу глюков или упадут или аварийно завершатся. А что например должен делать процесс БД облажавшись записать транзакцию в журнал? Как минимум фэйлануть запрос, а скорее всего и вообще завершить работу, чтобы минимизировать возможные разрушения.
Более жестокий и жизненный пример: а что если на этой ФС был своп? Вообще, идея совместно использовать один своп с виндой на нтфсном томе - имеет право на жизнь: а зачем вам два свопа? :) А теперь прикиньте, случился page fault, а своп файл не прочитался или прочитался мусор. Как вы думаете, что будет дальше? Правильно, в этом случае процесс FUSE драйвера одной левой может нагнуть всех :).
Хинт: доступ к файловой системе - это практически половина доступа к ОС :)
>> Как ни странно, я могу читать/писать на том с EXT4 под непривилегированным
>> пользователем. Мне доступен драйвер EXT4, надо же.
> Доступен для монтирования без помощи setuid-root/capable программ?А административные операции - они для админов, вы прикиньте?! Позволить любому болвану перекраивать структуру файловой системы в многопользовательской многозадачной ОС - потом костей не соберешь. Может мы вообще отменим нафиг права доступа к ФС и пускай первый же хомяк своим rm -rf /* кладет всю систему, а? Ну тогда вам в Win95, там как раз никаких заморочек с правами доступа нет.
> Продолжайте изливать чушь и победно развенчивать неправдоподобные глупости,
> которые вы от избытка ума углядываете в моих словах. Это забавно. :)Может мозги у вас и есть, но вот троллить вы совершенно не умеете :P. На такой жирный троллинг не поведется даже школота.
> А вы ножками поусерднее посучите - прибегут разработчики и бесплатно перепишут вам драйвер.
Мне проще пользоваться нормальными ФС с ядерными драйверами оказалось. А вы можете сучить ножками, ручками или чем там вам удобнее, ждать разработчиков и что там еще.
> А то. Взять вот так всё и вынести разом. :) Я прямо устал повторять. ;)
Ну так это уже давно реализовано в микроядерных всяких. Пользуйтесь наздоровье - там ядро вообше примитивный менеджер ресурсов по сути, и все. А драйвера напишете себе сами. Ну, линуксных разработчиков - устравивает их работа, видимо. Если бы это было не так - они бы писали драйвера под что-нибудь еще. Однако они инженеры а не теоретики, поэтому когда концептуальная чистота мешает эффективности реализации, они не стесняются послать все эти концепции к чертям (в *bsd :P) и сделать так как лучше работает. За что их продуктом все и пользуются, если вы еще не поняли.
> Может быть потому, что не считаю микроядерность единственно верным критерием? ;)
Ну, линукс делает команда инженеров, а не академиков. И он будет системой эффективной на практике, а не стройной в теории. У теоретиков по этому поводу баттхерт, но это никого кроме них особо не волнует.
> Вы хотите сказать, что я на микроядра не свалил, потому что они
> тормозят? ;) Больше ничего не хотите сказать? ;)А чего тут говорить то, графики загрузки фузевым NTFS драйвером проца сами все скажут, доходчивее некуда. Если такой здец будет с КАЖДЫМ драйвером - в системе работать будет просто невозможно.
> Что не отменяет полезности бункеров для решения некоторых задач и не говорит
> о том, что бункеры - игрушки, а их пользователи заблуждаются. ;)Нет, бункеры - не игрушки. А вот те кто строит бункеры не только с поводом но и без - страдают фигней, да. О чем Торвальдс и сказал. Просто число копающих себе бункеры стало как-то непропорционально задачам где они могли бы пригодиться.
>> Модульный он лишь в смысле наличия функций подгрузки/выгрузки кода.
> Да как сказать, ряд подсистем относительно независимо разрабатывается.Прямым текстом: это не имеет отношение к архитектуре ядра. Ядро - монолит, с общим адресным пространством для всех нитей. Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.
>> Это не имеет никакого отношения к архитектуре ядра.
> Это еще как сказать.Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.
> не столько архитектура ядра, сколько архитектура распределенной разработки, но границы
Это нисколько не архитектура ядра. Это организация процесса разработки.
> Деление на задачи пролегает по неким вполне себе архитектурным границам :). Дело
И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?
>> FUSE-драйвер - пользовательский процесс. В чём же этот неуловимый нюанс, который ставит
>> стабильность системы в зависимость от пользовательского процесса? Не поясните?
> Капитан объясняет: если от доступа обрабатываемых этим драйвером данным зависела работа
> каких-то программ...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но не всей системы. При этом после краха FUSE-драйвера ядро вернёт ошибки в ответ на сисколы процессов-клиентов раздела, и у последних будет как минимум возможность обработать эти ошибки и завершить работу.
Теперь, как события развиваются после сбоя ядерного драйвера.
В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение данных на других разделах) или полная компрометация системы (в случае эксплуатации ошибки-уязвимости).
В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей системы. При этом процессы-клиенты раздела при любом обращении к разделу уходят в контекст ядра без возможности обработать ошибки, быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL на них тоже не действует). При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.
> Более жестокий и жизненный пример: а что если на этой ФС был
> своп? Вообще, идея совместно использовать один своп с виндой на нтфсномПример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.
> томе - имеет право на жизнь: а зачем вам два свопа?
Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных задач. Кстати, по критерию скорости, который все вы так любите.
> Хинт: доступ к файловой системе - это практически половина доступа к ОС
> :)Ну кто бы мог подумать!
> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?
> перекраивать структуру файловой системы в многопользовательской многозадачной ОС - потом
> костей не соберешь. Может мы вообще отменим нафиг права доступа кВы не представляете себе модель привилегий доступа к FUSE. Позорьтесь дальше, продолжайте эту добрую традицию.
> ФС и пускай первый же хомяк своим rm -rf /* кладет
> всю систему, а? Ну тогда вам в Win95, там как раз
> никаких заморочек с правами доступа нет.А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть 95-ой, хоть 3.10-ой.
> Может мозги у вас и есть, но вот троллить вы совершенно не
> умеете :P. На такой жирный троллинг не поведется даже школота.А я и не троллю. Мне просто нравится наблюдать беспомощность некомпетентных выскочек без знания предмета, чувства собственного достоинства и уважения к собеседнику.
> Мне проще пользоваться нормальными ФС с ядерными драйверами оказалось. А вы можете
> сучить ножками, ручками или чем там вам удобнее, ждать разработчиков и
> что там еще.Вы предыдущий комментатор? Его, видите ли, задолбали FUSE-драйверы, за которые он не выложил ни копейки. Предложение посучить ножками адресовано ему.
>> А то. Взять вот так всё и вынести разом. :) Я прямо устал повторять. ;)
> Ну так это уже давно реализовано в микроядерных всяких. Пользуйтесь наздоровье -</sarcasm></smileys>
> там ядро вообше примитивный менеджер ресурсов по сути, и все. А
> драйвера напишете себе сами. Ну, линуксных разработчиков - устравивает их работа,
> видимо. Если бы это было не так - они бы писалиВы отвечаете на собственные глупости. Претензий к разработчикам по этой части у меня нет.
>> тормозят? ;) Больше ничего не хотите сказать? ;)
> А чего тут говорить то, графики загрузки фузевым NTFS драйвером проца сами
> все скажут, доходчивее некуда. Если такой здец будет с КАЖДЫМ драйверомСразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости", о котором все говорят - это 10-20%, не более, даже на микроядерных ОС реального времени.
> - в системе работать будет просто невозможно.
Размахивайте руками. Убеждайте окружающих. Это забавно.
> Нет, бункеры - не игрушки. А вот те кто строит бункеры не
> только с поводом но и без - страдают фигней, да. ОНапоминаю, что Торвальдс, как обычно, не делал никаких оговорок в духе "а вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые считают FUSE ФС чем-то большим, чем игрушки.
> чем Торвальдс и сказал. Просто число копающих себе бункеры стало как-то
> непропорционально задачам где они могли бы пригодиться.Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его несуществующими подробностями.
> Прямым текстом: это не имеет отношение к архитектуре ядра. Ядро - монолит,
> с общим адресным пространством для всех нитей.Более того, практически все остальные ОС общего применения обладают теми же свойствами. Это же относится и к WinNT, и к *BSD и к кому там еще. Полтора экзота на пятке АЭС в мире - великолепно! Проблемка только в том что у меня нет АЭС. И даже спутника.
> Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.
Ошибки в ядре и драйверах всегда чреваты неприятными последствиями. Если даже вынести драйвер ФС в юзерспейс, он, имеючи низкоуровневый доступ к диску, может внести на диск любые изменения в ФС, включая и нежелательные. Например, изменение конфигурации ОС и сервисов оной, подпихивание в нужные моменты времени не тех файлов и данных что ожидалось, подделка записей в ACL, и так далее. По сути поломаный драйвер ФС - это открытые ворота в ОС, как ни крути.
> Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.
А вам, видимо, хочется меня потроллить? Или зачем вы так демонстративно тупите, как будто не понимаете что если я получил полный доступ к тому через баг в драйвере - я уже царь и бог. Особенно в posix-like, где "everything is a file".
> Это нисколько не архитектура ядра. Это организация процесса разработки.
Организация процесса разработки связана с делением по архитектурным границам.
> И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?
По различным подсистемам являющим более-менее самостоятельные сущности.
> ...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но
> не всей системы.В случае проблем чтения своп-файла проблемы с стабильностью будут system-wide, например. Потому что внезапно, драйвер в пользовательском режиме, запросто сможет порушить не только данные другим процессам, но и даже всю выгруженную в своп память.
> При этом после краха FUSE-драйвера ядро вернёт ошибки
> в ответ на сисколы процессов-клиентов раздела, и у последних будет как
> минимум возможность обработать эти ошибки и завершить работу.Ну да, щаз. Если не прочелся например своп, процесс словит page fault -> не получилось прочесть страницу -> процесс умирает. Без внятных шансов это обработать. Сложно что-то обрабатывать, когда в мозг воткнулся лом.
> Теперь, как события развиваются после сбоя ядерного драйвера.
> В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение
> данных на других разделах)В хучшем случае, то же самое будет и в случае FUSE драйвера побившего своп-файл на своей ФС, например. Более того, скомпрометированный драйвер ФС может внаглую инжектить в своп любые произвольные данные, произвольно перекраивая работу всех остальных процессов, которых угораздило попасть в своп. По сути - это полное поимение ОС со всеми потрохами. Аналогично, при чтении бинарей, скомпрометированный драйвер может например тело вируса в каждый файл подшивать, или что там ему угодно.
> или полная компрометация системы (в случае эксплуатации
> ошибки-уязвимости).Знаете, если драйвер скомпрометирован и вернет вам при чтении бинаря не бинарь а вирусяку - хрен вы это оспорите, даже если это FUSE'вый драйвер сделал. Аналогично, драйвер может на лету патчить своп на своем томе с целью получения управления в рамках всех остальных частей системы, может оверрайдить записи ACL на томе в пользу себя и хозяина малвари, etc. А кто ему запретит то? Если он разбирает эти структуры, он же и соврать при этом остальной части ОС запросто может. И это может иметь далеко идущие последствия. Более того, обычно в CPU аппаратная изоляция кернела от юзера сделана куда более кардинально чем юзера от юзера.
> В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности
> удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей
> системы.Простите, а если драйвер FUSE напортачит и сольет битые данные на свой том - чем это неконсистентное состояние ФС будет отличаться от того что выше?
> При этом процессы-клиенты раздела при любом обращении к разделу уходят
> в контекст ядра без возможности обработать ошибки,То что вы описываете - баг ядра. А приколитесь, что будет если драйвер FUSE получит запрос "запишите мне 20 байтов в файл по смещению 0x100500" и ... повиснет? Как абсолютный максимум, драйвер можно пристрелить по таймауту. Но при этом том скорее всего будет основательно испорчен, особенно если таймаут случится в тот момент когда драйвер что-то делал и например оборудование решило стормозить. Ну может диск там минуту бэд ремапал, пытаясь его подчитать. Никто нам не гарантирует за сколько жесткий диск нашу команду смолотит.
> быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL
> на них тоже не действует).Ну вообще-то взвис в драйвере - это баг. Даже не столько драйвера ФС, сколько драйвера работающего с железкой. Правильная реакция - задетектить что железо померло и вернуть ошибку. Кстати, а часто у вас драйвера ФС все вешали? Я вообще видел только 1 раз OOPS в драйвере ФС, при том это был сырейший драйвер btrfs, год назад примерно. В результате упал процесс который вызвал оопс. И все. Отсюда мораль: криворуким обезьянам нечего делать в драйверах ФС. Вообще. Они с пользовательскими данными работают, поэтому сбои там попросту недопустимы. А кому нужна ОС, теряющая или разрушающая пользовательские данные? :)
> При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить
> страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.А вы хоть раз на практике такое видели с драйверами из майнлайна, объявленных стабильными? Их в оопс то свалить - надо крепко постараться. Вот так и надо работать, потому что сбой в драйвере ФС в любом случае означает что пользователь потеряет свои данные. Доверять писать это кому попало? Спасибочки. Сами пользуйтесь сбоящими драйверами. А я буду пользоваться теми, которые не сбоят, не крашат систему и не виснут. Мне мои данные нужны не в виде вермишели размазанной по диску.
> Пример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.
Файловые системы применяются и так и сяк. Откуда вы заранее знаете как вообще будет применяться тот или иной драйвер? И кстати само допущение что сбой в драйвере - это что-то легитимное, допускает что потеря пользовательских данных за счет глюков драйвера почему-то считается штатным и допустимым явлением. А какого, собственно?
> Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных
> задач. Кстати, по критерию скорости, который все вы так любите.Для сколь-нибудь серьезных задач, очень редко но все-таки может потребоваться объем памяти превышающий физически доступный в системе. И, кстати, если уж мы о надежности, при нехватке памяти как минимум обломается 1 или несколько процессов, и еще не факт что они корректно переваривают нехватку памяти. А может и OOM киллер пройтись по расстрельному списку. Вы уж определитесь - или уж надежность, или уж скорость. А то какие-то двойные стандарты прямо.
>> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
> Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?Да, я слышал о разделении привилегий. Ну вот административные операции - они, внезапно, для административных пользователей. Например, рута. Или иных пользователей, которым теми или иными механизмами позволят делать те или иные привилегированные операции. Как именно это реализуется, через системных псевдопользователей, suid'ные флаги или какое-нибудь sudo - да вообще вопрос десятый и относится уже к конкретике реализации системы деления прав в той или иной ОС. При том ядру ОС чисто технически никто и ничто не мешает делить права так как они захотят. Просто они работают более-менее в рамках выбранной абстракции, POSIX и прочая. Там - вот так. Но если надо чтобы вон там бесправный лузер получил вон те права на монтирование тома и вдруг почему-то вам не понравились уже существующие рычаги воздействия и механизмы - ну поменяйте сорцы и пусть вон тому юзеру тоже можно будет юзать этот сискол. Законом не запрещено, законы природы не нарушает. Хотя почти наверняка эквивалентное деление прав можно реализовать какими-то менее варварскими методами. Например, засунув юзера в контейнер и дав ему там права "псевдорута". Ну и будет он рулить, но только в своем загончике, а остальным напакостить не сможет. И простая абстракция, и вполне эффективно.
> Вы не представляете себе модель привилегий доступа к FUSE.
> Позорьтесь дальше, продолжайте эту добрую традицию.И вас также.
> А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть
> 95-ой, хоть 3.10-ой.В лично моем понимании, ядро - отличное место для энфорсинга правил контроля доступа. Потому что от юзеров хорошо заизолировано. Драйвер ФС имеет дело с списками контроля доступа и подобными сущностями, собственно и определяющими кому и что льзя на вон той ФС. Стало быть - он вполне выглядит как часть ядра и как вполне логичный компонент в ядре.
> А я и не троллю. Мне просто нравится наблюдать беспомощность некомпетентных выскочек
> без знания предмета, чувства собственного достоинства и уважения к собеседнику.Да-да, вы не троллите, а только пытаетесь, довольно уныло, имхо. Местами тупя не хуже собеседников. Кстати, синдром Д`Артаньяна вам засчитан.
> Вы предыдущий комментатор? Его, видите ли, задолбали FUSE-драйверы, за которые он не
> выложил ни копейки. Предложение посучить ножками адресовано ему.Наверное я. Хотя я в этом рубилове уже потерялся слегка. Насчет копеек - не обязательно платить за товар/услугу/что там еще чтобы обсуждать их преимущества и недостатки. Если кому-то не нравится обсуждение недостатков их результата труда, есть ровно один способ: сделать так чтобы этих недостатков не было.
> Вы отвечаете на собственные глупости. Претензий к разработчикам по этой части у
> меня нет.Тогда какие к Торвальдсу претензии? С чем вы не согласны? С тем что FUSE дрова тормозят и жрут процессор? Так это бенчмарками и мониторами ресурсов проверяется на раз и результат получается совсем не в ползу FUSE почему-то.
> Сразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости",
> о котором все говорят - это 10-20%, не более, даже на
> микроядерных ОС реального времени.А вы какими микроядерными ОС пользовались, и под какими нагрузками получили 10-20% и все такое? А то почему-то FUSE'вый NTFS грузит проц раз в пять сильнее чем ядерный EXT4. И вечно норовит упереться в проц, а не диск почему-то. И чего б это вдруг?
> Размахивайте руками. Убеждайте окружающих. Это забавно.
Вай-вай. Вы тоже с забавлением окружающих имхо справляетесь. Ну вот например очередная попытка потроллить, не особо удачная, имхо :P.
>> только с поводом но и без - страдают фигней, да. О
> Напоминаю, что Торвальдс, как обычно, не делал никаких оговорок в духе "а
> вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые
> считают FUSE ФС чем-то большим, чем игрушки.По большому счету так оно и есть. Те кому надо было драйвера в юзермоде, линукс вообще не должны были использовать с самого начала. Если кому всерьез нужна изоляция дров друг от друга и он даже может научно обосновать это - им таким дорожка сразу в микроядерные системы явно. А если кто хочет по быстрому налабать кривой драйвер, абы как, своими индусами вместо профессиональных ядерных разработчиков - так таким проектам вообще место на кладбище, т.к. падучие драйвера, теряющие пользовательские данные, налабанные лишь бы побыстрее - это крайне сомнительное "достижение".
> Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его
> несуществующими подробностями.Ну так и правильно сказал, по большому счету. А дополнения были лишь в допущении что у собеседника есть мозги и он понимает, что если не было призыва вынести поддержку FUSE совсем, значит возможность "копания бункера" никто полностью отбирать не собирается. Но повертеть пальцем у виска - в своем праве, ага.
> Более того, практически все остальные ОС общего применения обладают теми же свойствами.
> Это же относится и к WinNT, и к *BSD и кНу вот и разобрались с модульностью.
>> Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.
> Ошибки в ядре и драйверах всегда чреваты неприятными последствиями. Если даже вынести
> драйвер ФС в юзерспейс, он, имеючи низкоуровневый доступ к диску, может
> внести на диск любые изменения в ФС, включая и нежелательные. Например,Вы говорите банальности. Зачем? Чтобы абстрактно обосновать равноценность рисков в случае FUSE и ядерных драйверов?
Вы видели мою аргументы касательно принципа разделения привилегий, надёжности (возможность перезапуска, обработки ошибок FUSE-драйвера и клиентов его раздела), возможности писать FUSE-драйверы на более надёжных языках?
> изменение конфигурации ОС и сервисов оной, подпихивание в нужные моменты времени
> не тех файлов и данных что ожидалось, подделка записей в ACL,
> и так далее. По сути поломаный драйвер ФС - это открытые
> ворота в ОС, как ни крути.Не по сути, а - в случае FUSE - в некоторых (!) ситуациях, когда драйвер отвечает за обслуживание разделов с такими файлами (настройки служб, ОС и т.п.). Устал объяснять.
Вы хотите по существу поговорить, или как соседний комментатор, беспредметно лить воду? Вопрос не риторический. Ответьте, пожалуйста.
>> Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.
> А вам, видимо, хочется меня потроллить? Или зачем вы так демонстративно тупите,Мне хочется поговорить по существу, но вы усердно не замечаете моих аргументов и - куда уж там! - не стремитесь получить уточнения. Вместо этого вы считаете, будто я "туплю", троллю и не знаю элементарных вещей. Вам нравится недопонимание? Если да, то продолжайте в том же духе. Если нет, читайте внимательнее, запоминайте и задавайте уточняющие вопросы. Вопросы!
> как будто не понимаете что если я получил полный доступ к
> тому через баг в драйвере - я уже царь и бог.Успешная эксплуатация уязвимости в ядерном драйвере - царь и бог. Эксплуатация уязвимости в FUSE-драйвере - доступ к данным, доступным FUSE-драйверу, с последствиями для клиентов его раздела, не более. Если привилегированные процессы не являются клиентами раздела (либо являются, но не доверяют его содержимому), то и компрометация драйвера не позволит вам повысить привилегии через манипуляции с файлами.
> Особенно в posix-like, где "everything is a file".
Перестаньте обобщать - дьявол в деталях. И мы придём к взаимопониманию.
>> Это нисколько не архитектура ядра. Это организация процесса разработки.
> Организация процесса разработки связана с делением по архитектурным границам.Я думал, с модульностью мы уже разобрались. Каким границам - вот вопрос. Ни логическое разделение на файлы, модули, подсистемы, ни возможность подгрузки/выгрузки модулей в рантайме - никак не влияют на такое архитектурное свойство ядра, как монолитность в смысле общего адресного пространства и совместного доступа к данным. Монолит.
Если вы хотите довести всё до абсурда и оспаривать терминологию, я пасс. Для глумления над невежеством мне вполне хватает соседнего товарища.
>> И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?
> По различным подсистемам являющим более-менее самостоятельные сущности.Что значит, самостоятельные сущности? Адресное пространство одно? Одно. Доступ к данным совместный? Совместный. Вот, что существенно для определения такого свойства, как монолитность.
>> ...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но
>> не всей системы.
> В случае проблем чтения своп-файла проблемы с стабильностью будут system-wide, например.
> Потому что внезапно, драйвер в пользовательском режиме, запросто сможет порушить не
> только данные другим процессам, но и даже всю выгруженную в своп
> память.Господи, как я устал от этих беспомощных, вырожденных примеров. Над ними можно лишь глумиться, не более. Вы этого от меня ждёте? Да, можно извернуться и использовать FUSE так, чтобы система встала раком, но можно не изворачиваться и использовать так, что при отказе FUSE-драйвера не только система, но и клиенты его раздела смогут возобновить работу в штатном режиме после сбоя. А внутриядерные драйверы в линуксе так использовать НЕЛЬЗЯ. Вот, в чём суть. Если же вам что-то не ясно, не талдычьте мне о банальностях - задайте уточняющий ВОПРОС. Будьте человеком.
>> При этом после краха FUSE-драйвера ядро вернёт ошибки
>> в ответ на сисколы процессов-клиентов раздела, и у последних будет как
>> минимум возможность обработать эти ошибки и завершить работу.
> Ну да, щаз. Если не прочелся например своп, процесс словит page faultА если не своп? Вас послушать, так все пользователи FUSE, на всех FUSE-разделах в системе хранят непременно свопы. Когда стоит задача повысить надёжность работы системы путём использования перезапускаемых FUSE-драйверов, КТО в здравом уме положит туда своп (который вообще не используется в большинстве таких случаев)? Не доводите до абсурда, если хотите разговора по существу.
>> Теперь, как события развиваются после сбоя ядерного драйвера.
>> В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение
>> данных на других разделах)
> В хучшем случае, то же самое будет и в случае FUSE драйвераНет, не то же самое. Ошибка в FUSE-драйвере не повлечёт за собой ни панику, ни зависание системы даже в худшем случае.
> побившего своп-файл на своей ФС, например. Более того, скомпрометированный драйвер ФС
> может внаглую инжектить в своп любые произвольные данные, произвольно перекраивая работуОпять своп... Ладно, в рамках одного сообщения. Но если продолжите всё сводить к этому абсурдному юз-кейсу, я выйду из разговора.
> это полное поимение ОС со всеми потрохами. Аналогично, при чтении бинарей,
> скомпрометированный драйвер может например тело вируса в каждый файл подшивать, или
> что там ему угодно.Не в каждый файл, а в каждый файл на данном разделе, у которого, в случае, когда FUSE используется для усиления защиты системы, не будет привилегированных клиентов, готовых запустить троян. Иначе теряется весь смысл разделения привилегий, понимаете?
> Знаете, если драйвер скомпрометирован и вернет вам при чтении бинаря не бинарь
> а вирусяку - хрен вы это оспорите, даже если это FUSE'вый
> драйвер сделал. Аналогично, драйвер может на лету патчить своп на своем*facepalm*
> томе с целью получения управления в рамках всех остальных частей системы,
> может оверрайдить записи ACL на томе в пользу себя и хозяина
> малвари, etc. А кто ему запретит то? Если он разбирает эти
> структуры, он же и соврать при этом остальной части ОС запросто
> может. И это может иметь далеко идущие последствия. Более того, обычноЗапретит ему архитектор системы безопасности, который в здравом уме и твёрдой памяти не станет класть на непривилегированный раздел "привигелированные" данные.
Если провести аналогию с chroot, наш разговор мог бы выглядеть так:
- chroot позволяет изолировать процессы от доступа к файлам вне chroot-окружения.
- chroot небезопасен, потому что если посадить в него процесс с правами root, то он сможет модифицировать систему.
- Это вырожденный случай, в котором chroot как механизм строгой изоляции неприменим. Но ведь я говорю о непривилегированных процессах, чувствуете разницу?
- Нет никакой разницы, потому что root может модифицировать систему, даже не имея доступа к внешним файлам, либо выбравшись из chroot.
- Но ведь я говорю о непривилегированных процессах!
- А если положить внутрь chroot-окружения своп-файл или файлы, которые запустят пользователи вне chroot-окружения, то процесс внутри chroot-окружения сможет эти файлы модифицировать и протроянить систему!
- *facepalm*> в CPU аппаратная изоляция кернела от юзера сделана куда более кардинально
> чем юзера от юзера.Скорее наоборот. В линуксе 2.6 процессы ядра работают в одном адресном пространстве с пользовательскими, разница лишь в уровне привилегий страниц.
>> В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности
>> удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей
>> системы.
> Простите, а если драйвер FUSE напортачит и сольет битые данные на свой
> том - чем это неконсистентное состояние ФС будет отличаться от того
> что выше?Тем, что если драйвер напортачил и упал, мы прогоняем по разделу fsck, исправляем ошибки, перезапускаем драйвер, и он снова в работе. А процессы-клиенты, даже если они попадали с ошибками при обращении к сбойному разделу, могут быть перезапущены без перезагрузки системы.
>> При этом процессы-клиенты раздела при любом обращении к разделу уходят
>> в контекст ядра без возможности обработать ошибки,
> То что вы описываете - баг ядра. А приколитесь, что будет если
> драйвер FUSE получит запрос "запишите мне 20 байтов в файл по
> смещению 0x100500" и ... повиснет? Как абсолютный максимум, драйвер можно пристрелить
> по таймауту. Но при этом том скорее всего будет основательно испорчен,Вот именно, что можно "пристрелить по таймауту". И даже если (а вовсе не скорее всего) раздел будет испорчен, по нему можно прогнать fsck, в том числе в автоматическом режиме (и в ручном, но всё так же без перезагрузки системы, если ошибки серьёзные), перезапустить драйвер, службы, и система заработает в штатном режиме.
> особенно если таймаут случится в тот момент когда драйвер что-то делал
> и например оборудование решило стормозить. Ну может диск там минуту бэд
> ремапал, пытаясь его подчитать. Никто нам не гарантирует за сколько жесткий
> диск нашу команду смолотит.А что нам мешает опрашивать драйвер на административном сокете и различать штатное ожидание с подвисанием или крахом драйвера? Даже однопоточный драйвер можно потрейсить и выяснить, в каком стостоянии он находится.
>> быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL
>> на них тоже не действует).
> Ну вообще-то взвис в драйвере - это баг. Даже не столько драйвера
> ФС, сколько драйвера работающего с железкой. Правильная реакция - задетектить чтоРечь не о взвисе, а о BUG'е, когда нить драйвера дала сбой, но ядро продолжило работу.
> железо померло и вернуть ошибку. Кстати, а часто у вас драйвера
> ФС все вешали? Я вообще видел только 1 раз OOPS вНе частно, но было дело. Приятного мало. Причём, все ошибки исключительно на ext2/3/4, поскольку другими ФС под линуксом пользоваться я не рискую - проще влить немного денег в железо и получить требуемый уровень производительности.
Последний раз ошибка была на Ext3-разделе с включёнными квотами в ядре то ли 2.6.29.х, то ли 2.6.30.х, и ошибка та была введена сразу в ДВЕ актуальные на то время стабильные ветки ядра, в рамках какого-то патча, связанного с работой Ext4.
При желании можете убедиться сами. Переберите несколько серединных стабильных версий 2.6.29.х или 2.6.30.х (в ранних .х ошибки ещё не было, в поздних .х её уже пофиксили). Создаёте раздел Ext3, включаете квоты, вызываете chmod на любой файл, и вуаля - раздел стоит колом, а все его клиенты намертво повисают в контексте ядра.
> драйвере ФС, при том это был сырейший драйвер btrfs, год назад
> примерно. В результате упал процесс который вызвал оопс. И все. Отсюда
> мораль: криворуким обезьянам нечего делать в драйверах ФС. Вообще. Они сВы только что наехали на разработчиков ядра, которые умудрились в две актуальные стабильные версии ядра портировать баг, созданный при работе над Ext4, который поймали пользователи стабильных (хе-хе) Ext3-разделов с квотами. ;) Помню, в IRC народ ещё долго поминал их добрым словом... ;)
> пользовательскими данными работают, поэтому сбои там попросту недопустимы. А кому нужна
> ОС, теряющая или разрушающая пользовательские данные? :)Правильно, никому не нужна. Поэтому ни один "массовый" дистрибутив не пользуется "стабильными" версиями ванильного ядра, а стабилизирует и выпускает собственные. ;)
>> При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить
>> страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.
> А вы хоть раз на практике такое видели с драйверами из майнлайна,
> объявленных стабильными? Их в оопс то свалить - надо крепко постараться.Как написал выше, видел. И не раз. Причём, в последний раз даже не пришлось интенсивно грузить систему круглые сутки (обычно при такой нагрузке баги и вылезают), а лишь включить квоты и сделать chmod. ;)
> Вот так и надо работать, потому что сбой в драйвере ФС
> в любом случае означает что пользователь потеряет свои данные. Доверять писатьОпять-таки, не каждый сбой влечёт потерю данных. Сохранность данных в ядерных драйверах, кстати, обеспечивается подсистемой журналирования, устойчивой к сбоям, и регулярными профилактическими прогонами fsck (обратите внимание - на интенсивно используемых разделах он иногда находит ошибки; чаще, кстати, это ошибки вовсе не критичные).
> это кому попало? Спасибочки. Сами пользуйтесь сбоящими драйверами. А я буду
> пользоваться теми, которые не сбоят, не крашат систему и не виснут.
> Мне мои данные нужны не в виде вермишели размазанной по диску.;)
>> Пример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.
> Файловые системы применяются и так и сяк. Откуда вы заранее знаете как
> вообще будет применяться тот или иной драйвер? И кстати само допущениеЕщё раз, на всякий случай... Сделать бесполезными можно практически любые инструменты обеспечения надёжности и безопасности (и вообще любые инструменты), если не уметь ими пользоваться. Низкая квалификация пользователя - проблема пользователя.
> что сбой в драйвере - это что-то легитимное, допускает что потеря
> пользовательских данных за счет глюков драйвера почему-то считается штатным и допустимым
> явлением. А какого, собственно?Да нету такого допущения. Есть уверенность, что любой, сколько-нибудь сложный код содержит ошибки и рано или поздно может дать сбой. Наличие возможности оперативного восстановления после сбоя - иногда приятный плюс, а иногда жёсткое требование. Всё зависит от сути и специфики конкретных задач.
>> Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных
>> задач. Кстати, по критерию скорости, который все вы так любите.
> Для сколь-нибудь серьезных задач, очень редко но все-таки может потребоваться объем памятиДа, иногда действительно проще раз в 3 года добавить своп и повозиться в системе, невзирая на деградацию качества обслуживания. Но это скорее исключение, чем правило. Я не понимаю, зачем вы вообще делаете на нём акцент. Факт остаётся фактом: в большинстве случаев увеличение используемой памяти через своп кардинально и неприемлемо снижает качество обслуживания.
> превышающий физически доступный в системе. И, кстати, если уж мы о
> надежности, при нехватке памяти как минимум обломается 1 или несколько процессов,В надёжных системах никто не доводит до нехватки памяти и необходимости включения свопа. А в ОСРВ свопа нет вообще, поскольку его наличие убило бы гарантии по времени реакции на события.
> и еще не факт что они корректно переваривают нехватку памяти. А
> может и OOM киллер пройтись по расстрельному списку. Вы уж определитесь
> - или уж надежность, или уж скорость. А то какие-то двойные
> стандарты прямо.Одно другому не мешает. Ещё раз: во избежание нехватки памяти в надёжной системе устанавливаются избыточные объёмы памяти, а вовсе не включается своп.
>>> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
>> Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?
> Да, я слышал о разделении привилегий. Ну вот административные операции - они,
> внезапно, для административных пользователей. Например, рута. Или иных пользователей,Выше я там пошутил на примере chroot, почитайте. Я вам про непривилегированных пользователей говорю, а вы мне про рута опять. *facepalm* ;)
> которым теми или иными механизмами позволят делать те или иные привилегированные
> операции. Как именно это реализуется, через системных псевдопользователей, suid'ные флаги
> или какое-нибудь sudo - да вообще вопрос десятый и относится уже
> к конкретике реализации системы деления прав в той или иной ОС.В плане безопасности вопрос первый, а вовсе не десятый. То, что FUSE позволяет монтировать разделы непривилегированным пользователям - это плюс. Не требуется как раз всех этих setuid-root бинарников и привилегированных служб - минус один потенциальный риск повышения привилегий до root через уязвимость в таких службах и бинарниках.
> При том ядру ОС чисто технически никто и ничто не мешает
> делить права так как они захотят. Просто они работают более-менее в
> рамках выбранной абстракции, POSIX и прочая. Там - вот так. НоИ зачем вы мне это объясняете? Выводы сделайте какие-нибудь уже. Если тут есть риторический смысл, я его не понял.
> если надо чтобы вон там бесправный лузер получил вон те права
> на монтирование тома и вдруг почему-то вам не понравились уже существующие
> рычаги воздействия и механизмы - ну поменяйте сорцы и пусть вон
> тому юзеру тоже можно будет юзать этот сискол. Законом не запрещено,А зачем мне что-то менять, без сторонней верификации этих изменений, без поддержки их в апстриме и т.п., когда в FUSE для монтирования пользовательских разделов уже всё есть? По сути вы предлагаете отказаться от стандартных удобств и изобретать велосипед.
> законы природы не нарушает. Хотя почти наверняка эквивалентное деление прав можно
> реализовать какими-то менее варварскими методами. Например, засунув юзера в контейнер
> и дав ему там права "псевдорута". Ну и будет он рулить,Зачем городить контейнеры и давать пользователю capabilites, активирующие, помимо кода монтирования разделов, и другие привилегированные code paths? Незачем.
> но только в своем загончике, а остальным напакостить не сможет. И
> простая абстракция, и вполне эффективно.Не вполне. Потому как attack surface более широк, а накладные расходы на реализацию более высоки.
>> Вы не представляете себе модель привилегий доступа к FUSE.
>> Позорьтесь дальше, продолжайте эту добрую традицию.
> И вас также.Ладно, не принимайте на свой счёт. Вы вроде бы, пока, пытаетесь говорить по существу.
>> А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть
>> 95-ой, хоть 3.10-ой.
> В лично моем понимании, ядро - отличное место для энфорсинга правил контроля
> доступа. Потому что от юзеров хорошо заизолировано. Драйвер ФС имеет делоВообще-то по современным меркам "заизолировано" плохо, ну да ладно. Ход мысли ясен.
> с списками контроля доступа и подобными сущностями, собственно и определяющими кому
> и что льзя на вон той ФС. Стало быть - он
> вполне выглядит как часть ядра и как вполне логичный компонент в
> ядре.Логичный, кто ж спорит. Вот только потенциальное наличие уязвимости в таком логичном драйвере обуславливает гораздо большие риски *в любом случае*. В отличие от FUSE-драйверов, изолированных в юзерспейсе, на базе которых можно строить более безопасные системы.
> Да-да, вы не троллите, а только пытаетесь, довольно уныло, имхо. Местами тупя
> не хуже собеседников. Кстати, синдром Д`Артаньяна вам засчитан.Да засчитывайте, сколько угодно. Волновала б меня оценка со стороны, я бы и до уровня таких разговоров опускаться постыдился, в принципе.
> Наверное я. Хотя я в этом рубилове уже потерялся слегка. Насчет копеек
> - не обязательно платить за товар/услугу/что там еще чтобы обсуждать их
> преимущества и недостатки. Если кому-то не нравится обсуждение недостатков их результата
> труда, есть ровно один способ: сделать так чтобы этих недостатков не
> было.Одно дело - оценивать, и другое - требовать соответствия своим критериям и с апломбом отвергать чужие, отличающиеся.
>> Вы отвечаете на собственные глупости. Претензий к разработчикам по этой части у
>> меня нет.
> Тогда какие к Торвальдсу претензии? С чем вы не согласны? С темУже озвучивал. Здесь: https://www.opennet.ru/openforum/vsluhforumID3/78554.html#183
> что FUSE дрова тормозят и жрут процессор? Так это бенчмарками и
Это не у меня такие претензии. :)) Это у господ хомячков, которые ничего, кроме своих потребностей к скорости, во внимание не принимают (как оказалось, патологически).
> мониторами ресурсов проверяется на раз и результат получается совсем не в
> ползу FUSE почему-то.Наверное потому, что FUSE действительно тормоз. Но моя-то позиция на том, что невзирая на просадку по скорости, FUSE применим для решения задач, в которых первостепенное значения имеют иные свойства (надёжность, безопасность, скорость и стоимость разработки, выбор инструментария).
>> Сразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости",
>> о котором все говорят - это 10-20%, не более, даже на
>> микроядерных ОС реального времени.
> А вы какими микроядерными ОС пользовались, и под какими нагрузками получили 10-20%QNX пользовался, лет 9 назад. Под пиковыми нагрузками на сетевые службы, в том числе с высокими pps. Разница с вылизанным линуксом 2.4 не превышала 20%.
> и все такое? А то почему-то FUSE'вый NTFS грузит проц раз
> в пять сильнее чем ядерный EXT4. И вечно норовит упереться в
> проц, а не диск почему-то. И чего б это вдруг?Наверное, потому, что переключений контекста в FUSE как минимум в два раза больше, чем в драйверах микроядерных ОС, а механизм IPC не отличается особой простотой и эффективностью? Вы ведь в ключе сравнения с микроядрами спросили? Не сравнивайте. FUSE абы как прибит к монолиту сбоку.
>> Размахивайте руками. Убеждайте окружающих. Это забавно.
> Вай-вай. Вы тоже с забавлением окружающих имхо справляетесь. Ну вот например очередная
> попытка потроллить, не особо удачная, имхо :P.Самое забавное, что это искренняя констатация факта, с малой надеждой на то, что она заставит собеседника задуматься. ;) "Троллю" я весьма по-своему и исключительно для себя.
>> вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые
>> считают FUSE ФС чем-то большим, чем игрушки.
> По большому счету так оно и есть. Те кому надо было драйвераНет никаких больших счетов. Есть. Отдельно. Взятые. Задачи. Всегда! Если стоит задача сделать сложный, надёжный, безопасный, верифицированный, покрытый тестами и относительно недорогой в разработке и сопровождении специализированный драйвер и при этом скорость работы (читай: аппаратные требования) вторична, то наиболее вероятный ответ - FUSE + <нужное вписать> (джава, ада, хаскелль и т.п.). Под ядро ничего подобного за сопоставимые деньги написать практически нельзя.
> в юзермоде, линукс вообще не должны были использовать с самого начала.
А что, есть другие ОС, с функциональностью как в линуксе, но микроядерные и всё прочее? Вообще, странно слышать такие заявления в контексте обсуждения FUSE, который в линуксе (и других юниксах) есть, поддерживается и используется. ;)
> Если кому всерьез нужна изоляция дров друг от друга и он
> даже может научно обосновать это - им таким дорожка сразу в
> микроядерные системы явно. А если кто хочет по быстрому налабать кривойА если нет подходящей системы? Например, по критерию стоимости и гомогенности (уже есть системы и команда линуксоидов) инфраструктуры на выходе? Если дешевле написать "тормозной" FUSE-драйвер и прикупить чуть больше железа?
> драйвер, абы как, своими индусами вместо профессиональных ядерных разработчиков - так
> таким проектам вообще место на кладбище, т.к. падучие драйвера, теряющие пользовательские
> данные, налабанные лишь бы побыстрее - это крайне сомнительное "достижение".А какое вам, вообще, дело, если они драйвер для себя пишут? И как я уже говорил, под FUSE как раз можно написать драйвер, который будет надёжнее, безопаснее, удобнее (разработка, сопровождение) и дешевле ядерного.
>> Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его
>> несуществующими подробностями.
> Ну так и правильно сказал, по большому счету. А дополнения были лишьНе видите ничего дурного в необоснованных обобщениях и переходе на личности в предметном разговоре? Ну так держать.
> в допущении что у собеседника есть мозги и он понимает, что
> если не было призыва вынести поддержку FUSE совсем, значит возможность "копанияВопрос прекращения поддержки FUSE здесь ни при чём.
> бункера" никто полностью отбирать не собирается. Но повертеть пальцем у виска
> - в своем праве, ага.Вертеть пальцем у виска в предметном разговоре - удел хамов. Имеют право, да.
Дельно. Аргументированно.> Вот именно, что можно "пристрелить по таймауту". И даже если (а вовсе
> не скорее всего) раздел будет испорчен, по нему можно прогнать fsck,
> в том числе в автоматическом режиме (и в ручном, но всё
> так же без перезагрузки системы, если ошибки серьёзные), перезапустить драйвер, службы,
> и система заработает в штатном режиме.А вот это для простого пользователя вообще ключевой момент.
> А вот это для простого пользователя вообще ключевой момент.Сарказм? Устал объяснять, что потребностями обычных пользователей юз-кейсы FUSE не исчерпываются. Кластерные ФС (многие из которых построены на FUSE) тоже простому пользователю не нужны. Давайте теперь похохмим о нужности кластерных ФС...
> Давайте теперь похохмим о нужности кластерных ФС...Разделить на десктопную и серверную ветки?
В частности, мне вот простому пользователю, NTFS, о необходимости которой так много говорили большевики, и на которую с самого начала делался акцент, ну совсем как бы ни к чему. Ни в каком виде.
И вряд ли это хоть когда-нибудь произойдёт.
> Устал объяснять, что потребностями обычных пользователей юз-кейсы FUSE не исчерпываются. Кластерные ФС (многие из которых построены на FUSE) тоже простому пользователю не нужны. Давайте теперь похохмим о нужности кластерных ФС...Все кластерные ФС, которые имеют fuse интерфейс, так же имеют библиотеки с помощью которых их можно использовать без POSIX прослойки. В случае кластерных распределённых ФС просто нет другого выхода, т.к. fuse просто не тянет возможные нагрузки. Нигде в серьёзном продакшене их не используют через FUSE.
> распределённых ФС просто нет другого выхода, т.к. fuse просто не тянет
> возможные нагрузки. Нигде в серьёзном продакшене их не используют через FUSE.Ложь и провокация.
> При желании можете убедиться сами. Переберите несколько серединных стабильных версий 2.6.29.х
> или 2.6.30.х (в ранних .х ошибки ещё не было, в поздних
> .х её уже пофиксили). Создаёте раздел Ext3, включаете квоты, вызываете chmod
> на любой файл, и вуаля - раздел стоит колом, а все
> его клиенты намертво повисают в контексте ядра.chown, а не chmod, конечно же. Баг воспроизводился сменой владельца при включённых квотах.
> С логикой у тебя проблемы, капитан. На основании того, что "ядерный модуль
> NTFS быстрее FUSE реализации", Торвальдс делает далеко идущие выводы,В отличие от вас Торвальдс понимает как работает его система и что переключения контекстов нахаляву не бывают. Скорость у всех виденных дисковых ФС в FUSE и правда довольно игрушечная, чего не скажешь о пожирании ими процессора. На быстром SATA диске такое может упереться в проц а не диск, что для драйвера ФС вообще-то позорный факт.
> будто относительно низкая скорость работы драйвера ФС - единственный критерий оценки
> (по шкале "игрушечности", ха).Это вполне хороший критерий. Кто не верит - возвращается к флопповодам и диалапным модемам и 80386 процессорам на целых 33МГц.
> Тракторы и внедорожники тоже игрушки, потому что медленнее спорткаров
> - не более абсурдное высказывание.То барахло которое в фузе крутится - на внедорожник и трактор как-то не тянет. Скорее на вспашку лошадьми. Потому что трактор - дорогой и сложный, ему ГСМ всякие надо. А лошадь чо, сено жрет и довольна, запряг и вперед. Логика тех кто фузешные тормозилки пишет. Не ну конечно туксера здорово придумала - написать тормозную замануху а потом переписать под кернелмод и за бабки, но как бы само существование такой бизнес-модели намекает на то что они считают что ядерный вариант - быстрее. Независимо от Торвальдса :))
>> С логикой у тебя проблемы, капитан. На основании того, что "ядерный модуль
>> NTFS быстрее FUSE реализации", Торвальдс делает далеко идущие выводы,
> В отличие от вас Торвальдс понимает как работает его система и чтоВ отличие от меня Торвальдс дал понять, что не признаёт критериев, кроме скорости работы, и что не оставляет людям право на суждения по критериям кроме скорости.
А вы продолжайте тешиться иллюзиями, будто ваш собеседник не знает элементарных вещей.
> переключения контекстов нахаляву не бывают. Скорость у всех виденных дисковых ФС
> в FUSE и правда довольно игрушечная, чего не скажешь о пожирании
> ими процессора. На быстром SATA диске такое может упереться в проц
> а не диск, что для драйвера ФС вообще-то позорный факт.Позорный факт - это ваше нежелание признавать иных критериев кроме скорости.
>> будто относительно низкая скорость работы драйвера ФС - единственный критерий оценки
>> (по шкале "игрушечности", ха).
> Это вполне хороший критерий. Кто не верит - возвращается к флопповодам и
> диалапным модемам и 80386 процессорам на целых 33МГц.Что значит, хороший критерий? Добрый и ласковый? Есть задачи, где важна скорость. Есть задачи, где важна стабильность, безопасность, скорость разработки, свобода выбора инструментария и адаптация удобных традиционных абстракций для решения нетрадиционных задач.
>> Тракторы и внедорожники тоже игрушки, потому что медленнее спорткаров
>> - не более абсурдное высказывание.
> То барахло которое в фузе крутится - на внедорожник и трактор как-то
> не тянет. Скорее на вспашку лошадьми. Потому что трактор - дорогой
> и сложный, ему ГСМ всякие надо. А лошадь чо, сено жрет
> и довольна, запряг и вперед. Логика тех кто фузешные тормозилки пишет.Это ваша логика. Причём, весьма любопытная. Но эффект от её чтения - как от чтения советских газет. Сразу становится ясно, какой ресурс на Руси не будет выработан в течение следующего века.
> Не ну конечно туксера здорово придумала - написать тормозную замануху а
> потом переписать под кернелмод и за бабки, но как бы
> само существование такой бизнес-модели намекает на то что они считают что
> ядерный вариант - быстрее. Независимо от Торвальдса :))Быстрее!!!1111111 Ага.
> В отличие от меня Торвальдс дал понять, что не признаёт критериев, кроме
> скорости работы, и что не оставляет людям право на суждения по
> критериям кроме скорости.В ядре? Вы забываете о чем шла речь в дискуссии, в которой были сказаны слова Торвальдса.
> А вы продолжайте тешиться иллюзиями, будто ваш собеседник не знает элементарных вещей.
Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не знает или намеренно вводит в заблуждение.
> Что значит, хороший критерий? Добрый и ласковый? Есть задачи, где важна скорость.
> Есть задачи, где важна стабильность, безопасность, скорость разработки, свобода выбора
> инструментария и адаптация удобных традиционных абстракций для решения нетрадиционных
> задач.Есть такие критерии, вот только из ваших критериев к ядру относятся лишь первые два кроме скорости работы - "стабильность, безопасность". А по ним ФУЗЕ не блещет в сравнении с ядерными ФС.
> В ядре? Вы забываете о чем шла речь в дискуссии, в которой
> были сказаны слова Торвальдса.В каком ядре? Речь шла о FUSE в том числе, и по единственному критерию скорости Торвальдс назвал его игрушкой.
> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
> знает или намеренно вводит в заблуждение.И каков же контекст, просветите?
> Есть такие критерии, вот только из ваших критериев к ядру относятся лишь
> первые два кроме скорости работы - "стабильность, безопасность". А по ним
> ФУЗЕ не блещет в сравнении с ядерными ФС.Все эти критерии "к ядру относятся". Есть два варианта: ядерный драйвер или FUSE-драйвер. Оцениваем...
1. Надёжность
Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы. Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего перезапуска.2. Безопасность
Уязвимости в ядерном драйвере (включая логические, как в ReiserFS) потенциально ведут к компрометации всей системы; в FUSE-драйвере - к компрометации процесса драйвера, привилегий отдельного пользователя (с которыми работает процесс) и хранимых данных. При этом FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.3. Скорость разработки и свобода выбора инструментария
Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого, неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более развитыми средствами профилирования, тестирования и отладки.4. Адаптация удобных традиционных абстракций
Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под FUSE.
>> В ядре? Вы забываете о чем шла речь в дискуссии, в которой
>> были сказаны слова Торвальдса.
> В каком ядре? Речь шла о FUSE в том числе, и по
> единственному критерию скорости Торвальдс назвал его игрушкой.Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных на FUSE, нельзя решить только за счет перемещения их кода в ядро".
Стало быть критерии оценки ФУЗЕ должны быть те же, что и к ядерным ФС. А по ним они сливают.>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>> знает или намеренно вводит в заблуждение.
> И каков же контекст, просветите?См. выше.
>> Есть такие критерии, вот только из ваших критериев к ядру относятся лишь
>> первые два кроме скорости работы - "стабильность, безопасность". А по ним
>> ФУЗЕ не блещет в сравнении с ядерными ФС.
> Все эти критерии "к ядру относятся". Есть два варианта: ядерный драйвер или
> FUSE-драйвер. Оцениваем...
> 1. Надёжность
> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
> перезапуска.Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственный пункт в понятии "надежность". Да и банально ядерная ФС часто не заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не хватило и упс.
> 2. Безопасность
> Уязвимости в ядерном драйвере (включая логические, как в ReiserFS) потенциально ведут к
> компрометации всей системы; в FUSE-драйвере - к компрометации процесса драйвера, привилегий
> отдельного пользователя (с которыми работает процесс) и хранимых данных. При этомВопервых смотря какого пользователя. Вовторых вероятность существования неизвестной уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко простота хуже воровства.
> 3. Скорость разработки и свобода выбора инструментария
> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
> развитыми средствами профилирования, тестирования и отладки.А это специфика ядра. Хочешь надежно - не жлобись на время, знания и деньги.
> 4. Адаптация удобных традиционных абстракций
> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
> FUSE.Надежнее и безопаснее пишутся? Это что то новое. Пишуться то они пишуться, но быстро, надежно и безопасно работать таки не работают.
> Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных
> на FUSE, нельзя решить только за счет перемещения их кода в
> ядро".
> Стало быть критерии оценки ФУЗЕ должны быть те же, что и к
> ядерным ФС. А по ним они сливают.По кому по "ним"? По каким ещё, кроме скорости? Всё, что я услышал от здешних ораторов, это отсылки к скорости работы и апологетика скорости работы как единственно верного критерия.
>>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>>> знает или намеренно вводит в заблуждение.
>> И каков же контекст, просветите?
> См. выше.Посмотрел и не пойму, какие ко мне претензии. Вы их сформулируете, быть может?
>> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
>> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
>> перезапуска.
> Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственныйВы с фактами свои заявления сопоставляете? Это многократно, эмпирически доказанная истина. Я вам больше сказжу: при отказе ядерного драйвера все процессы, которые обращаются к файлам на отказавшем разделе, входят в контекст ядра и висят там безвозвратно, что не позволяет перезапустить не только драйвер, но и приложения. Впрочем вам-то, умудрённому опытом нетеоретику, об этом откуда знать...
> пункт в понятии "надежность". Да и банально ядерная ФС часто не
> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
> хватило и упс.Проца не хватило? Стыда у вас не хватило, такую чушь нести.
> Вопервых смотря какого пользователя.
Оставьте это беспомощное сотрясание нумерацией. Во-первых, беспредметная чушь. Во-вторых, FUD.
> Вовторых вероятность существования неизвестной
> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.С чего бы это вдруг, торагой друг?
>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чащеНадо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры читать отучали?
> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
> простота хуже воровства.Характер использования FUSE кем-либо не характеризует все случаи его использования.
>> 3. Скорость разработки и свобода выбора инструментария
>> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
>> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
>> развитыми средствами профилирования, тестирования и отладки.
> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
> и деньги.Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка тонка сказать об этом прямо. Поэтому вы встаёте в позу и заворачиваете пассажи на тему, кому и на что не следует "жлобиться".
>> 4. Адаптация удобных традиционных абстракций
>> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
>> FUSE.
> Надежнее и безопаснее пишутся? Это что то новое.Ещё бы вам знать. Конечно новое.
> Пишуться то они пишуться,
> но быстро, надежно и безопасно работать таки не работают.Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?
>> Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных
>> на FUSE, нельзя решить только за счет перемещения их кода в
>> ядро".
>> Стало быть критерии оценки ФУЗЕ должны быть те же, что и к
>> ядерным ФС. А по ним они сливают.
> По кому по "ним"? По каким ещё, кроме скорости? Всё, что я
> услышал от здешних ораторов, это отсылки к скорости работы и апологетика
> скорости работы как единственно верного критерия.А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.
>>>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>>>> знает или намеренно вводит в заблуждение.
>>> И каков же контекст, просветите?
>> См. выше.
> Посмотрел и не пойму, какие ко мне претензии. Вы их сформулируете, быть
> может?Фраза и Торвальдса и Мортона в контексте обсуждения переноса ФУЗЕ ФС в ядро.
>>> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
>>> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
>>> перезапуска.
>> Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственный
> Вы с фактами свои заявления сопоставляете? Это многократно, эмпирически доказанная истина.Сопоставляю. Проблем с ядерным драйвером на порядок меньше чем с ФУЗЕ.
> Я вам больше сказжу: при отказе ядерного драйвера все процессы, которые
> обращаются к файлам на отказавшем разделе, входят в контекст ядра и
> висят там безвозвратно, что не позволяет перезапустить не только драйвер, но
> и приложения. Впрочем вам-то, умудрённому опытом нетеоретику, об этом откуда знать...Ну да, мы, умудренные опытом нетеоретики, используя прямые средства просто не продим по ФУЗЕ граблям.
>> пункт в понятии "надежность". Да и банально ядерная ФС часто не
>> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
>> хватило и упс.
> Проца не хватило? Стыда у вас не хватило, такую чушь нести.Аргумент железный. У вас конечно ФУЗЕ систему не грузит, а мы просто готовить не умеем.
>> Вопервых смотря какого пользователя.
> Оставьте это беспомощное сотрясание нумерацией. Во-первых, беспредметная чушь. Во-вторых,
> FUD.С вашей стороны да, ибо аргументов у вас нет.
>> Вовторых вероятность существования неизвестной
>> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
> С чего бы это вдруг, торагой друг?С того, что ядерные дрова используются гораздо чаще ФУЗЕ. Потому проблемы при наличии оных более вероятно обнаружить в коде ядерных дров.
>>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
>> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще
> Надо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры
> читать отучали?Вы хотите сказать опытных ада-разработчиков так много, что они еще согласятся ФУЗЕ писать?
Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйвером не будет. Если для вас это гладиолус, то флаг вам в руки и 42 навстречу.>> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
>> простота хуже воровства.
> Характер использования FUSE кем-либо не характеризует все случаи его использования.Всегда есть альтернатива использованию ФУЗЕ. Причем более прямая альтернатива.
>>> 3. Скорость разработки и свобода выбора инструментария
>>> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
>>> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
>>> развитыми средствами профилирования, тестирования и отладки.
>> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
>> и деньги.
> Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка
> тонка сказать об этом прямо. Поэтому вы встаёте в позу и
> заворачиваете пассажи на тему, кому и на что не следует "жлобиться".Ну конечно, вы видимо можете писать быстро и надежно и дешево, а вот остальные могут только два из трех пунктов реализовать.
>>> 4. Адаптация удобных традиционных абстракций
>>> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
>>> FUSE.
>> Надежнее и безопаснее пишутся? Это что то новое.
> Ещё бы вам знать. Конечно новое.Ну да фантастика она всегда новая. Сказки от дядушки Примуса.
>> Пишуться то они пишуться,
>> но быстро, надежно и безопасно работать таки не работают.
> Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?Аргументов было достаточно. Sapienti sat
>> скорости работы как единственно верного критерия.
> А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.Так. На прямой вопрос о других критериях вы не ответили. Ну и чего изворачиваетесь? Авось непритязательная публика оценит хорошую мину при плохой игре?
Второе. В чём апологетика FUSE с моей стороны? И на каком основании вы взялись за меня решать, какой из моих аргументов основной, а какой - второстепенный?
> Фраза и Торвальдса и Мортона в контексте обсуждения переноса ФУЗЕ ФС
> в ядро.Это разве формулировка претензии? Неужели даже на это вас не хватит?
> Сопоставляю. Проблем с ядерным драйвером на порядок меньше чем с ФУЗЕ.
Потому что меньше. Ну кто бы сомневался. ;)
> Ну да, мы, умудренные опытом нетеоретики, используя прямые средства просто не продим
> по ФУЗЕ граблям.Вы, нетеоретики, даже не в состоянии прочитать и понять, о чём вам пишут прямым текстом. Ситуация, которую я описал, относится к внутриядерным драйверам. Упорствуйте дальше, отрицайте, демонстрируйте глупость. Мне это нравится.
>>> пункт в понятии "надежность". Да и банально ядерная ФС часто не
>>> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
>>> хватило и упс.
>> Проца не хватило? Стыда у вас не хватило, такую чушь нести.
> Аргумент железный. У вас конечно ФУЗЕ систему не грузит, а мы просто
> готовить не умеем.Жду от вас описания ситуации, в которой "банально проца не хватило" в следствие чего случился "крах ФУЗЕ". У вас ведь претензии к прочности аргументов. Ну так соответствуйте сами. А до той поры не ждите, что я буду распинаться в подробностях в ответ на ваши дешёвые провокации. ;)
> С вашей стороны да, ибо аргументов у вас нет.
Аргументов в пользу чего или против чего? Отвечайте конкретно. Я озвучу (повторю) свои аргументы. Не ответите - грош цена вашему слову. Ответите - ткну носом в уже сказанное.
>>> Вовторых вероятность существования неизвестной
>>> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
>> С чего бы это вдруг, торагой друг?
> С того, что ядерные дрова используются гораздо чаще ФУЗЕ. Потому проблемы при
> наличии оных более вероятно обнаружить в коде ядерных дров.И на каком основании вы решили, что частота использования кода коррелирует с количеством неизвестных уязвимостей в нём? Жду от вас ссылок хотя бы на экспертные мнения.
>>>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
>>> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще
>> Надо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры
>> читать отучали?
> Вы хотите сказать опытных ада-разработчиков так много, что они еще согласятся ФУЗЕ
> писать?То есть, смысла писать FUSE-драйвер на Ada мало, потому что мало опытных ада-разработчиков, которые, оказывается, могут ещё и не согласиться? Забавно, забавно. Это начинает походить на беседу с шизофреником. Какое вообще отношение имеет количество разработчиков на Ada к такому *свойству* FUSE, как возможность писать драйверы на разных языках? На джаве разработчиков полно, и она тоже типобезопасная. Жду от вас опус на тему количества смысла написания драйверов на джаве.
> Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании
> АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйверомИсчезнет он только в ваших фантазиях. С чего вдруг? Как и исчезновение разницы. Драйверы FUSE могут работать с правами непривилегированных пользователей, и в системах, где применяется принцип разделения привилегий, они безопаснее внутриядерных драйверов - обуславливают меньшие риски. Типобезопасность языка реализации обеспечивает дополнительный уровень защиты, не более (но и не менее).
> не будет. Если для вас это гладиолус, то флаг вам в
> руки и 42 навстречу.Для меня гладиолус - это беспомощные попытки обосновать малый смысл разработки драйверов на Ada малым числом разработчиков на этом языке. Особенно в контексте аргументов против самих свойств FUSE - отсутствия ограничений по инструментарию.
>>> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
>>> простота хуже воровства.
>> Характер использования FUSE кем-либо не характеризует все случаи его использования.
> Всегда есть альтернатива использованию ФУЗЕ. Причем более прямая альтернатива.Это громкие, но пустые слова. Вы отрицаете априори. Отрицаете. Априори. Вы расписались в своей беспомощности аргументировать фактами. Но уверен, у вас найдётся пара плохо связанных фраз, чтобы и здесь мне возразить. Выкладывайте. Мне уже интересно, на сколько далеко это зайдёт.
>[оверквотинг удален]
>>>> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
>>>> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
>>>> развитыми средствами профилирования, тестирования и отладки.
>>> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
>>> и деньги.
>> Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка
>> тонка сказать об этом прямо. Поэтому вы встаёте в позу и
>> заворачиваете пассажи на тему, кому и на что не следует "жлобиться".
> Ну конечно, вы видимо можете писать быстро и надежно и дешево, а
> вот остальные могут только два из трех пунктов реализовать.Вот этими словами вы что пытаетесь опровергнуть? Высокую стоимость разработки качественного ядерного кода на Си?
Алсо, попытка противопоставить меня "остальным" беспомощна. Старайтесь усерднее.
>>> Надежнее и безопаснее пишутся? Это что то новое.
>> Ещё бы вам знать. Конечно новое.
> Ну да фантастика она всегда новая. Сказки от дядушки Примуса.То есть по существу вам нечего возразить. Где же ваши более достойные альтернативы sshfs, s3fs, copyfs и т.п., которые "всегда есть"?
>>> Пишуться то они пишуться,
>>> но быстро, надежно и безопасно работать таки не работают.
>> Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?
> Аргументов было достаточно. Sapienti satВы себе льстите. Вода, которую вы беспредметно льёте, аргументами будет разве что в глазах тех, кого убеждает тон и настойчивость, но не суть и факты. Тут таких немало. Стало быть, это ваша целевая аудитория?
>>> скорости работы как единственно верного критерия.
>> А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.
> Так. На прямой вопрос о других критериях вы не ответили. Ну и
> чего изворачиваетесь? Авось непритязательная публика оценит хорошую мину при плохой игре?Ваша фраза и есть чистый пример изворачивания. Вы работаете на публику?
> Второе. В чём апологетика FUSE с моей стороны? И на каком основании
> вы взялись за меня решать, какой из моих аргументов основной, а
> какой - второстепенный?
>> Фраза и Торвальдса и Мортона в контексте обсуждения переноса ФУЗЕ ФС
>> в ядро.
> Это разве формулировка претензии? Неужели даже на это вас не хватит?Это формулировка контекста. Вас не хватает даже на понять такую малость.
>> Сопоставляю. Проблем с ядерным драйвером на порядок меньше чем с ФУЗЕ.
> Потому что меньше. Ну кто бы сомневался. ;)Естественно, у вас аргументов нет? Так и запишем.
>> Ну да, мы, умудренные опытом нетеоретики, используя прямые средства просто не продим
>> по ФУЗЕ граблям.
> Вы, нетеоретики, даже не в состоянии прочитать и понять, о чём вам
> пишут прямым текстом. Ситуация, которую я описал, относится к внутриядерным драйверам.
> Упорствуйте дальше, отрицайте, демонстрируйте глупость. Мне это нравится.А вы не можете прочитать и понять фразу Торвальдса в оригинале. Упорствуйте дальше. Вы глупость продемонстрировали.
>[оверквотинг удален]
>>>> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
>>>> хватило и упс.
>>> Проца не хватило? Стыда у вас не хватило, такую чушь нести.
>> Аргумент железный. У вас конечно ФУЗЕ систему не грузит, а мы просто
>> готовить не умеем.
> Жду от вас описания ситуации, в которой "банально проца не хватило" в
> следствие чего случился "крах ФУЗЕ". У вас ведь претензии к прочности
> аргументов. Ну так соответствуйте сами. А до той поры не ждите,
> что я буду распинаться в подробностях в ответ на ваши дешёвые
> провокации. ;)У вас все что противоречит вашей вере - дешевая провокация. Вы обвинили в неадекватности Торвальдса вот вначале докажите обвинение, потом требуйте того же от оппонента. \
>> С вашей стороны да, ибо аргументов у вас нет.
> Аргументов в пользу чего или против чего? Отвечайте конкретно. Я озвучу (повторю)
> свои аргументы. Не ответите - грош цена вашему слову. Ответите -
> ткну носом в уже сказанное.Перевод стрелок? Вначале общее и неаргументированное заявление, после требование аргументов от оппонента? Хотя вашему слову в принципе грош цена, может вам даже хватит ума понять почему.
>>>> Вовторых вероятность существования неизвестной
>>>> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
>>> С чего бы это вдруг, торагой друг?
>> С того, что ядерные дрова используются гораздо чаще ФУЗЕ. Потому проблемы при
>> наличии оных более вероятно обнаружить в коде ядерных дров.
> И на каком основании вы решили, что частота использования кода коррелирует с
> количеством неизвестных уязвимостей в нём? Жду от вас ссылок хотя бы
> на экспертные мнения.Может вам перечислить все статьи по теории вероятности? Али теорехтики нонче совсем безграмотные?
>>>>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
>>>> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще
>>> Надо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры
>>> читать отучали?
>> Вы хотите сказать опытных ада-разработчиков так много, что они еще согласятся ФУЗЕ
>> писать?
> То есть, смысла писать FUSE-драйвер на Ada мало, потому что мало опытных
> ада-разработчиков, которые, оказывается, могут ещё и не согласиться? Забавно, забавно.Вы знаете много Ада разработчиков в совершенстве знающих этот язык? Забавно, забавно.
> Это начинает походить на беседу с шизофреником. Какое вообще отношение имеет
> количество разработчиков на Ada к такому *свойству* FUSE, как возможность писать
> драйверы на разных языках? На джаве разработчиков полно, и она тоже
> типобезопасная. Жду от вас опус на тему количества смысла написания драйверов
> на джаве.Не говорите мне что мне делать и я не скажу куда вам идти. С Джавой вы к Ораклу. А с Адой вы банально брякнули не думая. Количество разработчиков коррелирует со сложностью языка и как результат со стоимостью разработки. Правда вам теорехтикам вряд ли это понять.
>> Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании
>> АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйвером
> Исчезнет он только в ваших фантазиях. С чего вдруг? Как и исчезновениеВы сами то писали что то на Ада сложнее Хелло Вурлд? Или так, абы поговорить заявили?
Писали бы, то знали, почему на Ада не имеет смысла писать ФУЗЕ.> разницы. Драйверы FUSE могут работать с правами непривилегированных пользователей, и в
> системах, где применяется принцип разделения привилегий, они безопаснее внутриядерных
> драйверов - обуславливают меньшие риски. Типобезопасность языка реализации обеспечивает
> дополнительный уровень защиты, не более (но и не менее).Плюшки Ады создавались в расчете на большие проекты и большие команды разработчиков. Использование Ады одним или несколькими разработчиками нивелирует почти все преимущества Ады, но сложность языка никуда не исчезает.
>> не будет. Если для вас это гладиолус, то флаг вам в
>> руки и 42 навстречу.
> Для меня гладиолус - это беспомощные попытки обосновать малый смысл разработки драйверов
> на Ada малым числом разработчиков на этом языке. Особенно в контексте
> аргументов против самих свойств FUSE - отсутствия ограничений по инструментарию.А для меня 42 это попытки приплести Аду только изза репутации последней, языка о котором слышали многие, но мало кто представляет что это.
>>>> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
>>>> простота хуже воровства.
>>> Характер использования FUSE кем-либо не характеризует все случаи его использования.
>> Всегда есть альтернатива использованию ФУЗЕ. Причем более прямая альтернатива.
> Это громкие, но пустые слова. Вы отрицаете априори. Отрицаете. Априори. Вы расписались
> в своей беспомощности аргументировать фактами. Но уверен, у вас найдётся пара
> плохо связанных фраз, чтобы и здесь мне возразить. Выкладывайте. Мне уже
> интересно, на сколько далеко это зайдёт.Аргументировать нужно некостыльность и неигрушечность ФУЗЕ. Вы расписались в неумении банально прочесть простой текст на пару абзацев ангельского и понять его. Успеха в троллинге.
>[оверквотинг удален]
>>>>> развитыми средствами профилирования, тестирования и отладки.
>>>> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
>>>> и деньги.
>>> Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка
>>> тонка сказать об этом прямо. Поэтому вы встаёте в позу и
>>> заворачиваете пассажи на тему, кому и на что не следует "жлобиться".
>> Ну конечно, вы видимо можете писать быстро и надежно и дешево, а
>> вот остальные могут только два из трех пунктов реализовать.
> Вот этими словами вы что пытаетесь опровергнуть? Высокую стоимость разработки качественного
> ядерного кода на Си?Вы же пытались доказать, что стоимость качественной разработки на Ада будет не дороже качественной разработки на Си. Как аргумент приводили скорость разработки ФУЗЕ не думая, что быстро надежно и дешево не бывает даже в случае ФУЗЕ.
> Алсо, попытка противопоставить меня "остальным" беспомощна. Старайтесь усерднее.
Вас таких легион, кучка на копейку. Потому к вам и обращаюсь как к массе.
>>>> Надежнее и безопаснее пишутся? Это что то новое.
>>> Ещё бы вам знать. Конечно новое.
>> Ну да фантастика она всегда новая. Сказки от дядушки Примуса.
> То есть по существу вам нечего возразить. Где же ваши более достойные
> альтернативы sshfs, s3fs, copyfs и т.п., которые "всегда есть"?Отдельные утилиты под эти задачи существовали и до ФУЗЕ.
>>>> Пишуться то они пишуться,
>>>> но быстро, надежно и безопасно работать таки не работают.
>>> Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?
>> Аргументов было достаточно. Sapienti sat
> Вы себе льстите. Вода, которую вы беспредметно льёте, аргументами будет разве что
> в глазах тех, кого убеждает тон и настойчивость, но не суть
> и факты. Тут таких немало. Стало быть, это ваша целевая аудитория?Я себе не льщу и на способность убедить вас и подобных вам понять что либо, кроме вашей веры, не расчитываю.
>>>> скорости работы как единственно верного критерия.
>>> А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.
>> Так. На прямой вопрос о других критериях вы не ответили. Ну и
>> чего изворачиваетесь? Авось непритязательная публика оценит хорошую мину при плохой игре?
> Ваша фраза и есть чистый пример изворачивания. Вы работаете на публику?Констатация факта отказа от ответа - это констатация факта отказа от ответа. Теперь, вместо того, чтобы признать факт, вы решили меня поспрашивать о работе на публику. Продолжайте в том же духе.
>> Второе. В чём апологетика FUSE с моей стороны? И на каком основании
>> вы взялись за меня решать, какой из моих аргументов основной, а
>> какой - второстепенный?
>>> Фраза и Торвальдса и Мортона в контексте обсуждения переноса ФУЗЕ ФС
>>> в ядро.
>> Это разве формулировка претензии? Неужели даже на это вас не хватит?
> Это формулировка контекста. Вас не хватает даже на понять такую малость.Я просил сформулировать претензию. Вы "сформулировали контекст". Вас не хватает даже на понять такую малость.
>>> Сопоставляю. Проблем с ядерным драйвером на порядок меньше чем с ФУЗЕ.
>> Потому что меньше. Ну кто бы сомневался. ;)
> Естественно, у вас аргументов нет? Так и запишем.Ещё раз: аргументов в пользу или против чего у меня нет? Отвечайте прямо - будут вам аргументы. Перечислять все свои аргументы, давая вам пространство для манёвра, у меня желания нет.
> А вы не можете прочитать и понять фразу Торвальдса в оригинале. Упорствуйте
> дальше. Вы глупость продемонстрировали.Именно это я и сделал: прочитал фразу Торвальдса в оригинале. И свои претензии к моей интерпретации её смысла вы до сих пор не смогли или не захотели сформулировать. Продолжайте юлить и копировать мою манеру нажима. Это забавно. :)
>[оверквотинг удален]
>>> Аргумент железный. У вас конечно ФУЗЕ систему не грузит, а мы просто
>>> готовить не умеем.
>> Жду от вас описания ситуации, в которой "банально проца не хватило" в
>> следствие чего случился "крах ФУЗЕ". У вас ведь претензии к прочности
>> аргументов. Ну так соответствуйте сами. А до той поры не ждите,
>> что я буду распинаться в подробностях в ответ на ваши дешёвые
>> провокации. ;)
> У вас все что противоречит вашей вере - дешевая провокация. Вы обвинили
> в неадекватности Торвальдса вот вначале докажите обвинение, потом требуйте того же
> от оппонента. \Во-первых, неадекватность Торвальдса - не единственная тема этого разговора. Вы не можете или не хотите обосновать ваше же утверждение о том, что некая "нехватка проца" может повлечь за собой "крах ФУЗЕ". Не обосновали до сих пор. Ни теорией, ни примерами конкретных ситуаций. Факт. Продолжайте в том же духе, мне нравится.
Теперь по поводу неадекватности. Цитирую Торвальдса:
"userspace filesystem"?
The problem is right there. Always has been. People who think that
userspace filesystems are realistic for anything but toys are just
misguided.Моя интерпретация практически совпадает с переводом: Торвальдс считает, что "люди, которые думают, что пользовательские файловые системы могут быть более, чем игрушками, просто заблуждаются". На лицо переход на личности группы людей, обобщённых по единственному критерию: наличию мнения о пригодности FUSE для решения "неигрушечных" задачь.
То же самое можно было скзать иначе, без выпадов в сторону широкого круга лиц, например: "Я считаю, что FUSE пользовательские файловые системы являются не более, чем игрушками, и людям не следует заблуждаться на этот счёт."
Человек, который переводит предметный разговор на личности, неадекватен. Человек, который обобщённо судит о мнениях группы людей, определяя ее по едиственному признаку без учёта существенных нюансов (ситуаций, в которых скорость работы является второстепенной), неадекватен.
Вот вам моя версия. Жду от вас сформулированных претензий. Равно как и примеров ситуаций с "нехваткой проца".
>>> С вашей стороны да, ибо аргументов у вас нет.
>> Аргументов в пользу чего или против чего? Отвечайте конкретно. Я озвучу (повторю)
>> свои аргументы. Не ответите - грош цена вашему слову. Ответите -
>> ткну носом в уже сказанное.
> Перевод стрелок? Вначале общее и неаргументированное заявление, после требование аргументов
> от оппонента? Хотя вашему слову в принципе грош цена, может вам
> даже хватит ума понять почему.Вы глупы или прикидываетесь? Я вас спрашиваю: аргументы в пользу чего или против чего вы хотите услышать от *меня*? Прямым текстом ведь написал: "Я озвучу (повторю) свои аргументы" - свои аргументы озвучу, понимаете?
Итак, какие аргументы вы хотите услышать от меня? Отвечайте конкретно. Я их озвучу. Не ответите - грош цена вашему слову. Ответите - ткну носом в уже сказанное.
>> И на каком основании вы решили, что частота использования кода коррелирует с
>> количеством неизвестных уязвимостей в нём? Жду от вас ссылок хотя бы
>> на экспертные мнения.
> Может вам перечислить все статьи по теории вероятности? Али теорехтики нонче совсем
> безграмотные?Совершенно верно, теоретики нынче совсем безграмотные, и должны бы знать, что теория вероятносТЕЙ действует лишь в одинаковых условиях, одинаковость которых в данном случае вы никак не обосновали. Вместо этого вы глубокомысленно намекаете на авторитет науки и ваши знания в области теории веростносТИ. ;) Продолжайте в том же духе, это действительно, чёрт возьми, весело. ;)
>> То есть, смысла писать FUSE-драйвер на Ada мало, потому что мало опытных
>> ада-разработчиков, которые, оказывается, могут ещё и не согласиться? Забавно, забавно.
> Вы знаете много Ада разработчиков в совершенстве знающих этот язык? Забавно,
> забавно.Ещё раз спрашиваю: какое отношение количество разработчиков имеет к *свойству* FUSE, которое позволяет писать драйверы на разных языках? Если лично у меня в штате есть толковый программист, допустим, на Хаскелле, которому поручено написать FUSE-драйвер на Хаскелле, количество, квалификация и заинтересованность разработчиков на Аде меня не касается. Равно как и в случае наличия такого разработчика на джаве, эрланге, модулах (простейшее семейство языков) и так далее.
Алсо, настоящий программист выучит аду за 2-3 недели, в объёме, необходимом для написания сложного многопоточного драйвера. Это вам не Си, где для написания сколько-нибудь качественного кода у программиста должна быть выработана дисциплина избежания ошибок ручного управления памятью и проверки выхода за границы значений.
>> Это начинает походить на беседу с шизофреником. Какое вообще отношение имеет
>> количество разработчиков на Ada к такому *свойству* FUSE, как возможность писать
>> драйверы на разных языках? На джаве разработчиков полно, и она тоже
>> типобезопасная. Жду от вас опус на тему количества смысла написания драйверов
>> на джаве.
> Не говорите мне что мне делать и я не скажу куда вам
> идти. С Джавой вы к Ораклу. А с Адой вы банально
> брякнули не думая. Количество разработчиков коррелирует со сложностью языка и какБрякать не думая - ваша прерогатива, торагой. Корреляция со сложностью языка - отдельный перл, в обосновании которого вы не сказали ровным счётом ничего. Вот вам опровержение на отдельных примерах: Обероны - простейшее семейство языков, разработчиков на Оберонах - ноль целых, хрен десятых; Модулы - простейшее семейство, столько же разработчиков.
> результат со стоимостью разработки. Правда вам теорехтикам вряд ли это понять.
Результат со стоимостью разработки? :))) Мой друк... У вас абстрактная сущность как таковая ("результат") коррелирует со *свойством* другой сущености - *стоимостью* разработки. Способность изъясняться у вас на уровне балбеса среднего школьного возраста. ;)
>>> Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании
>>> АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйвером
>> Исчезнет он только в ваших фантазиях. С чего вдруг? Как и исчезновение
> Вы сами то писали что то на Ада сложнее Хелло Вурлд? Или
> так, абы поговорить заявили?Писал, конечно. Вам нечего сказать по существу, и вновь вы переходите на личности. Продолжайте в том же духе.
> Писали бы, то знали, почему на Ада не имеет смысла писать ФУЗЕ.
И почему же, торагой друг? Вот пишу я на Аде, и всё замечательно: и биндинги к Си элементарны, и внутреннее представление нативных типов Ады с лёгкостью приводится в соответствие с сишным, и "игрушки" на FUSE я уже писал (правда, не на Аде - на питоне). Вот совершенно не вижу причин, почему нельзя на Аде писать. Вы уж просветите меня, теоретика. Уж соблаговолите снизойти до конкретики. ;)
> Плюшки Ады создавались в расчете на большие проекты и большие команды разработчиков.
Сходите, сопоставьте вашу околесицу с фактами из Ada Reference Manual:
http://www.adaic.org/resources/add_content/standards/05rm/ht...Не осилите прочитать сами и признать ошибку - я вам весело процитирую и не раз ещё напомню. ;)
Плюшки Ады, хха. Да сколько ж вам лет, увожаимый? ;)
> Использование Ады одним или несколькими разработчиками нивелирует почти все преимущества
> Ады, но сложность языка никуда не исчезает.Сложность языка? :)))))) Оооо, ну вы уж, пожалуйста, просветите меня-теоретика, в чём же сложность этого языка, который проектировался с рассчётом в т.ч. на простоту и читаемость исходного кода? :))
> А для меня 42 это попытки приплести Аду только изза репутации последней,
> языка о котором слышали многие, но мало кто представляет что это.Это вы, увожаимый, совершенно не представляете, что Ада за язык. :)) Спасибо, посмеялся.
> Аргументировать нужно некостыльность и неигрушечность ФУЗЕ. Вы расписались в неумении
Некостыльность и неигрушечность FUSE? Уж извините, торагой друк, я предпочитаю аргументировать сравнительно большую надёжность, безопасность, простоту разработки и свободу выбора инструментариев. Разговоры в терминах некостыльности - ваша прерогатива. ;)
> банально прочесть простой текст на пару абзацев ангельского и понять его.Расписался потому что расписался. ;)
> Успеха в троллинге.
Спасибо на добром слове.
>> Вот этими словами вы что пытаетесь опровергнуть? Высокую стоимость разработки качественного
>> ядерного кода на Си?
> Вы же пытались доказать, что стоимость качественной разработки на Ада будет не
> дороже качественной разработки на Си. Как аргумент приводили скорость разработки ФУЗЕ
> не думая, что быстро надежно и дешево не бывает даже в
> случае ФУЗЕ.Не бывает, потому что не бывает. ;) Впрочем, вы наверняка введены в заблуждение вашей же интерпретацией "скорости разрбаотки", надёжности и "дешевизны". В таком случае мне остаётся лишь пожелать вам, учиться оценивать относительно.
>> Алсо, попытка противопоставить меня "остальным" беспомощна. Старайтесь усерднее.
> Вас таких легион, кучка на копейку. Потому к вам и обращаюсь как
> к массе.Ооо, очередная жемчужина! Ваша последовательность не может меня не радовать. :)) Намекну: вы немного спутали противопоставление массам с отнесением к массам. ;)
>> То есть по существу вам нечего возразить. Где же ваши более достойные
>> альтернативы sshfs, s3fs, copyfs и т.п., которые "всегда есть"?
> Отдельные утилиты под эти задачи существовали и до ФУЗЕ.Под какие "эти" задачи? Снова потеряли нить разговора? И где же эти утилиты? ;)
> Я себе не льщу и на способность убедить вас и подобных вам
> понять что либо, кроме вашей веры, не расчитываю.А и не надо рассчитывать. Нужно изъясняться чётко и последовательно, аргументировать фактами, не лезть на рожон, демонстрируя полное незнание предметов, о которых вы имеете глупость многозначительно вещать, и задавать уточняющие вопросы, чтобы понять (ощутите разницу с "принять") мнение собеседника. И тогда разговор заладится, чему масса примеров - даже в комментах на опеннете, с моим, лично, участием.
>>>>> скорости работы как единственно верного критерия.
>>>> А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.
>>> Так. На прямой вопрос о других критериях вы не ответили. Ну и
>>> чего изворачиваетесь? Авось непритязательная публика оценит хорошую мину при плохой игре?
>> Ваша фраза и есть чистый пример изворачивания. Вы работаете на публику?
> Констатация факта отказа от ответа - это констатация факта отказа от ответа.
> Теперь, вместо того, чтобы признать факт, вы решили меня поспрашивать о
> работе на публику. Продолжайте в том же духе.Продолжайте сказку про белого бычка. ФУЗЕ безопасно, быстро и стабильно. Слава КПСС.
>>> Второе. В чём апологетика FUSE с моей стороны? И на каком основании
>>> вы взялись за меня решать, какой из моих аргументов основной, а
>>> какой - второстепенный?
>>>> Фраза и Торвальдса и Мортона в контексте обсуждения переноса ФУЗЕ ФС
>>>> в ядро.
>>> Это разве формулировка претензии? Неужели даже на это вас не хватит?
>> Это формулировка контекста. Вас не хватает даже на понять такую малость.
> Я просил сформулировать претензию. Вы "сформулировали контекст". Вас не хватает даже на
> понять такую малость.Претензия в том, что вы не учитываете контекста в котором была сказана фраза Торвальдса. Вы снова спросите про контекст, а получив указание на контекст спросите про претензию?
>[оверквотинг удален]
>> Естественно, у вас аргументов нет? Так и запишем.
> Ещё раз: аргументов в пользу или против чего у меня нет? Отвечайте
> прямо - будут вам аргументы. Перечислять все свои аргументы, давая вам
> пространство для манёвра, у меня желания нет.
>> А вы не можете прочитать и понять фразу Торвальдса в оригинале. Упорствуйте
>> дальше. Вы глупость продемонстрировали.
> Именно это я и сделал: прочитал фразу Торвальдса в оригинале. И свои
> претензии к моей интерпретации её смысла вы до сих пор не
> смогли или не захотели сформулировать. Продолжайте юлить и копировать мою манеру
> нажима. Это забавно. :)Копировать манеру юлить разве, но это только у вас получается.
>[оверквотинг удален]
>>>> готовить не умеем.
>>> Жду от вас описания ситуации, в которой "банально проца не хватило" в
>>> следствие чего случился "крах ФУЗЕ". У вас ведь претензии к прочности
>>> аргументов. Ну так соответствуйте сами. А до той поры не ждите,
>>> что я буду распинаться в подробностях в ответ на ваши дешёвые
>>> провокации. ;)
>> У вас все что противоречит вашей вере - дешевая провокация. Вы обвинили
>> в неадекватности Торвальдса вот вначале докажите обвинение, потом требуйте того же
>> от оппонента. \
> Во-первых, неадекватность Торвальдса - не единственная тема этого разговора. Вы не можетеНо это ключевое обвинение, так как прочие темы вытекают из этого пункта.
> или не хотите обосновать ваше же утверждение о том, что некая
> "нехватка проца" может повлечь за собой "крах ФУЗЕ". Не обосновали до
> сих пор. Ни теорией, ни примерами конкретных ситуаций. Факт. Продолжайте в
> том же духе, мне нравится.Не некая, а конкретная, копирование файла через ФУЗЕ. Плюс в прочх ветках приводились примеры, почитайте, если умеете. Хотя может у вас до бисовой мамы вычислительных ресурсов и вам проц не критичный ресурс. Ну а насчет факта то такими фактами Геббельс славился.
> Теперь по поводу неадекватности. Цитирую Торвальдса:
> "userspace filesystem"?
> The problem is right there. Always has been. People who think that
> userspace filesystems are realistic for anything but toys are just
> misguided.
> Моя интерпретация практически совпадает с переводом: Торвальдс считает, что "люди, которые
> думают, что пользовательские файловые системы могут быть более, чем игрушками, просто
> заблуждаются". На лицо переход на личности группы людей, обобщённых по единственному
> критерию: наличию мнения о пригодности FUSE для решения "неигрушечных" задачь.Ну и где неадекватность? ФУЗЕ явно сливает ядерным драйверам, но вы же считаете, что те критерии по которым ФУЗЕ пролетает, это неважные критерии, но вот надежность вы считаете оригинально.
> То же самое можно было скзать иначе, без выпадов в сторону широкого
> круга лиц, например: "Я считаю, что FUSE пользовательские файловые системы являются
> не более, чем игрушками, и людям не следует заблуждаться на этот
> счёт."
> Человек, который переводит предметный разговор на личности, неадекватен. Человек, который
> обобщённо судит о мнениях группы людей, определяя ее по едиственному признаку
> без учёта существенных нюансов (ситуаций, в которых скорость работы является второстепенной),
> неадекватен.По этому критерию вы также неадекватны.
> Вот вам моя версия. Жду от вас сформулированных претензий. Равно как и
> примеров ситуаций с "нехваткой проца".Претензия в необоснованных обвинениях Торвальдса на основании вырванной из контекста фразы.
>>>> С вашей стороны да, ибо аргументов у вас нет.
>>> Аргументов в пользу чего или против чего? Отвечайте конкретно. Я озвучу (повторю)
>>> свои аргументы. Не ответите - грош цена вашему слову. Ответите -
>>> ткну носом в уже сказанное.
>> Перевод стрелок? Вначале общее и неаргументированное заявление, после требование аргументов
>> от оппонента? Хотя вашему слову в принципе грош цена, может вам
>> даже хватит ума понять почему.
> Вы глупы или прикидываетесь? Я вас спрашиваю: аргументы в пользу чего или
> против чего вы хотите услышать от *меня*? Прямым текстом ведь написал:
> "Я озвучу (повторю) свои аргументы" - свои аргументы озвучу, понимаете?Вот, по вашему же определению вы неадекватны.
> Итак, какие аргументы вы хотите услышать от меня? Отвечайте конкретно. Я их
> озвучу. Не ответите - грош цена вашему слову. Ответите - ткну
> носом в уже сказанное.Рылом не вышли-с.
>>> И на каком основании вы решили, что частота использования кода коррелирует с
>>> количеством неизвестных уязвимостей в нём? Жду от вас ссылок хотя бы
>>> на экспертные мнения.
>> Может вам перечислить все статьи по теории вероятности? Али теорехтики нонче совсем
>> безграмотные?
> Совершенно верно, теоретики нынче совсем безграмотные, и должны бы знать, что теория
> вероятносТЕЙ действует лишь в одинаковых условиях, одинаковость которых в данном случае
> вы никак не обосновали. Вместо этого вы глубокомысленно намекаете на авторитет
> науки и ваши знания в области теории веростносТИ. ;) Продолжайте в
> том же духе, это действительно, чёрт возьми, весело. ;)Учите матчасть и теорию вероятности не по курсу в картинках для детсада.
>>> То есть, смысла писать FUSE-драйвер на Ada мало, потому что мало опытных
>>> ада-разработчиков, которые, оказывается, могут ещё и не согласиться? Забавно, забавно.
>> Вы знаете много Ада разработчиков в совершенстве знающих этот язык? Забавно,
>> забавно.
> Ещё раз спрашиваю: какое отношение количество разработчиков имеет к *свойству* FUSE, котороеПрямое.
> позволяет писать драйверы на разных языках? Если лично у меня в
> штате есть толковый программист, допустим, на Хаскелле, которому поручено написать FUSE-драйвер
> на Хаскелле, количество, квалификация и заинтересованность разработчиков на Аде меня не
> касается. Равно как и в случае наличия такого разработчика на джаве,
> эрланге, модулах (простейшее семейство языков) и так далее.Ага Хаскель и Ада разницы нет совсем. Вы круты.
> Алсо, настоящий программист выучит аду за 2-3 недели, в объёме, необходимом для
> написания сложного многопоточного драйвера. Это вам не Си, где для написания
> сколько-нибудь качественного кода у программиста должна быть выработана дисциплина избежания
> ошибок ручного управления памятью и проверки выхода за границы значений.С вами все ясно. На этом диалог можно заканчивать, вы банально не в теме.
>>> Это начинает походить на беседу с шизофреником. Какое вообще отношение имеет
>>> количество разработчиков на Ada к такому *свойству* FUSE, как возможность писать
>>> драйверы на разных языках? На джаве разработчиков полно, и она тоже
>>> типобезопасная. Жду от вас опус на тему количества смысла написания драйверов
>>> на джаве.
>> Не говорите мне что мне делать и я не скажу куда вам
>> идти. С Джавой вы к Ораклу. А с Адой вы банально
>> брякнули не думая. Количество разработчиков коррелирует со сложностью языка и как
> Брякать не думая - ваша прерогатива, торагой. Корреляция со сложностью языка -Это говорит чел, ляпнувший вначале про Аду, потом про джаву потом про хаскель.
> отдельный перл, в обосновании которого вы не сказали ровным счётом ничего.
> Вот вам опровержение на отдельных примерах: Обероны - простейшее семейство языков,
> разработчиков на Оберонах - ноль целых, хрен десятых; Модулы - простейшее
> семейство, столько же разработчиков.О, уже Модулу вспомнили.
>> результат со стоимостью разработки. Правда вам теорехтикам вряд ли это понять.
> Результат со стоимостью разработки? :))) Мой друк... У вас абстрактная сущность как
> таковая ("результат") коррелирует со *свойством* другой сущености - *стоимостью* разработки.Друх мой, стоимость это единственная характеристика позволяющая сравнить разные сущности.
> Способность изъясняться у вас на уровне балбеса среднего школьного возраста. ;)
По иному вы не поймете.
>>>> Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании
>>>> АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйвером
>>> Исчезнет он только в ваших фантазиях. С чего вдруг? Как и исчезновение
>> Вы сами то писали что то на Ада сложнее Хелло Вурлд? Или
>> так, абы поговорить заявили?
> Писал, конечно. Вам нечего сказать по существу, и вновь вы переходите на
> личности. Продолжайте в том же духе.Щазз. Писал бы, знал, особенности Ады, дающие преимущества перед Си.
>> Писали бы, то знали, почему на Ада не имеет смысла писать ФУЗЕ.
> И почему же, торагой друг? Вот пишу я на Аде, и всё
> замечательно: и биндинги к Си элементарны, и внутреннее представление нативных типов
> Ады с лёгкостью приводится в соответствие с сишным, и "игрушки" на
> FUSE я уже писал (правда, не на Аде - на питоне).
> Вот совершенно не вижу причин, почему нельзя на Аде писать. Вы
> уж просветите меня, теоретика. Уж соблаговолите снизойти до конкретики. ;)Успеха, есть много писателЕй, знающих много языков и пишущих на всех одинаково плохо.
>> Плюшки Ады создавались в расчете на большие проекты и большие команды разработчиков.
> Сходите, сопоставьте вашу околесицу с фактами из Ada Reference Manual:
> http://www.adaic.org/resources/add_content/standards/05rm/ht...Вот и сходите, а так же посмотрите проекты реализованные на Аде и банально подумайте зачем в Аду были введены средства отсутствующие в Сях
> Не осилите прочитать сами и признать ошибку - я вам весело процитирую
> и не раз ещё напомню. ;)
> Плюшки Ады, хха. Да сколько ж вам лет, увожаимый? ;)Очередное свидетельство вашей неадекватности по вашему же критерию.
>> Использование Ады одним или несколькими разработчиками нивелирует почти все преимущества
>> Ады, но сложность языка никуда не исчезает.
> Сложность языка? :)))))) Оооо, ну вы уж, пожалуйста, просветите меня-теоретика, в чём
> же сложность этого языка, который проектировался с рассчётом в т.ч. на
> простоту и читаемость исходного кода? :))Вы найдите хоть один язык кроме брейнфака который не писался бы "в расчете на простоту и читабельность" Но сложность языка это не простота и читабельность. Учите матчасть.
>> А для меня 42 это попытки приплести Аду только изза репутации последней,
>> языка о котором слышали многие, но мало кто представляет что это.
> Это вы, увожаимый, совершенно не представляете, что Ада за язык. :)) Спасибо,
> посмеялся.Ну кто б говорил. Крупнейший спец по Аде, тыкающий ее куда надо и куда не надо.
>> Аргументировать нужно некостыльность и неигрушечность ФУЗЕ. Вы расписались в неумении
> Некостыльность и неигрушечность FUSE? Уж извините, торагой друк, я предпочитаю аргументировать
> сравнительно большую надёжность, безопасность, простоту разработки и свободу выбора инструментариев.
> Разговоры в терминах некостыльности - ваша прерогатива. ;)Ну да, вам же потроллить.
>> банально прочесть простой текст на пару абзацев ангельского и понять его.
> Расписался потому что расписался. ;)Потому что тролль
>[оверквотинг удален]
> Спасибо на добром слове.
>>> Вот этими словами вы что пытаетесь опровергнуть? Высокую стоимость разработки качественного
>>> ядерного кода на Си?
>> Вы же пытались доказать, что стоимость качественной разработки на Ада будет не
>> дороже качественной разработки на Си. Как аргумент приводили скорость разработки ФУЗЕ
>> не думая, что быстро надежно и дешево не бывает даже в
>> случае ФУЗЕ.
> Не бывает, потому что не бывает. ;) Впрочем, вы наверняка введены в
> заблуждение вашей же интерпретацией "скорости разрбаотки", надёжности и "дешевизны".
> В таком случае мне остаётся лишь пожелать вам, учиться оценивать относительно.Аргументированность это от оппонентов
>[оверквотинг удален]
>> Отдельные утилиты под эти задачи существовали и до ФУЗЕ.
> Под какие "эти" задачи? Снова потеряли нить разговора? И где же эти
> утилиты? ;)
>> Я себе не льщу и на способность убедить вас и подобных вам
>> понять что либо, кроме вашей веры, не расчитываю.
> А и не надо рассчитывать. Нужно изъясняться чётко и последовательно, аргументировать фактами,
> не лезть на рожон, демонстрируя полное незнание предметов, о которых вы
> имеете глупость многозначительно вещать, и задавать уточняющие вопросы, чтобы понять (ощутите
> разницу с "принять") мнение собеседника. И тогда разговор заладится, чему масса
> примеров - даже в комментах на опеннете, с моим, лично, участием.Начните с себя.
> Продолжайте сказку про белого бычка. ФУЗЕ безопасно, быстро и стабильно. Слава КПСС.Это ваша версия моих аргументов. Особенно забавляет "быстро" - похоже, жажда скорости вас не отпускает. ;) Продолжайте проецировать, это забавно.
> Претензия в том, что вы не учитываете контекста в котором была сказана
> фраза Торвальдса. Вы снова спросите про контекст, а получив указание на
> контекст спросите про претензию?Здесь нет конкретики. Я считаю, что учитываю контекст, и никаких существенных деталей он в смысл сказанного не привносит. А по части перехода на личности - не может привнести в принципе. Считаете иначе? Сформулируйте свою претензию. Похоже, вы даже не знаете, как это делается. По-вашему собеседник сам должен догадаться, каким вы видите контекст, и в чём конкретно интерпретация собеседника с контекстом не согласуется.
>>> Естественно, у вас аргументов нет? Так и запишем.
>> Ещё раз: аргументов в пользу или против чего у меня нет? Отвечайте
>> прямо - будут вам аргументы. Перечислять все свои аргументы, давая вам
>> пространство для манёвра, у меня желания нет.Почему вы не прокомментировали эту часть? Мои аргументы вас не интересуют, надо понимать?
> Копировать манеру юлить разве, но это только у вас получается.
Продолжайте стоять в позе, это забавно. ;) На фоне вашего упорного нежелания отвечать на чётко поставленные вопросы - особенно. ;)
Итак, мои аргументы вам не интересны? Иначе бы вы, я полагаю, воспользовались моим предложением.
>[оверквотинг удален]
>>>> Жду от вас описания ситуации, в которой "банально проца не хватило" в
>>>> следствие чего случился "крах ФУЗЕ". У вас ведь претензии к прочности
>>>> аргументов. Ну так соответствуйте сами. А до той поры не ждите,
>>>> что я буду распинаться в подробностях в ответ на ваши дешёвые
>>>> провокации. ;)
>>> У вас все что противоречит вашей вере - дешевая провокация. Вы обвинили
>>> в неадекватности Торвальдса вот вначале докажите обвинение, потом требуйте того же
>>> от оппонента. \
>> Во-первых, неадекватность Торвальдса - не единственная тема этого разговора. Вы не можете
> Но это ключевое обвинение, так как прочие темы вытекают из этого пункта.И что из этого следует? Видите ли, если б вам было интересно лишь ключевое обвинение, например, в части неадекватности манеры общения Торвальдса, вы бы не отвлекались на комментарии характеристик FUSE, которые я дал. Но покуда у вас сохранялась какая-то уверенность в собственной позиции, вы отвлекались охотно. Теперь же позорно избегаете отвечать на чётко поставленные вопросы, вплоть до элементарных. Продолжайте в том же духе. ;)
> Не некая, а конкретная, копирование файла через ФУЗЕ. Плюс в прочх ветках
> приводились примеры, почитайте, если умеете. Хотя может у вас до бисовой
> мамы вычислительных ресурсов и вам проц не критичный ресурс. Ну а
> насчет факта то такими фактами Геббельс славился.Нет-нет-нет, друк мой. Вы утверждали, что "нехватка проца" может вызвать "крах ФУЗЕ". Вот я вас и спрашиваю, в который раз: в какой конкретно ситуации, по каким причинам и алгоритмам, "нехватка проца" (что бы это ни значило) вызовет крах FUSE-драйвера?
Вместо ответа на этот вопрос, вы лезете ко мне в карман и вместо стабильности FUSE начинаете обсуждать требования к ресурсам. Причём, забывая (или по-просту не понимая), что память и процессорное время очень часто стоят дешевле разработки ПО.
В ваших пассажах о вычислительных ресурсах проступает ровно один критерий оценки: скорость работы. Продолжайте в том же духе. Мне нравится наблюдать, насколько патологические формы может принимать фиксация на скорости у фанатичных хомячков. :)
>[оверквотинг удален]
>> The problem is right there. Always has been. People who think that
>> userspace filesystems are realistic for anything but toys are just
>> misguided.
>> Моя интерпретация практически совпадает с переводом: Торвальдс считает, что "люди, которые
>> думают, что пользовательские файловые системы могут быть более, чем игрушками, просто
>> заблуждаются". На лицо переход на личности группы людей, обобщённых по единственному
>> критерию: наличию мнения о пригодности FUSE для решения "неигрушечных" задачь.
> Ну и где неадекватность? ФУЗЕ явно сливает ядерным драйверам, но вы же
> считаете, что те критерии по которым ФУЗЕ пролетает, это неважные критерии,
> но вот надежность вы считаете оригинально.Я не только так не считаю, но и уже не раз об этом сказал. Повторю ещё раз: скорость - не единственный и не всегда первостепенный критерий оценки. Не единственный и не всегда, понимаете? Это значит, что есть задачи, в которых на первый план выходит не скорость работы. Но это не значит, что нет задач (они есть - их большинство), где высокая скорость работы (и/или относительно низкое потребление вычислительных ресурсов) является основным или одним из основных требований.
Доступно? Или вам покороче писать? А то слкладывается впечатление, что читая второе предложение, вы забываете смысл первого.
И снова о фиксации на скорости. Я вам про переход на личности, а вы мне о ней, родимой. Вы сами адекватны? Способны воспринимать смысл сказанного и следить за ходом разговора? У вас же цитаты перед носом! И при этом, голубчик, вы имеете глупость многозначительно дуть щёки и обвинять меня в игнорировании контекстов. ;) Товарняк с древесиной в глазу вас, случаем, не беспокоит?
>> Человек, который переводит предметный разговор на личности, неадекватен. Человек, который
>> обобщённо судит о мнениях группы людей, определяя ее по едиственному признаку
>> без учёта существенных нюансов (ситуаций, в которых скорость работы является второстепенной),
>> неадекватен.
> По этому критерию вы также неадекватны.Потому что неадекватен. ;) Алсо, следует ли понимать ваше "тоже" как согласие с неадекватностью Торвальдса в данном конкретном случае? ;) Или я тоже, но он не тоже? ;)
>> Вот вам моя версия. Жду от вас сформулированных претензий. Равно как и
>> примеров ситуаций с "нехваткой проца".
> Претензия в необоснованных обвинениях Торвальдса на основании вырванной из контекста фразы.Ха-ха-ха, ну так поясните мне, каким образом контекст, по-вашему, уточняет или меняет смысл этой фразы? Ну?
Потому что на мой взгляд контекст послужил лишь поводом для реализации склонностей Торвальдса к личным оскорблениям. В отрыве от фактов, как у него нередко происходит.
Когда Торвальдс назвал разработчиков OpenBSD мастурбирующими обезьянами, он озвучил мнение, будто в OpenBSD все прочие качества системы приносятся в жертву безопасности. Так вот, это не так. Фетиш OpenBSD - это стабильность и корректность, а также функционал, востребованный её разработчиками (не пользователями). И безопасности там уделяют внимание лишь в силу стремления к корректности, а также в силу исторических причин. На деле нет ни серьёзной защиты от эксплуатации уязвимостей ядра, ни усиления механизмов изоляции, вроде chroot.
Я понимаю, в ваших глазах фюрер ошибаться не может. Но чем раньше вы расстанетесь с этими фанатичными представлениями, тем менее то будет болезненно. ;)
>>> Перевод стрелок? Вначале общее и неаргументированное заявление, после требование аргументов
>>> от оппонента? Хотя вашему слову в принципе грош цена, может вам
>>> даже хватит ума понять почему.
>> Вы глупы или прикидываетесь? Я вас спрашиваю: аргументы в пользу чего или
>> против чего вы хотите услышать от *меня*? Прямым текстом ведь написал:
>> "Я озвучу (повторю) свои аргументы" - свои аргументы озвучу, понимаете?
> Вот, по вашему же определению вы неадекватны.Я не давал определения неадекватности в процитированном вами тексте. Что кагбе намекает, кто из нас двоих неадекватен на самом деле. ;)
>> Итак, какие аргументы вы хотите услышать от меня? Отвечайте конкретно. Я их
>> озвучу. Не ответите - грош цена вашему слову. Ответите - ткну
>> носом в уже сказанное.
> Рылом не вышли-с.При этом благородный дон считает достойным себя выступать в роли пустозвона и невежды, чьё слово ни стоит и ломанного гроша. Как мило. ;) Продолжайте в том же духе-с. :))
>> Совершенно верно, теоретики нынче совсем безграмотные, и должны бы знать, что теория
>> вероятносТЕЙ действует лишь в одинаковых условиях, одинаковость которых в данном случае
>> вы никак не обосновали. Вместо этого вы глубокомысленно намекаете на авторитет
>> науки и ваши знания в области теории веростносТИ. ;) Продолжайте в
>> том же духе, это действительно, чёрт возьми, весело. ;)
> Учите матчасть и теорию вероятности не по курсу в картинках для
> детсада.Спасибо, не горю желанием учить теорию вероятносТИ - что по картинкам, что без них. :)) Тем более ваш пример меня не вдохновляет. ;)
>> Ещё раз спрашиваю: какое отношение количество разработчиков имеет к *свойству* FUSE, которое
> Прямое.Потому что прямое. ;) Но аргументов я не услышу, потому как рожей не вышел-с, да-да. ;)
>> позволяет писать драйверы на разных языках? Если лично у меня в
>> штате есть толковый программист, допустим, на Хаскелле, которому поручено написать FUSE-драйвер
>> на Хаскелле, количество, квалификация и заинтересованность разработчиков на Аде меня не
>> касается. Равно как и в случае наличия такого разработчика на джаве,
>> эрланге, модулах (простейшее семейство языков) и так далее.
> Ага Хаскель и Ада разницы нет совсем. Вы круты.Свойство FUSE позволяет писать драйверы на любом из этих языков. Но вы не в состоянии понять даже буквальный смысл моих слов. Заметили два знакомых слова рядом - Ада и Хаскелль - и сравнивать начали. Цирк просто. :))
>> Алсо, настоящий программист выучит аду за 2-3 недели, в объёме, необходимом для
>> написания сложного многопоточного драйвера. Это вам не Си, где для написания
>> сколько-нибудь качественного кода у программиста должна быть выработана дисциплина избежания
>> ошибок ручного управления памятью и проверки выхода за границы значений.
> С вами все ясно. На этом диалог можно заканчивать, вы банально не
> в теме.Потому что не в теме. ;) Алсо, ну заканчивайте, заканчивайте уже диалог, голубчик! :) Посмотрим, способны ли вы сохранить хоть остатки достоинства.
>> Брякать не думая - ваша прерогатива, торагой. Корреляция со сложностью языка -
> Это говорит чел, ляпнувший вначале про Аду, потом про джаву потом про
> хаскель.Да, это говорю я, "ляпнувший". Вы не понимаете смысла сказанного, даже буквального, различаете лишь знакомые слова - ну так это ваши проблемы, голубчик. :)
>> отдельный перл, в обосновании которого вы не сказали ровным счётом ничего.
>> Вот вам опровержение на отдельных примерах: Обероны - простейшее семейство языков,
>> разработчиков на Оберонах - ноль целых, хрен десятых; Модулы - простейшее
>> семейство, столько же разработчиков.
> О, уже Модулу вспомнили.Вспомнил. А что, у вас будут (наконец-то?!) конкретные возражения, почему её неуместно вспоминать? ;)
>>> результат со стоимостью разработки. Правда вам теорехтикам вряд ли это понять.
>> Результат со стоимостью разработки? :))) Мой друк... У вас абстрактная сущность как
>> таковая ("результат") коррелирует со *свойством* другой сущености - *стоимостью* разработки.
> Друх мой, стоимость это единственная характеристика позволяющая сравнить разные сущности.Единственная? А как же, например, масса, объем, скорость (скорость!!!!11)?
Алсо, ну и что ж вы предлагаете сравнивать по стоимости (я даже не спрашиваю, зачем - вопрос явно не к вам :))? Стоимость достижения результата со стоимостью его разработки? ;) Смех и грех...
>> Способность изъясняться у вас на уровне балбеса среднего школьного возраста. ;)
> По иному вы не поймете.:))))))))) Хочу вас огорчить: я вас и так не понимаю. ;)) Вы собирались заканчивать диалог? Милости прошу. А тот тут есть мнение, что вам категорически слабо. ;))
>>> Вы сами то писали что то на Ада сложнее Хелло Вурлд? Или
>>> так, абы поговорить заявили?
>> Писал, конечно. Вам нечего сказать по существу, и вновь вы переходите на
>> личности. Продолжайте в том же духе.
> Щазз. Писал бы, знал, особенности Ады, дающие преимущества перед Си.Я их и знаю. ;) Вы их не знаете, даже кода на Аде в глаза не видели - вот это очевидно. Ибо пассажи о сложности Ады мог выдать только полный ламер, который не ослили даже в википедию сходить. :)
>>> Писали бы, то знали, почему на Ада не имеет смысла писать ФУЗЕ.
>> И почему же, торагой друг? Вот пишу я на Аде, и всё
>> замечательно: и биндинги к Си элементарны, и внутреннее представление нативных типов
>> Ады с лёгкостью приводится в соответствие с сишным, и "игрушки" на
>> FUSE я уже писал (правда, не на Аде - на питоне).
>> Вот совершенно не вижу причин, почему нельзя на Аде писать. Вы
>> уж просветите меня, теоретика. Уж соблаговолите снизойти до конкретики. ;)
> Успеха, есть много писателЕй, знающих много языков и пишущих на всех одинаково
> плохо.И я, без сомнения, один из таких писателЕй. Потому что из таких. ;)))
>>> Плюшки Ады создавались в расчете на большие проекты и большие команды разработчиков.
>> Сходите, сопоставьте вашу околесицу с фактами из Ada Reference Manual:
>> http://www.adaic.org/resources/add_content/standards/05rm/ht...
> Вот и сходите, а так же посмотрите проекты реализованные на Аде и
> банально подумайте зачем в Аду были введены средства отсутствующие в СяхА зачем мне думать? Я знаю. И ARM читал, и не один раз. Возможно, первый раз прочёл до того, как вы пешком под стол ходить перестали. Хотя, на счёт "перестали" у меня всё чаще возникают некоторые сомнения. :))
>> Не осилите прочитать сами и признать ошибку - я вам весело процитирую
>> и не раз ещё напомню. ;)
>> Плюшки Ады, хха. Да сколько ж вам лет, увожаимый? ;)
> Очередное свидетельство вашей неадекватности по вашему же критерию.Вы снова себе льстите, торагой друк. У нас с вами давно уже не предметный разговор - русла предметности вы старательно и в открытую избегаете. Так что вам и вашей манере общения моя манера общения вполне адекватна. ;) Зачем я трачу на вас время, и почему считаю допустимым опускаться до вашего уровня - вопрос отдельный. Имею, понимаете, слабость. ;)
> Вы найдите хоть один язык кроме брейнфака который не писался бы "в
> расчете на простоту и читабельность" Но сложность языка это не простотаОо, первая сколько-нибудь отличная от вашего уровня попытка передёрнуть. Ну так голубчик, всё же относительно. В некоторых языках простота и читабельность второстепенны. В Аде - первостепенны. На уровне общих языковых средств (то есть за исключения отдельных аннексов стандарта) не введено даже сколько-нибудь семантически сложных средств - намеренно, с акцентом. Об этом написано в самом начале любимой вами матчасти.
> и читабельность. Учите матчасть.
Какую матчасть, голубчик? У вас она какая-то другая, назовите её уже. ;)
>>> А для меня 42 это попытки приплести Аду только изза репутации последней,
>>> языка о котором слышали многие, но мало кто представляет что это.
>> Это вы, увожаимый, совершенно не представляете, что Ада за язык. :)) Спасибо,
>> посмеялся.
> Ну кто б говорил. Крупнейший спец по Аде, тыкающий ее куда надо
> и куда не надо.Вы проецируете. :) Я скромный, и вовсе не спец. ;) Крупнейший спец - это вы. У вас даже Ада специальная - очень сложная. :)
>> Некостыльность и неигрушечность FUSE? Уж извините, торагой друк, я предпочитаю аргументировать
>> сравнительно большую надёжность, безопасность, простоту разработки и свободу выбора инструментариев.
>> Разговоры в терминах некостыльности - ваша прерогатива. ;)
> Ну да, вам же потроллить.Вот, значит, как это называется: потроллить. В таком случае, да, люблю, знаете ли потроллить натощак... ;)
>>> банально прочесть простой текст на пару абзацев ангельского и понять его.
>> Расписался потому что расписался. ;)
> Потому что тролльА тролль потому что тролль. :)) Но в самом деле, голубчик, а чего вы ждали, прямым текстом отказывая мне в разговоре по существу? Вы-то сам благородный дон, не иначе. ;) А в падении уровня разговора ниже всякой критики виноваты, конечно, тролли. ;)
>>> Вы же пытались доказать, что стоимость качественной разработки на Ада будет не
>>> дороже качественной разработки на Си. Как аргумент приводили скорость разработки ФУЗЕ
>>> не думая, что быстро надежно и дешево не бывает даже в
>>> случае ФУЗЕ.
>> Не бывает, потому что не бывает. ;) Впрочем, вы наверняка введены в
>> заблуждение вашей же интерпретацией "скорости разрбаотки", надёжности и "дешевизны".
>> В таком случае мне остаётся лишь пожелать вам, учиться оценивать относительно.
> Аргументированность это от оппонентовО как. Я в ступоре! Эта фраза столь бессвязна, что - поздравляю! - вам удалось меня затроллить! :)))
>> А и не надо рассчитывать. Нужно изъясняться чётко и последовательно, аргументировать фактами,
>> не лезть на рожон, демонстрируя полное незнание предметов, о которых вы
>> имеете глупость многозначительно вещать, и задавать уточняющие вопросы, чтобы понять (ощутите
>> разницу с "принять") мнение собеседника. И тогда разговор заладится, чему масса
>> примеров - даже в комментах на опеннете, с моим, лично, участием.
> Начните с себя.Да хоть сейчас. Вопрос в том, готовы ли вы к этому?
> В отличие от меня Торвальдс дал понять, что не признаёт критериев, кроме скорости работы, и что не оставляет людям право на суждения по критериям кроме скорости.Как на счёт прочитать оригинал переписки? Приписывать свои фантазии другим не очень хорошо.
> В отличие от меня Торвальдс дал понять, что не признаёт критериев, кроме
> скорости работы, и что не оставляет людям право на суждения по критериям кроме скорости.Он высказал свое мнение. Имеет на него право. Более того - лично я с его мнением согласен. Кстати, техническую возможность использовать FUSE никто не убирал.
> А вы продолжайте тешиться иллюзиями, будто ваш собеседник не знает элементарных вещей.
Вы не знаете ровно одну вещь: свое г...о не пахнет. Вот об этом забывают в том числе и разработчики всякого тормозилова. Зато пользователи - отлично помнят.
> Позорный факт - это ваше нежелание признавать иных критериев кроме скорости.
Я не вижу вообще ни-ка-ких плюсов например в NTFS драйвере в юзермоде например. Он мне как пользователю вообще никаких преимуществ перед ядерными не предоставляет с моей пользовательской точки зрения. Зато дикий жрач процессора оным и тормозная скорость работы за минус вполне сойдут. И на фоне ядерных драйверов это выглядит как игрушка. Штука которая годна чтобы прочесть данные с тома, убить на нем дурную ФС и сделать нормальную.
>> Это вполне хороший критерий. Кто не верит - возвращается к флопповодам и
>> диалапным модемам и 80386 процессорам на целых 33МГц.
> Что значит, хороший критерий? Добрый и ласковый? Есть задачи, где важна скорость.Более того - это почти все сценарии использования. Тормозная система вообще почти никому не нужна. За рееееедкими исключениями. Но там где эти исключения есть - там вообще линукс не в кассу как правило.
> Есть задачи, где важна стабильность, безопасность, скорость разработки, свобода выбора
> инструментария и адаптация удобных традиционных абстракций для решения нетрадиционных
> задач.Вы назвали с полдюжины задач которые между собой пересекаются слабо, а то и вовсе противоречат друг другу. Например, скорость разработки - антоним стабильности и безопасности. Быстро налабанный продукт стабильным и надежным не бывает. Проверено десятилетиями опыта софтварной индустии. Понятно что все хотят и рыбку съесть и косточкой не подавиться, но так не бывает.
> как от чтения советских газет. Сразу становится ясно, какой ресурс на
> Руси не будет выработан в течение следующего века.Пи...больство. Как мое, так и ваше, впрочем. И любовь к газификации^W теоретизированиям. В то время как никому не нужны теоретизмы, нужна практически работающая операционка. Хорошо работающая. Только тогда у нее есть шансы. Непонимание этого момента свело в могилу сотни проектов.
>> само существование такой бизнес-модели намекает на то что они считают что
>> ядерный вариант - быстрее. Независимо от Торвальдса :))
> Быстрее!!!1111111 Ага.Да, вы только представьте себе, домашний NAS читающий флешку со скоростью 200Кб/сек никому даром не вперся. Зато со скоростью 10Мб/сек уже другой разговор. А процессор там дохлее и переключение контекстов тормозят его еще сильнее. Поэтому у туксеры вероятно будет некоторое количество клиентуры даже.
>как его высочество любит обгадить чужой труд.И сколько вашего кода в ядре, позвольте поинтересоваться?
>как его высочество любит обгадить чужой труд.
Пруфлинк.
>брызжащий на всех свысока.
Не подходите в следующий раз так близко и вас не забрызгает
>И сколько вашего кода в ядре, позвольте поинтересоваться?0, но причём тут это? Вы, детка, с логикой не дружите? Если, например, разработчики OpenBSD не шлют патчи Тролвальдсу, значит ему можно называть их дрочащими обезьянами, а всем, кто принял его высказывание как хамство перед тем как высказать свой отношение нужно обязательно накоммитить в ядро?
>Пруфлинк.
Ну вот сходу что вспомнилось:
http://article.gmane.org/gmane.linux.kernel/706950
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
+ сабж этой ветки + как он грубо опустил разработчика tty, что тот бросил код (ссылки под рукой нет).
>0, но причём тут это?О как! Действительно при чём. :D
>как его высочество любит обгадить чужой труд.
>брызжащий на всех свысока.
>Ну вот сходу что вспомнилось:так может сходу и своё ведро напишется? С блпоэтессами и пр?
и уж там то вы сможете принимать любой код невзирая на его качество?
А то ТАКИЕ выражения себе позволяете, будто вам фаерболы прищемили, а оказывается:
>но причём тут это?:D
Это правда.
И обсуждают GEOM в юзерспейсе.
При чём здесь BSD-шный GEOM и Linux?
> При чём здесь BSD-шный GEOM и Linux?Да так.. ветром навеяло.
> И обсуждают GEOM в юзерспейсе.Какой еще geom? Урожай травы в этом году удался! Кстати fuse есть и в *BSD, только она не geom слегка :)
Хм-м-м... вот прямо сейчас заливаю на 64-гиговую флэшку, отформатированную в exFAT, данные в 14-м Федорином горе. И что бы я делал без FUSE-драйвера? Скорость в 3.6 МБ/сек меня для однократной операции более чем устраивает.
>И что бы я делал без FUSE-драйвера?Очевидно, ты не игрался бы в игрушки, а занимался делом. Старейшина же объяснил.
> Очевидно, ты не игрался бы в игрушки, а занимался делом. Старейшина же
> объяснил.Это, между прочим, законно купленные ДВД с "The Sopranos" в Гоблиновской озвучке, а никакие не игрушки! :-D А до "занятий делом" у меня еще полтора часа. :-P Если серьезно, то иногда у Линуса какой-то совсем уж неадекват выплывает - то к Плюсам он неровно задышит, теперь вот и FUSE под раздачу попало...
>в Гоблиновской озвучке
>иногда у Линуса какой-то совсем уж неадекват выплываетЛол, вот кто неадекватен, так это нацист-украинофоб пучков-"гоблин"
> Лол, вот кто неадекватен, так это нацист-украинофоб пучков-"гоблин"Звучит так же смешно и правдиво как "космополит-славянофил Гитлер".
>The Sopranos"
>Если серьезно, то иногда у Линуса какой-то совсем уж неадекват выплывает - то к Плюсам он неровно задышит, теперь вот и FUSE под раздачу попало...и чё, теперь с симпсонов грузиться будешь?
Или специфика языка не позволяет определить те ньюансы сабжа, кроме которых в голову запал только один тезис - "фузе нужно убить"?
странно, а почему он его вообще в ведро взял... А потом ещё и cuse...
По прочтении комментов сложилось впечатление, что читать нынче высокое и никому не нужное искусство. Каждый увидел в тексте лишь то, что захотел. Ужос, и эти люди двигают ИТ откуда то и куда то :)."вот прямо сейчас заливаю на 64-гиговую флэшку, отформатированную в exFAT, данные в 14-м Федорином горе. И что бы я делал без FUSE-драйвера?"
и как это противоречит
"Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально низкоскоростному устройству. Но для чего-то вроде корневой ФС ? Нет. Из этого ничего не выйдет."?
Нет, конечно данные на 64-гига залить это ужасть какая критичная задача и показывает, что ФУЗЕ круть неведомая? Или это у вас "чего-то вроде корневой ФС"?
> "Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально
> низкоскоростному устройству. Но для чего-то вроде корневой ФС ? Нет. Из
> этого ничего не выйдет."?Ну, я регулярно обновляю на этой флэшке данные, так что о "редко используемом" говорить вряд ли можно. Да и называть USB 2.0 девайс "изначально низкоскоростным" тоже ИМХО не совсем корректно.
Смотрим второй пост сверху. Ваш оппонент сам ничего не читает, зато упрекает в этом других.
> Смотрим второй пост сверху. Ваш оппонент сам ничего не читает, зато упрекает
> в этом других.Это вот эта прелесть?
"И - да: "редко используемый интерфейс к изначально низкоскоростному устройству" - это SATA III к гибридному (SSD+HDD) диску? Или NTFS/HFS+ на нём же?"Ну извините, "бачилы очи шо купылы", ntfs-3g на SATA III? Ну вас это устраивает по скорости, меня нет. Я предпочту что либо без бутылочных горлышек, столь узких.
NTFS v3.1 при работе Windows Server 2008 R2 и Windows 7 на SATA III гибридном (SSD+HDD) диске с advanced format не является "бутылочным горлышком". При обычном, зачастую нерегулярном, доступе к этой ФС из Linux тоже проблем не возникнет. Делать этот раздел корневым никто не заставляет, это противоестественно даже как-то, но для данных пользователя, чтобы получить к ним доступ из-под Windows, сгодится. FUSE - игрушки для Линуса, за всех пусть не отвечает.
Ещё раз FUSE - File System in User Space - для данных в пространстве пользователя подходит без нареканий. Не будьте категоричными.
>Ещё раз FUSE - File System in User Space - для данных в пространстве пользователя подходит без нареканий.абсолютно и категорично согласен.
Есть задачи, где скорость имеет гораздо меньшее значение, чем возможность безопасно(!!!) и просто получить необходимые данные.
Более того, нтфс в юзерспейсе меня с этой точки зрения устраивает даже больше альтернативы возможного кернелпаника и/или дыр и багов.
Хотя народ конечно может пропиарить свою шкурно-платную разработку. :D
> NTFS v3.1 при работе Windows Server 2008 R2 и Windows 7 на
> SATA III гибридном (SSD+HDD) диске с advanced format не является "бутылочным
> горлышком". При обычном, зачастую нерегулярном, доступе к этой ФС из LinuxРечь была о ФУЗЕ. Хотя в данном разрезе стоит поднять вопрос об оправданности использования НТФС раздела для мультиОСного использования данных.
> тоже проблем не возникнет. Делать этот раздел корневым никто не заставляет,
> это противоестественно даже как-то, но для данных пользователя, чтобы получить к
> ним доступ из-под Windows, сгодится. FUSE - игрушки для Линуса, за
> всех пусть не отвечает.Опять таки, есть более прямые способы разделения данных, ФУЗЕ же остается большей частью для нечастого и некритичного использования.
> Ещё раз FUSE - File System in User Space - для данных
> в пространстве пользователя подходит без нареканий. Не будьте категоричными.Категоричны? Категоричность это найти игрушке пару серьезных применений и считать,что дальше пилить ее в плане производительности и качественности уже некуда/ненадо.
> Речь была о ФУЗЕ. Хотя в данном разрезе стоит поднять вопрос об
> оправданности использования НТФС раздела для мультиОСного использования данных.Да что с ним не так, с NTFS мультиОСным, для данных пользователя? /var, /log, /proc и т. д. оставьте ext4 и btrfs. Профиль пользователя меняется не столь интенсивно.
> Опять таки, есть более прямые способы разделения данных, ФУЗЕ же остается большей
> частью для нечастого и некритичного использования.Опять-таки, есть случаи, когда "более прямые способы" неприменимы, как ни жаль. А FUSE спасает.
> Категоричны? Категоричность это найти игрушке пару серьезных применений и считать,что
> дальше пилить ее в плане производительности и качественности уже некуда/ненадо.Но пара серьёзных применений для дела всё же нашлась и работает без сбоев и нареканий? Неужели это "игрушки"?
>> Речь была о ФУЗЕ. Хотя в данном разрезе стоит поднять вопрос об
>> оправданности использования НТФС раздела для мультиОСного использования данных.
> Да что с ним не так, с NTFS мультиОСным, для данных пользователя?
> /var, /log, /proc и т. д. оставьте ext4 и btrfs. Профиль
> пользователя меняется не столь интенсивно.Возьмем тандерберд. Почта локально лежит в разделе /home. От скорости работы с разделом /home зависит скорость работы тандырберда. Почты может быть много, очень много, папок лежащих в отдельных файлах может быть так же много. Про прочие примеры не говорим, типа необходимости поиска, чтения, записи множества файлов разного размера. Вы считаете что раздел /home может быть на ФУЗЕ? К сетевой папке может быть сделан доступ и с Винды и с Линукса, но вот тормозов ФУЗЕйных не будет. А если нет инета или еще какие проблемы, то есть внешние винты с сетевым интерфейсом небольшого размера. На данные пользователя их хватит.
>> Опять таки, есть более прямые способы разделения данных, ФУЗЕ же остается большей
>> частью для нечастого и некритичного использования.
> Опять-таки, есть случаи, когда "более прямые способы" неприменимы, как ни жаль. А
> FUSE спасает.Не так. Иногда ФУЗЕ проще использовать, но это если задача возникла одноразовая, если же задача повторится, то надо использовать тесамые прямые способы.
>> Категоричны? Категоричность это найти игрушке пару серьезных применений и считать,что
>> дальше пилить ее в плане производительности и качественности уже некуда/ненадо.
> Но пара серьёзных применений для дела всё же нашлась и работает без
> сбоев и нареканий? Неужели это "игрушки"?А как лучше назвать? Костыли? Ок, ФУЗЕ не игрушки, ФУЗЕ - костыли, когда прямые способы по какой либо причине недоступны. Например GmailFS, костыль заменяющий нормальный Гмыльный клиент. SSHFS - костыль заменяющий нормальный ssh клиент. Ограниченный функционал, но более удобно на некотором множестве задач. NTFS-3G это двойной костыль.
>> "Fuse подходит тогда, когда речь идет о редко используемом интерфейсе к изначально
>> низкоскоростному устройству. Но для чего-то вроде корневой ФС ? Нет. Из
>> этого ничего не выйдет."?
> Ну, я регулярно обновляю на этой флэшке данные, так что о "редко
> используемом" говорить вряд ли можно. Да и называть USB 2.0 девайс
> "изначально низкоскоростным" тоже ИМХО не совсем корректно.Назвать ЮСБ 2 высокоскоростным тоже язык не повернется. Да и вы используете флешку единолично, непостоянно, одним процессом чаще всего. Вам в принципе ФУЗЕ подходит, но это не значит, что критичные к скорости приложения удовольствуются ФУЗЕ.
Часто используемые это когда непрерывно пишутся логи, читаются атрибуты к тысячам файлов в секунду и т.д.Все действия производимые пользователем априори редкие. А флешка через USB медленная.
> Да и называть USB 2.0 девайс "изначально низкоскоростным" тоже ИМХО не совсем корректно.вот это настоящий лол. Переведи чтоли его мегабиты в мб/сек
>> Да и называть USB 2.0 девайс "изначально низкоскоростным" тоже ИМХО не совсем корректно.
> вот это настоящий лол. Переведи чтоли его мегабиты в мб/секВспоминаем древнее модемное соединение и таки да, ЮСБ 2 верьх скорости :)
> вот это настоящий лол. Переведи чтоли его мегабиты в мб/секНе надо ничего переводить, я выше приводил сегодняшнюю скорость копирования с ДВД на него - 3.5-3.6 МБ/сек. Да, я прекрасно понимаю, что USB 3.0 намного быстрее. Но из-за того, что тачки F1 гоняют "со скоростью света" называть Бомбу или Мерина "черепахой" я не буду.
А ничего так, что есть люди, монтирующие /home в Win-раздел со своим профилем, в каталог и особо не парятся? Win-раздел, разумеется, NTFS, при этом несложно и "бесшовную" интеграцию кроссплатформенного ПО сделать, с единой конфигурацией профилей, например, для Firefox и OOo...
> А ничего так, что есть люди, монтирующие /home в Win-раздел со своим
> профилем, в каталог и особо не парятся? Win-раздел, разумеется, NTFS, при
> этом несложно и "бесшовную" интеграцию кроссплатформенного ПО сделать, с единой конфигурацией
> профилей, например, для Firefox и OOo...В /home у них пишет/читает куча процессов кучу гигов данных? Стартует множество софта и подгружаются сотни библиотек оттуда? И это все через ФУЗЕ?
Вообще говоря мало ли у кого какие странности. Такой изврат должен хоть чем то оправдываться. Намекните хоть заради чего они это делали?
> Вообще говоря мало ли у кого какие странности. Такой изврат должен хоть
> чем то оправдываться. Намекните хоть заради чего они это делали?"Бесшовная" интеграция кроссплатформенного ПО, например, для Firefox и OOo, см. выше.
>> Вообще говоря мало ли у кого какие странности. Такой изврат должен хоть
>> чем то оправдываться. Намекните хоть заради чего они это делали?
> "Бесшовная" интеграция кроссплатформенного ПО, например, для Firefox и OOo, см. выше.См. выше о костылях. Есть более прямые способы хранения настроек, нежели ФС под Венду.
да! именно так и поступают в критичных задачах и это не изврат и не игрушки, а сириус бизнес. ещё один неосилятор текста детектед
Что важнее: система или пользовательские данные, обрабатываемые и хранимые ею? Если важнейшие данные хранятся на разделе с другой ФС, то FUSE - вовсе не игрушки, а очередной инструмент интеграции различных систем. Пример: проверка создаваемого кроссплатформенного ПО в РЕАЛЬНЫХ условиях. Никакой виртуализации, в виртуализированных средах можно вести лишь предварительное тестирование. Перезагрузка в другую ОС нужна, и кроссплатформенное ПО сохраняет везде свои настройки (бесшовная интеграция). Если для вас это пустые слова - сочувствую, можете теоретизировать и тупо троллить дальше. Я еды больше не дам, мне работать и деньги получать надо, а вы тренируйтесь в Linux дальше, может, и возьму вас когда-нибудь картриджи в принтерах менять.
> Что важнее: система или пользовательские данные, обрабатываемые и хранимые ею? Если важнейшие
> данные хранятся на разделе с другой ФС,Важнейшие данные в Линуксе под другой ФС? Вам не кажется, что с архитектурой системы что то не то?
> то FUSE - вовсе не игрушки, а очередной инструмент интеграции различных систем. Пример:
> проверка создаваемого
> кроссплатформенного ПО в РЕАЛЬНЫХ условиях. Никакой виртуализации, в виртуализированных
> средах можно вести лишь предварительное тестирование. Перезагрузка в другую ОС нужна,
> и кроссплатформенное ПО сохраняет везде свои настройки (бесшовная интеграция).Нет, оно конечно можно и на "спортивных" костылях бегать, но вообще способы хранения важных данных (и уж тем более настроек) в гетерогенных средах известны давно и они как то более прямые и быстрые. И это не ФУЗЕ.
> Если для вас это пустые слова - сочувствую, можете теоретизировать и тупо троллить
> дальше. Я еды больше не дам, мне работать и деньги получать
> надо, а вы тренируйтесь в Linux дальше, может, и возьму вас
> когда-нибудь картриджи в принтерах менять.Да к вам пойдет то? Какой нить ядерный ФУЗЕлятор?
>Важнейшие данные в Линуксе под другой ФС? Вам не кажется, что с архитектурой системы что то не то?Важнейшие данные не в Linux, а для пользователя. С архитектурой какой системы? Linux?
>способы хранения важных данных (и уж тем более настроек) в гетерогенных средах известны давно и они как то более прямые и быстрые. И это не ФУЗЕ.
Сетевые ФС не всегда допустимы, разработчик постоянно перемещается с ноутбуком, интернет есть не везде и не всегда.
>Да к вам пойдет то? Какой нить ядерный ФУЗЕлятор?
Извините, но Вас не возьму точно даже на замену картриджей...
>>Важнейшие данные в Линуксе под другой ФС? Вам не кажется, что с архитектурой системы что то не то?
> Важнейшие данные не в Linux, а для пользователя. С архитектурой какой системы?
> Linux?Мы говорим не об отдельной ОСи, мы как бе про гетерогенную систему, например ИС какого нить предприятия.
>>способы хранения важных данных (и уж тем более настроек) в гетерогенных средах известны давно и они как то более прямые и быстрые. И это не ФУЗЕ.
> Сетевые ФС не всегда допустимы, разработчик постоянно перемещается с ноутбуком,
> интернет есть не везде и не всегда.Разработчик перемещается с ноутом и при этом тестит кроссплатформенное оборудование?
В 90% случаев сетевые хранилища данных решают проблему, а в оставшихся 10% ФУЗЕ не лучшее решение. Особенно когда разработчик перемещается.>>Да к вам пойдет то? Какой нить ядерный ФУЗЕлятор?
> Извините, но Вас не возьму точно даже на замену картриджей...Оно и правильно, зачем подчиненный умнее начальника :)
>>>Важнейшие данные в Линуксе под другой ФС? Вам не кажется, что с архитектурой системы что то не то?
>> Важнейшие данные не в Linux, а для пользователя. С архитектурой какой системы?
>> Linux?
>Мы говорим не об отдельной ОСи, мы как бе про гетерогенную систему, например ИС какого нить предприятия.гетерогенные системы не предполагают низкоуровневый доступ к данным друг-друга хакерскими методами.
ваш КО.зыж
хотя во многих конторах так бывает - одни гадят втихаря другим, а те - первым.
а потом делают круглые глаза из нашейраши - а кто же тут нагадил!!! У-у-у?!!!
Но это уже не гетерогенная система. :D
>>>>Важнейшие данные в Линуксе под другой ФС? Вам не кажется, что с архитектурой системы что то не то?
>>> Важнейшие данные не в Linux, а для пользователя. С архитектурой какой системы?
>>> Linux?
>>Мы говорим не об отдельной ОСи, мы как бе про гетерогенную систему, например ИС какого нить предприятия.
> гетерогенные системы не предполагают низкоуровневый доступ к данным друг-друга хакерскими
> методами.
> ваш КО.Ну дык ФУЗЕ не дома это чистая НашаРаша и есть процентов на 90%.
Ведь кому то сетевая ФС не подходит, но ФУЗЕ годится и типа это корпоратив и гетероге> зыж
> хотя во многих конторах так бывает - одни гадят втихаря другим, а
> те - первым.
> а потом делают круглые глаза из нашейраши - а кто же тут
> нагадил!!! У-у-у?!!!
> Но это уже не гетерогенная система. :DНу так когда вместо построения нормальной системы используют НТФС через ФУЗЕ в качестве общего для ОСей раздела, то вот оно Щасте. :)
>Разработчик перемещается с ноутом и при этом тестит кроссплатформенное оборудование? В 90% случаев сетевые хранилища данных решают проблему, а в оставшихся 10% ФУЗЕ не лучшее решение. Особенно когда разработчик перемещается.Да как, голодный вы мой? Откуда взяться сетевым решениям в местах, где нет доступа к сети? И не забывайте про безопасность, даже если интернет у него будет под рукой: тащить многомегабайтный профиль через сеть - глупость, по меньшей мере. FUSE медленнее, но безопаснее kernel-mode-реализации "чужих" FS. Как перемещение разработчика связано с FUSE? Ещё больше тормозит?
>>Разработчик перемещается с ноутом и при этом тестит кроссплатформенное оборудование? В 90% случаев сетевые хранилища данных решают проблему, а в оставшихся 10% ФУЗЕ не лучшее решение. Особенно когда разработчик перемещается.
> Да как, голодный вы мой? Откуда взяться сетевым решениям в местах, где
> нет доступа к сети? И не забывайте про безопасность, даже если1 Что делает разраб с ноутом в таких местах, если ему там нужно тестить кросплатформенный софт под Линукс и Винду? Леммингам пишет навигационный софт? А кросплатформенность нужна, так как некоторые лемминги в пути любят поиграть?
> интернет у него будет под рукой: тащить многомегабайтный профиль через сеть
> - глупость, по меньшей мере.Ну конечно, домашний каталог на сервере это глупость. А у разраба только ноут.
> FUSE медленнее, но безопаснее kernel-mode-реализации "чужих"
Ви таки думаете безопаснее? Даете возможность получить доступ к профилям и настройкам не только гипотетическим линуксовым ксплойтам, но и реальным вирям с винды, и думаете, что это безопаснее? Или думаете код ФУЗЕ болеенадежен чем ядерный?
> FS. Как перемещение разработчика связано с FUSE? Ещё больше тормозит?
Вы привели в пример перемещающегося разраба, вот вам видимо это перемещение как то связано с ФУЗЕ.
>>>Да к вам пойдет то? Какой нить ядерный ФУЗЕлятор?
>> Извините, но Вас не возьму точно даже на замену картриджей...
> Оно и правильно, зачем подчиненный умнее начальника :)Тупые, но нахрапистые и хитрожопые начальники выезжают как раз за счёт более умных подчинённых - есть кого напрячь, есть с кого спросить, есть кого в случае провала "в жертву принести". Но это не наш случай, вы мне не нужны, разберусь и справлюсь со всем сам. Продолжайте тренировки на Linux'е, верьте в ущербность и непрактичность FUSE, используйте сетевое разделение ресурсов для гетерогенных сред со множеством удалённых сотрудников-разработчиков, рассуждайте о контекстах переключения ядер и приоритетах FS в user-mode и kernel-mode. Это мой давно пройденный этап, я верю лишь тому, что "осилил" сам и что реально, а не в теории, работает. Удачи! Не забудьте поесть по-настоящему, несостоявшийся заменщик картриджей!
> Тупые, но нахрапистые и хитрожопые начальники выезжают как раз за счёт более
> умных подчинённых - есть кого напрячь, есть с кого спросить, есть
> кого в случае провала "в жертву принести". Но это не наш
> случай, вы мне не нужны, разберусь и справлюсь со всем сам.Начальник, какая самокритика. Вот только насчет начальников которые "со всем сам" тоже есть много разных историй.
> Продолжайте тренировки на Linux'е, верьте в ущербность и непрактичность FUSE, используйте
Судя по всему тренируетесь вы, уважаемый, а я просто использую инструмент под задачу.
И это не только Линукс.> сетевое разделение ресурсов для гетерогенных сред со множеством удалённых сотрудников-разработчиков,
Ну да, до ФУЗЕ эта задача была неразрешима. Учите мат часть.
> рассуждайте о контекстах переключения ядер и приоритетах FS в user-mode и
> kernel-mode. Это мой давно пройденный этап, я верю лишь тому, что
> "осилил" сам и что реально, а не в теории, работает. Удачи!В смысле пройденный этап это "осилил"? Ну да, оно же проще ФУЗЕ, а если чего то ФУЗЕ не может, то это и не нужно правильным "поцанам"
> Не забудьте поесть по-настоящему, несостоявшийся заменщик картриджей!
> Хм-м-м... вот прямо сейчас заливаю на 64-гиговую флэшку, отформатированную в exFAT, данные
> в 14-м Федорином горе. И что бы я делал без FUSE-драйвера?
> Скорость в 3.6 МБ/сек меня для однократной операции более чем устраивает.у меня через этот FUSE NTFS/FATxx читаются и пишутся на скорости 20 мбайт/с. ЧЯНТД ?
У кого медленнее, возможно флешка тормозит? (речь о больших файлах, больше 100мб, конечно)
Fedora, Ubuntu - точно работает
> Скорость в 3.6 МБ/сек меня для однократной операции более чем устраивает.Обалденная скорость, право! Только почему-то с EXT4 у меня скорость записи на флеху 15 мегов в секунду :)
Капитан уже замучался объяснять, но напоминает что у флэшек есть разные классы скорости.FUSE может перелопалить на типичном декстопе и гигабит в секунду, пробовали, не проблема. Если у кого-то боттлнек на цифрах в 10-15 MiB/sec — FUSE тут не при чем, разве что конкретная реализация конкретной FS может быть, тормозная.
> FUSE может перелопалить на типичном декстопе и гигабит в секунду, пробовали, не
> проблема.Ага, только при линейном доступе к терабайтному винчу он у меня утыкается в 80Мб/сек, загрузив 1 процессорное ядро на 100%. Я не хочу ничего сказать но ext4 на том же диске выжимает 120, и грузит проц в раза 3-4 меньше. Сами такие драйвера и ФС и кушайте, имхо. А я посмотрев на разницу в работе просто выпилил NTFS со всех разделов где он еще оставался.
Это искуственным образом заторможенный ntfs-3g запутал молодого программиста, решившего, что его фс на уровне ядра будет быстрее. Или стоп, у него уже есть готовый код и того и того с существенной разницей в скорости?
>искуственным образом заторможенный ntfs-3gОткуда дровишки? В мае проверял из Wndows XP и из SystemRescueCD скорость записи файлов с одного NTFS-раздела одного диска на другой NTFS-раздел другого диска. Общий объём - около 130 ГБ, файлы разного размера, от мелких (несколько КБ) до крупных (от 4 до 8 ГБ). Разница в скорости - около 10-15% в пользу Windows, что некритично, т.к. операция нетипичная для Linux.
Из свежих новостей. https://www.opennet.ru/opennews/art.shtml?num=30986
> Из свежих новостей. https://www.opennet.ru/opennews/art.shtml?num=30986Проверьте сами, предварительно почитав комментарии к этой новости и поменьше верьте Антону Альтапармакову, я всё тестировал сам, в чём уверен.
Не надо дёргать системные вызовы ядра по каждому поводу, тогда и производительность не упадёт. Ещё если использовать многопроцессорные/многоядерные системы, то задержка от переключения контекста ядра будет меньше влиять на общую производительность системы.
займись
> Не надо дёргать системные вызовы ядра по каждому поводу, тогда и производительность
> не упадёт. Ещё если использовать многопроцессорные/многоядерные системы, то задержка
> от переключения контекста ядра будет меньше влиять на общую производительность системы.А если сразу писать в коде ядра, то переключений контекстов не будет вообще. Как бы всяко лучше, да.
>сообщения о том, что взгляд Линуса Торвальдса на файловые системы слишком ограничен, так как существует масса самых разнообразных применений механизма FUSE, где выгода от простоты и гибкости разработки с его использованием перевешивает любые преимущества пространства ядра в плане производительности.абсолютно согласен. пример - доступ к различным субд, которые вряд ли стоит запихивать в ядро.
>опровергнута одним из разработчиков NTFS-драйвера для Linux, который указал на то, что выполненная той же компанией реализация NTFS в виде модуля ядра значительно превосходит по производительности NTFS-3G.ещё бы! такой удар по коммерческим интересам. :D
Всё это только подтверждает изначальную бестолковость дизайна Линукса - сначала Трольвадс сделал кусок Г "фор фун", а теперь понятно, что костыли в виде ФУСЕ будут тормозить! Ядро так и осталось монолитным, никакие "выгружаемые драйверы" его не спасут.
>Ядро так и осталось монолитнымКак только ядро линукс перестанет быть монолитным, он перестанет быть линуксом. Монолитное ядро это не хорошо и не плохо, и от изначального дизайна линукса сейчас уже осталась только пара слов в замшелых мануалах начала 90х.
c этой точки зрения Торвальдс как раз и сказал, что микро-ядро - тормоз. :D
а я даже добавлю - предыдущий оратор - болван.
> Всё это только подтверждает изначальную бестолковость дизайна ЛинуксаТак это, вас никто насильно не заставляет им пользоваться. Юзайте миникс, от его величества Таненбаума, который лучше всех знает как надо делать расово верные операционки.
P.S. только вот почему-то все снискавшие популярность ОС или монолиты или какие-то жуткие франкенштейны ака гибридные ядра, при том еще вопрос кто из них там уродливее и кривее.
Толстовато. И достаточно топорно. Тоньше надо троллить, тоньше.
> Толстовато. И достаточно топорно. Тоньше надо троллить, тоньше.Да нормально, как минимум опеннет - успешно затроллен мистером Торвальдсом. Вон сколько флуда развелось от одного наброса Торвальдса :)
А линус то все еще торт =)В любом случае, этим вбросом он сильно привлек внимание разработчиков к fuse. Возможно что нибудь да и улучшат после этого +)
Линус, ну ты чего! Компизу, FUSE, fglrx и Wine на сервере - самое место!
> Линус, ну ты чего! Компизу, FUSE, fglrx и Wine на сервере - самое место!Опередил меня)
Тоже не вижу тут ничего плохого. Ну не принял он в ядро, а зачем его забивать и так уже тяжёлое ядро?
Лишний код, лишняя лазейка, лишний баг. А от того что будет часть когда в ядре, наврядли уж очень увеличится производительность примонтированной файловой системы, например с smb протокола.
Мне почему то кажется, что если ФС на FUSE кэширует в оперативке, то ни чего катастрофичного в плане производительности не будет.
это потому что вы ничего не слышали о переключении контекстов выполнения.
Так или иначе лишний раз писать на диск-не хорошо. Железка медленная само по себе. Какой процент задержки внесёт FUSE, если все девайсы медленные по определению?
большой как не странно.
По простой причине - в линухе итак вся свободная память отдаётся под кэш.
производительность ядерных драйверов и драйверов во фюзе равны только в одном случае - когда нет нагрузки вообще на эту подсистему. С ростом нагрузки производительность фюзе падает в геометрической прогрессии за счёт оверхедов - доп.буфер, переключение контекстов, обеспечение атомарности (блокировки) и тд.
)))) такие споры будут всегдамодель ядра просто не позволяет это сделать
надо задуматься о микро-ядерной архитектуре
Ну вот не понимаю я откуда опять такие споры, новости чтоли не внимательно читают большинство пользователей.
Торвальдс в вольном переводе сказал что "в пространстве ядра будет работать быстрее чем в пользовательском"
КТО НЕ СОГЛАСЕН ?? все согласны, тогда о чём споры? то что можно с оптимизить фузе нет вопросов можно, идеальных программ вообще нет.
ну посмотрите предыдущего оратора - про микроядро ему задуматься надо, угу. :D
макось хы и та - гибридное ведро. Пусть на вики что ли глянет. :D
зыж
что ни профан, то сразу думки про микроядро думает.
(и я далёк от мысли, что он из тех, кому интересны академические проблемы професуры. А вы как считаете? :D)
> что ни профан, то сразу думки про микроядро думает.Вообще складывается впечатление что разговоры о микроядре это такой способ самолюбования и самоудовлетворения. Все дескать идиоты, один я в белом и с микроядром наперевес.
Спасибо, посмеялся (в хорошем смысле). :)
Линус вообще что сказал, что глупо использовать FUSE как root раздел из-за своей специфика. А следовательно утверждение, что ФС нужно делать сперва для FUSE является неправильным, т.к. выбор целевой реализации (FUSE или Ядро) для ФС должно происходить из цели использования (высокая производительность - Ядро, низкая - FUSE).
Я, конечно, не гуру, но практический опыт показал, что инструменты бывают "общего применения" и "специализированные".
FUSE - это такой "швейцарский нож". Не очень-то подходит для полноценной замены ножовки, ножниц, рубанка и т.п. Однако позволяет выполнять несложные операции в случае необходимости. И утверждать, что "швейцарский нож" не годится для серьёзного строительства столь же нелепо, сколь нелепо утверждать о неприменимости FUSE для серьёзного применения.
> Я, конечно, не гуру, но практический опыт показал, что инструменты бывают "общего
> применения" и "специализированные".
> FUSE - это такой "швейцарский нож". Не очень-то подходит для полноценной замены
> ножовки, ножниц, рубанка и т.п. Однако позволяет выполнять несложные операции в
> случае необходимости. И утверждать, что "швейцарский нож" не годится для серьёзного
> строительства столь же нелепо, сколь нелепо утверждать о неприменимости FUSE для
> серьёзного применения.Для серьезного применения вы не будете использовать швейцарский нож. И уж точно на второй раз не будете ковырять бетон ножом, а возьмете перфоратор. Оно конечно "жить захочешь и не так раскорячишся", но вот про "несложные операции" и "не очень то подходит для полноценной замены" Линус и говорил. А еще гворил прежде чем тащить конкретную ФУЗЕ ФС ее доработать надо. RTFO.
Дык а я про что?..
> Дык а я про что?..Значит все правильно. :)
> "несложные операции" и "не очень то подходит для полноценной замены" Линус
> и говорил. А еще гворил прежде чем тащить конкретную ФУЗЕ ФСНет, Линус сказал ровно то, что сказал. В этом и суть: слишком много и с апломбом говорит - порой едва зная, о чём, и переходя на личности. Вроде и взрослый человек, а ведёт себя...
>> "несложные операции" и "не очень то подходит для полноценной замены" Линус
>> и говорил. А еще гворил прежде чем тащить конкретную ФУЗЕ ФС
> Нет, Линус сказал ровно то, что сказал. В этом и суть: слишком
> много и с апломбом говорит - порой едва зная, о чём,
> и переходя на личности. Вроде и взрослый человек, а ведёт себя...Ну-ну, поучи торвальдса ядра разрабатывать.
> Ну-ну, поучи торвальдса ядра разрабатывать.- Разработчики опенбсд - мастурбирующие обезьяны.
- Да вы батенька распустились!
- Ну-ну, поучи меня ядра разрабатывать.
> - Разработчики опенбсд - мастурбирующие обезьяны.Судя по результатам их деятельности - не так уж он и неправ, однако. Система у которой поддержка многоядерсности в половине подсистем отсутствует - мало кому нужна в эпоху, когда 2 ядра есть в _телефонах_.
То, что он сказал, мы вряд ли узнаем. Здесь скорее то, как поняли его специфический ангельский :)
Прочитал обсуждение новости.
Как же хорошо Линус тролит!
FUSE отлично может в гигабитные скорости. На среднем современном десктопе - точно. Да, внутриведерные системы могут куда большие цифры показать, но дело-то не в этом.Если у кого-то rootfs (не tmpfs на /tmp и /var/run и не $HOME) требует адовых пропускных способностей - это или весьма специфичный случай или человек знает толк в извращениях.
Ergo, делаем вывод что Линус опять с пафосным видом несет чушь.
> FUSE отлично может в гигабитные скорости. На среднем современном десктопе - точно.Да, конечно, выжрав ядрышко коры i5 ... i7 или фенома целиком под это дело. Всего-то.
API для файловых систем в юзерспейсе под названием FUSE
был изначально очень плохо спроектирован. Отсюда значительная доля
тормозов, даже не на "юзерспейсности".Более правильная реализация находится здесь
http://www.netbsd.org/docs/puffs/Ставший уже "классическим" FUSE реализован
поверх другого более нормально API.
> API для файловых систем в юзерспейсе под названием FUSE
> был изначально очень плохо спроектирован. Отсюда значительная доля
> тормозов, даже не на "юзерспейсности".Отсюда: http://cloudfs.org/2011/06/user-space-filesystems/
The inefficiency of moving I/O out to user space is also somewhat self-inflicted. A lot of that inefficiency has to do with data copies, but let’s consider the possibility that there might be fewer such copies if there were better ways for user-space code to specify actions on buffers that it can’t actually access directly. We actually implemented some of these at Revivio, and they worked. Why aren’t such things part of the mainline kernel? Because the gatekeepers don’t want them to be. Linus’s hatred of microkernels and anything like them is old and well known. Many other kernel developers have similar attitudes. If they think a feature only has one significant use case, and it’s a use case they oppose for other reasons, are they going to be supportive of work to provide that feature? Of course not. They’re going to reject it as needless bloat and complexity, which shouldn’t be allowed to affect the streamlined code paths that exist to do things the way they think things should be done. There’s not actually anything wrong with that, but it does mean that when they claim that user-space filesystems will incur unnecessary overhead they’re not expressing an essential truth about user-space filesystems. They’re expressing a truth about *their support of* user-space filesystems in Linux, which is quite different.
> Отсюда: http://cloudfs.org/2011/06/user-space-filesystems/То, что Линус неадекват по-моему известно очень давно.
А людям просто нравится ходить под фюрером,
будь то Линус, Столлман, Дреппер или Тео.
Мне кажется, "странности" в личности создателя -- это часть пиара,
возможно, главная его часть.Здесь paxuser метал бисером перед свиньями десятками постов, эффекта -- ноль.
Фюрер прав просто потому, что он Фюрер!