Как известно, в стандартной библиотеке C++ есть умный указатель с подсчётом ссылок std::shared_ptr; при желании можно думать о любом другом указателе с подсчётом ссылок, смысл дальнейшего от этого не изменится.

Как известно, при достижении счётчиком ссылок нуля вызывается deleter для указателя, управляемого shared_ptr-ом. По-умолчанию deleter просто применят оператор delete к указателю.

На что я хочу обратить внимание: работу по вызову деструктора и освобождению памяти делает тот тред и тот код, который сбрасывает счётчик до нуля. Если объект содержит другие shared_ptr в качестве своих полей, то часто освобождение этого объекта вызывает каскад освобождений памяти и приводит к задержкам в выполнении треда. Пример кода, могущий привести к таким каскадным высвобождениям, можно найти, например, тут https://bartoszmilewski.com/2013/11/13/functional-data-structures-in-c-lists/. Там односвязные иммутабельные списки, для предотвращения копирования всего списка при модификации, например, только головы, реализованы с использованием shared_ptr и могут иметь общие хвосты. Короче, с помощью shared_ptr реализуется persistence, я думаю вы знакомы с таким подходом.

Я тут подумал и пришёл к такой идее: завести threadsafe очередь для указателей (точнее, для структур, содержащих указатель + указатель на функцию, знающую что с этим указателем делать, ведь нам придётся стереть типы; но это уже детали) и при создании shared_ptr использовать custom deleter, который при вызове будет просто помещать указатель в очередь. Вызывать же деструкторы и освобождать память будет отдельный поток (или потоки?). Он будет брать очередной указатель из очереди и вызывать для него деструктор и освобождать память. Так мы избавим рабочие потоки от необходимости обслуживать каскады высвобождений памяти.

Я понимаю, что у этого подхода тоже будут performance penalties. Обычно куч всего несколько и при большом числе тредов каждая обслуживает несколько тредов. И если тред-освободитель будет освобождать память, он захватит лок у кучи, в которую могут лезть треды для выделения памяти. Там-то они и будут сталкиваться лбами. Это я понимаю. Но, в отличие от гарантированных длинных задержек, вызванных каскадным высвобождением памяти, тут задержки будут размазаны во времени или будут «распределены» между другими тредами, если они полезут выделять память в момент освобождения; или же, очень вероятно, эти задержки вообще не проявятся, если память выделять не полезут. Надо тестировать под различными нагрузками, заранее трудно сказать.

А что ЛОР про это думает? Дискас.

Решил потыкать Clang API. Допустим, я хочу пробежаться по AST, найти некоторые места, которые удовлетворяют определённым критериям и модифицировать их.

С первыми двумя пунктами проблем особых нет - я создал плагин для Clang, который создаёт ASTConsumer, переопределил метод HandleToplevelDecl, который по условию запускает RecursiveASTVisitor на некоторых элементах. Наконец, я нахожу места, которые хотел бы модифицировать. А вот с модификацией есть проблемы.

Допустим, я знаю, что интересующие меня ноды являются дочерними элементами CompoundStmt. Я могу переопределить TraverseCompoundStmt, вручную бежать по его детям и вызывать TraverseStmt для них. При этом visitXXX устанавливает флаг, который я потом проверяю. При выполнении условия я могу присвоить *it (где it - итератор из диапазона от stmt->child_begin() до stmt->child_end()) новый узел. В принципе это работает. Например, я могу создать пустой CompoundStmt и заменить узел на него. После этого я вижу с помощью objdump (а также по дампу AST), что соответствующие инструкции исчезают. Но что если я хочу более сложных изменений?

Например, я хочу создать метку (LabelStmt). И тут я натыкаюсь на проблему, что LabelStmt хочет LabelDecl, который в свою очередь хочет IdentifierInfo. Каким образом создать новый идентификатор и получить его IdentifierInfo? Если указать вместо нормального IdentifierInfo nullptr, то clang предсказуемо падает. Каких-либо нормальных конструкторов или статических методов для создания IdentifierInfo в самом IdentifierInfo я не заметил. Значит IdentifierInfo должен создавать кто-то другой. Но кто? Как вообще генерировать новые идентификаторы?

Я вижу ODROID-XU4 за $110 и BeagleBoard-X15 чуть дороже, первая с вентилем, а вторая вроде еще и не вышла в продажу.

Что купить поиграться? Будет как тонкий десктоп, сам линукс буду собирать на базе Void, там пакеты есть для ARMv6, ARMv7, еще будет тестовой управляющей платкой для cnc-станка.

Нужны нормальные cpu и gpu, памяти от 1 гига, идеально, чтобы был S/PDIF, но его в случае чего можно докупить поставить.

• biew - мощный hex редактор с дизассемблером (который, правда, заточен больше под x86/x86_64, на ARM'ах собирается с профилем «generic» и показывает мусор) и поддержкой редактирования текстов в однобайтных кодировках с полноценным предпросмотром (да, не только ASCII): http://saahriktu.org/hex/biew0.png , http://saahriktu.org/hex/biew1.png ;
• binarm (BINary ARMageddon) - командный hex редактор: http://saahriktu.org/hex/binarm.png ;
• binny - простой hex редактор: http://saahriktu.org/hex/binny.png ;
• bpe - командный hex редактор 1988-го года: http://saahriktu.org/hex/bpe.png ;
• bvi - Binary visual editor: http://saahriktu.org/hex/bvi.png ;
• chex и vex - простые hex редакторы, которые похожи как 2 капли воды: http://saahriktu.org/hex/chex.png , http://saahriktu.org/hex/vex.png ;
• dhex - hex редактор с встроенным калькулятором: http://saahriktu.org/hex/dhex.png ;
• file editor - простой hex редактор: http://saahriktu.org/hex/file_editor.png ;
• fm - простой hex редактор: http://saahriktu.org/hex/fm.png ;
• heme - простой hex редактор: http://saahriktu.org/hex/heme.png ;
• he - hex редактор с дизассемблером проца Z80: http://saahriktu.org/hex/he.png ;
• hexcurse - простой hex редактор: http://saahriktu.org/hex/hexcurse.png ;
• hexedit - простой hex редактор: http://saahriktu.org/hex/hexedit.png ;
• hexsed - аналог sed для бинарных файлов: http://saahriktu.org/hex/hexsed.png ;
• ht - мощный hex редактор с дизассемблером для кучи архитектур: http://saahriktu.org/hex/ht0.png , http://saahriktu.org/hex/ht1.png , http://saahriktu.org/hex/ht2.png ;
• hxd/unhxd - аналог xxd для бинарных файлов, но с полноценной поддержкой однобайтных кодировок (опять в дампе не только ASCII): http://saahriktu.org/hex/hxd_unhxd.png ;
• lde - а это не просто hex редактор, а hex редактор разделов файловых систем (ext2fs, minix и xiafs; есть минимальная поддержка msdos/fat и очень минимальная поддержка iso9660): http://saahriktu.org/hex/lde.png ;
• my1hexed - командный hex редактор: http://saahriktu.org/hex/my1hexed.png ;
• shed - простой hex редактор в один столбик: http://saahriktu.org/hex/shed.png ;
• tiah - простой hex редактор: http://saahriktu.org/hex/tiah.png ;
• tweak - простой hex редактор: http://saahriktu.org/hex/tweak.png ;
• vche - простой hex редактор: http://saahriktu.org/hex/vche.png ;
• zap - hex редактор 1987-го года, который повторяет поведение DEC'овской программы SIPP (Save Image Patch Program) для ОС RT-11: http://saahriktu.org/hex/zap.png ;

Ну и на десерт: ещё есть hexdumper под названием hex, ориганал которого был написан в 1983-ем году. И он тоже дампит не только ASCII: http://saahriktu.org/hex/hex.png .

Вопрос такой - как разрешить x11 приложению запущенному в docker создавать иконку в трее хост системы?

x11 пробрасывается в контейнер следующим образом:

XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth
touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run \
        --volume=$XSOCK:$XSOCK:rw \
        --volume=$XAUTH:$XAUTH:rw \
        --env="XAUTHORITY=${XAUTH}" \
        --env="DISPLAY" \
        myapp

Приложение, если важно - pidgin. WM - awesome. Локальный pidgin успешно рисует иконку в трее.

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

Под «restricted» подразумевается сборка с опциями:

CXXFLAGS="-fno-exceptions -fno-rtti -nostdinc++"

Все что мне нужно от обрезаных плюсов:
1) RAII
2) немного шаблонов
3) виртуальные функции
4) нэймспэйсы

В остальном, это будет сишка.

Линковаться будет только с сишными либами, в качестве стд либы будет APR.

Выбор стоит среди следующего:
- Boost test
- Google test
- CppUnit.

Есть какие-то особые преимущества у каждого из них? Целевые платформы x86 и arm.

Нужно качественно настроить подключение к OpenVPN чтобы при обрыве соединения трафик не шел мимо (т.е. запретить весь трафик в обход впн). Чтобы при старте системы CentOS 6 правила прописывались в iptables (и были там постоянно) и запускалось соединение с впн. IP адрес впн для сервера 123.123.123.123 порт 1234 покдлючение udp. Так же нужно исключить DNS Leak в обход впн и прочие протоколы.

Хочу познать 3D-графику. Интересуют самые основы, теория. Ну и практика, конечно же.

Я обычно против видео-уроков, в плане того, что касается программирования, но в этой нише, мне кажется они будут кстати.

Посоветуйте плиз хороших книжек, учебников, видео-уроков, etc. Думаю, Blender, прекрасно подходит для этой задачи. Если будут ещё какие решения - говорите, но главное, чтобы всё работало на GNU/Linux без всяких костылей, вроде Wine.

В ядре Linux обнаружена уязвимость, позволяющая повысить привилегии локального пользователя.

Причина уязвимости — race condition («состояние гонки») при обработке подсистемой управления памяти copy-on-write операций для частных маппингов памяти, доступной только для чтения. Непривилегированный пользователь может воспользоваться этим для повышения своих привилегий и получения возможности записи в память, размеченную только для чтения.

Патч, устраняющий уязвимость, просуществовавшую в ядре девять лет (начиная с Linux 2.6.22), уже представлен.

>>> Подробности

Вопрос такой: что (концептуально) мешает добавить в стандартную библиотеку что-то такое:

namespace std {

template <typename Container, typename UnaryPredicate>
bool all_of(const Container& c, UnaryPrecidate p) {
    return all_of(c.begin(), c.end(), p);
}

}

Да, я понимаю, что данная версия не такая гибкая как с итераторами, однако на моей практике 90% случаев используется для всего контейнера. А добавление таких функций позволило бы писать более аккуратный код:

std::all_of(container.begin(), container.end(), [] (const T &t) { return isOk(t); }
// vs
std::all_of(container, [] (const T &t) { return isOk(t); });

27 сентября 1983 года Ричард Столлман опубликовал изначальное объявление о Проекте GNU.

From CSvax:pur-ee:inuxc!ixn5c!ihnp4!houxm!mhuxi!eagle!mit-vax!mit-eddie!RMS@MIT-OZ
From: RMS%MIT-OZ@mit-eddie
Newsgroups: net.unix-wizards,net.usoft
Subject: new Unix implementation
Date: Tue, 27-Sep-83 12:35:59 EST
Organization: MIT AI Lab, Cambridge, MA

Free Unix!

Starting this Thanksgiving I am going to write a complete
Unix-compatible software system called GNU (for Gnu's Not Unix), and
give it away free(1) to everyone who can use it.
Contributions of time, money, programs and equipment are greatly
needed.

To begin with, GNU will be a kernel plus all the utilities needed to
write and run C programs: editor, shell, C compiler, linker,
assembler, and a few other things.  After this we will add a text
formatter, a YACC, an Empire game, a spreadsheet, and hundreds of
other things.  We hope to supply, eventually, everything useful that
normally comes with a Unix system, and anything else useful, including
on-line and hardcopy documentation.

GNU will be able to run Unix programs, but will not be identical
to Unix.  We will make all improvements that are convenient, based
on our experience with other operating systems.  In particular,
we plan to have longer filenames, file version numbers, a crashproof
file system, filename completion perhaps, terminal-independent
display support, and eventually a Lisp-based window system through
which several Lisp programs and ordinary Unix programs can share a screen.
Both C and Lisp will be available as system programming languages.
We will have network software based on MIT's chaosnet protocol,
far superior to UUCP.  We may also have something compatible
with UUCP.


Who Am I?

I am Richard Stallman, inventor of the original much-imitated EMACS
editor, now at the Artificial Intelligence Lab at MIT.  I have worked
extensively on compilers, editors, debuggers, command interpreters, the
Incompatible Timesharing System and the Lisp Machine operating system.
I pioneered terminal-independent display support in ITS.  In addition I
have implemented one crashproof file system and two window systems for
Lisp machines.


Why I Must Write GNU

I consider that the golden rule requires that if I like a program I
must share it with other people who like it.  I cannot in good
conscience sign a nondisclosure agreement or a software license
agreement.

So that I can continue to use computers without violating my principles,
I have decided to put together a sufficient body of free software so that
I will be able to get along without any software that is not free.


How You Can Contribute

I am asking computer manufacturers for donations of machines and money.
I'm asking individuals for donations of programs and work.

One computer manufacturer has already offered to provide a machine.  But
we could use more.  One consequence you can expect if you donate
machines is that GNU will run on them at an early date.  The machine had
better be able to operate in a residential area, and not require
sophisticated cooling or power.

Individual programmers can contribute by writing a compatible duplicate
of some Unix utility and giving it to me.  For most projects, such
part-time distributed work would be very hard to coordinate; the
independently-written parts would not work together.  But for the
particular task of replacing Unix, this problem is absent.  Most
interface specifications are fixed by Unix compatibility.  If each
contribution works with the rest of Unix, it will probably work
with the rest of GNU.

If I get donations of money, I may be able to hire a few people full or
part time.  The salary won't be high, but I'm looking for people for
whom knowing they are helping humanity is as important as money.  I view
this as a way of enabling dedicated people to devote their full energies to
working on GNU by sparing them the need to make a living in another way.


For more information, contact me.
Arpanet mail:
  RMS@MIT-MC.ARPA

Usenet:
  ...!mit-eddie!RMS@OZ
  ...!mit-vax!RMS@OZ

US Snail:
  Richard Stallman
  166 Prospect St
  Cambridge, MA 02139

>>> Подробности

Вечер, пятница.
Пока все приличные люди принимают стимулирующие вещества, мы творим...
Blender осваиваю не так давно, а данную модель делаю на заказ.

Карточка, которая всё это переваривает - GeForce GTX 750 Ti.
С работой справляется хорошо, и что особенно приятно, в linux, в отличие от ... при рендере система продолжает работать без фризов интерфейса. Это отлично, как раз можно успеть написать что нибудь полезное на Go, так как на нём это делается быстро.

• Distro: Fedora 24 x86_64
• DE: Xfce 4.12.3
• Fonts: Fira Sans 11 / Fira Mono 12
• WM Theme: Bluebird
• GTK2 / GTK3: Greybird / Zukitre
• Icon Theme: Elementary-Xfce-Dark

wallpaper

Основные рабочие инструменты: Blender, GIMP с парой плагинов и Sublime Text, который на скриншоте прячется.

Всегда использовал Xfce и всегда придавал ему подобный вид.

>>> Просмотр (1920x1080, 908 Kb)

Какая из программ лучше в качестве почтового клиента? Какая современнее, а какая застряла в 90-х?

Вот тут есть сравнение, Mu4e выигрывает с огромным отрывом

http://www.slant.co/topics/547/compare/~mu4e_vs_wanderlust_vs_gnus

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

Ъ

Async
Plugin management
Tests

!Ъ = https://github.com/vim/vim/blob/master/runtime/doc/version8.txt

NeoVim RIP?

Дискасс.

Возникла такая задача.

Есть USB приставка типа осциллографа, и программа под winXP, от его разработчика, которая запускает измерения, устанавливает частоту дискретизации, получает и отображает данные.

Ни исходников программы, ни описания протокола, по которому она с устройством общается, нет.

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

Нужно выяснить, как программа общается с устройством. Думаю использовать сниффер USB. Кто-нибудь имеет такой опыт? Какую лучше программу-сниффер использовать под XP? Как удобнее тестировать полученный таким образом результат под Linux?

Итак, я решил написать(или как вариант, собрать из кусочков) книгу-самоучилель по программированию, в которой бы не было глупых и нелепых ограничений на распространение. Однако копилефт я все же считаю приемлемым в данном случае. Общественным достоянием это не будет т.к. вполне могут найтись желающие использовать результат в своих проприетарных книгах, а проприетарные книги — плохо. Лицензия самого текста книги-учебника будет или Creative Commons Attribution-ShareAlike (что позволит без каких-либо проблем переиспользовать текст из википедии) или что-то вроде GNU Free Documentation License (без неизменяемых разделов естественно).

Лицензии всяких примитивных программок, написанных мной лично, будут вообще выложены под общественным достоянием, WTFPL или аналогичной лицензией т.к. являются тривиальными. Примерно вот так. Если я буду использовать чужие исходные тексты, они будут как включения, лицензируемые отдельно от всего остального. Проблем тут быть не должно.

Теперь к теме того, на кого книга ориентирована, какие начальные знания предполагаются, чему книга будет учить, какой первый ЯП взять и каков будет авторский самысел: С этим моментом я пока что не определился окончательно, и тут есть что обсудить. В частности, я не вижу особого смысла объяснять какие-то базовые понятия комбинаторики, об этом можно доступным языком прочитать из школьных учебников. Системы счисления(СС), перевод из одной СС в другую - вот это еще можно. One's и two's complement представления знаковых чисел — про это тоже можно написать. Если же человек не понимает комбинаторику, он ее быстро поймет на примере кода, который будет достаточно наглядно это показывать, и который всенепременно будет.
Пока что в качестве первого языка я склоняюсь к Си, и тому есть причины. Все прочие распространенные языки (кроме ассемблера, хотя его трудно назвать распространенным) не настолько близки к аппаратному уровню. Про нужность понимания на низком уровне написано тут http://russian.joelonsoftware.com/Articles/BacktoBasics.html https://habrahabr.ru/company/piter/blog/271347/ , не вижу смысла повторяться. Приведу лишь цитату:

«Просто плохой воркшоп попался», — скажете вы. Но на этом примере я хочу подчеркнуть более масштабную проблему: не изучив для начала C, программист оказывается лишен необходимых орудий, позволяющих понять, что именно происходит в используемой системе. Если вы — умный и пытливый питонщик, то вскоре докопаетесь до плотных пород языка C. Под этими горизонтами, скажут вам, «бойся драконов, костей и отладчиков». Соответственно, если вы не будете достаточно отважны и не проигнорируете предупреждений «да не берись ты за этот C», вы никогда не исследуете глубин, на которые можно забраться просто из любопытства.

Притом еще один важный момент: Си будет изучаться параллельно с ассемблером. Если речь идет об изучении ассемблера, необходимо четко зафиксировать то, на какой архитектуре это все происходит и в какой ОС. Так вот, ОС будет GNU/Linux а архитектура x86-64. Будут постоянно проводиться параллели между тем, что из себя представляет код на Си в текстовом виде, и тем, в какой текст на ассемблере его превращает компилятор. В связи с этим, первым делом будет рассказано о goto и конструкции if(условие) goto метка;. Про конструкции вида

if(условие)
{
  что-то_делаем;
}
else
{
  что-то_другое_делаем;
}

Первые хеллоуворды будут написаны вообще в особом стиле, без использования printf() и вообще без библиотеки Си; Будут использованы куски на ассемблере, которые делают системный вызов write и read, и с ними можно(нужно) будет линковаться, чтоб что-то вывести на экран. Будет рассказано и про printf естественно, но только когда будет совершенно четко ясно, что такое вообще va_list. Будет куча отсылок к драфту стандарта Си (недрафт почему-то платный). Будет так же рассказано про устройство ОС. В конце скорее всего будет дано задание сделать свою игрушечную ОС так что предполагается что человек к тому моменту должен уже отлично понимать всякие там связные списки, графы, очереди, спинлоки-аллокаторы свои уметь делать на асме при желании. Алгоритмы сортировки, обхода графов, хеш-таблицы, все это будет объяснено на языке Си, и плюсов вообще касаться я не буду.

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

Кроме того, после моей книги предполагается, что человек должен уметь заниматься такими ненужными (в GNU/Linux) на первый взгляд вещами, как крякинг, реверсинг, исправление ошибок в бинарниках, не обладая исходным текстом. Восстановление логики работы программы по дизасму. Ну и программирование в машинных кодах (без ассемблера, одним HEX редактором).

Как-то уж слишком дофига, не находите? Может быть не надо так глубоко во все это нырять? Жду предложений и критики по поводу того, что нужно, а чего не нужно писать. Возможно что я слишком много хочу.

cast ASM be_nt_all mister_VA

UPD: Программирование и отладка на C/ASM - Первые программы. Знакомство с C и ассемблером. Компиляция, линковка, код возврата. Вывод текста.

struct Foo;

impl Foo {
    fn get(&self) -> usize {
        42
    }
    
    fn set(&mut self, b: usize) {
    }
}

fn main() {
    let mut f = Foo;
    
    f.set(f.get());
}

results in

<anon>:15:11: 15:12 error: cannot borrow `f` as immutable because it is also borrowed as mutable [E0502]
<anon>:15     f.set(f.get());
                    ^
<anon>:15:5: 15:6 note: previous borrow of `f` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `f` until the borrow ends
<anon>:15     f.set(f.get());
              ^
<anon>:15:19: 15:19 note: previous borrow ends here
<anon>:15     f.set(f.get());
                           ^
error: aborting due to previous error
playpen: application terminated with error code 101

Почему? Здесь всё верно, иммутабельное заимствование f при вызове get() кончается до вызова set().

Сообщество Suckless, широко известное своей философией разработки ПО, а также набором программ, среди которых dwm, dmenu, surf, tabbed, st и другие, представило первый установочный образ дистрибутива Stali (static linux).

Проект интересен, прежде всего, множеством нестандартных архитектурных решений, отсутствующих в других дистрибутивах и воплощающих философию suckless на уровне ОС.

Основные отличия:

• статическая линковка всех программ;
• игнорирование FHS, предлагается иная иерархия директорий;
• установка и обновление при помощи git;
• замена coreutils и util-linux на sbase и ubase собственной разработки;
• использование musl в качества системной libc;
• отсутствие systemd, используется sinit (suckless init).

Разработчики отмечают более высокое быстродействие системы и низкое потребление памяти.

В дополнение к образу доступна пошаговая инструкция по установке.

>>> Подробности

Как многие уже знают, в Java решили ввести ключевое слово var. Драма разыгралась неслабая (хотя бы на хабре), но никто ещё не смог придумать случай, в котором этот var вообще имеет смысл использовать. Может, хотя бы здесь кто-то всё-таки сможет привести подобный пример?