Всем привет!
Я на линуксе уже месяцев 10 (никого не призываю, сидите на винде, оно вам не нужно!) и всё шло вроде хорошо. Система работала без проблем, работа работалась удобно, пока не случился ... апдейт.
У меня была Nobara (основана на Fedora) и у неё режим выпуска Rolling Release, т.е. обновляется постоянно, а не как LTS дистрибутивы, раз в несколько месяцев.
Так вот, ничто не предвещало беды. Очередной пак обновления включал драйверы Nvidia. Установил, перезагрузил и меня встречает прелестный белый экран Gnom'а с ошибкой "что-то пошло не так".
Ночь убил на попытки восстановления. Сносил дрова, ставил старее, переключился на X11 вместо Wayland, всё тщетно.
В итоге пришлось на целую неделю перейти на Windows 11 (елинственная флешка с системой была с виндой). И после почти года на линуксе, это было не просто. В целом что там, что там управление системой одинаковое, но разница в мелочах. Для Docker'а нужна виртуалка WSL, Qdrant отказался работать в контейнере, хотя на линуксе работал корректно и куча других мелких проблем с библиотеками и совместимостью.
В итоге, доделав дела которые были, я вернулся на линукс. На этот раз выбрал Cachy OS (на базе Arch).
Что по первым впечатлениям:
- Работает сильно быстрее федоры. Начиная установкой пакетов, заканчивая самой системой. Просто летает.
- После установки сразу актуальные драйвера, Wayland и Steam со специальной версие Cachy Proton, оптимизированной под эту ОС.
- Хоть Arch и популярен, но основные линукс сборки приходятся на RPM или DEB-пакеты, но в репозитории AUR есть почти всё, что нужно, собранное из DEB-пакетов.
Как-то так. Интересно, сколько проживёт эта установка?
Я на линуксе уже месяцев 10 (никого не призываю, сидите на винде, оно вам не нужно!) и всё шло вроде хорошо. Система работала без проблем, работа работалась удобно, пока не случился ... апдейт.
У меня была Nobara (основана на Fedora) и у неё режим выпуска Rolling Release, т.е. обновляется постоянно, а не как LTS дистрибутивы, раз в несколько месяцев.
Так вот, ничто не предвещало беды. Очередной пак обновления включал драйверы Nvidia. Установил, перезагрузил и меня встречает прелестный белый экран Gnom'а с ошибкой "что-то пошло не так".
Ночь убил на попытки восстановления. Сносил дрова, ставил старее, переключился на X11 вместо Wayland, всё тщетно.
В итоге пришлось на целую неделю перейти на Windows 11 (елинственная флешка с системой была с виндой). И после почти года на линуксе, это было не просто. В целом что там, что там управление системой одинаковое, но разница в мелочах. Для Docker'а нужна виртуалка WSL, Qdrant отказался работать в контейнере, хотя на линуксе работал корректно и куча других мелких проблем с библиотеками и совместимостью.
В итоге, доделав дела которые были, я вернулся на линукс. На этот раз выбрал Cachy OS (на базе Arch).
Что по первым впечатлениям:
- Работает сильно быстрее федоры. Начиная установкой пакетов, заканчивая самой системой. Просто летает.
- После установки сразу актуальные драйвера, Wayland и Steam со специальной версие Cachy Proton, оптимизированной под эту ОС.
- Хоть Arch и популярен, но основные линукс сборки приходятся на RPM или DEB-пакеты, но в репозитории AUR есть почти всё, что нужно, собранное из DEB-пакетов.
Как-то так. Интересно, сколько проживёт эта установка?
Forwarded from Код на салфетке
Всем привет!
Недавно я объявил, что мы работаем над сервисом для учёта финансов и попросил вас пройти опрос. Ваши ответы помогли уточнить требования к проекту.
Сейчас мы выходим на активный этап разработки:
- Уже реализована основа бэкенда с аутентификацией.
- Составлена дорожная карта.
- Ведётся работа над макетами дизайна.
🔹 Кого мы ищем:
- 1–2 стажёров-бэкендеров на FastAPI.
- Менеджера проекта, который поможет вести задачи и контролировать процесс.
👉 С фронтендом нам помогают друзья из IT-Академии Lad, так что здесь мы в надёжных руках.
🔹 Основные требования для стажёров-бэкендеров:
- Решить тестовое задание и прислать решение в личные сообщения канала.
- Знание FastAPI и SQLAlchemy.
- Умение разбираться в чужом коде.
- Желание учиться новому.
🔹 Условия:
Стажировка не оплачивается, но это возможность поработать над реальным проектом, получить опыт и добавить его в портфолио.
Недавно я объявил, что мы работаем над сервисом для учёта финансов и попросил вас пройти опрос. Ваши ответы помогли уточнить требования к проекту.
Сейчас мы выходим на активный этап разработки:
- Уже реализована основа бэкенда с аутентификацией.
- Составлена дорожная карта.
- Ведётся работа над макетами дизайна.
🔹 Кого мы ищем:
- 1–2 стажёров-бэкендеров на FastAPI.
- Менеджера проекта, который поможет вести задачи и контролировать процесс.
👉 С фронтендом нам помогают друзья из IT-Академии Lad, так что здесь мы в надёжных руках.
🔹 Основные требования для стажёров-бэкендеров:
- Решить тестовое задание и прислать решение в личные сообщения канала.
- Знание FastAPI и SQLAlchemy.
- Умение разбираться в чужом коде.
- Желание учиться новому.
🔹 Условия:
Стажировка не оплачивается, но это возможность поработать над реальным проектом, получить опыт и добавить его в портфолио.
Всем привет!
У GitVerse совместно с Хабром проходит конкурс Open Source-проектов «Код без границ». Я решил запрыгнуть в этот поезд со своим проектом ReVu, о котором расскажу подробнее уже в этот четверг.
Одним из условий конкурса является размещение проекта в репозитории на GitVerse.
Я решил воспользоваться ситуацией и «убить двух зайцев»:
- Принять участие в конкурсе
- Интегрировать GitVerse в свой проект
Но, как это часто бывает, всё оказалось не таким простым, как кажется. Об этом — данный пост.
Что понравилось?
1. Своя платформа. Кто бы что ни говорил, но нам нужны собственные аналоги. Сейчас GitHub блокирует доступ для пользователей из Крыма — что мешает однажды расширить эти ограничения? Наличие альтернативы внутри страны — полезно и важно.
2. Облачные раннеры «из коробки». Это удобно: можно запускать простые CI/CD-пайплайны без настройки собственного раннера. Да, есть лимиты, но они есть везде. Плюс — совместимость с GitHub Actions: мои воркфлоу заработали почти без изменений.
3. Приятный интерфейс. Возможно, субъективно, но внешний вид GitVerse современный и аккуратный — работать комфортно, «глаз не режет».
На этом, пожалуй, плюсы заканчиваются. Дальше — обычный git-хостинг без каких-то выдающихся фич.
Что не понравилось?
Здесь уже больше проблем.
1. Ограничения облачных раннеров. Образ сильно урезан: нет даже базовых зависимостей, например Node.js (а он нужен многим Actions). Нет доступа к Docker-сокету — собрать Docker-образ на стандартном раннере невозможно, придётся подключать свой.
2. Вебхуки и безопасность.
2.1. Нет подписи вебхуков. GitHub и Gitea подписывают события через HMAC SHA-256, что позволяет проверить целостность данных. У GitVerse этого нет — можно только добавить заголовок Authorization.
2.2. Некорректные ссылки в вебхуках. Вместо нормальных публичных URL вида
3. Слабое публичное API. GitVerse основан на Gitea — и это нормально, но при этом доступное API сильно урезано. В Gitea из коробки большой и удобный API, а здесь — «обрезок» без нужных эндпоинтов. К тому же API закрыто по умолчанию: чтобы использовать его, нужно подать заявку. Когда её рассмотрят — неизвестно.
Это то, что я заметил за несколько часов работы. Для кого-то всё перечисленное может быть не критично — основной функционал git-хостинга работает, а я, может, придираюсь.
Я написал письмо в поддержку с описанием проблем и вопросов. Ответ уже пришёл: «взяли в работу и свяжутся позже». Посмотрим, что ответят.
У GitVerse совместно с Хабром проходит конкурс Open Source-проектов «Код без границ». Я решил запрыгнуть в этот поезд со своим проектом ReVu, о котором расскажу подробнее уже в этот четверг.
Одним из условий конкурса является размещение проекта в репозитории на GitVerse.
Я решил воспользоваться ситуацией и «убить двух зайцев»:
- Принять участие в конкурсе
- Интегрировать GitVerse в свой проект
Но, как это часто бывает, всё оказалось не таким простым, как кажется. Об этом — данный пост.
Что понравилось?
1. Своя платформа. Кто бы что ни говорил, но нам нужны собственные аналоги. Сейчас GitHub блокирует доступ для пользователей из Крыма — что мешает однажды расширить эти ограничения? Наличие альтернативы внутри страны — полезно и важно.
2. Облачные раннеры «из коробки». Это удобно: можно запускать простые CI/CD-пайплайны без настройки собственного раннера. Да, есть лимиты, но они есть везде. Плюс — совместимость с GitHub Actions: мои воркфлоу заработали почти без изменений.
3. Приятный интерфейс. Возможно, субъективно, но внешний вид GitVerse современный и аккуратный — работать комфортно, «глаз не режет».
На этом, пожалуй, плюсы заканчиваются. Дальше — обычный git-хостинг без каких-то выдающихся фич.
Что не понравилось?
Здесь уже больше проблем.
1. Ограничения облачных раннеров. Образ сильно урезан: нет даже базовых зависимостей, например Node.js (а он нужен многим Actions). Нет доступа к Docker-сокету — собрать Docker-образ на стандартном раннере невозможно, придётся подключать свой.
2. Вебхуки и безопасность.
2.1. Нет подписи вебхуков. GitHub и Gitea подписывают события через HMAC SHA-256, что позволяет проверить целостность данных. У GitVerse этого нет — можно только добавить заголовок Authorization.
2.2. Некорректные ссылки в вебхуках. Вместо нормальных публичных URL вида
https://gitverse.ru/.../... приходят технические вроде http://gitea-http:3000/.../.... Такое ощущение, что «вышли в прод, а настроить забыли».3. Слабое публичное API. GitVerse основан на Gitea — и это нормально, но при этом доступное API сильно урезано. В Gitea из коробки большой и удобный API, а здесь — «обрезок» без нужных эндпоинтов. К тому же API закрыто по умолчанию: чтобы использовать его, нужно подать заявку. Когда её рассмотрят — неизвестно.
Это то, что я заметил за несколько часов работы. Для кого-то всё перечисленное может быть не критично — основной функционал git-хостинга работает, а я, может, придираюсь.
Я написал письмо в поддержку с описанием проблем и вопросов. Ответ уже пришёл: «взяли в работу и свяжутся позже». Посмотрим, что ответят.
🔥3