Эрик Рэймонд (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.dev/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
Новость: http://www.opennet.dev/opennews/art.shtml?num=45832
Пробуйте, посмотрим что выйдет...
сборка мусора останавлиапет выполнение программы?
да
> даНет. 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 в критических участках это логичная идея.
>Впрочем, запрещать GC в критических участках это логичная идея.Программа коррекции датчика времени является таковой чуть более чем полностью.
А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно.Правда тут в соседней новости собираются написать транслятор из C в Раст, чтоб PostgreSQL потянул. Как осилят - можно будет и NTP налету конвертить. :)
Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.
> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.На хаскеле?
> Уже! https://github.com/jameysharp/corrode. Мозилла кажись даже грант проекту дала.Учитывая что у мозиллы браузер превращается в тыкву и гуглхорм его обижает - скоро они кажется утратят способность раздавать гранты на разную концептуальную хну. А откуда они на это деньги будут брать? :)
> А выбирать язык, основным достоинством которого является хрень, которую надо отключить - это достойно.Ну, блин, это ESR. Известный своими логичными и результативными достижениями. Правда наибольшую известность он почему-то снискал как холуй проприетарщиков.
Любой сборщик мусора периодически останавливает потоки выполнения, просто потому, что нет другого способа пересчитать объекты, ссылки на которые лежат в регистрах и на стеке. Другое дело, что некоторые алгоритмы, на самом деле даже большинство алгоритмов, стремятся свести такие остановки к минимуму. Например, выполнить максимум работы в бекграунде, из параллельного потока. Помечать области памяти, с которыми идёт работа, флагом ro, с тем чтобы проводить все манипуляции несмотря на то, что программа продолжает работать с объектами -- и это проходит гладко, если программа ничего не меняет, но в случае, если она вносит изменения, процессор выкидывает исключение, выполнение задачи прерывается, сборщик мусора обрабатывает исключение и позволяет программе продолжать выполнение. Там есть разные техники преодоления этих проблем, между прочим очень любопытные -- я читал книжку об этом запоем, кстати очень рекомендую в качестве увлекательного чтения какое-нибудь систематическое описание этих алгоритмов. Но финально всё сводится к тому, что останавливаются _все_ потоки, сборщик мусора из каждого потока выковыривает содержимое регистров и стековых фреймов, быстренько составляет список объектов достижимых при помощи регистров и стека, после чего позволяет программе продолжать работу, а сам заканчивает итерацию сборки мусора. В самых продвинутых алгоритмах, этот этап остановки очень короткий и неплохо масштабируется, потому что остановив все потоки на всех процессах, сборщик мусора сам начинает работать многопоточно, задействуя все процессоры, для того чтобы быстро-быстро всё сделать.Но как бы там ни было, остановки, пускай и короткие, происходят, причём чем круче алгоритм, тем менее предсказуемо когда произойдёт остановка. Любая запись в память может привести к прерыванию и переключениям между ring3 и ring0. Периодически же будут возникать остановки типа stop-the-world. Это может быть неважно для десктопного приложения, но для синхронизации времени, где речь идёт о микросекундах -- это не вариант. Точнее не так: это может быть допустимо, и Раймонд говорит о том, что может быть "и так проканает", если паузы действительно будут измерятся небольшим числом микросекунд, как обещают go-фаги. Но может быть и не проканает.
Ох уж эти эксперты по сборке мусора опеннета 8))))) можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов.А послушаешь местных аналитиков, так получается что программы на GO полчаса работают, потом час висят, мусор разгребают.
> можно начать (и закончить) с того, что сборщик обычно включается раз в несколько часов и при активном удалении объектов.Об этом тебе лучше молчать. Если ты несколько часов активно удаляешь объекты (ну и создаёшь соответственно активно, чтобы было что удалять активно), а сборщик мусора при этом бездействует, то твоей программе место в каком-нибудь специальном загончике для прочих жаба программ, жрущих оперативную память гигабайтами.
> закончить) с того, что сборщик обычно включается раз в несколько часов
> и при активном удалении объектов.По закону подлости он решит отпедалить все это именно тогда когда интересовало точное время. Которое после такой диверсии перестанет быть точным, очевидно. Ведь если мусор несколько часов не собирали - вклин будет надолго.
Есть реализации GC без Stop The World. Такая, например, используется в Erlang. Достигается это тем, что у каждого микропроцесса в Erlang'е своя куча.
STW-то официально может и нет, но потоки останавливаются точно так же. Другое дело что паузы очень короткие и эрланг сам по себе просто тормоз для конкретно этой задачи.
>STW-то официально может и нет, но потоки останавливаются точно так же.Нет, не точно так же. Во-первых, не нужно синхронизировать остановку всех потоков, т.е. сами потоки не бывают остановлены на дольшее время чем нужно для сборки мусора в их конкретной куче. Во-вторых, остановка никогда не происходит в произвольном месте, обычно сборка мусора происходит при вызовах, выделяющих память, либо на блокирующих функциях типа ввода-вывода или, в случае erlang, отсылки-приёма сообщений. На том же хацкелле можно легко написать код, работающий в константной памяти и не дёргающий GC в принципе.
Erlang, кстати, не такой тормоз. Но других косяков у него до жопы :(
В любом случае производительность рандомно проседает. Для реалтайма под нагрузкой GC наверно самое худшее решение.
В той статье где разработчики Go хвалятся их будущим супер-сборщиком мусора на самом деле на рассмотрено ни одно негативное последствие их решения. Они преподносят свою идею как нечто революционно новое, хотя на самом деле всё что они делают уже давно известно 10+ лет. Они просто выбирают все возможные компромиссы ради укорочения паузы сборки мусора (но, например, частота таких пауз у них возрастает). Вот более подробный анализ недостатков их hype-collector:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8eИ таки да, любой сборщик мусора требует STW, даже теоретически невозможно сделать по-другому. Другое дело, что если этот STW -- считанные микросекунды, то всем пофиг. Хотя проектам типа NTP может быть и не пофиг.
> даВытесняющая многозадачность, даже если в системе несколько ядер или процессоров, тоже прерывает выполнение программы. Выполняется ваша программа без сборщика мусора, а тут прерывание прилетает - диск сообщил, что прочитал заказанные секторы. Выполняется дальше - а тут сетевая карта сообщает, что она буфер пакетами наполнила. Особенно много подобных эффектов будет в нагруженных системах, где работает больше одной программы. Там сборка мусора может быть просто незаметной на общем фоне торможения.
> сборка мусора останавлиапет выполнение программы?"Да, но." Там наверху по ссылке 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... б--нть.
и отупляет мозг программиста
"пропала планета..." (c) космоболы
учитывая что это всего лишь спутник NTP Classic, а не планета, то такие эксперименты на пользу - если что можно вернуться или форкнуть
голосую за раст
сборку мусора мы уже проходили, любопытнее глянуть, что покажет альтернативный подход
> голосую за раст
> сборку мусора мы уже проходили, любопытнее глянуть, что покажет альтернативный подходНу, и будут они его переписывать при каждом выходе нового релиза Раста.
Ах, да, а Раст уже научился компилироваться на чём-то, отличном от i686 и amd64?
да хоть в джаваскрипт умеет.
https://forge.rust-lang.org/platform-support.html
Уже умеет компилировать на и для mips, mipsel, mips64, mips64le, ppc, ppc64, ppc64le, s390x.
Так он же просто поддерживает всё что умеет LLVM, разве не так?p.s. Если так то там только вопрос насколько корректна и качественна поддержка той или иной архитектуры в LLVM
Ты не голосуй, а пойди и поучаствуй, если такой умный.
Я тоже голосую за Rust
1. что там такого надо переводить, все должно быть уже вылизано до блеска.
2. в чем новость? вот когда решат, тогда и будет новость. а сейчас пустая информация.
Началось!
Что? Сингулярность?
Ну да, на ноль поделили
На язык Rust или Go. Совсем никакой разницы, ага.
Ну так потому и 6-9 месяцев на решение.
По-моему, за это время можно накатать два прототипа на обеих языках. Особенно, с учётом того, что код уже есть - его надо просто "перевести"
>По-моему, за это время можно накатать два прототипа на обеих языках.Накатайте. Как люблю теоретиков.
> По-моему, за это время можно накатать два прототипа на обеих языках.И этот код чувствителен к времени выполнения и прочим мелочам. Там вон народ с PTP за наносекунды давится и timestamp пакетов аж с сетевухи снимает, а этим GC видите ли не мешает.
> Особенно, с учётом того, что код уже есть - его надо просто "перевести"
А если так подумать - круто получается: софтина не выполняет свою прямую задачу (синхронизация точного времени). Зато, блин, на go.
>софтина не выполняет свою прямую задачу (синхронизация точного времени). Зато, блин, на go.Или на ржавчине.
У ржавчины нет сборщика мусора, там всё четко.
>> По-моему, за это время можно накатать два прототипа на обеих языках.
> И этот код чувствителен к времени выполнения и прочим мелочам. Там вон
> народ с PTP за наносекунды давится и timestamp пакетов аж с
> сетевухи снимает, а этим GC видите ли не мешает.В новости - использование "безопасных строк" так-что какая-то часть rust-а ( или go или вплоть до php ) уже привнесена в проект.
> В новости - использование "безопасных строк" так-что какая-то часть rust-а ( или
> go или вплоть до php ) уже привнесена в проект.Это с чего бы? Безопасные строки сами по себе к горастам никак не относятся. Впрочем, ESR известен своей могучей тягой к хайпу и прочему корпоративно-маркетинговому булшиту.
язык - он
>>> несмотря на всё то время, которое он с 1983 года и по сей день вложил в изучение C со всеми его нюансамив оригинале он ничего "не вкладывал", а просто на нем разрабатывал:
>>> I’ve been writing steadily in C since 1983, and am correspondingly deeply aware of its quirks and flaws
"Вложил свои силы и энергию в разработку программ и изучение C" --- вполне правильный перевод.
Да, всё дело в формулировке. Неуместным казалось "вложил в изучение". Вообще тут очень скользкая тема, потому спецификация довольно тривиальна и логична, а вот компиляторы... А они имеют свои особенности и именно на их изучение тратится много время, а не на C.
Ладно, ждем NTPsec на GO.
два словаря Мюллера этому господину.
Как-то ловко Вы пропустили следующее предложение - "Despite my huge investment of time in the language, I’m ready."
Инвестиции !== вложения.
Ладно, проехали, пошёл искать Мюллера...
investment (ɪnˊvestmənt) n1) инвести́ция; вклад
2) (капитало)вложе́ние, помеще́ние де́нег, инвести́рование
3) предприя́тие или бума́ги, в кото́рые вло́жены де́ньги
4) оде́жда, облаче́ние
5) облече́ние полномо́чиями, вла́стью и т.п.
6) воен. оса́да, блока́да
7) attr.:
investment bank амер. инвестицио́нный банк;
investment goods това́ры произво́дственного назначе́ния;
investment outlet сфе́ра примене́ния капита́лаОчевидно, в оригинале имелась в виду "одежда" или "осада", да.
пацаны из openntpd и не знают
пацаны из openntpd написали бы сначала ntp, а не sntp
> пацаны из openntpd написали бы сначала ntp, а не sntpИзвини, если в софтину втулить все эти керберосы, лдапы и TLS - она перестанет быть секурной на любом ЯП. Просто потому что адские сотни кода. Поэтому пусть лучше остается как есть. Так он будет безопасным даже на сишечке, а хомяки с го и прочие раст-о-маны будут CVE пачками чинить. DJB про надежность софта все очень правильно ведь сказал. И без привязки к ЯП вообше.
Наконец даже до старпёров начало доходить что C пользоваться нельзя ни под какими предлогами.
Нет, пока не начало.
судя по его комменту он давно был готов соскочить с С, но до недавнего времени не было даже кандидата куда>> 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.
> судя по его комменту он давно был готов соскочить с С, но
> до недавнего времени не было даже кандидата куда
>>> 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.Не готов, а просто радуется, что появились альтернативы.
В чем-то его можно понять, монополия никому не шла на пользу.
В том числе, монополия на звание "единственного языка системного уровня".
А чем можно?
> Наконец даже до старпёров начало доходитьА то много с ними общался, что бы такие заявления делать?
> Наконец даже до старпёров начало доходить что C пользоваться нельзя ни под
> какими предлогами.Ух, ты уже перешел на ту чудо-систему на Rust? Где один кернел для запуска гиг требует? И файлуху еще возьми, нуб.
Вы хотели сказать нежелательно? Я думаю у старперов..., да и не только, этот вопрос как минимум пока открыт
Просто за C11, видимо, дело идет к новому стандарту Си.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...Такие откровения от разработчиков современных компиляторов, наводят на мысли, что C имеет фатальные недостатки, которые невозможно устранить, не ломая конкретно совместимость с существующей базой кода на C.
И именно такие мысли, я подозреваю, сделали неотвратимым появление всяких там rust и Go.
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
> Такие откровения от разработчиков современных компиляторов, наводят на мысли, что C имеет
> фатальные недостатки, которые невозможно устранить, не ломая конкретно совместимость
> с существующей базой кода на C.
> И именно такие мысли, я подозреваю, сделали неотвратимым появление всяких там rust
> и Go.Разработчики современных компиляторов сами себя в эту ситуацию загнали, некоторые оптимизации которые они используют и их реализация вообще спорны. И к языку как таковому это по моему не совсем относится, C всегда был "ассемблером с человеческим лицом".
клоун: описанные оптимизации невозможны без ОЧЕНЬ несбалансированных настроек компилятора.Взять первую описанную проблему - удаление строки dead = *p. Даже если переменная dead не используется, разыменование является значащей операцией и компилятор до проверки на NULL эту строчку никогда не удалит.
Однажды автора подобных статей поймали на прямой лжи и он заявил что просто выдумал свои примеры.
> разыменование является значащей операциейВ 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
клоун: именно потому, что она может повлиять на логику выполнения программы, эта операция является значащей.То, компилятор не учитывает это простое правило, многое говорит о его качестве.
> клоун: именно потому, что она может повлиять на логику выполнения программы, эта
> операция является значащей.
> То, компилятор не учитывает это простое правило, многое говорит о его качестве.Оно?
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), но доставать хард с образом виртуалки, честно говоря, влом.
Напишите, пожалуйста, название книги (если она вообще есть в электронном варианте)
А потом ставим этот самый Автокад на нормальный компьютер, на котором громадные карты МапИнфо и ИнГео летают - и, вуаля! Шевелится еле-еле, тормоза во всем страшные. Алгоритмы, может, и оптимизированы, а вот память жрет как не в себя. Результат - что оптимизируй, что не оптимизируй, а микрософтовские индусы только одну субстанцию и производить умеют.
>Они написали 90 алгоритмов для каждого из углов и оптимизировали их всеТо, что углов больше 90, почему-то не рассматривается. Может это просто гонево?
> Может это просто гонево?Его фраза "для компании AutoCAD" прекрасно демонстрирует, что он даже название программы от названия компании-разработчика отличить не может. В сочетании с остальным текстом комментария получается, что с вероятностью, стремящейся к 100%, это была всего-лишь попытка потешить своё клоунское ЧСВ.
клоун: Эта история мне нравится по двум причинам. Во-первых, она мотивирует. А во-вторых она написана в одной из таких книг, про которую все знают и говорят, но которую никто никогда не читал. Как библия у христиан. А для программистов это...Что-то уже многовато спойлеров :).
> Что-то уже многовато спойлеров :).Ты красиво обошёл замечание, что углы не ограничиваются градусами. Видать эта информация оказалась тебе не по зубам.
Он клован, а не математик (\программист\ботаник\Ынженер) ...
Зачем кловану радианы? Оне не смешные :)
Да. При том недоработки, которые делают невозможными некоторые оптимизации, многочисленны. Есть еще вариант ввести альтернативный синтаксис, но за это их возненавидят. У Rust'а же безопасность дает побочный эффект в виде улучшеного статического анализа и оптимизации компилятором. Например при копировании областей памяти заранее известно, пересекаются они, или нет. У С/С++ всё на указателях, включая весь stl, там нужны проверки в рантайме.
http://geekz.co.uk/lovesraymond/wp-content/images/ep013.jpg
По-момему с C было бы логичнее перейти на D. И сборка мусора там есть.
В тексте проскальзывает желание изменить практики программирования, а как средство достижения этой цели рассматриваестся варианты переходов на другой язык программирования.
Как бы логично, но не совсем. Мне кажется, что сегодня все немножко помешались на новых языках программирования и пробуют занести их в самые разные области применения программного обеспечения. А надо ли? Почему бы не оставить этот С, только не писать его руками, в подготовить инструменты, которые будут эксплуатировать правильные практики и генерировать С-код, который будет компилироваться и обеспечивать компактность, производительность и не терять при этом надежность?
И примеры такого подхода были и есть. Например "Р" - https://github.com/p-org/P.
Можно было бы адаптировать/доработать Р или например SPIN и собственно решать основную задачу, привнесение правильных практик в этот мир (в случае с Р это автоматное программирование ((с) А. Шалыто) ), а не переписывать на другой язык программирования.Говоря аллегориями, читать Достоевского или О'Генри удовольствие и на русском и на английском (при хорошем переводе, конечно), а какую-нибудь Дарью Устинову и на русском-то тяжело (imho :) ).
Прошу прощения, Татьяну Устинову. Я - знаток :)
клоун: по сути ты тоже предлагаешь новый ЯП, только компилировать предлагаешь не в бинарный код/псевдокод, а в код на языке Си, который потом будет скомпилирован в бинарный код/псевдокод. Зачем нужна прослойка в виде Си? И если нужна, то почему именно Си?Другой момент: производительность ПК достигла уровня, когда можно больше не экономить память (кто не помнит, в MS DOS использовали три глупых команды вместо двух умных чтобы сэкономить 1 байт). И сейчас производительность подходит к уровню, когда можно больше не беспокоиться об освобождении памяти: программист её только выделяет, сборщик мусора автоочищает. Новые техники программирования требуют новых языков, их использующих.
Эмбендовка смотрит на тебя, как на PHPера и Goпника.
клоун: если ты про "умные" вещи, то там стоит уже весьма производительное оборудование. Вот на последней выставке "умное мусорное ведро" представили с распознаванием выкидываемого мусора. Что-то я очень сомневаюсь, что у них ПО на асме или на Си.
Производительность очень уж клещится с энергопотреблением. Маленькая система много лопать не может потому что перегреется. А многие эмбедовочные системы нуждаются еще и в автономном питании или им вообще технически невозможно mains протянуть. Я что, буду тянуть 220 вольт к каждому датчику протечки? Чтобы как раз растекающиеся по воде 220 вольт всех положили, мде?
клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов.Как там было в "Назад в будущее":
- когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление.
- Аааа! Ну да... У меня с этим туго...
> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов.220 (да и поболее) без проводов уже давно есть в некоторых местах практически в любой хате.
В твоей, точно есть такие места.Вот только находится в этих местах чревато необратимыми повреждениями не только для живых организмов.
Так что не будет _никогда_ сколько-нибудь значимая величина электромагнитной энергии "по всей хате без проводов".
Ещё неизвестно чем вайфаи, мобильные телефоны, беспроводные камеры, блютусы аукнутся через пару поколений.Либо приборы будут потреблять ничтожно мало (а никак не 220 В).
Либо передача без проводов будет из конкретной точки, по конкретному пути, в конкретную точку(и все эти точки, пути защищены от тыканья пальцем).
Либо откроют что-нибудь новое - поле, не взаимодействующее с окружающей материей, путь через измерения в которых наша материя не существует (может квантовая спутанность и объясняется тем что в каком-то измерении частицы находятся рядом).
> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В
> будет по всей хате без проводов.Да оно и прям ща можно. Открыл микроволновку и врубил. Энергии наружу вылезет немеряно, только собирай. А если вон те киловатты для плиты таки вкачать и таки по воздуху - ты себя не ощутишь куском мяса в микроволновке? Уверен? А то что-то для чуваков работающих с мощными передатчиками нормативы какие-то есть, при том не ГТО :)
> Как там было в "Назад в будущее":
> - когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление.
> - Аааа! Ну да... У меня с этим туго...Да вот блин хотя-бы революцию в хотя-бы аккумуляторах обещают уже лет как хренадцать. Ежегодно не менее дюжины новостей. Г-Д-Е?!
И если у тебя с чем-то туго, то я вот физику не прогуливал. И поэтому догадываюсь об проблемах и ограничениях. Пока-что переают на сантиметры и спасибо если 80% от того что было. В принципе и на метр-два можно, но уже 40%. Что как-то не прикольно уже. А так ты извини но электричество без проводов еще Тесла гонял. Так что баянище! Выглядело круто, но вот КПД...
Язык 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 существуют (многопоточность и гонки никуда не денутся (как в приложении так и в рантайме языка) и хочется их поймать до этапа эксплуатации)
клоун: трансляцию в другой ЯП используют только если не смогли написать компилятор.> пошли по пути разработки собственных инструментов по генерации и верификации С-кода
Зачем? В новых ЯП или сама проблема больше не возникает, или есть более простое её решение. Пробовал когда-нибудь отлаживать ассемблер? Каким бы удобным не был отладчик для асма, отлаживать Си на порядок быстрее, удобнее и проще. А работать с новыми ЯП ещё быстрее и проще, чем с Си.
> Другой момент: производительность ПК достигла уровня, когда можно больше не экономить памятьМикроконтроллерам все это расскажешь. Как захочется поработать 5 лет от пары пальчиковых батареек - так народ творит просто чудеса оптимизации. Зато и результат того стоит.
И вот что-что а маложручие дешевые датчики - это основа основ IOT. Без них далеко не уедешь. В смысле, если ты свой х86 гроб прицепил к интернету и мусорке это еще не IoT и даже не эмбедовка как таковая. А как все это потом работает популярно разъяснил гражданин Зенков. У которого однажды не включился насос в его системе. Мало кому такие плюхи в управляющих системах захочется.
С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти везде", хотя она экономичней чем микроядро с 4кб. кода, т.е. всегда есть несколько параметров, иногда "выгодней" заряжать раз в день (смартфоны) иногда мелкосерийные сбис и аналоговые вычислители.
> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти
> везде", хотя она экономичней чем микроядро с 4кб. кода, т.е. всегда
> есть несколько параметров, иногда "выгодней" заряжать раз в день (смартфоны) иногда
> мелкосерийные сбис и аналоговые вычислители.P.s. Есть ещё такие вещи как влияния "массовости" на потребление ресурсов, современный процессор на 60нм. может жрать меньше чем заказные "схемы на толстых кристаллах"
> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти везде",Так МК как раз и делает все в софте. Железом какие-то тяжелые операции подперты, но рулит всем софт. Просто они предсказуемые, маложручие, на жесткий реалтайм заточены. Можно обмотки мотора вместо механического коллектора софтом переключать. Variable-freqency drive называется. А как ты думал напругу с разной частотой синтезируют? Ну не жесткой же логикой, на ней делать анализ состояний, защиты от перегруза и проч - замахашься.
> мелкосерийные сбис и аналоговые вычислители.
Нц вот это редко: затраты на пуск в производство чипа - довольно высокие.
А клоуну удачи с его маздаем и писюком в мусорке. Нуачо, поконкурируем. Надо же показать ушлепанам пихающим глючный писюк что можно сделать в разы дешевле, надежнее, экономичнее, и вообще? :)
Вот так, сначала учат юных падованов на "удобных" языках, а потом, обнаружив, что те не умеют писать продуманный код, ищут, какой бы такой "безопасный" язык подобрать для своих криворуких выкормышей.
клоун: ИТ перегрет. Дорогостоящие специалисты с "системным мышлением лямбда-паттернами" уступают своё место гораздо более дешёвым.Ты знаешь 10 алгоритмов сортировки и 4 алгоритма транспонирования матриц? Это давно никому не нужно.
Ной, не ной, но за этим будущее. И в нём ИТ-шник зарабатывает не больше, чем водитель троллейбуса.
Не так. ИТ-шники со знанием 10 алгоритмов сортировки и 4 алгоритмов транспонирования матриц пишут автопилот для автобусов, а осовободившиеся водители троллейбусов переквалифицируются в программи^Wб*длокодеры и продолжают получать те же деньги, но теперь уже не за вождение троллейбусов, а за каловые массы кода.
клоун: те же деньги? Держи карман шире... Онлайн-биржи чётко показывают тренды: ИТ - это индусы по 5 копеек.Если смотреть шире, то это та самая уберизация, о которой столько говорят в других сферах. Вместо дорогостоящего профессионального такси с профессиональным таксистом, тебе готовы за копейки подогнать машину, которая едет в ту же сторону.
> - это индусы по 5 копеек.Правильно. Потому что основам программизма нынче учат в любом вузе и даже школе. И индусов тоже! Поэтому если ты умеешь писать какую-нибудь вебню как еще милиард индусов - получается что ты в общем то ничего такого уникального и не умеешь. Сюрприз.
И работать за зарплату водителя троллейбуса - удел вот таких специалистов. Которые специалисты ни в чем. Ну как, писать glue code склеивающий функции фреймворка может даже индус. Значит это стоит вот столько. А водителей троллейбусов вообще зохвает автопилот в самом обозримом будущем. Компьютеры лучше в рутинных работах.
клоун: Именно. Только не "таких вот", а всех. Стремясь зарабатывать больше, они захавают соседние области, в результате доходы отрасли в целом скатятся под плинтус.Сроки тоже примерно понятны. Пока ИТ растёт на 10-15% в год этого не случится, но замедлись рост до 1-5%, как в других отраслях - и вот тебе берег, приплыли!
> в результате доходы отрасли в целом скатятся под плинтус.Не вижу предпосылок. Обычное разделение на чернорабочих и квалифицировнные кадры, придумано задолго до айти. Мало стоят работы на которые нет спроса или слишком много предложения. Обычный рынок.
> - и вот тебе берег, приплыли!
Вот лично мне чего-то IoT-образного в ближайшее время явно хватит. Я не говорил что довольно смешно перехватывать заказы подобным тебе элементам интерьера? :) Пока такие чудаки рассказывают про писюки, я высовываюсь с решением которое делает то же самое, только в разы лучше по всем параметрам, заказчики фигеют от такой разницы. Как вы там говорили? Ничего личного, это бизнес? Пора научить бракоделов с писюками в эмбедовке основам ведения бизнеса. Ага, у меня скринсэйверы экспы не висят. И регистрация не слетает. И бсодов нет. И press F1/any key/... не бывает. И лицензионно все чисто. И можно кастомизнуть под окружение. А попробуй так с своим маздаем и х86, ога. Если ты думаешь что сможешь взять эту высоту - фигня вопрос, попробуй :)
Выглядит как, мы сделали все хорошо, теперь нам скучно. Думаем, а не поломатьли и начать заново.
А смысл переходить? Расскажите мне, необразованному, с чем там С не справился.
Программисты уже не те. Хакеры не те. Это как гвозди без перчаток забивать - удобно, но после десятого удара по пальцам внезапно задумался.
в первом же абзаце сказано
>> 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-...
C в состоянии справиться с чем угодно -- он тьюринг-полный язык программирования. А причины переходить, примерно те же, что и причины, которые толкнули Томпсона с Керниганом писать unix на C, а не ассемблере.Разработка программ не стоит на месте. Она развивается. Требования меняются, меняется окружение, в котором работают программы. Меняется, наконец, типичный размер программы, причём в сторону увеличения. Это тренды, которые сопровождают разработку программ с самого начала, они подтолкнули когда-то системное программирование к переходу на C с ассемблера. Они же сейчас толкают в сторону ухода от C.
Сегодня C подпирают костылями, типа статических анализаторов кода, его подпирают и динамическими анализаторами, типа valgrind. Но тренды никуда не деваются, и подпирать до бесконечности не удастся.
И если Эрик Раймонд таки решится перевести системную программу на rust или go, то это будет очень полезным опытом. Причём полезным в любом случае -- как в случае успеха, так и в случае неудачи. Это даст возможность посмотреть на то, что из себя представляют rust с go в системном программировании. Пока, по большей части, вместо эмпирических данных мы имеем мнения экспертов, разной степени анонимности. Но как показывают исследования, мнения экспертов хороши тогда, когда не происходит радикальных изменений -- это очень хорошо видно по экономическим предсказаниям: эксперты хорошо предсказывают нормальное поведение рынка, но точность предсказаний падает до точности гадания на кофейной гуще, в случае сильно и резко влияющие на рынок событий.
Я не знаю, насколько для Раймонда является движущим мотивом возможность поставить такого рода эксперимент, но для нас, как для сторонних наблюдателей, запасшихся попкорном, это несомненно отличный мотив.
А, и кстати, если отвлечься от мнения анонимов о том, в чём плюсы, а в чём минусы, есть сукцесс стори о расте: https://onesignal.com/blog/rust-at-onesignal/
Основные бонусы раста проявляют себя, в принципе, как и ожидалось. А минусы, по большей части, связаны с молодостью и неразвитостью инфраструктуры -- breaking changes в библиотеках, нехватка инструментария и прочие.
Спасибо большое! Я примерно так и думал!
Мне кажеться, подобный сверхважный софт надо писать на Forth и математически подтвердить надежность. А писать на всяких rust, переписывать из-за новых хипстерских идей в компиляторе это не для такого софта.
И платить за ntp-сервер по $500 в месяц?Часть 1: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year
Часть 2: https://blog.pivotal.io/labs/labs/ntp-server-costing-500year...Ну, то есть, там проблема была не в том, что код сервака был особо тормозным, но если бы он был ещё и тормозным...
> И платить за 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, только хардкор. кушайте не обляпайтесь.
Rust — это системный язык программирования, внимание которого сосредоточено на трёх задачах: безопасность, скорость и параллелизм.
Согласно дизайну языка Си, такие задачи ему не ставились(ситуация была другой).
Его конструкции близко сопоставляются типичным машинным инструкциям, а всё остальное проблемы программистов.
С учётом развития и распространением "железяк" эти самые проблемы стали более актуальными. К тому же свои требования предъявляет бизнес(кто первым: займёт нишу и будет предоставлять лучшие услуги).
Безопасность, скорость и параллелизм должны быть частью языка, а оптимизация производительности под конкретную платформу - проблема соответствующего инструмента.БОльшую часть программных продуктов, так или иначе, создают для зарабатывания денег.
Выживает(остаётся востребованным) тот кто своевременно адаптируется.
Будто прочитал рекламную листовку.
> Его конструкции близко сопоставляются типичным машинным инструкциямНе поэтому ли чуть менее, чем во всех бенчмарках компилируемых языков именно Си выступает в качестве эталона? Не близость ли к железу позволяет программисту (при достаточной квалификации, разумеется) лучше понимать, как именно будет работать скомпилированный код и как его можно {на|пере}писать, чтобы выжать из железа максимум?
> Не близость ли к железу позволяет программисту (при достаточной квалификации, разумеется) лучше понимать, как именно будет работать скомпилированный кодТолько действительно понимает, хорошо, если один из десяти.
Остальные или считают, что они понимают или вообще из категории "напишу-ка на асме^W cи, ведь это круто! А еще там пони магией починят мои х*еновые структуры данных с алгоритмами. Какие кэшмиссы, бранчпредикшн и выравнивания с симдами? Там же МАГИЯ!"
С магией лучше к поклонникам того же Rust-а, например, то и дело лезущим со своей верой в способность компилятора если и не превратить кривой код к конфетку, то, как минимум, невозможность компиляции этой кривоты (типа статический анализ, обещания безопасности и всё такое). *По моим личным наблюдениям*, сишники/плюсовики куда более склонны более-менее адекватно оценивать сложность написания качественного кода на этих языках и признавать огромное количество грабель, по которым можно при этом пройтись.
> С магией лучше к поклонникам того же Rust-а, например, то и дело
> лезущим со своей верой в способность компилятора если и не превратить
> кривой код к конфетку, то, как минимум, невозможность компиляции этой кривоты
> (типа статический анализ, обещания безопасности и всё такое).Как будто неолуддиты, отвергающие технический прогресс, чем-то лучше.
По их логике правда и беспилотные автомобили всегда будут только игрушкой для неосиляторов вождения, потому как, пока что, даже весьма посредственный водитель уделывает таких автопилотов на раз!
Да и тест Тюринга эти автопилоты тоже не проходят! )
> Rust — это системный язык программирования,И как, много на нем систем то уже напрограммировали? Бутлоадер на этой системщине напсать? Или под микроконтроллеры попрограммить? А то понимаешь совсем не круто знать пять разных языков для разных задач, каждый понемногу и хреновенько. Получится один сплошной джамшутинг. Ну вон там в соседней новости питонобезопасность, понимаешь.
Я понимаю ещё Rust, но на Go переходить? Жесть.
> Я понимаю ещё Rust, но на Go переходить? Жесть.аргументируйте
В комментариях к оригиналу даже NodeJS предложили. Стильно-модно-молодёжно, ага.
Если изначальное заявление не содержит даже намёков на аргументацию, то, скорее всего, её и потом не будет.
Если уже совсем нет возможности оставаться на Си, то тогда хотя бы Go, но никак ни Rust.
> Если уже совсем нет возможности оставаться на Си, то тогда хотя бы
> Go, но никак ни Rust.аргументируйте
наверное по той же причине почему не C++
Тогда должен быть Rust, а не Go
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.
Наверняка, ещё что-то забыл.
> 1. Go был предложен в 2009 как альтернатива Си.Было дело. Если поискать, то пиарили в самом начале как "системный" язык.
Только на деле он такая же альтернатива Си, как опеннетчики балеринам.
>> 1. Go был предложен в 2009 как альтернатива Си.
> Было дело. Если поискать, то пиарили в самом начале как "системный" язык.
> Только на деле он такая же альтернатива Си, как опеннетчики балеринам.Все на Lisp ! Ура.
https://www.gnu.org/software/guix/
https://www.gnu.org/software/shepherd///Поясняю: scheme - это lisp, в хоро ^W широком смысле. См.историю лиспов, lisp-1--vs--lisp-2 и пр. ==Для контекста [опенета] разницы нет.
+++"Это я вам, как троль-балерина в первом поколении говорю."ТМ
6. ..., race detector,..
Вот и 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.
..."
> Вот и Eric Raymond уже обнаружил, что даже для простой конкатенации строк
> в Rust нужен целый ритуал, да и вообще Rust не подходит:+
12 Jan 2017 21:19 Eric Raymond "Rust severely disappoints me" http://esr.ibiblio.org/?p=7294С другой стороны... может, он ещё не принюхамши к прогрессу? Молодёжнее надо, Реймонд!
забавно но на swift даже не смотрят
Почему rust'аманы и go'пники стали такими активными?
Эрик Рэймонд к кому из них относится? Также было бы неплохо представить ваши достижения, просто чтобы понять, чей опыт весомей - Эрика или Анонима.
> Эрик Рэймонд к кому из них относится?К "таким активным", элементарно же. Ж)))
+++см.также http://www.opennet.dev/openforum/vsluhforumID3/110122.html#138 выше
Гугел решил потихоньку все ПО под себя переписать, контролировать удобней :)
Ну сейчас блин все на Rust начнут переписывать, а я так люблю C :(
> Ну сейчас блин все на Rust начнут переписывать, а я так люблю
> C :(Останетесь ценным маргиналом, будете поддерживать сверхважное legacy за огромные деньги, в чём проблема?
Не начнут, Эрик уже попробовал rust и он ему не понравился: http://esr.ibiblio.org/?p=7294
> Не начнут, Эрик уже попробовал rust и он ему не понравился: http://esr.ibiblio.org/?p=7294[Без обид :) , не хотел скрасть у коллеги линк-голду своим #146 -- тупо не дочитал досюда.]
Сейчас дочитал (я небыстр+) самого ESR-а до конца. С запросами в последних двух абзацах (хинт), не видать ему нового ЯП. И старые-то уже жмут... Хотя, мож, MLи какие, хаскелы или эрланги бы и подошли. Но мы(примазаться к Классику хочется, да) с Эриком найдём к чему и в них прикопаться -- и Анонимы опенетов не дадут пропасть.
Вывод: Програм[б]ление надо бросать -- всё пустое.
> за огромные деньги,Или сверхмалые, в каком-нибудь задрипаном ЦНИИ
Гы. Две статьи от того же реймонда, но от 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Чувак потыкал раст два дня и всё понял про его перспективы. :-)
Для затравки:> 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.
наверно тут оффтоп, но не знаете ли перспектив D в аналогичных проектах ?