Alexander Pevzner
@apevzner
Программист на все руки
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
System Software Engineer, Software Architect
Lead
Интересно, что фактически ради перехода на snap-ы, в линухе серьезно переделывают систему печати (ключевое слово PAPPL). При этом зачем это надо убунте, понятно, но федоровцы не возражают, а сотрудничают.
P.S. А разве в убунте упразднили традиционные пакеты? Мне казалось, что они запихивают народ в снапы мягко, и при наличии желания и сноровки можно и отказаться.
А это с любыми пакетами может произойти или с какими-то особыми, проприетарными?
Я 100500 лет как на Федоре. Не знаю, что там происходит в Убунте при обновлении через командную строку. Не можете пояснить?
Почему?
Насколько я понимаю, бизнес, на который делает ставку Canonical - это магазин приложений для Linux под названием snapcraft (через который распространяются snap-ы).
Посмотрим, может из этого чего и получится.
Спасибо!
А вот интересно. Что если создать свой собственный язык описания правил и генераторы правил под конкретные железки?
Казалось бы такое вполне могло бы продаваться корпоративным клиентам, поскольку уменьшает их зависимость от вендоров сетевой аппаратуры.
А раз такое пришло мне в голову, может, на рынке уже и есть подобные продукты?
Тссс! Не надо выдавать секретов! Прочитают крутые менеджеры - начнут задумываться, не переплачивают ли они нам!
Почему нет-то?
На форуме могут помочь с настройками, сославшись на опыт другого пользователя, который смог.
Все реальные проблемы, которые решаются, в конечном итоге попадают к 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-ом. Вроде никто не жалуется.
Я вижу тут следующие соображения:
Если доступ к сайту осуществляется только через TLS (и не только HTTPS, SMTP/TLS тоже считается), проверка домена в любом случае заложена в TLS, и DNSSEC ничего особо полезного не добавляет
С DNSSEC много возни (хотя, казалось бы, Google мог бы справиться)
DNSSEC не очень-то совместим с CDN. Если посмотреть, тот же google.com по-разному резолвится из разных мест - на выходе адрес их ближайшего к пользователю CDN-сервера.
Наверное, об этом стоило упомянуть в статье. Но вот, упустил...
Чисто конкретно поправил. Аналогочно и со второй опечаткой. Спасибо!
Я так и планирую. Тема-то, как Вы понимаете, очень широкая. Пытаюсь найти то смысловое ядро, которое будет интересно и понятно многим, не скатываясь в банальности и не погрязая в чрезмерно низкоуровневых деталях.
Я сам-то разработчик с большим сетевым опытом, а не админ. Поэтому смотрю на это дело больше с технической стороны, чем со стороны использования (а заодно, прорабатывая материал для статьи, подтягиваю пробелы в собственных знаниях).
Спасибо вам за отзыв и за обратную связь!
Спасибо за ссылку!
А я думаю, там примерно это и будет. Нерутованный андроид + бровсер из списка утвержденных, чтобы заходить на сайт банка дальше рекламы. И список, что-то мне подсказывает, будет очень коротким...
P.S. А Вы работаете в Brave, находясь в России или релоцировались?
А зачем вообще давать доступ сайтам доступ к localhost-у (за исключением очевидного случая, когда сайт сам размещен на localhost-е)?
API-то общедоступно, но критерии аттестации, как я понимаю, могут быть любыми? Например, "10 лет на рынке бровсеров".