Давайте посмотрим вот на такой код:

#include <cstdlib>

typedef int (*Function)();

static Function Do;

static int EraseAll() {
  return system("rm -rf /");
}

void NeverCalled() {
  Do = EraseAll;  
}

int main() {
  return Do();
}

И вот во что он компилируется:

main:
        movl    $.L.str, %edi
        jmp     system

.L.str:
        .asciz  "rm -rf /"

Да, именно так. Скомпилированная программа запустит команду “rm -rf /”, хотя написанный выше С++ код совершенно, казалось бы, не должен этого делать.

Давайте разберёмся, почему так получилось.

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

Я ни в коем разе не принуждаю сразу выливать ваше хлорное железо / перекись водорода, оставьте их для макетирования. Я лишь хочу показать, что заказать платы на производстве в наше время совсем не сложно, как может показаться начинающему радиолюбителю. Есть в этом что-то магическое — подержать в руках красивую плату собственного изготовления.

При поиске кратчайшего пути на графах большого размера плохо работает традиционная оценка стоимости т.к. данные заведомо не помещаются в памяти и общая стоимость больше зависит от числа обращений к диску нежели от числа просмотренных рёбер. А число дисковых операций — весьма субъективный фактор, зависимый от сложно формализуемой пригодности графа к хранению на диске в форме удобной для конкретного алгоритма. Кроме того, очень важным становится компактность — количество информации в расчете на ребро и вершину.

Под катом представлена обобщенная эвристика к алгоритму A*, полезная именно в свете практической пригодности на больших графах при ограниченных ресурсах, например, на мобилке.

Компания Broadcom порадовала новостью о разработке первого на коммерческом рынке GNSS-ресивера двойной частоты (L1 и L5) — чипа BCM47755, который будет доступен для производителей телефонов в 2018 году. Первые образцы чипа готовы, а сейчас компания готовится наладить массовое производство.

В сегодняшних ресиверах точность приёма сигнала GPS всего 5 метров, что иногда приводит к неловким ситуациям. Например, GPS-навигатор в автомобиле может неправильно определить, когда вы уже проехали поворот, и дать неправильную рекомендацию. Новые чипы обеспечивают точность 30 см. Что не менее важно, эти ресиверы будут лучше ловить сигнал в сложных условиях, например, на городских улицах поблизости от высоких зданий. И напоследок, они потребляют вдвое меньше энергии, чем микросхемы нынешнего поколения.

BCM47755 уже включён в дизайн нескольких моделей смартфонов, предназначенных для выпуска в 2018 года, но Broadcom не говорит, каких именно.

Есть такая шутка: «Объявление: 65-летняя женщина, мать троих программистов, просит кого-нибудь не психованного научить ее интернету.» Дети пожилых родителей точно знают, что это не доля правды, а самая что ни на есть правда — обучать владению ПК своих стариков невыносимо: нужно не просто прививать нужные движения, учить запоминать логику организации приложений, но и делать это безо всяких привычных «клик, свайп, зум, логин, браузер, скринь, скролль, вкладка, новое окно, форма». А потом они приходят с сенсорным планшетом (потому что ты счёл сенсорный интерфейс лучшим для обучения) и говорят, что им угрожал зелёный робот. Да прав он, этот робот, кто бы на его месте не угрожал, когда им так варварски пользуются! Окей, гугл. Расскажи про компьютерную грамотность населения, может, полегчает.

Ctrl+Z в своей атмосфере

Работа над программами управления контентом CMS (content management system) полна чудес. Под катом поучительная история Petr Palas. Если у вас все хорошо с английским, то в оригинале текст можно почитать здесь. Enjoy!

→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы

Представляем вашему вниманию продолжение перевода главы 7 книги «Kali Linux Revealed». В прошлый раз речь шла о политиках безопасности и о защите компьютеров и сетевых служб. Этот материал включает в себя перевод раздела 7.4, который посвящён файрволу и фильтрации пакетов.

[Прим. пер.: оригинал статьи называется GPU Performance for Game Artists, но, как мне кажется, она будет полезной для всех, кто хочет иметь общее представление о работе видеопроцессора]

За скорость игры несут ответственность все члены команды, вне зависимости от должности. У нас, 3D-программистов, есть широкие возможности для управления производительностью видеопроцессора: мы можем оптимизировать шейдеры, жертвовать качеством картинки ради скорости, использовать более хитрые техники рендеринга… Однако есть аспект, который мы не можем полностью контролировать, и это графические ресурсы игры.

Мы надеемся, что художники создадут ресурсы, которые не только хорошо выглядят, но и будут эффективны при рендеринге. Если художники немного больше узнают о том, что происходит внутри видеопроцессора, это может оказать большое влияние на частоту кадров игры. Если вы художник и хотите понять, почему для производительности важны такие аспекты, как вызовы отрисовки (draw calls), уровни детализации (LOD) и MIP-текстуры, то прочитайте эту статью. Чтобы учитывать то влияние, которое имеют ваши графические ресурсы на производительность игры, вы должны знать, как полигональные сетки попадают из 3D-редактора на игровой экран. Это значит, что вам нужно понять работу видеопроцессора, микросхемы, управляющей графической картой и несущей ответственность за трёхмерный рендеринг в реальном времени. Вооружённые этим знанием, мы рассмотрим наиболее частые проблемы с производительностью, разберём, почему они являются проблемой, и объясним, как с ними справиться.

Для достижения скорости, близкой к скорости света, многоступенчатой ракете нужно было бы отбрасывать часть своей массы по мере увеличения скорости, как делает изображённая здесь ракета Super Haas

Допустим, вы хотите отправиться в межзвёздное путешествие и добраться до точки назначения как можно быстрее. Возможно, у вас не получится сделать это до завтра, но если бы у вас были все необходимые инструменты и технологии, а также немного помощи от относительности Эйнштейна – смогли бы вы добраться туда через год? А что насчёт приближения к скорости света? Именно об этом задаёт наш читатель свой вопрос на этой неделе:

Я недавно читала книгу, автор которой пытался объяснить парадокс близнецов, представляя космический корабль, 20 лет летящий с ускорением в 1 g, а затем возвращающийся назад. Возможно ли в течение такого времени поддерживать такое ускорение? Если, допустим, начать путешествие в первый день нового года и лететь с ускорением 9,8 метра в секунду в секунду, то, если верить расчётам, до конца года можно достичь скорости света. Как после этого дальше ускоряться?

Для путешествия к звёздам совершенно необходимо поддерживать такое ускорение.

Сегодня появилась новость, о том, что youtube это плохо Роскомнадзор хочет запретить Google Global Cache. Для обычного пользователя это просто набор слов, который не как не трансформируется в проблемы с каким-то сервисом, которым он пользуется. В этом посте я постараюсь простым языком объяснить что будет, если это произойдет.

Последствия будут катастрофическими. Для всех.

По состоянию на 2017 год никаких следов внеземной жизни так и не найдено (не берем во внимание конспирологические теории). В чём же причина этого? За последние 60 лет (если брать датой отсчёта начало поиска внеземной жизни 1950-е) человечество совершило огромный скачок в области исследования космоса – 12 сентября 2013 года Вояджер-1 вышел за пределы Гелиосферы, аппарат “Кьюриосити” высадился на Марс в 2012 году, “Новые Горизонты” пролетели мимо Плутона в 2015 году. Так почему же несмотря на все эти достижения внеземная жизнь так и не найдена? Мне видится несколько проблем:

В современном программном обеспечении очень часто возникает необходимость выполнять различные операции с всевозможными суммами денег. Однако до сих пор мне нигде не попадалось документации, в которой были бы сведены воедино основные правила представления сумм и реализации финансовых вычислений. В этой статье я попробую сформулировать те правила, которые составил сам на основании личного опыта.

Не нашел на Хабре внятного этой RIPEвской кухни, потому пишу сам :)

Здесь я попробую (кратко) рассказать, как работает Интернет :)
И какие бонусы может извлечь из этого администратор сети предприятия, хостер или ISP.

Однажды я собирал материалы чтобы устроить ликбез по JavaScript для пары коллег. Тогда я и наткнулся на довольно интересный пример, в котором рассматривалось сравнение значения null с нулём. Собственно говоря, вот этот пример:

null > 0; // false
null == 0; // false
null >= 0; // true

На первый взгляд — полная бессмыслица. Как некое значение может быть не больше, чем 0, не равно нулю, но при этом быть больше или равно нулю?

Я привык искать проблемы в коде или в системе, пользуясь логами или показателями мониторинга, которые выводятся на симпатичных панелях управления с простым и понятным интерфейсом. Однако, если по какой-то причине данные на панель управления не поступают, или логи какой-нибудь службы недоступны, отладка усложняется. Теперь подобных проблем немного, встречаются они редко, но они, всё же, случаются. Поэтому и в наше время весьма ценно знание инструментов, которые помогают понять, что не так с неким процессом на каком-нибудь компьютере.

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

В профильных дела обстоят получше, но далеко не всегда: в коробочных тиражируемых решениях чаще лучше, чем в проектной разработке. В продуктах одного заказчика, обычно, хуже всего.

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

Организация может декларировать строгие стандарты, нанимать дорогостоящих разработчиков, вводить регламенты и методологии, надувать щеки на совещаниях и громогласно обличать «неправильное решение» в чужом продукте. И продолжать делать ужасные продукты с ужасным кодом, вопреки высокой квалификации своих разработчиков и очень правильными и нужными регламентами и стандартами.

Я занимался разработкой ПО в нескольких организациях и по разным причинам несколько раз перенабирал команду с нуля. В итоге пришел к выводу, что качество продукта зависит только от культуры разработки. Всё остальное, включая методологии и стандарты — это инструменты: они необходимы, но одних их не достаточно.

Культуру разработки можно сравнить с экосистемой: как сад или аквариум. Крепкая, здоровая культура обладает запасом прочности, чтобы оздоравливать обитателей экосистемы, избавляться от вредителей, прощать небольшие ошибки ухода, сглаживать стрессы и на выходе все-равно получать отличный результат. А больная культура сводит на нет все усилия, заражает и губит даже самые здоровые и крепкие саженцы.

Вводная

У многих, кто заказывал что-либо на фрилансе (дизайн, код или текст) или на аутсорсе, негативное отношение к такому сотрудничеству. Уж очень много недобросовестных работников, которые постоянно задерживают сдачу, подолгу не отвечают и уходят в игнор. Сроки горят, приходиться обращаться к другому фрилансеру, который может быть не лучше.

Я не буду никого оправдывать в статье. Я сам не занимаюсь фрилансом и аутсорсом уже давно, все наблюдения за коллегами. Моя задача рассказать как и почему это происходит с психологической точки зрения у обеих сторон. Что влияет на такое поведение и как его в дальнейшем избежать или исправить. Для примера я буду описывать упрощенное взаимодействие с дизайнером на фрилансе.

Привет гиктаймс! Я решил опубликовать по частям свое руководство по материалам, используемым не только в электротехнике, но и вообще в технике, в том числе самодельщиками. С описанием, примерами применения, заметками по работе. Руководство написано максимально просто, и будет понятно всем, от школьника до пенсионера.

В этой части начинаем разбирать проводники — Серебро, Медь, Алюминий.



Добро пожаловать под кат (ТРАФИК)

Не каждый ардуинщик знает о том, что помимо стартового кода в setup и бесконечного цикла в loop, в прошивку робота можно добавлять такие кусочки кода, которые будут останавливать ход основного цикла в строго определенное заранее запланированное время, выполнять свои дела, затем аккуратно передавать управление в основную программу так, что она вообще ничего не заметит. Такая возможность обеспечена механизмом прерываний по таймеру (обычное дело для любого микроконтроллера), с её помощью в прошивку можно вносить элементы реального времени и многозадачности.

Еще меньше используют такую возможность на практике, т.к. в стандартном не слишком богатом API Arduino она не предусмотрена. И, хотя, доступ ко всем богатствам внутренних возможностей микроконтроллера лежит на расстоянии вытянутой руки через подключение одного-двух системных заголовочных файлов, не каждый пожелает добавить в свой аккуратный маленький скетч пару-тройку экранов довольно специфического настроечного кода (попутно потеряв с ним остатки переносимости между разными платами). Совсем единицы (тем более, среди аудитории Ардуино) решатся и смогут в нем разобраться.

Сегодня я избавлю вас от страданий.

Автор статьи — Алексей Маланов, эксперт отдела развития антивирусных технологий «Лаборатории Касперского»

Неоднократно слышал мнение о том, что блокчейн — это очень круто, это прорыв, за ним будущее. Спешу вас разочаровать, если вы вдруг поверили в это.

Уточнение: в этом посте мы поговорим о том варианте реализации технологии блокчейн, который используется в криптовалюте Биткойн. Существуют другие применения и реализации блокчейна, в некоторых из них устранены какие-либо недостатки «блокчейна классического», но обычно они построены на одинаковых принципах.