список спорных идей linux

В таком случае в нормальных дистрибутивах мэйнтейнера меняют.

В таком случае в нормальных дистрибутивах мэйнтейнера меняют.

Не, ну понятное дело по закону сразу суд, тюрьма, расстрел, ад и погибель. С нормальными дистрибутивами лучше не шутить. Только вот беда - пакетов надо много, а конкурс невелик. Вот и приходится работать с тем, что есть.

chmod 0500 /bin/ps
chmod 0500 /usr/bin/top

И где теперь coreutils для непривелигерованного пользователя?

Ты лучше скажи, где теперь список процессов винды без прямого обращения к WinAPI или хотя бы tasklist?

И где теперь coreutils для непривелигерованного пользователя?

А кто-то запрещает пользователю сделать копию coreutils в ~/ ?

На noexec есть симметричный ответ в виде питона, например.

В мощношелле всё встроено. В .NET есть всё. В vbs (да, оно живо) нет проблем. Зачем winapi и tasklist?

То есть это не системные уже фичи, а фичи указанных свыше языков.

chmod 0500 /bin/ps
chmod 0500 /usr/bin/top

И где теперь coreutils для непривелигерованного пользователя?

Ты издеваешься или тупишь?

for p in /proc/[0-9]*; do echo $(basename $p) $(cat $p/comm); done

4) Множество разрозненных конфигурационных файлов вместо единого реестра.

Ага. и чуть что - все ПИ**ЕЦ. Прямо как в винде...

«пользовательское» использование мавена - найти пакет, собрать, установить из репозитория, установить из файла, запустить тесты. Те же самые команды, что и у %имя_твоего_пакетного_менеджера%.

Их «по дефолту» в rpm, например, нет. По дефолту скачать и установить rpmbuild сначала. И ненужен. Потому что собирать из сорцов нужно тем у кого всякие кастомные инсталляции, а не дефолтовому потребителю rpm. И без «Devel...» группы rpmbuild ничем н поможет.

мое желание касается не интерфейса командной строки с точки зрения пользователя (они везде одинаковые, разве что у апта какие-то задвиги с разделением на apt-cache и apt-get).

Это я понял.

Оно касается именно формата описания пакетов и поддержания жини этого пакета.

И это я понял. Ты хочешь вместо rpm'ов мегатулзу.

Особенно актуально для арчи, в которой установить пакет - самое меньшее дело, надо еще и удержать его в жизнеспособном состоянии в ходе роллинга.

Ага. Тут то мы и пришли к главному. :D

Самое главное в том что если ты гентовод или арчевод, у тебя все сложно и мегаконфигурируемо. И идет речь не о нормальном дистрибутиве линупса - а о большом LSB from scratch с кучей тулзов для «сэр желает извращений. Отсюда и потребность в мавенах.

Соответственно тут речь может идти только о создании своего мегадистрибюутива на мавене++ и о конкуренции с гентой. А вот всем остальным не-извращенцам нафиг это не нужно :D

объем чего больше? :)))

Всего :D

Довольно жалкое оправдание :}

Это не оправдание, это объяснение. По вашему же бессодержательному ответу на это объяснение мне кажется что вы хотите что бы я вас послал. Я прав? :D

Так ты больше ничего и не можешь, кроме как переходить на личности, ничего не поделаешь :}

Новая линза для ubuntu - со ссылками на платные статьи с ieee o_O

Монетизация. Почему то почти все думали что Марк занимается убунтой чисто из гуманитарных соображений... теперь удивляются :D

Так ты больше ничего и не можешь, кроме как переходить на личности, ничего не поделаешь :}

Какой ответ вы предполагали на ваш идиотский комент?

PS
Нет, еще я могу писать аргументы непонятные ограниченным самоуверенным людям, такими людьми игнорируемые. :D

объем чего больше? :)))

Но кстати что характерно - ответа на аргументацию, по существу - нету. А потом меня обвиняют в том что я мол неаргументирую. Я то аргументирую - только вот ответить нечем. И начинаются претензии к стилистике :D

А кто-то запрещает пользователю сделать копию coreutils в ~/ ?

Запрет на запуск всего из хомяка?

Да у тебя батхерт xDD

Я просто не представляю «профессиональных пользователей ОС». Когда арчу настраивал два дня, сосед ржал «да ты теперь fulltime linux user», и это было слегка обидно.

Если я Маша и юзаю только ворд, или Миша и юзаю только дотнет, я же не с ОС общаюсь, а с вордом своим, или дотнетом, и именно под это настраиваю среду, а не под какие-то возможные желание абстрактных fulltime linux userов :)

Но может такие люди есть, тебе виднее.

тред не читал, но вброс на троечку будет.

Но кстати что характерно - ответа на аргументацию, по существу - нету. А потом меня обвиняют в том что я мол неаргументирую. Я то аргументирую - только вот ответить нечем.

Да у тебя батхерт xDD

Я даже это комментировать не буду - просто в рамочку и настену.

Я просто не представляю «профессиональных пользователей ОС».

В зеркало гляньте. Вы профессиональный пользователь виндовса, при чем системы иной кроме интуитивно винды не мыслите. Знания ушли - а импринтинг остался. Линукс для вас - это такая бесплатная венда с исходниками. А все эти юниксвеи - троллинг на ЛОР, вы его(юниксвей) не понимаете и вам с ним неудобно. А cp это для ощущения собственной важности. Вот и непривычно вам под линупсом, и тянет линупс переделать под венду. :D

Когда арчу настраивал два дня, сосед ржал «да ты теперь fulltime linux user», и это было слегка обидно.
Если я Маша и юзаю только ворд, или Миша и юзаю только дотнет, я же не с ОС общаюсь, а с вордом своим, или дотнетом, и именно под это настраиваю среду, а не под какие-то возможные желание абстрактных fulltime linux userов :)

Вы настраиваете среду под определенные представления об удобстве. А представления об удобстве вы почерпнули в компьютерном детстве, прошедшем среди ужасов виндовс 95 в обнимку с мышкой.

Проблема не в том что вы себе настраиваете под дотнет и ворд, и не в том что вам файловые имена не нужны (а вам они не нужны). А в том что вы потом очень всем интересное мнение на тему нужности чего-то начинаете расширять до пределов вселенной. И в интернет транслировать. Подкрепляя рассказами про явапрограммистов и красный диплом на дотнете.

Но может такие люди есть, тебе виднее.

Вы я смотрю дети подземелий какие-то, травмироанные жестокой диктатурой майкрософта. Есть такие люди, есть, целый мир не искалеченных, свободных от этих ваших ужасов людей. :D Программистов, админов и даже юзеров.

Ты издеваешься или тупишь?

Нет, я просто хочу обратить внимание, насколько просто можно получить доступ к чувствительной инфорации.

я просто хочу обратить внимание, насколько просто можно получить доступ к чувствительной инфорации.

Если ты используешь умные слова вроде «доступ к чувствительной информации», ты должен понимать также, что «безопасность» ioctl и read/write ровно одинаковая. Security by obscurity, которую предоставляет ioctl, всерьез никем не рассматривается. Не нужна /proc - сделай chmod -R o-r /proc или просто не монтируй ее.

*)Ломать обратную совместимость с каждой версией, вроде уже сам линус (частично) отказался от этого идиотизма.

Репы — это тот же аппмаркеты, только бесплатный, которые внедряют сейчас во всех ОС.

Какая каша. В бесплатный маркет проги добавляют разработчики - посему он масштабируется. А в репы добавляют мейнтейнеры, что немаштабируемо от слова совсем. Если репы заменят на маркет то будет замечательно.

Потом потребуется отдельная индексация, интеграция с сервисами и так далее, плюс автоматические анализаторы разные - нам же внутрь документа гозрадо приятней глядеть и кросс-ссылатся.

А все это давно уже есть в виде соответствующих сервисов (сайнцдирект, пабмет, гугл школяр вот недавно появился). Другое дело, что публикациями дело и ограничивается (а есть же еще личная переписка, неопубликованные данные, ветки обсуждения на соответствующих форумах и разного рода базы данных). Не говоря уже о такой мелочи, как невозможность работать без инета. Записи можно конечно хранить в каком-нибудь Evernote, но тут опять под вопросом экспорт данных в другие форматы. Не говоря уже о возможности структуризации данных, которые имелись до начала пользования подобным блокнотиком.

А конкретная реализация очень даже будет отличатся от «поиска вообще».

Тут имеется множество задач, общих для всех типов данных. Например поиск дубликатов и черновая структуризация скидываемых данных. Тут без разницы, фотки это, статьи или mp3.

Конкурс также зависит от типа пакета.

Кстати да. Наглядный пример - deadbeef. Собирается вместе с патченным ffmpeg, и этим конфликтует с правилами размещения программ в репозиториях debian, запрещающими bundled libraries. По этой причине deadbeef нет ни в репозиториях debian, ни в репозиториях ubuntu.

С одной стороны мейнтейнеры debian правы, так как против bundled libraries есть весомые аргументы. С другой стороны waker говорил, что решение использовать патченный ffmpeg - тоже имеет аргументы за. И вне зависимости от того, кто прав в данной ситуации, deadbeef - лучший аудиоплеер, доступный в линуксе(имхо конечно же), и я хочу им пользоваться.

Мне как пользователю приходится либо делать .configure/make/make install(checkinstall), либо ставить .deb с сайта программы. Эти действия меня не смущают, но что делать в случае с неопытным пользователем или просто новичком в линуксе? Есть еще конечно ppa, и он ближе всего к концепции управляемого разработчиком кусочка маркета, но способ добавления ppa для неопытного пользователя также не слишком очевиден. Виндовый подход с setup.exe/setup.msi хоть и плох практически во всем, но все же имеет один большой плюс - низкий порог вхождения. И по моим наблюдениям сложность установки сторонних программ больше всего отпугивает новичков, потенциально готовых отказаться от винды в пользу линукс.

PS: да, установка .deb двойным кликом при установленном gdebi практически то же самое, что и установка .msi, но и там есть недостатки, которые мешают сторонним разработчикам распространять ПО в таком виде. Помню тред тут, в котором человек спрашивал, как показывать окно с текстом лицензионного соглашения при установке ПО из .deb, и решением оказалось юзать шеллскрипт с вызовом dialog, что очень похоже на костыль.

ты немного напутал. как раз ffmpeg используется системный (и именно из-за этого, собрать deadbeef с ffmpeg>=0.11 не получается).

но ты прав, если бы ffmpeg был бандленный — проблемы бы не было.

что делать в случае с неопытным пользователем или просто новичком в линуксе?

если речь все еще о deadbeef.. то распаковать архив на рабочий стол, и запустить оттуда файлик «deadbeef» неопытному пользователю, пришедшему с венды или мака, на порядок проще, чем поставить программу из ppa или репов.

(хотя вот сейчас я насчет этого уже не очень уверен, т.к. в основных DE, насколько я помню, десктоп выпилили)

Фигасе неадекват, хотя скорее всего тролль, потому что очень похоже, нести стандартный бред упоротого линуксофанатика. Не просто пользователя линукса, который работает на удобной для себя по техническим, эргономическим или идеологическим причинам, а обычного фанатика, поклоняющегося штольману, болеющего «Microsoft hatered is a disease» Torvalds (c) и карго культу Unix костылей которые придумали когда ничего нормального не было. Плюс школьное «Линукс это круто, а ты вендомышевоз иди на винфак»

Я не говорю что вы сам такой, просто вы попалились как тролль, который такого изображает.

кстати, пикаса например умеет определение лиц при импорте фотографий. почему бы ей их в теги и не писать?

А все это давно уже есть в виде соответствующих сервисов (сайнцдирект, пабмет, гугл школяр вот недавно появился).

Это просто «гуглопоиск» по базам статей. Я не об этом.

Другое дело, что публикациями дело и ограничивается (а есть же еще личная переписка, неопубликованные данные, ветки обсуждения на соответствующих форумах и разного рода базы данных).

Я какбэ в курсе.

Если конкретно я мыслю себе это как некую «кучу» материала. В решении наколенке представь что это git(hg) репозиторий с статьями, ветками форума и так далее, включая емейлы и какие то заметки-статьи. «База» хранится прямо в исходном виде - статьи в pdf, векти формума в виде папки с html и картинками и тп.

Во первых понятно что эту «кучу» проще иметь общую с научруком. Точнее первая куча у аспиранта так и появится, он поставит клиент, зарегается на сервисе(институтском или еще каком), и скажет что хочет получить «кучу» научрука.

Отсюда понятно что таких «куч» у среднего ученого будет несколько, но порядка 2-5 например, мы считаем чт ов пределах рабочей группы или даже лабы такая куча должна быть одна.

во вторых, понятно что индекс к поиску, особенно базовый, проще держать прямо там. И ребилдать на сервере (институтском или каком либо еще) - потому что куча будет в гигабайты размером.

Соответственно для работы с этой кучей будет некий софт организованный по тому самому юниксовому принципу кучи утилит и связанных кубиков :D
- система должна быть организована по принципу аналогичному дропбоксу. То есть локальные клиенты и сервера для метаинформации, в том числе общие, позволяющие легко линковатся друг с другом и с другими инсталляциями своих данных.
- структура «кучи», то есть папки с данными, будет стандартизирована, и это и будет основным местом с чем плагины и куски системы будут работать.
- часть скриптов будет хранится прямо в этой куче.
- часть данных будет «ссылками» на внешние ресурсы, типа например стораджа экспериментальных данных или там на комбинацию гуглозапросов для вытягивания нужной информации.
- мы предполагаем какие то удобные соглашения о написании плагинов к этому всему. Грубо говоря данные плагина тут, любой плагин работает над форком в DVCS, форк потом мержится, кеши тоже хранятся в куче что бы можно было пересчитать на кластере один раз.

Соответственно основной софт должен брать эту «кучу» и предоставлять удобный интерфейс аналогичный IDE. При чем именно с учетом того что такая система идет в разрез с десктопом. Десктоп оптимизирован под то что документы лежат на диске а ты непосредственно работаешь с небольшим их числом.
Тут же полный аналог исходников - если ты пишешь какую нибудь обзорную статью, или делаешь какие нибудь рефераты для личного понимания - будет куча открытых документов. И куча ссылок внутрь других документов.

На это цепляются всякие специфичные области плагины, в том числе самописные. В том числе плагины которые все это интегрируют с гугл школаром. Опять же пабмед только у вас - инженерам и физикам он не нужен.

Опять же, явно должны цеплятся и разные БД и аналогичные инструменты, типа mysq/postgres. Как минимум например для индексов поисков удобнее например сначала расчитать их в бд, потом сдампить sql и хранить его в куче, а потом на клиенте грузить в базу автоматически.

Далее вся эта система должна быть завязана на то что именно вы используете для написания статей с формулами (в том числе вашими специфичными). Я вот например lyx использовал бы - он идеально ложится в эту схему. А вот с вордом будет опа, но тоже можно что-то придумать. Но тем не менее на одном редакторе остановится просто не удастся, как минимум нужно будет openoffice,lyx, латех и просто текст. А так же некую логическую схему работы с этим - как хранить, в каких случаях преобразовывать и так далее.

Не говоря уже о такой мелочи, как невозможность работать без инета. Записи можно конечно хранить в каком-нибудь Evernote, но тут опять под вопросом экспорт данных в другие форматы.

Не говоря уже о возможности структуризации данных, которые имелись до начала пользования подобным блокнотиком.

Ну должны быть программы для импорта же. Плюс если система предоставляет удобную структуризацию - просто придется старые данные в нее наполовину вручную вносить.

Тут имеется множество задач, общих для всех типов данных.

Вообще говоря типовых задач, как типовых сюжетов в литературе, немного. Только вот думать что из этого следует, что софта или романов должно быть тоже немного, это бред.
То есть типовые задачи - это типовые библиотеки. Ну вот проигрывание mp3 типовая задача - и что? Уже даже библиотек некая куча.

Фигасе неадекват ....

<Претензии к стилю поскипаны>

и карго культу Unix костылей которые придумали когда ничего нормального не было.

Я же говорю - человек с виндовс импринтингом, юниксвея банально не понимает. Он не глупый, у него просто вырезана часть мозга. :D

И кстати историческая справка - все это ваше говно включая ГУИ изобрели до юниксвея. Юниксвей это один из последних изобретенных в CE фундаментальных подходов к инженерии компьютерных систем. Даже ОО в парадигме Алана Кея это по сути переработаный юниксвей - а потом пришли непонятливые и все засрали.

Юниквей это сборка систем из кубиков, система кубиков удобная для сборки конечных систем. Когда вы берете железо, разный софт, необходимые потребности и делаете законченное техническое решение. Можно ли так ПО делать? Можно. Но потому что кубики универсальны а не потому что такая система идеальна для разработки «ПО вообще».

А чистые программисты имеют проблемы в понимании юниксвея потому что они всю жизнь пилят кубики, при чем еще и по спекам - и часто это огромные монолитные кубы.

И начинается «да я на яве вызываю стопитсот библиотек, я тоже из кубиков111». Все верно, очень похоже, но библиотека это к сожалению не кубик. А вот демон или cli утилита - кубик. Демон можно вызвать отовсюду, он универсален в плане соединения с другими кубиками. А вот библиотеку, особенно на яве, вы вызываете из того языка на котором она написана. И как только выясняется что нужно стыковать ваш кубик с кубиком рубипрограммистов - начинаются срачи и кидание овном. Пока не приходят юниксоиды и тапком вас не разгоняют по углам, пилить кубики. Придумав xmlrpc, json и тп .... то есть еще один метод вязать юникс демонов и утилиты cli :D

Плюс школьное «Линукс это круто, а ты вендомышевоз иди на винфак»

Линукс батенька, это не круто, это другое. Юниксевей он другой. По этом и на винфак шлют - зачем в линуксе люди которые его хотят переделать под венду? Не нужно, идите на х** -> на винфак.

При чем, заметьте, вам никто не мешает использовать линукс как венду. Хотите - пожалуйста. Но вы то своими вендузячьими лапками пытаетесь другим жизнь испортить и превратить жизнь всех в ваш личный ад которым вы наслаждаетесь. На***

Я не говорю что вы сам такой, просто вы попалились как тролль, который такого изображает.

Мадам, я протрезвею.... ^W^W^W^W А вот вы пропалились что не понимаете юниксвея как инженерного принципа - эту стигмату вам вечно носить, как той мадам кривые ноги :D

ты немного напутал. как раз ffmpeg используется системный (и именно из-за этого, собрать deadbeef с ffmpeg>=0.11 не получается).

А как то динамически его подгружать, и грузить >0.11 при наличии? Слишком сложно?

Я же говорю - человек с виндовс импринтингом, юниксвея банально не понимает

Тут более тонкий момент. Человек с юникс/линукс головного мозга не понимает юниксвея. Все имеет свои недостатки, но столлманоугодность и школьная линукс-крутость не позволяют ему технические решения пропустить через фильтр здравой инженерной критики. Лечитесь, сер

Относительно воплей о демонах, это конечно хорошо, но библиотека заворачивается в демона за 10 мин, кстати так и надо делать. Хорошее приложение разработано обычно в стиле библиотека и два интерфейса - консольный и графический (если в этом есть смысл). А вот если библиотеку не сделать и городить утилитки, то потом будет конгломерат из дерева форков в каждом примитивнейшем приложении. Это будет жрать и тормозить, если еще и болеют текстовым ононизмом. Удачи в написании GIMP в виде набора юниксвей утилит. Вместо передачи данных по стеку в функцию заставим ядро качать блоки по pipe. Если текстовый ононизм присутствует, то сериализация и парсинг, вообще круто. Браво товарищ с инженерным образованием. Что-то я уже сомневаюсь что оно у тебя есть. У меня - системный программист, кафедра специализированных компьютерных систем.

Тут более тонкий момент. Человек с юникс/линукс головного мозга не понимает юниксвея. Все имеет свои недостатки, но столлманоугодность и школьная линукс-крутость не позволяют ему технические решения пропустить через фильтр здравой инженерной критики. Лечитесь, сер

Батенька, юнексвей это не рецепт, а инженерный принцип - недостатки это исключительно аспекты применения. Его применение - это the art (... of unix programming). А работа любого artists это в том числе как раз применение принципа таким образом что бы полученный результат недостатков не имел.

А как то динамически его подгружать, и грузить >0.11 при наличии? Слишком сложно?

в ffmpeg-0.11 API поменялся. в данный момент, он несовместим с deadbeef. официальные билды собираю с более старой версией ffmpeg.

Относительно воплей о демонах, это конечно хорошо, но библиотека заворачивается в демона за 10 мин, кстати так и надо делать. Хорошее приложение разработано обычно в стиле библиотека и два интерфейса - консольный и графический (если в этом есть смысл).

Батенька, один из принципов юниксвея это увеличения connectivity кубиков. То есть поясняю - «библиотека .... так и надо делать» это юниксвей. Увы и ах. :D

А вот если библиотеку не сделать и городить утилитки, то потом будет конгломерат из дерева форков в каждом примитивнейшем приложении.
Это будет жрать и тормозить, если еще и болеют текстовым ононизмом. Удачи в написании GIMP в виде набора юниксвей утилит. Вместо передачи данных по стеку в функцию заставим ядро качать блоки по pipe. Если текстовый ононизм присутствует, то сериализация и парсинг, вообще круто.

Панимаете в чем дело, в отличие от ху*чения огромных блобов индусами и их белыми собратьями, юниксвей требует таланта, умений, инженерной науки и прочего интеллекта. Это более сложный в применении принцип - и по этому более дорогой.

По этому какой нибудь ворд (и гимп, но он говорят внутри в чем то довольной юниксвейный) в виде блоба с тоннами малопонятного обьектного кода есть - а вот решения той же задачи юниксвейно нет. Более того в науке например, применение конкретного научного метода к конкретным случаям - это содержание диссертации. Применение юниксвея к гимпу или ворду - это будет диссертация в инженерных науках. Ну вот да, сложная задача, ниасилили пока.

Если же смотреть на тему «применение юниксвея к дизайну гимпа», то вполне очевидно что кубики там (консольные утилиты / плагины / демоны) должны работать с некими общими бинарными файлами изображений (в разделяемой памяти) - делая mapping только куска файла - мы можем заранее предполагать что редактирование изображений больше чем адресное пространство в 32 бита на 32 машинах будет иметь место постоянно быть. А команды получать уже через пайпы/сокеты, текстом. Будете мне рассказывать как офигенно эта будет сеарилизация будет жрать? :D

Соотвественно по пайпам текстом должны передаваться пути к этим файлам (в памяти или например в mount point для DSM filesystem) и параметры обработки. Это кстате даст нам, при наличии либо годной DSM либо какой другой методы видимости этих файлов в сети

а) кластеризуемость гомогенную.

б) кластеризуемость гетерогенную на разные архитектуры.

в) утилиты можно будет писать на любых языках и с использованием любых библиотек обработки изображений.

У меня - системный программист, кафедра специализированных компьютерных систем.

Судя по написанному как то упустили вас ваши преподаватели :D

О, все понятно, диванный эксперт. Ты хоть соображаешь насколько это все причесывание под не специфичную архитектуру решения, которое на ней эффективно не решается?

Уже представил комитет, какой-то OASIS который 5 лет стандартизирует текстовый протокол взаимодействия кубиков, набор команд. А без стандартизации они сделаны для друг друга - следовательно монолит. И да, тормозящий монолит.

Ты хоть соображаешь насколько это все причесывание под не специфичную архитектуру решения, которое на ней эффективно не решается?

Это было очень по диванному, безапелляционно заявить что «на этой архитектуре не решается». :D

Если говорить о реалистичном подходе то понятно что «ядро» придется писать с нуля, тщательно изучая гимп что бы почерпнуть уже нащупанную логику интерактивного взаимодействия.

Уже представил комитет, какой-то OASIS который 5 лет стандартизирует текстовый протокол взаимодействия кубиков, набор команд. А без стандартизации они сделаны для друг друга - следовательно монолит. И да, тормозящий монолит.

Вообще говоря протокол взаимодействия кубиков для гимпа будет делать не оазисы, а core team разрабов гимпа. Делать его особо универсальным совершенно не обязательно - а точнее наоборот, это будет довольно грязный протокол изменяющийся от версии к версии, и естественно с «расширениями» (или еще как) для разных типов обработчиков. Это будет прямо скажем, семейство протоколов, существующее только внутри гимпа, без всяких лишних проверок и прочего soapа-поапа как вы явисты любите :D

Чтобы ты мог сесть на диван и онанировать на юниксвей? )) Вот у нас все приложение - набор утилит, в котором нами придуманый протокол. Хотите расширить? Ну никто не ограничивает, только сначала разберитесь что мы придумали и завтра мы все переименуем. Удачи. Юникс-вей.

Не, ты эталонный диванщик строчки кода не написавший

А без стандартизации они сделаны для друг друга - следовательно монолит.

Ошибочка. Они сделаны друг для друга - но они не монолит, просто для присоединения к ним нового кубика этот кубик не должен отличатся по неким фундаментальным свойствам. Вопрос не в стандартизации, а в том насколько хорошо выпилен протокол, насколько далеко он «проэволюционирует» внутри гимпа

Если его будут пилить грамотные люди то на том количестве юзкейсов что есть в гимпе - он будет достаточно универсален.

Только они напишут это тормозящее и глючное убожище в 2020. Когда возможно задачи будут уже другие )

Но честно говоря все «ылитарно» идеологические разработки с психами в руководстве просто разбегаются до завершения. Удобство технологии превыше всего если она остается в рамках выполнения задачи.

Чтобы ты мог сесть на диван и онанировать на юниксвей? ))

Я уже перечислил мелкие плюсы. Главный плюс же юниксвея в гимпе это будет возможность делать на нем кастомные решения без копания в кишках гимпа. Кое-какой юниксвейный обработчик изображений кстати есть - imagemagic например. Будете рассказывать о его бесполезности? :D

Вот у нас все приложение - набор утилит, в котором нами придуманый протокол. Хотите расширить? Ну никто не ограничивает, только сначала разберитесь что мы придумали и завтра мы все переименуем. Удачи. Юникс-вей.

«Белки истерички» (C) http://demotivators.to/p/204053/belki-isterichki.htm

Чем протокол по вашему отличается от API? А с API в опенсорсе оно именно так и есть - и ничего, работает.

Не, ты эталонный диванщик строчки кода не написавший

Ява все таки страшная вещь - она ест мозгъ.

Да, и все сразу побегут копать текстовый протокол и его парсить, а потом где-то пихать во внутренности вместо того чтобы на Python написать handler в виде одного класса на 50 строчек, которому Exposed все важные обьекты GIMP. А потом наблюдать 500 процессов у себя на машине )))

Только они напишут это тормозящее и глючное убожище в 2020. Когда возможно задачи будут уже другие )

А возможно не будут. А возможно метеорит упадет. Скорость разработки самого гимпа весьма медленна - и причина банальна, нехватка суммарного платежеспособного спроса - то есть нехватка средств.

Но честно говоря все «ылитарно» идеологические разработки с психами в руководстве просто разбегаются до завершения. Удобство технологии превыше всего если она остается в рамках выполнения

задачи.

В данном случае нужно еще наличие спроса. Юниксвей в гимпе это конкретный набор бенефитов. И не надо мне говорить что например если вы маетесь с изображениями в десяток-другой гигабайт вам не нужна будет в гимпе кластеризуемость - да счас. С руками оторвете.

Проблема в том что это конкретная предпринимательская задача - найти тех кому нужен такой гимп и его им «продать», наладив обратную связь в виде денег. И с вашими рассказами о том что «медленно» и «технологии не те» оно не имеет ничего общего.

Да, и все сразу побегут копать текстовый протокол и его парсить, а потом где-то пихать во внутренности вместо того чтобы

А че, нельзя просто дампать структурку в json а потом ее оттуда цеплять, вот вообще без лишних мыслей? И чтоб дальше лишнего не думать еще, вообще просто в STOMP это все пихать, если для интерактивного общения а не для пайпов?

на Python написать handler в виде одного класса на 50 строчек, которому Exposed все важные обьекты GIMP. А потом наблюдать 500 процессов у себя на машине )))

И красиво крешатся по сегфолтам? :D

Проблема в том что это конкретная предпринимательская задача - найти тех кому нужен такой гимп и его им «продать», наладив обратную связь в виде денег.

А такие люди к стати есть. Например индустрия препресса в области автоматизированных преобразований изображений. Тоже смое с видео. Мы для изображений использовали imagemagic, а проблема того же ffmpeg совсем не в возможностях, а именно в предпринимательстве - различные транскодеры типа flipfactory делают хорошие деньги на этом - а этого добра ежесекундно в мире транскодируются петабайты.

Мы для изображений использовали imagemagic, а проблема того же ffmpeg совсем не в возможностях, а именно в предпринимательстве - различные транскодеры типа flipfactory делают хорошие деньги на этом - а этого добра ежесекундно в мире транскодируются петабайты.

А такие люди к стати есть.

Согласен - клиенты на серверсайд тулкиты для картинкопроцессинга точно есть и толпой. На счет не чистого серверсайда - а интерактива, не уверен что их сколько надо - но тоже можно придумать.

А вот предпринимателей которые эту задачу нормально потянут в условиях FOSS - нету. flipfactory же closedsource наверное. А вот с гимпом пока не получается ничего.

Более того, я подозреваю что легко так может оказаться что коммерческие перспективы юниксвейного гимпа будут на порядок лучше блобного. Именно потому что если на нем будут всякий кастом делать - то юниксвейно это резко удобнее - и разрабов будут нанимать для основной ветки.

Просто нужно все это сделать сорганизовать и тп, взять на себя риски. А вот фиг пока.

Сетевая прозрачность иксов

Слышу про это уже второй год. Никто так и не объяснил, что в этом полезного в повседневной работе с линуксом.