Помощь нашим бойцам в крипте Ethereum. Bitcoin and Tether (USDTtrc20):

BTC - 357a3So9CbsNfBBgFYACGvxxS6tMaDoa1P

ETH - 0x165CD37b4C644C2921454429E7F9358d18A45e14

USDT (trc20) - TEFccmfQ38cZS1DTZVhsxKVDckA8Y6VfCy

Мы сделали очень простую страницу на английском языке для тех, кто хочет помочь Украинской Армии в войне с Россией.
Принимаем платежи с карты любого банка мира.

Пожалуйста, очень-очень вас прошу максимальный репост.
Передайте ссылку всем вашим друзьям иностранцам.
Но и сами можете платить, она работает и для Украинцев.
Огромное количество запросов на помощь из-за рубежа.
Нам так сильно нужна ваша поддержка, дорогие Друзья!

Слава Украине!

Ссылка:
https://uahelp.monobank.ua/

Dear friends,

Russia has invaded Ukraine and started a full-scale European war. As you reading this message - Ukrainian cities are being bombarded by Russian missiles, menacing troops are marching over the borders and arriving via the Black Sea as citizens are desperately trying to flee towards the west. 

Ukraine, like never before needs your help! 

We hope that world leaders will unite in their response to stop Russia and help Ukraine. 

We believe in the combined power of regular people like you and me. Every one of us can help Ukraine now. 

Here’s how we can all help…

1. Send a donation. Every single donation, no matter how small, helps:
   - Donation account of the National Bank of Ukraine https://bank.gov.ua/en/news/all/natsionalniy-bank-vidkriv-spetsrahunok-dlya-zboru-koshtiv-na-potrebi-armiyi
    - Charity that supports war victims and veterans https://savelife.in.ua/en/donate/  

2. Ask your elected representatives to support Ukraine and impose stronger sanction against Russia.

3. Support the people of Ukraine by joining local demonstrations against Russian aggression.

4. Stop Russian disinformation, don't let them get away with it this time. Use "Report" functionality on social networks to block Russian bots. Contact your internet providers to block Russian sites with misinformation.

5. Share this message with your friends and ask them to spread it further.

We are stronger when united! Together we can win!

Національний банк України

Національний банк відкрив спецрахунок для збору коштів на потреби армії (оновлено)

  Національний банк України ухвалив рішення відкрити спеціальний рахунок для збору коштів на підтримку Збройних Сил України. Таке рішення ухвалене у зв’язку із введенням воєн...

💙💛

https://t.me/brodetsky/3985

https://savelife.in.ua/en/donate/

https://t.me/informnapalm/3402

Telegram

Технології, медіа та суспільство

Уважаемые читатели. Как вы заметили, это канал о технологиях, интернете, бизнесе, цифровой экономике и обществе. Политика здесь появляется только в контексте технологий. Но в связи с эскалацией агрессии России против Украины считаю нужным обозначить свою…

CatOps exists for almost five years already as a non-profit hobby project. Yes, at some point we were advertising some technical events here, but we never took money for that.

In my opinion, keeping it independent of ad money is what makes all the fun. I'll be honest with you, from time to time I get ideas of starting a Patreon or something similar, but each time it turns out to be too complicated.

However, there is a way to support CatOps financially! Even though this is an indirect support!

Consider subscribing to the Patreon page of the "Come Back Alive" Foundation or you can, of course, donate directly. They have all the details on their website. Unfortunately, not all the information on the website is translated to English, but the main things are there.

This Foundation supports Ukrainian army as well as establish re-integration programs for the veterans.

By supporting people, who take care of us, you empower us in doing our day-to-day jobs and providing some platform engineering content here.

With love 💛💙
@grem1in

Patreon

Patreon logo

Patreon is empowering a new generation of creators. Support and engage with artists and creators as they live out their passions!

This is a rare good example of rewriting something in Rust that seems to be justifiable https://pngquant.org/rust.html

Here is an article on how to track and get health metrics from critical infrastructure repositories: https://estebank.github.io/sustainable-growth-and-visibility.html
The author suggests tracking different things like issue backlog, changes in the number of contributors, frequency, and speed of code reviews. From that data, you can derive certain knowledge about potential burnout of core contributors, or find some new projects that grow in popularity and become critical, so now require more contributors and attention.
This article is focused on Rust ecosystems, but the approach seems to be useful and universal for other ecosystems too.

It reminded me how Rob Pike a few years ago suggested how we can calculate criticality scores for open source projects and packages: https://github.com/ossf/criticality_score/blob/main/Quantifying_criticality_algorithm.pdf
Here you can also find and download pre-aggregated lists for different languages and ecosystems: https://github.com/ossf/criticality_score

If we combine these two ideas, it should be possible to proactively discover and offer some help to projects that need more hands or other resources.

GitHub

criticality_score/Quantifying_criticality_algorithm.pdf at main · ossf/criticality_score

Gives criticality score for an open source project - ossf/criticality\_score

Recently I've got a few interns to look after and mentor, so one of them asked for some advice on improving their system design skills.
So I gave a long monolog on digging through the layers of abstractions and being curious and genuinely understanding how things work. After it, I suggested them to read a "Designing Data-Intensive Applications" book and also prepared a shortlist of talks that can work as conversation starter or places from where you can start digging deeper.
Here is the list:

https://youtu.be/WE9c9AZe-DY
https://youtu.be/j6ow-UemzBc
https://youtu.be/1TIzPL4878Q
https://youtu.be/CZ3wIuvmHeM
https://youtu.be/I32hmY4diFY
https://youtu.be/hnpzNAPiC0E
https://youtu.be/y2j_TB3NsRc
https://youtu.be/t7iVCIYQbgk
https://youtu.be/IO4teCbHvZw
https://youtu.be/6w6E_B55p0E
https://youtu.be/B5NULPSiOGw
https://youtu.be/_M-oHxknfnI
https://youtu.be/lKXe3HUG2l4
https://youtu.be/r-TLSBdHe1A
https://youtu.be/fU9hR3kiOK0
https://youtu.be/lJ8ydIuPFeU
https://youtu.be/5ZjhNTM8XU8
https://youtu.be/9RMOc0SwRro
https://youtu.be/tM4YskS94b0
https://youtu.be/H0i_bXKwujQ
https://youtu.be/m64SWl9bfvk
https://youtu.be/cNICGEwmXLU
https://youtu.be/em9zLzM8O7c
https://youtu.be/ohvPnJYUW1E
https://youtu.be/HJIjTTHWYnE

Write in the comments: what else would you recommend or what talk you'd add to the list.

YouTube

How Slack Works

QCon San Francisco International Software Conference is back this November 18-22, 2024. Software leaders at early adopter companies will come together to share actionable insights to help you adopt the right technologies and practices. Get exposed to new…

I have a great article for you about the challenges and problems of writing software for real-time audio generation.
https://glowcoil.com/posts/basedrop/

That's where we cannot do without low-level programming languages ​​with absolute control over what exactly will happen at any moment. Because you can't allow any unpredictable (non-constant) operations in the thread that generates the audio, it turns out that you can't do I/O, allocate or free memory, use mutexes or blocking queues to synchronize threads, etc.
With such restrictions, even the use of Rust looks too high-level because its RAII can play a bad joke on you and start to free some buffers when they lose their owner. So it turns out that even with Rust, you may, in special cases, have a memory leak or OOM.

It seems that for such software Zig with its explicit use of allocators and explicit defer, would be a little more convenient, but also not without difficulties.

Great article that shows what will happen if you do not design asynchronous programming features in low-level language from scratch https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d54d63934a1c

It turns out that everything is kind of works, but there are a handful of annoying nuances that you have to put up with or fix with some dirty hacks. And it is similar in most languages and most runtimes. It seems to me that the industry is trying to solve the problem of expensive OS threads and context switches, not where it needs to be solved. Why can't we make OS threads more lightweight? That would be great, and we already know how to use treads in our streams and work with queues, semaphores, and mutexes. All our tooling content understands streams, then what's the problem?

In 2013, people from Google delivered this talk https://www.youtube.com/watch?v=KXuZi9aeGTw
Where they demonstrate how to reduce the overhead of context switch 100 times or more.
If I understand correctly, in 2013, they already used this solution for services written in C ++ using "regular" threads.

In 2020, they even offered 3 patches for Linux, but didn't finish the discussion and did not merge these patches, and it may take another 5-10 years to get back to this idea.

Medium

A look back at asynchronous Rust

In 2013, I discovered the Rust programming language and quickly decided to learn it and make it my main programming language.