IT в России и мире в реалиях мирового кризиса
1,284,185
7,813
|
slavae ( Слушатель ) |
| 20 дек 2016 22:55:14 |
Занимательные новости от Касперского
новая дискуссия Дискуссия 1.913Отсюда
Ай-да новости: маркетинг vs. кибергопники + перезагрузка Лайнера Мечты.
Снова в эфире уже традиционная рубрика про хрупкость нашего всемирного цифрового дома. Интересных новостей про киберзловредство накопилось много! Да что там, поток таких новостей постепенно переходит из режима горного ручейка в масштаб полноценной Ниагары.
Как ветеран киберобороны скажу, что раньше катаклизмы планетарного масштаба обсуждались по полгода. А сейчас поток сообщений как лососи на нересте — толком и поговорить не о чем. «Слышал, хакнули Мегасуперкорпорацию, украли всё, и даже хомячка гендиректора самоуправляемый дрон унёс в неизвестном направлении?» — «Вчера ещё! А вот ты слышал…?»
Обычно в этой рубрике было в среднем по три новости зараз. Но приходится подстраиваться под обстоятельства, и сегодня будет горячая семёрка по-своему важных и интересных историй из мира цифровой опасности.
«Зарази братуху — получи скидку»
Киберпреступники давно ведут свою криминальную деятельность как бизнес. До нас доходили истории про «партнёрские конференции», когда одни преступные группы собирали другие, чтобы обсуждать сотрудничество и стратегию. Не чужды, в общем, негодяи учебников по менеджменту и маркетингу. А о чём надо думать, строя бизнес? О продуктах и услугах, разработке, организационной структуре, каналах — да много о чём!
Вот некие вымогатели почесали голову и предложили сделать своих жертв прямыми соучастниками в деле распространения малвары. Злобный сетевой маркетинг в худшем виде: зарази двух знакомых и получи ключ от своих файлов бесплатно.
Наступив в какую-нибудь гадость, ты получаешь предложение: плати или подгадь двум людям из списка контактов — пусть они платят (или дальше распространяют). И каждый будет потом чесать голову, то ли сам кликнул не на ту ссылку или забрёл в глубокие и заразные дебри без адекватной защиты, то ли какой-то
Эффективный хэдхантинг по-хакерски
Важная проблема любой организации: как найти правильных людей и мотивировать их эффективно работать? Организаторы DDoS-атак из Турции, не чуждые современных бизнес-тенденций, построили геймифицированную платформу для DDoS-атак, в которой участники соревнуются друг с другом и получают за активность всякие плюшки. Плюшки потом можно конвертировать в хакерские тулзы и софт для кликфрода.
Платформа эта патриотичная, и DDoSить предлагает тех, кого организаторы считают недругами Турции: от Рабочей партии Курдистана до Ангелы Меркель. Вербуются участники среди посетителей подпольных форумов в даркнете. Политически мотивированный краудсорс-DDoS уже случался, и не раз, теперь вот предприимчивые хакеры вывели процесс на удобную платформу с выстроенной системой мотивации участников. Так и представляю себе выпускника какой-нибудь школы MBA, который все это придумал.
Возвращение Shamoon-а и трудности атрибуции кибератак
Сообщают, что хакеры атаковали центробанк, а заодно ещё ряд госорганов и организаций в Саудовской Аравии с помощью старого-недоброго знакомого вайпера Shamoon. Пишут, что на несколько дней встала работа в саудовском агентстве гражданской авиации — впрочем, на работу аэропортов это не повлияло. Напомню, что эта малвара уже попортила крови как раз таки в Саудовской Аравии, когда в 2012-м году с её помощью некие негодяи стерли все данные и все бекапы у Сауди Арамко – крупнейшей нефтяной компании мира. Ущерб можно прикинуть как ГИГАНТСКИЙ. И вот теперь снова тот же зловред в той же стране. И снова показывают пальцем на Иран как на вероятного организатора нападения.
Но при этом, и это очень типичная история для мира продвинутых и не очень кибератак, доказательств виновности Ирана либо нет, либо они по каким-то причинам не представлены широкой публике. Например, в истории известной атаки на Sony Pictures в официальную версию о виновности Северной Кореи поверили не все
, и вполне серьезных альтернативных версий было больше, чем одна. И теперь отнюдь не все согласны, что в атаке Shamoon виноват именно Иран. Некое ближневосточное издание, например, размышляет (ну или высасывает некую субстанцию из пальца), не могла ли последняя атака быть организована Израилем, чтобы стравить Иран и Саудовскую Аравию. Что же там случилось на самом деле мы вряд ли когда-то достоверно узнаем.Крайне сложно назвать виновника кибернападения с высокой степенью достоверности. Доказательств после атаки обычно остаётся немного, и их сравнительно легко фальсифицировать. Ответ на вопрос: «Кто виноват?» в киберпреступлении найти очень сложно. Кстати, именно поэтому мы в своих исследованиях пальцем по показываем, из-за чего, бывает, расстраиваем журналистов, охочих до сенсаций. А что делать? Если говорить, что кто-то сделал что-то – для этого нужны железобетонные доказательства.
Лайнер Мечты. Перезагрузка.
Дальше новости будут всё больше железячные.
Что будет, если неделями не перезагружать компьютер? Обычный ответ: он будет тупить. А если не перезагружать современный пассажирский Боинг-787, то он может на какое-то (короткое) время стать неуправляемым. В связи с этим американское агентство гражданской авиации выпустило указание: Дримлайнер надо перезагружать раз в 3 недели. Потому что если все три управляющие модуля будут включены 22 дня подряд, они могут перезагрузиться одновременно, и пилот в этот момент рискует утратить контроль над самолетом.
источникВолноваться тут не о чем — я лично с удовольствием летал и буду летать 787-м. Но забавно смотреть, как компьютерная магия сменяет традиционную механическую. Если раньше первая мера по исправлению поломки была постучать ногой по колесу, теперь верный первый шаг – «выключи и включи, дай перезагрузиться», и все снова нормально работает. Только теперь в киберфизической реальности, где от стабильности компьютеров зависит реальная безопасность. Добро пожаловать в новый мир!
Будни немецких сталеваров
Тот печальный случай, когда новость уже не воспринимается как важная: хакеры из группировки Winnti взломали немецкого гиганта ТиссенКрупп и украли данные инженерного подразделения. Ещё одна большая компания в списке хакнутых. Не первая и не последняя, отмахнется читаталь. Но! Когда крадут секреты организации производства у больших индустриальных компаний, это вызывает дополнительную тревогу. Потому что, возможно, это подготовка к другим, более разрушительным кибератакам. К тому же в СМИ циркулировали слухи, что именно крупповскую домну взломали и сломали некие злодеи, причинив «очень серьезный физический ущерб». Крупп это отрицал и отрицает. Не уверен, что когда-нибудь подробности всей этой истории сделают публичными. Но даже по долетающим из Германии сигналам можно понять, что кибербезопасность – это очень серьезная проблема для тамошних сталеваров. И не только сталеваров.
Как обмануть умный счетчик
И ещё про железяки и их уязвимости. Производитель домашних солнечных панелей выпустил апдейт к своим счётчикам. Без него негодяи могут перехватить управление системой, всячески манипулировать ею, сообщать неверные данные о количестве поставленной энергии в общую сеть. И, да, куда без этого — вербовать панели в ботнеты для участия в DDoS-атаках. Сценарий «солнечные панели DDoS-ят камеры наблюдения, а те отстреливаются из домашних роутеров» всё ближе к воплощению в жизнь.
источникВ чём заключается уязвимость? Дефолтный админский пароль на все устройства один, и его можно подсмотреть в видеоинструкции к этим панелям на ютюбе. Такая вот нехитрая дыра.
Не забудьте перезагрузить счётчик после установки обновления!
Интернет вредных вещей снова на сцене
Пришло письмо от нашего постоянного радиослушателя Степана Степановича из деревни Глубокое, в котором он просит рассказать об «Интернете Вещей». С удовольствием выполняю его просьбу.
Продолжается печальное шествие по миру ботнета Mirai, который уже отметился в истории самыми мощными DDoS-атаками. Его отличительная особенность — он вообще не заражает персональные компьютеры, серверы и прочие планшеты. Эта часть компьютерной инфраструктуры его не интересует. Он, как хороший стартап, ориентируется на новую реальность – Интернет Вещей. На этот раз из-за малвары без Интернета остался почти миллион клиентов компании Дойче Телеком в Германии — Мирай заразил и «окирпичил» их роутеры. Затем ровно таким же образом он поступил с 100 тысячами пользователей в Великобритании. Червь использует торчащий в интернет WAN-порт, по которому можно дистанционно управлять устройством вообще без всякой аутентификации. Сколько таких устройств в мире? Уязвимых моделей, как минимум, десятки. Читаешь такое, и хочется ущипнуть себя. Как такое вообще возможно? Чтобы вообще без аутентификации. Даже пароля «12345678» нет.
И невольно задумаешься, сколько же надо усилий, чтобы все эти зияющие дыры законопатить? А если копнуть поглубже — ведь вскроются дыры скрытые, но не менее серьёзные. В общем, совет молодым: выбирайте в качестве карьеры кибербезопасность, работы в этой сфере – непочатый край.
Вот такие ай-да-новости принесли нам сети. Надеюсь, что всем понравилось и все от души ужаснулись за успехи цифровых технологий и торжество их шествия по жизни человека. Дальше будут ещё рассказы, оставайтесь на связи!
ОТВЕТЫ (128)
|
Podli ( Слушатель ) |
| 21 дек 2016 12:12:37 |
Цитата: slavae от 20.12.2016 19:55:14
[username@server_name ~]$ uptime
06:53:00 up 307 days, 4:22, 1 user, load average: 1,39, 1,40, 1,32
И это сильно нагруженный сервер, обслуживающий тысячи клиентов в реальном времени. Боинг на винде чтоли летает?
|
|
Superwad ( Слушатель ) |
| 21 дек 2016 16:02:28 |
Цитата: Podli от 21.12.2016 09:12:37
Все банально просто! В норме на 7 млн. нормальных операций процессором приходится одна ошибочная (сбойная). Есть алгоритмы, которые купируют и отслеживают. Есть сбои и при работе оперативной памяти. В обычном компе используют память без всякой перепроверки состояния, в серверах и критических системах - с контролем. Но даже это не спасает! И повреждения в загруженном исполняемом коде из-за ошибок в физических системах накапливается и абсолютно исправный код начинает сбоить - работать неправильно. Решение - загрузить весь код заново (перезагрузка) - вот и все. Банально.
|
|
Podli ( Слушатель ) |
| 21 дек 2016 18:14:40 |
Цитата: Superwad от 21.12.2016 13:02:28
По памяти.
ECC практически всегда ничего не делает. На практике было очень и очень немного случаев (парк серверов огромен - тысячи машин), когда ECC начинала что-то корректировать (это видно в логах ядра). В таких случаях поступали всегда одинаково - меняли планку памяти. Если на гарантии - добивали sysbasher-ом и все равно меняли.
Ну а информация про одну сбойную операцию на 7 миллионов для процессора не выдерживает никакой критики. Современные процы выдают единицы гигафлопс на ядро. Т.е. при полной загрузке мы получаем тысячи ошибок в секунду. При таком громадном количестве ошибок любой код развалится в пыль мгновенно. И да, единственный рабочий способ предотвратить такие ошибки - проводить параллельные вычисления по всем операциям и сравнивать результаты. При несовпадении - пересчитывать.
Истинная причина постоянных перезагрузок проста и банальна. И называется она - утечки памяти. Крупные конечно же находятся и чинятся. А вот поиск мелких утечек попросту намного более трудоёмок. И вместо ловли блох просто периодически приложение перезапускают. Такая же политика партии и на сервере, uptime которого я привел. Периодически (раз в пару недель) приложение там рестартует. Но рестартует приложение, а не сама ось. Благо, качество линуксового кода на порядок лучше "продукта" от мелкомягких.
|
ps_ ( Слушатель ) |
| 21 дек 2016 20:38:07 |
Цитата: Podli от 21.12.2016 15:14:40
Если вы не пользуетесь ежедневно огнетушителем, то это не значит, что он не нужен
|
|
Podli ( Слушатель ) |
| 21 дек 2016 20:54:35 |
Цитата: ps_ от 21.12.2016 17:38:07
Так пользуемся... Какой-то сервак начинает тормозить. Начинаем копать, находим коррекцию ошибок, меняем память. Т.е. оно сначала начнет глючить, потом умрет. Так что есть некоторое время на реакцию.
|
Senya ( Слушатель ) |
| 21 дек 2016 20:48:35 |
Цитата: Podli от 21.12.2016 15:14:40
Если это то, о чём я думаю - первоначально цифра означала, что сбоит 1 из 7 000 000 процессоров, прошедших выходное тестирование.
|
|
ps_ ( Слушатель ) |
| 21 дек 2016 21:03:04 |
Цитата: Senya от 21.12.2016 17:48:35
А мне казалось, что там счет на проценты.
Причем процессоры для работы на разных частотах, просто выбирают по результатам тестирования.
|
|
Senya ( Слушатель ) |
| 21 дек 2016 21:13:55 |
Цитата: ps_ от 21.12.2016 18:03:04
Проценты это просто брака. Не знаю сколько, может 20%, может меньше. Он сразу отбрасывается. Маркировать по частотам могут не только по результатам тестирования, но и просто по требованиям магазинов - сколько каких надо для удовлетворения спроса. Всё равно у бытовых множители блокированы, а в серверном сегменте народ вряд ли такой фигнёй как разгон страдает. Но сквозь любое тестирование обязательно пройдёт часть дефектных кристаллов. В голове крутится вероятность 10-7 (ну да похоже на семь миллионов но конечно не то). Не помню почему. Может быть и какая-то расчетная величина, не имеющая отношения к реальности.
|
|
DarkRaider ( Слушатель ) |
| 22 дек 2016 02:14:35 |
Цитата: Podli от 21.12.2016 15:14:40
1) Это не так, чтобы понять необходимо предметно разобраться в принципах аппаратной работы с памятью, что нереально сделать в формате форумной ленты. Оперативка с чсЕСС на "серверном" железе, на регистровой памяти (так же на интегрированной - допустим рейд-контроллерах) работает хорошо, просто не всегда явно видно КАК она работает. Если грубо и на пальцах - это аппаратно реализованный механизм правильности чтения, в случае обнаружения сбойной операции он корректирует и выдает правильный результат. Ни в какие логи аппаратные реализации не попадают, работают автоматически и незаметно. На "не серверном" железе - уже кто во что горазд и реализации уже кривые (так же как и все встроенные рейд-контроллеры). К слову, ошибки памяти и ошибки ввода-вывода- наиболее частые аппаратные ошибки в "компьютерной среде", вычислительные ошибки по сравнению с ними крайне редки (если не брать специфичные области расчётов).
2) Верно "наполовину", ошибки действительно есть и обычно они обусловлены "железячными" проблемами (ошибки расчёта топологии, температурные дрейфы параметров компонентов, нестабильность электропитания, ошибки в расчёте электромагнитных влияний, ошибки сихронизации) - всё это приводит к возникновению "цифрового шума". Но это не означает, что от этого всё должно разваливаться в пух и прах и совершенно не означает, что "на 1 миллион операций будет гарантированно сделано 39 ошибок". Так же надо понимать, что меры по борьбе с ошибками тоже имеются. Большинство этих ошибок так же проходит на низких уровнях (условно кварц в связи со старением сдвигает немного частоту и захват PLL происходит не сразу, а после n попыток), на практике на исправном оборудовании Вы не встретите ситуации когда ваша высокоуровневая программа будет выдавать 2+2=5.
В серьёзных областях используется так называемое "мажоритирование" - это как раз "параллельная" работа схем. Вот только надо понимать, что это 2-3-n одинаковых линий, которые параллельно делают ОДНО И ТО ЖЕ (На пальцах, если после какого то операнда у нас в регистре на первой линии 0001, а на второй и третьей 0010 - то автоматически правильным признается 0010).
3) Совершенно верно, большинство ошибок - программные. Современный мир активно способствует лавинообразному ухудшению качества кода. Языки программирование - становится всё более высокоуровневыми и всё менее типизированными. Ситуация же приравнивания Ваньки к Маньке отдана исключительно на откуп компиляторов, интерпретаторов, исполнительных машин, сборщиков мусора, которые тоже далеко не идеальны (да и не могут быть идеальны по сути). Количество программистов, которые реально, понимают, что они делают и как это работает "в железе" или "в операционке" - стремительно уменьшается. Кстати имеется и параллельный процесс - ввиду относительной "молодости" программируемых микросхем и микроконтроллеров - тамошние языки программирования из структурных и процедурных сейчас постепенно эволюционируют в сторону роста абстракции, а программисты уже начинают потихоньку терять связь с реальностью.
4) Опять таки современные нетипизированные языки резко способствуют забыванию проверок доступных диапазонов массивов и прочих списков и приложение зачастую "накапливает" ошибку. Опять же контроль входных данных программы - тоже сейчас очень "формален", так ка к очень мало программистов задумывается, что при росте размера входных данных, их алгоритмы красиво работающие на "стандартном размере" - могут начинать расти в геометрической прогрессии так как имеет место лавинообразный рост процента ошибок и времени выполнения алгоритма.
5) Это очень холиварное утверждение, не стоит начинать эти споры. Какой смысл сравнивать совершенно разные подходы и концепции? Всему своё место и время.
|
|
Valery ( Слушатель ) |
| 22 дек 2016 03:26:17 |
Это не так. В свое время модули памяти с дополнительными разрядами (код Хемминга) применяли еще покойной ныне Digital Equipment Corporation на VAX-11/780. В листингах OpenVMS до сих пор "уши" торчат. Сбойные страницы исключались из пула памяти. В логах все было записано. Модули памяти можно было заменять на основании логов ОС. И все это было "честно" содрано даже на советской копии CM-1700. Как и много чего...
Через некоторое время это похерили.
Назовите мне железку, которая ныне использует память с коррекцией ошибок!
В линейках HP я такое не вижу. Заглядываю в свой домашний AlphaServer DS-10 - там тоже только контроль четности, и все.
AlphaServer 2100, 4011, GS-80, GS-1280, Integrity 7640, 8640, и даже дисковый массив HP EVA - нет коррекции, только контроль четности.
На любых серверах x86/x64 я коррекции ошибок тоже не встречал. Возможно, сервера маленькие были. Буду рад ликбезу.
|
|
ps_ ( Слушатель ) |
| 22 дек 2016 10:06:54 |
Цитата: Valery от 22.12.2016 00:26:17
Мне казалось, что сбой памяти - это случайное событие, вызванное пролётом высокоэнергетической частицы космического излучения.
При этом меняется один бит и его можно исправить, если память использует код Хемминга. Исключать эту страницу из пула совершенно бессмысленно. Совершенно нормальная ячейка памяти, просто ей не повезло
Память с коррекцией ошибок называется ECC ram и везде спокойно продаеться (правда стоит раза в два дороже) и требует материнскую плату с поддержкой ECC (тоже раза в 2-3 дороже)
Я себе домой хотел купить, но потом жаба замучила и кроме того они только Xeon поддерживают, а он тоже очень дорогой
|
|
DarkRaider ( Слушатель ) |
| 22 дек 2016 17:19:16 |
Цитата: Valery от 22.12.2016 00:26:17
Любая "железка" на борту которой установлена ECC Registered память.
Практически все сервера, за исключением самых дешёвых одноядерных (зачастую ещё и не на серверных камнях или чипсетах).
Что и как вполне описано в вики
Бессмысленно на серверном классе только "детектировать" наличие ошибки. Она "читает" правильно, если количество ошибок не превышает 1 бит на байт.
Цитата: ЦитатаЦитата: ps_ от 22.12.2016 04:06:54
Мне казалось, что сбой памяти - это случайное событие, вызванное пролётом высокоэнергетической частицы космического излучения.
Исключать эту страницу из пула совершенно бессмысленно. Совершенно нормальная ячейка памяти, просто ей не повезло
Я себе домой хотел купить, но потом жаба замучила и кроме того они только Xeon поддерживают, а он тоже очень дорогой
Всё верно. Ну высокоэнергетическое космическое излучение - это актуально для спутников. У нас внизу причины обычно попроще, обычно - электромагнитные наводки и нестабильность питания. Опять же температурный дрейф может влиять.
Второй пункт вполне справедлив для столь модной нынче какашки как "NAND флэш" и ssd на их основе. Ввиду того, что там страничный механизм ввода-вывод, там как раз при сбое одной ячейки бракуется весь блок (причём на совсем). В общем недешёвое, ширпотребное безмерно раскрученное говно.
Покупать домой "серверный класс" нужно со смыслом, понимая что зачастую они не удобны, шумны и не поиграешь. Цены как раз можно найти вполне человеческие. Б/у сервера с цодов распродают тысяч по 50 рублей сейчас (без жёстких дисков) .
|
adolfus ( Слушатель ) |
| 23 дек 2016 01:24:19 |
Цитата: Podli от 21.12.2016 15:14:40
А) Совершенно верно. Причин несколько:
1) cамая распространненная и практически неустранимая в ближайшей и даже среднесрочной перспективе -- низкая квалификация программистов, обусловленная низким уровнем вхождения в профессию. Мало кто знает, что там под его любимым языком программирования и как этот все проецируется на конкретную архитектуру. 80% программистов, использующих MS Visual Studio, не только не имеют представления, как это работает и что там под ней происходит, но даже не могут найти, где распоалгаются фазы компилятора, линковщика и прочий микрософтовский шмурдяк, который запускается под этой студией. Из тех, кто использует cmake, только 20% знают, как скомпилировать и собрать программу без студии, используя только msbuild. Остальные поднимают проект в студию.
2) следующая по распространенности -- лень заниматься приборкой и чисткой. При этом прикрываются тоезисом, что за то время, которое будет ими потрачено на поиск утечек памяти и других совместно используемых ресурсов, конкурент займет их долю рынка. Хуже всего то, что именно так думает менеджмент в успешных конторах.
3) ну и последняя -- незнание инструментов, которые поиск утечек берут всецело на себя, оставляя программисту функции редактирования дырявых исходников.
Б) Поиск мелких утечек ничем не отличается от поиска крупных и наоборот. Конечно, если Вы не используете самописных аллокаторов/субаллокаторов. Утечки из-под системных аллокаторов легко обнаруживаются, мало того при нормальном завершении процесса все неосвобожденное явно процессом, будет возвращено в общую кучу как только процесс завершится и его дескриптор освободится. Иногда зависает часть памяти у форкнутых потомков, на котороых инструмент поиска утечек простот вешается вместе с ними. Но это имет отношение только к никсам, но не к виндам -- там вообще нет потомков, в смысле наследования ресурсов.
Потерять память можно только в сервисах и программах, которые живут очень долго, и только если написать свой "сверхэффективный для своего сервиса" аллокатор.
На самом деле все очень просто решается:
1) изучаем как система в лице malloc() или winAllocMem(или что там сегодня у них вместо нее) этой памятью рулит
2) не выдумываем велосипедов и используем только системные аллокаторы (malloc(), new), какими бы "неэффектвными" они не казались, решая вопросы эффективности алгоритмическими средствами.
3) все независимые компоненты, внутри которых есть запросы на выделение памяти, обвязываем тестами и прогоняем под валгриндом или что там у них в виндах.
4) собранный вами проект, даже если это проект размером в офис или еще какой ворд, гоняем под валгриндом.
Кстати, сделать пункт 4 с ванильным либрофисом рекомендуется всем, кто бурчит насчет утечек. Просто запускаете готовый ванильный бинарник под валгринд и колупаетесь в нем полчаса. Потом выходите и любуетесь логами.
|
|
vx ( Слушатель ) |
| 23 дек 2016 01:39:18 |
Цитата: adolfus от 22.12.2016 22:24:19
А вот еще чайницкий вопрос: как valgrind поможет от фрагментации кучи?
|
|
DarkRaider ( Слушатель ) |
| 23 дек 2016 02:20:13 |
Цитата: adolfus от 22.12.2016 22:24:19
Сказал - как отрезал. Видимо листинги лабораторок студентов никогда не видел... я, конечно, понимаю "в бизнесе" сейчас все перешли на всякие жабы с дотнетами, где просто нету ни одной malloc во всей программе размером "с оффис"... видимо отвык видеть. Источников "утечек памяти" - очень много можно наделать, даже в программе на 100 строк. Любое некорректное преобразование типов(ручное реже автоматическое), выходы за границы массива и размера переменных - всё это может приводить к "потерянным" кускам данных в памяти. Любые операции ввода-вывода при плохом просчёте алгоритма работы легко приводят к "забуферным" кускам.
Цитата: ЦитатаМожно, конечно, на си писать с ассемблерными вставками и добиться того же, но народ предпочитает использовать фортран и не учить ассемблеры.
Тема мантры "Фортран - наше всё", на мой взгляд, раскрыта полностью.
Может всё таки не стоит концентрироваться на языке?
Язык программирования - лишь способ описания алгоритма, для выбранной исполнительной платформы. Языков много, не все из них обладают равными возможностями, но тем не менее большинство универсальных языков более менее эквивалентно. Какие то удобней Вам, какие то не Вам. Зачем строить на этом всё сущее, вплоть до засирания платформы, только потому, что на ней любимый компилятор ещё не торт?
|
|
TAU ( Слушатель ) |
| 23 дек 2016 10:33:55 |
Цитата: adolfus от 22.12.2016 22:24:19
На самом деле при разработке критически важных приложений еще проще решается:
1) Не использовать вообще динамическое распределение памяти, или
2) Не использовать языки с "опасным" распределением памяти
|
|
DarkRaider ( Слушатель ) |
| 23 дек 2016 13:28:46 |
Цитата: TAU от 23.12.2016 07:33:55
Это автоматически означает потерю эффективности работы приложения (но не разработки естественно).
Чем "опаснее" язык и ниже уровень его абстракции - тем ближе низкоуровневые системные ресурсы, тем выше скорость работы кода и ниже влияние промежуточных этапов (компиляции например), больше потенциальных возможностей оптимизации. Оборотная сторона медали - выше сложность написания, сложнее поддержка кода, большая длительность разработки и отладки, ну и естественно уровень программиста.
Любая абстракция вверх, это повышение "удобности" за счёт требуемых мощностей.
К слову, "критически важные" приложения, при работе на нетипизированных ("сука опасных" как говаривали в Комеди) редко получаются хорошо... так как такое программирование очень быстро снижает уровень проработки кода. Уже не надо думать о том, как что происходит. Знай себе лепи, а компилятор за тебя всё посчитает и приведёт. Да и необходимость таскать за собой "пол операционки" (дотнет например или жабамашина) - тоже не всегда удобна.
|
|
Superwad ( Слушатель ) |
| 23 дек 2016 15:28:35 |
Я не знаю, как насчет быстрой обработки скорости кода. Я как-то пробегал по исходникам библиотек Delphi (VCL) - там половина на чистом Асме написана.
Вот FPC на низком уровне не смотрел - как-то не было надобности. Как в FPC решили проблему кроссплатформенности - не знаю.
А вообще, выкинуть С++ как язык, в котором логика размазана по файлам на один более логически четкий, так как большая часть времени приходится на отладку и логика в плюсах - это вырви мозг. И не надо на меня наседать, что это не так. Да и хваленая "стандартизация" плюсов - это полная туфта. Лично столкнулся. Тот же FPC если надо уменьшить код из-за библиотек, то вместо LCL можно использовать KOL.
А для написания безопасных и критически важных программ нужно использовать специальные компиляторы и языки программирования, специально под это заточенные. И С++ и близко туда не подпускать!!! Пристрелить на подступах за горизонтом!!!
|
|
DarkRaider ( Слушатель ) |
| 23 дек 2016 16:35:44 |
Цитата: Superwad от 23.12.2016 12:28:35
Да Паскаль - хороший язык (мне лично самый удобный), вот только F2C обсуждалась утилитка для коверта Фортран программ в Си программы. С кроссплатформенностью у Free Pascal всё замечательно решено. Список доступных архитектур - вполне достойный.
Цитата: ЦитатаА вообще, выкинуть С++ как язык, в котором логика размазана по файлам на один более логически четкий, так как большая часть времени приходится на отладку и логика в плюсах - это вырви мозг. И не надо на меня наседать, что это не так.
Глубота высот этой фразы ускользает в небытие непонятности через дыру в подсознании. Вы сами то поняли что сказали?
Цитата: ЦитатаА для написания безопасных и критически важных программ нужно использовать специальные компиляторы и языки программирования, специально под это заточенные. И С++ и близко туда не подпускать!!! Пристрелить на подступах за горизонтом!!!
Да вот как бы нету их, сильно специализированных системных языков в пруду неспециализированных платформ исполнения. Ближайший представитель этой "специализированной" фауны встретится в программировании микроконтроллеров... а ну да... и они ВСЕ строго типизированные... не работает железяка иначе на низком уровне... нолики, единички понимаешь....
Так что увы, "системные универсальные" - это С(до диеза) и ассемблер. Ну а если мы берём "не системные" задачи - то список уже гораздо шире и гаже, так как сильно варьируется от решаемых задач. Да и полоумных много... в своё время работал в конторе, поставляющей зуботехническое оборудование. Очень дивился тому, что НЕМЕЦКИЙ 5-координатный фрезерный стоматологический(маленький для протезов) станок имел штатное виндовое ПО (там своя небольшая САПР напоминающая solidworks) на жабе.
|
|
Alexxey ( Слушатель ) |
| 23 дек 2016 17:22:06 |
Сообщение удалено
Alexxey
25 дек 2016 18:17:20
Alexxey
25 дек 2016 18:17:20
Отредактировано: Alexxey - 25 дек 2016 18:17:20
|
|
Superwad ( Слушатель ) |
| 26 дек 2016 13:19:51 |
Для осознания глубины этой мысли добавлю - С++ шаблоны, дженерики, перегружаемые функции и их вызов из не из С++ компилятора. Чтобы найти проблему в трех соснах - потратил месяц!!! Ну его нах... Чес слово, ненавижу С++ - это взрыв мозга у того, кто отлаживает программы - ТАКОЙ системы еще надо поискать. Сделано специально для диверсантов. По другому не понимаю, для чего это сделано.
Цитата: ЦитатаЦитата: DarkRaider от 23.12.2016 10:35:44
***съедено на обед***
Да вот как бы нету их, сильно специализированных системных языков в пруду неспециализированных платформ исполнения. Ближайший представитель этой "специализированной" фауны встретится в программировании микроконтроллеров... а ну да... и они ВСЕ строго типизированные... не работает железяка иначе на низком уровне... нолики, единички понимаешь....
Так что увы, "системные универсальные" - это С(до диеза) и ассемблер. Ну а если мы берём "не системные" задачи - то список уже гораздо шире и гаже, так как сильно варьируется от решаемых задач. Да и полоумных много... в своё время работал в конторе, поставляющей зуботехническое оборудование. Очень дивился тому, что НЕМЕЦКИЙ 5-координатный фрезерный стоматологический(маленький для протезов) станок имел штатное виндовое ПО (там своя небольшая САПР напоминающая solidworks) на жабе.
Так, про станки и системы реального времени бывают двух типов
а) двухсистемные (терминальная часть -ЛЮБАЯ ОС, исполнительная - RTOS (вы не поверите, но это DOS, WinCE, Linux и др. пром. RTOS)
б) односистемные - только специальные RTOS (у нас есть станки, которые работают на специальной версии Линукса, разработанного Сименс). Где исполнение и терминальная часть - в одном флаконе. Кстати, кроме WinCE? остальные Виновсы - не системы реального времени. От слова совсем.
То что вы видели - это тупо терминальная часть - может быть написана на чем угодно, но исполнительная - только на RTOS. Тут без вариантов.
|
|
DarkRaider ( Слушатель ) |
| 26 дек 2016 15:55:25 |
Цитата: Superwad от 26.12.2016 10:19:51
Я понимаю душевную боль и тоже его недолюбливаю, но "работа тем сложнее чем меньше в ней понимаешь", да и качество первоначального кода не факт что нормальное. Вот и приходится "отлаживать месяцами". Уверяю, что проблем с отладкой чужих проектов на других языках не меньше.
Цитата: ЦитатаТак, про станки и системы реального времени бывают двух типов
а) двухсистемные (терминальная часть -ЛЮБАЯ ОС, исполнительная - RTOS (вы не поверите, но это DOS, WinCE, Linux и др. пром. RTOS)
б) односистемные - только специальные RTOS (у нас есть станки, которые работают на специальной версии Линукса, разработанного Сименс). Где исполнение и терминальная часть - в одном флаконе. Кстати, кроме WinCE? остальные Виновсы - не системы реального времени. От слова совсем.
То что вы видели - это тупо терминальная часть - может быть написана на чем угодно, но исполнительная - только на RTOS. Тут без вариантов.
1) Действительно, системы реального времени бывают 2х типов: QNX и сотоварищи (их много, в том числе самоправленных разными концернами) и WIndows-style (WinCE). Из них полноценные - только первые, так как CE - это система для написания "графических интерфейсов", концепция у ней такая... чтобы "не тормозила коммуникация с пользователем".
2) "терминальная часть" - это в описанном случае утилита командной строки, которая конвертирует "прожект" в G-коды и передаёт их в станок. А "Мегасапр" на жабе - это вполне себе самостоятельное приложение. Про него и речь.
3) Ввиду того, что наблюдаю пром. оборудование довольно часто - не все станки на RTOS. Достаточно их и просто на никсах. Всё таки область использования RTOS тоже довольно специфична и не везде оно нужно.
|
|
adolfus ( Слушатель ) |
| 02 янв 2017 19:45:11 |
Назовите хоть одну систему, где "прерывания хранятся в стеке или регистрах"?
|
barracuda1 ( Слушатель ) |
| 27 дек 2016 09:50:24 |
Цитата: Superwad от 26.12.2016 10:19:51
Подозреваю перл заставит вас застрелиться
А регулярные выражения заставят предварительно выпить яду, для надежности
|
|
Hadan ( Слушатель ) |
| 27 дек 2016 12:43:03 |
Цитата: Superwad от 26.12.2016 10:19:51
Ха, канделябром надо, канделябром.
Проблема не в языка а в мозгах. Понимать надо, что и где и как использовать, и писать надо «правильно», а не «круто».
На самом деле плюсы, замечательно ложатся на «железо». Темплеты, статики и инлайны заворачивают аппаратные особенности, так как не завернешь ни какими дефайнами.
|
|
adolfus ( Слушатель ) |
| 27 дек 2016 22:48:56 |
Цитата: Superwad от 26.12.2016 10:19:51
Хорошие шаблоны -- это клад для прикладника. Шаблоны не нужно отлаживать -- ими нужно пользоваться. Чем Вам не угодил STL, например?
Перегружаемые функциии? И как это может затруднить отладку? Может просто нужно использовать вменяемые имена и взять нормальный отладчик? Тогда и трех сосен не будет.
С++ хороший в своей основе язык, но есть и маразмы на ровном месте. Например, симметричное ограничение доступа к закрытой части класса. Куда бы было лучше, если бы доступ по записи/чтению устанавливался независимо. Типа, писать не можешь, но читать -- пожалуйста. Или наоборот. Всего лишь что-то типа модификаторов "readable"/"writable" в закрытой части класса.
|
Lapsha ( Слушатель ) |
| 28 дек 2016 08:32:39 |
Цитата: adolfus от 27.12.2016 19:48:56
Это тривиально реализуется заданием private модификатором соответствующего свойства плюс public/protected модификаторами соответствующего getter/setter метода(-ов). Если только readable - отсутствие открытого сеттера.
Самые основы правильного кодирования на языках ООП.
Модификаторы readable/writable - ненужная перегрузка лексики.
|
|
barracuda1 ( Слушатель ) |
| 28 дек 2016 09:55:22 |
Цитата: adolfus от 27.12.2016 19:48:56
А что вам мешает сменить приват на паблик? (да и другие методы доступа есть)
|
|
Lapsha ( Слушатель ) |
| 28 дек 2016 10:15:41 |
Доступ останется симметричным. Будет открытым для чтения и для записи.
В "правильном" кодировании доступ к данным в ООП рекомендуется делать через методы. Для остального есть структуры, к ООП не относящиеся. Это распространенная мешанина в мозгах у сишников - использование подходов и стиля С в С++. Каждый инструмент требует соответствующего обращения.
|
|
barracuda1 ( Слушатель ) |
| 28 дек 2016 10:49:02 |
Цитата: Lapsha от 28.12.2016 07:15:41
Так то да, но изначально вопрос ставился о времени обработки данных.
К примеру в шарпе сборщик мусора может и хорош (как меня некоторые уверяют), но на мой взгляд тратит уйму времени по сравнению с прямым доступом к массиву
PS: Просто задачи передо мной - обработка видео "на лету"
На ваш взгляд такой доступ к данным приемлем при необходимости обеспечить FullHD качество с дополненной реальностью в реальном времени?
|
|
Lapsha ( Слушатель ) |
| 28 дек 2016 12:01:14 |
Это сильно зависит от общей конфигурации железа, на котором все исполняется. Главным образом связки ЦПУ и графического ускорителя.
Но для реального времени, да еще и HD, да еще и манипуляцией битами в runtime, я не думаю, что применение Jit-среды исполнения с GC вообще хороший выбор.
Плюс юзание GDI вместо прямой работы с видеобуфером (OpenGL или DirectX в конкретном случае Win). Drawing - это ж API для работы с GDI (GDI+), не так ли? Я не копенгаген в Шарпе.
Сами вызовы функций выглядят вполне некоряво. Но и только.
|
|
barracuda1 ( Слушатель ) |
| 28 дек 2016 12:12:27 |
Цитата: slavae от 28.12.2016 08:56:45
Цитата: Lapsha от 28.12.2016 09:01:14
К сожалению взять битмап могу только так, так как передается из другого плагина написанного на шарпе (кстати приведенный код это С++)
Далее DirectX в связке с OpenCV (кстати во многом использующим ГПУ) и Point Cloud Library (PCL)
|
|
Lapsha ( Слушатель ) |
| 28 дек 2016 12:21:11 |
Сбили с толку заглавные буквы в названии подключаемых библиотек: IO, Drawing. Сильно "неклассический" с-шный и с++-шный стиль. С .NET не работаю и не работал, там же все унифицировано для всех сред исполнения, насколько я знаю.
|
|
barracuda1 ( Слушатель ) |
| 28 дек 2016 12:29:57 |
Цитата: Lapsha от 28.12.2016 09:21:11
Это CLRные библиотеки, using namespace System :: Drawing :: Imaging;
раньше тоже с ними никогда не работал, а вот пришлось
|
|
михайло потапыч ( Слушатель ) |
| 28 дек 2016 14:14:10 |
Видео в реальном времени надо обрабатывать прямо на GPU, например с помощью OpenCL, если конечно имеется такая возможность и выделенная видяха.
|
|
spv2 ( Слушатель ) |
| 28 дек 2016 02:31:18 |
Ада
Из новенького - Go, но он очень уж специфичный. ПМСМ, попытка убрать одни плохие практики оборачивается появлением других плохих
Но попытка заметная, хотя для критических областей я бы его не использовал.
|
|
TAU ( Слушатель ) |
| 23 дек 2016 19:32:13 |
Цитата: Superwad от 23.12.2016 12:28:35
По большому счету Вы, безусловно, правы. В АО "Информационные спутниковые системы" используется, например, Модула-2. Увы - весьма значительная часть именно критически важных пишется именно на Cи и С++.
|
|
adolfus ( Слушатель ) |
| 21 дек 2016 18:54:15 |
Цитата: slavae от 20.12.2016 19:55:14
Вот мой десктоп на работе.
$ uptime
16:42:42 up 37 days, 1:12, 3 users, load average: 0,95, 0,79, 0,77
Перезагружаю только тогда, когда ядро апгрейдится. И так семь с половиной лет. Ниже SMART статистика по жесткому диску.
Насчет утечек памяти. Самое поганое на этот счет приложение -- это файрфокс. Обязательно нужно за ним следить в htop и килять как только захватит полоперативки или даже раньше, если стал выгружаться на диск. Иначе все равно придется килять, но уже с другого компа -- иксы встанут так, что не добраться до терминала на локалхосте.
|
|
Podli ( Слушатель ) |
| 21 дек 2016 19:15:27 |
Цитата: adolfus от 21.12.2016 15:54:15
Цитата: Цитатаusername@machine_name:~$ top
top - 17:12:49 up 8:09, 17 users, load average: 0,15, 0,17, 0,23
Tasks: 294 total, 1 running, 292 sleeping, 0 stopped, 1 zombie
%Cpu(s): 1,8 us, 0,2 sy, 0,0 ni, 98,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 16144788 total, 4265276 used, 11879512 free, 261388 buffers
KiB Swap: 16486396 total, 0 used, 16486396 free. 1967920 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3046 k-zabel+ 20 0 2187576 879224 105436 S 2,7 5,4 54:11.48 firefox
3962 k-zabel+ 20 0 695012 276440 93364 S 2,3 1,7 10:52.38 skype
1111 root 20 0 782012 253456 230152 S 0,3 1,6 12:40.98 Xorg
2513 k-zabel+ 20 0 1097024 176084 91816 S 0,0 1,1 3:13.45 python2.7
4742 k-zabel+ 20 0 1204364 149492 69432 S 3,0 0,9 10:34.22 psi-plus
1672 k-zabel+ 20 0 1261832 109564 60052 S 0,0 0,7 10:27.19 compiz
2474 k-zabel+ 20 0 676988 72712 26804 S 0,3 0,5 2:23.95 gnome-term+
1814 k-zabel+ 20 0 884620 61344 21756 S 0,0 0,4 0:00.12 evolution-+
1831 k-zabel+ 20 0 1127600 58884 46600 S 0,0 0,4 0:01.20 nautilus
С утра на работе, постоянно бегаю в браузере. 100500 вкладок, постоянно плодятся и умирают в процессе. Что я делаю не так?
Ну и да, swap - зло. Отключен везде.
|
|
adolfus ( Слушатель ) |
| 21 дек 2016 21:12:10 |
Цитата: Podli от 21.12.2016 16:15:27
Оставьте машинку на недельку -- две, потом отпишетесь сколько своих окон и вкладок файрфокс на третьи сутки сможет обслужить.
Кстати, виртуалбокс с семеркой, которой выделена половина памяти и половина ядер, нормально через какое-то время неактивности выгружается и совершенно не мешает. А вот файрфокс висит в памяти круглосуточно и хрен его оттуда чем выкуришь. Полагаю что-то эта кодопомойка постоянно что-нибудь самостоятельно отсылает или принимает.