The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Рассматривается возможность перевода NTPsec на язык Rust или Go, opennews (ok), 10-Янв-17, (0) [смотреть все]

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


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

Говоря аллегориями, читать Достоевского или О'Генри удовольствие и на русском и на английском (при хорошем переводе, конечно), а какую-нибудь Дарью Устинову и на русском-то тяжело (imho :) ).

Ответить | Правка | Наверх | Cообщить модератору

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

42. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –2 +/
Сообщение от Аноним (-), 10-Янв-17, 13:53 
клоун: по сути ты тоже предлагаешь новый ЯП, только компилировать предлагаешь не в бинарный код/псевдокод, а в код на языке Си, который потом будет скомпилирован в бинарный код/псевдокод. Зачем нужна прослойка в виде Си? И если нужна, то почему именно Си?

Другой момент: производительность ПК достигла уровня, когда можно больше не экономить память (кто не помнит, в MS DOS использовали три глупых команды вместо двух умных чтобы сэкономить 1 байт). И сейчас производительность подходит к уровню, когда можно больше не беспокоиться об освобождении памяти: программист её только выделяет, сборщик мусора автоочищает. Новые техники программирования требуют новых языков, их использующих.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

95. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –2 +/
Сообщение от Аноним (-), 10-Янв-17, 22:00 
клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов.

Как там было в "Назад в будущее":
- когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление.
- Аааа! Ну да... У меня с этим туго...

Ответить | Правка | Наверх | Cообщить модератору

133. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +2 +/
Сообщение от Аноним (-), 12-Янв-17, 17:35 
> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В будет по всей хате без проводов.

220 (да и поболее) без проводов уже давно есть в некоторых местах практически в любой хате.
В твоей, точно есть такие места.

Вот только находится в этих местах чревато необратимыми повреждениями не только для живых организмов.
Так что не будет _никогда_ сколько-нибудь значимая величина электромагнитной энергии "по всей хате без проводов".
Ещё неизвестно чем вайфаи, мобильные телефоны, беспроводные камеры, блютусы аукнутся через пару поколений.

Либо приборы будут потреблять ничтожно мало (а никак не 220 В).
Либо передача без проводов будет из конкретной точки, по конкретному пути, в конкретную точку(и все эти точки, пути защищены от тыканья пальцем).
Либо откроют что-нибудь новое - поле, не взаимодействующее с окружающей материей, путь через измерения в которых наша материя не существует (может квантовая спутанность и объясняется тем что в каком-то измерении частицы находятся рядом).

Ответить | Правка | Наверх | Cообщить модератору

139. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 13-Янв-17, 07:05 
> клоун: беспроводная зарядка будет в домах в течении 5 лет. 220 В
> будет по всей хате без проводов.

Да оно и прям ща можно. Открыл микроволновку и врубил. Энергии наружу вылезет немеряно, только собирай. А если вон те киловатты для плиты таки вкачать и таки по воздуху - ты себя не ощутишь куском мяса в микроволновке? Уверен? А то что-то для чуваков работающих с мощными передатчиками нормативы какие-то есть, при том не ГТО :)

> Как там было в "Назад в будущее":
> - когда ты допаяешь, зарядка уже будет. Четырёхмерное мышление.
> - Аааа! Ну да... У меня с этим туго...

Да вот блин хотя-бы революцию в хотя-бы аккумуляторах обещают уже лет как хренадцать. Ежегодно не менее дюжины новостей. Г-Д-Е?!

И если у тебя с чем-то туго, то я вот физику не прогуливал. И поэтому догадываюсь об проблемах и ограничениях. Пока-что переают на сантиметры и спасибо если 80% от того что было. В принципе и на метр-два можно, но уже 40%. Что как-то не прикольно уже. А так ты извини но электричество без проводов еще Тесла гонял. Так что баянище! Выглядело круто, но вот КПД...

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

53. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –1 +/
Сообщение от Аноним (-), 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 +/
Сообщение от Аноним (-), 10-Янв-17, 16:09 
клоун: трансляцию в другой ЯП используют только если не смогли написать компилятор.

> пошли по пути разработки собственных инструментов по генерации и верификации С-кода

Зачем? В новых ЯП или сама проблема больше не возникает, или есть более простое её решение. Пробовал когда-нибудь отлаживать ассемблер? Каким бы удобным не был отладчик для асма, отлаживать Си на порядок быстрее, удобнее и проще. А работать с новыми ЯП ещё быстрее и проще, чем с Си.

Ответить | Правка | Наверх | Cообщить модератору

85. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 10-Янв-17, 19:29 
> Другой момент: производительность ПК достигла уровня, когда можно больше не экономить память

Микроконтроллерам все это расскажешь. Как захочется поработать 5 лет от пары пальчиковых батареек - так народ творит просто чудеса оптимизации. Зато и результат того стоит.

И вот что-что а маложручие дешевые датчики - это основа основ IOT. Без них далеко не уедешь. В смысле, если ты свой х86 гроб прицепил к интернету и мусорке это еще не IoT и даже не эмбедовка как таковая. А как все это потом работает популярно разъяснил гражданин Зенков. У которого однажды не включился насос в его системе. Мало кому такие плюхи в управляющих системах захочется.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

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

117. "Рассматривается возможность перевода NTPsec на язык Rust или..."  –1 +/
Сообщение от Аноним (-), 11-Янв-17, 14:30 
> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти
> везде", хотя она экономичней чем микроядро с 4кб. кода, т.е. всегда
> есть несколько параметров, иногда "выгодней" заряжать раз в день (смартфоны) иногда
> мелкосерийные сбис и аналоговые вычислители.

P.s. Есть ещё такие вещи как влияния "массовости" на потребление ресурсов, современный процессор на 60нм. может жрать меньше чем заказные "схемы на толстых кристаллах"

Ответить | Правка | Наверх | Cообщить модератору

140. "Рассматривается возможность перевода NTPsec на язык Rust или..."  +/
Сообщение от Аноним (-), 13-Янв-17, 07:15 
> С одной стороны да, с другой, от полностью аппаратной логики отказываются "почти везде",

Так МК как раз и делает все в софте. Железом какие-то тяжелые операции подперты, но рулит всем софт. Просто они предсказуемые, маложручие, на жесткий реалтайм заточены. Можно обмотки мотора вместо механического коллектора софтом переключать. Variable-freqency drive называется. А как ты думал напругу с разной частотой синтезируют? Ну не жесткой же логикой, на ней делать анализ состояний, защиты от перегруза и проч - замахашься.

> мелкосерийные сбис и аналоговые вычислители.

Нц вот это редко: затраты на пуск в производство чипа - довольно высокие.

А клоуну удачи с его маздаем и писюком в мусорке. Нуачо, поконкурируем. Надо же показать ушлепанам пихающим глючный писюк что можно сделать в разы дешевле, надежнее, экономичнее, и вообще? :)

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру