форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Рассматривается возможность перевода NTPsec на язык Rust или Go"	+/–
Сообщение от opennews (ok) on 10-Янв-17, 09:54
Эрик Рэймонд (Eric S. Raymond (http://www.catb.org/~esr/)), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО,  изложил (https://blog.ntpsec.org/2017/01/03/getting-past-c.html) потенциальные планы по переводу разработки NTP-сервера NTPsec (https://www.ntpsec.org/) с языка C на более современный язык - Rust или Go. Проект NTPsec стартовал (https://www.opennet.ru/opennews/art.shtml?num=43350) в 2015 году как ответвление от NTP Classic, нацеленное на повышение безопасности. С тех пор была проведена чистка исходных текстов от устаревших возможностей, код приведён в соответствие стандартам C99/ANSI, функции работы с памятью и строками заменены на защищённые аналоги, не допускающие переполнения буфера, привнесены практики аудита кода, верификации и покрытия кода тестами. Сегодня же, команда разработчиков NTPsec рассматривает возможность в перспективе перевести NTPsec на Rust или Go. Решение ещё не принято, но подготовка кода к такому шагу уже началась, например, код NTPsec избавляют от использования типов union и операций приведения типов (type punning (https://ru.wikipedia.org/wiki/%D0%9A%D0%...)). Рэймонд указывает срок 6-9 месяцев, в течение которого команда намерена принять окончательное решение и выбрать язык программирования. Основными доводами в пользу смены языка является уход от небезопасных практик программирования на С, с целью повышения безопасности и надёжности NTPsec. Более конкретно, Рэймонд упоминает проблемы, вызванные выходами за границы буфера и висячими указателями (wild pointers (https://ru.wikipedia.org/wiki/%D0%92%D0%...)), заявляя, при этом, что он готов отказаться от C, несмотря на всё то время, которое он с 1983 года и по сей день вложил в изучение C со всеми его нюансами. Поскольку сегодняшние высокие требования к безопасности продолжают расти, пришла пора перейти на новый уровень, если он позволит снизить частоту появления ошибок. Эрик Рэймонд затрагивает и негативные стороны такого перехода, а так же способы решить потенциальные проблемы. Например, в случае перевода на Go проблемы могут быть вызваны остановками во время операций сборки мусора, что весьма критично для программы сихронизирующей точное время. Такие проблемы, вероятно, могут быть преодолены запретом сборки мусора на время выполнения критичного к задержкам кода. URL: https://blog.ntpsec.org/2017/01/03/getting-past-c.html Новость: https://www.opennet.ru/opennews/art.shtml?num=45832
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
Сообщение от eRIC (ok) on 10-Янв-17, 09:54
Пробуйте, посмотрим что выйдет...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
Сообщение от Аноним (??) on 10-Янв-17, 09:55
сборка мусора останавлиапет выполнение программы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+3 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 10:11
	да
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–3 +/–
	Сообщение от Пользователь Debian on 10-Янв-17, 10:38
	> да Нет. STW останавливает, а параллельная сборка -- нет. Цитата из <https://blog.golang.org/go15gc>: « Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978. This is a deliberate divergence from most "enterprise" grade garbage collectors of today, and one that we believe is well suited to the properties of modern hardware and the latency requirements of modern software. In a tri-color collector, every object is either white, grey, or black and we view the heap as a graph of connected objects. At the start of a GC cycle all objects are white. The GC visits all roots, which are objects directly accessible by the application such as globals and things on the stack, and colors these grey. The GC then chooses a grey object, blackens it, and then scans it for pointers to other objects. When this scan finds a pointer to a white object, it turns that object grey. This process repeats until there are no more grey objects. At this point, white objects are known to be unreachable and can be reused. This all happens concurrently with the application, known as the mutator, changing pointers while the collector is running. Hence, the mutator must maintain the invariant that no black object points to a white object, lest the garbage collector lose track of an object installed in a part of the heap it has already visited. Maintaining this invariant is the job of the write barrier, which is a small function run by the mutator whenever a pointer in the heap is modified. Go’s write barrier colors the now-reachable object grey if it is currently white, ensuring that the garbage collector will eventually scan it for pointers. » Впрочем, запрещать GC в критических участках это логичная идея.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+16 +/–
	Сообщение от КО on 10-Янв-17, 10:43
	>Впрочем, запрещать GC в критических участках это логичная идея. Программа коррекции датчика времени является таковой чуть более чем полностью. А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно. Правда тут в соседней новости собираются написать транслятор из C в Раст, чтоб PostgreSQL потянул. Как осилят - можно будет и NTP налету конвертить. :)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	47. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от A on 10-Янв-17, 14:20
	Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	59. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:55
	> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала. На хаскеле?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	80. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:10
	> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала. Учитывая что у мозиллы браузер превращается в тыкву и гуглхорм его обижает - скоро они кажется утратят способность раздавать гранты на разную концептуальную хну. А откуда они на это деньги будут брать? :)
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	65. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 16:14
	> А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно. Ну, блин, это ESR. Известный своими логичными и результативными достижениями. Правда наибольшую известность он почему-то снискал как холуй проприетарщиков.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+9 +/–
	Сообщение от Ordu (ok) on 10-Янв-17, 11:15
	Любой сборщик мусора периодически останавливает потоки выполнения, просто потому, что нет другого способа пересчитать объекты, ссылки на которые лежат в регистрах и на стеке. Другое дело, что некоторые алгоритмы, на самом деле даже большинство алгоритмов, стремятся свести такие остановки к минимуму. Например, выполнить максимум работы в бекграунде, из параллельного потока. Помечать области памяти, с которыми идёт работа, флагом ro, с тем чтобы проводить все манипуляции несмотря на то, что программа продолжает работать с объектами -- и это проходит гладко, если программа ничего не меняет, но в случае, если она вносит изменения, процессор выкидывает исключение, выполнение задачи прерывается, сборщик мусора обрабатывает исключение и позволяет программе продолжать выполнение. Там есть разные техники преодоления этих проблем, между прочим очень любопытные -- я читал книжку об этом запоем, кстати очень рекомендую в качестве увлекательного чтения какое-нибудь систематическое описание этих алгоритмов. Но финально всё сводится к тому, что останавливаются _все_ потоки, сборщик мусора из каждого потока выковыривает содержимое регистров и стековых фреймов, быстренько составляет список объектов достижимых при помощи регистров и стека, после чего позволяет программе продолжать работу, а сам заканчивает итерацию сборки мусора. В самых продвинутых алгоритмах, этот этап остановки очень короткий и неплохо масштабируется, потому что остановив все потоки на всех процессах, сборщик мусора сам начинает работать многопоточно, задействуя все процессоры, для того чтобы быстро-быстро всё сделать. Но как бы там ни было, остановки, пускай и короткие, происходят, причём чем круче алгоритм, тем менее предсказуемо когда произойдёт остановка. Любая запись в память может привести к прерыванию и переключениям между ring3 и ring0. Периодически же будут возникать остановки типа stop-the-world. Это может быть неважно для десктопного приложения, но для синхронизации времени, где речь идёт о микросекундах -- это не вариант. Точнее не так: это может быть допустимо, и Раймонд говорит о том, что может быть "и так проканает", если паузы действительно будут измерятся небольшим числом микросекунд, как обещают go-фаги. Но может быть и не проканает.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–17 +/–
	Сообщение от лютый жабист__ on 10-Янв-17, 11:39
	Ох уж эти эксперты по сборке мусора опеннета 8))))) можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов. А послушаешь местных аналитиков, так получается что программы на GO полчаса работают, потом час висят, мусор разгребают.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+7 +/–
	Сообщение от Ordu (ok) on 10-Янв-17, 12:05
	> можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов. Об этом тебе лучше молчать. Если ты несколько часов активно удаляешь объекты (ну и создаёшь соответственно активно, чтобы было что удалять активно), а сборщик мусора при этом бездействует, то твоей программе место в каком-нибудь специальном загончике для прочих жаба программ, жрущих оперативную память гигабайтами.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	66. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 16:15
	> закончить) с того, что сборщик обычно включается раз в несколько часов > и при активном удалении объектов. По закону подлости он решит отпедалить все это именно тогда когда интересовало точное время. Которое после такой диверсии перестанет быть точным, очевидно. Ведь если мусор несколько часов не собирали - вклин будет надолго.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	102. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 00:33
	Есть реализации GC без Stop The World. Такая, например, используется в Erlang. Достигается это тем, что у каждого микропроцесса в Erlang'е своя куча.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	115. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 12:19
	STW-то официально может и нет, но потоки останавливаются точно так же. Другое дело что паузы очень короткие и эрланг сам по себе просто тормоз для конкретно этой задачи.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	120. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 18:41
	>STW-то официально может и нет, но потоки останавливаются точно так же. Нет, не точно так же. Во-первых, не нужно синхронизировать остановку всех потоков, т.е. сами потоки не бывают остановлены на дольшее время чем нужно для сборки мусора в их конкретной куче. Во-вторых, остановка никогда не происходит в произвольном месте, обычно сборка мусора происходит при вызовах, выделяющих память, либо на блокирующих функциях типа ввода-вывода или, в случае erlang, отсылки-приёма сообщений. На том же хацкелле можно легко написать код, работающий в константной памяти и не дёргающий GC в принципе. Erlang, кстати, не такой тормоз. Но других косяков у него до жопы :(
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	55. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от rshadow (ok) on 10-Янв-17, 15:20
	В любом случае производительность рандомно проседает. Для реалтайма под нагрузкой GC наверно самое худшее решение.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	130. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от qsdg (ok) on 12-Янв-17, 02:24
	В той статье где разработчики Go хвалятся их будущим супер-сборщиком мусора на самом деле на рассмотрено ни одно негативное последствие их решения. Они преподносят свою идею как нечто революционно новое, хотя на самом деле всё что они делают уже давно известно 10+ лет. Они просто выбирают все возможные компромиссы ради укорочения паузы сборки мусора (но, например, частота таких пауз у них возрастает). Вот более подробный анализ недостатков их hype-collector: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e И таки да, любой сборщик мусора требует STW, даже теоретически невозможно сделать по-другому. Другое дело, что если этот STW -- считанные микросекунды, то всем пофиг. Хотя проектам типа NTP может быть и не пофиг.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	76. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от www2 (ok) on 10-Янв-17, 18:08
	> да Вытесняющая многозадачность, даже если в системе несколько ядер или процессоров, тоже прерывает выполнение программы. Выполняется ваша программа без сборщика мусора, а тут прерывание прилетает - диск сообщил, что прочитал заказанные секторы. Выполняется дальше - а тут сетевая карта сообщает, что она буфер пакетами наполнила. Особенно много подобных эффектов будет в нагруженных системах, где работает больше одной программы. Там сборка мусора может быть просто незаметной на общем фоне торможения.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "перевода NTPsec на язык Go или на язык Rust или на язык ...."	+/–
	Сообщение от Andrey Mitrofanov on 10-Янв-17, 12:36
	> сборка мусора останавлиапет выполнение программы? "Да, но." Там наверху по ссылке ESR сказал, [такую кепку] надо мерять: "In any case, the Go developers have a pretty convincing story about holding stop-the-world pauses down to the small-number-of-milliseconds range. We’ll have to measure, but that just might be tolerable even without the GC lockout." И вообще, нас, анонимов, не спросят (но мы будем следить, да...): "In the end it might come down to which language I feel more comfortable in." ---Классик, http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat... б--нть.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	92. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 20:35
	и отупляет мозг программиста
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+9 +/–
Сообщение от Sfinx (ok) on 10-Янв-17, 09:56
"пропала планета..." (c) космоболы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 10:02
	учитывая что это всего лишь спутник NTP Classic, а не планета, то такие эксперименты на пользу - если что можно вернуться или форкнуть
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+10 +/–
Сообщение от Аноним (??) on 10-Янв-17, 10:04
голосую за раст сборку мусора мы уже проходили, любопытнее глянуть, что покажет альтернативный подход
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Пользователь Debian on 10-Янв-17, 10:33
	> голосую за раст > сборку мусора мы уже проходили, любопытнее глянуть, что покажет альтернативный подход Ну, и будут они его переписывать при каждом выходе нового релиза Раста. Ах, да, а Раст уже научился компилироваться на чём-то, отличном от i686 и amd64?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	14. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от эцсамое (ok) on 10-Янв-17, 10:45
	да хоть в джаваскрипт умеет.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	30. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
	Сообщение от arzeth (ok) on 10-Янв-17, 12:40
	https://forge.rust-lang.org/platform-support.html Уже умеет компилировать на и для mips, mipsel, mips64, mips64le, ppc, ppc64, ppc64le, s390x.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	113. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 11:53
	Так он же просто поддерживает всё что умеет LLVM, разве не так? p.s. Если так то там только вопрос насколько корректна и качественна поддержка той или иной архитектуры в LLVM
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	58. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:29
	Ты не голосуй, а пойди и поучаствуй, если такой умный.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	121. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 19:44
	Я тоже голосую за Rust
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

6. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от анонимчик on 10-Янв-17, 10:09
1. что там такого надо переводить, все должно быть уже вылизано до блеска. 2. в чем новость? вот когда решат, тогда и будет новость. а сейчас пустая информация.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+4 +/–
Сообщение от Бутират on 10-Янв-17, 10:23
Началось!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	122. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 19:47
	Что? Сингулярность?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	148. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от anonymous (??) on 13-Янв-17, 10:50
	Ну да, на ноль поделили
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

9. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Spalf (ok) on 10-Янв-17, 10:23
На язык Rust или Go. Совсем никакой разницы, ага.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Пользователь Debian on 10-Янв-17, 10:32
	Ну так потому и 6-9 месяцев на решение.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	35. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от НяшМяш (ok) on 10-Янв-17, 13:00
	По-моему, за это время можно накатать два прототипа на обеих языках. Особенно, с учётом того, что код уже есть - его надо просто "перевести"
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	41. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+4 +/–
	Сообщение от хрю on 10-Янв-17, 13:52
	>По-моему, за это время можно накатать два прототипа на обеих языках. Накатайте. Как люблю теоретиков.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	81. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:14
	> По-моему, за это время можно накатать два прототипа на обеих языках. И этот код чувствителен к времени выполнения и прочим мелочам. Там вон народ с PTP за наносекунды давится и timestamp пакетов аж с сетевухи снимает, а этим GC видите ли не мешает. > Особенно, с учётом того, что код уже есть - его надо просто "перевести" А если так подумать - круто получается: софтина не выполняет свою прямую задачу (синхронизация точного времени). Зато, блин, на go.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	107. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от . on 11-Янв-17, 06:07
	>софтина не выполняет свою прямую задачу (синхронизация точного времени). Зато, блин, на go. Или на ржавчине.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	124. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 20:00
	У ржавчины нет сборщика мусора, там всё четко.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	114. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 11:55
	>> По-моему, за это время можно накатать два прототипа на обеих языках. > И этот код чувствителен к времени выполнения и прочим мелочам. Там вон > народ с PTP за наносекунды давится и timestamp пакетов аж с > сетевухи снимает, а этим GC видите ли не мешает. В новости - использование "безопасных строк" так-что какая-то часть rust-а ( или go или вплоть до php ) уже привнесена в проект.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	138. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноим on 13-Янв-17, 06:52
	> В новости - использование "безопасных строк" так-что какая-то часть rust-а ( или > go или вплоть до php ) уже привнесена в проект. Это с чего бы? Безопасные строки сами по себе к горастам никак не относятся. Впрочем, ESR известен своей могучей тягой к хайпу и прочему корпоративно-маркетинговому булшиту.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	123. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 19:59
	язык - он
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

15. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
Сообщение от _hide_ (ok) on 10-Янв-17, 10:47
>>> несмотря на всё то время, которое он с 1983 года и по сей день вложил в изучение C со всеми его нюансами в оригинале он ничего "не вкладывал", а просто на нем разрабатывал: >>> I’ve been writing steadily in C since 1983, and am correspondingly deeply aware of its quirks and flaws
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	56. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:26
	"Вложил свои силы и энергию в разработку программ и изучение C" --- вполне правильный перевод.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	61. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от _hide_ (ok) on 10-Янв-17, 15:59
	Да, всё дело в формулировке. Неуместным казалось "вложил в изучение". Вообще тут очень скользкая тема, потому спецификация довольно тривиальна и логична, а вот компиляторы... А они имеют свои особенности и именно на их изучение тратится много время, а не на C. Ладно, ждем NTPsec на GO.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	93. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Михрютка (ok) on 10-Янв-17, 21:35
	два словаря Мюллера этому господину.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	100. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Comdiv (ok) on 10-Янв-17, 23:53
	Как-то ловко Вы пропустили следующее предложение - "Despite my huge investment of time in the language, I’m ready."
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	111. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от _hide_ (ok) on 11-Янв-17, 10:45
	Инвестиции !== вложения. Ладно, проехали, пошёл искать Мюллера...
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	112. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 11:05
	investment (ɪnˊvestmənt) n 1) инвести́ция; вклад 2) (капитало)вложе́ние, помеще́ние де́нег, инвести́рование 3) предприя́тие или бума́ги, в кото́рые вло́жены де́ньги 4) оде́жда, облаче́ние 5) облече́ние полномо́чиями, вла́стью и т.п. 6) воен. оса́да, блока́да 7) attr.:     investment bank амер. инвестицио́нный банк;     investment goods това́ры произво́дственного назначе́ния;     investment outlet сфе́ра примене́ния капита́ла Очевидно, в оригинале имелась в виду "одежда" или "осада", да.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

16. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
Сообщение от бедный буратино (ok) on 10-Янв-17, 11:01
пацаны из openntpd и не знают
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+3 +/–
	Сообщение от mike_t on 10-Янв-17, 11:39
	пацаны из openntpd написали бы сначала ntp, а не sntp
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	83. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:19
	> пацаны из openntpd написали бы сначала ntp, а не sntp Извини, если в софтину втулить все эти керберосы, лдапы и TLS - она перестанет быть секурной на любом ЯП. Просто потому что адские сотни кода. Поэтому пусть лучше остается как есть. Так он будет безопасным даже на сишечке, а хомяки с го и прочие раст-о-маны будут CVE пачками чинить. DJB про надежность софта все очень правильно ведь сказал. И без привязки к ЯП вообше.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

17. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–13 +/–
Сообщение от Аноним (??) on 10-Янв-17, 11:04
Наконец даже до старпёров начало доходить что C пользоваться нельзя ни под какими предлогами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от доктор психиатор Котлетова on 10-Янв-17, 11:54
	Нет, пока не начало.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 11:54
	судя по его комменту он давно был готов соскочить с С, но до недавнего времени не было даже кандидата куда >> I want to finish by saying that I find it rather exciting to be working at a time when replacing C in core infrastructure like NTP is even thinkable.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	89. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от XoRe (ok) on 10-Янв-17, 19:46
	> судя по его комменту он давно был готов соскочить с С, но > до недавнего времени не было даже кандидата куда >>> I want to finish by saying that I find it rather exciting to be working at a time when replacing C in core infrastructure like NTP is even thinkable. Не готов, а просто радуется, что появились альтернативы. В чем-то его можно понять, монополия никому не шла на пользу. В том числе, монополия на звание "единственного языка системного уровня".
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 12:08
	А чем можно?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	57. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:28
	> Наконец даже до старпёров начало доходить А то много с ними общался, что бы такие заявления делать?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	84. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:20
	> Наконец даже до старпёров начало доходить что C пользоваться нельзя ни под > какими предлогами. Ух, ты уже перешел на ту чудо-систему на Rust? Где один кернел для запуска гиг требует? И файлуху еще возьми, нуб.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	125. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 20:03
	Вы хотели сказать нежелательно? Я думаю у старперов..., да и не только, этот вопрос как минимум пока открыт
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

25. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Аноним (??) on 10-Янв-17, 12:12
Просто за C11, видимо, дело идет к новому стандарту Си.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Ordu (ok) on 10-Янв-17, 12:47
	http://blog.llvm.org/2011/05/what-every-c-programmer-should-... Такие откровения от разработчиков современных компиляторов, наводят на мысли, что C имеет фатальные недостатки, которые невозможно устранить, не ломая конкретно совместимость с существующей базой кода на C. И именно такие мысли, я подозреваю, сделали неотвратимым появление всяких там rust и Go.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	60. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:57
	> http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Такие откровения от разработчиков современных компиляторов, наводят на мысли, что C имеет > фатальные недостатки, которые невозможно устранить, не ломая конкретно совместимость > с существующей базой кода на C. > И именно такие мысли, я подозреваю, сделали неотвратимым появление всяких там rust > и Go. Разработчики современных компиляторов сами себя в эту ситуацию загнали, некоторые оптимизации которые они используют и их реализация вообще спорны. И к языку как таковому это по моему не совсем относится, C всегда был "ассемблером с человеческим лицом".
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	64. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 16:14
	клоун: описанные оптимизации невозможны без ОЧЕНЬ несбалансированных настроек компилятора. Взять первую описанную проблему - удаление строки dead = *p. Даже если переменная dead не используется, разыменование является значащей операцией и компилятор до проверки на NULL эту строчку никогда не удалит. Однажды автора подобных статей поймали на прямой лжи и он заявил что просто выдумал свои примеры.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	72. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Ordu (ok) on 10-Янв-17, 17:52
	> разыменование является значащей операцией В C++ это значащая операция. Да и то не всегда. В C же разыменование не имеет побочных эффектов -- возможный кеш-промах, со всей последующей активностью процессора не в счёт. Разыменование может иметь побочные эффекты, если оно приводит к UB, например, в случае чтения из нулевого указателя. Но если оно приводит к UB, то компилятор волен действовать так, как ему заблагорассудится. А чтобы не быть голословным, вот результат компиляции $ cat tmp.c void fn(int *p) {     int dead = *p;     if(!p)         return;     *p = 4; } $ gcc -v ... gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4) $ gcc -Wall -O2 -S tmp.c tmp.c: In function 'fn': tmp.c:3:6: warning: unused variable 'dead' [-Wunused-variable]   int dead = *p;       ^ $ cat tmp.s     .file    "tmp.c"     .section    .text.unlikely,"ax",@progbits .LCOLDB0:     .text .LHOTB0:     .p2align 4,,15     .globl    fn     .type    fn, @function fn:                                        ; <--- точка входа функции .LFB0:     .cfi_startproc     testq    %rdi, %rdi         ; проверка на нуль     je    .L1                           ; если нуль, то го на выход     movl    $4, (%rdi)         ; иначе: *p = 4 .L1:     rep ret                            ; собственно выход     .cfi_endproc .LFE0:     .size    fn, .-fn     .section    .text.unlikely .LCOLDE0:     .text .LHOTE0:     .ident    "GCC: (Gentoo 4.9.4 p1.0, pie-0.6.4) 4.9.4"     .section    .note.GNU-stack,"",@progbits
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	73. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 17:57
	клоун: именно потому, что она может повлиять на логику выполнения программы, эта операция является значащей. То, компилятор не учитывает это простое правило, многое говорит о его качестве.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	75. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним84701 (ok) on 10-Янв-17, 18:07
	> клоун: именно потому, что она может повлиять на логику выполнения программы, эта > операция является значащей. > То, компилятор не учитывает это простое правило, многое говорит о его качестве. Оно? clang (3.9.1) -O3 -S -masm=intel test.c contains_null_check:                    # @contains_null_check         .cfi_startproc # BB#0:                                 # %entry         push    rbp .Ltmp0:         .cfi_def_cfa_offset 16 .Ltmp1:         .cfi_offset rbp, -16         mov     rbp, rsp .Ltmp2:         .cfi_def_cfa_register rbp         test    rdi, rdi         je      .LBB0_2 # BB#1:                                 # %if.end         mov     dword ptr [rdi], 4 .LBB0_2:                                # %cleanup         pop     rbp         ret Современного интелькомпилятора не имею, есть МСшный (VS 2010), но доставать хард с образом виртуалки, честно говоря, влом.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

Часть нити удалена модератором

	79. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 18:41
	Напишите, пожалуйста, название книги (если она вообще есть в электронном варианте)
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от жабабыдлокодер (ok) on 10-Янв-17, 20:22
	А потом ставим этот самый Автокад на нормальный компьютер, на котором громадные карты МапИнфо и ИнГео летают - и, вуаля! Шевелится еле-еле, тормоза во всем страшные. Алгоритмы, может, и оптимизированы, а вот память жрет как не в себя. Результат - что оптимизируй, что не оптимизируй, а микрософтовские индусы только одну субстанцию и производить умеют.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Тот_Самый_Анонимус on 10-Янв-17, 20:29
	>Они написали 90 алгоритмов для каждого из углов и оптимизировали их все То, что углов больше 90, почему-то не рассматривается. Может это просто гонево?
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 00:24
	> Может это просто гонево? Его фраза "для компании AutoCAD" прекрасно демонстрирует, что он даже название программы от названия компании-разработчика отличить не может. В сочетании с остальным текстом комментария получается, что с вероятностью, стремящейся к 100%, это была всего-лишь попытка потешить своё клоунское ЧСВ.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	105. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 01:53
	клоун: Эта история мне нравится по двум причинам. Во-первых, она мотивирует. А во-вторых она написана в одной из таких книг, про которую все знают и говорят, но которую никто никогда не читал. Как библия у христиан. А для программистов это... Что-то уже многовато спойлеров :).
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	106. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Тот_Самый_Анонимус on 11-Янв-17, 05:28
	> Что-то уже многовато спойлеров :). Ты красиво обошёл замечание, что углы не ограничиваются градусами. Видать эта информация оказалась тебе не по зубам.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	108. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от . on 11-Янв-17, 06:14
	Он клован, а не математик (\программист\ботаник\Ынженер) ... Зачем кловану радианы? Оне не смешные :)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	126. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 20:10
	Да. При том недоработки, которые делают невозможными некоторые оптимизации, многочисленны. Есть еще вариант ввести альтернативный синтаксис, но за это их возненавидят. У Rust'а же безопасность дает побочный эффект в виде улучшеного статического анализа и оптимизации компилятором. Например при копировании областей памяти заранее известно, пересекаются они, или нет. У С/С++ всё на указателях, включая весь stl, там нужны проверки в рантайме.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

26. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+5 +/–
Сообщение от Аноним (??) on 10-Янв-17, 12:13
http://geekz.co.uk/lovesraymond/wp-content/images/ep013.jpg
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+6 +/–
Сообщение от Гентушник (ok) on 10-Янв-17, 12:28
По-момему с C было бы логичнее перейти на D. И сборка мусора там есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Аноним (??) on 10-Янв-17, 12:50
В тексте проскальзывает желание изменить практики программирования, а как средство достижения этой цели рассматриваестся варианты переходов на другой язык программирования. Как бы логично, но не совсем. Мне кажется, что сегодня все немножко помешались на новых языках программирования и пробуют занести их в самые разные области применения программного обеспечения. А надо ли? Почему бы не оставить этот С, только не писать его руками, в подготовить инструменты, которые будут эксплуатировать правильные практики и генерировать С-код, который будет компилироваться и обеспечивать компактность, производительность и не терять при этом надежность? И примеры такого подхода были и есть. Например "Р" - https://github.com/p-org/P. Можно было бы адаптировать/доработать Р или например SPIN и собственно решать основную задачу,  привнесение правильных практик в этот мир (в случае с Р это автоматное программирование ((с) А. Шалыто) ), а не переписывать на другой язык программирования. Говоря аллегориями, читать Достоевского или О'Генри удовольствие и на русском и на английском (при хорошем переводе, конечно), а какую-нибудь Дарью Устинову и на русском-то тяжело (imho :) ).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 12:55
	Прошу прощения, Татьяну Устинову. Я - знаток :)
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	42. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 13:53
	клоун: по сути ты тоже предлагаешь новый ЯП, только компилировать предлагаешь не в бинарный код/псевдокод, а в код на языке Си, который потом будет скомпилирован в бинарный код/псевдокод. Зачем нужна прослойка в виде Си? И если нужна, то почему именно Си? Другой момент: производительность ПК достигла уровня, когда можно больше не экономить память (кто не помнит, в MS DOS использовали три глупых команды вместо двух умных чтобы сэкономить 1 байт). И сейчас производительность подходит к уровню, когда можно больше не беспокоиться об освобождении памяти: программист её только выделяет, сборщик мусора автоочищает. Новые техники программирования требуют новых языков, их использующих.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	48. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 14:27
	Эмбендовка смотрит на тебя, как на PHPера и Goпника.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	49. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–4 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 14:38
	клоун: если ты про "умные" вещи, то там стоит уже весьма производительное оборудование. Вот на последней выставке "умное мусорное ведро" представили с распознаванием выкидываемого мусора. Что-то я очень сомневаюсь, что у них ПО на асме или на Си.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	87. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:41
	Производительность очень уж клещится с энергопотреблением. Маленькая система много лопать не может потому что перегреется. А многие эмбедовочные системы нуждаются еще и в автономном питании или им вообще технически невозможно mains протянуть. Я что, буду тянуть 220 вольт к каждому датчику протечки? Чтобы как раз растекающиеся по воде 220 вольт всех положили, мде?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	95. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 22:00
	клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов. Как там было в "Назад в будущее": - когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление. - Аааа! Ну да... У меня с этим туго...
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	133. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
	Сообщение от Аноним (??) on 12-Янв-17, 17:35
	> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов. 220 (да и поболее) без проводов уже давно есть в некоторых местах практически в любой хате. В твоей, точно есть такие места. Вот только находится в этих местах чревато необратимыми повреждениями не только для живых организмов. Так что не будет _никогда_ сколько-нибудь значимая величина электромагнитной энергии "по всей хате без проводов". Ещё неизвестно чем вайфаи, мобильные телефоны, беспроводные камеры, блютусы аукнутся через пару поколений. Либо приборы будут потреблять ничтожно мало (а никак не 220 В). Либо передача без проводов будет из конкретной точки, по конкретному пути, в конкретную точку(и все эти точки, пути защищены от тыканья пальцем). Либо откроют что-нибудь новое - поле, не взаимодействующее с окружающей материей, путь через измерения в которых наша материя не существует (может квантовая спутанность и объясняется тем что в каком-то измерении частицы находятся рядом).
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	139. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 07:05
	> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В > будет по всей хате без проводов. Да оно и прям ща можно. Открыл микроволновку и врубил. Энергии наружу вылезет немеряно, только собирай. А если вон те киловатты для плиты таки вкачать и таки по воздуху - ты себя не ощутишь куском мяса в микроволновке? Уверен? А то что-то для чуваков работающих с мощными передатчиками нормативы какие-то есть, при том не ГТО :) > Как там было в "Назад в будущее": > - когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление. > - Аааа! Ну да... У меня с этим туго... Да вот блин хотя-бы революцию в хотя-бы аккумуляторах обещают уже лет как хренадцать. Ежегодно не менее дюжины новостей. Г-Д-Е?! И если у тебя с чем-то туго, то я вот физику не прогуливал. И поэтому догадываюсь об проблемах и ограничениях. Пока-что переают на сантиметры и спасибо если 80% от того что было. В принципе и на метр-два можно, но уже 40%. Что как-то не прикольно уже. А так ты извини но электричество без проводов еще Тесла гонял. Так что баянище! Выглядело круто, но вот КПД...
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	53. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:01
	Язык C, как прослойку, часто используют для того, что бы поддержать бОльший спектр аппаратных платформ. Новый то он новый, конечно. Но в отличи и от старых языков, приложение на таком новом может быть формально верифицировано. В частности Р - язык взаимодействующих автоматов, корректность которых можно формально доказать. А SPIN, например, позволяет формально доказывать наличие гонок в коде. Я не предлагаю использовать Р или SPIN. Но пример и путь микроядра seL4 (https://sel4.systems) мне кажется правильным. Разработчики seL4 пошли по пути разработки собственных инструментов по генерации и верификации С-кода (сами инструменты сделаны на Haskell). Практическое программирование должно больше опираться на формальные математические методы, которые хорошо проработаны в научном программировании. Хотя текущее направление работ в Rust (например https://kha.github.io/2016/07/22/formally-verifying-rusts-bi... и http://ticki.github.io/blog/a-hoare-logic-for-rust/) мне нравится. Еще раз, Эрик говорит про устаревшие практики программирования. Я с этим согласен полностью и отметил лишь тот момент, что просто смена языка программирования может не дать результатов если не подкрепить их теорией. А теория должна быть заложена в новый язык. Компилятор этого нового язык может быть как самодостаточным (с свои рантаймом (например MLton)) так и являться утилитой, которая создает С-код не требующий рантайма больше чем стандартная библиотека С. Самодостаточный вариант не всегда возможен, т.к. в общем случае существуют аппаратные ограничения. И хотя в текущем случае с NTPsec аппаратные ограничения на память можно считать отсутствующими. Ограничения на использование CPU существуют (многопоточность и гонки никуда не денутся (как в приложении так и в рантайме языка) и хочется их поймать до этапа эксплуатации)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	63. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 16:09
	клоун: трансляцию в другой ЯП используют только если не смогли написать компилятор. > пошли по пути разработки собственных инструментов по генерации и верификации С-кода Зачем? В новых ЯП или сама проблема больше не возникает, или есть более простое её решение. Пробовал когда-нибудь отлаживать ассемблер? Каким бы удобным не был отладчик для асма, отлаживать Си на порядок быстрее, удобнее и проще. А работать с новыми ЯП ещё быстрее и проще, чем с Си.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	85. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:29
	> Другой момент: производительность ПК достигла уровня, когда можно больше не экономить память Микроконтроллерам все это расскажешь. Как захочется поработать 5 лет от пары пальчиковых батареек - так народ творит просто чудеса оптимизации. Зато и результат того стоит. И вот что-что а маложручие дешевые датчики - это основа основ IOT. Без них далеко не уедешь. В смысле, если ты свой х86 гроб прицепил к интернету и мусорке это еще не IoT и даже не эмбедовка как таковая. А как все это потом работает популярно разъяснил гражданин Зенков. У которого однажды не включился насос в его системе. Мало кому такие плюхи в управляющих системах захочется.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	116. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 14:28
	С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти везде", хотя она экономичней чем микроядро с 4кб. кода, т.е. всегда есть несколько параметров, иногда "выгодней" заряжать раз в день (смартфоны) иногда мелкосерийные сбис и аналоговые вычислители.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	117. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 14:30
	> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти > везде", хотя она экономичней чем микроядро с 4кб. кода, т.е. всегда > есть несколько параметров, иногда "выгодней" заряжать раз в день (смартфоны) иногда > мелкосерийные сбис и аналоговые вычислители. P.s. Есть ещё такие вещи как влияния "массовости" на потребление ресурсов, современный процессор на 60нм. может жрать меньше чем заказные "схемы на толстых кристаллах"
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	140. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 07:15
	> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти везде", Так МК как раз и делает все в софте. Железом какие-то тяжелые операции подперты, но рулит всем софт. Просто они предсказуемые, маложручие, на жесткий реалтайм заточены. Можно обмотки мотора вместо механического коллектора софтом переключать. Variable-freqency drive называется. А как ты думал напругу с разной частотой синтезируют? Ну не жесткой же логикой, на ней делать анализ состояний, защиты от перегруза и проч - замахашься. > мелкосерийные сбис и аналоговые вычислители. Нц вот это редко: затраты на пуск в производство чипа - довольно высокие. А клоуну удачи с его маздаем и писюком в мусорке. Нуачо, поконкурируем. Надо же показать ушлепанам пихающим глючный писюк что можно сделать в разы дешевле, надежнее, экономичнее, и вообще? :)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

36. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
Сообщение от Аноним (??) on 10-Янв-17, 13:16
Вот так, сначала учат юных падованов на "удобных" языках, а потом, обнаружив, что те не умеют писать продуманный код, ищут, какой бы такой "безопасный" язык подобрать для своих криворуких выкормышей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	68. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 16:26
	клоун: ИТ перегрет. Дорогостоящие специалисты с "системным мышлением лямбда-паттернами" уступают своё место гораздо более дешёвым. Ты знаешь 10 алгоритмов сортировки и 4 алгоритма транспонирования матриц? Это давно никому не нужно. Ной, не ной, но за этим будущее. И в нём ИТ-шник зарабатывает не больше, чем водитель троллейбуса.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	74. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от www2 (ok) on 10-Янв-17, 18:00
	Не так. ИТ-шники со знанием 10 алгоритмов сортировки и 4 алгоритмов транспонирования матриц пишут автопилот для автобусов, а осовободившиеся водители троллейбусов переквалифицируются в программи^Wб*длокодеры и продолжают получать те же деньги, но теперь уже не за вождение троллейбусов, а за каловые массы кода.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	77. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–3 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 18:15
	клоун: те же деньги? Держи карман шире... Онлайн-биржи чётко показывают тренды: ИТ - это индусы по 5 копеек. Если смотреть шире, то это та самая уберизация, о которой столько говорят в других сферах. Вместо дорогостоящего профессионального такси с профессиональным таксистом, тебе готовы за копейки подогнать машину, которая едет в ту же сторону.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	86. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 19:37
	> - это индусы по 5 копеек. Правильно. Потому что основам программизма нынче учат в любом вузе и даже школе. И индусов тоже! Поэтому если ты умеешь писать какую-нибудь вебню как еще милиард индусов - получается что ты в общем то ничего такого уникального и не умеешь. Сюрприз. И работать за зарплату водителя троллейбуса - удел вот таких специалистов. Которые специалисты ни в чем. Ну как, писать glue code склеивающий функции фреймворка может даже индус. Значит это стоит вот столько. А водителей троллейбусов вообще зохвает автопилот в самом обозримом будущем. Компьютеры лучше в рутинных работах.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	96. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 22:04
	клоун: Именно. Только не "таких вот", а всех. Стремясь зарабатывать больше, они захавают соседние области, в результате доходы отрасли в целом скатятся под плинтус. Сроки тоже примерно понятны. Пока ИТ растёт на 10-15% в год этого не случится, но замедлись рост до 1-5%, как в других отраслях - и вот тебе берег, приплыли!
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	141. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 07:29
	> в результате доходы отрасли в целом скатятся под плинтус. Не вижу предпосылок. Обычное разделение на чернорабочих и квалифицировнные кадры, придумано задолго до айти. Мало стоят работы на которые нет спроса или слишком много предложения. Обычный рынок. > - и вот тебе берег, приплыли! Вот лично мне чего-то IoT-образного в ближайшее время явно хватит. Я не говорил что довольно смешно перехватывать заказы подобным тебе элементам интерьера? :) Пока такие чудаки рассказывают про писюки, я высовываюсь с решением которое делает то же самое, только в разы лучше по всем параметрам, заказчики фигеют от такой разницы. Как вы там говорили? Ничего личного, это бизнес? Пора научить бракоделов с писюками в эмбедовке основам ведения бизнеса. Ага, у меня скринсэйверы экспы не висят. И регистрация не слетает. И бсодов нет. И press F1/any key/... не бывает. И лицензионно все чисто. И можно кастомизнуть под окружение. А попробуй так с своим маздаем и х86, ога. Если ты думаешь что сможешь взять эту высоту - фигня вопрос, попробуй :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

37. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+6 +/–
Сообщение от evkogan on 10-Янв-17, 13:23
Выглядит как, мы сделали все хорошо, теперь нам скучно. Думаем, а не поломатьли и начать заново.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Юрий (??) on 10-Янв-17, 13:25
А смысл переходить? Расскажите мне, необразованному, с чем там С не справился.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 13:36
	Программисты уже не те. Хакеры не те. Это как гвозди без перчаток забивать - удобно, но после десятого удара по пальцам внезапно задумался.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 10-Янв-17, 13:43
	в первом же абзаце сказано >> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns, and in general much stronger security and correctness guarantees. похоже за буфером следить слишком муторно насчет других проблем можно почитать по ссылочке, которую давали выше http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	44. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+5 +/–
	Сообщение от Ordu (ok) on 10-Янв-17, 14:06
	C в состоянии справиться с чем угодно -- он тьюринг-полный язык программирования. А причины переходить, примерно те же, что и причины, которые толкнули Томпсона с Керниганом писать unix на C, а не ассемблере. Разработка программ не стоит на месте. Она развивается. Требования меняются, меняется окружение, в котором работают программы. Меняется, наконец, типичный размер программы, причём в сторону увеличения. Это тренды, которые сопровождают разработку программ с самого начала, они подтолкнули когда-то системное программирование к переходу на C с ассемблера. Они же сейчас толкают в сторону ухода от C. Сегодня C подпирают костылями, типа статических анализаторов кода, его подпирают и динамическими анализаторами, типа valgrind. Но тренды никуда не деваются, и подпирать до бесконечности не удастся. И если Эрик Раймонд таки решится перевести системную программу на rust или go, то это будет очень полезным опытом. Причём полезным в любом случае -- как в случае успеха, так и в случае неудачи. Это даст возможность посмотреть на то, что из себя представляют rust с go в системном программировании. Пока, по большей части, вместо эмпирических данных мы имеем мнения экспертов, разной степени анонимности. Но как показывают исследования, мнения экспертов хороши тогда, когда не происходит радикальных изменений -- это очень хорошо видно по экономическим предсказаниям: эксперты хорошо предсказывают нормальное поведение рынка, но точность предсказаний падает до точности гадания на кофейной гуще, в случае сильно и резко влияющие на рынок событий. Я не знаю, насколько для Раймонда является движущим мотивом возможность поставить такого рода эксперимент, но для нас, как для сторонних наблюдателей, запасшихся попкорном, это несомненно отличный мотив. А, и кстати, если отвлечься от мнения анонимов о том, в чём плюсы, а в чём минусы, есть сукцесс стори о расте: https://onesignal.com/blog/rust-at-onesignal/ Основные бонусы раста проявляют себя, в принципе, как и ожидалось. А минусы, по большей части, связаны с молодостью и неразвитостью инфраструктуры -- breaking changes в библиотеках, нехватка инструментария и прочие.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	46. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Юрий (??) on 10-Янв-17, 14:17
	Спасибо большое! Я примерно так и думал!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

43. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Аноним (??) on 10-Янв-17, 13:58
Мне кажеться, подобный сверхважный софт надо писать на Forth и математически подтвердить надежность. А писать на всяких rust, переписывать из-за новых хипстерских идей в компиляторе это не для такого софта.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Ordu (ok) on 10-Янв-17, 14:08
	И платить за ntp-сервер по $500 в месяц? Часть 1: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year Часть 2: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year... Ну, то есть, там проблема была не в том, что код сервака был особо тормозным, но если бы он был ещё и тормозным...
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	94. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Михрютка (ok) on 10-Янв-17, 21:49
	> И платить за ntp-сервер по $500 в месяц? > Часть 1: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year > Часть 2: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year... > Ну, то есть, там проблема была не в том, что код сервака > был особо тормозным, но если бы он был ещё и тормозным... ето ничего, ето я еще не вижу в графиках вообще ни разу хостов из-под HyperV, где хостить линь без ntpd крайне проблемно, время уезжает шо ппц. и тут же мы накинем лопатой IoT. вы думаете, там будут синкаться 1-4 раза в сутки? а вот фиг вам, только ntpd, только хардкор. кушайте не обляпайтесь.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

51. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+2 +/–
Сообщение от Аноним (??) on 10-Янв-17, 14:48
Rust — это системный язык программирования, внимание которого сосредоточено на трёх задачах: безопасность, скорость и параллелизм. Согласно дизайну языка Си, такие задачи ему не ставились(ситуация была другой). Его конструкции близко сопоставляются типичным машинным инструкциям, а всё остальное проблемы программистов. С учётом развития и распространением "железяк" эти самые проблемы стали более актуальными. К тому же свои требования предъявляет бизнес(кто первым: займёт нишу и будет предоставлять лучшие услуги). Безопасность, скорость и параллелизм должны быть частью языка, а оптимизация производительности под конкретную платформу - проблема соответствующего инструмента. БОльшую часть программных продуктов, так или иначе, создают для зарабатывания денег. Выживает(остаётся востребованным) тот кто своевременно адаптируется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	52. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+3 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 15:00
	Будто прочитал рекламную листовку.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	103. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 00:43
	> Его конструкции близко сопоставляются типичным машинным инструкциям Не поэтому ли чуть менее, чем во всех бенчмарках компилируемых языков именно Си выступает в качестве эталона? Не близость ли к железу позволяет программисту (при достаточной квалификации, разумеется) лучше понимать, как именно будет работать скомпилированный код и как его можно {на|пере}писать, чтобы выжать из железа максимум?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	119. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+3 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 15:15
	> Не близость ли к железу позволяет программисту (при достаточной квалификации, разумеется) лучше понимать, как именно будет работать скомпилированный код Только действительно понимает, хорошо, если один из десяти. Остальные или считают, что они понимают или вообще из категории "напишу-ка на асме^W cи, ведь это круто! А еще там пони магией починят мои х*еновые структуры данных с алгоритмами. Какие кэшмиссы, бранчпредикшн и выравнивания с симдами? Там же МАГИЯ!"
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	129. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Аноним (??) on 12-Янв-17, 00:27
	С магией лучше к поклонникам того же Rust-а, например, то и дело лезущим со своей верой в способность компилятора если и не превратить кривой код к конфетку, то, как минимум, невозможность компиляции этой кривоты (типа статический анализ, обещания безопасности и всё такое). *По моим личным наблюдениям*, сишники/плюсовики куда более склонны более-менее адекватно оценивать сложность написания качественного кода на этих языках и признавать огромное количество грабель, по которым можно при этом пройтись.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	136. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 12-Янв-17, 20:00
	> С магией лучше к поклонникам того же Rust-а, например, то и дело > лезущим со своей верой в способность компилятора если и не превратить > кривой код к конфетку, то, как минимум, невозможность компиляции этой кривоты > (типа статический анализ, обещания безопасности и всё такое). Как будто неолуддиты, отвергающие технический прогресс, чем-то лучше. По их логике правда и беспилотные автомобили всегда будут только игрушкой для неосиляторов вождения, потому как, пока что, даже весьма посредственный водитель уделывает таких автопилотов на раз! Да и тест Тюринга эти автопилоты тоже не проходят! )
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	142. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
	Сообщение от Аноним (??) on 13-Янв-17, 07:34
	> Rust — это системный язык программирования, И как, много на нем систем то уже напрограммировали? Бутлоадер на этой системщине напсать? Или под микроконтроллеры попрограммить? А то понимаешь совсем не круто знать пять разных языков для разных задач, каждый понемногу и хреновенько. Получится один сплошной джамшутинг. Ну вон там в соседней новости питонобезопасность, понимаешь.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

54. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от th3m3 (ok) on 10-Янв-17, 15:15
Я понимаю ещё Rust, но на Go переходить? Жесть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от J.L. on 10-Янв-17, 17:17
	> Я понимаю ещё Rust, но на Go переходить? Жесть. аргументируйте
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	104. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 11-Янв-17, 00:52
	В комментариях к оригиналу даже NodeJS предложили. Стильно-модно-молодёжно, ага. Если изначальное заявление не содержит даже намёков на аргументацию, то, скорее всего, её и потом не будет.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

69. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Аноним (??) on 10-Янв-17, 17:16
Если уже совсем нет возможности оставаться на Си, то тогда хотя бы Go, но никак ни Rust.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	71. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от J.L. on 10-Янв-17, 17:18
	> Если уже совсем нет возможности оставаться на Си, то тогда хотя бы > Go, но никак ни Rust. аргументируйте
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	82. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Мадара (ok) on 10-Янв-17, 19:14
	наверное по той же причине почему не C++
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	131. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–3 +/–
	Сообщение от Аноним (??) on 12-Янв-17, 09:45
	Тогда должен быть Rust, а не Go
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	134. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Андрей (??) on 12-Янв-17, 18:24
	1. Go был предложен в 2009 как альтернатива Си. 2. Именно участвующие в разработке Си и его диалекта в Plan9 разрабатывают Go. 3. Компилятор очень быстрый (а был вообще как молния). 4. Минимум зависимостей для сборки. 5. Весь компилятор с линкером, ассемблером, солидной стандартной библиотекой собираются у меня за полторы минуты! А конца сборки Rust я так и не дождался. Вот числа с buildd.debian.org: golang-1.7    1.7.4-1                amd64    5m        400.29 MB rustc            1.14.0+dfsg1-2    amd64    7h 3m    3.45 GB (Builder: x86-grnet-01) Источник: https://buildd.debian.org/status/logs.php?pkg=golang-1.7 https://buildd.debian.org/status/logs.php?pkg=rustc Это не то что нельзя с Си сравнить, это просто ещё хуже Си++! 6. И там уже есть утилитки как трейсер, профайлер,.. 7. Очень удобная кросс-компиляция. Проще не видел. 8. Из поддерживаемых платформ есть Plan9. Наверняка, ещё что-то забыл.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	135. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
	Сообщение от Аноним (??) on 12-Янв-17, 19:32
	> 1. Go был предложен в 2009 как альтернатива Си. Было дело. Если поискать, то пиарили в самом начале как "системный" язык. Только на деле он такая же альтернатива Си, как опеннетчики балеринам.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	145. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Andrey Mitrofanov on 13-Янв-17, 09:09
	>> 1. Go был предложен в 2009 как альтернатива Си. > Было дело. Если поискать, то пиарили в самом начале как "системный" язык. > Только на деле он такая же альтернатива Си, как опеннетчики балеринам. Все на Lisp ! Ура.    https://www.gnu.org/software/guix/    https://www.gnu.org/software/shepherd/ //Поясняю: scheme - это lisp, в хоро ^W широком смысле. См.историю лиспов, lisp-1--vs--lisp-2 и пр. ==Для контекста [опенета] разницы нет. +++"Это я вам, как троль-балерина в первом поколении говорю."ТМ
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	143. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Андрей (??) on 13-Янв-17, 07:54
	6. ..., race detector,..
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	144. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
	Сообщение от Андрей (??) on 13-Янв-17, 08:07
	Вот и Eric Raymond уже обнаружил, что даже для простой конкатенации строк в Rust нужен целый ритуал, да и вообще Rust не подходит: Rust is presently unusable https://gitlab.com/NTPsec/blog/commit/46d9882054e0d0cb698ad9... "... Then I found out that a feature absolutely critical for writing network servers is plain missing from Rust. Contemplate this bug report: https://github.com/rust-lang/rust/issues/14961[Is there some API like "select/poll/epoll_wait"?] and get a load of this answer: "We do not currently have an epoll/select abstraction. The current answer is "spawn a task per socket". Upon https://github.com/rust-lang/rust/issues/27800[further investigation] I found that there are no proposals to actually fix this problem in the core language. The comments acknowledge that there are a welter of half-solutions in third-party crates but describe no consensus about which to adopt. ..."
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	146. "+>> Eric Raymond 'Rust severely disappoints me'"	+/–
	Сообщение от Andrey Mitrofanov on 13-Янв-17, 09:14
	> Вот и Eric Raymond уже обнаружил, что даже для простой конкатенации строк > в Rust нужен целый ритуал, да и вообще Rust не подходит: + 12 Jan 2017 21:19  Eric Raymond "Rust severely disappoints me" http://esr.ibiblio.org/?p=7294 С другой стороны... может, он ещё не принюхамши к прогрессу? Молодёжнее надо, Реймонд!
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

97. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–2 +/–
Сообщение от Аноним (??) on 10-Янв-17, 22:38
забавно но на swift даже не смотрят
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

98. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
Сообщение от Аноним (??) on 10-Янв-17, 23:20
Почему rust'аманы и go'пники стали такими активными?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	99. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Comdiv (ok) on 10-Янв-17, 23:48
	Эрик Рэймонд к кому из них относится? Также было бы неплохо представить ваши достижения, просто чтобы понять, чей опыт весомей - Эрика или Анонима.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	147. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Andrey Mitrofanov on 13-Янв-17, 09:18
	> Эрик Рэймонд к кому из них относится? К "таким активным", элементарно же. Ж))) +++см.также https://www.opennet.ru/openforum/vsluhforumID3/110122.html#138 выше
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

109. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
Сообщение от Аноним (??) on 11-Янв-17, 07:03
Гугел решил потихоньку все ПО под себя переписать, контролировать удобней :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

110. "Рассматривается возможность перевода NTPsec на язык Rust или..."	–1 +/–
Сообщение от Игорь (??) on 11-Янв-17, 07:53
Ну сейчас блин все на Rust начнут переписывать, а я так люблю C :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	118. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+3 +/–
	Сообщение от Аноним (??) on 11-Янв-17, 14:34
	> Ну сейчас блин все на Rust начнут переписывать, а я так люблю > C :( Останетесь ценным маргиналом, будете поддерживать сверхважное legacy за огромные деньги, в чём проблема?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	137. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 04:15
	Не начнут, Эрик уже попробовал rust и он ему не понравился: http://esr.ibiblio.org/?p=7294
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	149. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Andrey Mitrofanov on 13-Янв-17, 15:48
	> Не начнут, Эрик уже попробовал rust и он ему не понравился: http://esr.ibiblio.org/?p=7294 [Без обид :) , не хотел скрасть у коллеги линк-голду своим #146 -- тупо не дочитал досюда.] Сейчас дочитал (я небыстр+) самого ESR-а до конца. С запросами в последних двух абзацах (хинт), не видать ему нового ЯП. И старые-то уже жмут... Хотя, мож, MLи какие, хаскелы или эрланги бы и подошли. Но мы(примазаться к Классику хочется, да) с Эриком найдём к чему и в них прикопаться -- и Анонимы опенетов не дадут пропасть. Вывод: Програм[б]ление надо бросать -- всё пустое.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

132. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
Сообщение от Аноним (??) on 12-Янв-17, 14:20
> за огромные деньги, Или сверхмалые, в каком-нибудь задрипаном ЦНИИ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

150. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+1 +/–
Сообщение от Аноним (??) on 14-Янв-17, 07:33
Гы. Две статьи от того же реймонда, но от 12-13го января 17го: http://esr.ibiblio.org/?p=7294 -- Rust severely disappoints me http://esr.ibiblio.org/?p=7303 -- Rust and the limits of swarm design Чувак потыкал раст два дня и всё понял про его перспективы. :-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	151. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от Аноним (??) on 14-Янв-17, 07:35
	Для затравки: > I wanted to like Rust. I really did. I’ve been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec. > I finally cleared my queue enough that I could spend a week learning Rust. I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back. > In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	152. "Рассматривается возможность перевода NTPsec на язык Rust или..."	+/–
	Сообщение от J.L. on 17-Янв-17, 11:48
	наверно тут оффтоп, но не знаете ли перспектив D в аналогичных проектах ?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема