Дмитрий Беляев

В обоих под капотом cgroups и kernel namespaces.

2 варианта:

1. Полностью перезаписать его: echo 'New data' > write-only-file
2. Дозаписать данные в конец: echo 'New data at end' >> write-only-file

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

Неформально такую должность называют "эникей".

Обосновать повышение зп будет довольно сложно - Вы же не начали делать ничего сверх того, что уже делаете? Значит, только поиск нового места. Если контора считает, что ей бует проблематично найти еще одного такого же многорукого многонога - зп подымут. Если нет - расстанетесь без слез и упреков :)

Как насчёт

func() {
    echo -n "$1"
    read var
}

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

f-строки - это способ подставить в строку значение переменной или выражения.
В фигурных скобках - выражение, чьё значение нужно подставить. После двоеточия идёт указание на то, как это значение вывести.
Например, f"{i:2d}" означает "выведи значение переменной i как целое число (d), и дополни его пробелами до ширины 2 знака".

Подробнее в документации на язык, ссылку тебе дали выше.

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

Нужно сделать так, чтобы "бэкэнд на тайпскрипт" не падал, а отдавал 500 конкретно косячному запросу и продолжал работу.
Например можно в простейшем случае - завернуть весь колбэк обработки запроса в try/catch (если там есть асинхронные операции без await или блока .catch в Promise - то их внутренности тоже завернуть, содержимое каждой функции по отдельности).
Эксепшен не должен вываливаться до верха стека вызовов.

Потому что она реализует то, чего нет в стандартной библиотеке - асинхронный рантайм. Если писать сетевое приложение без токио, то придется плодить по отдельному потоку на каждый сетевой коннекшен. (на самом деле, речь идет про любой i/o, к которому чтение/запись файлов тоже относится) Каждый из этих потоков большую часть времени будет заблокирован в ожидании завершения сететвого вызова (передачи или приема данных). Однако, операционная система при разблокировке этих тредов будет постоянно переключать контекст для каждого потока и тратить процессорное время.
Асинхронный подход позволяет обойтись лишь сравнительно небольшим пулом потоков, на которые токио рантайм будет распределять таски (грин треды) и, таким образом, экономить процессорное время.

А что, стрелочные функции не принимают аргументов или не возвращают результат? Или делают это как-то иначе? Или они не являются функциями?
Вопросы риторические.

"Говорите" про них ровно так же, как про обычные. Когда окажется важным, что это именно стрелочная функция (а это бывает довольно редко), так и уточняйте.

супермозговывертный вызов можно сократить до
console[level].apply(console, argsWithFormat)

console[level] - некая функция из консоли, например, console.error. Но в IE9 у неё нет apply, и вызов через точку не сработает. Потому берется стандартный Function.prototype.apply и вызывается через call, так что console[level] станет для него как this (как то, что перед точкой), а остальное - аргументами.

Да, в общем-то русским (английским) по черному написано - data_process.c включает data_process.h, который первым определил функцию normalization().
А потом сам data_process.c определил функцию normalization() чуть пониже - ессно компилятор выдает замечание о переопределении, ибо оно есть :)

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

СУБД на стороне клиента разработчику нужно воспринимать только в качестве разновидности кеша данных, для которого по счастливому случаю предусмотрен API в виде SQL.
Какие проблемы?
- Все те, что есть у любой подсистемы, что обеспечивает кеширование. То есть, нужно следить, чтобы в ней находились только актуальные данные. Обеспечивать своевременную синхронизацию данных с сервером, решать конфликты кеша и данных сервера. Если у вас для пользователя предусмотрено ведение учетной записи, то в локальную базу данных не должно загружаться никаких данных, не предусмотренные правами доступа пользователя.

В любом случае, у вас эксклюзивная часть приложения, в которой, например, ведутся сведения об учетных записях пользователей, хранится состояние лицензий, должна находится на сервере. И там будет нормальная, взрослая СУБД.

Суть в том, что имеющие SQL запросы (INSERT, JOINT LEFT - RIGT) делать на стороне клиента, и я задался вопросом себе, насколько это нужная задача, и какие аргументы мог бы противопоставить, что это нужно - не нужно?

Если вы хотите собирать текст запросов на клиенте, передавать на сервер, и там исполнять.
Не самый хороший вариант, но терпимо только в одном случае, если учетная запись пользователя в точности соответствует учетной записи в СУБД, и доступ к данным в СУБД четко ограничен правами доступа - из учетной записи в СУБД нельзя дотянуться ни до каких данных, не принадлежащих только этому пользователю.
Но такое редко бывает, так что воздержитесь от этой практики, воспользуйтесь лучше GraphQL/TreeQL, чтобы ограничить API только тем функционалом и теми данными, которые необходимы для конкретного пользователя.