Случай из реального проекта, код ~10-летней выдержки. Когда-то давно забыл добавить return в функцию, где имеется хитрая условная компиляция. Долгое время всё нормально работало, а сегодня вот пересобрал проект и поимел весёлых проблем. При проигрывании звука сегфолтилось, хотя вроде как в коде всё было нормально. Старые версии (собранные старым GCC) не сегфолтились. При отключенной оптимизации сегфолта тоже не было. Что тут можно ещё сказать? Спасибо Сталлману за gdb, сильно удивился когда увидел вызов якобы вырезанной функции в нём. Ну и главное: читайте и анализируйте Warning’и, господа! Минимальный пример:

$ cat dead_code.cpp 
// dead_code.cpp

#include <cstdio>

int stub_0();
int pxt_PlayWithCallback(int chan, int slot, char loop, void (*FinishedCB)(int, int));

int pxt_Play(int chan, int slot, char loop) {
#ifdef _PLS_NO_DEAD_CODE
	if (stub_0()) {
		fprintf(stderr, "!!!!! GOOD CODE !!!!!\n");
	}
#else
    return pxt_PlayWithCallback(chan, slot, loop, NULL);
#endif
}

int pxt_PlayWithCallback(int chan, int slot, char loop, void (*FinishedCB)(int, int)) {
	fprintf(stderr, "????? DEAD CODE ?????\n");
	return stub_0();
}

int stub_0() { return 42; }

int main(int argc, char *argv[]) {
	return pxt_Play(-1, 20, 0);
}

// OK:
$ g++ dead_code.cpp
$ ./a.out 
????? DEAD CODE ?????

// OK:
$ g++ -D_PLS_NO_DEAD_CODE dead_code.cpp
$ ./a.out 
!!!!! GOOD CODE !!!!!

// WTF?:
$ g++ -O2 -D_PLS_NO_DEAD_CODE dead_code.cpp
$ ./a.out 
!!!!! GOOD CODE !!!!!
????? DEAD CODE ?????
Segmentation fault (core dumped)

// WTF???:
$ g++ -O3 -D_PLS_NO_DEAD_CODE dead_code.cpp
$ ./a.out 
!!!!! GOOD CODE !!!!!
!!!!! GOOD CODE !!!!!
...
!!!!! GOOD CODE !!!!!
!!!!! GOOD CODE !!!!!
Segmentation fault (core dumped)

А ведь довольно интересный простор за этим может скрываться. Ну право ведь, забыли return проставить, компилятор же по-дефолту return 0 впихнёт, верно? А я в этом был уверен.

P.S.

// Имеется предупреждение по-дефолту, отсутствует ret в конце функции, провал и сегфолт.
$ gcc --version
gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)

// Предупреждение только с -Wall, ret в конце функции имеется, нет провала и сегфолта.
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)

P.P.S. поиграться с компиляторами:

C++: https://gcc.godbolt.org/z/7ne8PM
C: https://gcc.godbolt.org/z/b6vqbK

Может кто-нибудь из профи подробно объяснить механизм такого поведения? Спасибо.

См. комментарии и ссылки в теме.

@Scheduled(cron = "0 */30 * * * *")
public void deleteGayShit() {
    jdbcTemplate.update("UPDATE comments SET deleted='t' WHERE id IN (:list) AND not deleted", ImmutableMap.of("list",
        jdbcTemplate.queryForList("SELECT id FROM msgbase WHERE message ILIKE '%Владимир'")));
}

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

Вышел Kotlin 1.4
Ctrl+F «Владимир»
20 Results.

Есть ли какие-нибудь идеи, как бы уменьшить эту энтропию без игнорирования anonymous? На ум приходит лишь игнор на основе «стоп-слов».

Простенькое решение для тех, кому надоело и кому мешает этот бред и шум:

// SPDX-License-Identifier: MIT-0

// ==UserScript==
// @name     Fuck off, Vladimirs
// @version  1
// @grant    none
// @include  https://www.linux.org.ru/*
// @run-at   document-end
// ==/UserScript==

(function() {
    document.querySelectorAll('div.msg_body').forEach(function(element) {
        const arr = element.innerText.split('\n\n');
        const is_author_anon = arr.splice(-1).join().startsWith('anonymous ');
        const is_gay_vladimir = arr.join().replaceAll(".","").toLowerCase().endsWith('владимир');
        if (is_author_anon && is_gay_vladimir) {
            element.closest('article').style.display = 'none';
        }
  });
})();

Не тонет. По мотивам:

Что за ад на главной?
А можно все-таки убрать ЭТО?
Ссылки на некорректные сообщения (53) (комментарий)
Ссылки на некорректные сообщения (53) (комментарий)

А ведь Pinkbyte просил:

Означенная тема отправлена в неподтвержденные. Настоятельно прошу товарищей-модераторов ее обратно не подтверждать.

Кажется тут недавно американский барин санкциями ударил китайского холопа:

Fabless companies like Huawei HiSilicon are only responsible for chip design, and manufacturing needs to be handed over to foundries like TSMC. And TSMC has been affected by the US ban and can no longer provide OEM services for Huawei.

https://asia.nikkei.com/Spotlight/Huawei-crackdown/TSMC-halts-new-Huawei-orders-after-US-tightens-restrictions

https://sparrowsnews.com/2020/08/07/after-september-15-no-more-kirin-chips/

Собственно, куда пойдут наши разработчики Elbrus, ежели TSMC под давлением США откажается запекать в кремний наши плюшки? У нас там ничего окроме 90нм с 2014 года так и не смогли сделать? Французы которые нам помогали разбежались, кроме TSMC больше ни у кого и нет нужных мощностей для производства Elbrus’ов наверное…

Существуют ли уже в экосистеме Rust’а такие аналоги Web-фреймворков, как, например:

• Spring Boot (Java, Kotlin, Groovy)
• Grails (Groovy)
• Django (Python)
• Ruby on Rails (Ruby)
• Play Framework (Scala)
• и т. д.

То бишь All-in-One решения, в составе которых помимо проброса контроллеров имеется ORM к какой-нибудь там PostgreSQL базе данных, шаблонизатор HTML/CSS/JavaScript по типу того же Thymeleaf из Spring или Apache FreeMarker, ну и встраиваемый Web server по типу Tomcat/Netty/Jetty опционально.

В идеале будет круто если на выходе сайт (или хотя бы его логика) будет завёрнута в компактный бинарь, который будет deamon’изирован тем же systemd а сверху будет Nginx с proxy_pass. Тот же Spring Boot удобно вкомпиливает всё в единый JAR-файл, который можно деплоить просто на машину с установленной JRE и базой данных.

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

• Python/Django – убогая динамическая типизация со всеми её проблемами в виде кривого автодополнения абсолютно в любых IDE, ситуацию угрёбищный type-hinting, который даже не часть языка, а так просто нашлёпка сбоку, практически не спасает, ещё дрист километровыми traceback’ами на каждый чих.
• Java/Spring Boot – с типизацией всё ок, но NPE-проблемы, несколько отстающая от современных трендов стандартная библиотека, для которой нужно создавать Util-классы. Далее у Spring’а слишком много магии в чёрной коробке, ехала аннотация через аннотацию, тяжесть JVM-стека, да и сам Spring тяжёлый.
• Kotlin/Spring Boot – с типизацией всё ок, типы помогают избегать NPE в Kotlin-коде, но так как большинство библиотек это чистая Java, приходится всё рутинно обёртывать, стандартная библиотека вполне актуальная и удобная. Далее со Spring’ом не слишком хорошая интеграция, нужно там всё подпирать какими-то костылями-плагинами вроде all-open, тестирование тоже усложнено из-за совершенно других средств моккирования, несовместимых со Spring’овскими. Далее к проблемам JVM-стека и тяжести Spring’а добавляется ещё кучка зависимостей самого Kotlin’а и его плагинов интеграции.
• Groovy/Grails – динамическая типизация, тяжесть Spring Boot и платформы JVM. Слишком декларативненько для логики. Возможно это просто с непривычки так ощущается.
• Scala/Play Framework – Не слишком нравится синтаксис Scala, и Play Framework со сборщиком sbt мне показался тяжелее Spring Boot’овской связки с Gradle/Maven. Понятно, что можно выкинуть sbt и т. д., но как-то хочется посмотреть в сторону от JVM-языков.
• Ruby/RoR – тормоза, динамическая типизация, синтаксис на любителя (я приверженец C-like языков), ещё не понравился жирный начальный проект, который генерируется там через сборщик. Он изначально обмазан кучей JavaScript-библиотек вроде свистопердящей полоски прогресс-бара сверху страницы и т. д.

Ну не PHP же, прости-господи, брать для Web-разработки в 2020 году, верно?! Есть ещё вариант с Go/<чем-то>, но количество батареек у Rust’а, на мой взгляд, побольше.

В общем, посоветуйте популярные Web-фреймворки на Rust, с которыми можно поиграться для своих pet-проектов.

https://www.howtogeek.com/440147/did-linux-kill-commercial-unix/
https://habr.com/ru/post/473502/

Ъ: Yes, Linux did kill Unix.

Неплохой вброс.

Давайте перечислим те случаи в современном мире, где другие Unix-like OS, отличные от Linux-based (и очевидных macOS вместе с iOS), всё ещё используются.

Я начну.

1. Sony PlayStation 3 – The base operating used by Sony for the Playstation 3 is a fork of both FreeBSD and NetBSD called CellOS.
2. Sony PlayStation 4 – The operating system is Orbis OS, based on FreeBSD 9.
3. Nintendo Switch – According to the Nintendo Switch system software’s licensing information, code from FreeBSD kernel is utilized by Horizon.

На уровне слухов: некоторые банки до сих пор используют AIX / Solaris / HP-UX, но обычно находятся в стадии миграции с них на RHEL и OL.

На уровне слухов 2: некоторые товарищи поговаривают, что на АЭС’ах до сих пор работают QNX’ы. Краем уха слышал, что кое-где на российских предприятиях непрерывного цикла используют OpenVMS.

Прочитав новость «Код интерпретатора Perl официально перенесён на GitHub» я решил взглянуть на репозиторий Perl 5, который теперь уже находится на GitHub’е.

Удивительно, как трепетно и качественно его перенесли, сохранив не только абсолютно всю 32-летнюю историю проекта, но и багрепорты (Issues), патчи (PRs), релизы и ветки. Надпись «32 years ago» рядом с файлами вызывает улыбку.

Что ещё делать в этот унылейший пятничный вечер, когда на улице неприятно моросит дождь со снегом, а все дорожки погрязли в осенней слякоти? Правильно, красноглазить! Так что я ради эксперимента и интереса решил взять и собрать древний Perl на современной x86_64-машинке с gcc (GCC) 9.2.0 в качестве компилятора. Сможет ли такой старый код пройти проверку временем?

Чтобы было совсем уж аутентичненько и некрофильненько, я развернул виртуальную машину с голыми иксами и twm, который тоже родом из 1987 года. Кто знает, может быть Larry Wall писал свой Perl используя именно twm, так сказать bleeding edge technology того времени. Используемый дистрибутив – Arch Linux. Просто потому что в его репозитории есть некоторые полезные вещи, которые впоследствии мне пригодились.

( читать дальше... )

>>> Просмотр (1605x600, 55 Kb)

Надоело мне ковыряться с WordPress’ом и PHP. Чувствую, что забиваю гвозди электронным микроскопом. Слишком увесистый и избыточный он для меня. Я бы давно нагенерировал статических HTML-страничек, если бы не одно но – комментарии. А для них нужна БД, увы. Всякими сторонними сервисами вроде Discuss или IntenseDebate пользоваться не хочу и не буду. Во-первых, там куча подгружающейся Boilerplate-ерунды, а во-вторых, руководствуюсь принципом «всё своё ношу с собой».

Собственно, хочу соорудить нечто подобное тому, что у меня есть сейчас на WordPress’е:

https://exlmoto.ru/gish-droid/

Мне нужно немногое, пару служебных страничек, да посты в виде привычной всем ленты на главной. В постах нужна нормальная подсветка кода (наверное заюзаю highlight.js, альтернатив ему не вижу), поддержка Markdown для разметки и, собственно, система комментариев с какой-нибудь там Google Captcha, чтобы спамеры не пролазили. По вкусу ещё кастомные CSS для светлой и тёмной тем. Всякие там загрузчики Media-файлов и продвинутые редакторы статей мне не нужны.

Так вот, что лучше всего выбрать для подобного? Какой фреймворк и стек Web-технологий? Давно поглядываю в сторону Spring и Java, хочу попробовать использовать их, так как ЛОР, например, работает весьма отзывчиво.

На что бы вы перешли, если бы вам надоел WordPress? Буду рад выслушать любые советы.

Сегодня обновление убило мой Arch Linux на старом ноутбуке, чему я очень сильно удивился. Никогда такого не было и вот опять. Но ситуация довольно интересная, поэтому я оставлю описание этой проблемы и её решение на всякий случай на этом форуме. Вдруг кто придёт из поисковика, а у него такая же хрень окажется. Может помогу кому. Итак, фотография ошибки:

Kernel panic – not syncing: No working init found

Вечером я просто обновился привычной всем командой yaourt -Syua и перегрузился в Windows (стоит в дуалбуте рядом с Fedora и Arch Linux) по делам. Ладно, вру, перегрузился чтобы поиграть в Half-Life и Unreal Tournament ’99. Поиграл на славу, снова решил загрузиться обратно в Arch Linux — получил ситуацию, которая запечатлена на фотографии выше.

Сначала я подумал, что каким-то неведомым образом слетел Fedora’вский grub, так как именно он обеспечивает мне, так сказать, «дуалбут» в три операционные системы: Windows 10, Arch Linux и Fedora 29. Загрузился в Fedora, выполнил привычные команды для восстановления grub’а и обновления его конфигурации:

grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

Перегрузился снова, в меню grub’а выбрал Arch Linux — ситуация нисколько не изменилась. Тогда я решил, что при последнем обновлении слетели какие-то модули в ядре и из-за этого оно валится в панику. Снова загрузился в Fedora. Отмечу, что как же хорошо, что я её установил рядом и теперь не мучаюсь со всякими LiveUSB-флешками в подобных ситуациях, примонтировал rootfs от Arch Linux’а и с помощью скрипта arch-croot чрутнулся в него:

mount /dev/sda4 /mnt
./arch-chroot /mnt

Из лога пакетного менеджера /var/log/pacman.log я вычленил список пакетов последнего обновления, которые могли испортить мне ядро и initramfs:

upgraded device-mapper (2.02.184-3 -> 2.02.184-4)
upgraded lvm2 (2.02.184-3 -> 2.02.184-4)
upgraded virtualbox-host-dkms (6.0.4-4 -> 6.0.6-1)
upgraded virtualbox (6.0.4-4 -> 6.0.6-1)

При установке VirtualBox с помощью DKMS незаметно для пользователя собираются и устанавливаются некоторые модули ядра, на которые я и грешил, а потому переустановил эти пакеты заново:

yaourt -S device-mapper lvm2 virtualbox-host-dkms virtualbox
yaourt -S linux

На всякий случай само ядро, пакет linux, я тоже переустановил. Перезагрузился — ситуация нихрена не изменилась. Подумал, раз ядро паникует от init’а, может проблема в systemd? Его же всегда и все винят во всех бедах! В третий раз загрузился в Fedora, переустановил пакет systemd и перегенерировал initramfs:

yaourt -S systemd
mkinitcpio -p linux

Перегрузился, постучался в Arch Linux — проблема не ушла. Очень странно! Пришлось в четвёртый раз грузиться в Fedora и начать гуглить инфу по этой ошибке. Поисковый запрос «kernel panic not syncing no init found arch linux» сразу же привёл меня в тему на форуме Arch Linux, благодаря которой я и решил эту проблему: [SOLVED] Kernel Panic - not syncing. No working init found. Человек на том форуме столкнулся с похожей ситуацией.

Итак, восстановление работы поломанного Arch Linux’а и расследование почему так случилось, ибо проблемка-то и не очень уж тривиальная. Из темы на форуме Arch Linux, по ссылке выше тот человек перепробовал все действия, которые попробовал я и у него тоже не получилось сначала восстановить работоспособность системы. Потом знатоки на том форуме посоветовали ему выполнить команду:

pacman -Qkk filesystem

warning: filesystem: /usr/lib64 (No such file or directory)

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

Механизм возникновения проблемы

Итак, судя по сообщению пользователя Scimmia:

There’s been a number of people without /usr/lib64/. I’m guessing it’s because of a updated that was --force’d. Don’t do that.

В pacman’е имеется какой-то странный баг или поведение, когда при опции --force или --overwrite нарушается структура файловой системы, в частности, имеется вероятность неведомым образом снести симлинк /usr/lib64 или вместо него создаётся пустая директория, как у того человека с форума. Судя по логу, я действительно обновлял какой-то пакет из AUR’а с этой опцией из-за того, что установка ругалась на какие-то существующие файлы и не придал этому значение после. Но самый цимес в том, что обновлял я этот пакет целых три месяца назад и этот --force и вылетел у меня из головы.

Что интересно, само отсутствие /usr/lib64 похоже никоим образом не влияет на работоспособность системы. Если бы что-то отвалилось и перестало работать сразу после обновления и перезагрузки, то было бы легче догадаться в чём же именно дело. Но этот симлинк /usr/lib64 в rootfs каким-то странным и неведомым способом влияет на построение образа initramfs, а поэтому Arch Linux рассыпался только спустя три месяца (sic!), когда прилетело обновление VirtualBox, которое обновило свои модули ядра и потребовало перегенерировать initramfs, генератор которого видя отсутствие симлинка /usr/lib64 тупо взял и сгенерировал мне кривой образ, из-за которого ядро посыпалось в панику.

Решение проблемы

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

cd /usr/
ln -s /usr/lib/ lib64
mkinitcpio -p linux

После выполнения этих команд Arch Linux загрузился как ни в чём не бывало и продолжил нормально работать.

Вердикт

Вот такая довольно странная и нетривиальная проблема меня посетила, которая «занесла меч над головой» и целых три месяца никак себя не проявляла. Если честно, даже не знаю, не найдя подобную тему на форуме Arch Linux, смог бы я найти решение или нет. Скорее всего нет и тупо бы снёс раздел с Arch Linux’ом, перенеся важные файлы.

А чем вы занимались сегодня ночью?

https://github.com/Microsoft/calculator

У кого-то ещё остались сомнения что Microsoft новая корпорация Бобра?

Upd. Оказывается, приложение написано не на чистом C++, а на диалекте С++/CX — биндинге к .NET-платформе и Windows Runtime.

https://github.com/Microsoft/calculator/blob/057401f5f2b4bb1ea143da02c773ac18d1bb9a2e/src/Calculator/App.xaml.cpp#L101-L115

Что им мешало написать сразу на C# — загадка.

Неужели они переносили ядро калькулятора, его движок, из старой версии на WinAPI + C в эту новомодную на XAML и C++/CX?

P.S. Старая версия выглядела вот так, если кто-то не помнит: https://imgur.com/gallery/2GG5X

Upd. Ха-ха, моё предположение оказалось верным. Действительно, под капотом модный и современный калькулятор из Windows 10 работает на древнем движке код которого уходит в 90-ые годы.

https://github.com/Microsoft/calculator/tree/master/src/CalcManager/CEngine

Просто сравните названия файлов с теми названиями, которые имеются в утёкших исходниках Windows 2000:

http://esxi.z-lab.me:666/~exl_lab/screens/windows_calc_old_vs_new.png

Видимо этим и обусловлен выбор C++/CX вместо привычного C#.

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

https://ghidra-sre.org/

(Российские подсети заблочены, заходить с любого VPN)

Исходники сказали подвезут на GitHub чуть попозже. Ссылка для мониторинга: https://github.com/NationalSecurityAgency/ghidra

Новость на Opennet’е: http://www.opennet.ru/opennews/art.shtml?num=50260

Для тех, кто в танке, это может стать отличной альтернативой IDA Pro. Так как там из коробки есть возможность декомпилировать самые разные бинари в псевдо-код аля C, то есть, чем в IDA Pro занимается плагин Hex-Rays Decompiler.

Как и ожидалось, для запуска Ghidra потребовалась Java, JDK версии 11+; для сравнения – в IDA Pro используется (в настоящее время) библиотека Qt 5.

В Ghidra скорее всего используется SWT, но не ковырялся сильно. Возможно тупо AWT+Swing на стероидах. Внутри релиза от АНБ полно ошмётков от различных Eclipse-проектов. Главное окно программы, в котором можно создавать одиночные и совместные проекты, выглядит следующим образом:

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_main.png

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

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_cpu.png

Самый вкусный инструмент это, конечно же, «CodeBrowser». В отличие от IDA Pro, тут всё довольно инуитивно и кнопочек с окошечками гораздо меньше. Просто импортируешь файл, открываешь его в «CodeBrowser», соглашаешься на его анализирование и через некоторое время (как закончится анализ) уже можно смотреть псевдокод тех или иных функций:

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_codebrowser1.png

Непонятно для чего они захардкодили стиль виджетов «Solaris» от ныне почившего Sun Microsystems, с ужаснейшими половинчатыми скроллбарами. При анализе бинарника разработчики Gidra даже сделали весёлую анимацию, где красный дракончик кушает бинарный код вида 00010001010. Сотрудники АНБ не лишены чувства юмора. Так что ждём в ближайшем апдейте миниатюрных лошадей и миленьких глазастых девочек. Больше скринов:

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_codebrowser2.png
http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_codebrowser3.png

Кроме того, стоит отметить, что из коробки в Ghidra имеется полезный дизассемблерский инструмент, который называется «Version Tracking». Суть этого инструмента в том, чтобы реверс-инженеру было удобно переносить уже проделанную работу на новые версии программы. Отслеживать все изменения, которые сделали разработчики по паттернам, сдвигам и т. д.

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_versiontracking.png

Я попробовал разобрать бинарь ARMv7, либу ARMv8 из APK и dex’ированные Android’овские Java-классы. На всех вариантах показался более-менее осязаемый псевдокод. Кому интересно, можете сравнить с той же IDA Pro:

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_vs_idapro.png

Я ранее использовал IDA Pro для разбора бинарного файла ARMv7, который работал с камерой телефона. Проанализировав псевдокод я узнал правильный порядок инициализации и подсмотрел как работали с нужными мне проприетарными классами, на которых нет ни документации, ни заголовочных файлов. Я думаю, воспользовавшись Ghidra’ой, я бы тоже справился с этой работой.

Так что в полку интересных и полезных инструментов прибыло.

Update. Посмотрел внимательнее на структуру релиза и оказалось что там уже лежат архивы с исходным кодом на Java для большинства компонентов этой программы. Поковырялся в них и нашёл небольшой GUI-фреймворк базирующийся на AWT+Swing, по типу того, как оно сделано у платформы IntelliJ IDEA. Корней SWT не нашёл. Декомпиляторы выполнены в виде нативных исполнительных (соответственно платформозависимых) файлов; их исходников в этом релизе я не обнаружил.

Под Windows выглядит эта Ghidra более-менее цивильно. Видимо под неё и затачивалась. А вот под macOS, просто ужас:

http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_win.png
http://esxi.z-lab.me:666/~exl_lab/screens/ghidra_macos.png

Даже хуже, чем на Linux c Solaris-темой.

Было бы неплохо иметь на LOR’е страничку (по типу такой же, которая посвящена разметке Markdown), на которой будет публиковаться «отчёт о прозрачности» по типу Habr’а или того же GitHub’а:

https://habr.com/info/transparency/
https://habr.com/ru/docs/docs/transparency/
https://github.com/github/gov-takedowns/tree/master/Russia

Ведь РКН и прочие структуры власти периодически (из-за действий некоторых пользователей) обращаются к администрации LOR’а.

Насколько я помню, последний инцидент был совсем недавно.

Введение белых списков на ЛОР-е

// Ошибка: org.apache.commons.httpclient.URIException
// Invalid URL encoding

maxcom

P.S. peregrine приношу свои извинения, не хотел этого делать.

Сперва я хотел бы поздравить всех пользователей ЛОРа с наступающим Новым Годом. Счастливых и весёлых вам выходных в 2019 году!

Осенью из новости на Linux.org.ru я узнал о выходе бета-версии операционной системы Haiku и решил проверить, можно ли использовать её для каких-то своих повседневных нужд обычному рядовому линуксоиду.

( читать дальше... )

>>> Просмотр (1366x768, 75 Kb)

В преддверии официального релиза новой версии Windows 10 от Microsoft:

https://blogs.windows.com/windowsexperience/2018/11/14/announcing-windows-10-...

И в продолжение этой темы 😹

>>> Просмотр (1128x1509, 1095 Kb)

Они: https://vdesign.kde.org/who.html сгноили ключевого разработчика KWin, Martin'а Flöser'а, который вёл очень интересный блог и был одним из самых активных и цитируемых разработчиков KDE.

[Пруф]
[Подробности на русском]

Очень жаль, что разработчик не смог справиться со школьниками дизайнерами KDE.

Что теперь будет с портом KDE на Wayland, одному Патрику известно, учитывая то, что Martin по сути единственный кто там «шарил» и делал порт.

В официальном репозитории mozilla-central поддержка GTK+2 уже удалена, см. коммиты 0054a15e3c89 и 26fa4e61b9bc.

Релиз Firefox 59, в кодовой базе которого будет полностью отсутствовать возможность сборки с GTK+2, назначен на 23 марта этого года.

Источники: [1], [2]

Предлагаю обсудить столь знаменательное событие.

P.S. Летом 2016 года из кодовой базы Firefox (50-ая версия) тоже была окончательно удалёна поддержка Qt 5, которая к тому времени являлась достаточно сырой и которую пилили различные OpenSource-энтузиасты, например, из Jolla (внутренний браузер использует Qt и Gecko) и даже с нашего форума (см. r=romaxa, romaxa). Подробности можно посмотреть здесь, а обcуждение прочитать здесь.

Тема: Помогите собрать кошелек! (см. удалённые)

Мои сообщения, с удалением которых я не согласен:

1. www.linux.org.ru/forum/general/13805324/13805984/history

2. http://esxi.z-lab.me:666/~exl_lab/screens/deleted_post.png

Могу ли я их восстановить (отправить их заново в тему), чтобы пользователи, попавшие из поисковиков в эту тему, видели инструкции по сборке и могли скачать готовые пакеты?

Спрашиваю потому, что в последний раз, когда пользователь stevejobs попытался восстановить своё удалённое сообщение, он лишился всех звёзд и получил анонимный статус.

Мне нужно разрешение модератора(-ов). Спасибо.

Решил оценить готовность дистрибутива Fedora 25 Workstation для повседневного рабочего использования. А что может дать более объективную оценку, чем выполнение какой-нибудь интересной работы в этом окружении?

В качестве такой задачи я выбрал портирование компьютерной игры Gish на Android OS. Недавно я вспомнил про этот оригинальный 2D-платформер и захотел поиграть в него на своём Android-смартфоне. Игра была выпущена в далёком 2004 году, а после попала в самый первый сборник инди-игр Humble Indie Bundle, который собрал более одного миллиона долларов. В знак признательности поддержавшему их сообществу, разработчик игры Cryptic Sea объявил о том, что исходный код Gish'а будет открыт и выпущен под лицензией GNU GPL v2.0, на LOR'е даже писали об этом событии.

Скачав исходники игры, я открыл их в Qt Creator'е [Скриншот] и начал переносить платформер с библиотеки SDL на SDL2. Потом я импортировал проект в Android Studio и продолжил работу уже там. В целом на портирование я отводил по 2-3 часа каждый день после работы. Спустя месяц появилась первая релизная версия игры.

Итак, за один месяц использования GNOME 3 и Wayland я заметил следующие проблемы:

1. Огромные декорации развёрнутых окон на низких разрешениях экрана выглядят настолько ужасно, что я решил установить расширение Pixel Saver, которое исправило эту проблему, правда, почему-то не во всех приложениях. Например, с GNOME Terminal это расширение не работает.
   
2. В некоторых Qt-приложениях видны артефакты отрисовки (см. скрин Qt Creator'а выше, заголовки вкладок) из-за некачественной мимикрии. Работать это не мешает, но смотрится эстетически некрасиво.
3. Иногда (очень редко) заметны странные мелькания в нижней части экрана. Возможно это какие-то баги в Intel'овских драйверах или Mesa3D, потому что в том же sddm и KDE Plasma 5 я тоже наблюдал такое.
4. Иногда появлялись проблемы, связанные с различными анимациями окон, их закономерность я не смог выявить.

Теперь о хорошем. Интеграция Wayland и XWayland приложений в GNOME 3 практически бесшовная. В процессе использования я не выявил никаких проблем с отрисовкой, буфером обмена, переключением языка и снятием скриншотов. Ещё соглашусь с тем, что GNOME 3 в Wayland-сеансе работает плавнее и быстрее, чем в X.Org-сессии, видимо, сказывается полное отсутствие тиринга.

Таким образом можно подытожить следующее: Fedora 25 Workstation, несмотря на радикальную и быструю замену X.Org на Wayland, осталась вполне пригодным для работы дистрибутивом. Надеюсь, в Fedora 26 исправят отмеченные мной шероховатости, а софт, который сейчас использует XWayland, переведут на Wayland.

P.S. Если кому интересны результаты портирования Gish, дайте знать, выложу свои наработки в комментариях.

>>> Просмотр (1366x1536, 1837 Kb)

В далёком 2011 году был такой малоизвестный конкурс для гиков, который назывался RIOT Tag-Team Coding Competition. Целью мероприятия было увеличение количества Homebrew-игр на различных карманных игровых устройствах на базе ядра Linux: Caanoo, GP2X Wiz, Pandora и Dingoo A320. Отличительной особенностью этого конкурса являлось то, что игру необходимо было разрабатывать командой, а игры от «одиночек» не принимались. Именно поэтому двое российских программистов «старой школы»: Don Miguel и Quasist решили объединить свои усилия и начали работать над эксклюзивным игровым проектом для актуальных на тот момент времени консолей от фирмы GPH: GP2X Wiz и Caanoo.

На мероприятии авторы представили 3D-игру под названием Adamant Armor Affection Adventure, которая была выполнена в популярной тогда стилистике Minecraft'а, но имела кучу отличий от него. Всего за три месяца (sic!) ребятам удалось сделать очень многое: разработать достаточно производительный и отлаженный 3D-движок для embedded-устройств, создать десяток разнообразных карт и монстров, записать звуки и музыку, сделать несколько режимов игры, собрать всё это воедино и достойно выступить на упомянутом выше конкурсе, заняв почётное и призовое второе место.

Вдохновившись как самой игрой, так и успехом и самоотверженным трудом её авторов, я решил «воздать славу» нашей отечественной Linux-тусовке и, в свободное от работы время, попивая чаёк, начал портировать её на Android OS.

На скриншоте я представил окружение, в котором выполнил эту работу. На старом ноутбуке, который удобно везде с собой таскать и не страшно потерять, стоит Arch Linux c KDE Plasma 5. Я люблю дефолт, поэтому ничего особо не кастомизировал. Разве что в KWin добавил сокрытие декораций у максимизированного окна. На втором скриншоте Eclipse IDE и портируемая игрушка, которая запущена в эмуляторе устройства. Основная работа проводилась именно в Eclipse. К сожалению, в Android Studio поддержка NDK-проектов до сих пор оставляет желать лучшего. Кроме того, для внесения правок в код движка я использовал Qt Creator IDE: [Скриншот]. На переднем плане окно игры, которая собрана нативно под GNU/Linux. Если кому интересно, то в комментариях к этому посту я выложу все свои наработки.

>>> Просмотр (1366x1536, 1835 Kb)