Pull to refresh
171
-32
Alexander Pevzner @apevzner

Программист на все руки

Send message

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

P.S. А разве в убунте упразднили традиционные пакеты? Мне казалось, что они запихивают народ в снапы мягко, и при наличии желания и сноровки можно и отказаться.

А это с любыми пакетами может произойти или с какими-то особыми, проприетарными?

Я 100500 лет как на Федоре. Не знаю, что там происходит в Убунте при обновлении через командную строку. Не можете пояснить?

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

Почему?

Насколько я понимаю, бизнес, на который делает ставку Canonical - это магазин приложений для Linux под названием snapcraft (через который распространяются snap-ы).

Посмотрим, может из этого чего и получится.

А вот интересно. Что если создать свой собственный язык описания правил и генераторы правил под конкретные железки?

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

А раз такое пришло мне в голову, может, на рынке уже и есть подобные продукты?

Сейчас же убедилась на своем опыте, ​​что не нужно быть крутым техническим специалистом, чтобы успешно вести комплексный продукт в IT.

Тссс! Не надо выдавать секретов! Прочитают крутые менеджеры - начнут задумываться, не переплачивают ли они нам!

Кстати, а компания из Украины может использовать аlt Linux?

Почему нет-то?

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

Все реальные проблемы, которые решаются, в конечном итоге попадают к Michael Sweet, который автор CUPS, если проблемы в самом CUPS-е, или к Till Kamppeter, который главный по принтерам в Linux вообще и в Ubuntu в частности - сюда попадут проблемы, например, с foomatic, коллекцией опенсорсных .PPD-файлов. Ну еще и проблемы, связанные с IPP over USB ко мне иногда попадают, но они редкие.

Поэтому писать в поддержку своего дистрибутива писать особого смысла-то и нет. К тому же, если дистрибутив этот сделан из Убунты, то всё Till-у и перешлют, а если из Редхата, то Zdenek Dohnal или перешлет кому-то из нас, или сам посмотрит в форуме.

Я к тому, что если зафайлить багу прямо в CUPS или foomatic, путь к помощи окажется короче.

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

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

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

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

Гугль активно двигает DoH. Причем в варианте, встроенном в Chrome и с терминацией на Гугловских серверах. Им, я бы даже сказал, не выгодно чинить проблемы в DNS.

Вряд ли мы здесь встретим людей, принимающих техническое решение о использовании DNSSEC в доменах масштаба google.com или intel.com. Таких людей просто физически очень мало, не думаю, что они тут стаями ходят

Но можем попробовать сами разобраться. Я потом обновлю статью.

История по вашей ссылке интересная. Там говорится, что если сломать TLD, DNSSEC сломается у кучи поддоменов. И еще там говорится, что такие случаи 100500 раз были в истории.

Мне, вообще, пока не очень понятно. Если сломается TLD, он и NS не будет возвращать и записи, относящиеся к DNSSEC тоже не будет. Вроде и просто домены сломаются, и криптоподпись сломается в них заодно. Но последствия первого сильно хуже последствий второго, и на фоне первого второе вроде как представляет только чисто академический интерес -- поправьте меня, если я не прав.

TLS сертификат не зависит никак от домена. С точки зрения TLS, имя домена - это просто такая строка. Мы идем на google.com, запоминаем, куда шли, резолвим адрес, куда-то попадаем, там нам предъявляют TLS-сертификат, и мы сравниваем строку в сертификате с запомненным доменом.

Единственное что, надо посмотреть, как это с CNAME сочетается. Я не знаю, бровсер сам резолвит CNAME и сразу обращается по каноническому адресу, или он идет по тому адресу, который дали, рассчитывает там найти TLS-сертификат, соответствующий имени, принимает оттуда redirect на каноническое имя, и потом, зайдя уже по каноническому имени, рассчитывает там найти другой TLS-сертификат, уже соответствующий новому имени. Я разберусь, мне любопытно.

Но в общем и целом, похоже, DNSSEC - мёртвая технология (хотя ее агония может еще довольно долго продолжаться).

Не очень понятно, в чем могли бы заключаться эти проблемы с совместимостью.
Вот habr.com, например, подписан DNSSEC-ом. Вроде никто не жалуется.

Я вижу тут следующие соображения:

  1. Если доступ к сайту осуществляется только через TLS (и не только HTTPS, SMTP/TLS тоже считается), проверка домена в любом случае заложена в TLS, и DNSSEC ничего особо полезного не добавляет

  2. С DNSSEC много возни (хотя, казалось бы, Google мог бы справиться)

  3. DNSSEC не очень-то совместим с CDN. Если посмотреть, тот же google.com по-разному резолвится из разных мест - на выходе адрес их ближайшего к пользователю CDN-сервера.

Наверное, об этом стоило упомянуть в статье. Но вот, упустил...

Чисто конкретно поправил. Аналогочно и со второй опечаткой. Спасибо!

поэтому может быть стоит Вам именно про это тоже написать

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

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

Спасибо вам за отзыв и за обратную связь!

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

P.S. А Вы работаете в Brave, находясь в России или релоцировались?

А зачем вообще давать доступ сайтам доступ к localhost-у (за исключением очевидного случая, когда сайт сам размещен на localhost-е)?

API-то общедоступно, но критерии аттестации, как я понимаю, могут быть любыми? Например, "10 лет на рынке бровсеров".

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

System Software Engineer, Software Architect
Lead