#книги
William E. Shotts - The Linux Command Line
11.05.2025 - 28.07.2025
Книга мне понравилась и она отличная. Теперь считаю, что она должна быть первой в изучении линукса(и даже MacOS). "Знать линукс" в большей степени значит знать, как работать в терминале и поэтому эту книгу можно воспринимать именно, как вводную в линукс. Жалею, что не прочитал ее раньше, так как многие вещи узнал более сложным путем :)
Книга состоит из 4х частей. Первая написана максимально просто и продуманно, так как надо для того, чтобы начать с чем-то работать (с терминалом в данном случае) - этим она очень понравилась. Вторая и третья про различные утилиты: sort, head, cat, tr и некоторые экстравагантные. А четвертая про shell скрипты. Эту часть читать было скучновато т.к. там в том числе объяснялись вещи известные программистам, вроде условий и циклов и еще раз читать про них было полезно только чтобы увидеть, какой у них синтаксис, но были и некоторые интересные приемы, ради которых ее и не пропустил. Ну и еще, чтобы к синтаксису привыкнуть и более осознанно смотреть на .sh скрипты, которые встречаются.
Книгу надо обновить. Она 2019 года. Надеюсь в 3м издании, которое выходит в начале 2026 года будет много поправлено.
- Рассказывается про init, хотя уже тогда systemd был популярен
- Глава про пакетные менеджеры. Неплохо бы добавить pacman
- В главе работу с диском много старого. Флоппи, CD-RW итд.
- Логи читаются не через journalctl
- Я бы убрал главу про печать, разделы про groff и подобное.
Однако! Когда я гуглил, когда выйдет 3е издание, то обнаружил, что на сайте автора бесплатно публикуется Internet Edition, которое потом превращается в продаваемое Edition. В этом интернет издании уже много изменений.
William E. Shotts - The Linux Command Line
11.05.2025 - 28.07.2025
Книга мне понравилась и она отличная. Теперь считаю, что она должна быть первой в изучении линукса(и даже MacOS). "Знать линукс" в большей степени значит знать, как работать в терминале и поэтому эту книгу можно воспринимать именно, как вводную в линукс. Жалею, что не прочитал ее раньше, так как многие вещи узнал более сложным путем :)
Книга состоит из 4х частей. Первая написана максимально просто и продуманно, так как надо для того, чтобы начать с чем-то работать (с терминалом в данном случае) - этим она очень понравилась. Вторая и третья про различные утилиты: sort, head, cat, tr и некоторые экстравагантные. А четвертая про shell скрипты. Эту часть читать было скучновато т.к. там в том числе объяснялись вещи известные программистам, вроде условий и циклов и еще раз читать про них было полезно только чтобы увидеть, какой у них синтаксис, но были и некоторые интересные приемы, ради которых ее и не пропустил. Ну и еще, чтобы к синтаксису привыкнуть и более осознанно смотреть на .sh скрипты, которые встречаются.
Книгу надо обновить. Она 2019 года. Надеюсь в 3м издании, которое выходит в начале 2026 года будет много поправлено.
- Рассказывается про init, хотя уже тогда systemd был популярен
- Глава про пакетные менеджеры. Неплохо бы добавить pacman
- В главе работу с диском много старого. Флоппи, CD-RW итд.
- Логи читаются не через journalctl
- Я бы убрал главу про печать, разделы про groff и подобное.
Однако! Когда я гуглил, когда выйдет 3е издание, то обнаружил, что на сайте автора бесплатно публикуется Internet Edition, которое потом превращается в продаваемое Edition. В этом интернет издании уже много изменений.
🔥6👍3❤1
Как я хотел почитать комментарии к книге на амазоне и столкнулся с тремя проблемами
Первая
Логинюсь на айпаде, ввожу логин+пароль. Получаю: "свяжитесь с поддержкой".
Думаю может с компа попробовать. Я там даже залогинен. Разлогиниваюсь. Пытаюсь залогиниться и получаю "свяжитесь с поддержкой".
Жму кнопку связи с поддержкой и там написано, что если не можете залогиниться, то смените пароль.
Ок. Меняю пароль, логинюсь и.... "свяжитесь с поддержкой".
Единственный оставшийся вариант - позвонить на номер в США.
Как мне кажется, уже на этом этапе очень много людей может отсеяться т.к. могут не знать языка или не иметь возможности позвонить в США.
Вторая
Но у меня же есть скайп!
Логинюсь в майкрософт, двойная аутентификация, получаю код на почте, ввожу его и: смените пароль...
Меняю пароль и еще раз ввожу код с почты
Пароль успешно сменился теперь надо залогиниться. Логинюсь и опять ввожу код с почты.
Hacker: 'I'm in'
Третья
Майкрософт любит спустя какое-то время неактивности как-то архивировать деньги на счете скайпа. Зачем? Почему? Непонятно.
Разархивировать их можно просто нажав кнопку и подождав до 15 минут (у меня вышло быстро).
Для меня загадка зачем это им нужно, но даже если и нужно, то зачем пользователю знать это все? Архивировали и разархивировали бы все это в фоне, без моего участия. Но нет, надо жизнь усложнить. Но они же сами функционал писали для этого, кнопочти на фронте рисовали...
Ладно, деньги разархивированы. Звоним.
По итогу спросили телефон и мое имя и сказали, что в течении часа я получу письмо, где надо будет загрузить паспорт с моим именем и с этого момента через 24 часа разблокируют. (наверное опять придется сбросить пароль)
Я ведь просто хотел почитать комментарии на амазоне😭
Первая
Логинюсь на айпаде, ввожу логин+пароль. Получаю: "свяжитесь с поддержкой".
Думаю может с компа попробовать. Я там даже залогинен. Разлогиниваюсь. Пытаюсь залогиниться и получаю "свяжитесь с поддержкой".
Жму кнопку связи с поддержкой и там написано, что если не можете залогиниться, то смените пароль.
Ок. Меняю пароль, логинюсь и.... "свяжитесь с поддержкой".
Единственный оставшийся вариант - позвонить на номер в США.
Как мне кажется, уже на этом этапе очень много людей может отсеяться т.к. могут не знать языка или не иметь возможности позвонить в США.
Вторая
Но у меня же есть скайп!
Логинюсь в майкрософт, двойная аутентификация, получаю код на почте, ввожу его и: смените пароль...
Меняю пароль и еще раз ввожу код с почты
Пароль успешно сменился теперь надо залогиниться. Логинюсь и опять ввожу код с почты.
Hacker: 'I'm in'
Третья
Майкрософт любит спустя какое-то время неактивности как-то архивировать деньги на счете скайпа. Зачем? Почему? Непонятно.
Разархивировать их можно просто нажав кнопку и подождав до 15 минут (у меня вышло быстро).
Для меня загадка зачем это им нужно, но даже если и нужно, то зачем пользователю знать это все? Архивировали и разархивировали бы все это в фоне, без моего участия. Но нет, надо жизнь усложнить. Но они же сами функционал писали для этого, кнопочти на фронте рисовали...
Ладно, деньги разархивированы. Звоним.
По итогу спросили телефон и мое имя и сказали, что в течении часа я получу письмо, где надо будет загрузить паспорт с моим именем и с этого момента через 24 часа разблокируют. (наверное опять придется сбросить пароль)
Я ведь просто хотел почитать комментарии на амазоне😭
pacman -Syu
В пакмане не нравилось, что при обновлении список пакетов выводится через пробел (1й скрин). Мне было неудобно искать, есть ли обновления каких-то конкретных пакетов. Но оказывается можно этот список выводить построчно (2й скрин).
Сделать можно раскомментировав строку
В пакмане не нравилось, что при обновлении список пакетов выводится через пробел (1й скрин). Мне было неудобно искать, есть ли обновления каких-то конкретных пакетов. Но оказывается можно этот список выводить построчно (2й скрин).
Сделать можно раскомментировав строку
VerbosePkgLists в /etc/pacman.conf.👍14 11 4 3🔥1
Алгоритм любой оптимизации
Порядок шагов и сам факт их наличия важен. Можно представить ситуацию, где игнорирование какого-либо шага приведет к негативным последствиям
Также важно помнить, что в большинстве случаев производительность кода и его читаемость находятся в обратной зависимости, и задача сводится к поиску баланса между ними. Если бы абсолютный приоритет всегда отдавался производительности, мы бы писали программы на ассемблере. Но производительность не единственный критерий качества кода
Алгоритм:
Я считаю, что реальность такова, что проблемы начинаются на самом первом пункте. Почему-то сам процесс оптимизации довольно привлекателен для разработчиков. Возможно потому что скорость выполнения - довольно очевидная метрика. А может еще и потому, что обучение программированию в университетах происходит на языках вроде C++, где много внимания уделяется довольно низкоуровневым моментам вроде передачи по ссылке и т.д.. В итоге постоянно хочется всё оптимизировать. Но сам процесс оптимизации занимает время и при отсутствии требования к более высокой производительности, чем сейчас, это впустую потраченное время.
Когда я начинал программировать мне тоже очень нравилось заниматься оптимизациями. Тем более, что в инженерных расчетах результаты могли быть более заметными и например расчет вместо дней мог быть оптимизирован до секунд (если первая версия была совсем уж плохо написана). Но со временем к моему интересу оптимизировать добавился интерес писать понятный код, который удобно читать и использовать. Сейчас я считаю, что верно изначально писать именно читаемый и корректный код, а только потом проходится по описанному алгоритму оптимизации.
Есть много отличных мыслей на эту тему в книге Совершенный код (главы 25, 26).
И цитата Кнута про необходимость поиска бутылочного горлышка:
Порядок шагов и сам факт их наличия важен. Можно представить ситуацию, где игнорирование какого-либо шага приведет к негативным последствиям
Также важно помнить, что в большинстве случаев производительность кода и его читаемость находятся в обратной зависимости, и задача сводится к поиску баланса между ними. Если бы абсолютный приоритет всегда отдавался производительности, мы бы писали программы на ассемблере. Но производительность не единственный критерий качества кода
Алгоритм:
1. Напишите хороший и понятный код, поддающийся легкому изменению
2. Задаться вопросом: А есть ли требование, чтобы было производительнее или это моя внутренняя потребность что-то оптимизировать?
3. Произвести измерение производительности ВСЕЙ системы до оптимизации
4. Найти бутылочное горлышко (Часть системы, которая вносит больший вклад в замедление производительности)
5. Произвести измерение производительности бутылочного горлышка
6. Написать тест на участок с бутылочным горлышком (если его еще нет)
7. Произвести оптимизацию (сохранив старую версию кода, чтобы можно было вернуться)
8. Произвести измерение производительности бутылочного горлышка и сравнить с измерением до оптимизации
9. Произвести измерение производительности ВСЕЙ системы и сравнить с измерением до оптимизации
Я считаю, что реальность такова, что проблемы начинаются на самом первом пункте. Почему-то сам процесс оптимизации довольно привлекателен для разработчиков. Возможно потому что скорость выполнения - довольно очевидная метрика. А может еще и потому, что обучение программированию в университетах происходит на языках вроде C++, где много внимания уделяется довольно низкоуровневым моментам вроде передачи по ссылке и т.д.. В итоге постоянно хочется всё оптимизировать. Но сам процесс оптимизации занимает время и при отсутствии требования к более высокой производительности, чем сейчас, это впустую потраченное время.
Когда я начинал программировать мне тоже очень нравилось заниматься оптимизациями. Тем более, что в инженерных расчетах результаты могли быть более заметными и например расчет вместо дней мог быть оптимизирован до секунд (если первая версия была совсем уж плохо написана). Но со временем к моему интересу оптимизировать добавился интерес писать понятный код, который удобно читать и использовать. Сейчас я считаю, что верно изначально писать именно читаемый и корректный код, а только потом проходится по описанному алгоритму оптимизации.
Есть много отличных мыслей на эту тему в книге Совершенный код (главы 25, 26).
И цитата Кнута про необходимость поиска бутылочного горлышка:
Программисты тратят огромное количество времени, размышляя или беспокоясь о скорости неключевых частей своих программ, и такие попытки повысить эффективность на самом деле оказывают сильное негативное влияние, если учитывать отладку и сопровождение. Мы должны забыть о незначительных оптимизациях примерно в 97% случаев: преждевременная оптимизация — корень всех зол.
❤12 2
#книги
Michael W. Lucas - Networking for Systems Administrators
28.07.2025 - 18.08.2025
Всё еще ищу хорошую книгу про сети, которая будет состоять не на 100% из теории, как Таненбаум. Эта книга уже довольно практическая и не на 1000 страниц, как популярно в книгах по сетям, а всего на 180. Однако идеальной для первой книги тоже назвать сложно, какие-то базовые вещи не рассказываются, но тем не менее она неплоха.
В начале было немного более скучно, а потом стало интереснее. Возможно из-за того, что чем ближе к концу книги, тем выше по уровням сетевой модели поднимались. То есть Network и Transport уровни были интереснее мне, чем Data Link.
Понравилось, что есть примеры команд для терминала, чтобы можно было что-то самому посмотреть.
Не понравилось, что эти команды были относительно устаревшими: есть два популярных пакета сетевых утилит - net-tools (ifconfig, netstat, route, arp, hostname) и iproute2 (ip, ss, nstat) и второй более современный, а в книге в основном про первый была речь. Но утилиты в целом похожие и найти альтернативу из второго пакета не проблема.
Я наверное уже не верю, что существует книга, которую я могу советовать, как первую по сетям. Это не такая, но читать эту было далеко не бесполезно, ибо я что-то забыл, что-то не знал, и читая ее в голове появлялись какие-то ассоциации, я их гуглил и уточнял понимание. В первый раз кстати так плотно говорил с ChatGPT в Voice Mod, удобно вышло. В общем, чем больше что-то про какую-то тему через себя пропускаешь, даже знакомые вещи, просто в других формулировках, тем больше пазл складывается.
Michael W. Lucas - Networking for Systems Administrators
28.07.2025 - 18.08.2025
Всё еще ищу хорошую книгу про сети, которая будет состоять не на 100% из теории, как Таненбаум. Эта книга уже довольно практическая и не на 1000 страниц, как популярно в книгах по сетям, а всего на 180. Однако идеальной для первой книги тоже назвать сложно, какие-то базовые вещи не рассказываются, но тем не менее она неплоха.
В начале было немного более скучно, а потом стало интереснее. Возможно из-за того, что чем ближе к концу книги, тем выше по уровням сетевой модели поднимались. То есть Network и Transport уровни были интереснее мне, чем Data Link.
Понравилось, что есть примеры команд для терминала, чтобы можно было что-то самому посмотреть.
Не понравилось, что эти команды были относительно устаревшими: есть два популярных пакета сетевых утилит - net-tools (ifconfig, netstat, route, arp, hostname) и iproute2 (ip, ss, nstat) и второй более современный, а в книге в основном про первый была речь. Но утилиты в целом похожие и найти альтернативу из второго пакета не проблема.
Я наверное уже не верю, что существует книга, которую я могу советовать, как первую по сетям. Это не такая, но читать эту было далеко не бесполезно, ибо я что-то забыл, что-то не знал, и читая ее в голове появлялись какие-то ассоциации, я их гуглил и уточнял понимание. В первый раз кстати так плотно говорил с ChatGPT в Voice Mod, удобно вышло. В общем, чем больше что-то про какую-то тему через себя пропускаешь, даже знакомые вещи, просто в других формулировках, тем больше пазл складывается.
❤6 1
TIL Github reactions sort
В гитхабе можно сортировать PR по числу реакций. Удобно
В гитхабе можно сортировать PR по числу реакций. Удобно
KYAML
Kubernetes в последней версии v1.34 добавляет поддержку нового формата KYAML, который является более строгим подмножеством YAML
Его цель - убрать неоднозначности и сделать формат читаемым и безопасным.
Пример YAML:
Эквивалентный KYAML:
Проблемы YAML:
KYAML вводит строгие правила:
На вид KYAML напоминает JSON, но при этом:
KYAML — это подмножество YAML. Любой YAML-парсер сможет разобрать KYAML-файл, а любой KYAML остаётся валидным YAML.
source
Kubernetes в последней версии v1.34 добавляет поддержку нового формата KYAML, который является более строгим подмножеством YAML
Его цель - убрать неоднозначности и сделать формат читаемым и безопасным.
Пример YAML:
Traditional YAML:
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app: web
spec:
selector:
app: web
ports:
- port: 80
targetPort: 8080
Эквивалентный KYAML:
---
{
apiVersion: "v1",
kind: "Service",
metadata: {
name: "my-service",
labels: {
app: "web",
},
},
spec: {
selector: {
app: "web",
},
ports: [{
port: 80,
targetPort: 8080,
}],
},
}
Проблемы YAML:
- Важны пробелы и отступы;
- Строки без кавычек, которые иногда неожиданно превращаются в числа или булевы значения;
- Разные варианты записи одного и того же объекта.
KYAML вводит строгие правила:
- все строки всегда в двойных кавычках;
- ключи без кавычек, кроме неоднозначных случаев;
- map-структуры всегда в {};
- списки всегда в [].
На вид KYAML напоминает JSON, но при этом:
- поддерживает комментарии;
- разрешает завершающие запятые;
- не требует кавычек у ключей.
KYAML — это подмножество YAML. Любой YAML-парсер сможет разобрать KYAML-файл, а любой KYAML остаётся валидным YAML.
source
🥴14❤5👍1🤔1🤣1
CamelHumps
В JetBrains IDE можно установить эту настройку:
И тогда нажатие стрелок с зажатым ctrl будет прыгать не до следующего пробела, а также до следующего слова в названии названном через CamelCase
Из нюансов: двойной клик теперь выделяет не всё название, а только часть. Но это можно отключить убрав галочку с настройки:
(Она находится под Use "CamelHumps" words)
В JetBrains IDE можно установить эту настройку:
Preferences → Editor → General → Smart Keys → Use "CamelHumps" words
И тогда нажатие стрелок с зажатым ctrl будет прыгать не до следующего пробела, а также до следующего слова в названии названном через CamelCase
Из нюансов: двойной клик теперь выделяет не всё название, а только часть. Но это можно отключить убрав галочку с настройки:
Honor "CamelHumps" words settings when selecting on double click
(Она находится под Use "CamelHumps" words)
❤15🔥4 3
Читай чтобы забывать
(c) Mo's blog
Итак, я читаю, чтобы забывать. Когда начинаю читать, я заранее готов потерять 98% того, что передо мной. От большинства текстов я хочу только двух вещей: во-первых, чтобы они слегка изменяли мое мышление, добавляя небольшоей кусочек к более точной модели мира; во-вторых, чтобы вытащить несколько ключевых идей, которые я, возможно, использую позже в своих текстах.
(c) Mo's blog
👍12 10❤1🖕1
Закончился премиум в телеге и при попытке вступить в очередной канал получаю вот это. Пришлось почистить группы и каналы.
Пока для меня были полезны только следующие фичи:
- Отсутствие рекламы
- Увеличенные лимиты на комьюнити
- Три реакции на сообщение
Не очень то важные, если подумать. Отсутствие рекламы, наверное, самое нужное.
Пока для меня были полезны только следующие фичи:
- Отсутствие рекламы
- Увеличенные лимиты на комьюнити
- Три реакции на сообщение
Не очень то важные, если подумать. Отсутствие рекламы, наверное, самое нужное.
👍8❤2
Вышла MX Master 4
Из нового:
- Haptic feedback: Отдача для кнопки под большим пальцем и меню "активных действий" (для меня бесполезная фича)
- Новый материал: текстурированный силикон вместо резины (лучше против износа и загрязнения)
- USB type C Bolt Receiver (наконец-то ушли от USB type A)
- Кнопки во всю площадь и нет отстровка вокруг колесика (меньше пачкаться будет из-за меньшего числа граней. На последней картинке сравнение c Master 3)
Меня смущает область для большого пальца. Как бы она не стала меньше. И также, она теперь - отдельный островок из другого материала, то есть опять же больше пачкаться будет - неясно, зачем так сделали. В остальном вроде отличный апгрейд, надеюсь в реальности так и окажется
Цена $120
link
Из нового:
- Haptic feedback: Отдача для кнопки под большим пальцем и меню "активных действий" (для меня бесполезная фича)
- Новый материал: текстурированный силикон вместо резины (лучше против износа и загрязнения)
- USB type C Bolt Receiver (наконец-то ушли от USB type A)
- Кнопки во всю площадь и нет отстровка вокруг колесика (меньше пачкаться будет из-за меньшего числа граней. На последней картинке сравнение c Master 3)
Меня смущает область для большого пальца. Как бы она не стала меньше. И также, она теперь - отдельный островок из другого материала, то есть опять же больше пачкаться будет - неясно, зачем так сделали. В остальном вроде отличный апгрейд, надеюсь в реальности так и окажется
Цена $120
link
1 6❤2🔥1
Чистка ноута
Во второй раз поставил:
node_exporter
prometheus
grafana
чтобы посмотреть, как поможет чистка ноута и замена термопасты.
Судя по графику разница где-то 7 градусов. Хотя, возможно, еще повлияла сама перезагрузка: я редко перезагружаю, может какие процессы фоновые вносили свой вклад. Поэтому построил дополнительную метрику T/cpu. Возможно странная, но вроде логичная. Разница получилась 9%.
Грустно всё не у apple.
Во второй раз поставил:
node_exporter
prometheus
grafana
чтобы посмотреть, как поможет чистка ноута и замена термопасты.
Судя по графику разница где-то 7 градусов. Хотя, возможно, еще повлияла сама перезагрузка: я редко перезагружаю, может какие процессы фоновые вносили свой вклад. Поэтому построил дополнительную метрику T/cpu. Возможно странная, но вроде логичная. Разница получилась 9%.
Грустно всё не у apple.
👀4🔥1 1 1