Ну сам репозиторий я веду с помощью aptly - оно автоматизирует вообще всё на уровне "вот этот пакет - вот в этот репозиторий, подпиши и опубликуй", ppa не делал ни разу.
Archlinux формат pkgbuild куда логичнее, ну и crux с alpine
глянул на pkgbuild - хм, подозрительно похоже на то, как реализовано описание пакетов в yocto.
Но на самом деле - если не считать автоматизации сборки - описание метаданных не особо отличается от debian-овского по содержанию.
должно быть что-то вроде блок-схем, тыкаем нужную область окна, оттуда забираются данные, добавляем блоки промежуточной обработки, тыкаем область в приложении, куда должны попасть данные.
Ну да, как-то так. И в блок-схеме - как в тех же delphi - кучка готовых компонентов и возможность написать/нарисовать свой или отнаследовать его от готового.
А ведь можно было обернуть это в инсталлятор с разными профилями
Пристрелите меня. Вы никогда не ставили софт на десятки компьютеров?
Вот как раз с инсталлятором обычно получается "жопа в мыле и ноги сношены". (Есть опыт и с quartus-ом, и с xilinx-овским софтом, и с некоторыми другими штуками под Linux - заканчивалось всё пакетированием этой софтины после установки на одну машину/в виртуалку). С пакетами - это можно сделать удалённо, скриптом и разлить настройки туда же. Конфигурационные файлы из пакетов обычно с комментариями - если вы собираетесь серверным софтом пользоваться - вы их в любом случае читаете как документацию и правите по ходу, а потом кладёте в систему версионирования (в идеале ;-) ).
Если ставите автоматически - то пишете правило в условный ansible, чтобы он эти правки сделал за вас. Профили, кстати могут и быть, где-нибудь в /usr/share/doc/<имя софта>/examples/
PS. Инсталлятор - это худшее, что может быть для установки софта. ИМХО. (из 10+ летнего опыта админства и Винды и Linux-а).
PPS. Если вы хотите профилей - ничто не мешает добавить их в пакет. И добавить выбор дефолтного профиля вопросом при установке. Этот функционал в тех же .deb пакетах существует и работает (не знаю, почему в postgresql этого нет. В почтовиках, например задаёт вопросы при установке и делает предварительную конфигурацию).
Была Picasa - её убили. Есть ещё несколько поделок, полностью завязанные на облака и не работающие оффлайн и/или с оффлайн-файлами. Про удобство интерфейса я даже не заикаюсь, если сунуть туда типичный "миллион фоток за 10 лет", то пользоваться этим будет просто невозможно из-за лагов и примитивнейшего интерфейса а-ля "выведем все фотки последовательно".
Странно. У меня shotwell подлагивает только на подгрузке thumbnails. (лежит примерно 10к фотографий.
Дефолтная классификация - по годам и таймлайну, можно добавить теги и поделить на именованные события - чтобы найти фото, вроде как хватает и без особых проблем?
Где-то 90% usecase-ов затыкает. Не без багов - ну так это opensource.
Банальный нечеткий поиск в файлах по содержимому
В линуксе в gnome был tracker, но я его традиционно прибивал - его сканер уж очень активно дёргал диски. Но он не единственный был. Вроде жив до сих пор?
Потому что после этого будет ровно тот же песец с безопасностью, который был в windows.
Если вам нужно делегировать отдельные права - для этого есть системные группы, куда добавляется пользователь.
Собственно золотое правило: "не работай под рутом без необходимости". В таком раскладе пользователь не может поломать в системе что-либо вне своего домашнего каталога.
Ну вот инсталлятор 1с не смогли без рута сделать.
Инсталлятор 1c вообще-то есть в виде пакетов. Пакеты ставятся из GUI (по крайней мере в debian они просто ставились двойным кликом, запуская gdebi и запрашивая админские права. И это - штатный способ установки того, чего нет в дистрибутиве.
Инсталлятор из .run-файла - это гарантированный способ получить бардак в системе и последующую переустановку, потому что инсталлятор что-то накосячил и вы будете выискивать и чистить, что он вам там наломал. За редким исключением, когда он ставит что-то изолированно в /opt.
Банально иллюстрации для книжек - что лучше, заплатить доллар непонятному художнику (ибо на профессионала денег нет), и ждать неделю-две, или заплатить 2 цента за то, что сгенерят за пару секунд 10-20 вариантов, выберешь подходящий?
Смотря для чего - для технических/научнопопулярных книжек - точно станет хуже. Для художественных - уже наблюдаю периодически, и у меня оно нередко триггерит uncanny valley, почему-то.
А потом выяснять - где нейросеть нагаллюцинировала в этом десятке тысяч.
Во всех современных камерах и телефонах есть exif - с указанием как минимум времени съёмки, как максимум - ещё и геолокации. Так что для того, чтобы отгруппировать по времени не нужно вообще никаких нейросеток. Дальше можно уже грубо руками потегировать то, что важное.
.deb пакет из имеющихся бинарников собирается тривиально
на уровне сложи в одну папку, как в файловой системе лежать будут. назначь права, пропиши текстовый control-файл с зависимостями и запусти одну команду.
Cобирать правильно из голых исходников - сложнее. но там есть вспомогательные утилиты и в общем особого rocket-science там нет. в совсем крайнем случае есть checkinstall, но за ним придётся потом руками писать зависимости пакетов.
Думать - да, надо, ну так это - как везде.
Cобственно даже попатчить существующий пакет не сложно - распаковать, забрать из него DEBIAN каталог, сложить в одну папку, починить и запаковать обратно. Регулярно приходилось делать за всякими любителями или в postinstall статистику установок посылать или вообще в домашний каталог пользователям там же лезть.
Я пользовался именно софтом и mono, но это было... чёрт, давно. 2018-й? Запомнил специфические баги и периодические падения софта и в какой-то момент на него плюнул. Но да, запускалось и в общем и целом работало.
Никто не заставляет пользоваться устаревшей технологией.
На момент покупки железа эта технология была вполне актуальной. И железо продолжит быть актуальным ещё некоторое время. Поменять прошивку BMS материнки не на что. Апплет зашит в неё.
Поддержкой коммерческого софта занимаются его производители, а не разработчики дистрибутивов.
Кстати 1C пакеты готовить нормально не умеет - у них в .deb пакетах есть и забытые зависимости и копирование файлов после установки (в postinst вроде бы) и libstdc++.so.6 в пакете и много чего ещё интересного.
Если сравните ситуацию с Java community – там все гораздо красивей и продуманней. И даже противостояние Spring vs базовый Java EE, только улучшает стандарты. Возможно потому что Java community делает инструмент для себя и поэтому стремится к более эффективным стандартам.
Ооо, прекрасная java с зоопарком версий и несовместимостью между ними. И при этом код для старых версий отваливается в новых. Если это инструмент для себя...
есть приличное количество кейсов когда форматер съедает код и делает его нечитаемым.
Я ещё ни разу не видел, чтобы форматер ломал корректный код.
Вот некорректный ломал. И обычно на этом этапе вопли и заканчивались, потому что следом ломался CI, и человек бежал чинить что он там пытался замёржить, а там и форматирование чинилось само.
Ну сам репозиторий я веду с помощью aptly - оно автоматизирует вообще всё на уровне "вот этот пакет - вот в этот репозиторий, подпиши и опубликуй", ppa не делал ни разу.
глянул на pkgbuild - хм, подозрительно похоже на то, как реализовано описание пакетов в yocto.
Но на самом деле - если не считать автоматизации сборки - описание метаданных не особо отличается от debian-овского по содержанию.
Ну да, как-то так. И в блок-схеме - как в тех же delphi - кучка готовых компонентов и возможность написать/нарисовать свой или отнаследовать его от готового.
Пристрелите меня. Вы никогда не ставили софт на десятки компьютеров?
Вот как раз с инсталлятором обычно получается "жопа в мыле и ноги сношены". (Есть опыт и с quartus-ом, и с xilinx-овским софтом, и с некоторыми другими штуками под Linux - заканчивалось всё пакетированием этой софтины после установки на одну машину/в виртуалку). С пакетами - это можно сделать удалённо, скриптом и разлить настройки туда же. Конфигурационные файлы из пакетов обычно с комментариями - если вы собираетесь серверным софтом пользоваться - вы их в любом случае читаете как документацию и правите по ходу, а потом кладёте в систему версионирования (в идеале ;-) ).
Если ставите автоматически - то пишете правило в условный ansible, чтобы он эти правки сделал за вас. Профили, кстати могут и быть, где-нибудь в /usr/share/doc/<имя софта>/examples/
PS. Инсталлятор - это худшее, что может быть для установки софта. ИМХО. (из 10+ летнего опыта админства и Винды и Linux-а).
PPS. Если вы хотите профилей - ничто не мешает добавить их в пакет. И добавить выбор дефолтного профиля вопросом при установке. Этот функционал в тех же .deb пакетах существует и работает (не знаю, почему в postgresql этого нет. В почтовиках, например задаёт вопросы при установке и делает предварительную конфигурацию).
Странно. У меня shotwell подлагивает только на подгрузке thumbnails. (лежит примерно 10к фотографий.
Дефолтная классификация - по годам и таймлайну, можно добавить теги и поделить на именованные события - чтобы найти фото, вроде как хватает и без особых проблем?
Где-то 90% usecase-ов затыкает. Не без багов - ну так это opensource.
В линуксе в gnome был tracker, но я его традиционно прибивал - его сканер уж очень активно дёргал диски. Но он не единственный был. Вроде жив до сих пор?
Потому что после этого будет ровно тот же песец с безопасностью, который был в windows.
Если вам нужно делегировать отдельные права - для этого есть системные группы, куда добавляется пользователь.
Собственно золотое правило: "не работай под рутом без необходимости". В таком раскладе пользователь не может поломать в системе что-либо вне своего домашнего каталога.
Инсталлятор 1c вообще-то есть в виде пакетов. Пакеты ставятся из GUI (по крайней мере в debian они просто ставились двойным кликом, запуская gdebi и запрашивая админские права. И это - штатный способ установки того, чего нет в дистрибутиве.
Инсталлятор из .run-файла - это гарантированный способ получить бардак в системе и последующую переустановку, потому что инсталлятор что-то накосячил и вы будете выискивать и чистить, что он вам там наломал. За редким исключением, когда он ставит что-то изолированно в /opt.
Смотря для чего - для технических/научнопопулярных книжек - точно станет хуже. Для художественных - уже наблюдаю периодически, и у меня оно нередко триггерит uncanny valley, почему-то.
А потом выяснять - где нейросеть нагаллюцинировала в этом десятке тысяч.
Во всех современных камерах и телефонах есть exif - с указанием как минимум времени съёмки, как максимум - ещё и геолокации. Так что для того, чтобы отгруппировать по времени не нужно вообще никаких нейросеток. Дальше можно уже грубо руками потегировать то, что важное.
.deb пакет из имеющихся бинарников собирается тривиально
на уровне сложи в одну папку, как в файловой системе лежать будут. назначь права, пропиши текстовый control-файл с зависимостями и запусти одну команду.
Cобирать правильно из голых исходников - сложнее. но там есть вспомогательные утилиты и в общем особого rocket-science там нет. в совсем крайнем случае есть checkinstall, но за ним придётся потом руками писать зависимости пакетов.
Думать - да, надо, ну так это - как везде.
Cобственно даже попатчить существующий пакет не сложно - распаковать, забрать из него DEBIAN каталог, сложить в одну папку, починить и запаковать обратно. Регулярно приходилось делать за всякими любителями или в postinstall статистику установок посылать или вообще в домашний каталог пользователям там же лезть.
Я пользовался именно софтом и mono, но это было... чёрт, давно. 2018-й? Запомнил специфические баги и периодические падения софта и в какой-то момент на него плюнул. Но да, запускалось и в общем и целом работало.
Возможно с тех времён стало лучше.
вот этот:
На момент покупки железа эта технология была вполне актуальной. И железо продолжит быть актуальным ещё некоторое время. Поменять прошивку BMS материнки не на что. Апплет зашит в неё.
Это не пример обратной несовместимости?
Консоль управления BMS у asrock rack. Выше определённой версии принципиально отказывается стартовать и работать.
Кстати 1C пакеты готовить нормально не умеет - у них в .deb пакетах есть и забытые зависимости и копирование файлов после установки (в postinst вроде бы) и libstdc++.so.6 в пакете и много чего ещё интересного.
Ну формально - рисовать мышкой цепочку команд и смотреть что там бежит ;-)
Типа того, как у yahoo! pipes было сделано.
sixel, или braile шрифты. даже библиотеки для этого есть. Но обычно такие штуки в браузере смотрятся.
mono умеренно кривой и бажный (ну когда я последний раз смотрел). Может с тех пор стал лучше.
Ооо, прекрасная java с зоопарком версий и несовместимостью между ними. И при этом код для старых версий отваливается в новых. Если это инструмент для себя...
Сейчас меня заминусуют, но он и так выглядит как месиво :-)
А вообще - в тех проектах, где это было у нас - на такие файлы (единичные), мы ставили просто исключение для clang-format.
Кроме того, clang-format умеет исключать кусок кода из форматирования:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
Используя комментарии перед и после этого куска:
Я ещё ни разу не видел, чтобы форматер ломал корректный код.
Вот некорректный ломал. И обычно на этом этапе вопли и заканчивались, потому что следом ломался CI, и человек бежал чинить что он там пытался замёржить, а там и форматирование чинилось само.
Не проще - часть сайтов не пускает "извне", часть - не пускает из России.
Не было - де-факто они заблокировали одно из многих зеркал (своё) и потом разблокировали. Здесь же это единственный репозиторий.
Только всё равно смысла в геоблокировке нет - она же тривиально обходима.