Года два назад проникся духом Make'а и решил запилить сборку проекта с юнит тестированием на нём (и генерацией зависимостей, есс-но).
По сути, Make — язык со своей парадигмой, на основе зависимостей, можно горы свернуть. Но в процессе написания чего-то сложного постоянно натыкаешься на нереализованные мелочи, отчего получаются хаки, вкрапления sed'а и прочие не очень понятные вещи.
DLNA работает для всех видео на скриншоте? Некоторые (может быть, все) телевизоры samsung, например, могут показывать матрёшку (так написано в спеках) и поддерживают DLNA. Но потом оказывается, что эта матрёшка только с внешнего диска работает, а по DLNA — уже нет.
Консоль никогда и не была дружественной к пользователю.
Как постоянный пользователь консоли, совершенно не согласен с этим утверждением. Хотя, конечно, гибкость интерфейса несколько ограничена, но во всём остальном он вполне может источать дружелюбие.
Дружественная реализация sudo, это, к примеру, виндовый UAC. По-моему, в kde и гноме тоже что-то подобное было.
gksu и аналоги, наверное. К сожалению, у меня недостаточно знаний о UAC, чтобы грамотно похоливарить, но я не раз встречал по 2 и более окошек подтверждения на копирование файла куда-то в каталог с программой (дело было в windows 7). Это эталон того недружественного подхода, который мне не нравится.
На самом деле, никогда не рассматривал sudo в таком ключе. Мой стандартный сценарий выглядит так: sudo для еденичных команд и sudo -s для крупных задач. Что, однако, никак не нарушает принцип «не работай от root» в моём понимании, так как по-прежнему защищает от опечаток в командах, неожиданно начинающих требовать права на удаление корня вместо пользовательского файла или от безответственных программ пользовательского окружения. (сказано в статье)
Использование sudo в качестве повода перепроверить написанное имеет как минимум две проблемы:
Постоянное впечатывание sudo в длинных сценариях пахнет культом выглядит неоптимально.
С sudo -s реализовать такой подход невозможно впринципе.
И, безусловно, такие принудительные поводы выглядят крайне недружественно по отношению к пользователю.
Хотя, если распределять поток конфет по конфете в каждое устройство и считать распределитель быстродействующим, то можно есть даже в real-time (с лагом в одну операцию устройства), пока суммарная производительность кластера равна потоку конфет.
В real-time есть конфеты одного цвета не получится, жаль. Разве что с небольшим кластером из этих устройств и ощутимой задержкой относительно входных данных^Wконфет.
Использовали GPS как источник времени?
По сути, Make — язык со своей парадигмой, на основе зависимостей, можно горы свернуть. Но в процессе написания чего-то сложного постоянно натыкаешься на нереализованные мелочи, отчего получаются хаки, вкрапления sed'а и прочие не очень понятные вещи.
pastebin.com/BVvCpWJV
pastebin.com/9FakyqTk
Избранные простые моменты:
Но на таком, в отличие от кода из поста, gcc быстро поймёт, что над ним издеваются, и выключится.
зы: день публикации этой новости — не лучший день для ideone
gksu и аналоги, наверное. К сожалению, у меня недостаточно знаний о UAC, чтобы грамотно похоливарить, но я не раз встречал по 2 и более окошек подтверждения на копирование файла куда-то в каталог с программой (дело было в windows 7). Это эталон того недружественного подхода, который мне не нравится.
Использование sudo в качестве повода перепроверить написанное имеет как минимум две проблемы:
Постоянное впечатывание sudo в длинных сценариях
пахнет культомвыглядит неоптимально.С sudo -s реализовать такой подход невозможно впринципе.
И, безусловно, такие принудительные поводы выглядят крайне недружественно по отношению к пользователю.