[12:13:53] <valexey> да ладно. вон на rust'e уже сделали: https://github.com/bluejekyll/trust-dns
[12:14:16] <valexey> а он как минимум не менее безопасный чем Ада.
[13:32:45] <landgraf> valexey, ты конфы не перепутал?
[13:38:47] <valexey> дык вроде бы вопрос про надежность DNS-серверов, нет?
вообще, вопрос интересный - вот есть используемый сишный DNS-сервер. в нем нашли дыры. ок. Я беру, пишу свой DNS-сервер, скажем на чистом асме. И после этого утверждаю что он надежней и безопасней. Ведь никто ни одной уязвимости в нем не нашел!
Вопрос - будет ли моё утверждение когда-то кем-то опровергнуто?
[13:53:15] <valexey> то есть имеется дилемма - с одной стороны, чем меньше проектом пользуются, тем меньше у него будет (известных) багов.
с другой стороны, тем выше вероятность, что именно ты напорешься на критический баг в этом проекте, и он порушит всю твою экосистему, если она завязана на оный проект.
и чем больше пользуются проектом, тем критичней становится любой его баг так как в этом случае на него завязано множество больших экосистем.
[13:58:56] <landgraf> valexey, ты почитай про cve эти, там сплошные переполнения буфера
[14:00:24] <valexey> ну и кто им злобный буратин? есть же и -fsanitize с любыми опциями, и компилятор варнингами сыпет, которые легко в ошибки выливаются.
[14:02:06] <valexey> алсо переполнение буфера это не единственный способ налажать в DNS-сервере фатально. если с нуля писать. то есть лажи будет МНОГО в свежго DNS-сервера на любом языке. и баги у него будут отловлены и исправлены только если им будут массово пользоваться.
[14:02:55] <valexey> ну и, насколько я понимаю, DNS-сервер оптимизируется прежде всего под нагрузку. если он будет работать в два раза медленней, будут юзать другой, который быстрее.
[14:03:59] <landgraf> и который падает каждый день?
[14:04:37] <valexey> а он падает каждый день?
[14:05:38] <landgraf> а он быстрее в два раза? ты первый в экстремумы полез
[14:05:41] <valexey> насколько я понимаю, сейчас основная проблема с этим DNS-серваком как раз в том, что он НЕ падает. хотя должен. вот например на Аде сервак бы падал. И на любом другом ЯП где ведется проверка границ.
[14:06:34] <landgraf> valexey, ну тебе виднее, я вот прямо сейчас ковыряюсь с sigabrt багом, не знаю где он там НЕ падает
[14:07:22] <valexey> дык когда говорят про уязвимость - это означает что возможна атака, когда ты заставляешь сервак что-то эдакое сделать и при этом не упасть. через то же переполнение буфера.
[14:08:02] <valexey> если проделать такую операцию с серваком который собран с опцией проверки границ - то он шлепнется, но не даст провести манипуляцию.
[14:08:24] <landgraf> а мужики то не знают!
[14:10:55] <valexey> но, кстати, надо будет взглянуть на проблемный код. интересно, можно ли было это предотвратить на другом ЯП.
[14:11:16] <valexey> т.е. логическую ошибку, а не выход за границы посредством выкидывания исключения.
[14:11:27] <landgraf> сидят такие дядьки в евроконтроле, блукепитал, боинге и где-то там еще и не знают что у них софтина медленная и может в два раза быстрее работать.
[14:11:42] <landgraf> valexey, чем плохо выкинуть исключение и послать клиенту servfail?
[14:12:21] <landgraf> тем что клиент, который послал кривой запрос с целью положить твой сервис прибежит жаловаться?
[14:12:45] <valexey> тем, что ошибка остается.
[14:13:11] <valexey> и в процессе выкидывания и ловли исключения можно насажать еще ошибок.
[14:13:23] <valexey> например будет какая-нибудь утечка какого-нибудь ресурса.
[14:13:32] <valexey> памяти, сокетов, чего угодно.
[14:14:04] <valexey> так как программист прощелкал вариант, и за него отработала аварийная защита уровня рантайма.
[14:14:16] <landgraf> ладноЮ пойду работать, нет времени продолжать это
[14:14:49] <valexey> угу
[14:15:47] <landgraf> valexey, ты когда на машине едешь - тоже АБС и всю стабилизацию отрубаешь? вдруг там ошибка и защита уровня рантайма не нужна?
[14:15:56] <landgraf> ну и ремни безопасности не используешь наверняка
[14:16:52] <valexey> ремни безопасности не использовать опасно так как подушки безопасности не отключаются для водителя.
[14:17:29] <valexey> тот самый случай, когда система безопасности тебя убьет, если сработает частично.
[14:19:08] <landgraf> так подушку тоже отключи
[14:19:16] <valexey> кстати, из за АБС, в некоторых условиях, есть неиллюзорный шанс не затормозить как надо. На некоторых немцах она очень хреново работает на снегу. Машина останавливается на несколько метров дальше чем без АБС.
[14:19:19] <landgraf> вдруг там ошибка
[14:19:48] <valexey> А, кстати, да, в АБС тоже ошибки были. Несколько человек погибло, насколько я знаю.
[14:19:53] <landgraf> valexey, ты не считаешь что "в некоторых условиях" тут довольно важная фраза?
[14:20:07] <valexey> Эти некоторые условия у нас, блин, каждый год.
[14:20:10] <landgraf> valexey, ты на вопрос ответь, отключаешь АБС? подушки? ошибки ведь были
[14:20:15] <landgraf> и условия там всякие
[14:20:28] <landgraf> или так, демагогией позаниматься
[14:20:49] <valexey> в моем авто система торможения в принципе не рассчитана на работу без АБС. Также нет штатной возможности это отключить.
[14:21:00] <valexey> С подушками - аналогично.
[14:21:40] <landgraf> предохранитель выдерни
[14:21:53] <landgraf> возможность есть даже на приусе
[14:22:19] <landgraf> разъемы от подушек отключи, сохранишь топливо, опять же
[14:22:49] <valexey> кстати, подушки для пассажира отключаются же. штатным образом. чтобы подушка ребенка не убила.
[14:23:30] <landgraf> valexey, вообще не кстати, читай мануал
[14:23:59] <landgraf> подушка отключается если ставишь кресло против движения
[14:24:19] <valexey> ну да.
[14:27:06] <valexey> ладно. работать надо. пойду дальше писать mission critical систему на С++ :-)
[14:27:34] <landgraf> подушки в машине отключить не забудь =)
[14:28:55] <valexey> это можно. доступ к CAN-шине вроде бы есть :-)
[14:29:24] <valexey> кстати, видели дыру в CAN-шине?
[14:29:45] <valexey> https://www.opennet.ru/opennews/art.shtml?num=47039
[14:29:52] <landgraf> зачем тебе доступ? вытаскиваешь блок srs и все
[14:30:37] <landgraf> лучше, конечно, ккупить Ваз 2106 какой, чтобы не тратить ресурсы полезные =)
[14:30:57] <valexey> ну, я ж программист, кто ж меня до машины то допустит? для этого есть специальные люди.
[14:43:12] <landgraf> я бы некоторых программистов не допускал и до клавиатуры, так же как и некоторых "автомехаников" до машины
[14:45:08] <valexey> ну так то да. клавиатура штука отмирающая. надо голосом диктовать кому что делать!
[14:49:17] <valexey> кстати, а то, что контора X использует язык Y ни о чем не говорит. Вот если контора X перевела с свой проект P языка L на язык Y, то это еще может о чем-то сказать о применимости L и Y в проектах похожих на P.
А если просто X использует в P язык Y, то это могло сложиться исторически. Например много где до сих пор кобол вот используют. А NASA вот на C++ марсоходы программирует.
[15:26:38] <landgraf> я слышал люди и на питоне high-performace multi-threading applications программируют
[15:28:15] <valexey> угу. но частенько потом на С++ переписывают. например в яндексе.
[15:28:53] <valexey> и этот переход python->c++ что-то значит.
[15:29:24] <valexey> слышал и счастливые истории как с c++ перешли на python (если не полностью, то частично). для других проектов.
[15:30:15] <valexey> слышал о счастливом переводе проекта с D на C++. С Ады на C++. C Си на С++.
[15:30:19] <valexey> С python на go
[15:31:03] <valexey> c ruby на Go. Даже что-то слышал о переходе с C++ на java.
[15:32:13] <valexey> в переводе проекта с python на c++ в яндексе я даже успел поучаствовать. хотя он до сих пор целиком не переехал.
[17:49:00] <gour(home)> из ближайшего к моей работе: IBM QMF for Windows был на C++ и MFC, а теперь он на Java и стал большим, толстым и весьма кроссплатформенным.
[17:50:23] <valexey> компиляторы Go были один на Си, другой на С++, стали оба на Go
[17:50:23] <gour(home)> а QMF TSO/CICS и прочие z/OS с 1983-го года был на PL/X, а его successor разрабатывается на C++
[17:50:30] <valexey> с рантаймом гошным - аналогично.
[17:51:18] <gour(home)> писать компиляторы зависимые от самих себя это уже почти канон.
[17:52:00] <valexey> ну там товарищи довольно прагматичные. поэтому вначале на сях и плюсах два компилятора.
[17:52:11] <gour(home)> хотя про gcc-шный компилятор golang-а я не помню...
[17:52:18] <valexey> gccgo
[17:52:28] <valexey> на c++ был писан. теперь на go
[17:52:39] <gour(home)> молодцы.
[17:53:36] <valexey> ну, то есть они весьма прагматично работают. вначале сделали на том, на чем быстрее и надежней, на тот момент. потом переписали, как основное в языке вылизали.
[17:53:51] <valexey> точнее полуавтоматически конвертанули компилятор.
[17:53:57] <valexey> из си в Go
[17:54:14] <gour(home)> главное чтобы Lua не переписывали на Lua =)
впрочем, уже есть.
[17:54:27] <valexey> там конечно побочки были - первая версия гошного копилятора на го была медленней в пару-тройку раз
[17:54:45] <valexey> а вот есть Lua на Go! https://github.com/milochristiansen/lua
[17:55:03] <gour(home)> а на Go я сейчас буду пантограф себе моделировать. не на Аде... хотя... нет, всё-таки на Go.
[17:55:30] <valexey> оракл пишет тулзы на Го, интел пишет
[17:55:32] <gour(home)> есть. Go вообще Go-дный язык. =)
[17:55:45] <valexey> http://www.opennet.ru/opennews/art.shtml?num=47314
[17:56:11] <valexey> ну он такой, простой.. чуть сложнее чем чистый Виртовский оберон.
[17:56:18] <valexey> Примерно по сложности как Active Oberon
[17:56:20] <gour(home)> микросервисы как стиль жизни =)
[17:57:03] <gour(home)> ему бы, как смоллтолку, ещё и всё-в-себе-песочницу с гуями и прочим =)
[17:57:28] <valexey> в мире победившего веба гуй захвачен другими языками :-)
[18:02:06] <gour(home)> угу. потому как зачем морочиться, когда можно просто запустить сервер на первом попавшемся свободном порту локалхоста и заспавинить системный браузер, цепляющийся к самому себе )
[18:02:43] <valexey> ага
[19:24:56] <valexey> o! оказывается в плюсах strucy Node {std::map<i, Node> childs;}; -- это UB
[19:25:00] <valexey> няшненько!
[21:14:50] <gour(home)> ну... описывать структуру с раскрытием шаблонов через недоописанное самоё себя - это довольно сурово.
[21:16:35] <valexey> тем не менее - работает :-)
[21:23:12] <valexey> потому как sizeof(std::map<i, Node>) не зависит от sizeof(Node)
[21:23:31] <valexey> а вот с gcc'шной реализацией unordered_map так уже не прокатит
[21:29:13] <valexey> а с реализацией unordered_map которая в MSVS - опять всё прокатывает.
[21:32:48] <valexey> иногда плюсы напоминают чертово минное поле