Репозитории и зеркала. Что это и в чем разница
Репозиторий - это сервер или хранилище, где хранятся пакеты программного обеспечения для операционной системы.
Зеркало (mirror) - это копия репозитория, распределенная по различным серверам или местоположениям для обеспечения быстрого доступа и загрузки пакетов пользователями. Зеркала позволяют распределять нагрузку, обеспечивать отказоустойчивость и улучшить скорость загрузки пакетов.
Другими словами. Репозитории - это оригинальные хранилища кода, где хранится и отслеживается разработка проекта. Зеркала - это копии репозиториев, которые могут использоваться для ускорения скачивания или для обеспечения надежности доступа к коду.
#misc
Репозиторий - это сервер или хранилище, где хранятся пакеты программного обеспечения для операционной системы.
Зеркало (mirror) - это копия репозитория, распределенная по различным серверам или местоположениям для обеспечения быстрого доступа и загрузки пакетов пользователями. Зеркала позволяют распределять нагрузку, обеспечивать отказоустойчивость и улучшить скорость загрузки пакетов.
Другими словами. Репозитории - это оригинальные хранилища кода, где хранится и отслеживается разработка проекта. Зеркала - это копии репозиториев, которые могут использоваться для ускорения скачивания или для обеспечения надежности доступа к коду.
#misc
Foo и Bar — смысл, традиция, история
Это часто используемые метасинтаксические переменные в программировании и компьютерной литературе. Они служат для обозначения абстрактных переменных, функций, или других объектов, когда конкретные имена не важны или не известны. Использование этих терминов помогает разработчикам сосредоточиться на структуре и логике кода, а не на именах переменных.
Вот несколько причин, почему foo и bar так часто используются:
1. Традиция: Эти термины существуют с самого начала эры программирования и используются в учебниках, документации и примерах кода. Эта традиция продолжается и по сей день, потому что многие разработчики уже знакомы с этими терминами.
2. Универсальность: foo и bar не несут в себе никакого конкретного значения, что делает их идеальными для использования в качестве временных имен. Они могут обозначать что угодно — от переменных и функций до классов и объектов.
3. Легкость в запоминании: Эти короткие и простые слова легко запомнить и набрать, что делает их удобными для использования в примерах и тестовом коде.
4. Избежание конфликтов: Поскольку foo и bar не используются в реальных проектах, они минимизируют вероятность конфликтов с именами переменных, которые уже могут быть в коде.
История этих метасинтаксических переменных восходит к ранним дням компьютерной науки и хакерской культуры. Они, вероятно, происходят от военных терминов "FUBAR" (fouled up beyond all recognition -> испорченный до неузнаваемости), используемых во время Второй мировой войны, которые потом были адаптированы в область компьютерных наук.
Вместе с "foo" и "bar" иногда используются и другие похожие термины, такие как "baz", "qux", "quux" и так далее, особенно когда требуется несколько абстрактных имен.
#misc #theory
Это часто используемые метасинтаксические переменные в программировании и компьютерной литературе. Они служат для обозначения абстрактных переменных, функций, или других объектов, когда конкретные имена не важны или не известны. Использование этих терминов помогает разработчикам сосредоточиться на структуре и логике кода, а не на именах переменных.
Вот несколько причин, почему foo и bar так часто используются:
1. Традиция: Эти термины существуют с самого начала эры программирования и используются в учебниках, документации и примерах кода. Эта традиция продолжается и по сей день, потому что многие разработчики уже знакомы с этими терминами.
2. Универсальность: foo и bar не несут в себе никакого конкретного значения, что делает их идеальными для использования в качестве временных имен. Они могут обозначать что угодно — от переменных и функций до классов и объектов.
3. Легкость в запоминании: Эти короткие и простые слова легко запомнить и набрать, что делает их удобными для использования в примерах и тестовом коде.
4. Избежание конфликтов: Поскольку foo и bar не используются в реальных проектах, они минимизируют вероятность конфликтов с именами переменных, которые уже могут быть в коде.
История этих метасинтаксических переменных восходит к ранним дням компьютерной науки и хакерской культуры. Они, вероятно, происходят от военных терминов "FUBAR" (fouled up beyond all recognition -> испорченный до неузнаваемости), используемых во время Второй мировой войны, которые потом были адаптированы в область компьютерных наук.
Вместе с "foo" и "bar" иногда используются и другие похожие термины, такие как "baz", "qux", "quux" и так далее, особенно когда требуется несколько абстрактных имен.
#misc #theory
Что такое поддержка?
В контексте операционных систем "поддержка" обычно означает, что разработчики продолжают предоставлять обновления безопасности, исправления ошибок и иногда новые функции для определенной версии операционной системы.
Когда говорят, что поддержка для определенной версии операционной системы закончилась, это означает, что производитель перестал предоставлять обновления для этой версии. Это означает, что безопасность и стабильность операционной системы могут стать уязвимыми, так как обновления безопасности не будут выпускаться.
Например, если в CentOS 8 закончилась поддержка, это означает, что не будут выпускаться обновления безопасности и исправления ошибок для этой версии. В то время как поддержка для CentOS 7, возможно, продолжается, и обновления будут выпускаться.
Например, Debian Bullseye имеет стабильный выпуск и имеет поддержку. Обычно стабильные версии дистрибутивов длятся около 5 лет. Однако это может измениться в зависимости от решения проекта.
#misc #theory
В контексте операционных систем "поддержка" обычно означает, что разработчики продолжают предоставлять обновления безопасности, исправления ошибок и иногда новые функции для определенной версии операционной системы.
Когда говорят, что поддержка для определенной версии операционной системы закончилась, это означает, что производитель перестал предоставлять обновления для этой версии. Это означает, что безопасность и стабильность операционной системы могут стать уязвимыми, так как обновления безопасности не будут выпускаться.
Например, если в CentOS 8 закончилась поддержка, это означает, что не будут выпускаться обновления безопасности и исправления ошибок для этой версии. В то время как поддержка для CentOS 7, возможно, продолжается, и обновления будут выпускаться.
Например, Debian Bullseye имеет стабильный выпуск и имеет поддержку. Обычно стабильные версии дистрибутивов длятся около 5 лет. Однако это может измениться в зависимости от решения проекта.
#misc #theory
Что такое FAQ?
FAQ - это аббревиатура от английского выражения "Frequently Asked Questions", что в переводе на русский язык означает "Часто задаваемые вопросы". FAQ представляет собой список самых часто задаваемых вопросов и ответов на них, который обычно размещается на веб-сайте или в документации к продукту или услуге. Это помогает пользователям быстро найти ответы на свои вопросы без необходимости обращаться к службе поддержки или другим источникам информации.
#misc #theory
FAQ - это аббревиатура от английского выражения "Frequently Asked Questions", что в переводе на русский язык означает "Часто задаваемые вопросы". FAQ представляет собой список самых часто задаваемых вопросов и ответов на них, который обычно размещается на веб-сайте или в документации к продукту или услуге. Это помогает пользователям быстро найти ответы на свои вопросы без необходимости обращаться к службе поддержки или другим источникам информации.
#misc #theory
GNU GPL License и коммерческие компании (продажа)
Если компания взяла программу под GNU GPL лицензией, внесла в неё изменения и начала продавать, но при этом ограничила доступ к своим измененным исходным кодам, она нарушает принципы данной лицензии. GNU GPL обязывает распространять исходный код программы и любые изменения к нему под той же лицензией, чтобы сохранить свободу программы для всех пользователей. Такие действия могут привести к правовым последствиям и претензиям со стороны сообщества свободного программного обеспечения. Для коммерческого ПО открывать исходники всем - это не принято, НО придется бесплатно предоставлять исходники проекта конечным получателям, даже если вы распространяете продукт за деньги. Да, продажа программы лицензией вполне разрешена. Предоставлять исходники можно как вместе с программой, так и отдельно.
#misc #opensource
Если компания взяла программу под GNU GPL лицензией, внесла в неё изменения и начала продавать, но при этом ограничила доступ к своим измененным исходным кодам, она нарушает принципы данной лицензии. GNU GPL обязывает распространять исходный код программы и любые изменения к нему под той же лицензией, чтобы сохранить свободу программы для всех пользователей. Такие действия могут привести к правовым последствиям и претензиям со стороны сообщества свободного программного обеспечения. Для коммерческого ПО открывать исходники всем - это не принято, НО придется бесплатно предоставлять исходники проекта конечным получателям, даже если вы распространяете продукт за деньги. Да, продажа программы лицензией вполне разрешена. Предоставлять исходники можно как вместе с программой, так и отдельно.
#misc #opensource
JPG (JPEG) — не поддерживает прозрачность, сжимает файлы с потерей качества (lossy), лучше для фотографий и больших картинок.
PNG — поддерживает прозрачность, не теряет качество (без потерь), лучше для графики, иконок, скриншотов и логотипов.
#misc
PNG — поддерживает прозрачность, не теряет качество (без потерь), лучше для графики, иконок, скриншотов и логотипов.
#misc
Игровые порты
Это не официальные версии игр, а адаптированные или заново написанные движки старых игр, которые позволяют запускать их на современных системах. Они жизненно важны для сохранения игровой истории и ретро-гейминга, часто дают игре "вторую жизнь".
> Примеры игровых портов:
ioquake3 — порт движка Quake III Arena. Исходный код был открыт id Software, энтузиасты улучшили его, добавили поддержку новых ОС и расширили возможности.
vcmi — попытка воссоздать движок Heroes of Might and Magic III. Исходников оригинала нет, всё пишется с нуля по поведению оригинала.
DevilutionX — реверс-инженеренный движок Diablo 1. Исходника не было, энтузиасты восстановили код по бинарнику.
> Как пишутся игровые порты:
Иногда с исходников, если их выложил разработчик (как Doom, Quake).
Чаще всего — с помощью реверс-инжиниринга: смотрят, как работает оригинальная программа, анализируют данные, изучают бинарники (exe-файлы), и воссоздают код на новом языке.
> Кто этим занимается:
Открытое сообщество энтузиастов, часто фанаты игры или программисты, которым интересен вызов.
Иногда — одиночки, чаще — небольшие команды.
> Цели портов:
Позволить запускать любимые игры на современных ОС.
Исправить баги, добавить поддержку современных разрешений, онлайн-игры, новых контроллеров и т.д.
Иногда — добавить новые возможности (моды, мультиплеер, графические улучшения).
#games #misc
Это не официальные версии игр, а адаптированные или заново написанные движки старых игр, которые позволяют запускать их на современных системах. Они жизненно важны для сохранения игровой истории и ретро-гейминга, часто дают игре "вторую жизнь".
> Примеры игровых портов:
ioquake3 — порт движка Quake III Arena. Исходный код был открыт id Software, энтузиасты улучшили его, добавили поддержку новых ОС и расширили возможности.
vcmi — попытка воссоздать движок Heroes of Might and Magic III. Исходников оригинала нет, всё пишется с нуля по поведению оригинала.
DevilutionX — реверс-инженеренный движок Diablo 1. Исходника не было, энтузиасты восстановили код по бинарнику.
> Как пишутся игровые порты:
Иногда с исходников, если их выложил разработчик (как Doom, Quake).
Чаще всего — с помощью реверс-инжиниринга: смотрят, как работает оригинальная программа, анализируют данные, изучают бинарники (exe-файлы), и воссоздают код на новом языке.
> Кто этим занимается:
Открытое сообщество энтузиастов, часто фанаты игры или программисты, которым интересен вызов.
Иногда — одиночки, чаще — небольшие команды.
> Цели портов:
Позволить запускать любимые игры на современных ОС.
Исправить баги, добавить поддержку современных разрешений, онлайн-игры, новых контроллеров и т.д.
Иногда — добавить новые возможности (моды, мультиплеер, графические улучшения).
#games #misc
Где обсудить Linux: полезные форумы
Хотите быстро задать вопрос по Linux, поделиться опытом или найти решение проблемы? Вот два проверенных ресурса, где можно сразу после регистрации создавать посты — без долгих ожиданий и ограничений:
linux.org — международный портал с форумом, новостями и подробной документацией. Отлично подходит для англоговорящих пользователей и тех, кто хочет быть в курсе последних тенденций.
linux.org.ru — крупнейший русскоязычный форум, где обсуждают всё: от установки дистрибутивов до тонкостей администрирования. Здесь всегда найдётся ответ на любой вопрос!
#misc
Хотите быстро задать вопрос по Linux, поделиться опытом или найти решение проблемы? Вот два проверенных ресурса, где можно сразу после регистрации создавать посты — без долгих ожиданий и ограничений:
linux.org — международный портал с форумом, новостями и подробной документацией. Отлично подходит для англоговорящих пользователей и тех, кто хочет быть в курсе последних тенденций.
linux.org.ru — крупнейший русскоязычный форум, где обсуждают всё: от установки дистрибутивов до тонкостей администрирования. Здесь всегда найдётся ответ на любой вопрос!
#misc
Меньше хаоса в репозитории: правила README и описания usage
Речь пойдёт про документацию. Да-да, то, что вы так не любите писать. Когда я прихожу в новую компанию, я каждый раз вижу одно и то же: первые месяцы испытательного срока я сижу и разбираюсь в их говёных скриптах/программах без README, без usage-описания, без комментариев, которые что-то делают, и мне надо сидеть и читать весь код целиком, чтобы понять, что оно делает. Нормально? Нет, это не нормально. Ради Христа, пишите в своих проектах README, CONTRIBUTING, ChangeLog, Wiki, usage-функции в ваших скриптах/программах, комментарии и т.д. Если вы не знаете, как они пишутся, посмотрите в open-source проектах популярные шаблоны. Это просто правила хорошего тона.
Для чего это делать?
- Быстрее адаптация: новички стартуют без созвонов.
- Меньше багрепортов "не работает": есть шаги и ожидания.
- Консистентность: единый источник правды по запуску, настройке, версиям.
Что должно быть в README:
- О чём проект: 1–2 строки миссии, чем не является.
- Быстрый старт: установка, минимальный пример запуска, ожидаемый результат.
- Конфигурация: переменные окружения, файлы настроек, приоритеты.
- Требования: версии языка/инструментов, системные зависимости.
- Сценарии запуска: типовые команды (test, build, lint, run).
- Структура репозитория: где код, где тесты, где скрипты.
- Устранение неполадок: частые ошибки и как исправить.
- Версионирование и релизы: где ChangeLog, как нумеруются версии.
- Вклад и правила: CONTRIBUTING, стиль кода, как писать MR/PR.
- Лицензия и контакты: права использования и как связаться.
Usage для скриптов и CLI — обязательно:
- Примеры. Минимум 2–3 конкретных примера: "как запустить локально", "как прогнать на файле/каталоге", "как выключить проверку X".
- Всегда реализуйте
- Ошибки и логи: печатайте понятные сообщения, указывайте, что делать дальше.
- Коды выхода: 0 — ок, ненулевые — с расшифровкой. Это важно для CI.
Документация — это не бюрократия, а ускоритель. Сегодня вы пишете
#misc #thoughts
Речь пойдёт про документацию. Да-да, то, что вы так не любите писать. Когда я прихожу в новую компанию, я каждый раз вижу одно и то же: первые месяцы испытательного срока я сижу и разбираюсь в их говёных скриптах/программах без README, без usage-описания, без комментариев, которые что-то делают, и мне надо сидеть и читать весь код целиком, чтобы понять, что оно делает. Нормально? Нет, это не нормально. Ради Христа, пишите в своих проектах README, CONTRIBUTING, ChangeLog, Wiki, usage-функции в ваших скриптах/программах, комментарии и т.д. Если вы не знаете, как они пишутся, посмотрите в open-source проектах популярные шаблоны. Это просто правила хорошего тона.
Для чего это делать?
- Быстрее адаптация: новички стартуют без созвонов.
- Меньше багрепортов "не работает": есть шаги и ожидания.
- Консистентность: единый источник правды по запуску, настройке, версиям.
Что должно быть в README:
- О чём проект: 1–2 строки миссии, чем не является.
- Быстрый старт: установка, минимальный пример запуска, ожидаемый результат.
- Конфигурация: переменные окружения, файлы настроек, приоритеты.
- Требования: версии языка/инструментов, системные зависимости.
- Сценарии запуска: типовые команды (test, build, lint, run).
- Структура репозитория: где код, где тесты, где скрипты.
- Устранение неполадок: частые ошибки и как исправить.
- Версионирование и релизы: где ChangeLog, как нумеруются версии.
- Вклад и правила: CONTRIBUTING, стиль кода, как писать MR/PR.
- Лицензия и контакты: права использования и как связаться.
Usage для скриптов и CLI — обязательно:
- Примеры. Минимум 2–3 конкретных примера: "как запустить локально", "как прогнать на файле/каталоге", "как выключить проверку X".
- Всегда реализуйте
-h и --help с понятным usage(): что делает команда, какие аргументы и их значения по умолчанию.- Ошибки и логи: печатайте понятные сообщения, указывайте, что делать дальше.
- Коды выхода: 0 — ок, ненулевые — с расшифровкой. Это важно для CI.
Документация — это не бюрократия, а ускоритель. Сегодня вы пишете
--help и три примера, завтра экономите час себе и коллегам.#misc #thoughts