Русский
Русский
English
Статистика
Реклама

Быстрые vps

Услуга за услугу. Как русские учёные впряглись за Пастера в споре с антипрививочниками

06.05.2021 10:07:53 | Автор: admin


В 2020 у нас появился новый повод гордиться Россией вакцина от коронавируса, разработанная центром имени Н.Ф. Гамалеи.
Я расскажу о событиях 135-летней давности. О приключениях молодого доктора Гамалеи в Париже и о том, как в мире победили вирус бешенства.


Победили это конечно громко сказано. Вирус до сих пор смертелен. Если не ввести вакцину, или ввести поздно, когда уже проявились симптомы человек гарантированно умрёт в страшных мучениях. Посмотрите на ютубе ролик из московской больницы про заболевшего бешенством мужчину запомните на всю жизнь. И перестанете легкомысленно относиться к возможному заражению.

Если вас укусила подозрительная собака (или милый уличный котёнок) обратитесь в травмпункт. В детстве нас пугали 40 уколами в живот, но современные вакцины требуют 3-6 уколов в плечо, пережить можно. Можете конечно ничего не делать, ведь не от каждого укуса получают заражение (вероятность 30% в случае собак). Но это как играть в русскую рулетку с двумя патронами в револьвере оно вам надо?

Карикатура 1826 года: бешеный пес на улицах Лондона. Покусанная женщина скорее всего уже не жилец:


А я перехожу к истории создания вакцины от бешенства. В конце статьи расскажу про вклад русских учёных. Перенесёмся в Париж, в восьмидесятые годы 19 века.

Последний подвиг Пастера


Знаменитому французскому химику и микробиологу Луи Пастеру уже за шестьдесят. За 15 лет до этого он пережил инсульт, парализовало левую половину тела. Восстанавливался несколько месяцев, смог снова ходить, но опыты в лаборатории с тех пор проводит только руками учеников. Позади десятки лет служения науке, может пора на покой?

Но Пастер хочет научиться спасать людей. Самый страшный враг инфекционные болезни. Трое детей Пастера умерли от брюшного тифа, так что к микробам у него личные счёты.

Проблема в том, что врачи как-то не спешат исследовать микробную версию происхождения болезней. Им проще развивать привычную теорию миазмов дескать, все болезни из-за плохого воздуха. А прорывные открытия в медицине приходится делать химику Пастеру.

В юности он исследовал проблемы виноделия и установил, что брожение это не химический процесс, а биологический, там замешаны и грибки, и бактерии. Придумал, как сделать так, чтобы вино не скисало тем самым спас винодельческую отрасль Франции (а заодно и возродил отечественное пивоварение).

Придумал пастеризацию теперь продукты можно было хранить и перевозить на большие расстояния (к вопросу о спасении людей одно только пастеризованное молоко позволило резко сократить детскую смертность).

Далее Пастер переключился на болезни шелковичных червей. Открыл двух микробов-возбудителей, разработал методы профилактики и лечения, спас мировую индустрию шёлка.

Тренировка на овцах


Следующий успех был в области ветеринарии: Пастер научился спасать животных от смертельных инфекций, победил куриную холеру и сибирскую язву. И вообще впервые описал, как работает приобретённый иммунитет.

За сто лет до этого уже изобрели первую вакцину для людей это была прививка от оспы. Берём неопасный для человека вирус коровьей оспы, заражаем человека, в результате он получает иммунитет к опасной человеческой версии. Проблема была в том, что этот принцип не догадались перенести на остальные опасные болезни.

Метод Пастера в общем виде состоял в следующем:
  1. Берём заболевших животных, пытаемся выделить биологическую жидкость с микробом
  2. Заражаем этой жидкостью здоровых животных, убеждаемся, что они заболели
  3. Повторяем десятки раз
  4. ??????
  5. PROFIT!

А в чём профит, спросите вы? В том, что мы получаем стабильную версию возбудителя, с которой можно работать. Следующая задача ослабить микроб, сделать его неопасным. Потом можно вколоть неопасную версию здоровым животным и посмотреть, разовьётся ли у них иммунитет после укола.

Подход сработал. С куриной холерой помогло просто подержать бульон с микробом на воздухе пару дней. Привитые этим бульоном куры не заболевали.

Возбудителя сибирской язвы получилось ослабить с помощью карболовой кислоты (стоит упомянуть, что основную работу по описанию сибирской язвы проделал немецкий бактериолог Роберт Кох. Он же научился выращивать бактерию в колбе с бульоном. Команда Пастера взяла готовые результаты и применила к ним свой метод создания вакцины).

А дальше последовал публичный эксперимент: на большой ферме взяли стадо овец и разделили на две половины, одних привили вакциной, других оставили в качестве контрольной группы. Опыт инициировал ветеринар Россиньоль, который не верил в микробов.
Через три недели в присутствии наблюдателей всему поголовью ввели смертельный штамм сибирской язвы.

Сибирская язва развивается быстро через два дня животные из контрольной группы были мертвы. Из привитых никто не погиб.

Эксперимент оказался убедительным, скептики были посрамлены. Правительство дало добро на промышленное производство вакцины, через три года во Франции было привито 3 миллиона овец. А Пастер и его команда переключились на следующую болезнь из списка.

Неудача с холерой


В 1883 году четыре сотрудника лаборатории выехали в Египет, где разразилась эпидемия холеры. Несколько месяцев они пытались повторить метод: брали материал больных людей и пытались заразить подопытных животных: мышей, кур, собак и обезьян. Ничего не получалось, животные не заболевали. Увидеть возбудителя в микроскоп также не удалось. В процессе опытов заразился и умер член команды Луи Тюилье. Работу пришлось сворачивать.

Создание вакцины от бешенства


Перспективнее было заняться болезнью, которой болеют и люди, и животные. Уже пару лет команда Пастера занималась бешенством. После неудачи с холерой решено было переключить всё внимание на этот проект.

Болезнь была известна с древности. С одной стороны, врачи знали, что бешенство смертельно и шансов на выздоровление нет. С другой стороны, собирали и записывали услышанные методы лечения, авось пригодятся. Тут тебе и прижигания укусов, и прокалывание пузырьков под языком, всевозможные снадобья. Зачем это было записывать, если любой врач мог убедиться, что метод не работает непонятно. Шарлатанов выручала статистика ведь после укуса был шанс, что человек не заразился. Тогда выжившего человека можно предъявлять как доказательство эффективности снадобья.

(в средневековой Франции с больными, у которых проявились симптомы, поступали просто душили человека между двумя матрасами. Отменили эту практику только при Наполеоне)

Как видите, поле для исследователя было непаханое. Вооружаемся методом Пастера, но предстоит решить две проблемы:

Проблема#1 непонятно, как гарантированно заражать подопытных собак и кроликов. Ясно, что возбудитель содержится в слюне, но уколы слюной результата не дали. То же самое с переливанием крови заражённых.

Если вирус в конечном счёте поражает нервную систему, может поискать его там? Получилось. Если взять кусочек мозга умершего животного и положить в мозг здоровому (для этого надо сделать трепанацию), то заражение происходит. А дальше берём материал уже от этого животного, пересаживаем следующему и т.д. Последовательным заражением получаем вирус с нужными нам свойствами. Проще всего было работать с кроликами в лаборатории закипел конвейер по извлечению кроличьих мозгов.

Проблема#2 долгий инкубационный период бешенства. При заражении можно ждать и неделю, и месяц, пока симптомы проявятся.
Чтобы получить стабильный вирус, нужно провести десятки перезаражений так можно и годы потратить на это.

Стали отбирать те образцы возбудителя, которые проявляют симптомы раньше всех. И через несколько десятков перезаражений получили стабильный штамм, который проявлялся через 7 дней. Вирус стал злее и опаснее.
Звучит страшновато!

Пастер и кролики. (если вы представляете картину с кроликами-мутантами, которые готовы вырваться на волю и всех перекусать в реальности было не так страшно. У кроликов развивалось паралитическое бешенство, они тихо-мирно умирали в своих клетках)

Оставался последний штрих сделать из смертельного вируса неопасный. Результата добились обычной сушкой. Вытаскивали спинной мозг кролика и сушили в стерильной колбе. Чем больше дней сушатся мозги тем слабее вирус.

Набор юного микробиолога. На дне колбы каустическая сода, которая забирает влагу:


Дальше выясняем, как долго нужно сушить препарат, пока вирус не потеряет силу (ответ 14 дней).
Если вводить собакам убитый возбудитель, они не заболевают.
Если вводить недосушенный заболевают и умирают.
Теперь попробуем ввести препараты в порядке убывания (14, 13, 12 дней и т.д.). И собака не умерла! Более того, получила иммунитет если ей теперь вводить живую версию вируса, собака останется жива.

Пара лет ушла на отработку точной схемы прививок в итоге Пастер был готов повторить публичный эксперимент, на этот раз с двумя группами собак.
Бешеную собаку запустили в оба вольера, чтобы она всех перекусала.
Опыт удался после заражения привитые собаки выжили, а из непривитых заразилась и умерла половина группы, как и положено по статистике. После такого доказательства команде Пастера предоставили просторные помещения, здания бывших конюшен. Можно было производить вакцину в больших количествах.

Но только как её применять? Первоначальный план был привить всех собак во Франции, как получилось с овцами. Тогда и вирус бешенства перестанет циркулировать среди животных, исчезнет опасность для людей. Беда в том, что прививка должна быть многократной собаку придётся держать в стационаре 40 дней. Даже с домашними собаками так не получится, не говоря о бродячих. Да и на производство вакцины для всех собак не хватит кроликов, слишком малый выход препарата. Как же спасти людей от болезни?

Вакцинация после заражения


И вот тут пришло озарение. У природного вируса долгий инкубационный период. У лабораторного короткий. Если человека укусила собака, что, если вколоть ему вакцину до того, как проявились симптомы?


В колбе те самые кроличьи мозги.

Сказано, сделано. Проверили гипотезу на укушенных собаках работает.
Вот итог пятилетних изысканий действующая вакцина от бешенства.

Теперь нужно испытать на людях. Случай подворачивается очень быстро Пастеру привозят девятилетнего мальчика, искусанного бешеной собакой. Ран так много, что он точно не выживет без вакцины, терять нечего. Курс уколов завершается успешно, мальчик выжил.
Потом второй пациент, успех. В конце 1885 года после официального доклада перед Академией наук Пастер начинает вакцинировать укушенных людей.

Русские у Пастера


Первым русским пациентом Пастера был кавалерийский офицер из Петербурга, укушенный бешеной собакой. В Париж его направил непосредственный командир, принц А.П. Ольденбургский.

Это было ещё в ноябре 1885, офицер выздоровел. В дальнейшем принц станет основателем и главным спонсором института экспериментальной медицины в Санкт-Петербурге.

В то же время одесское общество врачей собирает средства, чтобы отправить своего представителя на обучение и практику к Пастеру. Выбор падает на Николая Фёдоровича Гамалею, молодого, но уже опытного инфекциониста.


Нашему герою в то время 27 лет. Путёвку в Париж получил по настоятельной рекомендации Ильи Мечникова.


С собой в Париж Гамалея привёз пациента, укушенного мальчика. После курса прививок мальчик выжил, а сам Николай Фёдорович активно включился в работу лаборатории.

В Москве врачи провернули аналогичную комбинацию командировали в Париж ординатора Н.М. Унковского.

В течении всего 1886 года из России приезжали пациенты, а сопровождавшие их доктора часто оставались на стажировку у Пастера.

Придёт бешеный волчок и укусит за бочок


История про Пастера и смоленских крестьян известная, и часто повторяется в разных версиях. Бешеный волк покусал 19 человек в окрестностях города Белого (тогда Смоленская губерния). При волчьих укусах заражение происходит в 80% случаев, судьба крестьян была незавидной.

(за 10 лет до этого такой же случай был в Пензенской губернии. Тогда погибли 37 человек)

Повезло, что среди интеллигенции города Белого нашёлся человек, который читал об изысканиях Пастера (полезно интересоваться научпопом). Он же предложил отправить телеграмму в Париж. И в тот же день они получили ответ от Пастера приезжайте немедленно. Дальше пришлось бороться с бюрократией. Отписали губернатору, тот доложил министру внутренних дел пока шла переписка, утекало драгоценное время.

Министр финансировать поездку за счёт бюджета отказался если все начнут ездить в Париж за казённый счёт, тут никаких денег не напасёшься!

Собирать деньги смс-ками тогда ещё не придумали, поэтому в Белом объявили сбор среди жителей. Все скинулись, плюс городская дума опустошила свой бюджет. На седьмые сутки больные погрузились в сани и отправились в Смоленск.
Там прождали ещё пару дней, пока оформлялись бумаги, и наконец сели в поезд. Губернатор помог с паспортами и бесплатными билетами.
(иногда пишут, что крестьяне пришли в Париж пешком. Это конечно не так)

К Пастеру в Париж прибыли только на 14-й день после заражения. Им немедленно начали колоть курс прививок.

В середине курса проявились признаки болезни у одного из укушенных, через три дня он умер. До этого Пастер пролечил уже несколько сотен человек, это был второй случай смерти среди привитых. Нужно было разбираться. Череп умершего вскрыли (при этом нашли кусок волчьего зуба), эмульсию мозга вкололи кроликам и морским свинкам на 7й день они были живы. Значит, больной умер не от вируса из прививки, а от волчьего укуса.

Понаблюдали за заражёнными животными симптомы совпали с собачьим бешенством. Вывод волчий вирус тот же самый. Но ситуации для больных опаснее, т.к. волк часто кусает за голову и шею. Нужно было с самого начала ставить более сильную дозу. К сожалению, догадка пришла слишком поздно во время второго курса умерло ещё двое человек. Пастер распорядился сделать третий курс уколов больше смертей не было. После выздоровления крестьяне отправились домой.

Из России в этом году приезжали и другие пациенты, около сотни человек. А всего за 1886 год через клинику прошло 1600 пациентов со всей Европы.

Выздоровевшие крестьяне в Париже. Одного не хватает священника Анатолия Ершова. Он уехал раньше, делать операцию на лице, т.к. сильно пострадал от укусов.

Случай с тремя умершими русскими повлиял на решение Пастера о создании прививочных станций в других странах. До этого он хотел прививать от бешенства только в Париже, под контролем своей команды. Что, если врач в другой стране проявит небрежность и пациенты погибнут? Эти смерти были бы на его совести. Но теперь выяснилось, что укусы волков гораздо опаснее, и люди могут просто не добраться до Парижа. А если доберутся и прививка не сработает из-за потери времени эти смерти также будут на его совести.

Первые прививочные станции

В итоге Пастер дал добро на создание прививочных станций в крупных городах по всей Европе. Первую такую лабораторию создал Гамалея в Одессе, уже в июне 1886 года. В том же году в Москву вернулся Унковский, в Петербург доктор Воинов. Каждый вёз в багаже клетки с кроликами, заражёнными стабильной версией вируса.

Теперь пострадавшим от укусов не нужно было ехать в Париж. Достаточно было добраться до ближайшей прививочной станции. К сожалению, поддержки правительства не было, станции открывались на частные пожертвования.

Статистика работы первых прививочных станций в России. Процент умерших в целом сравним с парижской клиникой.


Каждая лаборатория со временем превратилась в полноценный научный центр.
Результаты работы русских станций и накопленный опыт здорово выручили Пастера, когда через пару лет ему пришлось бороться с антипрививочниками.

Последняя война со скептиками


В 1886 году Пастер был популярен в народе и имел репутацию спасителя. Но любая оплошность и симпатии публики развернутся в другую сторону. А журналисты с удовольствием раздуют из трагедии сенсацию.

В Италии произошло то, чего опасался Пастер местный профессор не рассчитал дозировку и вколол пациентам живой вирус. В результате 5 человек погибли от самой прививки. После этого правительство Италии закрыло станцию. В остальных странах смертность привитых держалась на уровне 1-4%, но среди умерших стали попадаться случаи с необычными симптомами. Не проявлялись обычные признаки водобоязни, люди просто умирали. Похоже на паралитическое бешенство у кроликов. Всё ясно, виновата прививка!

В Англии создали специальную комиссию для проверки этих случаев.
Пастер попросил помощи у Николая Гамалеи. Гамалея провёл в Англии несколько месяцев и выяснил следующее:
  1. В описанных случаях смертей не было исследования штамма на кроликах. Как только исследования стали проводить, выяснилось, что лабораторный штамм ни при чём, люди умирали от собачьего вируса.
  2. Симптомы паралитического бешенства у людей действительно встречаются.
    Только так бывало и раньше, просто никто такую смерть не вписывал в графу бешенство, если не было явной связи с укусами животных.
    То есть это не прививки виноваты, а просто раньше о таких проявлениях болезни не знали.

Плюс Гамалея предоставил комиссии результаты работы русских лабораторий. Комиссия была удовлетворена и рекомендовала правительству разрешить работу прививочных станций в Англии.

Оставалось выиграть аппаратную борьбу в Парижской академии наук и победить в дискуссии с противниками микробной теории. Основной аргумент звучал так: от ваших прививок никакой пользы. Сейчас от бешенства умирает столько же народу, сколько и раньше, вы просто любите ставить людям бесполезные уколы.
Ну ещё бы, раньше статистика не велась и сколько людей умирало от бешенства, никто не знал. А вот наши доказательства, вот результаты экспериментов, вот данные по спасённым людям. Заткнитесь и не мешайте работать.

И на некоторое время антипрививочники действительно заткнулись. Пастеру удалось собрать средства на создание целого института микробиологии. Пожертвования шли со всего мира, солидный взнос внёс русский император. Институт заработал, одно из направлений возглавил Илья Ильич Мечников, будущий нобелевский лауреат.

Последнюю битву Луи Пастер выиграл, во многом благодаря помощи русских учёных.


Пара выводов для читателей:
  1. Если вы завели собаку или кошку (или подобрали на улице) не сочтите за труд, сделайте животному прививку от бешенства.
  2. Если вас укусили сходите в травмпункт. Особое внимание если вы нашли следы на теле ребёнка. Маленькие дети иногда могут скрыть, что их укусила собака или поцарапала уличная кошка. Больное животное может выглядеть здоровым, а слюна его уже заразна. Как и сто лет назад чем раньше обратиться за помощью, тем выше шансы на благоприятный исход.
  3. Если в клинике нет антирабических препаратов (а такое, увы, встречается) не поленитесь, съездите туда, где они есть.

На этом всё, берегите себя

Автор: Юрий Деточкин, специально для блога Маклауд
Источники:
Шевелев А. С., Николаева Р. Ф. Последний подвиг Луи Пастера. М.: Медицина, 1988
Е. В. Шерстнева. Первые пастеровские станции в России. Проблемы социальной гигиены, здравоохранения и истории медицины, 2012
Карапац М.М., Краева Л.А. Ученики Пастера из России. Инфекция и иммунитет, 2018
Фотоколлекция на сайте Института Пастера
В. Рыкова. Смертоносный кусь. Биомолекула, 2018.




Автор этой статьи Юрий Деточкин. Мы благодарим автора за статью.

Облачные серверы от Маклауд быстрые и надежные. Без древнего железа.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Перевод 30 лет Линукса. Интервью с Линусом Торвальдсом. Часть 1

04.05.2021 10:05:07 | Автор: admin


Тридцать лет назад Линусу Торвальдсу был 21 год, он был студентом Хельсинского университета. Именно тогда он впервые выпустил ядро Linux.Анонс этого события начинался так: Я делаю (свободную) операционную систему (просто в качестве хобби, большой и профессиональной она не будет). Три десятилетия спустявсе топ-500 суперкомпьютеров в мире работают под Linux, равно как и более 70% всех смартфонов. Linux явно стал и большим, и профессиональным.

В течение тридцати лет Линус Торвальдс руководил разработкой ядра Linux, вдохновив бесчисленное множество других разработчиков и опенсорсных проектов. В 2005 году Линус также создал Git, чтобы было проще управлять процессом разработки ядра, с тех пор Git превратился в популярную систему контроля версий, которой доверяют бесчисленные опенсорсные и проприетарные проекты.

Следующее интервью одна из серии бесед с лидерами опенсорса. Линус Торвальдс ответил на вопросы по электронной почте, поразмышляв о том, что он узнал за годы руководства большим опенсорсным проектом. В первой части акцент сделан на разработке ядра Linux и Git. [Linux] был личным проектом, который вырос не из какой-нибудь большой мечты создать новую операционную систему, объясняет Линус, а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.

Что касается создания Git и его последующей передачи Джунио Хамано для дальнейшей доработки и поддержки, Линус отметил: Не собираюсь утверждать, что программирование это искусство, поскольку на самом деле это большей частью просто хорошая инженерия. Я горячо верю в мантру Томаса Эдисона об одном проценте таланта и девяноста девяти процентах упорного труда: почти все зависит от мелких деталей и ежедневной рутинной работы. Но есть и эта эпизодическая составляющая, называемая талант, этот хороший вкус, который сводится не только к решению какой-либо задачи, но и к стремлению решить ее чисто, аккуратно и да, даже красиво. У Джунио есть как раз такой хороший вкус.

Итак, читайте первую часть этого интервью (есть и вторая). В оригинале она выходит через неделю после первой, и во второй части Линус исследует те уроки и озарения, которые приобрел за три десятилетия во главе разработки ядра Linux.

Разработка ядра Linux


Джереми Эндрюс: Linux повсюду, он вдохновил целый мир опенсорса. Разумеется, так было не всегда. Вы прославились тем, что выпустили ядро Linux еще в 1991 году, скромно сообщив об этом в Usenet в разделе comp.os.minix. Десять лет спустя вы написали увлекательную и глубоко личную книгу под названием Ради удовольствия: Рассказ нечаянного революционера, где разобрали большую часть этой истории. В августе этого года Linux празднует тридцатилетие! Это захватывающе, поздравляем! В какой момент на вашем пути вы осознали, что Linux это уже гораздо больше, чем просто хобби?

Линус Торвальдс: возможно, прозвучит слегка потешно, но, на самом деле, это произошло очень рано. Уже к концу девяносто первого (и определенно к началу девяносто второго) Linux вырос значительно сильнее, чем я ожидал.


Да, на тот момент у Linux было, пожалуй, всего несколько сотен пользователей (и даже пользователей слишком громко сказано люди просто возились с ним), и это, возможно, звучит странно, учитывая, насколько Linux вырос впоследствии. Но во многих отношениях, для меня лично, большой поворотный момент наступил, когда я осознал, что другие люди в самом деле пользуются Linux, заинтересованы им, и операционная система начала жить своей жизнью. Люди начали присылать патчи, и система начала делать гораздо больше, чем я изначально мог представить.

Думаю, X11 была портирована на Linux где-то в апреле девяносто второго (не верьте мне на слово, когда я припоминаю даты слиииишком давно дело было), а еще один серьезный шаг свершился, когда у системы вдруг появился GUI и целый новый набор возможностей.

Чтобы дать широкий контекст скажу, что в самом деле не начинал с наполеоновских планов или больших ожиданий. Это был личный проект, который вырос не из какой-нибудь большой мечты создать новую операционную систему, а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.

Поэтому, когда я выпустил ту самую первую версию, посыл в самом деле был смотрите, что у меня получилось и, разумеется, я надеялся, что другие найдут мою работу интересной, но это не была по-настоящему серьезная, практически-ориентированная ОС. Это была скорее проверка концепции и просто личный проект, который я к тому моменту разрабатывал уже несколько месяцев.

Причем, переход от этого личного проекта к продукту, который оказался по-настоящему востребован у других, по которому мне стала приходить обратная связь (и багрепорты), а также кое-какие патчи все это стало для меня большойпеременой.

Просто пример одного по-настоящему фундаментального аспекта: исходная лицензия на копирайт формулировалась примерно так: допускается распространение в виде исходников, но не за деньги.

Дело в том, что для меня одна из проблем заключалась в реальной дороговизне коммерческого Unix (да, для бедного студента, потратившего все деньги на новый ПК, так и было), поэтому для меня было серьезно и важно обеспечить доступность исходного кода (так, чтобы люди могли с ним пошаманить), и я хотел, чтобы проект оставался открытым для людей вроде меня, которые просто не могли позволить себе альтернатив.

И я изменил лицензию в конце девяносто первого (или, может быть, в самом начале девяносто второго), поскольку нашлись те, кто хотел распространять систему на дискетах в локальных группах пользователей Unix, но при этом хотя бы отбить расходы на дискеты и компенсировать себе время, потраченное на копирование. Причем, я понял, что это, очевидно, совершенно оправданно, и что важнее всего было обеспечить не полную бесплатность, а свободную доступность исходников.

К чему это привело: мало того, что люди стали распространять Linux на собраниях в группах пользователей Unix, но и в считанные месяцы появились первые дистрибутивы для дискет, например, SLS и Slackware.

По сравнению с теми первыми, по-настоящему фундаментальными изменениями, все дальнейшие можно считать пошаговыми. Разумеется, некоторые из этих шагов были весьма велики (систему взяла на вооружение IBM, под мою систему портировали Oracle DB, состоялись первичные коммерческие предложения Red Hat, Android расцвел на смартфонах, т.д.), но лично мне эти события все равно казались не столь революционными, как люди, которых я даже не знаю, уже используют Linux.

Дж. А.: Вы когда-нибудь сожалели, что выбрали именно такую лицензию, либо завидовали тому, какие деньги сделали другие люди и компании на вашем детище?


ЛТ: Ничуть.

Во-первых, мне вполне хватает. Я не баснословно богат, но я хорошо оплачиваемый программист, занимаюсь любимым делом, сам составляю себе расписание. Не бедствую.

Но не менее важно, что я на 100% уверен: именно такая лицензия во многом определила успех Linux (и Git, если уж на то пошло). Думаю, всем причастным гораздо приятнее знать, что все в равных правах, и никого такая лицензия не выделяет.

Существует немало таких проектов с двойной лицензией, где за исходным владельцем остается коммерческая лицензия (можете использовать это в вашем проприетарном продукте при условии, что будете отчислять нам роялти), но, с другой стороны, продукт также доступен по GPL-подобной лицензии для использования в опенсорсных проектах.

Думаю, в такой ситуации действительно сложно выстроить сообщество, так как те, кто занимается опенсорсом, всегда будут сознавать, что они второй сорт. Плюс такая ситуация порождает массу лицензионной бумажной волокиты, чтобы избранные всегда сохраняли свои особые права. Таким образом, в проекте возникает серьезная пробуксовка.

С другой стороны, я видел много лицензированных опенсорсных проектов от BSD (или MIT, или т.п.), которые просто фрагментируются, как только становятся достаточно крупными и приобретают коммерческую важность, а компании, причастные к таким проектам, неизбежно решают запатентовать принадлежащие им фрагменты.

Итак, я считаю, что GPLv2 дает практически идеальный баланс все работают, и правила для всех одинаковы, но при этом все равно требует от людей отдачи сообществу (долг платежом красен). Причем, каждый знает, что все остальные люди, вовлеченные в проект, подчиняются одним и тем же правилам, поэтому весь процесс очень равноправный и честный.

Разумеется, обратный эффект заключается в том, что и вы получаете что-то от проекта, в который вложили силы. Разумеется, можно попытаться запрыгнуть на хвост проекту и оставаться обычным пользователем, почему нет. Но, избрав такой путь, вы нисколько не будете контролировать проект. Это также может быть вполне нормально, если вам нужна всего лишь непритязательная операционная система, а Linux уже делает все, что вам надо. Но, если у вас есть особые требования, то единственный реальный способ влиять на проект это участвовать в нем.

При таком подходе все честны. Включая меня. Каждый может сделать форк проекта и пойти своим путем, сказать: пока, Линус, у меня есть своя версия Linux, и ее поддержку я беру на себя. Я особенный только потому что и только до тех пор, пока люди доверяют мне за хорошо сделанную работу. Именно так и должно быть.

То, что каждый может поддерживать собственную версию вызывало у некоторых беспокойство по поводу версии GPLv2, но я вижу в этом достоинство, а не недостаток этой лицензии. Несколько парадоксально, но я считаю, что именно это и уберегло Linux от фрагментации: ведь каждый может сделать собственный форк проекта, и это нормально. На самом деле, именно в этом заключается один из ключевых принципов, на основе которых спроектированGit каждый клон репозитория это самостоятельный маленький форк, и люди (а также компании) ответвляют собственные версии, именно так и совершается весь процесс разработки.

Итак, форки не проблема, если потом при слиянии вы добавите в основную ветку только то, что получилось хорошо. Именно здесь вступает в дело GPLv2. Право сделать форк и развивать собственный проект очень важное, но в равной степени важна и другая сторона медали право впоследствии снова объединиться, если форк показал себя успешным.

Другая проблема в том, что вам по-настоящему нужны только инструменты для поддержания интересующего вас потока задач, но при этом вам также нужен подходящий менталитет для поддержки этого проекта. Серьезным препятствием для возвращения форков в общий проект являются не только вопросы лицензирования, но и дурная кровь. Если форк создается из чувства глубокого противоречия родительской ветке, то объединить две ветки обратно может быть очень сложно, причем, дело не в лицензировании и не в технических причинах, а в том, что форк был столь несочетаем с исходной версией. Опять же, думаю, что в Linux такого удалось в основном избежать, поскольку мы всегда относились к созданию форков как к делу совершенно естественному. Поэтому естественно воспринимается и обратное слияние, если какая-то работа успешно прошла проверку практикой.

Итак, отвечая на вопрос, я немного ушел в сторону, но считаю, что это важное отступление. Я решительно не жалею о том, какую лицензию выбрал, поскольку действительно считаю, что в GPLv2 заключается огромная часть успешности Linux.

На самом деле, деньги не столь серьезный мотиватор. Они не сплачивают людей. Думаю, что, если работаешь над общим проектом и чувствуешь, что реально можешь быть полноправным партнером в рамках этого проекта, то именно это и мотивирует людей.

Дж.А.: В наши дни, если кто-то выпускает исходный код по лицензии GPLv2, то делает это в основном ради работы с Linux. Как вы нашли лицензию, и сколько времени и сил у вас ушло на изучение других существующих лицензий?


ЛТ: В те времена в сообществе еще бушевали серьезные флеймы по поводу BSD и GPL (думаю, отчасти они разжигались из-за того, что у rms настоящий талант бесить людей), так что я встречал разные дискуссии на тему лицензирования только в разных новостных группах usenet, которые я читал (такие источники, какcomp.arch,comp.os.minixи т.д.).

Но двумя основными поводами были, пожалуй, банальный gcc который очень и очень поспособствовал тому, чтобы Linux набрал ход, поскольку мне был абсолютно необходим компилятор для C и Ларс Виржениус (Ласу), другой шведскоязычный студент с факультета компьютерных наук, с которым мы учились в университете на одном курсе (шведскоязычное меньшинство в Финляндии очень невелико).

Ласу гораздо активнее участвовал в дискуссиях по лицензированию и т.п., чем я.

Для меня выбор GPLv2 не был огромной дипломатической проблемой, а был обусловлен в основном тем фактом, что моя изначальная лицензия была столь импровизированной, и ее требовалось обновить, а еще я чувствовал себя в долгу перед gcc, и GPLv2 соответствовала моим ожиданиям исходники нужно отдавать.

Итак, вместо того, чтобы сделать другую лицензию (или просто отредактировать оригинальную, убрав формулировку запрещаются денежные операции такой вариант тоже рассматривался), я хотел выбрать такую, которая была бы уже известна людям, и я хотел привлечь к ее разработке юристов.

Дж. А.: Каков ваш обычный день? Сколько времени вы тратите на написание кода, по сравнению с ревью кода и чтением/написанием электронной почты? Как вы находите баланс между личной жизнью и разработкой ядра Linux?

ЛТ: Сейчас я пишу очень мало кода, долго не писал. А когда я все-таки пишу код, чаще всего я оказываюсь в ситуации, когда разворачивается дискуссия о какой-либо конкретной проблеме, я вношу изменения и отсылаю их в виде патча, в основном в качестве пояснения предложенного решения.

Иными словами, основной объем кода, который я пишу, скорее сводится к посмотри, а мы это делаем вот так и в данном случае патч очень конкретный пример. Легко увязнуть в какой-нибудь теоретической высокоуровневой дискуссии о том, как решить какую-нибудь задачу, и, на мой взгляд, что наилучший способ описать решение просто привести фрагмент кода, может быть, не весь код и максимально выпятить его именно таким образом.

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

Да, я уделяю время и ревью кода, но, честно говоря, к тому времени, как я получаю пул-реквест, код, вызвавший вопросы, уже успевает просмотреть множество других людей. Поэтому, хотя я и просматриваю патчи, больше внимания я уделяю объяснениям и истории патча, как он пришел ко мне. Причем, с людьми, с которыми мы работаем достаточно давно, я обхожусь даже без этого: все они занимаются поддержкой тех подсистем, за которые отвечают, и микроменеджмент по контролю их работы не мое дело.

Итак, весьма часто моя работа заключается в том, чтобы просто присутствовать, играть роль концентратора, того человека, который управляет релизами и следит за соблюдением правил. Иными словами, моя работа в большей степени связана с процессом поддержки, а не с низкоуровневым кодом.

Дж.А.: Какова ваша рабочая обстановка? Например, комфортнее ли вам работать в затемненной комнате, где ничего не отвлекает, либо в комнате с видовым окном? Вы склонны работать в тишине или под музыку? Какое аппаратное обеспечение вы обычно используете? Выполняете ревью кода в vi, в окне терминала или в навороченной IDE? И есть ли такой дистрибутив Linux, который вы предпочитаете для данной работы?


ЛТ: не могу сказать, что у меня в комнате темно, но я действительно прикрываю шторами окно у рабочего места, поскольку яркий солнечный свет мне не нравится (правда, в этот сезон в Орегоне его и так не слишком много;). Так что никаких панорам, только (заваленный) стол с двумя 4k мониторами имощным ПК под столом. И еще пара ноутбуков под рукой, для тестирования и на случай, если какая-то работа прилетит мне в дороге.

И я хочу работать в тишине. Возненавидел щелканье механических винчестеров, к счастью, они давно отправлены в утиль, поскольку я давно переключился на работу исключительно с SSD, вот уже более десяти лет как. Шумные процессорные вентиляторы для меня также неприемлемы.

Вся работа делается в традиционном терминале, хотя, я и не пользуюсь 'vi'. Я работаю с этим убогим micro-emacs, который не имеет ничего общего с emacs от GNU, с той оговоркой, что некоторые привязки клавиш у них похожи. Я привык работать с этим редактором еще в Хельсинском университете, будучи юнцом, и так и не смог от него отучиться, хотя, подозреваю, вскоре мне придется это сделать. Несколько лет я сварганил для него (очень ограниченную) поддержку utf-8, но редактор уже старый, и во всех его аспектах сквозит, что написан он был в 1980-е, а та версия, которой пользуюсь я это форк, не поддерживаемый с середины 90-х.

В Хельсинском университете этот редактор использовался, поскольку он работал под DOS, VAX/VMSиUnix, почему и мне довелось с ним познакомиться. А теперь он просто вшит мне в пальцы. На самом деле, давно пора переключиться на какую-то альтернативу, которая исправно поддерживается и как следует воспринимает utf-8. Пожалуй, попробую 'nano'. Мой же наспех слепленный антикварный мусор работает на том уровне вполне приемлемо, что у меня не возникало острой нужды переучивать мои старые пальцы на новые фокусы.

Итак, моя настольная рабочая среда весьма безыскусна: открыто несколько текстовых терминалов, еще браузер с почтой (плюс еще несколько вкладок, в основном с техническими и новостными сайтами). Я хочу, чтобы значительная часть рабочего стола была свободна, поскольку привык работать с достаточно большими окнами терминалов (100x40 можно сказать, таков у меня исходный размер окна по умолчанию), и у меня бок о бок открыто несколько окон терминала. Поэтому работаю с двумя мониторами по 4k.

На всех моих машинах я использую Fedora, не потому, что этот дистрибутив для меня однозначно предпочтителен, а потому, что я к нему привык. Меня не особо волнует выбор дистрибутива, я расцениваю дистрибутив в основном как вариант установки Linux на машине, как среду, в которой настроены все мои инструменты, так, чтобы я мог просто заменить ядро и сосредоточиться на работе с ним.

Дж. А.: Публичное обсуждение разработки ядра происходит впочтовой рассылке по ядру Linux, и трафик там запредельный. Как вы успеваете разгребать столько почты? Вы исследовали другие решения для совместной работы и коммуникации вне почтовой рассылки, либо простая почтовая рассылка чем-то идеально подходит для той работы, которую вы делаете?

ЛТ: О, я не читаю саму рассылку, посвященную разработке ядра, годами не читал. Там слишком много всего.

Нет, суть рассылки по разработке ядра в том, что она ставится в копию во всех дискуссиях (ладно -некоторыхрассылок по разработке ядра это касается, ведь их много и тогда традиционная lkml используется в качестве резервного варианта, если для заданного вопроса не находится более узконаправленная рассылка). Таким образом, когда к дискуссии подключается новичок, он может посмотреть историю и контекст проблемы, просто изучив рассылку, посвященную разработке ядра.

Таким образом, я привык, что подписан на эту рассылку, но вся почта из lkml, где я не указан в копии, у меня автоматически попадает в авто-архивацию, так что по умолчанию я ее не вижу. Но, когда какую-то проблему доводят до меня, я могу развернуть всю дискуссию по ней, поскольку она лежала у меня в электронной почте, а не просто во входящих, и ждала своего часа.

В настоящее время я предпочитаю использовать функционалlore.kernel.org, так как работает он очень хорошо, и вокруг него уже выстроены некоторые другие инструменты. Поэтому дискуссии можно не автоматически упаковывать в мои собственные почтовые архивы, а сохранять вот таким образом тогда они видны. Но общий поток задач концептуально остается прежним.

Действительно, я до сих пор получаю изрядное количество электронной почты, это очевидно, но за долгие годы ситуация во многих отношениях изменилась скорее к лучшему, чем к худшему. Во многом это благодаря Git и тому, как хорошо налажен процесс релизов ядра: раньше у нас было гораздо больше проблем с потоком кода и инструментальным оснащением. Ситуация с электронной почтой на рубеже веков у нас была гораздо, гораздо хуже, когда еще приходилось иметь дело с гигантскими связками патчей, и у нас были серьезные проблемы с масштабируемостью потока разработки.

Причем, модель с почтовой рассылкой (и сопровождающими ее инструментами) в самом деле работает очень хорошо. Я не о том, что люди не пользуются иными средствами коммуникации кроме электронной почты (имею в виду и личные переговоры, и участие в почтовых рассылках): многим очень нравятся различные чаты в режиме реального времени (традиционный вариант IRC). Причем, хотя это и никогда не было моим коньком, очевидно, что многим нравится метод мозгового штурма. Но модель с списком рассылки, используемым в качестве архива работает очень хорошо, и бесшовно сшивается как с рассылкой патчей от разработчика к разработчику в электронных сообщениях, так и с отправкой отчетов по проблемам в виде электронной почты.

Итак, электронная почта остается основным каналом связи, по ней удобно обсуждать технические проблемы, поскольку патчи встраиваются в ту же среду, что и письма. Причем, почта работает сразу во всех часовых поясах, а это очень важно, когда сообщество так сильно рассредоточено географически.


Дж.А.: Я пристально следил за разработкой ядра на протяжении примерно десяти лет,вел на эту тему блог в KernelTrap и писал о новых возможностях по мере их развития. Бросил заниматься этим примерно к моменту выхода версии ядра 3.0, выпущенной спустя 8 лет, когда выходили версии с номерами 2.6.x. Можете ли резюмировать, какие наиболее интересные события произошли с ядром после релиза версии 3.0?

ЛТ: Эх. Это было так давно, что я даже не знаю, с чего начать резюмировать. Прошло уже десять лет с момента выхода версии 3.0, и за это десятилетие мы успели внести много технических изменений. Архитектура ARM выросла, и ARM64 стала одной из наших основных архитектур. Много-много новых драйверов и новая базовая функциональность.

В любом случае, что самое интересное за последнее десятилетие как нам удалось удержать действующую модель разработки по-настоящему ровной, и что в ней не изменилось.

За десятилетия мы попробовали много разных схем версионирования, у нас были разные модели разработки, но релиз 3.0 фактически оказался именно тем, в котором окончательно оформилась модель, используемая нами с тех пор по сей день. В этой версии мы, так сказать, официально заявили, что релизы выпускаются по времени, номера версий это просто номера, и в них нет никаких зависимостей компонентов.

Мы затеяли всю историю с привязкой релизов ко времени и с окном по сведению патчей (merge window) во времена 2.6.x, поэтому сама эта инициатива не нова. Но именно в 3.0 последние реликты у номера есть значение были выброшены на свалку.

У нас была и случайная схема нумерации (в основном до версии 1.0), у нас была целая модель нечетные минорные номера соответствует версии ядра, которая находится в разработке, четные означают стабильное ядро, готовое к продакшену, после чего в версиях 2.6.x мы перешли к модели с привязкой релизов по времени. Но у людей по-прежнему оставался вопрос Что должно произойти, чтобы увеличился мажорный номер. И в версии 3.0 было официально объявлено, что четный мажорный номер версии не несет никакой семантики, и что мы всего лишь стараемся придерживаться простой нумерации, с которой было бы удобно обращаться, и которая бы чрезмерно не разрасталась.

Итак, за последние десятилетия мы внесли совершенно колоссальные изменения (в Git легко посмотреть некоторую статистику в числовом выражении: примерно три четверти миллиона коммитов, сделанных 17 тысячами участников). Но сама модель разработки остается весьма ровной и стабильной.

Так, конечно, было не всегда. Первые двадцать лет в истории разработки ядра были полны поистине болезненных перемен в модели разработки. Последнее десятилетие получилось гораздо более предсказуемым в плане выхода релизов.

Дж.А.: На настоящий момент последний релиз 5.12-rc5. Как стандартизирован процесс релизов? Например, изменения какого рода попадают в -rc1, по сравнению с -rc2 и так далее? И в какой момент вы решаете, что очередной релиз готов к официальному выходу? Что происходит, если вы ошиблись, и после финального релиза приходится серьезно отойти назад, и как часто это случается? Как этот процесс развивался с годами?

ЛТ: Выше я на это уже указывал: сам процесс в самом деле хорошо стандартизирован, и остается таким на протяжении последнего десятилетия. Перед этим произошло несколько серьезных потрясений, но с 3.0 он работает практически как часы (на самом деле, это началось еще на несколько лет ранее во многих отношениях переход на Git положил начало современным процессам, и потребовалось время, прежде, чем все к этому привыкли).

Поэтому у нас была такая каденция с двухнедельным окном по сведению патчей, за которым следует примерно 6-8 недель, затрачиваемых на изучение кандидатов для релиза; думаю, такие циклы поддерживаются уже на протяжении примерно 15 лет.

Правила тоже всегда были одни и те же, хотя, их не всегда требовалось соблюдать со всей строгостью: окно по сведению патчей предназначено для нового кода, который предположительно протестирован и готов, а затем в течение примерно двух последующих месяцев вносятся правки, и мы убеждаемся, что все проблемы действительно утрясены. Да, это происходит не всегда, и бывает, что предположительно готовый код приходится отключать или вообще выбрасывать прямо перед релизом.

Затем цикл повторяется поэтому релизы у нас происходят примерно с десятинедельным интервалом.

А критерии для релиза для меня заключаются в ощущении достаточной уверенности, которая, очевидно, в свою очередь основана на том, какие сообщения о проблемах по-прежнему продолжают приходить. Если в какой-нибудь области проблемы продолжают сохраняться на поздних этапах релизного цикла, то я весьма настойчиво требую все откатить и говорю займемся этим в одном из следующих релизов, когда как следует разберемся, что к чему, но в целом прибегать к таким мерам требуется достаточно редко.

Всегда ли такой процесс дает нужный результат? Нет. Как только релиз ядра состоялся, и особенно, когда релиз подхвачен ядром у вас появляются новые пользователи, люди, не тестировавшие релиз на этапе разработки, и они находят какие-то вещи, которые не работают, или которые мы не отловили в ходе подготовки релиза. Это во многом неизбежно. Отчасти именно поэтому мы держим целые деревья стабильных ядер, в которые после релиза продолжаем вносить правки. Причем, срок поддержки у одних стабильных ядер дольше, чем у других, такие долгоживущие ядра обозначаются аббревиатурой LTS (долгосрочная поддержка).

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

Дж.А.: В прошлом ноябре, по вашим словам, вас впечатлили новые чипсеты ARM64 от Apple, поставленные в некоторых из их новых компьютеров. Вы следите за этими разработками, чтобы поддерживать их под Linux? Вижу, workбыладобавлена в for-next. Вероятно ли, что Linux будет грузиться на оборудовании Apple MacBook уже с появлением готовящегося ядра 5.13? Станете ли вы одним из ранних пользователей? Насколько велика для вас важность ARM64?

ЛТ: я очень эпизодически проверяю, как с этим дела, но пока там все на очень раннем этапе. Как вы правильно отметили, самый ранний вариант поддержки, вероятно, будет добавлен в ядро 5.13, но учитывайте пожалуйста, что мы в самом начале пути, и аппаратное обеспечение Apple пока еще не годится дляполезной работыпод Linux.

Основную проблему представляет не сама arm64, а драйверы для аппаратного обеспечения, сопутствующего этой архитектуре (в особенности это касается SSD и GPU). На данном раннем этапе работы мы успели привести в работоспособный вид некоторые весьма низкоуровневые штуки, которые пока не приносят никакой реальной пользы кроме первичного запуска оборудования. Пройдет еще какое-то время, прежде, чем эти разработки станут реальным вариантом, который можно попробовать.

Но улучшилось не только аппаратное обеспечение Apple сама инфраструктура для arm64 значительно выросла, и ядра процессора изменились от ни о чем до вполне конкурентоспособной альтернативы для серверного пространства. Еще не так давно серверное пространство arm64 представляло собой весьма унылое зрелище, но процессоры Graviton2 от Amazon и Altra от Ampere оба основаны на значительно улучшенной версии ARM Neoverse IP гораздо лучше альтернатив, имевшихся на рынке несколько лет назад.

Я уже более десяти лет дожидался, пока появится удобная машина с ARM, и ее до сих пор нет, но сейчас до нее гораздо ближе, чем было когда-то.

На самом деле могу сказать, что хотел машину с ARM гораздо дольше, еще в подростковые годы, причем, по-настоящему желанна была Acorn Archimedes, но из соображений цены и доступности пришлось удовлетвориться Sinclair QL (процессор M68008), а затем, конечно же, через несколько лет я сменил ее на i386 PC.

Несколько десятилетий казалось, что такая машина уже не за горами, но в широкой доступности ее по-прежнему не было, а также я не мог предпочесть ее другим компьютерам по соображениям производительности/цены. Когда-нибудь она появится. Надеюсь, не в столь отдаленном будущем.

Дж.А.: есть ли в ядре какие-то аспекты, которые сделаны не лучшим образом, но, чтобы поправить их как следует, пришлось бы полностью переписывать код? Иными словами, ядру 30 лет, и за эти 30 лет значительно изменились наши знания, языки программирования аппаратное обеспечение. Если бы сейчас вы переписывали ядро с нуля, то что бы вы в нем изменили?

ЛТ: на самом деле, намвесьмахорошо удавалось даже целиком переписывать некоторые вещи, если была такая необходимость, поэтому все детали, которые казались необезвреженными бомбами, давным-давно переписаны.

Естественно, у нас есть изрядное количество слоев, которые оставлены для обеспечения совместимости, но обычно там не ужас-ужас. Причем, неясно, а исчезнут ли эти слои для совместимости, если переписать все с нуля ведь они нужны для обратной совместимости со старыми бинарными файлами (а зачастую и для обратной совместимости со старыми архитектурами, например, для запуска 32-битных приложений для x86 на x86-64). Поскольку я считаю обратную совместимость очень важной, я хотел бы сохранить их даже в переписанной версии.

Итак, очевидно, что у нас много вещей, которые реализованы не оптимально, в том смысле, что улучшить можно что угодно, но, учитывая, как вы сформулировали вопрос, я отвечу на него отрицательно в ядре нет ничего, чем я бы гнушался. Есть унаследованные драйверы, которыми никогда никто не озаботится хотя бы настолько, чтобы их подчистить, есть и другие уродливые вещи, но ключевой момент в том, что они никого особо не волнуют. Это все не проблемы, а если они превратятся в проблемы, то мы активно избавляемся от поддержки по-настоящему старого унаследованного кода, до тех пор, пока ситуация вновь не начинает всех устраивать. Так, с годами мы избавились от множества драйверов, и мы откажемся от поддержки целой архитектуры, если ее поддержка утратит какой-либо смысл.

Нет, единственная серьезная причина для переписывания могла бы возникнуть лишь в случае, если бы обнаружился некоторый практический кейс, в котором вся структура действительно не имеет смысла. Наиболее вероятным примером такого рода в реальности могла бы оказаться какая-нибудь маленькая встраиваемая система, которой не нужно ничего, что сегодня может предложить Linux, а на уровне аппаратного обеспечения ее отпечаток столь мал, что этой системе попросту нужно нечто помельче и попроще, чем операционная система, какой за годы развития стал Linux.

Ведь Linuxзначительновырос. Даже на небольших устройствах (вспомним мобильные телефоны, например) он сегодня гораздо мощнее, чем исходный Linux, который разрабатывался для машин своего времени.

Дж.А.: Как насчет хотя бы частично переписать ядро на Rust, языке, который разрабатывался именно с прицелом на производительность и безопасность? Есть ли пространство для улучшения в таком ключе? Как вы считаете, возможно ли, чтобы другой язык, например, Rust, заменил C в ядре?


ЛТ: Увидим. Не думаю, что Rustзакрепится в самой основе ядра, но писать на нем отдельные драйверы (или, может быть, целые подсистемы драйверов) не скажу, что это совершенно невероятно. Может быть, он и для файловых систем подойдет. Поэтому, скорее не заменить C, а дополнить наш код на C там, где это целесообразно .

Разумеется, на драйверы как таковые приходится примерно половина кода ядра, поэтому места для таких разработок много, но я не думаю, что кто-то в самом деле рассчитывает, что уже существующие драйверы будут переписаны на Rust целиком. Может быть, есть люди, желающие писать новые драйверы на Rust, а некоторые драйверы мы на нем действительно можем переписать, если это будет целесообразно.

Но прямо сейчас ситуация дошла только до люди пробуют его, играют с ним, не более. Легко подчеркивать преимущества, но здесь определенно есть и сложности. Поэтому я очень склонен подождать и понаблюдать, действительно ли обещанные сильные стороны Rust себя оправдают.

Дж.А.: Есть ли в ядре какие-либо конкретные элементы, которыми вы лично особенно гордитесь?

ЛТ: выдающиеся части, которые мне хочется лишний раз подчеркнуть это уровень VFS (виртуальная файловая система) (и поиск имени пути в частности) и наш код виртуальной машины. Первое просто потому, что в Linux некоторые из этих фундаментальных вещей (поиск имени файла по-настоящему базовая функциональность в операционной системе) выполнимы намного лучше, чем во многих других ОС. А второе в основном потому, что мы поддерживаем более 20 архитектур, и по-прежнему делаем это при помощи в основном унифицированного уровня виртуальной машины, что, на мой взгляд, весьма впечатляет.

Но, в то же время, все это во многом проистекает из какая из частей ядра вам наиболее интересна. Ядро достаточно велико, чтобы разные разработчики (и разные пользователи) просто придерживались разных мнений по поводу того, что в нем наиболее важно. Некоторым кажется, что планирование задач наиболее захватывающая функция ядра. Другим нравится вникать в тонкости драйверов устройств (а у нас таких много). Лично я сильнее вовлечен в работу над VM и VFS, поэтому, естественно, указываю на них.

Дж.А.: Я нашел вот такое описание поиска имени пути, и он сложнее, чем я ожидал. Почему реализация этой функции в Linux настолько лучше, чем в любых других операционных системах? И что для вас означает лучше?

ЛТ: Поиск имени пути это поистине настолько обычная и фундаментальная вещь, что почти никто вне круга разработчиков ядра не считает, что это проблема. Они просто открывают файлы и принимают это как должное.

Но на самом деле очень сложно добиться, чтобы это работало как следует. Именно потому, что поиск имени пути все время происходит буквально везде, и поэтому данная задача критически сказывается на производительности; кроме того, это именно та область, в которой требуется хорошо масштабироваться при работе в средах SMP, блокировки при выполнении таких задач сопряжены с немалой сложностью. А вы хотите свести к минимуму какие-либо операции ввода/вывода, поэтому кэширование это очень важно. На самом деле, поиск имени пути настолько важен, что его нельзя выполнять на низком уровне файловой системы, ведь у нас более 20 различных файловых систем, и реализация в каждой из них собственных механизмов кэширования и блокировок стала бы подлинной катастрофой.

Итак, одна из основных задач, решаемых на уровне VFS это обработка всего кэширования и всех блокировок, связанных с компонентами имени пути, а также с обработкой всех операций, касающихся сериализации и обхода точек монтирования, причем, все это делается в основном при помощи неблокирующих алгоритмов (RCU), а также с применением весьма умных сущностей, напоминающих блокировки (блокировка lockref, предусмотренная в Linux это очень особенная спин-блокировка с подсчетом ссылок, буквально предназначенная для кэширования dcache, и, в принципе, это специализированный механизм подсчета ссылок, учитывающий блокировки, который в определенных типичных ситуациях может выполнять исключение блокировок).

В итоге: низкоуровневые файловые системы все равно должны искать вещи, которые не кэшированы, но на их уровне не приходится беспокоиться о кэшировании и соблюдении правил согласованности и атомарности, которые должны соблюдаться при поиске имени пути. Уровень VFS все это обрабатывает за них.

Причем, в этом Linux успешнее, чем какая-либо другая операционная система, и это не мешает ему хорошо масштабироваться даже на машинах с тысячами CPU. Даже когда этим машинам приходится обращаться к одним и тем же каталогам (скажем, к корневому каталогу или домашнему каталогу проекта приходится одновременно обращаться даже в приложениях с сильно развитой многопоточностью, а такое по-поточное поведение не поддается какому-либо распределению).

Поэтому, здесь в Linux все не просто лучше, но даже Лучше с большой буквы Л. Ни одна другая система в этом и близко не сравнится с Linux. Механизм dcache просто единственный в своем роде.

Дж.А.: Прошлый год тяжело дался всему миру. Как пандемия COVID-19 повлияла на процесс разработки ядра Linux?

ЛТ: на самом деле, минимально, поскольку мы привыкли к такому режиму работы. Все-таки, электронная почта чудесный инструмент, позволяющий обходиться без оффлайновых совещаний.

Да, в начале года ситуация повлияла на саммит по разработке ядра (и в этом году он пока также остается в подвешенном состоянии), а большинство конференций было отменено или переведено в виртуальный режим. Люди, работавшие в офисе, в основном стали работать из дома (но многие из тех, кто занимается поддержкой ядра, и раньше работали в таком режиме). Поэтому многие вещи изменились, но в основе своей процесс разработки ядра остался таким как прежде.

Причем, все это очевидно повлияло на нашу жизнь в другой плоскости, в том, что касается социальных связей. Но вообще, будучи разработчиками ядра, которые общаются с коллегами почти исключительно по электронной почте, мы, вероятно, оказались наименее затронуты пандемией.



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Перевод 30 лет Линукса. Интервью с Линусом Торвальдсом. Часть 2

06.05.2021 14:05:14 | Автор: admin


Первая часть интервью.

Распределенная система контроля версий Git


Дж.А.: Linux только первая из ваших работ, глобально повлиявших на мир опенсорса. В 2005 году вы также создали Git, исключительно популярную распределенную систему контроля версий. Вы быстро перенесли дерево исходников ядра Linux из проприетарного хранилища Bitkeeper в новоиспеченный Git, который сделали опенсорсным, и в том же году передали поддержку Git Джунио Хамано. История этих событий увлекательна, расскажите, что побудило вас передать этот проект так быстро, и как вы нашли и выбрали Джунио?

ЛТ: Итак, ответ на этот вопрос состоит из двух частей.


Во-первых, я совершенно нехотел создавать новую систему контроля исходников. Linux был создан, так как мне очень интересен низкоуровневый интерфейс между аппаратным и программным обеспечением в принципе, эта работа была выполнена из любви к предмету и личного интереса. Напротив, Git был создан из необходимости: не потому, что я интересуюсь контролем исходников, а потому что большинство имевшихся на тот момент систем контроля версий вызывали у меня подлинное отвращение, а та единственная, что показалась мне наиболее терпимой и при этом действительно весьма хорошо сочеталась с моделью разработки Linux (BitKeeper) стала несостоятельной.

Итог: я занимаюсь Linux более 30 лет (до годовщины первого релизаеще остается пара месяцев, но работать над тем, что впоследствии превратилось в Linux, я стал уже более 30 лет назад), и все это время занимаюсь его поддержкой. Но Git? Я даже не думал о том, чтобы поддерживать его в долгосрочной перспективе. Он мне определенно нравится, и я, конечно, считаю, что это наилучшая из имеющихся систем управления исходниками, но она не является моей большой любовью и увлечением, если вы понимаете, о чем я.

Поэтому я всегда хотел найти кого-то, кто поддерживал бы эту систему контроля исходников за меня; на самом деле, я был бы счастлив вообще не писать ее.

Таков контекст.

Что касается Джунио на самом деле, он один из первых, кто реально занялся разработкой Git. Первые изменения от него пришли мне в пределах нескольких дней после того, как я выложил в общий доступ самую первую (и весьма сырую) версию Git. Поэтому Джунио причастен к этому проекту, можно сказать, с самых первых дней Git.

Но не подумайте, что я просто передал проект первому встречному. Я поддерживал Git несколько месяцев, и что побудило меня поинтересоваться у Джунио, не хочет ли он взять эту поддержку на себя так это трудноуловимое чувство хорошего вкуса. В самом деле, не могу описать это точнее: программирование сводится к решению технических задач, но суть в том, как вы их решаете, и это одна из тех вещей, которые начинают распознаваться со временем: определенные люди обладают хорошим вкусом, и поэтому выбирают правильное решение.

Не хочу заявлять, что программирование это искусство, поскольку на самом деле программирование это в основном хорошая инженерия. Я глубоко верю в мантру Томаса Эдисона про один процент таланта и девяносто девять процентов усердия; практически вся суть успеха заключается в мелких деталях и ежедневной рутинной работе. Но, все-таки, иногда приходится проявить вдохновение и тот самый хороший вкус, то есть, не просто решить задачу, а решить ее чисто, аккуратно и да, даже красиво.

Вот у Джунио такой хороший вкус нашелся.

Всякий раз, когда заходит речь о Git, я не забываю предельно ясно подчеркнуть следующее: пусть я и был зачинателем Git и спроектировал его ключевые идеи, зачастую я получаю за это чрезмерно много признания. Это было больше 15 лет назад, и я был по-настоящему погружен в работу над Git только в течение первого года. Джунио образцово справляется с поддержкой Git, и именно благодаря нему Git стал тем, чем является сегодня.

Кстати, вся эта история с хорошим вкусом и подыскиванием людей, которые им обладают, а также с умением доверять этим людям касается не только Git, но и в не меньшей степени всей истории Linux. В отличие от Git, Linux это продукт, чьей поддержкой я до сих пор активно занимаюсь, но, чем Linux во многом похож на Git так это вовлеченностью огромного множества людей в проект. Думаю, одно из самых замечательных достижений Linux в том, что его поддержкой занимаются буквально сотни активных участников, и все они, отвечающие за разные части ядра, обладают этим трудноопределимым чувством вкуса.

Дж.А.: Доводилось ли вам когда-либо делегировать кому-то поддержку, а потом понять, что это решение было ошибочным?

ЛТ: структура нашей работы по поддержке никогда не была настолько черно-белой или негибкой, чтобы это доставляло нам какие-либо проблемы. На самом деле, маловероятно, что мы даже когда-нибудь попытаемся тщательно документировать процедуру поддержки. Да, у нас есть файл MAINTAINERS, но он создан для того, чтобы можно былонайтинужных людей, это в самом деле не знак какого-то исключительного обладания.

Поэтому вся структура кто чем владеет в основном пластична и предназначена для ориентирования, означает этот человек активен и хорошо справляется со своей работой, а не упс, мы доверили человеку проект, а он взял и все запорол.

Ситуация пластична и в том смысле, что, может быть, вы занимаетесь поддержкой одной подсистемы, но вам что-то нужно подхватить из другой системы так вот, эти границы проницаемы. Обычно такие вещи сначала активно обсуждаютсяс людьми, а лишь потом делаются, но суть в том, что такая практика есть, и не существует жестких правил вроде вам можно прикасаться только к этому файлу.

Фактически, здесь мы вновь затрагиваем тему лицензирования, поднятую в первой части, и подчеркиваем один из принципов, по которым спроектирован Git, а именно у каждого есть собственное дерево, и технически ни одно дерево не является особенным.

Поскольку во многих других проектах использовались такие инструменты как CVS или SVN фундаментально некоторые люди действительно становятся особенными и пользуются обладанием, которое приходит вместе с этим статусом. В мире BSD этот феномен называется бит подтверждения (commit bit): это разряд, обладатель которого имеет право фиксировать код в центральном репозитории (или, как минимум, некоторых его частях).

Я всегда терпеть не мог такую модель, поскольку она неизбежно сказывается на политике и порождает в сообществе разработчиков клику, когда некоторые люди становятся привилегированными, и им по умолчанию доверяют. Проблема даже не в том, что по умолчанию доверяют, а как раз в другой стороне медали: кому-то, другим людям, не доверяют, и они по определению оказываются аутсайдерами, которым для выполнения работы нужно пройти кого-то из охранителей.

Опять же, в Git такой ситуации не возникает. Все равны. Каждый может клонировать ветку, начать собственную разработку, и, если они хорошо справятся с работой, то при объединении их ветка может вернуться в основную, а если очень хорошо то им поручается поддержка, и именно они начинают отвечать за слияние кода в тех деревьях, за которые отвечают ;).

Поэтому не приходится наделять людей особыми привилегиями, таким битом подтверждения. Это также означает, что не возникает политики, связанной с коммитами, не приходится никому по умолчанию доверять. Если оказалось, что кто-то плохо справился с работой, либо, что чаще, человек просто охладел к проекту и нашел дело поинтереснее их наработки не попадут в основную ветку при объединении, и они не будут путаться под ногами у других, кто может предложить новые, свежие идеи.

Дж.А.: Впечатляли ли вас когда-нибудь новые возможности Git, включали ли вы их в свои рабочие процессы? Можете ли назвать такие фичи, которых, на ваш взгляд, в Git до сих пор не хватает?

ЛТ: разумеется, в первую очередь были удовлетворены именно мои пожелания по функционалу, поэтому мне редко приходилось задумываться о каких-либо новых фичах.

С годами Git определенно улучшился, и некоторые такие подвижки отразились и на моих рабочих процессах. Например, Git всегда работал весьма быстро в конце концов, это была одна из целей, которые я поставил при проектировании, но значительная часть работы исходно делалась в виде шелл-скриптов, организованных вокруг некоторых базовых вспомогательных программ. С годами большая часть этих шелл-скриптов ушла, это означает, что я могу применять комплекты патчей от Эндрю Мортона даже быстрее, чем это делалось изначально. Это очень радует, поскольку именно скорость работы с патчами я использовал в качестве одного из первых контрольных показателей при тестировании производительности.

Итак, для меня Git всегда был хорош, но со временем стал только лучше.

Значительныеулучшения связаны с тем, насколько удобнее стало регулярным пользователям работать с Git. Во многом благодаря тому, что люди разобрались, как в Git устроен поток задач, и просто привыкли к нему (оноченьотличается от CVS и других аналогов, к которым люди привыкли ранее), но и сам Git стал гораздо приятнее в использовании.



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

HTML-теги и атрибуты, о которых вы, возможно, не знали

01.05.2021 14:19:19 | Автор: admin

image


Эта статья шпаргалка по HTML-тегам. Поэтому не будем разглагольствовать, сразу к делу.


abbr


Тег abbr определяет аббревиатуру или акроним. Аббревиатура или акроним расшифровываются с помощью атрибута title.


<abbr title="HyperText Markup Language">HTML</abbr> был разработан британским ученым Тимом Бернерсом-Ли приблизительно в 19861991 годах.

abbr часто используется совместно с тегом dfn, идентифицирующим понятие или термин:


<p><dfn><abbr title="Cascading Style Sheets">CSS</abbr></dfn> - формальный язык описания внешнего вида документа (веб-страницы).</p>

address


Тег address определяет контактную информацию об авторе или владельце документа или статьи. Контактная информацию может включать в себя адрес электронной почты, адрес сайта, физический адрес, номер телефона, ссылки на аккаунты в социальных сетях и т.д.


<address>Автор статьи: <a href="mailto:ivan@mail.com">Иван Иванов</a><br />Официальный сайт: <a href="http://personeltest.ru/away/example.com" target="_blank" rel="noopener noreferrer">Example.com</a><br />Адрес: некоторое царство, некоторое государство<address>

audio


Тег audio используется для встраивания аудио-контента (музыка и др.) в веб-страницу.


Для определения аудио-источника используется либо атрибут src, либо тег source. Последний используется для определения нескольких источников, из которых браузер выбирает наиболее подходящий (для определения типа аудио-контента используется атрибут type).


Текст между <audio> и </audio> отображается только в случае, когда браузер не поддерживает элемент audio.


В настоящее время поддерживается три формата аудио: MP3, WAV и OGG.


Атрибуты:


  • autoplay автовоспроизведение (блокируется большинством браузеров)
  • controls панель управления (без этого атрибута элемент audio, скорее всего, не будет отображаться на странице)
  • loop определяет, что воспроизведение, после завершения, начнется сначала
  • muted воспроизведение без звука (позволяет преодолеть блокировку autoplay)
  • preload определяет, должен ли аудио-контент загружаться после загрузки страницы. Возможные значения: auto, metadata, none. Значение none не позволит работать с аудио с помощью JavaScript
  • src путь к аудиофайлу

<audio controls>

  Ваш браузер не поддерживает элемент "audio".</audio><!-- или --><audio src="music.mp3" preload="metadata" controls muted loop>Ваш браузер не поддерживает элемент "audio".</audio>

video


Тег video используется для встраивания видео-контента (видеоклип и др.) в веб-страницу.


Для определения видео-источника используется либо атрибут src, либо тег source. Последний используется для определения нескольких источников, из которых браузер выбирает наиболее подходящий (для определения типа видео-контента используется атрибут type).


Текст между <video> и </video> отображается только в случае, когда браузер не поддерживает элемент video.


В настоящее время поддерживается три формата видео: MP4, WebM и OGG.


Атрибуты:


  • autoplay автовоспроизведение (блокируется большинством браузеров)
  • controls панель управления
  • loop определяет, что воспроизведение, после завершения, начнется сначала
  • muted воспроизведение без звука (позволяет преодолеть блокировку autoplay)
  • preload определяет, должен ли видео-контент загружаться после загрузки страницы. Возможные значения: auto, metadata, none. Значение none не позволит работать с видео с помощью JavaScript
  • src путь к видеофайлу
  • poster изображение, отображаемое при загрузке видео или до нажатия пользователем кнопки воспроизведения
  • width ширина элемента в пикселях
  • height высота элемента в пикселях

<video width="320" height="240" controls>

  Ваш браузер не поддерживает элемент "видео".</video><!-- или --><!-- Такой вариант может использоваться для воспроизведения видео в качестве фона страницы --><video src="movie.mp4" autoplay muted loop>Ваш браузер не поддерживает элемент "видео".</video>

DOM API предоставляет множество свойств, методов и событий для работы с элементами audio и video.


base


Тег base определяет основной путь (URL) и/или цель (target) для всех относительных путей в документе. Он должен размещаться в теге head и иметь хотя бы один из следующих атрибутов:


  • href основной путь
  • target определяет значение по умолчанию атрибута target всех гиперссылок и форм на странице. Возможные значения: _blank, _parent, _self и _top

<head>  <base href="http://personeltest.ru/away/example.com/" target="_blank"></head><body>  <header>    <nav>      <!-- http://example.com/product.html -->      <a href="product.html">Продукт</a>    </nav>  </header>  <main>    <!-- http://example.com/images/happy_face.png -->    <img src="images/happy_face.png" alt="" />  </main>  <footer>    <nav>      <!-- http://example.com/contacts.html -->      <a href="contacts.html">Контакты</a>    </nav>  </footer></body>

blockquote и cite


Тег blockquote определяет раздел страницы, заимствованный из другого источника. Источник указывается в атрибуте cite.


<blockquote cite="http://personeltest.ru/aways/ru.wikipedia.org/wiki/JavaScript">JavaScript - мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией спецификации ECMAScript (стандарт ECMA-262).</blockquote>

Тег cite определяет название какой-либо работы (книги, стихотворения, песни, фильма, картины, скульптуры и т.д.). Он также может представлять из себя ссылку на источник цитаты.


<p>Для более глубокого изучения JavaScript советую взглянуть на <cite>"Вы не знаете JS"</cite> Кайла Симпсона.</p>

code


Тег code используется для определения части компьютерного кода:


<p>HTML-тег `button` определяет кликабельную кнопку.</p><p>CSS-свойство `background-color` определяет цвет фона элемента.</p>

Для форматирования блока кода code часто используется совместно с тегом pre:


<pre>  `    const name = prompt('Как Вас зовут?')    if (name?.trim()) alert(`Привет, ${name}!`)    else console.info('Пользователь пожелал остаться неизвестным')  `</pre>

datalist


Тег datalist определяет список возможных вариантов для заполнения поля для ввода текста. Он позволяет реализовать "автозавершение" для элемента input: при установке фокуса на такое поле пользователь видит выпадающий список.


Атрибут id тега datalist должен совпадать с атрибутом list тега input.


<!-- Атрибут `for` тега `label` должен совпадать с атрибутом `id` тега `input` --><label for="browser">Выберите Ваш браузер из списка:</label><input list="browsers" id="browser"><datalist id="browsers">  <option value="Edge">  <option value="Firefox">  <option value="Chrome">  <option value="Opera">  <option value="Safari"></datalist>

Свойство options объекта Datalist возвращает коллекцию всех элементов списка.


dl, dt и dd


Тег dl определяет список описаний (определений, извиняюсь за тавтологию). Он используется совместно с тегами dt, определяющим понятие или термин, и dd, определяющим описание термина.


Внутри dd могут размещаться параграфы, изображения, ссылки, списки и т.д.


<dl>  <dt>Кофе</dt>  <dd>Черный горячий напиток</dd>  <dt>Молоко</dt>  <dd>Белый холодный напиток</dd></dl>

details


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


По умолчанию details находится в закрытом состоянии.


Внутри details могут размещаться любые теги.


Для отображения заголовка details используется тег summary.


Индикатором открытого состояния details является атрибут open (этот атрибут может использоваться в качестве CSS-селектора details[open] или JavaScript-селектора document.querySelector('[open]')).


<details>  <summary>Заголовок - видимая часть элемента "details"</summary>  <p>Скрытый контент - дополнительная информация</p></details>

dialog


Тег dialog определяет диалоговое окно. Он используется для создания "попапов" и модальных окон.


По умолчанию dialog находится в неактивном состоянии.


Индикатором активного состояния dialog является атрибут open.


<dialog open>Открытое диалоговое окно</dialog>

Для управления объектом Dialog с помощью JavaScript используются такие методы как show(), close() и showModal(), а также свойство open.


figure


Тег figure определяет обособленный (автономный) контент, такой как иллюстрации, диаграммы, фотографии, примеры кода и т.д.


Несмотря на то, что контент элемента figure формально относится к основному потоку (main flow), его позиция (местонахождение) не зависит от этого потока. Поэтому удаление элемента figure не должно влиять на поток документа.


Для добавление подписи к figure используется тег figcaption.


<figure>  <img src="v8-compiler-pipeline.png" alt="V8 compiler pipeline" style="width:100%">  <figcaption>Рис. 1 - Процесс компиляции кода "движком" JavaScript V8.</figcaption></figure>

meter


Тег meter определяет скалярное значение в пределах известного диапазона или дробного значения. Другими словами, meter определяет меру чего-либо (gauge).


Этот тег не должен использоваться в качестве индикатора прогресса.


Для обеспечения доступности совместно с meter рекомендуется использовать тег label.


Атрибуты:


  • value текущее числовое значение между min и max
  • min нижняя числовая граница диапазона
  • max верхняя числовая граница диапазона
  • low верхняя числовая граница нижнего предела диапазона. Должна быть больше min, но меньше high и max
  • high нижняя числовая граница верхнего предела диапазона
  • optimum оптимальное числовое значение между min и max. Расположение этого атрибута определяет предпочтительную часть диапазона. Например, если optimum находится между min и low, значит, предпочтительным является нижний диапазон
  • form определяет элемент form, с которым связан meter

<label for="disk_d">Использование диска "D":</label><meter id="disk_d" min="0" max="100" value="60">60%</meter>

Так можно записать уровень заряда батареи вашего устройства в значение meter:


// <meter id="meter" max="100"></meter>if ('getBattery' in navigator) {  navigator.getBattery()    .then(({ level }) => {      meter.value = level * 100    })}

progress


Тег progress определяет процесс выполнения задачи.


Этот тег не должен использоваться для определения меры чего-либо.


Для обеспечения доступности совместно с progress рекомендуется использовать тег label.


Атрибуты:


  • max максимальное значение. По умолчанию равняется 1
  • value текущее значение

<label for="file">Процесс загрузки:</label><progress id="file" max="100" value="32">32%</progress>

Так можно реализовать десятисекундный таймер:


// <progress id="progress" value="0" max="10"></progress>const timerId = setInterval(() => {  progress.value += 1  if (progress.value === progress.max) {    progress.remove()    clearInterval(timerId)  }}, 1000)

output


Тег output используется для представления результата вычислений.


Атрибуты:


  • for определяет связь между результатом и элементами, используемыми для его выичсления
  • form определяет элемент form, которому принадлежит output
  • name название элемента output

<form oninput="x.value=parseInt(a.value)+parseInt(b.value)">  <input type="number" id="a" value="25" />  +  <input type="number" id="b" value="50" />  =  <output name="x" for="a b">75</output></form>

picture


Тег picture предоставляет возможность использования нескольких источников для изображения (нескольких изображений).


Этот тег позволяет использовать разные изображения в зависимости от ширины области просмотра (viewport width) вместо масштабирования одного изображения.


Элемент picture содержит два тега: один или более source и один img.


Браузер выбирает элемент source с медиа-запросом, совпадающим с текущей шириной области просмотра. Элемент img указывается в качестве последнего дочернего элемента на случай отсутствия совпадений с source.


Путь к изображению указывается в атрибуте srcset, а медиа-запрос в атрибуте media.


<picture>

  <img src="default.jpg" alt="" style="width:auto;"></picture>

template


Тег template используется в качестве контейнера для разметки, которая не отображается при загрузке страницы.


Этот тег предназначен для хранения разметки, которая используется часто, но в определенных случаях (по запросу).


Контент внутри template может быть отрендерен с помощью JavaScript.


<template>  <h1>Заголовок</h1>  <p>И какой-то текст</p></template><button id="button">Это не кнопка</button>

((body, { content }) => {  button.onclick = () => {    body.append(content.cloneNode(true))  }})(document.body, document.querySelector('template'))

time


Тег time определяет конкретное время (или дату и время).


Атрибут datetime используется для представления времени в машиночитаемом формате.


<p>Некоторые люди искренне верили в то, что в <time datetime="2000-01-01 00:01">полночь 2000 года</time> наступит конец света, но, как видите, свет продолжается. Возможно, он закончится в <time datetime="3000-01-01 00:01">полночь 3000 года</time>, но это не точно</p>

noscript


Тег noscript определяет резервный контент, который отображается в случае, если в браузере отключен JavaScript. Он может использоваться как в теге head, так и в теге body. В первом случае noscript может содержать только такие теги как link, style и meta.


<script>document.write('Одни дивы да спаны... Где семантика?')</script><noscript>Пожалуйста, включите JavaScript</noscript>

Другие теги в форме шпагралок


Семантическое "секционирование" страницы


<body>  <header>    <h1>Page Title</h1>    <nav>      <ul>        <li><a href="#">Link1</a></li>        <li><a href="#">Link2</a></li>      </ul>    </nav>    <img src="images/logo.png" alt="" />  </header>  <aside>    <h2>Aside Title</h2>    <p>Aside Content</p>  </aside>  <main>    <article>      <h2>Atricle Title</h2>      <section>        <h3>Section Title</h3>        <p>Section Content</p>      </section>    </article>    <div>      <section>        <h2>Section2 Title</h2>        <p>Section2 Content</p>      </section>      <section>        <p>Section3 Content</p>      </section>    </div>  </main>  <footer>    <nav>      <ol>        <li><a href="#">Link3</a></li>        <li><a href="#">Link4</a></li>      </ol>    </nav>    <div>      <p>Block text &amp; <span>inline text</span></p>    </div>  </footer></body>

Стилизация текста


<p>  Текст может быть    <b>полужирным</b>,    <strong>полужирным и "важным"</strong>,    <i>"наклонным"</i>,    <em>наклонным и важным</em>,    <small>маленьким</small>,    <del>удаленным из документа</del>,    <ins>вставленным в документ</ins>,    <u>подчеркнутым</u>    <s>неправильным</s>.  Он может представлять собой    <q>короткую цитату</q>,    <kbd>ввод с клавиатуры</kbd>,    <samp>вывод программы</samp>.  Текст может находиться    <sup>над строкой</sup> и    <sub>под ней</sub>.  Наконец, он может быть <mark>помеченным</mark>.  Длинныйтекстможноразделять<wbr />внужномместе.  Его можно переносить<br />на новую строку и разделять<hr />горизонтальной чертой.</p>

Форма


Символ / означает или.


<form  action="URL"  autocomplete="on / off"  enctype=""  id="form"  method="GET / POST"  name="form"  novalidate>  <fieldset>    <legend>Title</legend>    <label for="first_name">Имя:</label>    <input type="text" id="first_name">    <label>Фамилия:      <input type="text">    </label>  </fieldset>  <select    autofocus    disabled    form="form"    multiple    name="select"    required    size="10"  >    <optgroup label="Group1">      <option        value="option1"        disabled        label="option1"      ></option>      <option value="option2" selected></option>    </optgroup>    <optgroup label="Group2" disabled>      <option value="option3"></option>    </optgroup>    <option value="option4"></option>  </select>  <textarea    autofocus    cols="30"    disabled    form="form"    maxlength="50"    name="textarea"    placeholder="Введите текст..."    readonly    required    rows="10"    wrap="hard / soft"  ></textarea>  <button    type="submit"    autofocus    disabled    form="form"    formaction="URL"    formenctype=""    formmethod="GET / POST"    formnovalidate    name="submit"  >    Кнопка для отправки формы  </button>  <button type="reset">Кнопка для сброса формы (очистки полей для ввода данных)</button>  <button type="button">Просто кнопка</button></form>

Поля для ввода данных


<input type="button"><input type="checkbox"><input type="color"><input type="date"><input type="datetime-local"><input type="email"><input type="file"><input type="hidden"><input type="image"><input type="month"><input type="number"><input type="password"><input type="radio"><input type="range"><input type="reset"><input type="search"><input type="submit"><input type="tel"><input type="text"> (значение по умолчанию)<input type="time"><input type="url"><input type="week">

Атрибуты:


  • accept MIME-тип принимаемых файлов (только для type="file"). Значения: расширение, например, .png, audio/*, video/*, image/*, медиа тип, например, json
  • alt подпись
  • autocomplete on / off
  • autofocus
  • checked только для type="checked" или type="radio"
  • disabled
  • form
  • formaction только для type="submit" или type="image"
  • formenctype только для type="submit" или type="image". Значения: application/x-www-form-urlencoded, multipart/form-data, text/plain
  • formmethod только для type="submit" или type="image" (get / post)
  • formnovalidate отключает проверку элементов формы
  • formtarget определяет, где отображается ответ, полученный после отправки формы (только для type="submit" или type="image"). Значения: _blank, _self, _parent, _top, название фрейма
  • height высота в пикселях (только для type="image")
  • list
  • max максимальное значение (число или дата)
  • maxlength максимальная длина строки (количество символов)
  • min минимальное значение (число или дата)
  • minlength минимальная длина строки (количество символов)
  • multiple позволяет пользователю выбирать несколько значений или отправлять несколько файлов
  • name
  • pattern регулярное выражение для проверки значения поля
  • placeholder
  • readonly
  • required
  • size количество символов, определяющее ширину поля
  • src путь к изображению, используемому в качестве кнопки для отправки формы (только для type="image")
  • step интервал (шаг) между min и max
  • type
  • value
  • width ширина поля в пикселях (только для type="image")

Пример валидации адреса электронной почты и пароля:


<form>  <input    type="email"    id="email"    name="email"    pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"    required  />  <input    type="password"    id="password"    name="password"    pattern="(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,}"    title="Пароль не может быть меньше 8 символов и должен содержать одну цифру, одну прописную (заглавную) букву и одну строчкую букву"    required  />  <input type="submit" /></form>

Таблица


<table>  <caption>    Table Title  </caption>  <colgroup>    <col span="2" />    <col />  </colgroup>  <thead>    <tr>      <th        abbr="H1"        colspan="2"        rowspan="2"        scope="col / colgroup / row / rowgroup"      >        Heading1      </th>      <th>Heading2</th>    </tr>  </thead>  <tbody>    <tr>      <td colspan="2" rowspan="2">1-1</td>      <td>1-2</td>    </tr>    <tr>      <td>2-1</td>      <td>2-2</td>    </tr>  </tbody>  <tfoot>    <tr>      <td>3-1</td>      <td>3-2</td>    </tr>  </tfoot></table>

Теги colgroup и col могут использоваться для стилизации определенных колонок таблицы целиком вместо стилизации каждой ячейки и строки по отдельности.


Послесловие


Мы рассмотрели почти все существующие HTML-теги. С полным списком можно ознакомиться здесь или здесь. Во многих публикациях упоминаются теги map и area, но с их использованием сопряжено несколько проблем (сложность реализации карты, зависимость областей от координат и т.д.), поэтому я оставил их без внимания. Также существуют такие теги, как svg и canvas, предназначенные для работы с графикой, но для рассказа о каждом из них требуется отдельная статья (и даже не одна).




Наши виртуалки можно использовать для разработки веб-сайтов.


Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!


Подробнее..

Перевод Графика для JVM

02.05.2021 16:16:26 | Автор: admin


Допустим, я хочу создавать качественные десктопные приложения. Я также хочу сделать это на JVM. Не надейтесь мы еще не достигли цели. Но у меня есть план.

Почему именно JVM?


Это производительность на достаточно высоком уровне, но не заставляет вас слишком много задумываться о каждом выделение памяти. Это кроссплатформенно. В нем есть отличные языки Kotlin, Scala и, конечно же, Clojure. C # тоже подойдет, но в нем нет Clojure.

Разве вы уже не можете создавать десктопные приложения на JVM?


Вы можете. Но традиционно AWT, Swing и JavaFX сопровождались множеством недостатков в качестве и производительности. Они были настолько существенными, что только одной компании удалось создать прилично выглядящее приложение на Swing. Это возможно, но требует огромных усилий.

Разве не все пользовательские интерфейсы Java прокляты?


Нет, не совсем. У AWT, Swing и JavaFX есть свои проблемы, но это исключительно их проблемы. Нет фундаментальной причины, по которой невозможно создать высококачественный пользовательский интерфейс на JVM. Просто это еще не было сделано.

Почему это еще не было сделано?


Я думаю, это связано с терпением. Мы так привыкли к вещам, которые можно собрать за неделю, что никто не думает о годах. А для хорошего пользовательского интерфейса требуются годы работы. Это большое обязательство.

Почему не Electron?


Первая причина производительность. JS отличный язык для создания пользовательского интерфейса, но он намного медленнее, чем JVM. Wasm может быть быстрым, но подразумевает C ++ или Rust.

Второй это модель DOM. Это ужасающая коллекция уловок, которые делают простые вещи сложными, а сложные невозможными. Я много раз думал: Если бы я рисовал этот элемент управления/макет напрямую, я бы закончил несколько часов назад.

Это означает, что существует очень низкий предел возможностей веб-приложений с точки зрения производительности и качества. Я считаю, что мы можем и должны добиться большего.

Однако Electron научил нас двум хорошим вещам:

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


Десктоп по-прежнему актуален?


Я верю, что это так!

Недавно я смотрел интервью между разработчиком Android и разработчиком iOS. Один спрашивал:

Кто-нибудь по-прежнему пишет десктопные приложения?

На что другой ответил:

Понятия не имею Может быть?

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

И я был на обеих сторонах. Однажды я жил без рабочего стола несколько недель. К этому привыкаешь, но это, конечно, не идеал. Сбор и обработка любой информации очень болезненны: сложно выделить текст, сложно выполнить поиск на странице, сложно иметь несколько вкладок, сложно перемещать данные между приложениями. Например, вы добавляете событие в календарь. Вам нужно найти адрес события в почте, где есть ссылка, открывающая браузер. К тому времени, когда вы нашли то, что вам нужно, и вернули в календарь, оно уже выгружается из памяти, и весь контекст теряется. Возможность одновременного открытия нескольких окон это суперспособность рабочего стола.

Телефоны отлично подходят для небольших быстрых одноцелевых задач. У них есть свое место, но жизнь намного сложнее, чем телефон. Многим из нас все еще нужен этот велосипед для ума.

Хорошо, что же ты предлагаешь?


Путь к качественному пользовательскому интерфейсу на JVM долгий. Нам понадобятся:

  • графическая библиотека,
  • библиотека интеграции окна / ОС,
  • набор инструментов пользовательского интерфейса.


Сегодня я рад анонсировать первую часть этого эпического квеста: графическую библиотеку. Она называется Skija и представляет собой просто набор привязок к очень мощной, хорошо известной библиотеке Skia. Та, которую поддерживает Chrome, Android, Flutter и Xamarin.

image

Как и любая другая библиотека JVM, она кроссплатформенная. Она работает в Windows, Linux и macOS. Это так же просто, как добавить файл JAR. Намного проще, чем массировать флаги компилятора C ++ в течение нескольких дней, прежде чем вы сможете что-либо скомпилировать. Skija позаботится об управлении памятью за вас. И привязки создаются вручную, поэтому они всегда имеют смысл и доставляют удовольствие (по крайней мере, насколько позволяет Skia API).

Что с этим делать? В основном рисовать. Линии. Треугольники. Прямоугольники. Но также: кривые, контуры, формы, буквы, тени, градиенты.

image

Думайте об этом как о Canvas API. Но вроде бы действительно продвинутой версии. Она понимает цветовые пространства, современную типографику, макет текста, ускорение графического процессора и тому подобное.

image

О, и это быстро. Действительно быстро. Если этого достаточно для Chrome, вероятно, этого будет достаточно и для вашего приложения.

Что я могу с этим сделать?


Много вещей! Пользовательские библиотеки виджетов пользовательского интерфейса и целые наборы инструментов, графики, диаграммы, визуализации, игры. Например, мы поигрались с реализацией java.awt.Graphics2D и запуском Swing поверх него похоже, все работает нормально.

Зачем выпускать отдельную графическую библиотеку? Чем это полезно?


Я не большой поклонник объединять все в одном месте. Вы никогда не сможете угадать все детали правильно кто-то всегда будет недоволен конкретным решением.

Независимые взаимозаменяемые библиотеки более гибкие. Филосовия Unix.

Что с остальной кусочками паззла?


Обе вещи находятся в разработке в JetBrains.

  • Для интеграции управления окнами и ОС есть Skiko. Она говорит, что это Skia для Kotlin, но она также реализует создание окон, события, пэкэджинг и все остальное. Она даже интегрируется с AWT и Swing.
  • А для инструментария пользовательского интерфейса есть Compose Desktop. Это форк Android Compose, декларативного UI-фреймворка, работающего в среде рабочего стола.


Но прелесть в том, что это даже не обязательно эти двое!

Не нравится AWT? Принесите свою собственную библиотеку окон.

Kotlin не подходит Вам? Используйте любой другой язык JVM.

Compose плохо справляется с нагрузкой? Молитесь, чтобы кто-нибудь написал альтернативу или написал что-то свое (извините, но хорошего решения пока нет. Это еще только начало).

И, конечно, если вы хотите развернуть свою собственную библиотеку окон или набор инструментов для виджетов пожалуйста, сделайте это! Мы надеемся, что это произойдет.

В заключение


Skija это часть более широкой картины. Прогресс пользовательского интерфейса Java был заблокирован некачественной Graphics2D. Но все меняется. Что из этого выйдет? Время покажет.

Пожалуйста, попробуйте Skija и поделитесь с нами своим мнением. Или, может быть, начните ей пользоваться мы были бы счастливы, если бы вы это сделали! Вот ссылка:

github.com/JetBrains/skija

14 ноября 2020 Обсуждение на HackerNews



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru