The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

У Linux Foundation новый технический директор

19.12.2008 11:30

Некоммерческая организация Linux Foundation опубликовала пресс-релиз, согласно которому ее новым техническим директором назначен Ted Ts'o . Тед известен как разработчик ядра Linux и до недавнего времени наряду с Steve Hemminger, Andrew Morton, Linus Torvalds и Andrew Tridgell являлся доверенным членом совета этой организации. На посту технического директора Тед сменил Маркуса Рекса, который принял предложение Novell вернуться в эту компанию на должность генерального менеджера и вице-президента подразделения OPS.

В качестве технического директора Ted Ts'o будет курировать технические вопросы работы Linux Foundation, включая контроль за разработкой программы стандартизации Linux Standard Base (LSB) и мониторинг рабочих групп, таких как, например, Open Printing. Также в его обязанности будет входить обеспечения взаимодействия между членами LF и техническим советом (Technical Advisory Board), представляющим мнение сообщества ядра Linux.

До назначения на должность технического директора Ted Ts'o работал в качестве старшего технического консультанта компании IBM. В последнее время сферой его деятельности была работа, связанная с разработкой индустриального решения реального времени на базе Linux. Тед также вел проект разработки системы Linux и Windows аутентификации Kerberos. Основной вклад Теда в Linux - создание файловых систем ext2, ext3 и ext4.

  1. Главная ссылка к новости (http://linux-foundation.org/we...)
Автор новости: blkdog
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/19469-linux
Ключевые слова: linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 17:34, 19/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Основной вклад Теда в Linux - создание файловых систем ext2, ext3 и ext4.

    Весомый вклад.

    з.ы. У меня все время стоит вопрос: кто ему платить зарплату? Где Linux Foundation берет деньги на содержание своего штата?

     
     
  • 2.2, pavel_simple (??), 17:44, 19/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Основной вклад Теда в Linux - создание файловых систем ext2, ext3 и ext4.
    >
    >Весомый вклад.
    >
    >з.ы. У меня все время стоит вопрос: кто ему платить зарплату? Где
    >Linux Foundation берет деньги на содержание своего штата?

    не считаю чужих денег -- тогда и свои небойсь заведутся

     
     
  • 3.4, pavel_simple (??), 17:53, 19/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Основной вклад Теда в Linux - создание файловых систем ext2, ext3 и ext4.
    >>
    >>Весомый вклад.
    >>
    >>з.ы. У меня все время стоит вопрос: кто ему платить зарплату? Где
    >>Linux Foundation берет деньги на содержание своего штата?
    >
    >не считаю чужих денег -- тогда и свои небойсь заведутся

    P.S. оговорка по Фрейду?
    правильно "не считай чужих денег - появятся свои"

     
  • 2.3, vitek (??), 17:52, 19/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Основной вклад Теда в Linux - создание файловых систем ext2, ext3 и ext4.
    >Весомый вклад.

    и это действительно так.

     

  • 1.5, Аноним (5), 00:10, 20/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Основной вклад Теда в Linux - создание файловых систем ext2

    А дальше уже пошли тормозные костыли, т.к. reiserfs && reiser4 их уделывают по полной. Но Тсо их мейнтейнеров не особо жалует, по каким-то сугубо по личным причинам... жаль :(

     
     
  • 2.7, User294 (??), 01:46, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А дальше уже пошли тормозные костыли, т.к. reiserfs && reiser4 их уделывают
    >по полной.

    А помнится тут бенч проскакивал.Тупой и малоинтересный.Но одно оный показывал неплохо: хваленому рейзер4'у однако ж через некоторое время становится весьма душно из-за фрагментации файлов при активном юзании ФС... а вот EXT'ы к фрагментации не очень то и склонны в принципе.И вообще, заявлять что рейзер всех и всегда зарулит - мягко говоря неверно.У него как сильные так и слабые стороны есть.Как впрочем и у любой иной ФС.Наверняка можно накопать пример проблемный для рейзера но не представляющий для ext'ов проблем.

     
     
  • 3.9, Аноним (1), 04:17, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да, вы тот бенч от начало до конца внимательней прочитайте (надеюсь мы говорим про одно и то же http://balancer.ru/). Фрагментация (если она и была, а то ведь это как погода на Марсе, вполне могло статься, что у человека с железом не лады) у рейзер4 это милая шалость, по сравнению с тем, что выкинули все остальные "прогрессивные" ФС
     
     
  • 4.15, User294 (??), 15:21, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Да, вы тот бенч от начало до конца внимательней прочитайте

    Я и прочитал.От и до.И даже (если вы читали обсуждение того бенча тут на опеннете) не без оснований раскритиковал данный бенч к такой-то матери.Потому что слегка интересуюсь вопросами файловых систем.На уровне легкого хобби.

    В общем то ЕДИНСТВЕННОЕ что по этому бенчу видно и какой вывод можно сделать (автор ведь даже конфигурацию толком не описал, настройки EXT3 и т.п.) - то что рейзер и рейзер4 там ничем таким у автора не блеснули в плане фрагментации.Даже на тестовых файлах сразу после их записи - фрагментация у рейзеров оказалась *больше* чем у всех остальных фс (у кого автор осилил замерять ее).Да и вообще, аффтар бенча вообще сподвинулся на бенч сугубо заколебавшись от тормозов Reiser4 который у него сильно фрагментировался при работе как я понял.Ага?

    >(надеюсь мы говорим про одно и то же http://balancer.ru/).

    О нем самом.

    >статься, что у человека с железом не лады)

    Неубедительно.Почему же тогда остальные ФС от мнимых проблем железа у него не страдали?И вообще автор выбрал для себя XFS и о проблемах более ничего не говорил.Странно.

    >у рейзер4 это милая шалость, по сравнению с тем, что выкинули все остальные
    >"прогрессивные" ФС

    Да?А вон в том же бенче банальные JFS и XFS дружно натянули ВСЕХ рейзеров (!) в плане фрагментации.Кстати XFS вообще нагло продемонстрировал фрагментацию 0%.Кто смотрел описание работы XFS думаю запросто поймет почему у него фрагментация около 0% - вот с чем-чем а с оной XFS пытается бороться довольно агрессивно.

     
     
  • 5.18, Аноним (1), 17:41, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    "Уровень фрагментации ext3 измерить не удалось, программа выдавала серию ошибок.

    ext4dev в тест не попала по причине постоянных падений при попытке копирования на неё данных /usr.

    Далее в комментариях от самого balancer

    "Ну, для /usr падения xfs не страшны, он почти всё время в R/O, а вот в /home у меня пропажи при падении питания были. Например, почти всегда накрывается файл сессий Оперы."
    Вместо вступления.
    Собсвенно это и навело на нехорошие мысли, о проблемах с железом (ради интереса узнать бы производителя диска и контроллера на матери). И да, очень хорошие сами по себе факты.
    1) Несколько тестов от 1ого человека, к сожалению, мало пригодны, чтобы делать далеко идущие выводы (нерепрезентативно). Не настаиваю, что этот аргумент очень сильный, но всё же стоит призадуматься.
    2) Ладно. Я допускаю, что проблемы с фрагментацией есть. Но смотрите, в подавляющем большинстве тестов reiser4 - лидер (где-то безоговорочный, где-то с небольшим отрывом, но всё равно 1ый). Я к чему всё это пишу, после небезызвестных событий с главным разработчиком этой ФС, отношение сообщества ещё больше охладело. Обидно, пропадает, если не лучшая ФС, то очень хорошая. Патчи кстати шлются (часто видны коммиты про рейзер4 в http://repo.or.cz/w/linux-2.6/zen-sources.git). Да и проблемы с фрагментацией должно быть решаемы. Вот такие дела...

     
  • 2.8, sHaggY_caT (ok), 01:50, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Основной вклад Теда в Linux - создание файловых систем ext2
    >
    >А дальше уже пошли тормозные костыли, т.к. reiserfs && reiser4 их уделывают
    >по полной. Но Тсо их мейнтейнеров не особо жалует, по каким-то
    >сугубо по личным причинам... жаль :(

    Поищите поиском по последним новостям бейнчи, не на столько и уделывает..

    А еще, есть точка зрения, что ext3 таки надежнее любого рейзера, особенно, 4го, который, наверное, уже и не выйдет.

     
     
  • 3.10, Аноним (1), 04:40, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Рассказать о надёжности? Был у меня раздельчик. Жил, не тужил, ресеты и всё такое. Reiserfs при загрузке всё спокойно перемалывал, никаких потерь данных не было. Но разговор не об этом. В один прекрасный день, устав от непонятных для меня тормозов дисковой подсистемы, я решился сделать проверку диска, и не абы какую а влепил сразу же --rebuild-tree (почитайте в мане reiserfsck что это значит). И тут же утилитка мне выдаёт, что не может прочитать блок такой-то и завершает свою работу. Прочитав ман, должно быть понятно, что случается с ФС (tip: unmountable state). Только потом, я узнаю, что у меня с каждой загрузкой будет всё больше и больше сыпать жёский диск бэдами, потом до меня, дурака, дойдёт, что запускать reiserfsck --rebuild-tree с указанием списка бэдблоков по "живому" (просто не было возможности скопировать с помощью того же dd на другой диск) разделу несамая удачная идея (мало того, badblocks из пакета ext2tools неправильно определяет номера битых блоков рейзера, хотя специально был передан ключ про размер блока в 4k). Но речь далеко не об этом. Когда появился новый диск, таки был скопирован тот раздел (правда dd_rescue). Могу сказать, что вот таких перестроек дерева на живом разделе было запущенно раз 15 (пока стало понятно, что дурит badblocks) + 3 раза, почему то мне кажется, болезненный прогон самим badblocks. Да вот, это всё было скопировано dd_rescue и тем же reiserfsck --rebuild-tree приведён в монтируемое состояние. Потери при копировании dd_rescue составил окло 7 метров (размер блока брал 256 байт), в реальности после перестройки дерева, в абсолютном значении потери составили больше, но не значительно (да и повезло битыми оказались для меня неважные данные). Дак к чему эта вся тирада? А, да, разговор про надёжность. Вот пример когда я почувствовал, что надёжно.
     
     
  • 4.11, Аноним (1), 04:55, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    С той поры привилось стойкое отвращение к жёским дискам фирмы Западный Цифровой (WD), диск отработал чуть больше года. Может мне попался не совсем удачный экзэмпляр, а может и нет... ))

     
  • 4.12, БуржуЙ (?), 09:29, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну и какой Вы сделали вывод?

    если бы было что-то надёжнее, то все производители (RH, Novell,...) этим бы воспользовались.
    и ни какой Тсо им бы не помешал. (бизнес есть бизнес. ничего личного)

    фс класса ext* - это рабочая лошадка, которая работает в любых условиях. кстати, не каждый коммерческий *nix может похвастать такой же.
    а если её подтюнить и использовать lvm - то получается очень надежное и гибкое решение. да ещё и сертифицированное для энтерпрайс (например, под б/д oracle).

     
     
  • 5.16, Аноним (1), 17:19, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ну и какой Вы сделали вывод?

    А довольно простой. Ко всяким выборам ынтырпрайзчиков и "весомым" бенчмаркам кого-либо, стоит относится с большой долей скептицизма, хотя бы до тех пор, пока на себе не проверишь. Тот раздел, между прочим, был корневым (да не простокорневым, короче всё дерево было на этом разделе, теперь-то у меня /usr/bin и /home отдельно), система до то того момента как я решил "по-умному" проверить ФС стартовала и работала. Она пережила криворукие попытки её восстановить, и была восстановлена, те она оказалась устойчивой и при работе со сбойным железом, и в плане пользователя-идиота. Вполне конкретный пример, а не абстрактный пук про надёжность и ынтырпрайз.

    Про lvm вообще не понял, каким боком это может быть аргументом против reiserfs?

     
     
  • 6.20, БуржуЙ (?), 18:06, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну что же. Если Вы хотите выражаться в терминах "абстрактный пук" и "ынтырпрайз", то извольте-с.

    Ваш пук красноречиво говорит только о том, что "криворукие" попытки (Ваши слова!) её восстановить увенчались успехом. Но от греха подальше Вы все-таки, цитата "теперь-то у меня /usr/bin и /home отдельно". Защита от криворукости или от замечательной фс?
    >Про lvm вообще не понял, каким боком это может быть аргументом против reiserfs?

    Наводящий вопрос.
    А зачем Вам нужна была именно reiserfs? Для проверки своей криворукости?
    По каким критериям Вы её выбирали?

     
     
  • 7.22, Аноним (1), 20:29, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не ёрничайте. Вы отлично поняли, что я хотел сказать.
     
     
  • 8.24, БуржуЙ (?), 20:53, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Выражайтесь приличней и никто не будет ёрничайть Или Вы думаете, что Ваши выска... текст свёрнут, показать
     
     
  • 9.26, Аноним (1), 21:14, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да, я понял,что вы очень толстый тролль... текст свёрнут, показать
     
  • 7.23, Аноним (1), 20:37, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А зачем Вам нужна была именно reiserfs? Для проверки своей криворукости?

    Чтобы вы спросили. Ну надеюсь спорить что reiser 3.6 быстрей ext3 не будете?

     
     
  • 8.25, БуржуЙ (?), 21:03, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Спорить Ни в коем случае Вы даже представить не можете, что под словом быст... текст свёрнут, показать
     
     
  • 9.27, Аноним (1), 21:18, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Нюансы Вроде зависимость скорости кодирования lame от используемой ФС Или созд... текст свёрнут, показать
     
     
  • 10.29, vitek (??), 22:35, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Не только Это ещё и вроде размера журнала, directory indexing, а в ext4 ... текст свёрнут, показать
     
  • 2.13, szh (ok), 13:34, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > reiserfs && reiser4 их уделывают по полной.

    не так быстро, анонимный аналитик :
    http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=2
    http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=4

     
     
  • 3.17, Анонимус (?), 17:40, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >не так быстро, анонимный аналитик :
    >http://www.phoronix.com/scan.php?page=article&item=ext4_benc...
    >http://www.phoronix.com/scan.php?page=article&item=ext4_benc...

    только вот почему результатов тестов по работе с небольшими файлами и большими каталогами нам не предоставили? ибо результаты очевидны, т.к. ext* сливают в этом в _разы_ :)

     
     
  • 4.21, vitek (??), 18:10, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    вы нам тоже эти _разы_ не предоставите?

    с кем то я уже спорил по этому поводу.... потом он пропал.

     
     
  • 5.28, Аноним (-), 21:40, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да запросто: создаем в одном каталоге 10000 файлов, половину на выбор удаляем, создаем еще 10000 файлов, т.е. имитируем обыкновенный maildir, где фс семейства ext* будут просто "задыхаться http://lkml.org/lkml/2007/1/7/18

    yes, ext3 does suck-by-design. Always has. (C) Andrew Morton

     
     
  • 6.30, vitek (??), 22:44, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    в комменте 29, чуть выше https://www.opennet.ru/openforum/vsluhforumID3/46936.html#29
    я привёл немного ссылок.
    если их прочитать, то и 10000 - это будут семечки.
    я ежедневно работаю с ~1000000 файлов в одном каталоге и нормально (OeBS о чём-нибудь говорит? :-)

    Andrew Morton чувак крутой конечно, но файловых систем от него особо я не видел.

     
     
  • 7.31, Аноним (-), 00:17, 21/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Andrew Morton чувак крутой конечно, но файловых систем от него особо я не видел.

    Никакой "крутой чувак", написавший свою фс критиковать ее не будет по определению. Вообщем, неважно. Надеюсь, что в будущем Тсо не будет своими предубеждениями мешать прогрессивным фс бфть в ядре и развиваться

     
     
  • 8.35, szh (ok), 02:28, 23/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    http kerneltrap org Linux Reiser4_Update people who really like reiser4 might... текст свёрнут, показать
     
     
  • 9.36, Аноним (-), 11:38, 23/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да-да, поменять практически стабильную и самую быструю fs на постоянно падающую ... текст свёрнут, показать
     
     
  • 10.37, szh (ok), 13:58, 23/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    речь про Ханса Райзера я думаю ... текст свёрнут, показать
     
     
  • 11.38, Аноним (-), 14:48, 23/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Так Ханс уже давно не майнтейнер Reiser4, если взять дату поста Ворошат какое-то... текст свёрнут, показать
     
  • 4.32, szh (ok), 00:39, 21/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > только вот почему результатов тестов по работе с небольшими файлами и большими каталогами нам не предоставили? ибо результаты очевидны, т.к. ext* сливают в этом в _разы_ :)

    reiserfs слил очень сильно на больших файлах. То есть утверждение "reiserfs быстрее ext*" является враньем. Я о вранье и не более того.

     
     
  • 5.33, Аноним (-), 04:50, 21/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >reiserfs слил очень сильно на больших файлах.

    провел у себя тесты с созданием/чтением/удалением 2GB файла, опции по умолчанию, раздел 12Gb: ext3 - 51/50/3c, reiserfs - 50/53/1c; сказать, что кто-то "слил очень сильно" - нельзя

    >То есть утверждение "reiserfs быстрее ext*" является враньем.

    по субъективным ощущениям и по объективным с небольшими и маленькими файлами - правда

     
     
  • 6.34, Аноним (-), 04:55, 21/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    я мерял как положено, т.е. сбрасывал кеш перед каждой операцией и время мерял вместе с sync


     

  • 1.14, Аноним (1), 13:57, 20/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >если бы было что-то надёжнее, то все производители (RH, Novell,...) этим бы воспользовались.

    +100 В СПО вату не катают.

     
     
  • 2.19, Анонимус (?), 17:57, 20/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>если бы было что-то надёжнее, то все производители (RH, Novell,...) этим бы воспользовались.
    >+100 В СПО вату не катают.

    ага, они ее едят https://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf
    по ссылке - анализ кода драйверов ext3,reiserfs,jfs на предмет обнаружения и коррекции ошибок в данных, вот выводы:
    • Ext3: Overall simplicity. Ext3 implements a simple and mostly
    reliable failure policy, matching the design philosophy found in the
    ext family of file systems. It checks error codes, uses a modest level
    of sanity checking, and recovers by propagating errors and aborting
    operations. The main problem with ext3 is its failure handling for
    write errors, which are ignored and cause serious problems including
    possible file system corruption.
    • ReiserFS: First, do no harm. ReiserFS is the most concerned
    about disk failure. This concern is particularly evident upon write
    failures, which often induce a panic; ReiserFS takes this action
    to ensure that the file system is not corrupted. ReiserFS also uses
    a great deal of sanity and type checking. These behaviors combine
    to form a Hippocratic failure policy: first, do no harm.
    • JFS: The kitchen sink. JFS is the least consistent and most diverse
    in its failure detection and recovery techniques. For detection,
    JFS sometimes uses sanity, sometimes checks error codes, and
    sometimes does nothing at all. For recovery, JFS sometimes uses
    available redundancy, sometimes crashes the system, and sometimes
    retries operations, depending on the block type that fails, the
    error detection and the API that was called.


     
     
  • 3.39, crypt (??), 18:31, 23/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Чуваки, я вас нифига не понимаю. Если вас так волнует вопрос, какая ФС круче. Да поднимите вы сервер с реальным ип, да проверьте сообща.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру