Комментарии 150
НЛО прилетело и опубликовало эту надпись здесь
а где можно глянуть на >3000 команд? просто интересно стало :)
раньше они интересовались стандартами лишь с целью сделать свои несовместимые реализации, дабы помешать распростарнению этих стандартов
Давайте Вы не будете заниматься бестолковым бэшингом и немножечко подумаете?
VML was submitted as a proposed standard to the W3C in 1998 by Autodesk, Hewlett-Packard, Macromedia, Microsoft, and Visio.
The SVG specification is an open standard that has been under development by the World Wide Web Consortium (W3C) since 1999.
Неужели получается, что это именно SVG — «несовместимый»?
VML was submitted as a proposed standard to the W3C in 1998 by Autodesk, Hewlett-Packard, Macromedia, Microsoft, and Visio.
The SVG specification is an open standard that has been under development by the World Wide Web Consortium (W3C) since 1999.
Неужели получается, что это именно SVG — «несовместимый»?
НЛО прилетело и опубликовало эту надпись здесь
а?
VML в терминах W3C не является стандартом — «стандарты» имеют статус «Recommendation». www.w3.org/TR/NOTE-VML есть всего-лишь проигранный тендер (в котором выиграл SVG) на разработку технологии векторной графики. Также VML не разрабатывается с 1999 года в отличие от SVG которым занимаются достаточно активно.
Я это понимаю. Я написал именно про башинг. Бессмысленный и беспощадный. А ведь всего то делов — один «проигранный тендер».
Конечно это не «всего то делов», я с вами согласен. Но хорошо зная и VML и SVG (писал SVG на VML: пример) замечу, что последний удобнее и более consistent (не знаю как это по-русски)
Всего два вопроса:
1. Чем же по Вашему posix лучше win32?
2. Что мешает им сосуществовать (полагаю Вы в курсе, что Windows вполне себе POSIX-сертифицированная ОС)?
1. Чем же по Вашему posix лучше win32?
2. Что мешает им сосуществовать (полагаю Вы в курсе, что Windows вполне себе POSIX-сертифицированная ОС)?
НЛО прилетело и опубликовало эту надпись здесь
1. Серьезно? А мне почему то казалось, что POSIX — просто пост-фактум стандартизированные интерфейсы одной из самых дорогостоящих ОС своего времени. Вы ведь помните, что означает последняя буква в этой аббревиатуре, да?
2. Так а к чему тогда вообще «глядишь заменят win api на posix api»? Зачем менять, если они отлично сосуществуют? Кроме того, вообще о смене можно подумать только после ответа на первый вопрос. Пока же я увидел только лозунг, не слишком близкий к реальности.
2. Так а к чему тогда вообще «глядишь заменят win api на posix api»? Зачем менять, если они отлично сосуществуют? Кроме того, вообще о смене можно подумать только после ответа на первый вопрос. Пока же я увидел только лозунг, не слишком близкий к реальности.
НЛО прилетело и опубликовало эту надпись здесь
1) posix api гораздо удобнее в использовании, чем win api.
2) Уже давно подсистема posix не поставляется, да и та, что была, кастрирована чуть более чем процентов на 70. Вроде еще где-то была отдельная более совершенная, но ее тоже качать надо.
2) Уже давно подсистема posix не поставляется, да и та, что была, кастрирована чуть более чем процентов на 70. Вроде еще где-то была отдельная более совершенная, но ее тоже качать надо.
1. Серьезно? Хорошо бы пример. А то, знаете ли, у меня совершенно другие ощущения.
2. Серьезно? Давно в Programs and Features заглядывали?
2. Серьезно? Давно в Programs and Features заглядывали?
1) Посмотри, например, pthreads.
2) Открой 57ю страницу книжки Руссиновича. Ну и заодно поищи psxss.exe и psxdll.dll. Я ни в vista hp, ни в win xp sp3 их не вижу.
2) Открой 57ю страницу книжки Руссиновича. Ну и заодно поищи psxss.exe и psxdll.dll. Я ни в vista hp, ни в win xp sp3 их не вижу.
1. Виндовые потоки НАМНОГО удобнее и консистентнее позиксовых.
2. Естественно не видишь. Ибо SFU/SUA всю жизнь были серверным компонентом. Правда в Windows 7 ее таки зачем то включили в клиентскую ОС img230.imageshack.us/img230/8338/capturemd.png
2. Естественно не видишь. Ибо SFU/SUA всю жизнь были серверным компонентом. Правда в Windows 7 ее таки зачем то включили в клиентскую ОС img230.imageshack.us/img230/8338/capturemd.png
1) Чем же?
2) А мне какая разница? Написано Windows. Откуда я знаю, что под словом windows вдруг стали подразумевать только Win Server, а не все семейство?
2) А мне какая разница? Написано Windows. Откуда я знаю, что под словом windows вдруг стали подразумевать только Win Server, а не все семейство?
Да хотя бы тем, что потоки никогда не прикидывались процессами. То есть ИЗНАЧАЛЬНЫМ архитектурным решением было ввести две сущности: одну — единицу исполнения и другую — контейнер для ресурсов. Join-ы/detach-и (и идея joinability вообще) — это вообще что-то страшное. В винде что сами потоки, что event-ы (condition-ы), что mutex-ы (а также семафоры, таймеры, процессы, консоль и пр.) ожидаются одной функцией (на самом деле их несколько: одна простая для ожидания одного объекта и более сложная — для ожидания нескольких, но это сделано исключительно для удобства и сути не меняет).
При этом, скажем, большая часть этих объектов может быть именованой (в том же неймспейсе, что и файловые системы — называемой директорией объектов), чтобы их можно было открыть из других процессов/сессий. Права доступа НА ВСЕ эти объекты контроллируются тоже единообразно.
Есть встроенные threadpool-ы, есть IOCP, асинхронные процедуры, job-ы (которые значительно шире позиксовых process groups) и многое другое.
Я честно говоря вообще не понял, на что Вы надеялись, приводя в пример pthreads.
При этом, скажем, большая часть этих объектов может быть именованой (в том же неймспейсе, что и файловые системы — называемой директорией объектов), чтобы их можно было открыть из других процессов/сессий. Права доступа НА ВСЕ эти объекты контроллируются тоже единообразно.
Есть встроенные threadpool-ы, есть IOCP, асинхронные процедуры, job-ы (которые значительно шире позиксовых process groups) и многое другое.
Я честно говоря вообще не понял, на что Вы надеялись, приводя в пример pthreads.
ваш собеседник привел пример несоответствия API Windows стандарту (ну или рекомендации) POSIX.
Самое дерьмо в реализации MS заключается в том, что портировать unix-программы невозможно. Что там у них написано про поддержку — это вопрос десятый.
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой.
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий. Скорее всего сознательно.
Самое дерьмо в реализации MS заключается в том, что портировать unix-программы невозможно. Что там у них написано про поддержку — это вопрос десятый.
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой.
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий. Скорее всего сознательно.
ваш собеседник привел пример несоответствия API Windows стандарту (ну или рекомендации) POSIX.
Вы правда не читали? Напоминаю:
> posix api гораздо удобнее в использовании, чем win api.
> Хорошо бы пример. А то, знаете ли, у меня совершенно другие ощущения
> Посмотри, например, pthreads.
О боже. Невозможно? Откуда ж столько портов?
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой
Эх, вот если бы люди говорили только о вещах в которых разбираются. Мечты, мечты…
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий.
О пресвятая Гаечка. Даже если бы Ваше предыдущее утверждение имело хоть какой то смысл, отследить логическую связь с вот этим вот бредом невозможно.
Мало того, что pthread-ы полностью реализованы в SUA. Но хуже всего то, что ВСЕ pthread-овые вызовы — крайне примитивное подмножество виндовых потоков. К тому же, как я уже сказал, неконсистентное и неудобное.
Вы правда не читали? Напоминаю:
> posix api гораздо удобнее в использовании, чем win api.
> Хорошо бы пример. А то, знаете ли, у меня совершенно другие ощущения
> Посмотри, например, pthreads.
О боже. Невозможно? Откуда ж столько портов?
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой
Эх, вот если бы люди говорили только о вещах в которых разбираются. Мечты, мечты…
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий.
О пресвятая Гаечка. Даже если бы Ваше предыдущее утверждение имело хоть какой то смысл, отследить логическую связь с вот этим вот бредом невозможно.
Мало того, что pthread-ы полностью реализованы в SUA. Но хуже всего то, что ВСЕ pthread-овые вызовы — крайне примитивное подмножество виндовых потоков. К тому же, как я уже сказал, неконсистентное и неудобное.
— Как я понимаю, cygwin нужен потому, что из POSIX подсистемы NT нельзя достучаться до подсистемы Win32. В таком разрезе POSIX подсистема NT представляется сравнительно бесполезной штукой.
— Не знаю, как не серверную линию, которая к тому же дорогая, а портирование на начальные продукты Windows посикс-приложений наталкивается на серьезные трудности, из-за отстутствия fork-а.
— Не знаю, как не серверную линию, которая к тому же дорогая, а портирование на начальные продукты Windows посикс-приложений наталкивается на серьезные трудности, из-за отстутствия fork-а.
Можно достучаться. Сygwin — это не posix api для windows. Cygwin — это целое окружение, а не только system api
По поводу fork — качайте SUA, там это есть: в win 7 подсистема debugging caps сама пользуется полным аналогом fork-а, чтобы клонировать процессы
По поводу fork — качайте SUA, там это есть: в win 7 подсистема debugging caps сама пользуется полным аналогом fork-а, чтобы клонировать процессы
О, еще по поводу fork — не сочтите за труд взглянуть сюда, пожалуйста:
groups.google.co.uk/group/comp.os.ms-windows.programmer.nt.kernel-mode/browse_thread/thread/86837f458b67a79f/eeceb4c546b35314?lnk=st&q=ntcreateprocess+fork&rnum=4&hl=en#eeceb4c546b35314
groups.google.co.uk/group/comp.os.ms-windows.programmer.nt.kernel-mode/browse_thread/thread/86837f458b67a79f/eeceb4c546b35314?lnk=st&q=ntcreateprocess+fork&rnum=4&hl=en#eeceb4c546b35314
> the kernel will fork
Как я понимаю, слово 'fork' и интерфейс API fork не совсем одно и то же.
Как я понимаю, слово 'fork' и интерфейс API fork не совсем одно и то же.
А почему мне должно быть не все равно, как вы понимаете? Функционал-то аналогичный присутствует, написать обертку для него — задача несложная. Главное, что:
— образ процесса клонируется;
— shared memory доступна обоим процессам;
— дескрипторы (хэндлы в терминологии винды) сдублируются;
— id дочернего процесса вернется.
На rsdn, если я не ошибаюсь, где-то есть статья, как написать грубый аналог inetd для windows при помощи такой операции
— образ процесса клонируется;
— shared memory доступна обоим процессам;
— дескрипторы (хэндлы в терминологии винды) сдублируются;
— id дочернего процесса вернется.
На rsdn, если я не ошибаюсь, где-то есть статья, как написать грубый аналог inetd для windows при помощи такой операции
Добавлю
1. Но можно (очевидно) достучаться до Native подсистемы, поверх которой реализованы и POSIX и Win32 — никаких проблем
2. Fork действительно плохо ложится на архитектуру NT (пожалуй единственный позиксовый системный вызов), но во первых есть vfork, который ложится идеально и даже работает быстрее, покрывая при это подавляющее большинство usecase-ов fork-а, а во вторых нынешним «модным трендом» является использование потоков, которые тоже элементарно реализуются в NT.
1. Но можно (очевидно) достучаться до Native подсистемы, поверх которой реализованы и POSIX и Win32 — никаких проблем
2. Fork действительно плохо ложится на архитектуру NT (пожалуй единственный позиксовый системный вызов), но во первых есть vfork, который ложится идеально и даже работает быстрее, покрывая при это подавляющее большинство usecase-ов fork-а, а во вторых нынешним «модным трендом» является использование потоков, которые тоже элементарно реализуются в NT.
1) Не хочется лезть в то, что мне не особо надо, но судя по тому, что при разработчики Cygwin указывают на сложности с эмуляцией форка, не все так просто.
2) Нет, vfork не годится для замены fork. Именно поэтому на платформе Win32 подавляющее распространение получили треды.
3) Думаю повсеместное применение тредов вызвано именно распространенностью win32. Думаю что ситуация будет выравниваться в сторону восстановления применения процессов там, где это оправданно. А оно много где оправданно.
2) Нет, vfork не годится для замены fork. Именно поэтому на платформе Win32 подавляющее распространение получили треды.
3) Думаю повсеместное применение тредов вызвано именно распространенностью win32. Думаю что ситуация будет выравниваться в сторону восстановления применения процессов там, где это оправданно. А оно много где оправданно.
1. А Win32 подсистема Вам значит нужна из POSIX?
2. vfork годится потому что в подавляющем большинстве случаев следом идет exec*. Про «именно поэтому» я бы перефразировал: именно потому, что fork не отвечал современным требованиям к параллельным вычислениям и появились pthread-ы.
Я, к примеру, вот так сходу не могу придумать примера, когда использование fork оправдано — всегда либо создание процесса fork/exec, либо все те же «потоки», но в отдельном (скопированном) адресном пространстве. Можете привести хотя бы один usecase когда fork справляется лучше, чем даже pthreads (и не забывайте, что создание потока примерно в 10 раз дешевле форка)?
2. vfork годится потому что в подавляющем большинстве случаев следом идет exec*. Про «именно поэтому» я бы перефразировал: именно потому, что fork не отвечал современным требованиям к параллельным вычислениям и появились pthread-ы.
Я, к примеру, вот так сходу не могу придумать примера, когда использование fork оправдано — всегда либо создание процесса fork/exec, либо все те же «потоки», но в отдельном (скопированном) адресном пространстве. Можете привести хотя бы один usecase когда fork справляется лучше, чем даже pthreads (и не забывайте, что создание потока примерно в 10 раз дешевле форка)?
Ну вот сейчас я пишу сервер на процессах: тысячи fork() и ни одного vfork() или exec().
На Линукс нет такого соотношения именно за счет скорости форк.
В win32 такая ситуация именно потому, что там есть треды и vfork но нет форка. Т.е. нет вызова, позволяющего очень быстро создать новый процесс.
А области где отдельный процесс лучше, чем треды известны:
— Надежность
— Простота
— Защищенность адресного пространства
На Линукс нет такого соотношения именно за счет скорости форк.
В win32 такая ситуация именно потому, что там есть треды и vfork но нет форка. Т.е. нет вызова, позволяющего очень быстро создать новый процесс.
А области где отдельный процесс лучше, чем треды известны:
— Надежность
— Простота
— Защищенность адресного пространства
Ну вот сейчас я пишу сервер на процессах: тысячи fork() и ни одного vfork() или exec().
Ну да, Вы пишете многопоточное приложение. Я же просил привести пример, когда форк дает какую либо выгоду по сравнению с vfork/exec и pthread_create (Ну или по сравнению c CreateProcess/CreateThread, если угодно).
Скажу более, создание стапиццот единиц исполнения может привести к ЗАМЕДЛЕНИЮ исполнения (особенно на линуксовых скедьюлерах, которые меняются раз в пару лет, а толку никакого). Именно поэтому для виндового IOCP рекомендуется (и по умолчанию ставится) количество рабочих потоков, не превышающих количества процессоров.
На Линукс нет такого соотношения именно за счет скорости форк.
Нет. Во первых я мерял. Форк был около 700к тактов на линуксе. CreateThread — меньше 100к. Во вторых это очевидно. CreateThread создает пару структур в ядре и все. fork — инициализирует новое адресное пространство, копирует все дескрипторы и делает еще туеву хучу ненужной работы.
А области где отдельный процесс лучше, чем треды известны
Опять лозунги. Я же вроде бы попросил конкретный use case. Я не вижу никаких проблем ни с безопасностью, ни с простотой, ни с надежностью.
Ну да, Вы пишете многопоточное приложение. Я же просил привести пример, когда форк дает какую либо выгоду по сравнению с vfork/exec и pthread_create (Ну или по сравнению c CreateProcess/CreateThread, если угодно).
Скажу более, создание стапиццот единиц исполнения может привести к ЗАМЕДЛЕНИЮ исполнения (особенно на линуксовых скедьюлерах, которые меняются раз в пару лет, а толку никакого). Именно поэтому для виндового IOCP рекомендуется (и по умолчанию ставится) количество рабочих потоков, не превышающих количества процессоров.
На Линукс нет такого соотношения именно за счет скорости форк.
Нет. Во первых я мерял. Форк был около 700к тактов на линуксе. CreateThread — меньше 100к. Во вторых это очевидно. CreateThread создает пару структур в ядре и все. fork — инициализирует новое адресное пространство, копирует все дескрипторы и делает еще туеву хучу ненужной работы.
А области где отдельный процесс лучше, чем треды известны
Опять лозунги. Я же вроде бы попросил конкретный use case. Я не вижу никаких проблем ни с безопасностью, ни с простотой, ни с надежностью.
> fork — инициализирует новое адресное пространство, копирует все дескрипторы и делает еще туеву хучу ненужной работы.
Как раз за счет copy-on-write fork не делает лишней работы.
> Опять лозунги.
Это не лозунги. На форках сервера делать легче. Труднее IPC Но зато выше безопасность. Это как-бы азбука вообще-то. Если мы даже в этом не сходимся, то пора заканчивать беседу.
Как раз за счет copy-on-write fork не делает лишней работы.
> Опять лозунги.
Это не лозунги. На форках сервера делать легче. Труднее IPC Но зато выше безопасность. Это как-бы азбука вообще-то. Если мы даже в этом не сходимся, то пора заканчивать беседу.
Вы, похоже, совершенно не представляете, что делает fork. Это потокам не нужно дополнительное адресное пространство. форк же, помимо собственно создания все той же единицы исполнения, должен создать адресное пространство (на x86 это PDE/PTE таблицы)
В смысле структур ядра — конечно создает.
В смысле структур ПРОЦЕССОРА. Ну и для ядра приходится больше заниматься. Ведь чтоб создать новый контейнер ресурсов и скопировать туда все ресуры тоже нужно маленько постараться.
Да, кстати, в ядре NT нет ничего такого, что помешало бы реализации полноценного форка, но СЕЙЧАС это не реализовано. И, признаться, мне совсем не грустно по этому поводу
Да, кстати, в ядре NT нет ничего такого, что помешало бы реализации полноценного форка, но СЕЙЧАС это не реализовано. И, признаться, мне совсем не грустно по этому поводу
> Да, кстати, в ядре NT нет ничего такого, что помешало бы реализации полноценного форка, но СЕЙЧАС это не реализовано. И, признаться, мне совсем не грустно по этому поводу
Я тоже думаю, что было бы возможно сделать форк в ядре НТ, хотя может что-то и мешает, я не настолько знаток НТ.
Но вот Майкрософт потихонечку теряет рынок серверов, а на рынке сверхмощных компьютеров вообще едва присутствует. Возможно отсутствие форка также играет в этом свою роль.
Я тоже думаю, что было бы возможно сделать форк в ядре НТ, хотя может что-то и мешает, я не настолько знаток НТ.
Но вот Майкрософт потихонечку теряет рынок серверов, а на рынке сверхмощных компьютеров вообще едва присутствует. Возможно отсутствие форка также играет в этом свою роль.
Но вот Майкрософт потихонечку теряет рынок серверов
Что?!!!
70% серверного рынка и растет.
на рынке сверхмощных компьютеров вообще едва присутствует
Это да. Только я не понимаю о чем это говорит.
Возможно отсутствие форка также играет в этом свою роль.
Мдя, человеку, видевшему только молоток, все проблемы кажутся гвоздями. fork даже рядом не валялся со средствами параллельного исполнения винды.
Что?!!!
70% серверного рынка и растет.
на рынке сверхмощных компьютеров вообще едва присутствует
Это да. Только я не понимаю о чем это говорит.
Возможно отсутствие форка также играет в этом свою роль.
Мдя, человеку, видевшему только молоток, все проблемы кажутся гвоздями. fork даже рядом не валялся со средствами параллельного исполнения винды.
Ах, да
3. Что будем делать с тем же mach, в котором все те же процессы (task) и потоки (threads)? Странным образом он появился раньше NT. Причем в той же MacOSX для скедьюлинга используется именно mach — без всякой винды. «Потоки» распространены потому, что они лучше разделяют абстракции и являются более хорошим решением во всех сценариях использования
3. Что будем делать с тем же mach, в котором все те же процессы (task) и потоки (threads)? Странным образом он появился раньше NT. Причем в той же MacOSX для скедьюлинга используется именно mach — без всякой винды. «Потоки» распространены потому, что они лучше разделяют абстракции и являются более хорошим решением во всех сценариях использования
Вообще-то, там, где есть форк, больше распространены процессы.
Насчет mach я не совсем понял, это ведь вроде микроядро? Не совсем в тему? Или Вы что-то другое имеете в виду, о чем я не в курсе.
Насчет mach я не совсем понял, это ведь вроде микроядро? Не совсем в тему? Или Вы что-то другое имеете в виду, о чем я не в курсе.
Вообще-то, там, где есть форк, больше распространены процессы.
Вообще то там, где волнуются о производительности больше распространены потоки, которые не только легче сами по себе, так еще и избавляют от расходов на IPC.
Насчет mach я не совсем понял, это ведь вроде микроядро
И что? Когда само по себе — микроядро, когда в составе XNU — гибридное. Это что-то меняет?
Это к тому, что потоки появились, хм… несколько раньше NT.
И, да, практически у всех коммерческих ОС были потоки до появления pthread-ов. Вот, к примеру, солярка: docs.sun.com/app/docs/doc/806-6867/sthreads-10606?l=ja&a=view
Вообще то там, где волнуются о производительности больше распространены потоки, которые не только легче сами по себе, так еще и избавляют от расходов на IPC.
Насчет mach я не совсем понял, это ведь вроде микроядро
И что? Когда само по себе — микроядро, когда в составе XNU — гибридное. Это что-то меняет?
Это к тому, что потоки появились, хм… несколько раньше NT.
И, да, практически у всех коммерческих ОС были потоки до появления pthread-ов. Вот, к примеру, солярка: docs.sun.com/app/docs/doc/806-6867/sthreads-10606?l=ja&a=view
Я не пойму, какое это имеет отношение к предмету нашей беседы. В смысле устройство ядра MacOS А в области программ/серверов MacOS это BSD.
Вы сказали, что это винда «виновата» в использовании потоков. Я же говорю, что у всех свои потоки — идея просто очень «чистая»
Такого я не мог сказать. Единственное что я мог сказать, что в Windows нет форка.
Думаю повсеместное применение тредов вызвано именно распространенностью win32. Думаю что ситуация будет выравниваться в сторону восстановления применения процессов там, где это оправданно. А оно много где оправданно.
Пока что я получил только один пример, в котором использование хоть как то оправдано. И то не от Вас. Причем этот пример ОЧЕНЬ специфический
Пока что я получил только один пример, в котором использование хоть как то оправдано. И то не от Вас. Причем этот пример ОЧЕНЬ специфический
Если Вы откроете книжку или статью по написанию серверов (не виндовс онли), то первое, что Вы там увидите, это будет сервер на форках.
Ага, если я открою linux-only книжку, то первое, что я увижу будет linux-only сервер.
Но почему же если смотреть на солярковый сервер, к примеру, я все еще вижу потоки? docs.sun.com/source/819-0908-10/agAperf.html
Но почему же если смотреть на солярковый сервер, к примеру, я все еще вижу потоки? docs.sun.com/source/819-0908-10/agAperf.html
Windows services for Unix — бесплатная.
А что за негодование «но ее тоже надо качать»? Из линуксового репозитория пакеты качать не обломится, а с microsoft.com, значит, напрягает, что ли?
А что за негодование «но ее тоже надо качать»? Из линуксового репозитория пакеты качать не обломится, а с microsoft.com, значит, напрягает, что ли?
Напрягает то, что люди считают систему posix-совместимой, хотя де-факто без дополнений она таковой не является. Тоже самое, что считать линукс win api-совместимым, качая при этом вайн. Глупо же.
Эм. Posix сам по себе модульный, и состоит из кучи стандартов: posix.1 (minimal), posix 1001.a (или как-то так), posix rt (реальное время).
«Из-коробки» windows совместим с minimal posix (posix.1), для остального нужно качать дополнения. Имхо это нормально — вас же не смущает, что linux, например, не реализует posix rt?
«Из-коробки» windows совместим с minimal posix (posix.1), для остального нужно качать дополнения. Имхо это нормально — вас же не смущает, что linux, например, не реализует posix rt?
Вообще-то уже давно были патчи по подрежке posix 1003.1b.
Сторонняя фирма Wind River также выпускает системы жесткого реального времени на базе WinNT, соответствующие в том числе posix rt. Что это доказывает? Так же, как и наличие патчей — то, что это дело наживное, при желании выпуск platform adaptation layer закроет эту нишу для win.
Наличие или отсутствие патчей или компонент — это вопрос скорее маркетинга, чем технический (для WinNT это так). А раз так, то приоритет этого вопроса тоже определяется маркетингом, который черпает свои знания из реальных требований и нужд потребителей. На практике же оказывается, что нужды и требования таковы, что custom WinAPI + MSDN по удобству многократно заруливает posix. А большего и не надо — full posix ради full posix нужен только гикам; в реальности подавляющее большинство posix-совместимого ПО без проблем портируется в win
Наличие или отсутствие патчей или компонент — это вопрос скорее маркетинга, чем технический (для WinNT это так). А раз так, то приоритет этого вопроса тоже определяется маркетингом, который черпает свои знания из реальных требований и нужд потребителей. На практике же оказывается, что нужды и требования таковы, что custom WinAPI + MSDN по удобству многократно заруливает posix. А большего и не надо — full posix ради full posix нужен только гикам; в реальности подавляющее большинство posix-совместимого ПО без проблем портируется в win
> Наличие или отсутствие патчей или компонент — это вопрос скорее маркетинга, чем технический
Вот поэтому их и нужно давить всеми средствами. Чтобы превратить ситуацию в такую, когда «из соображений маркетинга» нужно делать систему максимально совместимой.
> в реальности подавляющее большинство posix-совместимого ПО без проблем портируется в win
Вот это утверждение является неправдой.
Вот поэтому их и нужно давить всеми средствами. Чтобы превратить ситуацию в такую, когда «из соображений маркетинга» нужно делать систему максимально совместимой.
> в реальности подавляющее большинство posix-совместимого ПО без проблем портируется в win
Вот это утверждение является неправдой.
Кого «их»? Очнитесь, как вы давить собрались — пиздобольствуя в топиках Хабра, извините за прямоту? Ну-ну, продолжайте.
А вообще, надавите лучше на linux, чтобы в ядро включили планировщик или там что еще.
Или давайте лучше в linux сделаем полностью совместимый win32 api — без wine, прямо в ядре, чтобы виндовые программы гонять. А что? Вам не нравится, что есть cygwin (linux-layer для винды), но устраивает, что есть wine (win-layer для linux).
Как-то однобоко получается.
>>Вот это утверждение является неправдой.
apache, mysql, postgress, php, perl, TeX, emacs, gcc… список можно продолжать бесконечно. Портируются, api вполне хватает.
А вообще, надавите лучше на linux, чтобы в ядро включили планировщик или там что еще.
Или давайте лучше в linux сделаем полностью совместимый win32 api — без wine, прямо в ядре, чтобы виндовые программы гонять. А что? Вам не нравится, что есть cygwin (linux-layer для винды), но устраивает, что есть wine (win-layer для linux).
Как-то однобоко получается.
>>Вот это утверждение является неправдой.
apache, mysql, postgress, php, perl, TeX, emacs, gcc… список можно продолжать бесконечно. Портируются, api вполне хватает.
> пиздобольствуя в топиках Хабра
А вот нервничать и грубить не надо.
> apache, mysql, postgress
Как я понимаю, Вы не совсем в курсе трудностей портирования.
А вот нервничать и грубить не надо.
> apache, mysql, postgress
Как я понимаю, Вы не совсем в курсе трудностей портирования.
Да вроде не нервничал, сказал, как вижу. «Давить надо» звучало бы обоснованно, если бы вы обладали ресурсами, чтобы это сделать. В противном случае это просто неподкрепленные ничем слова, вот и все ;)
Маленькой долей ресурсов я обладаю. Все сообщество разработчиков — большой долей ресурсов. А давить нужно потому, что если не давить, монополии будут всячески проталкивать закрытые стандарты.
От этого все проиграют.
От этого все проиграют.
Та ну. Сколько ни вижу примеров, 50/50, где-то проигрывают, где-то выигрывают. Я бы не сказал, что открытые стандарты — это выгоднее, открытые — просто другая модель
Я имел в свое большие трудности/неприятности с закрытыми стандартами/продуктами. Поэтому совершенно сознательно считаю, что:
— Стандарты для общего применения ОБЯЗАТЕЛЬНО должны быть открытыми
— Программные продукты могут быть закрытыми только в небольшом количестве малоответственных случаев.
— Стандарты для общего применения ОБЯЗАТЕЛЬНО должны быть открытыми
— Программные продукты могут быть закрытыми только в небольшом количестве малоответственных случаев.
Тут большая сложность с тем, что считать «общим применением».
Давайте вспомним, как начинались те технологии общего применения, на которые счас особенный hype (например, для web и около с ним):
— javascript — закрытая технология Netscape
— flash — закрытая технология macromedia (ныне Adobe)
— ajax (объект XmlHttpRequest) — закрытая технология MS (IE)
— java — закрытая технология Sun
— ах да, забыл, posix — это закрытая технология, постфактум объявленные системные интерфейсы nix-ядра.
— Можно продолжать и продолжать…
Потом они были открыты, да, но главной движущей силой были именно сами их авторы. Как только технология попадает в open source — все надежды и предсказания по фичам, capability, срокам исчезают.
Спеки на posix открыты — где поражающее многообразие posix-ядер? Гребаный стыд, два основных unix-а разрабатываются Apple (MacOS=Mach/BSD) и Sun (Solaris и OpenSolaris)
Возьмем, например, .NET — полностью открытые спеки, бери и делай. Нет, под предлогом «МС все у нас отберет» мы вообще не будем ничего делать, а то, что уже делают (mono) даже в дистрибутивы не включим.
Так что тут с присоединением MS к SVG появляется надежда, что он все-таки скоро выйдет.
Давайте вспомним, как начинались те технологии общего применения, на которые счас особенный hype (например, для web и около с ним):
— javascript — закрытая технология Netscape
— flash — закрытая технология macromedia (ныне Adobe)
— ajax (объект XmlHttpRequest) — закрытая технология MS (IE)
— java — закрытая технология Sun
— ах да, забыл, posix — это закрытая технология, постфактум объявленные системные интерфейсы nix-ядра.
— Можно продолжать и продолжать…
Потом они были открыты, да, но главной движущей силой были именно сами их авторы. Как только технология попадает в open source — все надежды и предсказания по фичам, capability, срокам исчезают.
Спеки на posix открыты — где поражающее многообразие posix-ядер? Гребаный стыд, два основных unix-а разрабатываются Apple (MacOS=Mach/BSD) и Sun (Solaris и OpenSolaris)
Возьмем, например, .NET — полностью открытые спеки, бери и делай. Нет, под предлогом «МС все у нас отберет» мы вообще не будем ничего делать, а то, что уже делают (mono) даже в дистрибутивы не включим.
Так что тут с присоединением MS к SVG появляется надежда, что он все-таки скоро выйдет.
> Или давайте лучше в linux сделаем полностью совместимый win32 api — без wine, прямо в ядре, чтобы виндовые программы гонять. А что? Вам не нравится, что есть cygwin (linux-layer для винды), но устраивает, что есть wine (win-layer для linux).
Как-то однобоко получается.
Почему мне не нравится cygwin? Нет у меня с cygwin-ом проблем. Пусть будет. Win32 в ядре не нужно. В качестве дополнительного слоя, как Wine, нет проблем.
Как-то однобоко получается.
Почему мне не нравится cygwin? Нет у меня с cygwin-ом проблем. Пусть будет. Win32 в ядре не нужно. В качестве дополнительного слоя, как Wine, нет проблем.
Ну так posix services тоже как дополнительный слой уже присутствует. Зачем что-то еще, если всех устраивает?
Мне — для того, чтобы написанные мною продукты как можно легче портировались на как можно большее количество систем. Для этого желательно иметь везде какой-то стандарт. Поскольку для меня предпочтительная платформа Линукс/ЮНИКС, то я заинтересован, чтобы в Виндовс был бы пригодный к использованию POSIX.
Забыл добавить — по умолчанию был бы пригодный к использованию POSIX.
Не катит :)
Почему-то пользу хотите получать лично вы, а «давить» кричите в сторону инженеров из win. Напишите full-compatible posix adaptation layer для windows — и вам спасибо скажут, и получите то, что хотите.
Не осиливаете? Ну, извините, либо пользуйтесь тем, что есть (большая часть posix работает и так), либо обоснуйте, какая от этого будет польза, и найдите тех, кто согласен это сделать. Все остальное — из разряда хотелок: WSU — это нормальный серверный posix.
Linux-а на десктопе меньше 5% — нет смысла затачиваться под него, чтобы угодить единицам, когда большинство довольно и так
Почему-то пользу хотите получать лично вы, а «давить» кричите в сторону инженеров из win. Напишите full-compatible posix adaptation layer для windows — и вам спасибо скажут, и получите то, что хотите.
Не осиливаете? Ну, извините, либо пользуйтесь тем, что есть (большая часть posix работает и так), либо обоснуйте, какая от этого будет польза, и найдите тех, кто согласен это сделать. Все остальное — из разряда хотелок: WSU — это нормальный серверный posix.
Linux-а на десктопе меньше 5% — нет смысла затачиваться под него, чтобы угодить единицам, когда большинство довольно и так
Я не кричу, а просто высказываю свое мнение. А мнение мое примерно такое:
— Майкрософт это компания монополист, которая долгое время делала ставку на закрытые стандарты (сам имел с этим большие трудности)
— Написать такой удовлетворяющий необходимому требованию адаптер я не могу — видимо нет соответствующих вызовов в API, сам не пробовал, сужу по опыту CYGWIN
— Обертку написать можно, она будет медленной. А скорость — это одна из основных черт форка-а и есть.
— Я именно и употребил термин «давить» потому, что добровольно Майкрософт, в силу того, что это монополия и того, как она видит свои преимущества, не будет поворачииваться в сторону открытых стандартов
— На сегодня «давить» можно (и нужно) именно через повышения доли Линукса и именно на десктопе.
— Майкрософт это компания монополист, которая долгое время делала ставку на закрытые стандарты (сам имел с этим большие трудности)
— Написать такой удовлетворяющий необходимому требованию адаптер я не могу — видимо нет соответствующих вызовов в API, сам не пробовал, сужу по опыту CYGWIN
— Обертку написать можно, она будет медленной. А скорость — это одна из основных черт форка-а и есть.
— Я именно и употребил термин «давить» потому, что добровольно Майкрософт, в силу того, что это монополия и того, как она видит свои преимущества, не будет поворачииваться в сторону открытых стандартов
— На сегодня «давить» можно (и нужно) именно через повышения доли Линукса и именно на десктопе.
> А скорость — это одна из основных черт форка-а и есть.
Создание потока примерно в 10 раз «легче» создания форка. Если же учесть последующий exec, то виндовый CreateProcess как бы не легче такой парочки оказался.
Создание потока примерно в 10 раз «легче» создания форка. Если же учесть последующий exec, то виндовый CreateProcess как бы не легче такой парочки оказался.
Тьфу, не «создания форка», а просто «форка»
Примерно так:
--Linux 2-thread context switches are > 6 times faster than NT (and
twice as fast as QNX)
Since 2.0.0, Linux process switch times have been about 10-15% slower
than thread switch times pretty consistently, so that'd be about 5
times faster than NT thread switches. It's worth noting that Albert's
measurements were on Linux 2.1.7, which was after the switch from
hardware to software context switching and before Ingo's improvements
brought the software switches up to the speed of the hardware switches;
that difference might be enough to account for the difference between
my results and Albert's, but that's just a random thought that oughtn't
be taken too seriously.
--Linux 2-thread context switches are > 6 times faster than NT (and
twice as fast as QNX)
Since 2.0.0, Linux process switch times have been about 10-15% slower
than thread switch times pretty consistently, so that'd be about 5
times faster than NT thread switches. It's worth noting that Albert's
measurements were on Linux 2.1.7, which was after the switch from
hardware to software context switching and before Ingo's improvements
brought the software switches up to the speed of the hardware switches;
that difference might be enough to account for the difference between
my results and Albert's, but that's just a random thought that oughtn't
be taken too seriously.
Во первых, при чем здесь «context switches»? Я говорю о создании. Во вторых не верю — мне бы чего нибудь посолиднее, чем мнение линукс евангелиста на какой то никому неизвестной дискуссионной борде. Хотя бы потому, что единственное отличие со стороны скедьюлера будет в том нужно перегружать адресное пространство (cr3 x86) или нет. При перезагрузке cr3 сбрасываются все TLB, что приводит к необходимости перезаполнять их каждый раз. То есть к совершенно не имеющему отношения собственно переключению контекстов добавляется гигантский оверхед на необходимость лезть каждый раз в память.
Закрытые стандарты — это способ добиться своих целей, не более. Никакого профита для МС использовать открытые стандарты нет, разве что они более совершенны с технической точки зрения.
Далее, usecase, в котором скорость программы зависит от скорости fork настолько редок и специален, что там и так отказываются от fork в пользу fibers/threads.
Наконец, чтобы повысить долю linux на десктопе, нужно, чтобы linux предоставлял больше преимуществ, чем в случае с windows заплатить 200$ и получить отличную систему, драйвера под практически любое железо, ее круглосуточную поддержу и кучу работающего софта.
Далее, usecase, в котором скорость программы зависит от скорости fork настолько редок и специален, что там и так отказываются от fork в пользу fibers/threads.
Наконец, чтобы повысить долю linux на десктопе, нужно, чтобы linux предоставлял больше преимуществ, чем в случае с windows заплатить 200$ и получить отличную систему, драйвера под практически любое железо, ее круглосуточную поддержу и кучу работающего софта.
Далее, usecase, в котором скорость программы зависит от скорости fork настолько редок и специален
Кстати, оппонент не может привести такого примера — может хоть Вы мне приведете пример, когда использование fork может быть оправдано (я правда не знаю)
Кстати, оппонент не может привести такого примера — может хоть Вы мне приведете пример, когда использование fork может быть оправдано (я правда не знаю)
Ну, как же, ранние версии CGI и аналогичной архитектуры приложения использовали fork, порождая процесс на каждый запрос. потом, правда, даже при всей «скорострельности» fork, о которой говорит мой оппонент, от этой модели отказались в пользу FCGI, где все преимущественно висит в одном процессе, а обработка — в тредах. Последняя сейчас считается наиболее прогрессивной — тот же пистон ее реализует в своем WSGI
Форк имеет смысл использовать, если вы исполняете недоверенный код. Вероятно, у eugenyk-а именно такая ситуация в его сервере. Но безопасность всегда была недешевой вещью.
В других случаях вам нет смысла защищаться от своего же кода — если он ломится в не свою память, это ошибка разработчика, а не recoverable сбой в рантайме. Так что ценность «быстрого» fork в том случае, когда есть threads, конкретно преувеличена
В других случаях вам нет смысла защищаться от своего же кода — если он ломится в не свою память, это ошибка разработчика, а не recoverable сбой в рантайме. Так что ценность «быстрого» fork в том случае, когда есть threads, конкретно преувеличена
Хм, пожалуй Вы правы. Хотя, чтобы исполнять недоверенный код и предоставлять ему содержимое собственной памяти нужно быть достаточно осторожным, но таки да здесь fork будет быстрее. С друой стороны для нагруженных серверов он все равно недостаточно быст и тот же apache создает пул процессов до начала обработки запросов. В данном случае не так существенно будет ли холодный старт занимать 100 миллисекунд или 1000.
Не только. Если вы используете в сервере форк, повышается надежность приложения. За счет того, что в случае ошибки у вас падает не все приложение, а только процесс с ошибкой.
Часто говорят, что вот, можно протестировать код и отловить все ошибки. Часто это трудновыполнимо, поскольку в многозадачных приложениях количество состояний очень велико, а время на разработку/тестирование всегда ограничено.
Не зря же большинство реально работающих серверов в посикс системах использует сервис на форках. Когда нужно повысить производительность, префодят к системе с префорком. И только тогда, когда нужна очень высокая производительность переходят к конечным автоматам.
Часто говорят, что вот, можно протестировать код и отловить все ошибки. Часто это трудновыполнимо, поскольку в многозадачных приложениях количество состояний очень велико, а время на разработку/тестирование всегда ограничено.
Не зря же большинство реально работающих серверов в посикс системах использует сервис на форках. Когда нужно повысить производительность, префодят к системе с префорком. И только тогда, когда нужна очень высокая производительность переходят к конечным автоматам.
Надежность приложения повышается прежде всего за счет статического анализа кода и хорошего дизайна, приводящего к тестируемости кода, что в свою очередь приводит к высокому покрытию.
Ну так сервер на форках, это и есть хороший дизайн. Вот к примеру терминатор в мире HTTP серверов, Apache 1.3/Apache2-mpm-prefork.
Тут все просто — он был сделан, когда pthreads еще не были распространены.Вся идеология fork идет от того, что в unix не было потоков в том понимании, что считаем мы.
Далее, apache — это как раз пример приложения, исполняющего недоверенный (с точки зрения разработчиков Apache) код. Если вы пишете свой кастомный хэндлер запросов, ясный пень, что это весь ваш код и защищаться там особо не от кого.
Ну и потом — posix тоже эволюционирует, это же _практический_ стандарт. Я уверен, через 3-5 лет fork объявят obsolete как средство, не соответствующее задаче. По крайней мере, новые приложения, юзающие fork а не vfork, крайне редки уже и сейчас.
Далее, apache — это как раз пример приложения, исполняющего недоверенный (с точки зрения разработчиков Apache) код. Если вы пишете свой кастомный хэндлер запросов, ясный пень, что это весь ваш код и защищаться там особо не от кого.
Ну и потом — posix тоже эволюционирует, это же _практический_ стандарт. Я уверен, через 3-5 лет fork объявят obsolete как средство, не соответствующее задаче. По крайней мере, новые приложения, юзающие fork а не vfork, крайне редки уже и сейчас.
1) Вообще-то Apache на сегодня имеет две ветки, одна на тредах, одна на префорках. На Win32 ясно, там нужно использовать на тредах, на UNIX-ах как правило используют на форках.
2) С моей точки зрения, любой код, включая свой — недопроверенных. Кроме этого, существует еще и безопасность. Виндовс-пипл, правда славятся легкомысленным отношением к безопасности. Но вот например IE8 сделан на процессах. Судя по всему именно из соображений безопасности.
3) Уверенность, это хорошо, однако посмотрим. Только насчет замены fork-a vfork-ом в посикс, как-то я сомневаюсь. В моих книжках прямо написано, что vfork небезопасен и пользоваться им не рекомендуется.
2) С моей точки зрения, любой код, включая свой — недопроверенных. Кроме этого, существует еще и безопасность. Виндовс-пипл, правда славятся легкомысленным отношением к безопасности. Но вот например IE8 сделан на процессах. Судя по всему именно из соображений безопасности.
3) Уверенность, это хорошо, однако посмотрим. Только насчет замены fork-a vfork-ом в посикс, как-то я сомневаюсь. В моих книжках прямо написано, что vfork небезопасен и пользоваться им не рекомендуется.
>>Виндовс-пипл, правда славятся легкомысленным отношением к безопасности.
Не надо разжигать :) Будем поглядеть, когда никсы распространятся до соответствующих масштабов.
>>С моей точки зрения, любой код, включая свой — недопроверенных
Странно, а вот апач на тредах делают, и ничего. Имхо вы пытаетесь хайдить ошибку вместо того, чтобы ее пофиксить. Я согласен, что так надежнее, но считаю, что в болшинстве случаев такая модель избыточна. Хотя, если учесть, как течет по памяти php, например, это будет обоснованно — но это еще один пример «сделаем гуано, а потом будем пытаться от него защититься»
>>например IE8 сделан на процессах
Вы как будто игнорируете то, что я написал. IE8 исполняет много недоверенного _не своего_ кода — всяческие плагины, flash, video, аддоны, BHO и прочее. Ясное дело, лучше его защитить аппаратно — я же выше примерно это и написал.
Не надо разжигать :) Будем поглядеть, когда никсы распространятся до соответствующих масштабов.
>>С моей точки зрения, любой код, включая свой — недопроверенных
Странно, а вот апач на тредах делают, и ничего. Имхо вы пытаетесь хайдить ошибку вместо того, чтобы ее пофиксить. Я согласен, что так надежнее, но считаю, что в болшинстве случаев такая модель избыточна. Хотя, если учесть, как течет по памяти php, например, это будет обоснованно — но это еще один пример «сделаем гуано, а потом будем пытаться от него защититься»
>>например IE8 сделан на процессах
Вы как будто игнорируете то, что я написал. IE8 исполняет много недоверенного _не своего_ кода — всяческие плагины, flash, video, аддоны, BHO и прочее. Ясное дело, лучше его защитить аппаратно — я же выше примерно это и написал.
> Вы как будто игнорируете то, что я написал. IE8 исполняет много недоверенного _не своего_ кода — всяческие плагины, flash, video, аддоны, BHO и прочее.
Я не игнорирую, просто свой/не свой код понятие размытое. Вот исполняете свой код, вдруг бах, ошибка, например переполнение буфера, и уже исполняется не Ваш код. И глядь, если программа на тредах, чужой код уже читает дамп памяти ДРУГИХ КЛИЕНТОВ сервера, а там может быть мнооого интересного, включая например пароли.
Я не игнорирую, просто свой/не свой код понятие размытое. Вот исполняете свой код, вдруг бах, ошибка, например переполнение буфера, и уже исполняется не Ваш код. И глядь, если программа на тредах, чужой код уже читает дамп памяти ДРУГИХ КЛИЕНТОВ сервера, а там может быть мнооого интересного, включая например пароли.
Кроме переполнения буфера, есть еще тысячи способов читать чужой процесс — dbg, инъекция динамических библиотек в процесс, еще кучи. Я в таких случаях предпочитаю использовать языки, в которых рантайм следит за отсутствием переполнения буфера, и есть надежные средства сокрытия паролей, типа SecureString, который шифрует данные в памяти. А так имхо мы лечим кашель сильным средством от запора — цель достигнута, пациент не кашляет (в основном, потому что боится покашлять)
И — да — судя по комментарию выше «posix api гораздо удобнее в использовании, чем win api.» напрягает вас совершенно не то, что там люди считают.
Внимательно присмотритесь к списку www.itl.nist.gov/div897/ctg/posix/finalreg4.htm
Ну к чему пустой треп? Никогда Microsoft не откроет коды и не перейдет на posix api и не уберет >3000 команд, потому что все это не нужно и даже более того — вредно для Microsoft.
А поддержка SVG радует, конечно, почему нет.
А поддержка SVG радует, конечно, почему нет.
posix не posix, но блин навести порядок в API давно уже пора, там же просто дикая куча функций, способов достичь одного и того же. Порезать бы там все устаревшие функции, а старый софт пускать в режиме эмуляции целиком и полностью.
posix же хотя бы компактнее
posix же хотя бы компактнее
В win7 сделаны первые шаги к этому — modular kernel api, посмотрите презентацию с PDC nov 2009 от Марка Руссиновича. Теперь kernel32, например — это эмулятор для старых программ, который вызывает новые функции ядра из API-библиотек, рафинированных и разделенных.
До полного счастья конечно далеко, но начало положено.
До полного счастья конечно далеко, но начало положено.
Как в сфере браузеров их притеснили, так и заинтересовались (svg обычный и анимированный — неплохое решение для иллюстраций на сайтах, и уже сейчас поддерживается как минимум оперой), начать их (Microsoft) поджаривать с другого бока — еще чем-нибудь заинтересуются.
Неужели наконец лед сдвинулся? SVG — потрясная технология и пока только IE ее сдерживает.
Ну и славненько, ждем реальных результатов в IE9
Да только вот пока он выйдет, пока распространится. Он IE6 до сих пор держит большую долю.
Да и не ясно в каком объёме будет поддержка, да из Сильверлайтом некоторые пересечения есть.
Думаю радоваться рано, пока это заявления о намерениях не поддкреплённые реальнимы достижениями. Выбраное направление радует, но подождём годик на результаты.
Да и не ясно в каком объёме будет поддержка, да из Сильверлайтом некоторые пересечения есть.
Думаю радоваться рано, пока это заявления о намерениях не поддкреплённые реальнимы достижениями. Выбраное направление радует, но подождём годик на результаты.
Ну наконец-то!
Лучше б мозги напрягли, и волшебным образом превратили 6 и 7 хотя бы в 8.
«Вчера мы отправили запрос на присоединение к рабочей группе...»
W3C, гони их в шею, а запрос пусть присылают, когда ie6 сдохнет :)
W3C, гони их в шею, а запрос пусть присылают, когда ie6 сдохнет :)
чуж закончится тем, что svg частично станет форматом мелкософта, с закрытыми плюшками, работающими только в ИЕ какой то особой версии… они же любители делать свои стандарты =)
Топик чисто, чтобы поглумиться над MS, пока других радостей мало)
SVG+JS может теоретически заменить flash?
SVG+JS может теоретически заменить flash?
Что-то как-то оно не совсем одинаково выглядит пока :)
Chrome 4.0.266.0
Shiretoko 3.5.8pre
Opera 10.10.4742
Будем ждать… =)
Chrome 4.0.266.0
Shiretoko 3.5.8pre
Opera 10.10.4742
Будем ждать… =)
Я на uzbl проверял.
Chrome 4.0.249.43, работает отлично (:
Кстати, можно не только SVG. JS с чем угодно работает, хоть сам с собой. см. www.chromeexperiments.com/
Кстати, можно не только SVG. JS с чем угодно работает, хоть сам с собой. см. www.chromeexperiments.com/
Размер и положение фоток каждый раз заново генерируется ;)
Из него картинки можно средствами браузера достать :) В отличие от flash.
В вебките работает, в опере — нет.
В вебките работает, в опере — нет.
Красивый пример)
Canvas заменит Flash, SVG — для других целуй
webo.in/articles/all/2009/23-using-canvas/
webo.in/articles/wsd2009/vml-svg-canvas/
webo.in/articles/wsd2009/vrml-vml-svg-canvas/
webo.in/articles/all/2009/23-using-canvas/
webo.in/articles/wsd2009/vml-svg-canvas/
webo.in/articles/wsd2009/vrml-vml-svg-canvas/
… а Silverlight? Неужели ms будет копать под себя?
Это конечно все классно,
вот бы они (разработчики браузеров) собрались и сделали так чтобы
все работало по одному стандарту без всяких хаков и фишек под конкретный браузер,
было бы вообще отлично.
вот бы они (разработчики браузеров) собрались и сделали так чтобы
все работало по одному стандарту без всяких хаков и фишек под конкретный браузер,
было бы вообще отлично.
НЛО прилетело и опубликовало эту надпись здесь
Не будет этого. Всегда будут разногласия. Это же конкуренция. Тут кто первый встал того и тапки. В конце концов это сводится к позициям на рынке браузеров, и поверьте уж — w3c тоже не святые.
да пусть даже не w3c.
Пусть даже новый стандарт разработают,
только бы сделали все единым стандартом.
Движки разные, браузеры разные, а работают одинаково.
Вот какой утопии хочется. А то «по долгу службы» приходится сталкиваться с версткой иногда,
сделаешь в одном браузере, а в остальных начинаются свистопляски (
Пусть даже новый стандарт разработают,
только бы сделали все единым стандартом.
Движки разные, браузеры разные, а работают одинаково.
Вот какой утопии хочется. А то «по долгу службы» приходится сталкиваться с версткой иногда,
сделаешь в одном браузере, а в остальных начинаются свистопляски (
Так было такое, во времена абсолютной гегемонии ИЕ5-6 был один стандарт де-факто. Но появились борцы за справедливость и теперь мы имеем тот зоопарк, который имеем :)
Для заинтересованных: в IE благодаря наличию VML (начиная с IE5) можно эмулировать практически весь SVG (не включая модуль фильтров)
Смотреть в IE:
www.amplesdk.com/examples/svg/tiger/
www.amplesdk.com/examples/svg/worldmap_interactive/
Смотреть в IE:
www.amplesdk.com/examples/svg/tiger/
www.amplesdk.com/examples/svg/worldmap_interactive/
Неужели! О, сколько времени было убито на создание совместимой с эксплорером графики.
Нормально. Microsoft уверенно взяла курс на HTML5 и сопутствующие технологии. Осталось дождаться результатов
«Как видно из нашего постоянного участия в рабочих группах W3C»
а по вот этой теме есть «пруфлинки»?
а по вот этой теме есть «пруфлинки»?
Прошу прощения, забыл при переводе вставить данную ссылку, которая присутствовала в оригинале, на фразе «As evidenced by our ongoing involvement in W3C working groups»
Ну, первое, что приходит в голову MS практически с самого начала в CSS working group
IE прижали к стене.
Так им и надо.
Так им и надо.
Я не понимаю, все топики, так или иначе связанные с Microsoft вызывают такую бурю негодования у линуксоидов?=) Причём я уверен, что процентов как минимум 30 сидят под виндой.=)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft присоединяется к рабочей группе SVG