Dmitry Bay

Нужно понимать принципиальную разницу подхода:

apt - установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt - это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

snap - установка большого приложения со всеми зависимостями, которые никак не использует остальной софт на этом же компьютере. Отсюда тратится лишнее место на диске и в оперативной памяти. Зато никаких проблем с зависимостями, плюс snap работает в любых системах и не завязан на конкретный менеджер пакетов и собственно пакетный формат.

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

лол, макось всегда заявляла, что поддержка нтфс у неё только ридонли.
если вы вели работу на нтфс, то претензии только к вам самому и/или стороннему нтфс-драйверу (если он использовался).
да, сочувствую. но тут вы сами себе привезли проблем.

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

Например как intro. js?

насколько я знаю строки сравниваются посимвольно (char коды). и тут чар-код "1" будет меньше чем "2".

до первого вхождения. как только удается определить какая строка меньше - дальше проверка не производится. в вашем случае она останавливается на последнем символе дня.

Пользуюсь air на м1 уже 2,5 месяца.
Проверил по всем прогам свой ssd и все четко, пользуюсь целыми днями безвылазно так сказать. Берите и не думайте даже:)

Типа в них (на m1) мало ОЗУ - поэтому активно используется своп.
Но он и так почти всегда активно используется (чтобы отказаться от свопа, мне, например, 32Гб ОЗУ в моем компе не хватает).
Так что скорее вброс. Современные ССД достаточно живучие.

У вас Hardware offload на порту брижда sfp-sfpplus1 по каким-то причинам не активировался, поэтому данные свичевались процессором коммутатора, а не аппаратно свич-чипом. Насколько я помню, HW. offload в коммутаторах Микротик работает только для первого созданного бриджа, а у вас порты SFP+ в bidge2, возможно причина в этом. Если ether1 используется только для управления, попробуйте вывести его из бриджа и использовать независимо, а порты SFP+ перевести в bridge1.

Бенчмарки - это хорошо, но очень важно понимать что именно там меряли и почему результаты именно такие.

Несколько лет назад я тоже делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

На тесте, где сервисы не делали запросы в базу - из всех четверых лучше всего отработал Go с приличным отрывом, цифры, к сожалению, уже не помню.

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, особо не будет.

Другое дело если ваш сервис не будет делать запросы в базу, или будет кешировать результаты запросов, тогда вы почувствуете ощутимую разницу.

Еще очень важно понимать сколько ваш скрипт потребляет ресурсов. Это становится критически важным, когда вы имеете дело с большими нагрузками.

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.

Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше, соответственно расходы за эти сервера у вас будут в 10 раз меньше :)

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)