> Странная политика для репозитория свободного софта.
Политика как раз самая правильная — пакеты должны собираться централизованно, а не заливаться хрен знает кем. Ну и в идеале нужны ещё повторяемые сборки чтобы это проверять, не знаю как у них с этим.
> например в f-droid, благо что для создания репозитория там даже софт устанавливать не нужно, достаточно бесплатного хостинга, вроде GitHub-репозитория или ещё чего-нибудь, где надо создать папку, в папку кинуть xml-файлик и саму apk
Интересен механизм смены светофильтров с первой картинки. Я правильно понимаю что там что-то типа рельсы в виде фигуры Лиссажу по которой катаются фильтры?
Никогда не пользовался "!!", но разве (по крайней мере в zsh) не для этого есть tab, который развернёт "!!" и позволит её просмотреть перед выполнением.
Никто не отрицает. Но случаев когда в неправильной работе программы после оптимизации действительно виноват компилятор — единицы, против целого моря кривого кода кишащего UB.
То есть вы думаете что .onion где торгуют оружием и наркотиками власти не «занимаются», а как только там появится пиратка (которая там, в общем, испокон веков), сразу займутся? И в чём тогда ценность tor, если ему, по-вашему, способны угрожать какие-то правообладатели?
Ну в нормальных окружениях это разделяемые библиотеки которые ставятся в систему единожды и используются всем софтом, поэтому как раз размер каждого конкретного приложения сокращается, а не растёт на размер фреймворка.
> Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код.
Искусство программирования — в алгоритмах и архитуктуре, никто его не убивает. Да и для кросс-платформенного низкоуровнего программирования инструментов предостаточно.
А вот не-кроссплатформенный код, насколько бы изящно и изобретательно он не использовал недокументированные возможности для «выжимания всего из железа» — на деле мёртвый мусор: через N лет железо сменится и он перестанет работать как задумано, ещё через K железа вообще не останется, а запустить этот код получится даже не на каждом эмуляторе (например, игры, использующие свойства ЭЛТ дисплеев чтобы получить больше цветов чем позволяла система).
> Защита от дурака. Все эти бесконечные песочницы и разграничения доступа
> Насчет «генерации музыки на лету» — эта фраза несколько вводит в заблуждение, возникает впечатление, что на лету генерируются ноты. Нет, ноты хранятся в памяти. Но в компактной форме. На лету (в реальном времени) идет только синтез звука.
> Сама библиотека то останется нетронутой (если распространять в бинарном виде).
Библиотеки бывают и header-only, если что. Но тут речь об наиболее распространённом случае, когда есть и .so'шка собирающаяся один раз, и header'ы чувствительные к локальным флагам.
> Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
Дык если даже сделать единый репозиторий (как в линуксе например), то это не отменит хотелку собрать вот эту вот либу с разными флагами компиляции и так далее.
Почему, header'ы собираются с теми флагами с которыми собирается проект, в этом и фишка.
Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.
Хотя тут ещё можно поспорить (одна, но сборка vs. уже собранный пакет, выкачка всей истории vs. только того что нужно), но хорошо — аргумент о необходимости множественной компиляции убираем.
Политика как раз самая правильная — пакеты должны собираться централизованно, а не заливаться хрен знает кем. Ну и в идеале нужны ещё повторяемые сборки чтобы это проверять, не знаю как у них с этим.
Вообще-то, f-droid — репозитрий строго свободного софа, f-droid.org/wiki/page/Inclusion_Policy
Но да, сделать приложение (а заодно и чёрный список телефонов) свободным было бы самым лучшим решением.
Ну, скажем, для первого проекта — поморгать светодиодом — не нужна. А для чего-нибудь серьёзного она нужна в обоих случаях.
> А главное — для старта ISP и USB-Serial потому 1$ никак…
Я стартовал припаяв к LPT разъёму 5 проводков, поэтому кроме attiny действительно ничего покупать не понадобилось.
Ну в нормальных окружениях это разделяемые библиотеки которые ставятся в систему единожды и используются всем софтом, поэтому как раз размер каждого конкретного приложения сокращается, а не растёт на размер фреймворка.
> Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код.
Искусство программирования — в алгоритмах и архитуктуре, никто его не убивает. Да и для кросс-платформенного низкоуровнего программирования инструментов предостаточно.
А вот не-кроссплатформенный код, насколько бы изящно и изобретательно он не использовал недокументированные возможности для «выжимания всего из железа» — на деле мёртвый мусор: через N лет железо сменится и он перестанет работать как задумано, ещё через K железа вообще не останется, а запустить этот код получится даже не на каждом эмуляторе (например, игры, использующие свойства ЭЛТ дисплеев чтобы получить больше цветов чем позволяла система).
> Защита от дурака. Все эти бесконечные песочницы и разграничения доступа
Это вообще мимо, ибо этим занимается система.
> Кризис перепроизводства
Не понятно как это связано с ожирением софта.
Бывает и полностью на лету, без хранения нот (правда не знаю насколько широко она исполльзовалась на практике). Типа countercomplex.blogspot.ru/2011/10/algorithmic-symphonies-from-one-line-of.html
Уже давно нет.
Библиотеки бывают и header-only, если что. Но тут речь об наиболее распространённом случае, когда есть и .so'шка собирающаяся один раз, и header'ы чувствительные к локальным флагам.
> Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
Утопия и дыра в безопасности.
Хотя тут ещё можно поспорить (одна, но сборка vs. уже собранный пакет, выкачка всей истории vs. только того что нужно), но хорошо — аргумент о необходимости множественной компиляции убираем.