Sergey Matveev [Mon, 30 Nov 2020 08:11:13 +0000 (11:11 +0300)]
Посмотрел "Ужин с придурком"
https://ru.wikipedia.org/wiki/%D0%A3%D0%B6%D0%B8%D0%BD_%D1%81_%D0%BF%D1%80%D0%B8%D0%B4%D1%83%D1%80%D0%BA%D0%BE%D0%BC_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1998)
Смеялся от души массу времени!
Причём главный герой ("придурок") в общем-то вызывает уважение.
Sergey Matveev [Mon, 30 Nov 2020 07:38:29 +0000 (10:38 +0300)]
Скучает по DTrace
https://utcc.utoronto.ca/~cks/space/blog/solaris/DTraceStillMiss
https://utcc.utoronto.ca/~cks/space/blog/solaris/DTraceVersusEBPF
Человек много лет проработавший с Solaris и DTrace недавно переехал на
GNU/Linux. И вот пишет что всё равно eBPF пока не такая клёвая и хорошая
замена DTrace, так как, как и в целом во всей Linux-экосистеме, в теории
всё можно делать тип-топ, а на практике всё сырое. Всё очень сильно
зависит от версий ПО, в противовес когда одна команда работает над всем
и сразу.
Sergey Matveev [Sun, 29 Nov 2020 08:54:44 +0000 (11:54 +0300)]
mpv коммит о locale
https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe
Я много где читал что POSIX locales это ужасная штука. Но сам не
сталкивался с ними, будучи программистом C. А тут вот в mpv есть коммит
объясняющий почему с ними всё так плохо. Насколько понимаю, тьму проблем
решает UTF-8.
stream_libarchive: workaround various types of locale braindeath
Fix that libarchive fails to return filenames for UTF-8/UTF-16 entries.
The reason is that it uses locales and all that garbage, and mpv does
not set a locale.
Both C locales and wchar_t are shitfucked retarded legacy braindeath. If
the C/POSIX standard committee had actually competent members, these
would have been deprecated or removed long ago. (I mean, they managed to
remove gets().) To justify this emotional outbreak potentially insulting
to unknown persons, I will write a lot of text. Those not comfortable
with toxic language should pretend this is a religious text.
C locales are supposed to be a way to support certain languages and
cultures easier. One example are character codepages. Back when UTF-8
was not invented yet, there were only 255 possible characters, which is
not enough for anything but English and some european languages. So they
decided to make the meaning of a character dependent on the current
codepage. The locale (LC_CTYPE specifically) determines what character
encoding is currently used.
Of course nowadays, this is legacy nonsense. Everything uses UTF-8 for
"char", and what doesn't is broken and terrible anyway. But the old ways
stayed with us, and the stupidity of it as well.
C locales were utterly moronic even when they were invented. The locale
(via setlocale()) is global state, and global state is not a reasonable
way to do anything. It will break libraries, or well modularized code.
(The latter would be forced to strictly guard all entrypoints set
set/restore locales, assuming a single threaded world.)
On top of that, setting a locale randomly changes the semantics of a
bunch of standard functions. If a function respects locale, you suddenly
can't rely on it to behave the same on all systems. Some behavior can
come as a surprise, and of course it will be dependent on the region of
the user (it doesn't help that most software is US-centric, and the US
locale is almost like the C locale, i.e. almost what you expect).
Idiotically, locales were not just used to define the current character
encoding, but the concept was used for a whole lot of things, like e. g.
whether numbers should use "," or "." as decimal separaror. The latter
issue is actually much worse, because it breaks basic string conversion
or parsing of numbers for the purpose of interacting with file formats
and such.
Much can be said about how retarded locales are, even beyond what I just
wrote, or will wrote below. They are so hilariously misdesigned and
insufficient, I can't even fathom how this shit was _standardized_. (In
any case, that meant everyone was forced to implement it.) Many C
functions can't even do it correctly. For example, the character set
encoding can be a multibyte encoding (not just UTF-8, but awful garbage
like Shift JIS (sometimes called SHIT JIZZ), yet functions like
toupper() can return only 1 byte. Or just take the fact that the locale
API tries to define standard paper sizes (LC_PAPER) or telephone number
formatting (LC_TELEPHONE). Who the fuck uses this, or would ever use
this?
But the badness doesn't stop here. At some point, they invented threads.
And they put absolutely no thought into how threads should interact with
locales. So they kept locales as global state. Because obviously, you
want to be able to change the semantics of basic string processing
functions _while_ they're running, right? (Any thread can call
setlocale() at any time, and it's supposed to change the locale of all
other threads.)
At this point, how the fuck are you supposed to do anything correctly?
You can't even temporarily switch the locale with setlocale(), because
it would asynchronously fuckup the other threads. All you can do is to
enforce a convention not to set anything but the C local (this is what
mpv does), or to duplicate standard functions using code that doesn't
query locale (this is what e.g. libass does, a close dependency of mpv).
Imagine they had done this for certain other things. Like errno, with
all the brokenness of the locale API. This simply wouldn't have worked,
shit would just have been too broken. So they didn't. But locales give a
delicious sweet spot of brokenness, where things are broken enough to
cause neverending pain, but not broken enough that enough effort would
have spent to fix it completely.
On that note, standard C11 actually can't stringify an error value. It
does define strerror(), but it's not thread safe, even though C11
supports threads. The idiots could just have defined it to be thread
safe. Even if your libc is horrible enough that it can't return string
literals, it could just just some thread local buffer. Because C11 does
define thread local variables. But hey, why care about details, if you
can just create a shitty standard?
(POSIX defines strerror_r(), which "solves" this problem, while still
not making strerror() thread safe.)
Anyway, back to threads. The interaction of locales and threads makes no
sense. Why would you make locales process global? Who even wanted it to
work this way? Who decided that it should keep working this way, despite
being so broken (and certainly causing implementation difficulties in
libc)? Was it just a fucked up psychopath?
Several decades later, the moronic standard committees noticed that this
was (still is) kind of a bad situation. Instead of fixing the situation,
they added more garbage on top of it. (Probably for the sake of
"compatibility"). Now there is a set of new functions, which allow you
to override the locale for the current thread. This means you can
temporarily override and restore the local on all entrypoints of your
code (like you could with setlocale(), before threads were invented).
And of course not all operating systems or libcs implement this. For
example, I'm pretty sure Microsoft doesn't. (Microsoft got to fuck it up
as usual, and only provides _configthreadlocale(). This is shitfucked on
its own, because it's GLOBAL STATE to configure that GLOBAL STATE should
not be GLOBAL STATE, i.e. completely broken garbage, because it requires
agreement over all modules/libraries what behavior should be used. I
mean, sure, makign setlocale() affect only the current thread would have
been the reasonable behavior. Making this behavior configurable isn't,
because you can't rely on what behavior is active.)
POSIX showed some minor decency by at least introducing some variations
of standard functions, which have a locale argument (e.g. toupper_l()).
You just pass the locale which you want to be used, and don't have to do
the set locale/call function/restore locale nonense. But OF COURSE they
fucked this up too. In no less than 2 ways:
- There is no statically available handle for the C locale, so you have
to initialize and store it somewhere, which makes it harder to make
utility functions safe, that call locale-affected standard functions
and expect C semantics. The easy solution, using pthread_once() and a
global variable with the created locale, will not be easily accepted
by pedantic assholes, because they'll worry about allocation failure,
or leaking the locale when using this in library code (and then
unloading the library). Or you could have complicated library
init/uninit functions, which bring a big load of their own mess.
Same for automagic DLL constructors/destructors.
- Not all functions have a variant that takes a locale argument, and
they missed even some important ones, like snprintf() or strtod() WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT
THE FUCK WHAT THE FUCK WHAT THE FUCK WHAT THE FUCK
I would like to know why it took so long to standardize a half-assed
solution, that, apart from being conceptually half-assed, is even
incomplete and insufficient. The obvious way to fix this would have
been:
- deprecate the entire locale API and their use, and make it a NOP
- make UTF-8 the standard character type
- make the C locale behavior the default
- add new APIs that explicitly take locale objects
- provide an emulation layer, that can be used to transparently build
legacy code without breaking them
But this wouldn't have been "compatible", and the apparently incompetent
standard committees would have never accepted this. As if anyone
actually used this legacy garbage, except other legacy garbage. Oh yeah,
and let's care a lot about legacy compatibility, and let's not care at
all about modern code that either has to suffer from this, or subtly
breaks when the wrong locales are active.
Last but not least, the UTF-8 locale name is apparently not even
standardized. At the moment I'm trying to use "C.UTF-8", which is
apparently glibc _and_ Debian specific. Got to use every opportunity to
make correct usage of UTF-8 harder. What luck that this commit is only
for some optional relatively obscure mpv feature.
Why is the C locale not UTF-8? Why did POSIX not standardize an UTF-8
locale? Well, according to something I heard a few years ago, they're
considering disallowing UTF-8 as locale, because UTF-8 would violate
certain ivnariants expected by C or POSIX. (But I'm not sure if I
remember this correctly - probably better not to rage about it.)
Now, on to libarchive.
libarchive intentionally uses the locale API and all the broken crap
around it to "convert" UTF-8 or UTF-16 (as contained in reasonably sane
archive formats) to "char*". This is a good start!
Since glibc does not think that the C locale uses UTF-8, this fails for
mpv. So trying to use archive_entry_pathname() to get the archive entry
name fails if the name contains non-ASCII characters.
Maybe use archive_entry_pathname_utf8()? Surely that should return
UTF-8, since its name seems to indicate that it returns UTF-8. But of
fucking course it doesn't! libarchive's horribly convoluted code (that
is full of locale API usage and other legacy shit, as well as ifdefs and
OS specific code, including Windows and fucking Cygwin) somehow fucks up
and fails if the locale is not set to UTF-8. I made a PR fixing this in
libarchive almost 2 years ago, but it was ignored.
So, would archive_entry_pathname_w() as fallback work? No, why would it?
Of course this _also_ involves shitfucked code that calls shitfucked
standard functions (or OS specific ifdeffed shitfuck). The truth is that
at least glibc changes the meaning of wchar_t depending on the locale.
Unlike most people think, wchar_t is not standardized to be an UTF
variant (or even unicode) - it's an encoding that uses basic units that
can be larger than 8 bit. It's an implementation defined thing. Windows
defines it to 2 bytes and UTF-16, and glibc defines it to 4 bytes and
UTF-32, but only if an UTF-8 locale is set (apparently).
Yes. Every libarchive function dealing with strings has 3 variants:
plain, _utf8, and _w. And none of these work if the locale is not set.
I cannot fathom why they even have a wchar_t variant, because it's
redundant and fucking useless for any modern code.
Writing a UTF-16 to UTF-8 conversion routine is maybe 3 pages of code,
or a few lines if you use iconv. But libarchive uses all this glorious
bullshit, and ends up with 3 not working API functions, and with over
4000 lines of its own string abstraction code with gratuitous amounts of
ifdefs and OS dependent code that breaks in a fairly common use case.
So what we do is:
- Use the idiotic POSIX 2008 API (uselocale() etc.) (Too bad for users
who try to build this on a system that doesn't have these - hopefully
none are left in 2017. But if there are, torturing them with obscure
build errors is probably justified. Might be bad for Windows though,
which is a very popular platform except on phones.)
- Use the "C.UTF-8" locale, which is probably not 100% standards
compliant, but works on my system, so it's fine.
- Guard every libarchive call with uselocale() + restoring the locale.
- Be lazy and skip some libarchive calls. Look forward to the unlikely
and astonishingly stupid bugs this could produce.
We could also just set a C UTF-8 local in main (since that would have no
known negative effects on the rest of the code), but this won't work for
libmpv.
We assume that uselocale() never fails. In an unexplainable stroke of
luck, POSIX made the semantics of uselocale() nice enough that user code
can fail failures without introducing crash or security bugs, even if
there should be an implementation fucked up enough where it's actually
possible that uselocale() fails even with valid input.
With all this shitty ugliness added, it finally works, without fucking
up other parts of the player. This is still less bad than that time when
libquivi fucked up OpenGL rendering, because calling a libquvi function
would load some proxy abstraction library, which in turn loaded a KDE
plugin (even if KDE was not used), which in turn called setlocale()
because Qt does this, and consequently made the mpv GLSL shader
generation code emit "," instead of "." for numbers, and of course only
for users who had that KDE plugin installed, and lived in a part of the
world where "." is not used as decimal separator.
All in all, I believe this proves that software developers as a whole
and as a culture produce worse results than drug addicted butt fucked
monkeys randomly hacking on typewriters while inhaling the fumes of a
radioactive dumpster fire fueled by chinese platsic toys for children
and Elton John/Justin Bieber crossover CDs for all eternity.
Sergey Matveev [Sat, 28 Nov 2020 08:30:16 +0000 (11:30 +0300)]
Настоящие трусливые подлые террористы
https://lenta.ru/news/2020/11/28/bhy/
https://lenta.ru/news/2020/11/19/austr_afgh/
То США просто так убило КСИРовца в Ираке в начале года (потом им
отомстили), то была речь "а не убить ли Асада?", теперь вот в Афганстане
уже другие англосаксы показывают свою суть, израиль вот засветился
подлым и трусливым убийством. Ещё раз убеждаюсь что Западный мир
(ангосаксы, евреи) это террористы номер один в мире, не говоря про
коварные и подлые бесчестные игры, подстрекательства и кучу лжи.
Sergey Matveev [Fri, 27 Nov 2020 15:23:59 +0000 (18:23 +0300)]
NoJS club
https://nojs.club/
Чтобы "вступить" в клуб, нужно отправить issue на Github... на котором
без JS не зарегистрироваться, насколько знаю (возможно какие-то действия
через внешние инструменты можно проделать).
Sergey Matveev [Fri, 27 Nov 2020 13:00:51 +0000 (16:00 +0300)]
Google CAPTCHA доказывают что ты американец, а не человек
https://shkspr.mobi/blog/2017/11/captchas-dont-prove-youre-human-they-prove-youre-american/
Вот-вот! Всё же мне приходилось натыкаться на CAPTCHA и я не раз
удивлялся некоторым "вопросам" которые явно мне чужды и я могу ответить
на них только по фильмам пиндосским. Там в комментариях и говорят про
примеры идиотизма.
Sergey Matveev [Fri, 27 Nov 2020 10:26:14 +0000 (13:26 +0300)]
В Python 3.8 предлагают использовать pax формат архива по умолчанию
https://bugs.python.org/issue36268
Кроме того, что сам GNU Tar не рекомендует GNU Tar, а pax, кроме того
что NetBSD/OpenBSD не поддерживают GNU Tar:
* For C/C++, Libarchive and GNU tar are the modern two heavy hitters,
and they both have supported it for a very long long. Modern version
of old-style bsdtar should, but if not then they don't support GNU tar
either. These are commonly used when needed with C/C++, or programmers
implement their own bespoke solutions.
* Libtar (C) does not, but it hasn't been updated for 6 years (and has
been in minimal maintenance mode for over 15) so I'm not sure its
really relevant anymore. Virtually any platform will also have one of
the previous.
* The major implementation for Java, Apache Commons Compress, added
support for both pax and GNU in its 1.2 version, back in 2011 (8 years
ago)
* R uses the system's tar executable (or bundled modern tar), so will
have the same support as that (i.e. any remotely modern system should
be compatible). Their documentation explicitly recommends against GNU
tar in favor of pax or ustar instead for portability:
https://stat.ethz.ch/R-manual/R-devel/library/utils/html/tar.html
* git-archive uses pax exclusively
* PHP supports ustar only, not pax or GNU; in that case pax is generally
the more compatible of the two extended formats
* The node-tar library, the apparent standard for Javascript, support it
* The standard tar package for Go supports it
* What seems to be the major current implementation for C#, SharpZipLib,
supports it
* Ruby has no apparent standard implementation; a few third-party
libraries have a mix of support
Sergey Matveev [Thu, 26 Nov 2020 20:26:22 +0000 (23:26 +0300)]
Greg Kroah-Hartman использует Filco клавиатуры и трэкбол
https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroahhartman_linux_kernel_developer_ama/
Бесполезный факт, но здорово, что настоящие профи программисты все как
один за тактильными клавиатурами. И трэкболы очень в ходу.
https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/cmi2khj/
А ещё ему больше нравится Go, чем Rust.
Узнал про "WET" (Write Everything Twice), не слышал прежде. А вот DRY я
сам постоянно использую слово.
Sergey Matveev [Thu, 26 Nov 2020 15:57:07 +0000 (18:57 +0300)]
Впервые начал генерировать .do другим .do
Для тестов нужны данные из ASN.1 структуры. Достать их можно по
длине/смещению, которые можно узнать распарсив бинарь. Но для парсинга
нужен Python, PyDERASN. Не заставлять же их ставить. Поэтому .do.do файл
является исполняемым, с Python shebang-ом, который выплёвывает dd
строчку с нужными seek/count параметрами. Уж такую мелочь для
неизменного входного файла можно и закоммитить.
Sergey Matveev [Thu, 26 Nov 2020 09:29:23 +0000 (12:29 +0300)]
Github сделает тёмную тему
https://habr.com/ru/news/t/529996/
Вот он современный web во всей красе! Вместо того, чтобы выдавать
нормальную структурированную информацию (HTML просто) и каждый сам бы
себе настраивал как *ему* хочется чтобы всё отображалось, все будут
терпеть и ныть 7 лет. У меня в броузере Xombrero даже из коробки можно
нажать кнопочку "s" и цвета будут что-то типа инвертированы (точнее
какой-то CSS применяется, не вдавался в подробности) и всё ставится
тёмным и красивым. А "S" глобально это включает, чтобы мне на каждую
страницу не надо было жать "s".
Sergey Matveev [Wed, 25 Nov 2020 21:53:23 +0000 (00:53 +0300)]
Интереснейшая история Фортран, Алгол, Ада, Паскаль
https://habr.com/ru/company/dataart/blog/529916/
Андрей Терехов (завкафедрой системного программирования Матмеха СПбГУ,
профессор, доктор физмат наук) рассказывает о том как в СССР проникали
всякие зарубежные языки.
Sergey Matveev [Tue, 24 Nov 2020 21:40:30 +0000 (00:40 +0300)]
Как находятся баги? KRACK
https://cryptologie.net/article/511/how-do-people-find-bugs/
https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
Интересная подборка того, что даже в формально верифицированных
протоколах всё равно могут быть ошибки и несостыковки. Ох уж эти люди...
In modern world, bugs find you.
I don't find bugs -- I write them.
А вторая статья про KRACK атаку на 802.11i. Мэтью Грин так лестно
отзывается об IEEE! И по сути это их огромный fail что такое кривое
получается в плане безопасности.
Sergey Matveev [Tue, 24 Nov 2020 17:43:16 +0000 (20:43 +0300)]
Свой CA
В Паутине тьма примеров как сваять свой CA на основе OpenSSL команд. Я
считаю OpenSSL команды чистым садизмом и издевательством над человеком.
Как и код их библиотеки и документации. Привожу пример как можно сделать
свой CA на certtool из GnuTLS-а:
Этого достаточно чтобы софт с выпущенными сертификатами работал. Почему
ECC (ECDSA)? Потому что компактно, быстро, эффективно. На помойку тех
кто умеет только RSA. Я бы конечно предпочёл EdDSA, но это точно далеко
не всеми поддерживается.
Sergey Matveev [Tue, 24 Nov 2020 17:22:43 +0000 (20:22 +0300)]
Бесплатных то CA сколько развелось!
https://habr.com/ru/company/globalsign/blog/529698/
https://scotthelme.co.uk/introducing-another-free-ca-as-an-alternative-to-lets-encrypt/
https://docs.https.dev/list-of-acme-servers
Только ни одного вне США. ZeroSSL написали что австрийский, но он не
корневой CA, а подписан пиндосами, да и даже свой сайт у него за
Cloudflare. Активно выпиливали все зарубежные, теперь плодят своих, мол
выбор и альтернатива.
Sergey Matveev [Tue, 24 Nov 2020 09:02:57 +0000 (12:02 +0300)]
mpv и SDL
С предыдущего поста ради интереса попробовал всё же новую версию с SDL
звуком собрать. Управлять выходным устройством не нашёл как, но можно
делать sysctl hw.snd.default_unit и глобально его менять для всей
системы. Для моих задач это подходит, ибо я или только музыку слушаю,
или только на монитор звук вывожу или, лёжа на диване, вывожу в колонки
ноутбука. Обновляться не собираюсь, но в принципе жить можно. Хотя и
появляется абсолютно ненужная прослойка в виде SDL, но вроде это не
плохой софт, даже быстро собирается.
Sergey Matveev [Tue, 24 Nov 2020 08:13:10 +0000 (11:13 +0300)]
mpv и OSS/sndio поддержка
https://github.com/mpv-player/mpv/commit/71d218eae4b4d93ada34ff74906f71ad359c84bc
https://github.com/mpv-player/mpv/issues/8296
С выходом нового релиза mpv, в котором уже давно
(ed22279730f95d93e57f140807f664ba2bbbaa92) выпилили две единственные
нормальные звуковые системы. Люди начали отписываться, мол, верните. Ну
посмотрим что из этого выйдет или всё же кто-нибудь найдётся кто вернёт
их снова. Linux экосистема уже давно стала не сильно отличаться от
Windows (сложностью, непонятностью, дерьмовостью, архитектурой абсолютно
чуждой хакерской и Unix-way), а теперь ещё вот в который раз видно что
люди в ней считают что никого в округе больше нет (как и Windows
когда-то всегда считал). Причём в самом Linux как нету ничего близкого к
OSS/sndio, так и нет, но страдают теперь все пользователи mpv. Их право
конечно, они никому ничего не должны, а я как программист тоже понимаю
как сложно бывает поддерживать сильно разношёрстные вещи. Пока сижу вот
на каком-то там коммите mpv. В принципе то всё устраивает полностью.
Ведь даже mplayer мнооого лет вообще не обновляется и мне его тоже
хватало, только обновляй всякие libav/ffmpeg.
Sergey Matveev [Mon, 23 Nov 2020 19:14:43 +0000 (22:14 +0300)]
Little Big Aventures в ScummVM!
https://www.scummvm.org/news/20201122/
ScummVM снова (вслед за 592c8e4c08c63dae747cae59d46603240c1b8109)
умудряется приятно удивлять и они добавляют TwinEngine, позволяющий в
легендарные LBA поиграть! Я какое-то и прохождение смотрел и начитан про
LBA много, но играть в него так и не вышло: похоже я совсем в аркады не
умеют -- в лучшем своём прохождении я только смог выбраться из тюрьмы, в
самом начале игры, а дальше всё убивают и убивают. В прохождениях видел
что прыткость и реакция это всё что надо. Но, хоть в FPS-ах у меня было
очень неплохо всегда, а тут не получалось.
Sergey Matveev [Mon, 23 Nov 2020 13:27:36 +0000 (16:27 +0300)]
Мой Atom блога теперь отдаёт HTML
Раньше был <content type="text">, но его "\n" автоматически
escape-ились и это похоже никто не поддерживал. Сам я про эту проблему
знал, но всё откладывал, а потом и просто забыл. Сейчас делаю
type="html" с текстом обёрнутым в <pre>. В newsboat и
rss2email+mutt+lynx вроде всё показывает теперь корректно. А ещё в RFC
обратил внимание что type="text" вообще MAY быть при показе
отформатирован как угодно, забив на все whitespace-ы и переводы строк.
Так что изначально type="text" было некорректным решением.
Sergey Matveev [Mon, 23 Nov 2020 12:33:33 +0000 (15:33 +0300)]
А Вернер Кох любит HTML почту
https://lists.gnupg.org/pipermail/gnupg-users/2020-November/064364.html
... потому что простое procmail правило избавляет его от спама! :-)
Он и раньше был трушным: e86a4dc7dc0311d5da5916ea5adeb777b50d96a7 но
сейчас совсем крут. А ведь стоит, пускай не удалять, но в spam помещать
всё где HTML! Иногда всё же умудряются находится люди которые шлют в HTML.
Sergey Matveev [Mon, 23 Nov 2020 09:51:06 +0000 (12:51 +0300)]
Посмотрел "Полуночную жару"
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%83%D0%BD%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D0%B6%D0%B0%D1%80%D0%B0_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1967)
Отличный фильм! Но я оказывается уже слушал радиоспектакль по книге по
которой снят этот фильм. Так что о сюжете уже в курсе.
Sergey Matveev [Sun, 22 Nov 2020 17:26:05 +0000 (20:26 +0300)]
Ускорение запуска bash
https://work.lisk.in/2020/11/20/even-faster-bash-startup.html
Не только я обеспокоен задержками при запуске базовых простых вещей,
типа калькулятора. Помню что тоже мерил и zsh и vim время запуска всяких
штук, оптимизируя.
Sergey Matveev [Sun, 22 Nov 2020 15:55:12 +0000 (18:55 +0300)]
Каганов заценил современный русский хип-хоп
http://lleo.me/dnevnik/2020/11/22_1
Моргенштерн, Элджей, Макс Корж, Егор Крид:
* это всё попса, а не хип-хоп
* раскрутка искусственным шумом
* петь не умеют, слова... без комментариев
Sergey Matveev [Sun, 22 Nov 2020 15:27:18 +0000 (18:27 +0300)]
Фишки современных эмуляторов терминала
https://www.youtube.com/watch?v=9DgQqDnYNyQ
* Unicode/UTF-8. Ими в видео показывают как отображают прям иконки
директорий например. Ну тут вопрос шрифтов только, по моему. Выглядит
интересно, но по сути даже в примере видео я ориентируюсь по цвету --
ну никто же не будет вглядываться в иконку
* Лигатуры -- тоже вопрос шрифтов. Кому-то нужны/нравятся
* SGR ANSI коды. Ну вот это точно может ощутимо помогать визуально.
st поддерживает конечно же
* Поддержка мыши -- а вот это абсолютное зло! Готов крушить и громить
когда я не могу выделить кусок текста, ибо какая-то сраная программа
перехватываешь мышь. Нафиг мне терминал если я не могу выделить в нём
что-то или вставить? st кстати поддерживает проброс мышки
* OSC коды -- общение с буфером обмена, выставлением title-ов окон. Да,
это must-have. st конечно же держит. Для lynx даже писал патч чтобы он
выставлял название окна/сайта. В vim это тоже нужно выставлять чтобы и
в tmux показывалось нормальное название tab-а
* bracketed paste mode -- если этого нет, то терминал просто неюзабелен.
Но меня удивляет как мало людей знает про эту штуку, насилуя себя
какой-нибудь ручной работой с set paste в Vim
* 24-бит цвет. Боюсь что подобное я даже отключаю, например в Vim. Ибо
мне нужны хорошие сочные яркие цвета. default цветовые схемы на 24-бит
-- блёклые. st поддерживает
* поддержка отображения bitmap графики (Sixel). Вот это st не держит, да
и вообще не много кто. Под вопросом насколько это удобно, но что-то не
слышал чтобы люди особо это использовали. Ну и тут много разных
несовместимых реализаций и плохая совместимость с другим софтом. Но
даже в видео у человека ооооочень медленно отображаются картинки, что
для меня точно было бы не юзабельно
Как минимум не сказали про то как мышкой, разными кликами, можно
выделять слова или предложения. А ещё всякий XIM ввод (хотя я этим
никогда не пользовался). А ещё некоторые позволяют производить какие-то
действия над выделенным текстом.
Sergey Matveev [Sun, 22 Nov 2020 15:22:51 +0000 (18:22 +0300)]
Снова Туктамышева крута
https://www.championat.com/figureskating/article-4195009-figurnoe-katanie-gran-pri-2020-2021-proizvolnaja-programma-zhenschiny-muzhchiny-onlajn-transljacija-21-nojabrja-2020.html
Оказывается уже как два года (9b57fe2c57650546ae8b55de278cda720a92d6f4)
я если и вижу упоминание Туктамышевой, то обязательно зайду в новость
посмотреть на фотографии с ней. Посмотрел на других в этой статье: ну
посмотрел и посмотрел. А вот Туктамышевой налюбоваться не могу.
Sergey Matveev [Sun, 22 Nov 2020 15:10:38 +0000 (18:10 +0300)]
Посмотрел "Не/смотря ни на что"
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5/%D1%81%D0%BC%D0%BE%D1%82%D1%80%D1%8F_%D0%BD%D0%B8_%D0%BD%D0%B0_%D1%87%D1%82%D0%BE
Местами ускорял просмотр, ближе к концу, но фильм понравился. Хотя в
целом я и не одобряю главного героя что он на такой важной работе врал и
не говорил о слепоте. Ну да, смог достичь и даже в таком состоянии
успехов, но ведь это же и заслуга кто ему помогал. Это же просто тупо
опасно для жизни и своей и окружающих. Как и героиня с ребёнком тоже
сказала ему в лицо что доверила своего ребёнка тому, кто точно не мог бы
за ним приглядывать. Да, если бы он говорил о своём состоянии, то работы
ему не видать. Только если бы он не представлял опасности для себя и
окружающих (а покалечив себя, работодателю придётся несладко), то я бы
промолчал, мол ложь во благо.
Sergey Matveev [Sun, 22 Nov 2020 12:50:00 +0000 (15:50 +0300)]
Снова доработки goredo, redo-stamp и хэширование
Вчера обнаружил что при REDO_NO_HASH на самом деле не работает
redo-stamp поведение. Ничего не падает, но цель остаётся изменённой,
даже если stamp остаётся прежним.
Сам по себе redo-stamp у меня был некрасивым хаком: если во время
определения OOD (out-of-date) цели мы понимаем что она со штампом, то в
конце, если она требует пересборки, запускаем выполнение этой цели,
прямо внутри OOD функции, рекурсивно вызываемой. Это мешало
распараллеливанию -- одна проблема. По сути я делал изменение порядка
выполнения целей и зависящие штампа (а это так или иначе связанные с
redo-always целями), выполняя их раньше, а дальше, благодаря хэшам (на
штампам!), остальные считали что цель не изменилась.
Отключение хэшей приводит к тому, что цели всё равно, не смотря на штамп
пересобираются, ведь ctime то поменялся. А алгоритм понимания OOD цели
взят из redo-c и предельно прост: прочитать .dep, пройтись по каждой
записи в нём, если она имеет .dep, то рекурсивно вызвать OOD на неё.
Просто "сверху вниз" идём и смотрим не устарел ли кто. С отключением
хэшей приходится из-за штампов *заранее* понимать является ли цель
-always или -stamp, а также добавлять состояние о том что в *текущей*
сборке штамп не изменился. Это в итоге у меня заработало, есть коммит,
но это сущий ад уродства и хака, когда мы не просто спускаемся, а
заранее читаем и узнаём про зависимость. Плюс я ещё не добавлял
распараллеливание выполнения out-of-order always/stamped целей (так как,
скорее всего, такие цели на практике будут лёгкими (определение
переменных окружения, версии какой-нибудь), то это не создаёт проблем.
Но в общем случае оно страшно.
Если что-то всё слишком усложняется и добавляется хак то тут, то там
(например просасывание текущего stamp чтобы понять, в момент вызова
redo-stamp, остался ли он прежним), то что-то делается не так. Моя не
работающая версия с redo-stamp по сути делала только одно, давая нужное
и ожидаемое на самом деле поведение (поэтому я был уверен что оно
работало) -- меняла порядок выполнения целей, а дальше хэши делали
нужное поведение.
А не хотелось бы пользователю прописать redo-stamp в каждой цели? В
идеале хотелось бы, поэтому redo-stamp выглядит полнейшим уродством.
Теперь я яростно против него, видя как он на самом деле всё усложняет.
А что говорит apenwarr?
https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps
Могут быть проблемы с пустыми файлами. Так как их хэши всегда остаются
прежними и цель будет считаться всегда свежей. Это единственный аргумент
который я принимаю... в общем случае, если бы не тот факт, что и redo-c
и apenwarr/do и apenwarr/redo и goredo при отсутствии stdout выхлопа не
создают файл, а отсутствие файла является признаком всегда протухшей
цели. На практике из-за этого нет никаких проблем и с желанием делать
пустые файлы, которые не устаревают (например создание какого-нибудь .rc
в котором реально нет никаких команд, выставляющих флаги), и с желанием
делать псевдо-цели "агрегаты". Если есть желание не делать выхлоп, но
всё равно иметь stamp -- ну так сделать запись в файл какого-нибудь хэша
от нужных данных, а файл не использовать. "Родное" хэширование
(go)redo(-c) из-за малого объёма данных будет супер лёгким. Поэтому на
практике это не проблема, повторюсь. Но она требует полноценной
поддержки и работы с stdout захватом и $3 файлом, чего некоторые
реализации не делают, считая захват stdout вредом. Ну вот и получается:
если забить на оригинальное предложение DJB с stdout/$3 -- имеем кучу
проблем и негибкостей, например при постоянной проверке хэшей. Сами
дураки что отказались -- сами же себе создали проблем. Те кто создают
пустые файлы при отсутствии stdout (я уверен что автор redo-c плохо
подумал, влив чей-то глупый pull request в последних коммитах) -- сами
же себе создали невозможность создания агрегатов и постоянно протухающих
целей. Короче, DJB всё предложил как никогда правильно и корректно!
Что ещё apenwarr говорит на тему "почему бы не всегда делать хэши?"
* It makes it hard to force things to rebuild -- просто touch-ем
действительно не выйдет. Но есть redo (не -ifchange, который по
умолчанию делает force)
* Targets that are just used for aggregation -- это снова пустые файлы.
С ними нет проблем, так как они будут отсутствовать
* Calculating checksums for every output file adds time to the build --
учитывая скорость современных быстрых хэшей (BLAKE2/3, Skein), даже
просто на современных файловых системах всегда все данные хэшируются
(ZFS). В теории оно конечно добавляется время, так как оно в любом
случае что-то делает/занимает на CPU, но так ли это увеличивает время,
чтобы жертвовать простотой софта и удобством пользователя не заставляя
его писать каждый раз и думать где нужен redo-stamp? Сколько времени
будет сэкономлено потому что он не поставил redo-stamp, а выполнение
какой-нибудь сверх лёгкой цели типа "echo ${GO:-go}" займёт ГОРАЗДО
больше времени, так как нужно запустить дочерний sh процесс. Я убеждён
что на практике это совсем не аргумент. Ну и речь же не про абсолютно
всегда проверку хэша, а если, например, только ctime поменялся --
поэтому если на диске будет лежать гигабайтный tarball, который просто
лежит, то хэшироваться он не будет при проверке OOD
* Building stuff unnecessarily and then stamping it is much slower than
just not building it in the first place, so for almost every use of
redo-stamp -- не понял к чему, ведь как-раз stamp-ы наоборот позволяют
не собирать unnecessarily. Или это к тому, что проще собрать "echo
${GO:-go}" чем проверять хэш? Возможно только если процесс хэширования
очень медленный, что не правда на практике
* To steal a line from the Zen of Python: explicit is better than
implicit. Making people think about when they're using the stamp
feature. -- Нет уж, снова не согласен и автор противоречит себе.
Почему же ifcreate/ifchange implicitly ставятся? А как же Zen?
Потому что это точно удобно будет всем, оно уменьшает нагрузку на
пользователя, помогает ему (а инструмент должен помогать!). Checksum-ы
и желание делать redo-stamp абсолютно всегда, если создаётся $3 --
абсолютно нормально и адекватно
* djb's (as yet unreleased) version of redo doesn't implement checksums
а вот это не правда, ибо я сам помню что речь про checksum-ы я видел в
его статьях. Там речь вообще только про них и была, никаких
ctime/mtime/whatever
Как с самого начала мне не нравились ВСЕ аргументы apenwarr, так сейчас
и подавно. Сейчас на практике я вижу НАСКОЛЬКО это всё усложняет и
уродует. Проблем с aggregation targets и пустыми файлами нет, если не
забивать на stdout и не создавать пустые файлы когда пользователь это
явно не попросил (touch $3). Мне кажется, apenwarr/redo просто борется с
тем, что в Python это всё медленно, хоть сами хэши и на C, но
просасывать данные нужно через Python.
Поэтому я решил выпилить возможность отключения хэшей и выпилил всё
уродство с redo-stamp. Сама команда и даже запись в .dep остались, но
ни на что не влияют. Однако порядок выполнения целей теперь хаотичен,
как и был и как и должен был быть. И проблема в том, что определение OOD
целей, множества целей, может происходить задолго до того как
always цель выполнится. Если поставить маленький уровень параллелизма,
неспешно рассматривая OOD каждой задачи и выполняя их, то всё неплохо. В
противном случае, всё работает, но много целей будут выполнятся потому
что OOD решил что они протухли, ибо always цель ещё не выполнилась. В
общем, проблема (чтобы всё красиво работало: например видя изменение
пути к AR команде, только .a пересобрался, а другие даже не пытались бы)
только с порядком выполнения зависимостей. И проблема и вся эта головная
боль только и только при наличии redo-always зависимостей, что даже
чисто теоретически говорит что раз always, значит протухший всегда,
значит все кто от тебя зависят -- тоже автоматом протухшие, всё честно.
И если следовать принципу apenwarr -- уже лучше пересобрать, чем что-то
недособрать, то можно и вообще ничего не делать.
Но я решил всё же хоть как-то но побороть и оптимизировать это всё.
Сначала я нахожу все always зависимости, попутно полностью собирая
информацию о том как кто на кого влияет. В любом случае. .dep файлы мы и
так читаем, поэтому тут overhead на ОС/диск не увеличиваются, ну кроме
как на чтение из кэша. Затем явно параллельно выполняю их. То есть
форсирую выполнение always раньше всего остального. А дальше я собираю
параллельно все цели которые зависят от каждого always. Затем выполняю
тех кто зависят от них. И продолжаю пока не будет ни одной задачи
протухшей. Звучит как ресурсоёмко, как плохо распараллеливаемо, как то,
что мы идём в обратном направлении по дереву зависимостей (а так и
есть), но на практике все case-ы которые я могу придумать, при
использовании always -- очень быстро должны сходится на нет (у меня во
всех проектах так и есть), если always не изменился. А дальше
запускаются штатные сборки, если, конечно же, они всё же OOD.
Пришлось добавить много кода. Но он касается чисто определения порядка
выполнения целей, без уродств. Если always целей нет, то всё работает
чисто по старинке, максимально просто и тупо как в redo-c. Даже не
смотря на "много" кода -- кол-во добавленных строчек чуть-чуть стало
больше чем я выпилил stamp-specific кода! При этом весь новый код
сосредоточен только в ifchange алгоритме/работе, не затрагивая
OOD/runScript функции.
Sergey Matveev [Sat, 21 Nov 2020 17:11:40 +0000 (20:11 +0300)]
Доработки goredo
http://www.goredo.cypherpunks.ru/
Jobserver, аналогичный своей сутью на GNU Make-овый, я добавил в goredo
под конец. Ну и конечно же после этого обнаружил что при кол-ве задач 1
оно бывает виснет. --debug показывает что возникает где-то deadlock. Без
ограничения кол-ва задач всё работает. Потратил много часов, но проблема
оказалась в двух строчках defer-ов, помененных местами: было ожидание
завершение задач, но которые не могли продолжить работу, так как мы свой
job-токен ещё не отдали.
Плюс оптимизации производительности определения свежести цели и redo-dot
утилита, которая сгенерирует DOT зависимостей. На практике, в моём
проекте из-за большого количества взаимосвязей она не знаю для чего
могла бы пригодится, но, опять же, сделать так легко, а надо же догнать
и перегнать альтернативные реализации.
Sergey Matveev [Fri, 20 Nov 2020 18:01:27 +0000 (21:01 +0300)]
Boost индукционной плиты
Тётя мне показала что можно одним нажатием на кнопку "boost" ощутимо
добавить мощности нагрева индукционной плиты. Она и так значительно
быстрее вскипятит воду чем электрический чайник, а с boost-ом вообще
чудеса. Кнопку видел, но даже не задумывался что это и для чего, хотя
она и говорит сама за себя.
Sergey Matveev [Fri, 20 Nov 2020 16:40:50 +0000 (19:40 +0300)]
I redo redo
http://git.cypherpunks.ru/cgit.cgi/goredo.git/tree/README
Психанул и написал свою redo реализацию на Go!
Python apenwarr/redo всем хорош, но Python зависимость не очень приятна.
Плюс при большом уровне параллелизма у него иногда что-то сбоит и он
падает. Не критично, ибо всё равно потом всё недособранное можно
пересобрать (это ж не Make, где с чистого листа только безопасно будет),
но не приятно.
redo-c не имеет redo-stamp команды. С ней просто приятнее и удобнее
жить. Плюс он не уважает umask, ибо просто используется mkstemp(). И
мозолят глаза его .dep. файлы в каждой директории.
Решил было просто переписать его на Go. И в основу он полностью и лёг.
Но на Go так приятно и легко пишется, что я по сути почти все фичи
apenwarr/redo реализации засунул. Ровно один день чтобы написать рабочую
(текущие проекты полностью мочь без проблем *пере*собирать) redo
реализацию. Тестами ничего не покрыто, но у себя всё что в голову
приходило и на нетривиальном проекте с default/redo-stamp разнообразием
оно отрабатывает идеально. Сейчас я даже Python реализацию удалил из
путей.
Что добавил, чего не было в redo-c:
* всегда захватывать stdout. Как и в apenwarr/redo, явно проверяется не
записал ли пользователь И в stdout И в $3. Я не раз по неосторожности
так делал и это сильно помогало
* явно проверять что собранный файл не изменился пользователем, вне
контекста сборки redo, опять же, как это делает apenwarr/redo -- это
очень удобно, ибо позволяет временно вносить правки и смотреть что
получится, но файлы не будут перезатёрты
* исполняемые файлы запускаются как есть, содержащие shebang --
запускаются с ним. Ну а оставшиеся с /bin/sh -e (или -x в дополнении)
* redo -x покажет trace (sh -x) только для текущих указанных целей, а не
всех -- оказалось это очень удобно (но можно через env выставить и
показ вообще всего для всех)
* уважение umask
* redo-stamp, redo-whichdo (мне не надо, но сделать легко)
* в .dep файле сохраняется и UUID сборки, по которому можно понять а
была ли цель уже собрана, ведь от неё могут зависеть многие, а на ней
стоит redo-always или redo-stamp какой-нибудь. Позволяет избежать
возможных повторных ненужных сборок. В apenwarr/redo тоже хранится
информация о конкретной сборки, поэтому в нём тоже избежали эту
проблему
* lock-и и зависимости для каждой цели у меня аналогично в отдельных
файлах, но все они собраны в .redo поддиректории (каждой директории
проекта), что просто разгружает глаз. Там же хранятся и .log файлы
А теперь отличия от навороченного apenwarr/redo:
* apenwarr/redo проверяет размеры, mtime и ещё несколько параметров
файла для определения его свежести. Насколько понимаю, ctime он не
использует потому что он меняется с изменением link count-а. Я
использовал подход redo-c: проверка ctime, если не совпал, то проверка
хэша файла. Проверка хэша убирает false positive срабатывание. Если
хочется иметь "вечную" цель, то, как и redo-c, как и apenwarr/redo,
отсутствие файла воспринимают как тухлость. Последние правки в redo-c
не удаляют файл, если stdout был пуст -- это ломает подобный подход. Я
поэтому делал revert коммита. Ибо это добавляет гибкости и отсутствие
проблем из-за хэширования пустоты. В итоге имеем и гибкость и false
positive защиту хэшом. Если покажется кому-то медленным, то добавил
возможность отключения хэширования (как apenwarr/redo будет). Для хэша
использую BLAKE2b
* я явно делаю sync для созданных целей и файлов зависимостей, а также
директорий после переименования файлов. Можно отключить. apenwarr/redo
не делает sync ни для целей, ни для SQLite3 БД, явно отключая
синхронность
* распараллеливание работы делается через jobserver-like протокол, но с
возможностью infinite работ. У меня на C проекте это позволяет сверх
быстро собрать его
* у меня разукрашенный вывод, с удобными indent-ами, возможностью показа
когда цель завершена и сколько это заняло времени, возможностью
показа PID-ов. stderr задач можно тоже показывать с PID-ом самого
shell-скрипта выполняющегося. У меня сверх verbose debug вывод, весь
из себя разукрашенный, показывающий все принимаемые решения и шаги
* stderr каждой цели можно сохранить на диск автоматом, но в нём каждая
строка будет ещё и с TAI64N timestamp-ом, совместимым с tai64nlocal
утилитой. redo-log команда позволит просмотреть его
* состояние хранится в .dep файлах которые являются recfile-ами
(8249370437018ad186c7946f22242731fba52035, d47bdefa40f41b81435565029c035f62614fe0da)
Особо надобности в этом нет, oneline формат redo-c не проблематичен,
но так красивее, мне кажется
* в процессе работы создаются временные файлы, которые при убийстве
процесса не подчищаются. Сделал отдельную redo-cleanup команду для их
подчистки и возможности вообще удаления .redo отовсюду, для начала с
чистого листа
* apenwarr/redo даже в FAQ говорит что скорее всего начнёт создавать
.redo поддиректории в каждой директории, ибо не понятно как выяснять
что является верхним уровнем проекта. Я сделал подход redo-c: вплоть
до корня ФС он будет искать .do файлы. Но, с возможностью ограничения
"сверху" через REDO_TOP_DIR переменную или наличию .redo/top файла.
И оптимизация и безопасность если проект и подпроект используют redo,
но должны быть независимы друг от друга. Насколько понимаю,
apenwarr/redo тут будет иметь проблемы
Наконец, goredo имеет "gore" корень, что не может меня, любителя
goregrind, не радовать. Это один исполняемый файл, на который нужно
создать символические ссылки. Точнее запустить с -symlinks опцией, чтобы
он это сделал сам.
goredo в итоге работает и собирает проект даже на глаз ОЩУТИМО быстрее.
Всё же, как ни крути, но Python это Python и быстро запуститься
программа на нём не может. Чтобы просто перезапустить rebuild, который
пройдёт по целям делающим redo-stamp, apenwarr/redo нужно время заметное
на глаз, тогда как goredo отрабатывает вмиг. В общем, пока для меня это
идеальная redo реализация!
Смотрел ли я ещё на какие-нибудь?
* Haskell реализация поддерживает только redo-ifchange. Да, это основное
и главное, но нет, хочется большего
* Есть 2-3 реализации на shell (не считая работающего apenwarr/do, но не
делающего rebuild), но либо они требуют либо GNU утилит, либо вообще
bash (идёт сразу в жопу)
* redux на Go я даже пробовал запускать. Он создавал какое-то дичайшее
количество (многие мегабайты) JSON файлов, но .do вроде запускал.
Только с безумно низкой скоростью это всё работало и я даже через
десятки секунд (минуты?) не дождался конца и нажал Ctrl-C. Просто
неюзабельно
* C++ не смотрел, ибо нафиг этот язык, тем более для выполнения redo задачи
* Отпадают не совместимые с redo(-ifchange) реализации
И только с написанием goredo я наконец-то понял надобность в
redo-ifcreate! Например есть цель "foo", но нет "foo.do", а есть
"default.do" (где-нибудь). Если в зависимости будет прописано только
"foo" и "default.do", то появление "foo.do" не заставить цель протухнуть!
Поэтому пути поиска default.do файлов автоматически прописываются в
зависимости, как-будто был вызван redo-ifcreate. Очень красиво, на мой
взгляд. Как пользователь, я redo-ifcreate так и не знаю где вызвать, но
внутри без него вижу что нельзя. Ведь и зависимость от .do файла явно
никто не прописывает -- оно автоматически.
Sergey Matveev [Thu, 19 Nov 2020 13:07:19 +0000 (16:07 +0300)]
Много людей подписались на рассылку LEAPSECS
https://pairlist6.pair.net/pipermail/leapsecs/2020-November/007275.html
Именно сегодня. После статьи из 273d4d5a49d90e55fbd5a173cf587fe09f8b03e7.
И я ведь тоже после неё подписался, интересно же!
Sergey Matveev [Thu, 19 Nov 2020 12:28:03 +0000 (15:28 +0300)]
Самая популярная покупка с первой зарплаты
https://lenta.ru/news/2020/11/19/pervazarp/
Одежда, гаджет, отдых, развлечения или отдали родителям. Ну меня за пару
месяцев зарплата ушла на Beyerdynamic наушники. Модель которую с тех пор
только и использую, ни на что не променяв.
Sergey Matveev [Thu, 19 Nov 2020 07:30:22 +0000 (10:30 +0300)]
Самая популярная песня всех времён
https://lenta.ru/news/2020/11/18/shazamtrack/
https://www.youtube.com/watch?v=q0hyYWKXF0Q
https://www.youtube.com/watch?v=fiore9Z5iUg
https://www.youtube.com/watch?v=PBZfCmlRIVs
https://www.youtube.com/watch?v=SsYXnH9lzCY
... по мнению Shazam. Ни одного исполнителя не знаю, ни одной песни не
слышал. Заценил. Я даже не могу сказать что "это не моё", ибо мне
реально жутко не нравится всё услышанное. Как минимум, отсутствие
голосов. Просто противно и неприятно их слушать. В них нет ни изюминки,
ни красоты, ни души. Мне например очень не нравится манера исполнения и
голос (тембр?) Bon Jovi, Nickelback особенно -- но у них выделяющиеся и
запоминающиеся, просто на любителя. А тут... просто какие-то сонные
подростки бубнящие в микрофон. Да и музыка... настолько уныла, скучна и
просто никакая, что наверное это причина почему в моём предыдущем посте
Земля даже стала медленнее вращаться!
С одним трэком "Let Her Go" я всё же знаком только потому что Within
Temptation на одном из bonus альбомов исполнили на него кавер:
https://www.youtube.com/watch?v=xJrEvz6nbv8 -- но даже он у них является
самым унылым. А вот кавер на Imagine Dragons "Radioactive"
(678bb3bee703cc2fc2d2a427b970c9b1a4ffb08a), так меня бесящий в оригинале
(но! вокалист всё же петь умеет, есть изюминка!), у Within Temptation
отличен: https://www.youtube.com/watch?v=hKDxvVom64c
Sergey Matveev [Thu, 19 Nov 2020 07:07:36 +0000 (10:07 +0300)]
Отправка <...> сообщений в IM-ах
https://rachelbythebay.com/w/2020/11/18/signal/
В Signal, как тут пишут, нельзя отправить сообщения в которых есть
что-то похожее на HTML тэги. Ну офигеть, а люди ещё умудряются говорить
что IM-ы это удобно, когда даже выхлоп ifconfig нельзя отправить.
Sergey Matveev [Tue, 17 Nov 2020 15:22:10 +0000 (18:22 +0300)]
pygopherd выпилили из Debian потому что не поддерживает Py3
https://lists.debian.org/debian-user/2020/11/msg00319.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937449
Хотя там всё же можно оставить было пакет если количество пользователей
большое. Как же мне много чего в Debian не нравится стало, и тут вот
очередные решения основанные на популярности.
Sergey Matveev [Tue, 17 Nov 2020 15:17:25 +0000 (18:17 +0300)]
cut vs awk
https://www.datagubbe.se/cutvawk/
Увидел в статье клёвый хак с tr -s " ". Его мне очень недоставало в tr!
awk я считаю лет 30 назад должен был перестать использоваться уже. Есть
Perl, полностью с потрохами легко заполняющий его нишу. Но awk я, к
сожалению, продолжал иногда использовать для print XX вещей. С tr хаком
уж точно перестану.
Sergey Matveev [Tue, 17 Nov 2020 11:43:41 +0000 (14:43 +0300)]
Интервью с Ангусом Янгом -- он тоже был впечатлён Хендриксом
https://www.darkside.ru/news/126147/
Почти все гитаристы упоминают что Хендрикс был крутейшим богом гитары.
Согласен с этим. Но также запомнилось что от Ангуса я не слышал про
Джимми упоминаний. Не то чтобы я много интервью с ним читал и слышал, но
вот не попадалось. А оказалось что Хендрикс то его впечатлил ещё как!
Purple Haze -- то самое!
А ещё Ангус оказывается совершенно в отказе от любого алкоголя! Не знал
про этот факт. Здорово! И я тоже вообще ничего алкогольного
принципиально не употребляю.
Забавно, а интервьювер впервые поцеловался под Thunderstruck AC/DC. Меня
немного удивляет, ибо как можно отвлекаться даже на такую штуку, когда
такая композиция играет!
Sergey Matveev [Tue, 17 Nov 2020 09:39:36 +0000 (12:39 +0300)]
Использую GNU Stow и для штатной его задачи
В f25380e9842d68f2f9ecce0d530db90903eeb66b коллега поднял тему по
иерархии директорий и устройству/установке пакетов. При этом упомянул
GNU Stow. С того момента всё не выходил он у меня из головы, ведь я его
уже использую для dotfiles (94dad30d714080ca9eb403277a4c923b54bc20c3),
но не использую для штатной цели! А ведь у меня в домашней директории
было много программ установлено (mutt, git, ffmpeg и десяток других),
которые я не хочу глобально в систему ставить. Каждая программа стоит
просто в $HOME префиксе и я в .zshenv добавлял PATH/MANPATH/INFOPATH для
неё. Только сегодня дошло что нафига я этим занимался, ибо Stow как-раз
для этого! Засунул все программы в $HOME/local/stow и он сделал нужные
symlink-и и про .zshenv я могу забыть теперь. Очень удобная штука!
Причём, кроме GNU grep и GNU sed (ну и recutils), без которых можно
прожить и я их использую только из-за производительности, я активно
использую и очень рекомендую GNU parallel и GNU Stow -- оба которых
написаны на Perl. Можно сказать, среди всего GNU софта я только на Perl
написанный считаю must-have-ным :-)
Sergey Matveev [Mon, 16 Nov 2020 19:01:08 +0000 (22:01 +0300)]
pkg-config нравится
https://people.freedesktop.org/~dbn/pkg-config-guide.html
В целом я считаю что freedesktop.org делает в основном плохое, но
pkg-config мне нравится. Только сегодня дошли руки причесать
генерирование корректного .pc файла, который позволяет парой вызовов
получить реально все CFLAGS/LDFLAGS/LDLIBS нужные для сборки. Requires
справляется с тем, что указав зависимости, он и их CFLAGS подставит все.
А у себя в проекте прям определяю какие зависимости определились через
pkgconf, добавляя их в итоговый requires, а какие нет, добавляя их
*FLAGS/LDLIBS уже к соответствующим секциям. К сожалению, проблема на
практике в том, что не все библиотеки предоставляют .pc файлы. Но,
благо, их легко делать. Но даже suckless проекты его вовсю используют и
поэтому их сборка не вызывает проблем и, тем более, какого-нибудь ада в
виде autotools.
Sergey Matveev [Mon, 16 Nov 2020 17:33:02 +0000 (20:33 +0300)]
Посмотрел "Вторую жизнь Уве"
https://ru.wikipedia.org/wiki/%D0%92%D1%82%D0%BE%D1%80%D0%B0%D1%8F_%D0%B6%D0%B8%D0%B7%D0%BD%D1%8C_%D0%A3%D0%B2%D0%B5_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Очень понравился фильм! В целом он конечно грустный и печальный, но
забавные моменты ещё какие есть. Заканчивается, я считаю, на хорошей
ноте, мол главный герой много кому оказался полезен. Но в жизни я думаю
таких не много найдётся.
Вообще у меня в блоге как фильм ни упоминается, то он мне понравился. На
самом деле я смотрю их в разы больше, но они настолько не стоят отзыва
(если это не редкостная гадость), что просто об этом умалчиваю, стыдясь
что взялся такое смотреть.
Sergey Matveev [Mon, 16 Nov 2020 17:23:21 +0000 (20:23 +0300)]
Blockchain and trust статья Шнайера. Голосование на blockchain
https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html
https://www.schneier.com/blog/archives/2020/11/on-blockchain-voting.html
Удивительно, но я почему-то не читал эту статью раньше у него. Люто
нравится, так как в ней повторены аналогичные мои point-ы почему
BitCoin/blockchain бесполезны:
[...]
Blockchain technology is often centralized. Bitcoin might
theoretically be based on distributed trust, but in practice, that’s
just not true. [...] With bitcoin, there are only a few miners of
consequence. There’s one company that provides most of the mining
hardware. There are only a few dominant exchanges. To the extent
that most people interact with bitcoin, it is through these
centralized systems.
[...]
Do you need a public blockchain? The answer is almost certainly no.
A blockchain probably doesn’t solve the security problems you think
it solves.
[...]
Honestly, cryptocurrencies are useless. They’re only used by
speculators looking for quick riches, people who don’t like
government-backed currencies, and criminals who want a black-market
way to exchange money.
А вообще там сплошная тема про доверие и то что доверие нельзя заменить
алгоритмами и протоколами. А вышел на эту статью я через "On blockchain
voting", где тоже сказано что для голосования использование blockchain
вообще тупейшая идея.
Честно говоря я переживал что Шнайер не высказывался о blockchain-ах и
даже наоборот где-то по началу говорил что идея неплохая. Я вот такой
упёртый и считаю Bitcoin/blockchain -- сущим глупым hype-ом, не несущим
никакой практической пользы (ну, кроме продавцов электроэнергии, железа
и спекулянтов, конечно же), а Шнайер, мол, нет и может быть я всё же не
прав? Нет уж, оказалось что всё ok, мы с ним сходимся во мнении.
Столлман про Bitcoin плохо говорил потому что там нет анонимности, что
очевидно.
Sergey Matveev [Mon, 16 Nov 2020 14:50:11 +0000 (17:50 +0300)]
Apple firewall не поможет от программ от Apple
https://thenextweb.com/plugged/2020/11/16/apple-apps-on-big-sur-bypass-firewalls-vpns-analysis-macos/
В общем, это и не firewall оказалось, ибо прозрачен для софта от Apple.
Sergey Matveev [Mon, 16 Nov 2020 08:34:20 +0000 (11:34 +0300)]
Преимущества "Linux" перед Windows: длины имён файлов
https://github.com/nbeaver/why-linux-is-better
Только начал бегло смотреть по диагонали и вижу раздел с максимальной
длиной пути в Windows: 260 символов, а в "Linux" например 4096 (байт?).
И типа в Windows много проблем из-за этого. Насчёт полного пути не знаю,
но вот я не раз сталкивался с тем, что torrent-ы созданные под Windows
не могут быть записаны на некоторые ФС (в том числе ZFS), так как в
Windows ограничение на кол-во символов, а в Unix-ах на байты и кириллица
там становится раза в два длиннее (UTF-8) и уже не влезает: cdc44c7a1bb63c5822313ac73e99a39bda088bff. Но я считаю что 255
символов/байт это вполне себе достаточно.
В остальном же... особо больше мне ничего не приглянулось и не
запомнилось из этой здоровенной статьи.
Sergey Matveev [Sun, 15 Nov 2020 11:17:35 +0000 (14:17 +0300)]
Ваш компьютер больше не принадлежит вам
https://habr.com/ru/post/528104/
Ужасный перевод, но я и оригинал читал. Даже не стал комментировать, ибо
и так про отправку запускаемых команд уже упоминал.
(22dfdf4ab8cd4c68c15720af9296091114e3c3f7). Только Apple это малая часть
компьютеров. Но уже не одно десятилетие движение свободного ПО говорит
про то, что проприетарное ПО это когда вы не управляете своим компьютером.
Особенно всё усугубляется когда компьютер подключён к Сети. Это одна из
причин почему я принципиально не связываюсь с проприетарщиной, в том
числе и JavaScript программам, которые многие не относят/не приравнивают
к запуску несвободного кода.
Sergey Matveev [Sat, 14 Nov 2020 20:50:44 +0000 (23:50 +0300)]
Mike Fraser
http://mikefrasermix.com/credits/
Этот человек создал наверное четверть вообще всех альбомов что у меня на
жёстком диске! Только одних AC/DC пять штук! У некоторых и звук свой
неповторимый -- например группа Septicopyemia обращалась к чешскому
чуваку что сводил альбомы Jig-Ai и звук у них получился именно таким же,
чешским горграйндовым, как и должен быть!
Sergey Matveev [Sat, 14 Nov 2020 20:34:08 +0000 (23:34 +0300)]
Сборка redo проекта в отдельной build директории
В 401c0f635a1cdfb01068a48a4cdf40791d3db458 писал про полную нормальную
замену autotools redo целями. apenwarr/redoconf по многим причинам мне
не нравится, но он умеет делать (даже заставляет) отдельные, независимые
от кода build-директории. Я у себя нашёл как это реализовать: банальный
и простой shell-скрипт который просто делает иерархию директорий и
жёсткие ссылки на файлы исходного кода. Полностью воссоздаются
директории (find+mkdir, find+ln): conf doc examples src tests, а также
копируется эталонный config файл (с -i опцией, чтобы не перезатереть
ненароком) и базовые {all,install,clean}.do цели. Отрабатывает быстро,
место в общем-то не занимает весь этот исходный код. Ни одного .do файла
не правил. Можно сказать что просто весь проект я жёсткими ссылками
переношу, ну и ладно. Зато теперь я с разными опциями (точнее конфигами)
могу параллельно напересобираться для проверок.
Sergey Matveev [Sat, 14 Nov 2020 13:17:10 +0000 (16:17 +0300)]
Замена autoutils redo системой
https://redo.readthedocs.io/en/latest/cookbook/redoconf-simple/
В моей C программе всё усложняется конфигурация сборки: есть
опциональные библиотеки, есть выбор методов/библиотек, появилась
зависимость между некоторыми переменными конфигурации. Если выбран метод
использования криптографии из библиотеки YYY, а не XXX, то всякие
XXX_CFLAGS=${XXX_CFLAGS:-`$PKG_CONFIG --cflags xxx`} исполняться не
должны. Их можно просто закомментировать, но это ручной труд. Добавлять
массу if-ов в сам конфиг (который обычный shell файл) -- тоже плохо,
хотя в нём уже есть hardcoded вещи типа добавления -pthread если
включено использование pthread mutex-ов. Плюс пользователю нужно явно
задавать pkgconf/pkg-config команду например, хотя она может быть
определена сама. Некоторые команды (plantuml, dmalloc) опциональны. В
общем или существенно усложнять простой config, который выглядит просто
как какой-то .ini файл, либо... что-то придумывать.
Определение команд, определение наличия библиотек (у меня опциональные
libtai, dmalloc, libtap например) -- всё это отдельные изолированные
друг от друга задачи. Между ними могут быть зависимости, как например
$CRYPTO_CFLAGS зависит от флагов конкретно выбранной криптобиблиотеки.
Раньше config содержал вереницу переменных внутри которых были вызовы
pkgconf, которые запускались все последовательно. Всё это (отдельные
задачи, зависимости между ними) явно задача для системы сборки!
Я помнил что в apenwarr/redo реализации есть redoconf -- штука которая
как-раз для замены ./configure ада, в которой можно набросать отдельными
файлами всякие детекторы. Я по сути взял из неё идеи, но саму
использовать не стал. Во-первых, там намёки на GNU Make. Во-вторых, она
банально просто где-то падала и не работала у меня -- что-то не так в
shell-скриптах. В-третьих, это полноценный такой framework, с кучей
библиотечных shell функций и обёрток -- требующий и изучения и уже не
такой и прекрасный как redo, не привязанный к языкам или чему-то
подобному. В-четвёртых, там очень много делается через создание shell
файлов с соответствующими костылями для всякого escape-а данных.
В-пятых, там подход заточен чтобы делать один большой и жирный compile
скрипт, содержащий все CFLAGS/LDFLAGS/LDLIBS для сборки целей. Я же у
себя для каждой конкретной .o-цели явно задаю и управляю какие конкретно
опции и флаги передаются -- чтобы лучше понимать что от чего зависит.
Но основную идею я заимствовал. Если программа использует $CC, то можно
сделать вот такой детектор, который учитывает и переменные окружения:
можно добавить зависимость от цели учитывающей изменение переменных
окружения (0676a1348e8ffe14a7840c8699d3afdc6857e24c) и учитывать не
поменялось ли значение самой цели:
проверка наличия redo-stamp чтобы работало под реализациями без этой
команды -- всё будет работать, просто изменение переменных окружения не
заставит пересобираться (если системы не основаны на хэшах, конечно же).
Программа которой нужна cc команда:
redo-ifchange ../conf/cmd/cc
read CC < ../conf/cmd/cc
$CC ...
Сделать более сложные цели для определения команд, возможно с выводом в
stderr о том что команда не найдена и будет использоваться пустышка --
тривиально. Раньше у меня всё глобально зависело в целом от конфига и
переменных окружения (его касающиеся). Теперь команды сборки
документации зависят только от cmd/makeinfo, cmd/plantuml (который
подставит пустышку, с предупреждением, если настоящий не найден) и
изменение cmd/cc не повлияет на пересборку документации. Плюс для сборки
некоторые .o файлов нужны знания о PCSC библиотеке, добываемые через
pkgconf. Для других .o файлов нужен LibreSSL, тоже через pkgconf. Обе .o
зависят от разных conf/flags/{crypto,pcsc} флагов и поэтому вызовы
pkgconf-а могут быть распараллелены. Определение наличия и
работоспособности libtai библиотеки делается через сборку (прямо внутри
conf/flags/tai) временного файла с C кодом, но знание о $TAI_*FLAGS
нужно только при сборке log.o файла -- пока он дожидается сборки и
проверки наличия libtai, множество других целей уже успеет собраться,
так как они не зависят от conf/flags/tai.
Многие .o зависят от криптографических библиотек. Но им без разницы
какая именно библиотека будет использована. Поэтому я использую общие
$CRYPTO_*FLAGS, значение которых зависит от выбранного метода
криптографии:
тут и зависимость от конкретной pkg-config реализации и возможность
переопределения SSL_* и выхлоп просто в виде трёх строчек в файл.
Библиотеке которой надо использовать CRYPTO_*:
redo-ifchange ../conf/flags/crypto
read CRYPTO_CFLAGS < ../conf/flags/crypto
# или
{ read X ; read X ; read CRYPTO_LDLIBS ; } < ../conf/flags/crypto
Подход с read-ом мне люб тем, что не надо париться с экранированием и
генерированием валидного shell-кода. Изначально у меня был lib.rc с
библиотечными shell функциями, но под конец полностью исчез.
В итоге, что я получил?
* возможность лёгкого добавления детекторов как и в autoconf. Сейчас у
меня в проекте 14 conf/cmd и 19 conf/flags (всякие флаги сборки кода).
Плюс с зависимостями между ними
* полное распараллеливание работы этих детекторов
* зависимость конкретных целей сборок совершенно разнородных вещей
(документация, .o файлы, исполняемые, .a) от только нужным им командам
и флагам/настройкам
* при изменении переменных окружения (хочу быстро всё пересобрать с
CC=clang-NEW redo clean install) будут пересобраны только зависящие от
CC цели (например сгенерированный asn1Parser-ом файл .c из .asn1
спецификации не будет затронут). Зависимость только от конкретики
Это всё просто офигенно! Есть небольшой недостаток моего подхода: вместо
"redo-ifchange ../vars ; . ../vars" у меня большее количество
зависимостей и из-за read-а каждое чтение каждой команды/флага занимает
строчку. Но зато чистейший pure POSIX shell, никаких shell фунок
самопальных, отсутствие хаков и возни с экранированием строк, которая
присутствовала раньше (а у apenwarr/redoconf так вообще там целые экраны
кода для этого).
Для того чтобы узнать какие вообще опции можно изменить/настроить в
apenwarr/redoconf -- вызывают отдельные функи "регистрирующие" что у нас
есть на руках. У меня в каждом "детекторе" команд/флагов/настроек есть
возможность влияния на него через переменные окружения или тем что
прописано в config-файле. Де-факто это всегда запись/использование
переменных в виде ${WHATEVER}. Что мешает мне просто из всех .do
навыдёргивать эти переменные?
Почему в одном месте perl, а в другом sed? Так исторически сложилось,
лень переделывать :-). После выполнения, я получу красивый полный
список:
AR ARM_CFLAGS ARM_LDFLAGS ARM_LDLIBS ASN1PARSER CC CFLAGS CLANG_FORMAT
[...]
TAI_LDFLAGS TAI_LDLIBS TAP_CFLAGS TAP_LDFLAGS TAP_LDLIBS TASN1_CFLAGS
TASN1_LDFLAGS TASN1_LDLIBS VERSION
Без описания переменных правда. Но пока все они говорят сами за себя и
должны быть понятны. Для их описания уже понадобится конечно куда-то
зашивать эту метаинформацию, например просто в виде комментария рядом с
переменной оставлять и чуть-чуть усложнённым perl скриптом выдёргивать.
Когда я начал всю эту переделку, то совершенно полностью не был уверен в
результате и вообще будет ли оно того стоить. Превзошло все ожидания!
Единственное чего у меня совершенно нет, в отличии от apenwarr/redoconf
-- возможности работы в отдельной изолированной build директории, что
вообще конечно хорошим тоном является. Пока даже не думал как это сделать.
Можно просто наворотить себе git worktree в отдельных директориях, как хак.
Sergey Matveev [Sat, 14 Nov 2020 08:21:25 +0000 (11:21 +0300)]
Скорость работы LLVM 11 и его инструментарий
Обновился с LLVM 6 до 11. LSP демон стал работать значительно быстрее,
меньше каких-то непонятных warning-ов выдаёт. В 543ea92f9b81c1c8adead550e7ce0cf3cc665240 писал про то, что скорость
прежних задач не должна падать -- тут они справились! А вот всякие
clang-tidy стали работать медленнее... но при этом находят больше
серьёзных недочётов и в (ещё не протестированном) коде нашли утечки
памяти (отсутствие free) и кое где отсутствующие break. За это можно
простить, тем более что оно не интерактивное.
Вообще LLVM/Clang инструментарий очень нравится и насколько понимаю в
GNU GCC нифига подобного ничего нет. И clang-format, который 100%
форматирует весь мой код. scan-build ПОТРЯСАЮЩЕ находящий серьёзные
ошибки, которые и во время ревью человек то нифига не заметит (хитрые
goto/if из-за которых потеряется значение переменной). clang-tidy
выдающий и false positive, но также и полезные вещи типа утечек памяти
или неинициализированные значения. clangd LSP -- как linter отличен!
Куча -Weverything проверок (которые даже в doxygen docstring-и умеют
залезать) и sanitizer-ов, которые в 99% случаев находили некорректности
работы с памятью, переполнения чисел или ошибок из-за их знаковости.
Вовсю моё программирование на C опирается на эти инструменты.
Единственное что я ставил дополнительно это: https://include-what-you-use.org/
С помощью которой я легко корректно и правильно организую include-ы,
ведь задача очень не приятна для человека.
Sergey Matveev [Sat, 14 Nov 2020 08:12:50 +0000 (11:12 +0300)]
Иерархия файловой системы в Unix-like системах
https://cr.yp.to/slashpackage.html
https://jdebp.eu/FGA/slashpackage.html
https://sta.li/filesystem/
Коллега скинул ссылки на очередной предложение от DJB касательно
управления "пакетами". Точнее того, как их можно было бы устанавливать и
размещать. jdebp.eu продолжает идею ещё дальше. Такой подход мне
нравится, безусловно. Плюс /var/service где daemontools смотрит за
демонами. У sta.li тоже видел предложение по куда более простой
иерархии:
/ - the root home
/bin - all executables
/sbin -> /bin # softlink pointing to /bin
/boot - all boot files
/etc - system configuration
/home - user directories
/var - spool, run, log, cache
/share - man pages, locales, dependencies
/include - include/headers
/lib - static libraries for building stuff
/mnt - mount points
/usr -> / # softlink pointing to /
/sucks - stuff that sucks, like ugly gnu library dependencies,
or systemd fake handlers
Которое мне тоже нравится. Но вот менять это в уже готовой ОС, типа
FreeBSD, не стал бы. Оно красивее, правильнее, но стоит ли оно того?
Если делать дистрибутив/ОС с нуля, то стоит обо всём это задумываться. А
так овчинка выделки не стоит -- уж больно много геморроя.
Хотя это ужасно что мы стали жить в /usr и /usr/local директориях, ведь
история говорит что просто у хакера не хватило места в / ФС и было много
свободного на /usr и поэтому он туда начал всякое устанавливать.
Sergey Matveev [Sat, 14 Nov 2020 08:00:02 +0000 (11:00 +0300)]
glibc и memset_s
https://en.cppreference.com/w/c/string/byte/memset
Компилировал недавно свою программу на последней LTS Ubuntu, GCC10.
Отругала меня что ничего не знает про memset_s функцию (безопасная
очистка памяти). Действительно grep вообще ничего не показал. Как же
так? А вот так, действительно, glibc положил на опциональные C11 функции
связанные с security. Даже не самая свежая FreeBSD имеет их у себя в libc.
Я то думал что наконец-то в 2011-ом году догадались стандартизировать
наличие функции безопасной очистки памяти. Сделать то сделали, вот
только в GNU/Linux мире это не реализовано. Когда-то я считал что GNU
софт и библиотеки монструозны по размерам, но при этом чего только не
содержат и богаты функционалам. Теперь вижу что они просто монструозны!
Sergey Matveev [Sat, 14 Nov 2020 07:56:37 +0000 (10:56 +0300)]
Power Up!
https://en.wikipedia.org/wiki/Power_Up_(album)
Вышел новый альбом AC/DC и даже нашёл где его скачать! Хорош ли он?
Слушал перед сном. Когда проснулся сегодня -- до сих пор что-то из него
играло в голове и хотелось его переслушать. В отличии от трёх предыдущих
(20 лет времени) -- в нём уже рок-н-ролльчик, а не блюз, который после
прослушивания у меня ничего не оставлял в памяти. Альбом хорош!
Вот правда сразу же бросилось в уши что он жутко скомпрессирован! Очень
громкий. Но всё же слушать можно, в отличии от Metallica "Death Magnetic".
Sergey Matveev [Sat, 14 Nov 2020 07:46:52 +0000 (10:46 +0300)]
Рекомендации к просмотру xkcd
Сегодня заметил что на сайте xkcd.com есть рекомендации просмотра:
xkcd.com is best viewed with Netscape Navigator 4.0 or below on a
Pentium 3±1 emulated in Javascript on an Apple IIGS at a screen
resolution of 1024x1. Please enable your ad blockers, disable
high-heat drying, and remove your device from Airplane Mode and set
it to Boat Mode. For security reasons, please leave caps lock on
while browsing.
Sergey Matveev [Sat, 14 Nov 2020 07:45:14 +0000 (10:45 +0300)]
musl то требует Linux
http://www.musl-libc.org/faq.html
Я про musl упоминал что штука выглядит хорошей, но ни в коем случае даже
мысли не было чтобы его использовать у себя на FreeBSD. У нас и так
хороший BSD libc. А даже если бы и захотелось, то musl всё равно требует
Linux ядро.
Sergey Matveev [Fri, 13 Nov 2020 09:29:08 +0000 (12:29 +0300)]
Прочитал "Пиратов Карибских морей"
https://www.livelib.ru/book/1000250586-piraty-karibskih-morej-v-riva
С одной стороны получил удовольствие, а с другой как-будто какой-то
бабских роман прочитал, где сплошные интриги и козни на теме любви.
Запомнилось что очень тяжело даётся идентификация героев романа: имена
всюду и везде есть, но вот тяжело мне они запоминаются и я часто только
по контексту понимал кто к кому пришёл. Ну как в некоторых просмотренных
корейских фильмах все на одно лицо.
Sergey Matveev [Fri, 13 Nov 2020 07:54:06 +0000 (10:54 +0300)]
Железо на шаг впереди, софт делает два шага назад
https://fabiensanglard.net/silicone/index.html
Автор пишет что, не смотря на возрастающую производительность
процессоров и железа в целом, на каждую сохранённую железячниками
инструкцию, софт умудрится сделать на две инструкции больше. Меня
впечатлило что автор говорит что раньше Photoshop на SSD грузился
за секунду, XCode запускался мгновенно. А теперь на Ryzen 5 2600 с
M.2 NVMe он уже просто не в состоянии использовать XCode и Photoshop
грузится на 13сек!
Это нормально что raytracer-ы требуют больше ресурсов потому что они
делают более качественную и лучшую картинку. Компиляторы получили всякие
LTO оптимизации, которые тоже ресурсоёмки. Но вот не нормально что
прежние такие же задачи на новом железе выполняются так же долго.
Именно в этом году я конкретно начал замечать и париться об отзывчивости
системы. Я делал это и прежде, но в этом году у меня обострение какое-то.
* Давным давно я выкинул bash, в первую очередь потому что он медленный.
Я уже не вспомню где и как именно, но он тупо просто некоторые чисто
shell вещи умудряется делать так, что я на глаз замечаю задержку.
* Для калькулятора я часто запускал python -- и даже на современных
мощных Mac системах (коллега проверял) "не прогретый" запуск занимает
более секунды! Если мне надо посчитать в калькуляторе что-то, то я,
очевидно, хочу его моментальный запуск! Это происходит не часто,
поэтому к долгому времени запуска я привыкнуть не могу. Я перешёл на
zcalc, а теперь вот на dc в rlwrap в tmux с кучей shell-скриптов
обёртки -- и это работает стремглав, по сравнению с запуском python.
* За последний год я больше работал с Go и не переставал удивляться что
он способен откомпилировать с нуля mumble-сервер, жирный irc-сервер с
кучей зависимостей за считанные секунды!
* Когда я что-то рассматриваю и пробую из плагинов для Vim-а, то
скорость работы (или я замечу задержку или нет) практически на первом
месте. Возясь с LSP увидел что скорость работы Python LSP сервера
такая, что я полностью отключил его, ибо мне проще и удобнее руками
вызывать pylint/pyflake/whatever, а не получать с дичайшей
асинхронностью по времени warning-и, которые уже не актуальны могут
быть. Linting clangd для C работает вполне вполне с достаточной
скоростью и помогает, но вот дополнение методов/функций работает очень
медленно -- автоматику во время набора поэтому отключил. А вот в Go
LSP работает практически со скоростью моего набора!
* Когда я стал использовать redo со всякими pkg-config-ами, то весь
процесс конфигурирования+сборки+установки стал таким быстрым (для моих
проектов, конечно же), что мне почти физически становится плохо когда
я вижу что на моём ноутбуке ./configure выполняется дольше чем сама
сборка. Это проблема configure, но всё же!
* Когда я стал программировать на C, то вижу с какой скоростью всё
способно компилироваться. C++ -- адовейший ад. У коллеги с мощным
компьютером видел сколько собирает Rust программу типа PyDERASN-а --
ещё большее время ожидания, при котором можно прочитать новости успеть
* Недавняя эпопея с статической/динамической линковкой показала
насколько много впустую тратится время *человека* ожидающего запуск
программы
* Texinfo собирает мою домашнюю страницу всё равно секунды, но это на
порядок быстрее чем Python Sphinx. Не то чтобы это критично, но к
быстрой работе команд/задач очень привыкаешь и офигеваешь как в
некоторых проектах дока собирается по несколько минут. Давным давно
для вырезания docstring-ов и их вставки в .texi/.rst файлы у меня был
Python скрипт и при частой сборке программ я бОльшую часть времени мог
ждать только факта самого его запуска. Сейчас у меня быстро написанная
программка на Perl -- работающая просто моментально для глаза (Perl
вообще очень и очень шустрый)
* Буквально ведь всего несколько лет назад, когда в FreeBSD был GCC,
сборка полностью всей ОС занимала меньше (на в разы более слабом
железе) чем сборка сейчас LLVM-а. CMake собирается дольше чем GCC (не
самый последний GCC, конечно же, где вроде как тьма C++ появилось). А
скорость сборки всей системы важна, если бы мы максимально старались
делать статическую линковку (c0de9bbf633b421a57a10db70d6d76b5f195546e).
Сборка Go, начиная с 1.4, занимает суммарно (без тестов) наверное пару
минут на ноутбуке
Отзывчивость системы это life-changing! Это не просто "ну, приятно что
быстрее запускаются", а это именно в корне меняет привычки и работу за
компьютером. Огромное количество людей уходит с жирных IDE на Emacs/Vim
только потому что на их 16GB RAM системах оно всё равно всё тормозит (с
моей точки зрения -- до неюзабельного состояния).
Буквально позавчера я устанавливал Ubuntu последнюю LTS на флешку
(обычную такую дешёвую флешку), чтобы на отдельном ноутбуке поработать с
железом и с ней. В ней так много всего позапущено (без GUI! это server
вариант), что когда мне показали приглашение для логина, то логин занял
более чем минуту, прежде чем я увидел строку shell-а! Каждая, *КАЖДАЯ*
команда имеет видимый и ощутимый lag. На этой же флешке я помню как
запускал FreeBSD с GUI и Firefox-ом -- это была юзабельная система.
Большие лаги я наблюдают когда соединяюсь с удалённым VPS-ками по IPv6,
который идёт через третьи страны -- вот на современных Ubuntu,
запущенных на локальном железе, ощущения похожие.
Я, как программист, часто понимаю, конечно же, откуда растут ноги всего
этого, но нужно же иметь совесть! Отдельная тема это смартфоны и
броузеры (штатные, где ничего не отключено из JS-а) -- где всё медленно
и неспешно, в slow-mode-е. У папы на смартфоне я вижу задержку наверное
чуть ли не на каждый клик (не в броузере, а просто в системе), хотя
другие этого не замечают уже, ибо привыкли. Мне в фильмах всегда
бросалось что любое нажатие по любой кнопочке обязательно должно
открывать окошко/менюшку с анимированным визуальным эффектом. В Mac по
умолчанию когда показываются все текущие окна, тоже анимация их
размещения по экране. В фильмах это ладно и простительно. Но нормальный
человек рехнулся что ли за каждым частым действием ждать десятки/сотни
миллисекунд на свистоперделку, вместо того чтобы от компьютера сразу
получить ответ на свою команду? Знаю что в проприетарных системах этими
анимациями часто скрывают, на самом деле, долгое время запуска/работы,
но ведь не всегда же так.
Насколько мог бы "динамический" IPsec между host-to-host системами
(когда одна из сторон "анонимна" например) помочь с хранением
handshake/state и сократить до минимума лишние round-trip-ы до сервера,
дьявольски увеличив отзывчивость системы (HTTP/2 со всякими TLS session
resumption-ами это и пытаются добиться как-раз). Когда люди хотят чтобы
в каждой сетевой программке была поддержка TLS, то меня это бесит! IPsec
надо развивать, а не эти изолированные TLS сессии. Ведь нет же ничего
чтобы хранило state при запуске lynx, curl, wget, whatever -- наверное
только броузер одна из немногих программ которая долго живёт и может
блюсти уже установленные handshake-и. Life-changing когда я стал
использовать OpenSSH долгоживущие сессии и моментально логиниться на
сервер, а не ждать пока TCP/SSH handshake отработает и вся эта не
шустрая асимметричная криптография (пускай даже и *25519!).
Или вот на работе у нас используется OpenVPN. Под пять секунд приходится
ждать пока он подключится! А ведь ping до сервера вообще показывает чуть
больше 2мс!
На глаз видно насколько медленнее работает SSH или IKEv2 с RSA ключами.
Но это уже ладно -- это тема ни программистов, ни компьютеров. Но пора
активнее начать использовать эллиптические кривые.
Я бы на месте пользователей компьютеров и ресурсов Интернетов люто
ненавидел любого программиста, бессовестного и обнаглевшего!
Sergey Matveev [Thu, 12 Nov 2020 09:35:55 +0000 (12:35 +0300)]
Мужик два года заходил в квартиру через окно
https://lenta.ru/news/2020/11/12/man_seeking_woman/
И всё было удобно и прекрасно, пока к нему не пришла женщина и пришлось
тратиться и ломать замок двери. Жил, не тужил и тут на тебе!
Sergey Matveev [Wed, 11 Nov 2020 17:30:51 +0000 (20:30 +0300)]
Overhead от динамической линковки
http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://sta.li/faq/
В комментарии http://blog.stargrave.org/russian/71870b1510dfc2727093f2767b994b8596f9b163#comment1
я запускал convert, в котором ldd на полэкрана, в течении 165мс. Когда
руками собрал с нуля, то у меня на полтора экрана вывод ldd и утилита
запускается более чем в два раза дольше. Всё таки 200мс это очень и
очень заметное на глаз время, тем более для long-live утилиты.
Когда я только начал в этом году программировать на C, то задавался
вопросом какие библиотеки мне делать (static vs shared). И все хакеры
говорят в один голос о статической линковке. Есть даже целый "stali"
(static linux) дистрибутив, целью которого является только статическая
линковка, musl и всякое такое. В котором много ссылок на конкретные
примеры всяких размеров программ, времени их запуска и тому подобного.
Plan9 и Go -- имеют только такую линковку.
И вот, судя по ImageMagick, я однозачно теперь тоже за статическую.
Во-первых, если использовать всякие -ffunction-sections+-Wl,--gc-sections,
то в итоговом исполняемом файле не останется лишнего кода в виде
неиспользуемых функций. Во-вторых, даже если размер будет и больше, то
он всё равно при этом будет быстро (быстрее) загружаться, что куда
важнее чем место на диске.
Основной аргумент за динамическую линковку у людей: типа если нужно
обновить OpenSSL, то можно только его обновить, не трогая остального. Но
даже я на своей практике с чистой совестью могу заявить что это брехня
только изредка работающая, ибо регулярно *на практике* несовместимости в
версиях библиотеки, которые препятствуют обновлению и по факту
приходится всё равно пересобирать зависимый от неё софт. Да и в чём
проблема пересборки всего что зависит от неё, пускай это даже и libc?
Отсутствие исходников? Не аргумент, ибо они должны быть в свободном ПО.
Проприетарное -- идёт нафиг. Время сборки/пересборки -- а вот это повод
задумываться над скоростью компилирования. C-компиляторы вполне себе
шустрые например. Go -- аналогично, пересобрать ВЕСЬ Go софт, сколько бы
его не было -- вопросы нескольких минут, как мне представляется на
практике. C++/Rust/etc -- теперь я ещё больше понимаю насколько важно
время сборки. А в идеальной и прекрасной системе со свободным ПО (значит
и исходники будут) на C/Go проблем нет никаких. Скорость,
производительность, простота, безопасность (куча ссылок касающаяся
недостатков динамической линковки про безопасность как-раз),
эффективность! Плюс никаких проблем с тем чтобы иметь софт с самыми
разносторонними по версиям зависимостями, ибо они всё равно вшиваются.
Sergey Matveev [Wed, 11 Nov 2020 16:39:59 +0000 (19:39 +0300)]
Линковка ld и порядок -l аргументов
https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Работал я со своей C программой в LLVM/Clang/FreeBSD, работал в
GNU/Linux, GCC 4.x, glibc. А сегодня в современной Ubuntu с GCC10 не мог
собрать её. Упорно ругается что не может найти символы всякие, которые
из библиотек берутся. Беглый поиск "а не бага ли это GCC?" не дал
результатов. Начал тупо перебирать и менять местами все эти -l
аргументы чтобы заработало, ибо надо успеть это сделать довольно срочно.
Но позже нашёл вот статью в которой объясняет как именно обрабатываются
-l, что магии там нет, всё довольно просто. А я просто совершенно не
понимал (точнее подозревал, но в корне не верно) как линковщик работает.
А всё так "сложно" не просто так -- а чтобы быстро работал ld. Можно
указать пару аргументов (--{start,end}-group) и будет работать всегда и
везде, грубо говоря, но с соответствующим performance overhead.
Sergey Matveev [Wed, 11 Nov 2020 11:54:48 +0000 (14:54 +0300)]
Соскучился по Ubuntu
Давно я что-то про неё ничего не писал. Нужно тут собрать одну
библиотеку под неё. Скачал самый последний LTS. После установки, первым
же делом сделал apt install build-essential. Ну разве могло оно пройти
успешно?
[...]
Err:8 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-libc-dev amd64 5.4.0-42.46
404 Not Found [IP: 2001:67c:1562::18 80]
Fetched 38.8 MB in 9s (4,546 kB/s)
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-dev_5.4.0-42.46_amd64.deb 404 Not Found [IP: 2001:67c:1562::18 80]
Ладно, apt-get update починил, ещё и GCC10 стал стягиваться.
Хочу установить libtap, libtai -- apt search по ним ничего не показывает.
Хотя в портах FreeBSD, например, обе имеются.
Sergey Matveev [Wed, 11 Nov 2020 11:45:16 +0000 (14:45 +0300)]
Python Concurrency From the Ground Up
https://www.youtube.com/watch?v=MCs5OvhV9S4
Очень понравилось выступление с живым показом как написать корутину на
Python, без asyncio, from the ground up.
Хоть у мужика и Emacs, но совсем не использует никакого автодополнения
(типа Ctrl-P из Vim), даже в bash всё любит набирать руками.
Sergey Matveev [Wed, 11 Nov 2020 09:31:30 +0000 (12:31 +0300)]
wpa_supplicant оказывается deprecated, как и ifconfig
https://losst.ru/top-5-prichin-ispolzovat-linux-v-2020
Чисто случайно из статьи вот узнал что wpa_supplicant оказывается тоже
уже устарел и вместо него используется wicd. Про него я не помню чтобы
слышал. Насколько ж давно я с WiFi последний раз работал под GNU/Linux!
Sergey Matveev [Wed, 11 Nov 2020 09:27:42 +0000 (12:27 +0300)]
HP почти переплёвывает Apple
https://www.linux.org.ru/news/hardware/15995352
HP удалённо блокирует принтеры, чтобы те не печатали. А ещё даже может
достучаться до них и через особые документы, отправляемые на печать
(чтобы и без Интернета мочь поднасрать). Скупердяйство не знает границ,
как верно заметили. До Apple конечно далеко, но всё равно удивляет эта
черта проприетарщиков.
Sergey Matveev [Tue, 10 Nov 2020 18:28:54 +0000 (21:28 +0300)]
В самолёте попоили собаку
https://lenta.ru/news/2020/11/10/dogplane/
... ну девушка начала оттуда же пить сама. Меня возмущают возмущения
людей :-). Да я сотни раз (тысячи?) так делал со всеми своими собаками,
давая и ложки облизывать, которыми сам же продолжаю есть, и из тарелки
или чашки чего полакать или там мороженое полизать.
Мерзкие пёсоненавистники!
Не забуду как хороша их слюна для заживления порезов/царапин! Был случай
когда я в детстве конкретно ободрал запястье, пришла собака наша, и
давай просто лизать это место. А я на компьютере вроде что-то смотрел.
Потом через несколько минут смотрю на руку -- а там и следа нет!
Sergey Matveev [Tue, 10 Nov 2020 18:15:07 +0000 (21:15 +0300)]
Конкурс красоты в Новой Зеландии
https://lenta.ru/news/2020/11/10/missnewzealand/
... выиграл мужик. Оказывается аналогично было и в Испании.
https://lenta.ru/news/2018/07/03/transmiss/
Там настолько всё плохо с женщинами, что на их конкурсах побеждают мужчины?
Или просто нормальным уже вход запрещён?
Sergey Matveev [Tue, 10 Nov 2020 11:32:57 +0000 (14:32 +0300)]
Тупость в статьях про качественный звук
В одном журнале вот увидел:
Однако теорема Котельникова не дает ясных критериев, какая частота
дискретизации нужна для КАЧЕСТВЕННОГО восстановления звукового
сигнала из цифровых отсчетов. Ведь при частоте дискретизации 44 кГц
на один период сигнала с частотой 22 кГц придется лишь 2 отсчета!
Замените период синусоиды всего двумя прямоугольными импульсами –
вот как искажаются высшие гармоники звукового сиг‐ нала в
аудиозаписях стандарта CD. И лишь низ‐ кочастотные гармоники
воспроизводятся довольно точно, так как на один их период приходятся
десятки‐сотни отсчетов. Отсюда следует, что для качественного
воспроизведения и за‐ писи аудио (например, в профессиональных
целях) нужна повышенная частота дискретизации (96, 192 кГц...) Для
решения этих задач по‐ явились «профессиональные» звуковые платы.
При этом возрос поток передаваемых данных, что потребовало
использовать более быструю шину PCI вместо ISA. Некоторые из этих
плат мы рассмотрим далее.
Автор явно и конкретно не понимает что говорит теорема Котельникова. Он
считает что раз на экране увидел два прямоугольничка (два отсчёта для
22kHz) и они не похожи на красивые синусоиды, то вот так вот всё адски
искажается. В 200bf7ba55111f981e69e8e89b7cfcbf9d539379 я публиковал
ссылку на короткие видеоуроки от Xiph.org, а также там есть отдельное
видео как-раз про прямоугольнички и синусоиды. Прямоугольнички -- по
сути это просто другой способ представления данных, а не тот
электрический сигнал который подаётся (да и нельзя такой сформировать).
И там на осциллографах в видео показывают что эти два отсчёта идеально
передадут оригинальную синусоиду. Теорема Котельникова как-раз и говорит
что этих отсчётов достаточно. Буквально достаточно чтобы передать
информацию.
А большие частоты дискретизации нужны для обработки звука, чтобы при его
изменении терялось из-за округления как можно меньше информации. Особенно
важна глубина квантования. Но для конечного результата, CD более чем за
глаза достаточно.
Sergey Matveev [Tue, 10 Nov 2020 08:27:43 +0000 (11:27 +0300)]
Ctrl-F в режиме поиска
В ced719937ead049475dc5fbb5cb6d51dc5df98f8 писал про Ctrl-F (или q:) для
редактирования истории и текущей командной строки. Но забыл про то, что
аналогично оно работает и для строк поиска ("/", "?"): или Ctrl-F или
"q?" с "q/".
Sergey Matveev [Mon, 9 Nov 2020 19:32:27 +0000 (22:32 +0300)]
Закон Годвина
https://beldmit.livejournal.com/629418.html
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%93%D0%BE%D0%B4%D0%B2%D0%B8%D0%BD%D0%B0
Не слышал о таком "законе" раньше. С автором (beldmit) полностью
солидарен что если собеседник переходит на мемы, то разговор можно
считать законченным, ибо это мерзкий сарказм. А он в беседе уже не несёт
ни смысловую нагрузку, ни, зачастую, уважение к собеседнику и
используется когда сказать уже нечего. Хотя, я наверное и сам часто
перехожу на него, но я никогда и не был хоть сколько-то приятным в
беседах.
А в Wikipedia есть ссылка на письмо Линуса в GNOME:
https://mail.gnome.org/archives/usability/2005-December/msg00022.html
где он (этим UI нацистам) припоминает что (форсированный) выбор файла
через иконки в миллион раз медленнее чем возможность ввести к нему путь
(особенно автодополняемый). Сегодня я долго боролся с тем, чтобы
грёбаный GDK заткнулся о том что он не может найти иконки для zathura,
ибо она у меня установлена в отдельной иерархии директорий, победив это
выставлением XDG_что-то-там. Яростно ненавидел и ненавижу подходы GNOME.
Sergey Matveev [Mon, 9 Nov 2020 16:36:27 +0000 (19:36 +0300)]
PDF просмотр в табах. XEmbed
https://tools.suckless.org/tabbed/
http://git.stargrave.org/cgit.cgi/dotfiles.git/commit/?id=006a3bcc53de2435426073730ca2de002e93b635
https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html
Сегодня меня осенило что ведь можно zathura помещать в табы. Точнее
стоило бы, вроде бы видел что её запускают внутри tabbed. Ибо когда надо
открыть много PDF (потому что надо быстро просмотреть/найти в них что-то,
но не знаешь где именно), то, делая zathura *.pdf, в dwm порождается
много окон, который регулярно помещаются из стэка в главную область экрана.
Вообще это не проблема на самом деле. Тут всё ok. Но у меня давняя
проблема с zathura что при изменении геометрии окна она бывает
"залипает". Или ни на что не реагирует или не реагирует система
рендеринга у неё. И когда окно перемещается из стэка в главную область
dwm, то resize происходит и PDF-ку уже возможно не получится прочитать
из-за глюков zathura. Поэтому я делал for p (*.pdf) zathura $p и
открывая по одной PDF-ке у меня получалось что все окна в главной
области сразу же.
Подумал что одно окно с табами упростит жизнь. До suckless проекта я и
не слышал о XEmbed протоколе X-ов, который позволяет делать
таб-менеджеры и включать в него "детей". Не нужно делать табы в
терминалах или броузерах -- нужно чтобы они поддерживали XEmbed протокол
и за табы будет отвечать внешняя программа, типа tabbed. tabbed имеет
всякие сочетания клавиш для переключения, перемещения, создания
(запуском внешней команды), удаления табов. tabbed можно указать команду
для запуска и ей он сможет передать id своего окна для embedding-а.
Раньше не использовал ничего из этого, так как табы в терминале у меня
tmux-овые, а GUI броузер xombrero сам ими рулит (uzbl, surf не
использую). С zathura это получилось. Вот только... теперь она вообще в
перманентном состоянии "замороженности" внутри tabbed и ничего не
рендерит. Проблема zathura тут стала проявляться 100% времени.
Я смог найти упоминание этой проблемы, но нигде нет намёков на решение.
Но у меня и родная zathura из портов, далеко не самая свежая. А она ещё
и от girara зависит. Пошёл обновлять всё это. Понадобилось ещё и MuPDF
ставить тоже не из портов, ибо этот был не достаточно свежий. Всё это
отдельный квест, ибо никаких привычных configure+make+make install или
redo (:-)!) тут нет. ninja, meson и чисто голые Makefile-ы. В этом году
ещё и не раз видел CMake сборки. Вот зоопарк то развёлся!
Но в итоге всё поставил, и написал скрипт обёртку над zathura который
запускает tabbed если его не нашёл или суёт в уже имеющийся эту zathura.
А на самом деле то мне надо было просто её (+зависимости) обновить чтобы
исчезла бага при resize окон.
Sergey Matveev [Mon, 9 Nov 2020 13:19:33 +0000 (16:19 +0300)]
Ускорение git clone в 100 раз
https://habr.com/ru/post/527116/
Ожидал что вся статья будет посвящена --depth. Почти так, плюс ещё
упомянули стягивание только нужного ref-а. Стыдоба об этом писать целые
статьи (это тема для небольших блогов/twitter-ов). А вот (единственный,
пока) комментарий куда полезнее, намекающий на --reference, который
учтёт наличие локального репозитория.
Sergey Matveev [Mon, 9 Nov 2020 12:33:18 +0000 (15:33 +0300)]
Почему IPsec вместо WireGuard?
В 1d5bc1731a1e8f77fed6e7c60bbdeb9db421a87d написал что всё равно
использую IPsec по возможности. Если забыть про то, что IPsec тесно
интегрирован в ОС/ядро и позволяет делать далеко не только VPN туннели,
то всё равно остаётся вопрос эффективности.
IPsec ESP это отдельный тип IP-пакета, в котором (для AES-GCM) : SPI
(4B) + SEQ (4B) + IV (8B) + padLen (1B) + PAD (0-3B) + NextHdr (1B) = 18
+ 0-3 байта overhead. Причём от IV (вместо него использовать ESN) или
SEQ можно было бы для AEAD-ов где это всё счётчики и избавиться уж, но
стандарты гласят вот так.
WireGuard (из его whitepaper): type+reserved (4B) + counter (8B) + I_m
(4B) + UDP заголовок (8B) = 24 байта. В любом случае чуть больше ESP.
Но, при этом ещё и CRC надо считать в UDP заголовке! Хотя он и не нужен,
ибо и так данные аутентифицируются. Так что даже в теории он любом
случае чуть менее эффективен. На практике парсинг ESP возможно отъедает
и больше CPU из-за if-ов всяких, но это уже вопрос конкретной
реализации, которую можно и упростить/ускорить.
Ну а ChaCha20+Poly1305 для ESP уже есть: https://tools.ietf.org/html/rfc7634
И если мне нужно обеспечить защиту только между двумя IP-адресами, двумя
хостями, то в WireGuard-е пришлось бы шифровать IP-пакеты -- это же VPN,
а в IPsec использовать транспортный режим где внутри ESP будет лежать
сразу же TCP/UDP/SCTP/whatever. Но это конечно вопрос решаемых задач. Но
вот у меня по факту нигде нет туннельного режима IPsec, хотя есть пара
туннелей gif-туннелей между двумя хостами, а в остальном только
транспортные между хостами, чтобы не городить между ними никаких
костылей в виде TLS.
Sergey Matveev [Mon, 9 Nov 2020 10:27:27 +0000 (13:27 +0300)]
Время-вперёд Свиридова
https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%BC%D1%8F,_%D0%B2%D0%BF%D0%B5%D1%80%D1%91%D0%B4!_(%D1%81%D1%8E%D0%B8%D1%82%D0%B0)
А ещё, когда вспоминал про "трэки vs альбомы" (d0f0adae0afb2d1690b93a924f032582fb19900d)
не упомянул что совершенно не знал про "Время-вперёд" Свиридова. Я до
Олимпиады-2014 считал что мотивчик с трубами это просто такая здоровская
заставка к телепередаче Время. Впервые услышал (почти) дальнейшую тему
этой композиции только при просмотре открытия в Сочи. Офигеннейшая! Да и
только эту "красную" часть открытия я лучшего всего и запомнил,
наверняка из-за музыки.
Sergey Matveev [Mon, 9 Nov 2020 09:25:40 +0000 (12:25 +0300)]
Как автор curl работает с git-ом
https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/
Всё банально и ничего особо интересного. Но вот обратил внимание что он
не использует git stash, потому что проще сделать отдельную ветку и в
ней коммит. В принципе то оно конечно верно, без stash жить можно. Но...
как я писал в 3605f863a029ba28f8258bc023f94ef1045b20dc -- огромная куча
команд git-а это сахар просто упрощающий жизнь. Лично у меня stash
использует супер часто. Даже не смотря на то, что у меня алиасы на git
branch (Gb) и git checkout (Gc), я всё равно не смогу делать всё так же
быстро и удобно как с git stash-ом. В котором я кстати только в это году
научился (точнее наконец то задумался) делать git stash push
определённых файлов.
Ну тут у каждого свои вкусы и предпочтения. Коллеги любили делать git
remote update, а я никогда, ибо только git fetch. Многие любят делать
git checkout -b, а я только отдельно git branch и git checkout команды
по отдельности (точнее их алиасы). Опять же, куча команд которые чего
только не умеют делать. git pull делаю только если уверен в результате
(мой remote, состояние которого я знаю) или добавляя какой-нибудь --rebase.
Sergey Matveev [Mon, 9 Nov 2020 07:39:12 +0000 (10:39 +0300)]
Маски-шоу
https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D0%BA%D0%B8-%D1%88%D0%BE%D1%83
https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D0%BA%D0%B8_(%D0%BA%D0%BE%D0%BC%D0%B8%D0%BA-%D1%82%D1%80%D1%83%D0%BF%D0%BF%D0%B0)
Глядя на фильмы Чаплина, постоянно про себя вспоминал про сериал
Маски-шоу, который обожал смотреть по ТВ, когда попадал на него.
До сих пор в голове кучу сценок оттуда помню. А озвучка... по ней
сразу передача узнавалась и существенный вклад в забаву именно она
и вносила.
Sergey Matveev [Mon, 9 Nov 2020 07:29:58 +0000 (10:29 +0300)]
Посмотрел "Золотую лихорадку" Чаплина
https://ru.wikipedia.org/wiki/%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%B0%D1%8F_%D0%BB%D0%B8%D1%85%D0%BE%D1%80%D0%B0%D0%B4%D0%BA%D0%B0_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Конечно же понравилась! Очень впечатлён сценой с домом на краю пропасти.
Так классно сделано, без каких-либо этих компьютеров! Ну и вот фильму
будет почти скоро как сотня лет, а женщины как играли ради забавы с
чувствами мужчин, так и продолжают в своём духе.
Sergey Matveev [Sun, 8 Nov 2020 16:58:58 +0000 (19:58 +0300)]
Попробовал WireGuard
Я его одобрял, но на деле ни разу не пробовал использовать. Использовал
wireguard-go реализацию и wireguard-tools. Всё собралосб без проблем. С
первого раза всё настроил -- всё заработало, как по маслу. iperf3
показал сильно скачущую скорость, но достигающую 800 Mbps между IPv6
адресами поверх туннеля тоже по IPv6. Для userspace Go реализации я
считаю это отлично. В своём GoVPN я достигал вроде только 700 с чем-то
Mbps. Продолжаю и дальше одобрять этот VPN! Я всё равно по технической
возможности стал бы использовать IPsec (собственно, он у меня везде и
используется), но когда надо пробиться VPN-ом за NAT-ом, то IPsec не
подходит.
Sergey Matveev [Sun, 8 Nov 2020 15:48:27 +0000 (18:48 +0300)]
Посмотрел "Удар головой"
https://ru.wikipedia.org/wiki/%D0%A3%D0%B4%D0%B0%D1%80_%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Ещё один хороший французский фильм. В котором Франсуа Перрена играет не
Пьер Ришар, что непривычно. Показывает что не надо опускаться до уровня
всяких уродов и вести и отвечать им также как и они бы поступали. В
фильме типа они сами себя наказывают. Но то фильм, а в жизни даже с
судами фиг добьёшься справедливости.
Sergey Matveev [Sun, 8 Nov 2020 15:29:20 +0000 (18:29 +0300)]
Посмотрел "Огни большого города"
https://ru.wikipedia.org/wiki/%D0%9E%D0%B3%D0%BD%D0%B8_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%BE%D0%B3%D0%BE_%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0
Очень понравился! Оторвать от Чаплина глаз сложно, да как и от красавицы
главной героини. Всё что видел с ним по телевизору нравилось всегда!
Sergey Matveev [Sun, 8 Nov 2020 12:52:10 +0000 (15:52 +0300)]
Ctrl-F в режиме редактирования строки
Пару недель назад коллега поделился обнаруженной в Vim командой Ctrl-F в
режиме командной строки: оно вызывает "q:" окно, в котором и текущая
строка есть, которую можно отредактировать обычным модальным способом.
Часто хотелось отредактировать строку в Vim-е в ":" через Vim :-). Но
явно плохо искал в документации или забивал на это, или вообще
редактировал строку просто в файле, а дальше копировать в регистр и
выполнял его. А Ctrl-F офигенная штука, нужно не забывать про неё, хоть
и не часто требуется!
Sergey Matveev [Sun, 8 Nov 2020 11:21:23 +0000 (14:21 +0300)]
10 простых шагов захождения на сайты в 2018 году
Нашёл в одном журнале:
1. Открываешь сайт.
2. Отказываешься от пуш-уведомлений.
3. Закрываешь уведомление о кукисах.
4. Закрываешь попап с предложением подписки.
5. Закрываешь онлайн-чат.
6. Закрываешь окошко «Ваш город....?».
7. Закрываешь окошко «Не нашли что искали? Оставьте телефон, мы сразу перезвоним».
8. Закрываешь попап «Подпишитесь на наши соц. сети».
9. Извиняешься перед окружающими за свои громкие маты
10.Вспоминаешь, зачем открыл сайт
Sergey Matveev [Sat, 7 Nov 2020 20:13:57 +0000 (23:13 +0300)]
Спешка людей, качество работы, музыка
Недавно критиковал мысль друга, который считает что темп жизни стал
быстрее и времени у людей мало на что стало хватать, поэтому всё нужно
здесь и сейчас.
Не спорю что очень многие стали всюду и везде спешить. Вот только...
кому это надо и кому от этого лучше? Если бы они успевали делать больше
чем "не спешащие" -- ok. Вот только беда в том, что это не так. Людям
нужно узнать ответ на вопрос "почему мой nginx вот тут не работает"
здесь и сейчас в stackexchange/google -- на этот вопрос они, допустим,
получат ответ, вот только ни знаний, ни понимания он не добавит. У них
будут снова и снова возникать аналогичные вопросы, тогда как один раз,
посидев подольше с документацией, пошевелив мозгами, можно впредь все
эти вопросы закрыть. Но о гугл-программистах уже писал: 7cdc4d886c28ff3b454a20f3328c9b6f5ff69036
Почему то очень хочется вставить цитату Пратчетта (хотя может и не к месту):
Дай человеку огонь, и ему будет тепло до конца дня. Подожги
человека, и ему будет тепло до конца его жизни.
Побыстрее пройти курсы, побыстрее пройти tutorial -- всё ведёт к
непониманию и дорогой цене такого сотрудника, который и обманывает
надеждами и ожиданиями, и за которым или переделывать всё надо или
доделывать или помогать постоянно.
С одним коллегой мы лучше других знаем Vim только потому, что когда
понимаем что сейчас что-то явно можно лучше в нём сделать для какого-то
редактирования, то мы остановимся и пойдём искать нужное в документации.
Иногда просто так читаем документацию, какие-то её разделы, ибо
информации много, но каждый раз что-нибудь от отложится в голове.
Встречал людей которые годами пользуются Vim, но, с моей точки зрения,
не намного дальше vimtutor ушли. Оно конечно уже всё равно эффективнее
чем блокнот/nano/whatever, но чем больше познаёшь инструмент, тем больше
понимаешь и ценишь как он экономит наше время. Можно сразу после школы,
а то и недоучившись пойти работать, а можно ещё несколько лет потратить
на обучение и получить базу знаний которая будет фундаментом до конца
жизни, стоящего этих лет.
Во всем конечно нужно знать меру -- постоянно обучаться и
совершенствоваться и читать всё на свете, готовиться ко всему что
придумается -- так можно и до конца жизни ничего и не начать уж делать.
Делом тоже нужно успеть заняться. Кто-то долго проектирует, потом не
успевает реализацию сделать. Кто-то слишком мало проектировал и плохо
продумал то, что уже успел реализовать, а потом будет расхлёбывать и
мучиться с этим поделием.
Недавно с отцом говорили о гитарах и музыкантах и есть известный факт
что многие хотят и мечтают стать рок-звёздами (ok, мечтали, раньше --
теперь мечтают рэп-звёздами или это уже тоже вышло из моды?), особенно
гитаристами, но только мало кто, особенно будучи подростком, понимает
что знание трёх аккордов и умение фигачить как Ангус Янг -- разделяет
гигантская пропасть. Все эти наши великие гитаристы всю жизнь, грубо
говоря, каждый день часами пилят и пилят, пилят и пилят одно и то же.
Это колоссальное дрочево, колоссальный труд. У большинства людей
терпения на это не хватит. А видят люди только получившиеся сливки их
работы -- концерты и выступления. Запись альбома может длиться
относительно недолго, типа арендовали сколько-то раз студию, записались,
потом отдельно где-то это всё сводится. Но перед этим годами пилят и
пилят одно и то же. Папа то у меня играл в ансамбле на гитаре и до сих
пор дома её в руки берёт. А я пробовал научиться, даже ноты научился
читать (сейчас то конечно уже забыл), но понял что я не настолько хочу
играть, ибо это чёртова прорва времени нужна и терпения.
Но профессиональная ИТ тема уже обмуслёкана много раз. Для меня это
факт: спешащая молодёжь, контролируемая ответами гугла -- дороже
обходится всем, сколько бы она не пыталась побольше и побыстрее сделать,
ибо качество плачевное, зачастую труд вообще не стоящий начинания. Но и
по жизни у них, как мне представляется по рекламе/фильмам, вдалбывающим
спешку -- быстрая еда, быстрый секс, быстрые решения. А быстрые решения,
чаще всего, необдуманные. Предварительные ласки и ухаживания, всё равно
закончатся тем же сексом, с тем же результатом, вот только эмоций и их
сила не в сравнение больше.
Идёшь куда-нибудь, пересёкся на улице со старым знакомым. Ты рад ему,
многое хотел бы расспросить, но зная что у вас около полуминуты времени,
ибо вы оба имеете дела, ты не будешь задавать вопросы о жизни и прочем,
кроме чисто для галочки. Ты бы мог за полминуты узнать как и где живёт,
где работает, женат ли, есть ли дети, всё такое прочее, но вот так вот
шустро полученная информация будет сродни допросу. По хорошему можно
договориться о встрече в обстановке без ощутимых временных ограничений.
Тут можно было бы как-раз и сказать: вот, все всюду спешат и свободное
время -- роскошь. А я скажу что это люди себе (точнее СМИ) вбивают что
они как-будто такие занятые. По хорошему можно прям сейчас на улице было
бы оторваться от похода в магазин или какому-то запланированному
посещению инстанций, но они никуда не убегут, а вот с другом/знакомым ты
уже возможно не пересечёшься. Уверен что мало кто когда пожалел бы о
таком спонтанном забивании на дела, ради разговора с другим человеком.
Нам вбивают эти ценности спешки, которые не дают ничего полезного в
жизни, разве что чуть более скоростное перемалывание дел в обществе
потребления, где выгода будет только производителям, где спешащие люди
ими не являются.
А вообще хотел написать про музыку. Сегодня вот упомянул про Peccatum и
Starofash группы. И особенно у Starofash есть много длинных композиций.
Пять минут может идти медленная полу-унылая мелодия, а потом что-то
забойное. Даже в black метале типа Funeral Mist есть трэки за 10мин. И
вот я подумал что ведь все эти спешащие люди в принципе не стали бы
слушать такую музыку. Её не поставят по радио, ибо можно было бы
проиграть в три раза больше трэков, между которыми вставить рекламу. На
работе с коллегой выяснили что в целом (в основной массе) люди перестали
слушать альбомы. Они слушают единичные трэки. Этот же коллега тоже
альбомы не слушает. Почему то в блоге об этом не писал, но что несколько
лет назад, что сейчас я считаю что половина рок-музыки которая у меня
есть: по настоящему воспринимается только прослушивая целым альбомом.
Когда-то я был просто шокирован прослушиванием альбома Pink Floyd "The
Wall". Все знают и все слышали основной трэк с детским хором из него. И
я лет 20 его знал и слышал. Но как-то дома, вроде папа, поставил
полностью этот альбом. К этому трэку очень долго всё подходит, но оно
настолько хорошо с ним сочетается, что у меня точно были мурашки по коже
от ощущений! Можно сказать, что я за 20лет слушания -- впервые его
услышал и прочувствовал!
Gorguts "Colored Sands" (fc345478530d9a9161fa81f9ecabdec6aa876d40) --
если с него поставить сразу "Enemies Of Compassion", где сразу бойкое
рубилово, то... не, удовольствие конечно получишь, бесспорно, но не
такое как если бы перед этим играл симфонический "Battle Of Chamdo"
трэк. И тем более не такое как если перед ним все остальные четыре
трэка. Это совершенно разные уровни впечатлений!
Есть много альбомов (какой-то от Flying Colors, какой-то от Fredrik
Thordendal, да тот же Pleiades' Dust от Gorguts) которые можно считать
одним большим трэком. Да, какие-то части нравятся больше, их можно
переслушать, но они не могут восприниматься отдельно от всего
остального. Если бы на альбомах Starofash вырезать унылые пианино,
оставив вокал Ihsahn-а с электрогитарами... это уже совершенно не то.
Тоже имеет ценность, но не такую, не с такими сильными ощущениями.
Ещё в школе один друг спросил почему на "Secret Of The Runes" Therion-а
два последних трэка на альбоме (кавер на "Summernight City" ABBA и
Crying Days) помечены как "бонус", разве на других релизах альбомов их
нет? Блин, да ведь там все они объединены одной общей тематикой,
(Ginnungagap, Midgård, Asgård, Jotunheim, Schwarzalbenheim, Ljusalfheim,
Muspelheim, Nifelheim, Vanaheim, Helheim), а тут внезапно появится ABBA?
Наборы медленных и быстрых композиций создают общую атмосферу. На
переходах сильнее всё чувствуется.
На концертах стараются давать разогрев! Бывают концерты без него, и
вроде бы и группа которую годами ждал, и играют здорово, но ты не
накачан энергией. На концерте люди как конденсаторы -- без заряда
колбаситься сложно начать. А ещё в самом начале концерта нужно тупо и
привыкнуть ушами к звуку. А ещё когда выступление группы начинается, то
куча людей передислоцируется кто подальше от сцены, кто поближе и это
отвлекает. Поэтому я считаю ОЧЕНЬ круто что Rammstein в прошлом году
(смотрел только видео) вышли с каким-то вообще медлячком заупокойным.
Я к тому, что больше ощущений, эмоций от жизни получается когда есть
ожидание (там где надо), когда есть с чем сравнивать, когда есть время
на "накачку" энергией, когда есть время на длительные ласки, вместо
быстрого пятиминутного секса, когда есть время на обдумывание решений.
Здесь и сейчас это синоним -- не думай о последствиях, оторвись. А
отсюда и наркоманы, оторвавшиеся в своё время. Залётные дети от
родителей у которых и чувств то друг к другу не было никаких, кроме
быстро удовлетворённой похоти. Это общество потребления -- где думают за
тебя рекомендательные системы и "гуглы". Где тебе не дают времени на
принятие решений, потому что вот прям здесь и сейчас могут что-то
оформить или сразу же дать товар (ещё и со скидкой).
Повторюсь что во всём нужен баланс и мера. Быть нерасторопным и
медлительным тоже наверное плохо. Шустрая молодёжь наверное побольше
успевает попробовать... что можно быстро попробовать. Но вот например
как минимум половины рок музыки люди уже не в состоянии воспринять и
получить непередаваемые эмоции, ибо альбомы люди не слушают (а я с
трудом вспоминаю когда я отдельно трэк то себе ставил, не говоря про
shuffled проигрывание). Безусловно отдельным трэкам и сборникам есть ещё
какое место в жизни! Много мест где музыкальный фон бы не помешал, но
времени всего 15мин например. Или я вот поставлю далеко не каждый
альбом, если знаю что меня могут прервать (куда-нибудь пойти), отвлечь и
всё такое (лучше не слушать, чем оторваться от прослушивания, пускай
даже в фоне пока пишешь код -- это как не кончить: лучше даже и не
начинать тогда).
Пускай у меня относительно редко появляются новые альбомы или знакомства
с группами, но, я считаю, зато получаю больше эмоций и впечатлений.
Доступность, частота -- обесценивают общение, секс, да и всё что угодно.
Я вот в прошлом/этом году смотрел сериалы разные и у меня возникала
пустота когда он (или его сезон) заканчивался. Сильное желание
продолжить второй сезон или ещё чего начать смотреть. А если потерпеть и
подождать, то желание и пустота пропадают и ты рад что не стал убивать
время этой сериальной жвачкой. Лучше редко, да метко. Реже что-то
посмотреть, но качественнее. Ведь в целом достойные фильмы ой как не
часто появляются.
И по жизни у меня как-то двояко получается: с одной стороны я против
спешки именно в жизни. Если я весь в работе, но мне позвонила мама
предложив пойти с ними погулять по нашему королёвскому парку, а я
разозлён от того что я только начал, только вошёл в раж и работа идёт
как по маслу -- но с годами я понимаю что общение с людьми (близкими)
сильно ценнее. Именно с близкими, друзьями, родственниками, возможно
коллегами. В этом году я понял что (@#$%!) без отдыха, но не выходит
работать, можно выгореть. И это будет дороже чем... если бы не выгорать
и своевременно например отдыхать (по ivi я помню, что доходил до такого
состояния что или разосрусь так что меня обязаны будут уволить, или...
меня директор просто насильно, похоже очень хорошо понимая людей,
выгонял в отпуск, после которого всё нормализовывалось). С другой
стороны я всегда быстро хожу, ненавидя неспешное передвижение людей,
ведь какой-то толк тратить время на перемещение? Мне доставляют почти
физические страдания наблюдения за тем, как люди медленно редактируют
текст (плохо зная редактор или не используя эффективный редактор
(+возможно клавиатуру, променивая эстетику на эффективность)). В меня
вселяется бес когда я вижу как на смартфонах людей или в броузерах с
JS-ом еле-еле неспешно загружаются и подгружаются с крутилками и
свистоперделками анимированными их сайты. Сейчас меня вообще много что
бесит, особенно когда вот юзаешь go, C, redo, Ethernet (вместо WiFi,
который вижу у других людей). Возможно я просто всё смешал: работа
работой, а общение/развлечения это уже другое, а обучение так вообще
третье.
Но если брать эффективность клавиатур/редакторов, то некоторые говорят
что они много думают, но мало набирают. Ok, допустим, и моя специфика
работы другая. То что надумал -- надо ещё в сотнях и тысячах строк кода
оформить. Мне не раз говорили что я много пишу текста (письма там)
потому что могу, потому что клавиатура тактильная. И любой большой
текста значит написан "ещё одним с тактильной клавой". Тоже возможно
верно и возможно мне не стоит изливать мысли потому что могу, а лучше бы
пошёл спать в час ночи (сейчас) и было бы больше проку :-). Но в целом,
считаю, спешка мало чего хорошего даёт. "Поспешишь -- людей насмешишь!"
Есть места где стоило бы (не ждать например полдня другого самолёта,
потому что пару минут кто-нибудь не удосужился поднапрячься и поспешить,
раз проспал), но в целом в жизни спешка полезна только изредка.
Постоянная -- приводит к гугл-программистам и отсутствию кучи эмоций,
переживаний и ощущений.
Есть правда и действительно нагруженные по работе люди, на которых всё
взвалено, всё от них зависит, и т.д.. Но это же тоже проблема, что нет
больше никого, что ни на кого нельзя передать нагрузку. Вообще мне бы
было приятно что от меня что-то важное бы зависело (значит я чего-то да
стою), но всему нужна мера и рано или поздно ноги человека подкосятся
под тяжестью и всем будет дороже его потеря работоспособности. Но это
скорее речь про заменяемость людей: незаменяемым быть лестно и приятно,
но в целом всем окружающим это очень дорого. Поэтому хорошие
руководители должны избавляться от незаменяемых людей (в том плане, что
они должны передавать опыт/знания/умения, делать всё чтобы
минимизировать фатальность их ухода/потери/наглости). Вот только где
найти им замену/подмену...
Sergey Matveev [Sat, 7 Nov 2020 13:17:18 +0000 (16:17 +0300)]
RPi400 как старый добрый Спектрум
https://martinpeck.com/blog/2020/11/06/Raspberry-Pi-400/
Тоже в детстве подключал Спектрум к телевизору и магнитофону. Вот только
у нас был не красивенький встроенный в клавиатуру, а отдельная коробка с
разъёмами от космических аппаратов, к которой отдельно клавиатура
подключалась.
Sergey Matveev [Sat, 7 Nov 2020 09:56:52 +0000 (12:56 +0300)]
Заценил Peccatum и Starofash
https://en.wikipedia.org/wiki/Peccatum
https://en.wikipedia.org/wiki/Starofash
https://www.youtube.com/watch?v=xkYQXS4_R-E
На одном альбоме Ihsahn-а заинтересовался что за женщина поёт. Оказалось
что его жена, с которой у него даже совместный проект Peccatum. А потом
у неё свой Starofash.
В целом оба проекта понравились. Много правда есть унылого и неспешного,
особенно у Starofash, где даже по пять минут нет ни одной электрогитары.
Но я успел даже по два раза все альбомы прослушать. Ибо есть пять минут
уныния, а потом что-то клёвое и забойное.
Ну а Ihsahn вообще офигенный! Всё что с ним не слышал -- всё очень
здоровское и достойное! Emperor, сама его группа Ihsahn (выступление
которой в живьём не забуду, особенно мрачнейший The Grave впечатлил) и
вот эти ещё две. Плюс в скольких он проектах не подпевал как гость --
всегда голос узнаётся. Альбомы самого Ihsahn я за последние дни
переслушал по несколько раз. Причём у него же вот и совсем спокойные
есть (с выступления в Москве): https://www.youtube.com/watch?v=zuS_bj3N2mc
но и тот же Grave: https://www.youtube.com/watch?v=1Mrc9za28Ck
Sergey Matveev [Sat, 7 Nov 2020 09:08:18 +0000 (12:08 +0300)]
Команды git-а: worktree, subtree
https://blog.meain.io/2020/bunch-of-git-stuff/
Показаны примеры применения относительно новых команд worktree/subtree.
Первую я на практике использовал несколько раз -- есть случаи когда
реально полезно и удобно с ней. Но запросто у человека может и не
возникнуть надобности в ней. subtree не использовал, и вот с ходу пока
даже не могу представить когда бы понадобилась лично мне (так то в
статье есть примеры).
Вообще если бы я не знал git, то судя по статьям/рассылкам/блогам вряд
ли бы к нему подступался, ибо только ленивый не говорит что он дико
сложный и не понятный. Это также подтверждалось постоянно и на работах,
где люди с трудом въезжают в него. Да и если объективно прикинуть, то
достаточно посмотреть на git reset: что делает эта команда? Чего только
не делает! git checkout? Аналогично! Ну или я (до сих пор), как минимум,
не в состоянии коротко и ясно сказать для чего они. Они много для чего и
это увеличивает порог входа.
В ivi из-за плохих пониманий git-а (точнее применимости и допустимости
некоторых практик) некоторым командам запрещалось делать git cherry-pick
или rebase-ы, особенно интерактивные. git -- мощный инструмент, но
который в "плохих" руках может и вредить. Защиты от дурака в нём не много.
У меня никогда не возникало проблем с git-ом. Во-первых, мне никто
никогда с ним не помогал -- весь путь его "познания" проходил сам (с
коллегами). Во-вторых, мне кажется я использовал его фичи только после
их познания/узнавания и у меня не возникало потребностей в том что не
знал. Возможно просто везло, а не как новичкам приходящим в команду и
которых сразу бросают в пучины git rebase. Плюс мне кажется что на меня
снизошло какое-то озарение после прочтения:
http://www.ftp.newartisans.com/pub/git.from.bottom.up.pdf
после которого git выглядит чрезвычайно простой штукой.
git в целом и есть простая нехитрая и незатейливая штука. В нём немного
примитивов и действий как таковых. Просто десятки команд это помощники
для разных ситуаций. Это сплошной сахар. Одно и то же действие в git
можно выполнить, зачастую, тьмой разных способов (наборов команд). У
людей даже разные привычки как и что выполнять, хотя результат будет
один. А возможно и не один, но в одном случае будет какой-нибудь
конфликт в файлах, а в другом уже нет. И всё это создаёт сложности
(видимость), но на самом деле никакой магии нет.
Я не использовал ни Mercurial (только hg pull/clone), ни Bazaar, ни Arch
(на который вроде как и забили), ни Darcs. Читал про них. Mercurial
выглядит чище и проще, не является нагромождением всего и вся
раскиданным и пересекающимся в разных командах. Но про него от очень
опытных пользователей, которые и хорошо умеют git, наслышан про его
негибкость и сложности делать относительно сложные вещи. Для новичков
Mercurial, насколько понимаю, хорош, но для людей которые чётко понимают
что хотят сотворить с историей коммитов -- он будет занозой. Просто
наслышан о таком мнении от самых разных опытных людей, которые в итоге
переходят на git.
А ещё отдельная боль с git-ом это Github. Точнее проблема с людьми,
упорото считающих что git и Github это синонимы. Github закрывает
репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только
ленивый не напоминает в комментариях всяких ресурсов что git как бы
децентрализованная система.
В общем, git штука с большим порогом входа, в том числе из-за неряшливых
команд, но очень мощный инструмент. И из-за своей мощности (возможностей
тасовки и вообще работы с коммитами) он стоит изучения/использования.
Можно не знать и 90% всех его имеющихся команд и их опций и отлично жить
с ним.
Sergey Matveev [Fri, 6 Nov 2020 15:45:16 +0000 (18:45 +0300)]
Синхронные и асинхронные коммуникации на работе
https://habr.com/ru/post/526754/
Во-во-во! Все точно и по делу сказано! И БЕЗУМНО печально что многие
люди не понимают всего написанного. И крайне удручает когда на работе
вместо асинхронных методов становятся популярны синхронные, ведь это же
(@#$%!) так удобно, так быстро и шустро все стали отвечать красотке Оле!
А ещё удручает когда молодёжь, по жизни не пользуясь асинхронными
методами общения, и не умеет, и не понимает и не знает как использовать
тот же email/tracker. Или использует tracker "на отвали" чтобы там
надоедливому менеджеру завести всё же тикет, вот только при этом он ещё
и сразу напишет в синхронном общении о том что он сделал тикет. И
полностью поддерживаю основную мысль:
Самая важная мысль. Асинхронная коммуникация -- это прежде всего
уважение ко времени и планам, а также ко вниманию и сосредоточенности
коллег.
Хотя конечно есть и крайности этого подхода, когда можно неделями по
неспешной, уважающей окружающих, почте ни к чему не приходить и долго
мусолить. Иногда бывает надо и полезно собраться синхронно всем
пообщаться. И тут тоже крайность часто бывает: регулярные собрания с
кучей воды и болтовни не по делу или когда есть много людей которых не
касается обсуждаемый вопрос. И ладно бы потерпеть 5мин, если бы они
длились столько.
Sergey Matveev [Fri, 6 Nov 2020 08:34:24 +0000 (11:34 +0300)]
Посмотрел "Чапаева"
https://ru.wikipedia.org/wiki/%D0%A7%D0%B0%D0%BF%D0%B0%D0%B5%D0%B2_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Кроме фильмов Чаплина, даже не вспомню что я ещё настолько старого смотрел.
Фильм очень понравился! Очень необычно сейчас такое смотреть -- совсем
по другому постановка сделана. В начале то так вообще просто небольшие
сценки, как бы не связанные между собой. Треть фильма я как-будто уже
знал, ибо столько фраз узнавал! А развязка фильма, с концом Чапаева,
сделана так коротко и быстро! И если в этом фильме она занимала,
допустим 30-40% (ну так, на память/на глаз) фильма, а всё остальное это
набор очень смешных сцен, то в современных фильмах бы на смешное
оставили 20%, дальше 60% времени медленно и угрюмо бы показывали
неспешную нагнетающуюся развязку, немного action-а, а дальше ещё минут
15 все бы горевали и грустили под унылую музыку. А тут -- пострекотали
по плывущему Чапаю и сразу титры. Но очень много смешного и забавного в
нём -- это запоминается!
Sergey Matveev [Fri, 6 Nov 2020 08:28:57 +0000 (11:28 +0300)]
gu в Xombrero
В Xombrero броузере есть "gu" команда, которая переходит на URL на
"ступень выше" -- отрезает слово до следующего слэша. Очень часто
хочется отрезать больше чем один слэш, например когда я в каком-то блоге
на "://.../whatever/2020/01/02" и gu меня бросит на "://.../whatever/2020/01",
потом на "://.../whatever/2020", и т.д.. А часто бывает так, что перейдя
по уровень выше, тебе сделают редирект снова на низлежащий уровень. И
мне приходится уже "O" командой редактировать ссылку, backspace-ом
удаляя нужный кусок URL-а.
А вчера у меня какой-то нейрон сказал голове "а что если добавить
число перед gu, как в vi можно же для кучи команд добавить число". И
действительно "3gu" сразу откидывают до трёх уровней. Почему мне эта
идея в голове не приходила столько лет и сколько времени я терял на
ручное удаление?! Ну или почему я так плохо читаю доки?
Sergey Matveev [Fri, 6 Nov 2020 08:22:01 +0000 (11:22 +0300)]
Обновление matterircd
Обновил локальный matterircd: мост между Mattermost (который у нас на
работе используется) и IRC клиентом.
Пока возился с обновлением, смотрением как какие опции конфига влияют на
поведение, заметил что MM в целом очень не прочь потерять сообщения. Раз
в несколько месяцев но выясняется что какие-то сообщения я не видел и их
реально нету в логах irssi. А выясняется когда точно известно что что-то
посылали или точно на что-то ждёшь ответа. Причём matterircd использует
прям буквально ту же самую кодовую базу что и сам сервер MM. Так что MM
вообще не гарантирует доставки.
Но обновлённый мост добавляет трёхбуквенные hex-префиксы (XXX) к
сообщениям и пишет какое именно сообщение было отредактировано, удалено
или на какой тред это ответ. Прежде он писал в скобочках полностью всё
цитируемое сообщения треда, которое могло быть огромным и частенько
глазами просто было не понять где находится само сообщение написанное
пользователем. Плюс если добавить "@@XXX", то можно явно сказать что это
идёт ответ на определённое сообщение.
s/XXX/ позволяет удалить своё сообщение, а s/XXX/new text --
отредактировать. Но там нужно самостоятельно высчитывать номер *своего*
сообщения и у меня это плохо выходит и мне логика не всегда понятна их
нумерации (как-будто даже какой-то баг).
Sergey Matveev [Fri, 6 Nov 2020 07:04:04 +0000 (10:04 +0300)]
Почему я считаю man-ы плохим форматом документации?
Мне казалось что об этом писал в блоге, но что-то с ходу не нашёл.
man-ы мне в первую очередь не нравятся тем, что в них нет ссылок и
возможности перехода по ним. Напишут "смотрите EXAMPLES", и вводи
"/EXAMPLES", а ещё лучше с не забывать "/^EXAMPLES". Напишут смотреть
другой man, и снова делать это всё руками. А как открыть man сразу на
нужной секции? Штатного способа не предлагают. Хотя можно и сделать хак
в виде: man -P "less +/^EXAMPLES" ...
Другое дело info! То самое, что является единственным и основным
форматом документации в GNU. Оно уже структурировано, имеет ссылки. По
сути это уже гипертекстовый документ/формат, куда раньше появившийся чем
HTML. Можно одним вызовом (-n опция) прыгнуть на нужные ссылки/ноды.
man для простых и коротких команд, чисто классических по идеологии Unix,
ещё терпимо, так как зачем им ссылаться на что-то, ведь команда
выполняет свою чётко заданную работу. Но огромных программ тоже не мало.
Один GnuPG чего стоит (но у него и info есть (собственно, man-ы в нём из
него делаются)). А вот когда речь про документацию на библиотеку (C), то
без ссылок жизнь не мила. Один man perl содержит *только* ссылки на
несколько десятков других man-ов, как и man zsh содержит ссылки или иди
в zshall.
info ещё приятен тем, что он сам по себе human-readable формат, который
можно и без дополнительного ПО прочитать. man не читабельный, но его
формат всё же достаточно прост для простых утилит -- да и кто когда-либо
жаловался на то, что он не может прочитать man? Идеология вызова
каких-нибудь eqn и tbl процессоров (в дополнении к troff) мне нравится
даже больше чем жёстко отрендеренный info. Но, так как на практике это
всё равно всё смотрится в терминале, то желания перерендерить не
возникает -- is good enough.
Как альтернатива info мог бы выступать HTML, который тоже из терминала
можно смотреть текстовыми броузерами. Но, если каждую ноду выносить в
отдельный .html, то нельзя будет искать по всей документации к
программе/библиотеке! А в .info можно по всей. Делать одну большую
.html-ку решает проблему, но её будет неудобно читать, но это уж можно и
потерпеть.
А если документация просто огромна? .info позволяет разделять её на
отдельные файлы:
где в головном .info есть ссылки на -[12], динамически подгружаемые
файлы по мере надобности. С .html такой возможности нет (если только не
терять возможность поиска). .info же делает это просто автоматически.
В общем случае .info позволяет и картинки встраивать (точнее ссылаться
на них, в отдельных файлах), но я видел работоспособность этого только в
Emacs графическом.
По мне так это прям чуть ли не идеальный формат для документации. Ok, на
самом деле Microsoft CHM тоже выглядит как в теории хорошая
альтернатива, если бы конечно не была проприетарной. Это и HTML, который
может быть перерендерен как надо (или в терминале смотришь, или в GUI на
4k мониторе), и ещё и сжат в одном bundle-е, и ещё и поиск по нему
возможен. С обычным .html, в принципе, тоже никто не запрещает
использовать grep по файлам, но удобно ли это? Но готовых решений для
.chm просмотра (с поиском) мне не известно чтобы написали, тогда как
.info существует уже больше тридцати лет (судя по Wikipedia, ссылающейся
на ITS Emacs, почти 40 лет).
Но .info ещё нужно и чем-то создать. Штатно предлагаемый GNU Texinfo это
отдельный формат мне так нравящийся!
* Писать руками .man -- небольшого размера ещё терпимо, но в целом
увольте этим заниматься!
* Писать HTML от руки можно, хотя и не очень удобно читать его исходный
код. Но терпимо, но всё же не даром не многие на нём пишут напрямую.
* Markdown -- полностью не признаю этот формат. Ибо НЕТ такого формата!
Есть только с десяток (больше?) разрозненных малосовместимых между
собой диалектов. И я уже десятки раз видел как кто-то даёт "markdown",
но именно моим процессором оно не обрабатывается. ОЧЕНЬ небольшое
подмножество будет работать гарантированно везде. Настолько небольшое,
что мне в принципе оно не интересно, ибо это несерьёзно. А писать на
"github markdown", "XXX markdown", "whatever markdown"... серьёзно?
* reStructured Text -- так как его реализаций не много (не одна ли
docutils?), то он будет работать, в отличии от Markdown, везде. Именно
reST, а не Sphinx надмножество. Мне он нравился и хоть он и зависит от
Python, но я на reST/Sphinx писал всё на свете. Даже web-сайты были
когда-то все на нём сделаны, ибо HTML выхлоп у него вполне себе
хороший. Но... его возможностей форматирования мне не хватало
частенько. Сделать жирную ссылку -- проблема (собственно, я даже не
помню можно ли это в принципе сделать). Делать сложные структуры с
многоуровневыми списками и табличками внутри -- ± можно, но уже очень
сложно читается и требует большой аккуратности из-за отступов.
Генерировать reST тоже становится проблематично
* AsciiDoc -- использовал его на первой работе (не мой выбор). Мало чего
по нему помню, но, хотя бы, это вроде бы действительно отдельный
нормальный формат, а не куча диалектов под одним именем (ненавижу
сраный Markdown!). git документация написана на нём. Выглядит как
хорошая альтернатива reST, но всё равно зависит от Python, в котором
де-факто reST
* Texinfo -- на этот формат я возможно не смотрел потому что он ещё с
80-х годов. Возможно потому что есть "tex" и кажется что имеется связь
с TeX. Но это лучший формат что я видел для создания .html (и конечно
же .info)! Некая золотая середина между гибкостью и свободой
самовыражения HTML и лёгкостью чтения/написания reST! Плюс написал на
C/Perl, поэтому работает очень быстро, не требует тяжёлых Python-ов.
Удобен для машинного генерирования. Удобен для работы в редакторе.
Имеет множество плюшек и сахара для создания документации по исходному
коду (reST не имеет, но Sphinx через директивы поддерживает).
Texinfo явно сильно заточен для создания доки по программам. Может
мешать местами его древовидная работа с нодами, однако такая же
древовидная требуется и в Sphinx например. Всё же Texinfo/Sphinx это не
general purpose средства, а для определённых задач. Но это всё равно
перекрывается простотой, гибкостью, удобством работы с ним. Вообще
Texinfo создавался сразу же и для того, чтобы из доки можно было сделать
.tex файлы и сразу из них отрендерить печатный вариант (книгу). Это
никогда не проверял как работает и априори полагаю что с кириллицей
возникнут проблемы. Sphinx тоже умеет генерировать .tex (LaTeX? не помню
уже), который с кириллицей не работал из коробки. .info файлы вроде
Sphinx-ом плохо генерировались.
А ещё, что скорее является anti-feature, но Texinfo это единственное
через что я смог сделать максимально работоспособный Word-compatible
выхлоп. Texinfo создаёт Docbook, который можно открыть в LibreOffice и
он его отлично отрендерит, даже со всеми таблицами и *почти* не
потерянным форматированием (насколько помню, только заголовки почему-то
были не нужного размера -- но они были всё же заголовками). Сделать
что-то из Sphinx-а, чтобы было так же похоже на ожидание, что через
*Office-ы можно было бы сконвертировать -- не выходило.
Когда я восхищаюсь огромному количеству документации в man-ах
OpenBSD/FreeBSD, то я восхищаюсь и аплодирую именно наличию
документацию, а не её формату. Но GNU выбор Texinfo/Info я считаю лучшим
что есть.
Sergey Matveev [Thu, 5 Nov 2020 15:08:33 +0000 (18:08 +0300)]
Почему федеративные системы не взлетают?
https://beldmit.livejournal.com/628814.html?nojs=1
Человек пишет что с 1994-го года был и в Фидо и где только не был и
всегда существовали централизованные системы, которые на порядки были
популярнее федеративных (автор пишет про распределённые, но я всё же
разделяю их с федеративными). И с причиной их популярности я полностью
согласен:
Причина провала скорее всего предельно проста. Порог вхождения в
централизованные системы низок, потому что коммерсанты это в
состоянии сделать.
Говорит что взлетели только электронная почта ("которая сейчас скорее
умирает, а коммерчески безнадёжна уже давно") и BitTorrent. В целом
согласен. Я бы ещё добавил news/NNTP (которые умерли). Ну и мне не
понятно в каком месте email умирает. Чтобы умереть -- нужно чтобы
появилась замена хоть какая-то. Для email-а её нет даже отдалённо.
Я бы ещё наверное добавил всё же RSS/Atom с домашними страничками и
блогами. У меня уже более 300+ feed-ов, и их количество только растёт,
ведь каждый год всё больше и больше людей слезает с соцсетей.
Sergey Matveev [Thu, 5 Nov 2020 09:28:32 +0000 (12:28 +0300)]
netpbm формат и генерирование картинки в 5LoC bash
https://www.vidarholen.net/contents/blog/?p=904
Я давний "поклонник" netpbm утилит и форматов. Мне кажется что уже
наверное лет 15 я для работы с изображениями только его и использую.
#!/bin/bash
exec > my_image.ppm # All echo statements will write here
echo "P3 250 250 255" # magic, width, height, max component value
for ((y=0; y<250; y++)) {
for ((x=0; x<250; x++)) {
echo "$((x^y)) $((x^y)) $((x|y))" # r, g, b
}
}
netpbm это набор утилит для работы с PNM файлами. PNM-ы бывают: PBM
(bitmap, монохромный), PGM (graymap, серый), PPM (pixmap, цветной), PAM
(цветной, ещё и с альфа-каналом). Каждый из них может быть представлен
в ASCII текстовом формате (как в примере выше), где задаётся формат,
размеры изображения и глубина на канал. Или в аналогичном, но бинарном
формате. Например когда я недавно занимался сканированием фотографий, то
мне надо было и обрезать, и scale-ить, и менять глубину цвета, и кучу
других подобных вещей. Изображение перегоняется в PNM, дальше через
pipe-ы применяются фильтры, дальше PNM преобразуется в нужный формат
(JPEG2000, WebP, и т.д.).
Ещё вот позже появился suckless проект: https://tools.suckless.org/farbfeld/
где формат тоже предельно прост:
8 -- "farbfeld" magic value
4 -- 32-Bit BE unsigned integer (width)
4 -- 32-Bit BE unsigned integer (height)
[2222] -- 4x16-Bit BE unsigned integers [RGBA] / pixel, row-major
В принципе мне он нравится больше, так как наборы PNM форматов это
только ведь об эффективности. Хотя... в том числе и про удобство для
генерирования/обработки наверное тоже, но преобразовать в RGBA и обратно
совсем не проблема. Из коробки farbfeld, конечно же, имеет и конвертеры
в PAM/PPM.
Sergey Matveev [Wed, 4 Nov 2020 11:58:46 +0000 (14:58 +0300)]
Закат useability
https://datagubbe.se/decusab/
Понравилась статья с примерами современных графических интерфейсов.
Аналогичное касается ведь и web-страничек. Почему у меня прям сразу же
рвотные позывы когда кто-либо предлагает через страничку в броузере
юзать какой-нибудь Mattermost? Да потому что рехнёшься пытаться понять
где там вообще элементы управления, не говоря об их использовании. Один
только факт когда убираются/исчезают полосы прокрутки... сколько же
ненависти это вызывает и непонимания как это используют, ведь автор
подобного интерфейса явно садист.
Sergey Matveev [Wed, 4 Nov 2020 11:18:15 +0000 (14:18 +0300)]
Впервые заюзал redo-stamp, хоть что-то кроме redo-ifchange
Хочется вшивать версию библиотеки в исходный код/документацию. Для
получения версии библиотеки я использую информацию о текущем git
коммите. Если сделать цель типа:
то она конечно сработает, но только один раз, так как у неё нет
зависимостей. Делать зависимости на .git/* объекты -- ну как-то не
хорошо, но (не проверял) наверное что-то типа (само собой, вместо cat,
надо использовать git команды для получения соответствующей информации):
redo-ifchange .git/`cat .git/HEAD | cut -d\ -f2`
Хочется сделать зависимость от вывода команды -- именно от вывода, а не
факта изменения файла с содержимым git-describe. apenwarr/redo, как и
redo-c смотрят на метаинформацию файла, а не на хэш от содержимого.
Поэтому задачу, без постоянной пересборки всего что зависит от версии,
не знаю как выполнить через redo-ifchange/ifcreate.
Но многие redo реализации имеют redo-stamp команду, которая позволяет в
зависимости добавить хэш от произвольных входных данных. Цель будет
выполняться/проверяться всегда, но считаться "обновлённой" только если
хэш поменяется:
Работает на ура! При пересборке проекта цель VERSION высвечивается, но
если её содержимое не меняется, то и зависимости не пересобираются. А
чтобы оно работало с redo-c, в котором нет redo-stamp, то я решил просто
проверять наличие этой команды, но уже конечно без пересборки если
версия изменится.
$ cat VERSION.do
[ -n "$VERSION" ] || VERSION=`git describe --tags @ 2>/dev/null || git describe --always @`
echo $VERSION > $3
if command -v redo-stamp >/dev/null ; then
redo-always
redo-stamp < $3
else
echo No redo-stamp command found: VERSION is built only once >&2
fi
Sergey Matveev [Wed, 4 Nov 2020 09:21:14 +0000 (12:21 +0300)]
Узнать размер файла в "Linux"
https://losst.ru/razmer-fajla-v-linux
Ох ох ох! Перемешаны намешаны ls/stat команды и du. Нельзя же так. du
показывает именно disk usage, который может *существенно* отличаться от
значения ls/stat из-за сжатия и sparse областей как минимум. Посмотрев
на du, может быть потом очень неприятно видеть что при копировании на
какой-нибудь FAT оно не уместится там.
Sergey Matveev [Wed, 4 Nov 2020 08:34:57 +0000 (11:34 +0300)]
Бойкотирование Wayland
https://www.opennet.ru/opennews/art.shtml?num=54022
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
https://refi64.com/posts/dont-boycott-wayland.html
Меня терзают смутные сомнения и воспоминания о том, что вот подобные
высказывания мы все где-то уже слышали, о том что всё ломается, все
заботятся только о GNOME, ничего не даёт действительно полезного и
нового:
В сообщении говорится: "Wayland не решает никаких проблем, которые у
меня есть, но ломает почти все, что мне нужно. И обычно оно остаётся
сломанным, потому что связанные с Wayland люди, похоже, заботятся
только о GNOME и отдаляют всех остальных в этом процессе. НЕ
УСТАНАВЛИВАЙТЕ WAYLAND! Пусть Wayland не уничтожит все, чтобы потом
другим людям не пришлось устранять ущерб, который он нанесёт. Или
сделайте больше Red Hat/GNOME-специфичных компонентов (glib, Portals,
Pipe wire) обязательными зависимостями!"
Ах да, всё это было уже про systemd :-)! Учитывая что творилось с
systemd и что всё завязывалось на GNOME -- поверю высказыванию Симона
Петера, ибо сложно поверить что GNOME-people могут достойно делать
достойные замены. Список того, что ломает Wayland, очень похож на
аналогичные списки того что творил/ломал systemd. История повторяется.
Хотя лично у меня особо никакого мнения нет. Я и X.org плохо знаю. Читал
про то, как работа с графикой идёт в Plan 9 -- вот это мне однозначно
нравилось своей незатейливой простотой. X.org выглядит монстром. Просто
Mir/Wayland не знаю. Если это сильно более простые штуки чем X-ы, то
одобряю. Но... боюсь что в "простоту" могут вкладывать совершенно другие
значения чем я представляю. Ведь кто-то умудряется говорить и про
простоту systemd, его модульность и прочее прочее. Но всё говорит про
то, что Wayland это классический продукт GNOME/Freedesktop.org, поэтому
мало чего хорошего (для Unix-like) системы ждать не приходится, ведь под
ними и DBus, PulseAudio, XDG_* -- то, чей подход в принципе мне чужд.
Хотя что-то из их https://www.freedesktop.org/wiki/Software/ использую.
Sergey Matveev [Tue, 3 Nov 2020 15:08:58 +0000 (18:08 +0300)]
Использую очередную библиотеку от DJB: libtai
https://cr.yp.to/libtai.html
https://cr.yp.to/proto/tai64.txt
https://cr.yp.to/y2k.html
https://cr.yp.to/proto/utctai.html
В одной C-шной библиотеке сделал возможность выбора между обычным POSIX
gettimeofday+localtime и libtai. libtai работает значительно быстрее
(ну, как минимум, потому что сама библиотека не занимается
форматированием вывода для человека), имеет простой интерфейс, всё что
нужно для сериализации/десериализации. Хочется наносекунды, хочется
аттосекунды -- отрезай сколько надо байт, делов то! А преобразовать в
человекочитаемый формат можно tai64nlocal утилитой из состава
daemontools, но уже асинхронно по времени.
Sergey Matveev [Tue, 3 Nov 2020 08:19:42 +0000 (11:19 +0300)]
Конец жёсткой воде
Все годы что я живу в своей квартире -- вода была очень жёсткой. Пару
раз вскипятишь воду в чайнике -- покроется дно известью, даже после
фильтра настольного. Но последние несколько месяцев дно чайника, как и
известковые разводы в ванне исчезли напрочь! Явно в доме что-то
установили/поменяли. Здорово стало, хотя меня особо и не напрягало.