>Под Linux их писать всё ещё не имеет смысла пока он не используется на десктопах массово.
Мне линуксоиды на такую фразу всегда говорят какие-нибудь глупости и начинают разглагольствовать про superior unix foundation.
>Поэтому до того как они перешли на «OSI approved», их лицензии отдавали неприятным душком.
Кто куда перешёл? Просто OSI подтвердила свободность лицензии MS-PL/MS-RL (http://www.opensource.org/licenses/ms-pl www.opensource.org/licenses/ms-rl)
Вы не приемлите «инакомыслие»? Вам мало того, что лицензия «OSI approved»? Всё, что не GPLv3 (которая довольно несвободная по сути вещь) — странные лицензии?
>работает только в IE+.net (ещё выдаёт тупое сообщение с подтверждением запуска)
Неправда же. Как минимум, в FF оно тоже работает. А «тупое сообщение» (вместо запуска очередного трояна без всяких вопросов) оно выдаёт только если приложение не подписано или требует слишком много прав.
P.S. Если вы знаете как в Chrome/Firefox запустить неподписаный exe'шник без всяких «тупых вопросов», то поделитесь способом.
Если Вы не поняли мою мысль, поясню:
говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
А вот сравнивать именованные каналы с библиотеками (в частности COM) — вот это воистину «В огороде бузина, в Киеве дядька». Никакой связи нету. Или вы решили учить сишников, что правильно общаться с библиотеками через UDS, а не вызовы экспортированных функций? Не забудьте потом запостить отчёт на хабр.
>Так Вы каждый раз разное просите. То связать тип файла с приложением, то зачем-то «зайти в сетевой каталог и показать 1000 файлов».
Не, я прошу то же самое, что и в начале — «связать тип файла с приложением». Но я не говорил для чего именно. Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.
>Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org.
Я понимаю, что он, видимо наиболее стандартный способ. Но есть разница между словами «наиболее хороший» и «хороший». Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
>А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы. Хотя хотелось бы, конечно, чтобы Desktop Entry файлы поддерживались обычными шеллами типа bash и POSIX шеллами типа ksh.
>Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
Например, он мог бы запускать установленную в данной системе по умолчанию программу обработки данного типа файла при выполнении команды ./file. (как альтернативу используемой сейчас схеме запуска скриптов через hashbang)
>И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас). Это должен быть один их открытых мировых стандартных форматов. XML для этого вполне подойдёт. Быстро-распарсиваемых? Это не нужно. Распарсить достаточно один раз. Важен только быстрый доступ.
>Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач? Думаю, не будет ошибкой, если я скажу, что этот класс задач больше, чем задачи, для которых обязательно нужно лезть внутрь файла. Если Вы наконец поняли, что расширения тоже важны для определения типа файла, то, я думаю, дискуссию по этому вопросу можно закончить.
Так что там с SVG? Файл есть, поддержка есть, типа нет… грустно как-то
>Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается
Вы, кажется, всё никак не поймёте, что я прошу.
Но с каждым разом всё ближе, так что надежда на понимание есть.
Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ». Desktop Entry поддерживается на уровне DE. Соответственно, не все DE поддерживают это. Опять же такую схему поддерживают не все терминалы. Но какие-то подвижки есть, этого нельзя не признать. (Если бы они ещё выкинули на помойку формат файлов в INI стиле...) Глядишь, лет через 5 кто-нибудь начнёт делать подобную систему для библиотек, а не только для программ.
P.S. «Desktop entry files should have the .desktop extension, except for files of Type Directory which should have the .directory extension.» Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
На всякий случай, уточню, что обсуждение сейчас идёт о эффективности использования расширений файлов для определения типа содержимого.
>а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой. Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере». Или «показать в папке с большим количеством документов только документы Word»
>Сколько Вы выиграете своей регуляркой по имени файла
Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
>Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
Эээ… Вы как-бы понимаете хотя бы примерно сколько операция надо тупо на то, чтобы открыть файл и прочитать пару байт? А чтобы потом применить строковую регулярку? И на сколько порядков больше операций надо сделать в случае, если файл находится не на локальной машине?
//Клуб противников эффективных алгоритмов всё ширится…
Какой-то плохонький способ…
$ file --mime SVG.svg
SVG.svg: text/xml
Но главное — не в этом. Думаю, Вы понимаете, что я имел в виду стандартно расширяемое решение. То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
можно, конечно смело делать >>magic, но ясно, что это решение плохое.
Ну почему-же сразу отсталый. Процессоры же становятся всё быстрее — циклы некуда девать. Какой смысл быстро искать «буковки после точечки» в быстрой хэш таблице? Лучше откроем файл (а ещё лучше, сначала закачаем его из сети), вдумчиво почитаем его, и гордо ответим, что это «что-то напоминающее XML».
Я думаю, что причина — в специализированности и «нестандартности».
Проблема курицы и яйца, опять же. Без инфраструктуры не будет COM классов, если нет COM классов, то инфраструктура не нужна.
>Потому что они не нужны.
Я нигде не утверждал, что они нужны. Я просто констатировал факт, что их нет. А так, да, они не нужны. В винде не нужны, потому, что она их переросла (постепенный переход к .Net), а в линуксе — потому, что он до такого ещё не дорос.
Как паровой двигатель, не нужный ни первобытным племенам, ни современным людям.
>И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
>Чем mime-type не устраивает?
Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.
Мне линуксоиды на такую фразу всегда говорят какие-нибудь глупости и начинают разглагольствовать про superior unix foundation.
Кто куда перешёл? Просто OSI подтвердила свободность лицензии MS-PL/MS-RL (http://www.opensource.org/licenses/ms-pl www.opensource.org/licenses/ms-rl)
Неправда же. Как минимум, в FF оно тоже работает. А «тупое сообщение» (вместо запуска очередного трояна без всяких вопросов) оно выдаёт только если приложение не подписано или требует слишком много прав.
P.S. Если вы знаете как в Chrome/Firefox запустить неподписаный exe'шник без всяких «тупых вопросов», то поделитесь способом.
$ file --mime SVG.svg
SVG.svg: text/xml
Мне кажется, это проблема…
говорить, что «Компоненты любой сложности, также, прекрасно реализуются с помощью машины» серебряной_пули_№123 — плохой тон. Рекламные лозунги нам ни к чему. С таким же успехом «компонент любой сложности» может быть реализован хотя на ассемблере, хоть в машинном коде, хоть на машине Тьюринга.
А вот сравнивать именованные каналы с библиотеками (в частности COM) — вот это воистину «В огороде бузина, в Киеве дядька». Никакой связи нету. Или вы решили учить сишников, что правильно общаться с библиотеками через UDS, а не вызовы экспортированных функций? Не забудьте потом запостить отчёт на хабр.
Не, я прошу то же самое, что и в начале — «связать тип файла с приложением». Но я не говорил для чего именно. Запуск программы — один из возможных контекстов. Показ иконок для 1000 файлов — другой. Фильтрация документов определённого типа — третий.
>Desktop Entry файлы — это тот самый стандартный способ. Описанный в стандарте FreeDesktop.org.
Я понимаю, что он, видимо наиболее стандартный способ. Но есть разница между словами «наиболее хороший» и «хороший». Я имею в виду, что даже «наиболее хороший» тем не менее может быть недостаточно хорош. Надеюсь, вы понимаете мою мысль.
>А насчёт «чтобы везде работал» — это к разработчикам того самого «везде».
Стандартная отмазка — «если чего-то нет, допиши сам или попинай авторов». Но это немного не в тему — я не обязан собственноручно заниматься улучшением *nix (и не прошу никого улучшать его для меня); я просто констатирую наличие проблемы. Хотя хотелось бы, конечно, чтобы Desktop Entry файлы поддерживались обычными шеллами типа bash и POSIX шеллами типа ksh.
>Вот тут, пожалуйста, поподробнее: каким образом терминал может такое «поддерживать»?
Например, он мог бы запускать установленную в данной системе по умолчанию программу обработки данного типа файла при выполнении команды ./file. (как альтернативу используемой сейчас схеме запуска скриптов через hashbang)
>И каким же форматом Вы предлагаете заменить один из самых легко- и, самое главное, быстро-распарсиваемых форматов? Варианты в студию!
Думаю, вы согласитесь. что для такой вещи плохо использовать слабо специфицированный плохорасширяемый негибкий INI-подобный формат с ворохом вендор-проприетарных расширений (как это происходит сейчас). Это должен быть один их открытых мировых стандартных форматов. XML для этого вполне подойдёт. Быстро-распарсиваемых? Это не нужно. Распарсить достаточно один раз. Важен только быстрый доступ.
>Поэтому в данном случае быстро отсеять мусор по маске имени файла — необходимая оптимизация.
Неужели Вы наконец признали, что использование «буковок после точечки в конце имени файла» — это не глупость, а важная оптимизация, покрывающая довольно большой класс задач? Думаю, не будет ошибкой, если я скажу, что этот класс задач больше, чем задачи, для которых обязательно нужно лезть внутрь файла. Если Вы наконец поняли, что расширения тоже важны для определения типа файла, то, я думаю, дискуссию по этому вопросу можно закончить.
Зачем повторять мне мои же слова?
Я выше уже соглашался, что «паровой двигатель, не нужен первобытным племенам»
Как на PHP работать с SSE регистрами процессора?
>Блин, мне даже как-то неудобно «бить лежачего», но если он сам упорно напрашивается
Вы, кажется, всё никак не поймёте, что я прошу.
Но с каждым разом всё ближе, так что надежда на понимание есть.
Итак, чем меня не устраивают Desktop Entry файлы? Я просил, повторяю, «стандартный (чтобы всеми признавался и везде работал) способ». Desktop Entry поддерживается на уровне DE. Соответственно, не все DE поддерживают это. Опять же такую схему поддерживают не все терминалы. Но какие-то подвижки есть, этого нельзя не признать. (Если бы они ещё выкинули на помойку формат файлов в INI стиле...) Глядишь, лет через 5 кто-нибудь начнёт делать подобную систему для библиотек, а не только для программ.
P.S. «Desktop entry files should have the .desktop extension, except for files of Type Directory which should have the .directory extension.» Интересно, зачем эти глупые люди парятся по поводу «буковок после точечки в конце имени файла»...?
>а обе они находятся в контексте «открыть после этого файл соответствующей программой»?
Неправильно думаете/придумываете. Я же не сказал, что контекст именно такой. Контекст может быть, например «зайти файловым менеджером в сетевую папку с 1000 файлов на удалённом компьютере». Или «показать в папке с большим количеством документов только документы Word»
>Сколько Вы выиграете своей регуляркой по имени файла
Выделение подстроки, находящейся после последней точки можно назвать регуляркой лишь с большой натяжкой. Более того, эта операция имеет сложность, не зависящую от количества типов файлов, которые мы умеем различать.
>Вам ни о чём не говорят, раз Вы думаете об оптимизации операции, занимающей доли процента от общего времени выполнения задачи.
В корне неверные расчёты и выводы. Вы берёте один контекст и делаете какие-то выводы, зыбыв, что контекстов бывает множество.
//Клуб противников эффективных алгоритмов всё ширится…
$ file --mime SVG.svg
SVG.svg: text/xml
Но главное — не в этом. Думаю, Вы понимаете, что я имел в виду стандартно расширяемое решение. То есть стандартное решение, при котором установленная программа могла бы связать себя с определённым форматом.
можно, конечно смело делать >>magic, но ясно, что это решение плохое.
Хабр катится всё дальше… в светлое разумное будущее, конечно.
Проблема курицы и яйца, опять же. Без инфраструктуры не будет COM классов, если нет COM классов, то инфраструктура не нужна.
Я нигде не утверждал, что они нужны. Я просто констатировал факт, что их нет. А так, да, они не нужны. В винде не нужны, потому, что она их переросла (постепенный переход к .Net), а в линуксе — потому, что он до такого ещё не дорос.
Как паровой двигатель, не нужный ни первобытным племенам, ни современным людям.
>И, кстати, компоненты любой сложности прекрасно реализуются с помощью unix domain sockets.
Компоненты любой сложности, также, прекрасно реализуются с помощью машины Тьюринга…
>Чем mime-type не устраивает?
Покажите мне стандартный (чтобы всеми признавался и везде работал) способ связать бинарный файл с MIME type'ом.