[unix] почему "линукс популярнее"?
Глеб, не надо постить статью core-member о самой ФриБСД, это все равно не справедливо 
кто-нить из гигантов двигает фрю?
линсакс то да.
линсакс то да.
Кстати, действительно интересно, почему всякие могучие дядьки типа Novell и IBM заявляют, что намерены всячески поддерживать Linux, а о FreeBSD ни слова? Вероятно, из-за популярности Линуха? Маркетинговые игры?
незнаю как новелл, а айбиэмеры не только заявляют
постепенно все интересные фишки из аикса переносяцца в линукс.
постепенно все интересные фишки из аикса переносяцца в линукс.
1) Лицензия GNU - получше, чем фрёвая. С ней больше уверенности в том, что система останется бесплатной.
2) У них есть свои разработки. Платные. И, судя по всему, переводить своих клиентов на них с линукса им проще, чем с фри.
2) У них есть свои разработки. Платные. И, судя по всему, переводить своих клиентов на них с линукса им проще, чем с фри.
2) дык наоборот с комерческих на линукс
Неее.
1) Продвигается Линукс _вместо_ винды. Ибо дешевле и не хуже.
2) С Линукса юзвер переводится на платный юникс. Ибо надёжнее. И быстрее.
1) Продвигается Линукс _вместо_ винды. Ибо дешевле и не хуже.
2) С Линукса юзвер переводится на платный юникс. Ибо надёжнее. И быстрее.
Тогда сразу вопрос: "вместо винды, ибо дешевле и не хуже". Тогда получается, что FreeBSD либо дешевле, либо хуже, либо и то и другое?
2) С Линукса юзвер переводится на платный юникс. Ибо надёжнее. И быстрее.
клево
лизенция Фри не нравилась все "гиганты".Тогда сразу вопрос: "вместо винды, ибо дешевле и не хуже". Тогда получается, что FreeBSD либо дешевле, либо хуже, либо и то и другое?
Я ж написал - проблемы возникают скорее не в первой части, а во второй. Т.е. при пересаживании с бесплатной бсди на платный вариант юникса. Бздя вроде надёжней считается...
1) Лицензия GNU - получше, чем фрёвая. С ней больше уверенности в том, что система останется бесплатной.
? Где в BSD закладки того, что система станет платной? Извини, ты чушь сморозил.
Тут скорее другая фигня. Гиганты боятся делать что либо под лицензией BSD потому, что тогда конкурент может пользоваться их наработками не нарушая закон.
А всякие строители релизов не плодятся как грибы просто потому, что это обречено на провал - никому не удастся сделать релиз лучше базового. Может быть если бы Линус в своё время понимал, что ОС != ядро, то был бы и линукс единый. И был бы он более удобным, чем то что имеем сейчас.
1) Лицензия GNU - получше, чем фрёвая. С ней больше уверенности в том, что система останется бесплатной.
хм ... какие же пункты во фревой лецензии вызывают такие подозрения?
Она не пытается соревноваться с вендой. Тем более OpenBSD и NetBSD.
Вообще разговор пошел не совсем туда куда я хотел. В статье акцент делался на то, что зачастую feature перестает поддерживаться только после того, как она перестала быть нужно последнему из разработчиков. Что эта беда касается всех open source проектов, причем Linux этому сопротивляется, а FreeBSD нет,
> Может быть если бы Линус в своё время понимал, что ОС != ядро, то был бы и линукс единый.
Что бы он должен был сделать, если бы понимал?
И сразу следующий вопрос: а зачем бы ему нужно было бы это делать (иначе говоря, кому должен)?
Что бы он должен был сделать, если бы понимал?
И сразу следующий вопрос: а зачем бы ему нужно было бы это делать (иначе говоря, кому должен)?
> Вообще разговор пошел не совсем туда куда я хотел.
Неудивительно. Я например только заголовок прочитал, судя по нему, это реклама.
> В статье акцент делался на то, что зачастую feature перестает поддерживаться только после того, как она перестала быть
> нужно последнему из разработчиков.
Ты говоришь, что это беда? А как должно быть, я не понял?
Неудивительно. Я например только заголовок прочитал, судя по нему, это реклама.
> В статье акцент делался на то, что зачастую feature перестает поддерживаться только после того, как она перестала быть
> нужно последнему из разработчиков.
Ты говоришь, что это беда? А как должно быть, я не понял?
Что бы он должен был сделать, если бы понимал?Создать нужные каталоги в репозитории и заимпортить туда софт, который у него заработал под linux. bash там всякий, gcc или чего он там еще запускал в самом начале.
Пригласить разработчиков.
И сразу следующий вопрос: а зачем бы ему нужно было бы это делать (иначе говоря, кому должен)?Володя, ты любишь вопросы заводить в тупик. Конечно, блин он никому не должен. И ядро он тоже никому не должен. Может быть если бы он не взялся за Linux, а стал бы просто всю жизнь бездельничать и ганджа курить, то прожил бы жизнь веселее.
Это как наш недавний разговор про OSPF. Никому мы блин это не должны, и никто не скажет спасибо. Но сетка станет надежней и это просто интересно.
Может быть если бы Линус в своё время понимал, что ОС != ядро, то был бы и линукс единый. И был бы он более удобным, чем то что имеем сейчас.
В своей книге "Just for fun" он ясно даёт понять, что он не пытался написать систему для всеобщего пользования, он написал её для себя (это потом она получила широкое распространение). Он пишет, что был рад избавиться от пользовательских программ и заниматься только тем, что ему интересно, т.е. ядром. Поэтому в силу своего характера он не мог (да и не хотел) заниматься линуксом как дистрибутивом. Ядром он занимался и сейчас занимается, и его версия ядра считается лучшей, т.к. ему в этом доверяют.
Наверное, это был оффтопик, но тем не менее
Фича должна поддерживаться до тех пор, пока она нужна хотя бы 5 юзерам. Иначе система теряет конкурентоспособность, какие бы классные фичи там бы ни были. Нельзя наличию directx противопоставлять softupdates.
> Создать нужные каталоги в репозитории и заимпортить туда софт, который у него заработал под linux. bash там всякий, gcc
> или чего он там еще запускал в самом начале.
А ты уверен, что было не так?
> Пригласить разработчиков.
Куда пригласить?
> Это как наш недавний разговор про OSPF. Никому мы блин это не должны, и никто не скажет спасибо. Но сетка станет
> надежней и это просто интересно.
Вот и делают то, что интересно.
А проблемы тех, кто хочет как BSD, только лучше, Линуса я думаю (*) просто не ебут.
* вывод сделан на основании регулярного чтения linux-kernel
> или чего он там еще запускал в самом начале.
А ты уверен, что было не так?
> Пригласить разработчиков.
Куда пригласить?
> Это как наш недавний разговор про OSPF. Никому мы блин это не должны, и никто не скажет спасибо. Но сетка станет
> надежней и это просто интересно.
Вот и делают то, что интересно.
А проблемы тех, кто хочет как BSD, только лучше, Линуса я думаю (*) просто не ебут.
* вывод сделан на основании регулярного чтения linux-kernel
Это как раз был самый топик. О том что в open source делается то, что интересно разработчикам,
А проблемы тех, кто хочет как BSD, только лучше, Линуса я думаю (*) просто не ебут.
* вывод сделан на основании регулярного чтения linux-kernel
А более понятно можно выразиться?
> Фича должна поддерживаться до тех пор, пока она нужна хотя бы 5 юзерам.
Теперь пойди к тем, от кого ты хочешь этой поддержки, и объясни им, что они тебе должны.
Например, заплатив за поддержку.
Насколько я знаю, Red Hat например поддерживает все фичи, которые нужны их клиентам, которые платят.
> Иначе система теряет конкурентоспособность
Линуса это не ебёт.
Есть компании, которые этим занимаются, относительно успешно, хотя с MS не сравнить, конечно.
Теперь пойди к тем, от кого ты хочешь этой поддержки, и объясни им, что они тебе должны.
Например, заплатив за поддержку.
Насколько я знаю, Red Hat например поддерживает все фичи, которые нужны их клиентам, которые платят.
> Иначе система теряет конкурентоспособность
Линуса это не ебёт.
Есть компании, которые этим занимаются, относительно успешно, хотя с MS не сравнить, конечно.
Вот мы и пришли к единому мнению.
Проблема open source в бесплатности. Что очень тяжело сделать open source платным.
Проблема open source в бесплатности. Что очень тяжело сделать open source платным.
Тебе нравится подход *BSD, ты ведь описываешь его и говоришь, что Линус должен был сделать так же?
А зачем ему это было бы нужно?
А зачем тебе это было бы нужно? Ведь *BSD и так есть. Я предположил, что ты хочешь что-то вроде, только лучше, и ответил, что Линусу положить на это твоё желание.
А зачем ему это было бы нужно?
А зачем тебе это было бы нужно? Ведь *BSD и так есть. Я предположил, что ты хочешь что-то вроде, только лучше, и ответил, что Линусу положить на это твоё желание.
> Вот мы и пришли к единому мнению.
Где?
> Проблема open source в бесплатности.
Какая ещё проблема?
> Что очень тяжело сделать open source платным.
Да вроде не тяжелее, чем closed source.
Большой успех в продажах универсальный ОС только у Microsoft, остальным тяжело.
Где?
> Проблема open source в бесплатности.
Какая ещё проблема?
> Что очень тяжело сделать open source платным.
Да вроде не тяжелее, чем closed source.
Большой успех в продажах универсальный ОС только у Microsoft, остальным тяжело.
Где?
Здесь:
Я хотел сказать так: очень тяжело сделать платное open sourceным. Потому что если есть действительно классные наработки, то их стырят и что бы доказать это придется несколько лет провести в судах.
Здесь:
> Фича должна поддерживаться до тех пор, пока она нужна хотя бы 5 юзерам.
Теперь пойди к тем, от кого ты хочешь этой поддержки, и объясни им, что они тебе должны.
Например, заплатив за поддержку.
Насколько я знаю, Red Hat например поддерживает все фичи, которые нужны их клиентам, которые платят.
> Что очень тяжело сделать open source платным.
Да вроде не тяжелее, чем closed source.
Я хотел сказать так: очень тяжело сделать платное open sourceным. Потому что если есть действительно классные наработки, то их стырят и что бы доказать это придется несколько лет провести в судах.
> Потому что если есть действительно классные наработки, то их стырят и что бы доказать это придется несколько лет
> провести в судах.
Не стырят, а воспользуются.
Так эти наработки принесут большую пользу, чем если останутся секретными.
Тебе не нравится, что деньги получит кто-то другой?
Тут две возможности: либо они так здорово их расширили, что их продукт оказался лучше твоего, что нормально,
либо они воспользовались уродскими законами об авторском праве, который дал им возможность ограничить права пользователей своего продукта и получить прибыль, которую ты не получил по соображениям этики, так это проблема общества целиком, а не open source, читай Столлмана до просветления.
> провести в судах.
Не стырят, а воспользуются.
Так эти наработки принесут большую пользу, чем если останутся секретными.
Тебе не нравится, что деньги получит кто-то другой?
Тут две возможности: либо они так здорово их расширили, что их продукт оказался лучше твоего, что нормально,
либо они воспользовались уродскими законами об авторском праве, который дал им возможность ограничить права пользователей своего продукта и получить прибыль, которую ты не получил по соображениям этики, так это проблема общества целиком, а не open source, читай Столлмана до просветления.
Как вариант:
Либо у них сеть распространения лучше построена
Или Более толстая мохнатая лапа в гос. службе или крупной корпорации сидит
ps
Все эти рассуждения о том, что если будет полная свобода, то пользователи и возьмут отдадут деньги разработчику - очень надуманны. Т.к. свобода не гарантирует, что будут равноправные условия по доведению продукта до потребителя у разработчика, разработавшего продукт, и у какого-либо перекупщика.
Либо у них сеть распространения лучше построена
Или Более толстая мохнатая лапа в гос. службе или крупной корпорации сидит
ps
Все эти рассуждения о том, что если будет полная свобода, то пользователи и возьмут отдадут деньги разработчику - очень надуманны. Т.к. свобода не гарантирует, что будут равноправные условия по доведению продукта до потребителя у разработчика, разработавшего продукт, и у какого-либо перекупщика.
Это проблемы капитализма, хорошо известные, никакого отношения к open source не имеющие.
> Все эти рассуждения о том, что если будет полная свобода, то пользователи и возьмут отдадут деньги разработчику - очень надуманны.
А разве тут кто-то так рассуждал?
> Все эти рассуждения о том, что если будет полная свобода, то пользователи и возьмут отдадут деньги разработчику - очень надуманны.
А разве тут кто-то так рассуждал?
> Это проблемы капитализма, хорошо известные, никакого отношения к open source не имеющие.
Имеющие.
Потому что закрытие исходников, введение авторских прав и т.д. - это способ разработчику хоть как-то получить перевес над перекупщиками (тиражирами и т.д.)
ps
> Это проблемы капитализма, хорошо известные
Почему именно капитализма? Это проблема любой мультиагентной системы.
Имеющие.
Потому что закрытие исходников, введение авторских прав и т.д. - это способ разработчику хоть как-то получить перевес над перекупщиками (тиражирами и т.д.)
ps
> Это проблемы капитализма, хорошо известные
Почему именно капитализма? Это проблема любой мультиагентной системы.
Вот этот способ имеет некоторое отношение к open source, а сами проблемы - общие, вон, даже и к капитализму не привязаны, как оказывается.
> это способ разработчику хоть как-то получить перевес над перекупщиками (тиражирами и т.д.)
вот есть про то, каким образом и в чьих интересах распространили понятие интеллектуальной собственности на программы
http://tentacle.local/master/mirrors/davem/stallman-forelesning.html
про книжки, песенки и фильмы дискуссии не менее жаркие
ограничения на копирование были введены в интересах общества, и вроде как в своё время были очень оправданы, но только время это давно прошло
так как сейчас они поддерживают индустрии, которые имхо не служат интересам общества, а выгодны только очень узкому кругу людей
это голливуд, богатые звукозаписывающие компании, богатые софтовые фирмы (торгующие коробочным софтом) и т.д.
законы об авторском праве позволяют владельцам и менеджерам таких компаний получать сверхприбыли
> это способ разработчику хоть как-то получить перевес над перекупщиками (тиражирами и т.д.)
вот есть про то, каким образом и в чьих интересах распространили понятие интеллектуальной собственности на программы
http://tentacle.local/master/mirrors/davem/stallman-forelesning.html
про книжки, песенки и фильмы дискуссии не менее жаркие
ограничения на копирование были введены в интересах общества, и вроде как в своё время были очень оправданы, но только время это давно прошло
так как сейчас они поддерживают индустрии, которые имхо не служат интересам общества, а выгодны только очень узкому кругу людей
это голливуд, богатые звукозаписывающие компании, богатые софтовые фирмы (торгующие коробочным софтом) и т.д.
законы об авторском праве позволяют владельцам и менеджерам таких компаний получать сверхприбыли
Столмана я читал.
Он не дает ответа - что помешает корпорациям получать сверхприбыль, если авторского права не будет.
Допустим авторского права нет.
Ты выпустил классную программу и продаешь ее по 10$.
Microsoft берет твою программу и начинает продавать ее по всему миру за 5$.
Твои действия?
Он не дает ответа - что помешает корпорациям получать сверхприбыль, если авторского права не будет.
Допустим авторского права нет.
Ты выпустил классную программу и продаешь ее по 10$.
Microsoft берет твою программу и начинает продавать ее по всему миру за 5$.
Твои действия?
> Ты выпустил классную программу и продаешь ее по 10$.
> Microsoft берет твою программу и начинает продавать ее по всему миру за 5$.
Не будут покупать ни у тех, ни у тех, так как можно скопировать бесплатно.
Никаких сверхприбылей, соотвественно.
> Microsoft берет твою программу и начинает продавать ее по всему миру за 5$.
Не будут покупать ни у тех, ни у тех, так как можно скопировать бесплатно.
Никаких сверхприбылей, соотвественно.
Но деньги можно получать и косвенно. За рекламу, поддержку и т.д.
Ты с чьего сайта будешь скачивать программу? С Microsoft.com? Или KrutayaPrograma.narod.ru?
Ты с чьего сайта будешь скачивать программу? С Microsoft.com? Или KrutayaPrograma.narod.ru?
поддержка сможет осуществляться любой организацией, в отличии от нынешнего состояния, когда закон даёт на это монополию только одной, таким образом ситуация по-любому не хуже, чем с авторским правом
у оригинальных авторов при этом преимущество, они лучше знают особенности программы, и более того, пользователь это тоже понимает, так что конечно, если авторы будут заниматься поддержкой, то заказов у них будет больше, чем у левой конторы
да, раскрученная марка, административные рычаги и другие внеэкономические способы влияния будут продолжать оказывать воздействие, ведь авторское право - только одно из них, просто самое уродливое и самое ненужное
> Ты с чьего сайта будешь скачивать программу?
А какая разница, ведь от этого сайту не прибыль, а только затраты.
у оригинальных авторов при этом преимущество, они лучше знают особенности программы, и более того, пользователь это тоже понимает, так что конечно, если авторы будут заниматься поддержкой, то заказов у них будет больше, чем у левой конторы
да, раскрученная марка, административные рычаги и другие внеэкономические способы влияния будут продолжать оказывать воздействие, ведь авторское право - только одно из них, просто самое уродливое и самое ненужное
> Ты с чьего сайта будешь скачивать программу?
А какая разница, ведь от этого сайту не прибыль, а только затраты.
> Не будут покупать ни у тех, ни у тех, так как можно скопировать бесплатно.
Скорее всего будет не так.
Отмена авторского права приведет к росту всяких защит, привязыванию копии программы к конкретному окружению, запутыванию кода и т.д.
Потому что разработчики захотят хоть как-то отбить деньги, и если сейчас деньги отбиваются за счет корпоративных пользователей, которые стараются не ставить пиратский софт, то без авторского права ...
Или предлагается обязать программы выкладывать в исходниках? Но тогда придется определится, что такое исходники, потому что asm файл сгенеренный C-компилятором, это тоже исходники.
Скорее всего будет не так.
Отмена авторского права приведет к росту всяких защит, привязыванию копии программы к конкретному окружению, запутыванию кода и т.д.
Потому что разработчики захотят хоть как-то отбить деньги, и если сейчас деньги отбиваются за счет корпоративных пользователей, которые стараются не ставить пиратский софт, то без авторского права ...
Или предлагается обязать программы выкладывать в исходниках? Но тогда придется определится, что такое исходники, потому что asm файл сгенеренный C-компилятором, это тоже исходники.
> Отмена авторского права приведет к росту всяких защит, привязыванию копии программы к конкретному окружению, запутыванию кода и т.д.
Именно такую картинку мы видим на рынке shareware, где закон об авторском праве несильно выполняется.
Именно такую картинку мы видим на рынке shareware, где закон об авторском праве несильно выполняется.
Есть разработчик - он хорошо умеет программы разрабатывать, с пользователями он плохо умеет общатся.
Есть распространитель - он плохо умеет программы разрабывать, но умеет хорошо общаться с пользователями.
Вопрос:
Кому пользователи понесут деньги?
Получается, что разработчик деньги с программ не получает, а получает из какого-то другого источника.
А программу пишет из спортивого интереса.
Внимание, вопрос:
Разработчик будет разрабатывать то, что ему интересно разрабатывать, или то, что нужно пользователям?
Есть распространитель - он плохо умеет программы разрабывать, но умеет хорошо общаться с пользователями.
Вопрос:
Кому пользователи понесут деньги?
Получается, что разработчик деньги с программ не получает, а получает из какого-то другого источника.
А программу пишет из спортивого интереса.
Внимание, вопрос:
Разработчик будет разрабатывать то, что ему интересно разрабатывать, или то, что нужно пользователям?
>> Ты с чьего сайта будешь скачивать программу?
> А какая разница, ведь от этого сайту не прибыль, а только затраты.
А как же реклама, продажа сопутствующих товаров и т.д.?
> А какая разница, ведь от этого сайту не прибыль, а только затраты.
А как же реклама, продажа сопутствующих товаров и т.д.?
> Отмена авторского права приведет к росту всяких защит, привязыванию копии программы к конкретному окружению,
> запутыванию кода и т.д.
Вот-вот, реально, пусть помучаются, раз уж хотят ограничить права пользователей.
Пользователи тоже увидят разницу, между собственническими и свободными программами.
Поддерживать проще тоже продукт, свободный от искусственных ограничений.
А сейчас, когда закон даёт возможность ограничивать права пользователей нахаляву, закрытые продукты получают нечестное преимущество.
> Или предлагается обязать программы выкладывать в исходниках?
С этим трудно, согласен.
> Есть разработчик - он хорошо умеет программы разрабатывать, с пользователями он плохо умеет общатся.
> Есть распространитель - он плохо умеет программы разрабывать, но умеет хорошо общаться с пользователями.
А что же мы видим сейчас?
Есть программист - он хорошо умеет программы разрабатывать, с пользователями он плохо умеет общатся.
И есть менеджеры, рекламщики - они плохо умеют программы разрабатывать, но хорошо умеют общаться с пользователями.
Кому достаются деньги?
> Получается, что разработчик деньги с программ не получает, а получает из какого-то другого источника.
> А программу пишет из спортивого интереса.
Необязательно, есть и другие способы.
Например:
Зарплата в компании, где он работает именно программистом. Компания при этом может:
* разрабатывать софт для внутреннего использования (утверждается, что сейчас больше половины программистов заняты именно в таких компаниях, можно голосовалку для смеху замутить даже)
* выпускать системы со встроенным ПО (одно из самых интересных имхо занятий для программиста)
* зарабатывать на поддержке произведённых продуктов, не важно самой этой компанией или другими (хотя конечно, работа в компании автора программы повышает доверие к уровню поддержки со стороны клиента)
* получать гранты от государства или некоммерческих фондов (то есть, работать для общества)
Кроме того:
* из желания прославиться, что в дальнейшем поможет устроиться на высокооплачиваемую должность в одну из вышеперечисленных компаний, или основать собственную; также слава может являться самоцелью
* по заказу от заинтересованных пользователей
Реально, от отмены ограничений на копирование пиздец придёт только коробочной индустрии, но я считаю её вредной для общества и плакать не буду, и я не одинок.
Программистов, а так же юристов и маркетоидов, поменьше конечно станет, но это не страшно, просто пойдут программировать только реально способные и заинтересованные, а не кто-попало в рассчёте на долю от сверхприбылей.
> Разработчик будет разрабатывать то, что ему интересно разрабатывать, или то, что нужно пользователям?
Если пользователям будет что-то реально нужно, а это ещё не создано, то они тем или иным способом оплатят разработку.
> А как же реклама, продажа сопутствующих товаров и т.д.?
Ты в это веришь?
wget не показывает рекламы
если я хочу просто что-то скачать, то покупать никакие сопутствующие товары просто не буду, даже если и увижу рекламу
так же вроде как время, когда можно было заработать на банерах, давно прошло, если меня не обманули
> запутыванию кода и т.д.
Вот-вот, реально, пусть помучаются, раз уж хотят ограничить права пользователей.
Пользователи тоже увидят разницу, между собственническими и свободными программами.
Поддерживать проще тоже продукт, свободный от искусственных ограничений.
А сейчас, когда закон даёт возможность ограничивать права пользователей нахаляву, закрытые продукты получают нечестное преимущество.
> Или предлагается обязать программы выкладывать в исходниках?
С этим трудно, согласен.
> Есть разработчик - он хорошо умеет программы разрабатывать, с пользователями он плохо умеет общатся.
> Есть распространитель - он плохо умеет программы разрабывать, но умеет хорошо общаться с пользователями.
А что же мы видим сейчас?
Есть программист - он хорошо умеет программы разрабатывать, с пользователями он плохо умеет общатся.
И есть менеджеры, рекламщики - они плохо умеют программы разрабатывать, но хорошо умеют общаться с пользователями.
Кому достаются деньги?
> Получается, что разработчик деньги с программ не получает, а получает из какого-то другого источника.
> А программу пишет из спортивого интереса.
Необязательно, есть и другие способы.
Например:
Зарплата в компании, где он работает именно программистом. Компания при этом может:
* разрабатывать софт для внутреннего использования (утверждается, что сейчас больше половины программистов заняты именно в таких компаниях, можно голосовалку для смеху замутить даже)
* выпускать системы со встроенным ПО (одно из самых интересных имхо занятий для программиста)
* зарабатывать на поддержке произведённых продуктов, не важно самой этой компанией или другими (хотя конечно, работа в компании автора программы повышает доверие к уровню поддержки со стороны клиента)
* получать гранты от государства или некоммерческих фондов (то есть, работать для общества)
Кроме того:
* из желания прославиться, что в дальнейшем поможет устроиться на высокооплачиваемую должность в одну из вышеперечисленных компаний, или основать собственную; также слава может являться самоцелью
* по заказу от заинтересованных пользователей
Реально, от отмены ограничений на копирование пиздец придёт только коробочной индустрии, но я считаю её вредной для общества и плакать не буду, и я не одинок.
Программистов, а так же юристов и маркетоидов, поменьше конечно станет, но это не страшно, просто пойдут программировать только реально способные и заинтересованные, а не кто-попало в рассчёте на долю от сверхприбылей.
> Разработчик будет разрабатывать то, что ему интересно разрабатывать, или то, что нужно пользователям?
Если пользователям будет что-то реально нужно, а это ещё не создано, то они тем или иным способом оплатят разработку.
> А как же реклама, продажа сопутствующих товаров и т.д.?
Ты в это веришь?
wget не показывает рекламы
если я хочу просто что-то скачать, то покупать никакие сопутствующие товары просто не буду, даже если и увижу рекламу
так же вроде как время, когда можно было заработать на банерах, давно прошло, если меня не обманули
Если пользователю что-то надо, он может это заказать. Нужно быстрое исправление ошибок и расширение софта - плати за поддержку.
Я вообще не понимаю в чем вопрос. Самые дорогие програмные продукты обычно нужны только одной фирме для своих специфических целей и даже, если бы они были бесплатными, это ничем бы не помогло желающим их своровать, поскольку они а) никому не нужны б) в них хрен кто разберется.
Я работал в одной фирме. Там, чтобы научиться правильно настраивать выпускаемый ею програмный комплекс нужно было просветление, настолько странно и непредсказуемо он работал.
Я вообще не понимаю в чем вопрос. Самые дорогие програмные продукты обычно нужны только одной фирме для своих специфических целей и даже, если бы они были бесплатными, это ничем бы не помогло желающим их своровать, поскольку они а) никому не нужны б) в них хрен кто разберется.
Я работал в одной фирме. Там, чтобы научиться правильно настраивать выпускаемый ею програмный комплекс нужно было просветление, настолько странно и непредсказуемо он работал.
Там, чтобы научиться правильно настраивать выпускаемый ею програмный комплекс нужно было просветление, настолько странно и непредсказуемо он работал.
Это говорит только о том насколько хуёвый был в этой фирме продукт и не более.
на счет могучих дядек:
Интересная ситуация - у каждого из "могучих дядек" был и есть свой собственный вариант юнихса.
Но каждый обращает своё внимание на линухс.
Может это все из-за того что:
1. линухс смог подвести этих могучих дядек к одному знаменателю, в отличие от попыток стандартизации юнихса.
2. или быть может из-за лицензий платного юнихса никто не хочет завязываться на какую-либо форму( платного, бесплатного ) юнихса.
Интересная ситуация - у каждого из "могучих дядек" был и есть свой собственный вариант юнихса.
Но каждый обращает своё внимание на линухс.
Может это все из-за того что:
1. линухс смог подвести этих могучих дядек к одному знаменателю, в отличие от попыток стандартизации юнихса.
2. или быть может из-за лицензий платного юнихса никто не хочет завязываться на какую-либо форму( платного, бесплатного ) юнихса.
Бывшие разработчики часто ссылаются на bloated and unmaintainable code base, вследствии marketing-driven development.
Кроме того, для железячных фирм разработка ОС - это not profit center, but cost center, вот они намерены избавиться от этого, но для этого все фичи, нужные пользователям, перенести.
Кроме того, для железячных фирм разработка ОС - это not profit center, but cost center, вот они намерены избавиться от этого, но для этого все фичи, нужные пользователям, перенести.
Это говорит только о том насколько хуёвый был в этой фирме продукт и не более.
Ну, ну. Эта фирма процветает и процветать будет еще долго, несмотря на разных умников. Стабильность работы и простота настройки этому не помеха. Когда я уходил, рассматривались грандиозные планы по созданию мега-сложной распределенной системы управления, логирования, настройки и слежения за всеми подсистемами программы. Не могу даже представить, что получится в результате.
Все в мире относительно.
Мелкософт тоже с ДОСом процветала
Мелкософт тоже с ДОСом процветала
Зря волну гонишь. Все программные продукты рассчитанные на десятки покупателей ставятся с трудом. Никто не предполагает, что их будет ставить кто-то кроме поставщика, и поэтому не тратят время на удобный инсталлятор и прочую фигню.
вспомнил про инсталлятор для военных, который предлагалось выпустить в форме приказа 
а никто волну и не гнал.
Просто то что процитировано было - к теме обсуждения не относится.
Просто то что процитировано было - к теме обсуждения не относится.
Мы часто выпускаем продукты на заказ, но при этом мы вынуждены ставить защиту на каждую копию программы.
т.к. заказчики не могут оплатить заказ сразу в том объеме, в котором нам было бы интересно на них работать.
Им проще оплачивать каждую копию.
Защита ставится по причине того, что заказчики российские, и законы для них не писаны.
И если уже есть одна копия, то остальные не покупаются.
Поэтому я не понимаю, почему вы так упираете на то, что с заказного ПО шибко большая отдача будет?
Фирмы редко работают на одного заказчика, чаще работают сразу на несколько, выигрывая на том, что общие задачи уже написаны. Причем задача для первого заказчика часто делается в убыток, или по себестоимости.
Мне сложно представить одиночного заказчика, который сможет придти и заказать разработку достаточно сложной задачи (например офиса) в полном объеме.
ps
Опять же вернемся к конкретике.
Мы делаем заказы, заказы примерно похожи, поэтому у нас сделан программный движок, на который наворачивается уже конкретика. Это позволяет нам не задирать цены для каждого заказа и держатся на плаву.
Но без авторского права, нам будет сложно сохранить права на движок, и сам движок нам делать будет уже не выгодно, нам проще будет делать каждый заказ отдельно, задрав цены.
Кто в итоге выиграл?
т.к. заказчики не могут оплатить заказ сразу в том объеме, в котором нам было бы интересно на них работать.
Им проще оплачивать каждую копию.
Защита ставится по причине того, что заказчики российские, и законы для них не писаны.
И если уже есть одна копия, то остальные не покупаются.
Поэтому я не понимаю, почему вы так упираете на то, что с заказного ПО шибко большая отдача будет?
Фирмы редко работают на одного заказчика, чаще работают сразу на несколько, выигрывая на том, что общие задачи уже написаны. Причем задача для первого заказчика часто делается в убыток, или по себестоимости.
Мне сложно представить одиночного заказчика, который сможет придти и заказать разработку достаточно сложной задачи (например офиса) в полном объеме.
ps
Опять же вернемся к конкретике.
Мы делаем заказы, заказы примерно похожи, поэтому у нас сделан программный движок, на который наворачивается уже конкретика. Это позволяет нам не задирать цены для каждого заказа и держатся на плаву.
Но без авторского права, нам будет сложно сохранить права на движок, и сам движок нам делать будет уже не выгодно, нам проще будет делать каждый заказ отдельно, задрав цены.
Кто в итоге выиграл?
Мы часто выпускаем продукты на заказ, но при этом мы вынуждены ставить защиту на каждую копию программы. т.к. заказчики не могут оплатить заказ сразу в том объеме, в котором нам было бы интересно на них работать. Им проще оплачивать каждую копию.
эта проблема связана не с ПО, а с неразвитостью банковской системы в РФ. По-нормальному ваш партнер должен был бы взять кредит (если прога действительно стоит так много) и из него оплачивать вашу работу. В этом случае ваши риски были бы меньше (не получится так, что разработчик купит одну копию по цене 1/20 от стоимости разработки, а потом у него начнутся "финансовые трудности") и не надо было бы тратить время на защиту.
Мы делаем заказы, заказы примерно похожи, поэтому у нас сделан программный движок, на который наворачивается уже конкретика. Это позволяет нам не задирать цены для каждого заказа и держатся на плаву.
Конкретика - это хорошо. Вот например проект в котором я сейчас участвую, он содержит два сделанных нами движка. Первый (делал мой напарник) - по сути дела враппер поверх движка сделанного нашим заказчиком. Чтобы его сделать пришлось затратить несколько человеко-месяцев и много консультаций с разработчиками (это несмотря на то что была документация, исходники и т.д.) Как работает враппер - я примерно понимаю, но что-то в нем менять не возьмусь
Второй движек делал лично я, в нем есть doxygen'овская документация (в основном с TeX-овскими формулами напарники им кое-как умеют пользоваться, но что-то принципиально новое на его основе делать так и не научились. Если наш код вдруг попадет в руки злобных конкурентов, вряд ли он им сильно поможет...> эта проблема связана не с ПО, а с неразвитостью банковской системы в РФ. По-нормальному ваш партнер должен был бы взять кредит
Заказчику - это невыгодно. Риск с нас переносится на него.
Сейчас, если дело не пойдет, то заказчик теряет стоимость одной копии программы, иначе он теряет полную стоимость.
> много консультаций с разработчиками (это несмотря на то что была документация, исходники и т.д.)
> напарники им кое-как умеют пользоваться, но что-то принципиально новое на его основе делать
Есть большая вероятность, что здесь виноваты следующие причины:
1. Плохая архитектура
2. Низкоуровневый внешний интерфейс библиотеки
3. Низкая квалификация разработчиков
4. Мало документации общего уровня.
5. В документации плохо освещены детали.
6. Мало примеров.
За последние полгода мы стыковались как минимум с 5-ю довольно крупными библиотеками от разных производителей.
Документацией использовалась для получения общего представления об архитектуре + получение информации о конкретных деталей. Общение с разработчиками библиотек шло на уровне: "хотим вот такую фичу, можете ли Вы ее сделать? Когда это будет? Будет ли вообще?".
Библиотеки были разработаны на .Net и имели четкую архитектуру. Вместе с документацией, также шло несколько больших примеров.
Что мы делали не так?
Заказчику - это невыгодно. Риск с нас переносится на него.
Сейчас, если дело не пойдет, то заказчик теряет стоимость одной копии программы, иначе он теряет полную стоимость.
> много консультаций с разработчиками (это несмотря на то что была документация, исходники и т.д.)
> напарники им кое-как умеют пользоваться, но что-то принципиально новое на его основе делать
Есть большая вероятность, что здесь виноваты следующие причины:
1. Плохая архитектура
2. Низкоуровневый внешний интерфейс библиотеки
3. Низкая квалификация разработчиков
4. Мало документации общего уровня.
5. В документации плохо освещены детали.
6. Мало примеров.
За последние полгода мы стыковались как минимум с 5-ю довольно крупными библиотеками от разных производителей.
Документацией использовалась для получения общего представления об архитектуре + получение информации о конкретных деталей. Общение с разработчиками библиотек шло на уровне: "хотим вот такую фичу, можете ли Вы ее сделать? Когда это будет? Будет ли вообще?".
Библиотеки были разработаны на .Net и имели четкую архитектуру. Вместе с документацией, также шло несколько больших примеров.
Что мы делали не так?
Еще один пример.
Есть такая программа Reflector, используется для просмотра и дизассемблирования .Net-сборок.
Сама программа тоже написана на .Net-е.
Разработчики программы не предполают, что программа может использоваться в качестве библиотеки для другой программы. Соответственно нет никакой документайии, нет никакого особого внешнего интерфейса, часть функциональности private и не доступно снаружи.
Но при этом, за пол дня удалось программу заиспользовать в качестве библиотеки. Удалось понять общую архитектуру, удалось решить конкретную задачу, которая стояла перед нами.
Отмечу опять же, что сама программа имела четкую архитектуру, и довольно высокоуровневый интерфейс взаимодействия между отдельными частями.
Есть такая программа Reflector, используется для просмотра и дизассемблирования .Net-сборок.
Сама программа тоже написана на .Net-е.
Разработчики программы не предполают, что программа может использоваться в качестве библиотеки для другой программы. Соответственно нет никакой документайии, нет никакого особого внешнего интерфейса, часть функциональности private и не доступно снаружи.
Но при этом, за пол дня удалось программу заиспользовать в качестве библиотеки. Удалось понять общую архитектуру, удалось решить конкретную задачу, которая стояла перед нами.
Отмечу опять же, что сама программа имела четкую архитектуру, и довольно высокоуровневый интерфейс взаимодействия между отдельными частями.
Заказчику - это невыгодно. Риск с нас переносится на него.
риск должен быть на том кто платит деньги... наверное вам имеет смысл снизить расценки (пересмореть зарплаты сотрудников?
) и оставить риски заказчикам, если сейчас заказчик считает что ваша цена уже содержит риски. И перейти на полную оплату за проект, а не за копии.Есть большая вероятность, что здесь виноваты следующие причины:
1. Плохая архитектура
2. Низкоуровневый внешний интерфейс библиотеки
3. Низкая квалификация разработчиков
4. Мало документации общего уровня.
5. В документации плохо освещены детали.
6. Мало примеров.
1. Может быть, я с ней не знаком
2. Таково назначение библиотеки. Чтобы ее эффективно и полностью использовать, надо много чего знать. Собственно назначение нашего враппера - повысить уровень, изолироваться от ненужных нам деталей.
3. Может быть. Все-таки ТНК, там и китайцы, наверное, делали, и индусы, и наши эммигранты...
4. Пожалуй даже слишком много...
6. Целая прога ("коробочная") основанная на этой либе, точнее ее исходники. Куда уж больше...
Кстати, щас посмотрел либу - исходников на 3 мега, написана на С++.
Общение с разработчиками библиотек шло на уровне: "хотим вот такую фичу, можете ли Вы ее сделать? Когда это будет? Будет ли вообще?".
Мы тоже так говорили. Нам отвечали: "чуваки, тот кто это делал, уволился год назад, а мы в этом разбираемся не больше вас"
а теперь представь себе, что назначение либы понятно только специалистам (не в области программинга а принципы работы - еще большим специалистам. Чтобы программеру со стороны во все это въехать, ему нужно как минимум стать обычным специалистом, неплохо изучить предметную область.
> риск должен быть на том кто платит деньги...
Совсем не согласен.
Хочешь сказать, что когда ты идешь в магазин, то ты готов (имеешь возможность) взять на себя риск?
Готов два раза (первый раз неудачно) заплатить за куртку? за машину? за квартиру?
А зачем тогда сделаны, например, две недели money back-а?
> сейчас заказчик считает что ваша цена уже содержит риски. И перейти на полную оплату за проект, а не за копии
И что мы выиграем? Снизим себе зарплату. Отпугнем часть клиентов. И где же выигрышь?
> Собственно назначение нашего враппера - повысить уровень, изолироваться от ненужных нам деталей.
ИМХО, это один из признаков плохой архитектуры. Вернее не архитектуры, а создание библиотеки как целого продукта, удобного для использования.
Плохо, когда сложность библиотеки, перекладывается на плечи клиента.
Совсем не согласен.
Хочешь сказать, что когда ты идешь в магазин, то ты готов (имеешь возможность) взять на себя риск?
Готов два раза (первый раз неудачно) заплатить за куртку? за машину? за квартиру?
А зачем тогда сделаны, например, две недели money back-а?
> сейчас заказчик считает что ваша цена уже содержит риски. И перейти на полную оплату за проект, а не за копии
И что мы выиграем? Снизим себе зарплату. Отпугнем часть клиентов. И где же выигрышь?
> Собственно назначение нашего враппера - повысить уровень, изолироваться от ненужных нам деталей.
ИМХО, это один из признаков плохой архитектуры. Вернее не архитектуры, а создание библиотеки как целого продукта, удобного для использования.
Плохо, когда сложность библиотеки, перекладывается на плечи клиента.
> назначение либы понятно только специалистам (не в области программинга а принципы работы - еще большим специалистам.
Да, согласен. Это большая проблема.
Но поэтому библиотека и должна быть построена так, чтобы с ней можно было быстро начать работать, даже не имея особых знаний о деталях.
Да, согласен. Это большая проблема.
Но поэтому библиотека и должна быть построена так, чтобы с ней можно было быстро начать работать, даже не имея особых знаний о деталях.
ИМХО, это один из признаков плохой архитектуры.
Само по себе наличие врапперов не есть признак плохой архитектуры. Это если речь идет о настоящих врапперах. В данном случае этот термин мне кажется неверным, по смыслу это скорее Facade.
Согласен. Wrapper - это не плохо, и не хорошо.
Плохо то, что пользователи сразу вынужденны сами писать wrapper для использования библиотеки.
Имхо, такой wrapper должен был написан самими разработчиками библиотеки.
Т.е. разработчики библиотеки не думали о пользователях библиотеки, а думали только о себе.
Плохо то, что пользователи сразу вынужденны сами писать wrapper для использования библиотеки.
Имхо, такой wrapper должен был написан самими разработчиками библиотеки.
Т.е. разработчики библиотеки не думали о пользователях библиотеки, а думали только о себе.
в нашем случае это и враппер и фасад одновременно. Фасад (в чистом виде) вряд ли тоже является признаком дурной архитектуре, иначе этого слова не было бы в книжке банды
Если эта библиотека бесплатная, то жаловаться в этой ситуации просто не на что.
1. Если у меня нет денег на ноут, например, то я беру кредит в банке (точнее мне его оформляют прям в магазине). За риски связанные с качеством или сроками поставки отвечает производитель или продавец, а за риски связанные с оплатой - я. При этом у покупателя есть возможность управлять рисками, в том числе отказаться от кредита, или от money-back за определенную сумму, как в ультре
2. Снизите зарплату, зато она будет гарантированной. Клиент всегда будет оплачивать работу, а не только тогда когда не удалось дешево сломать вашу защиту Клиентов может стать только больше, т.к. снизятся расценки...
3. Библиотека создавалась для внутренних целей компании, потенциальных пользователей библиотеки туева хуча, возможностей - тоже. Кому что понадобится, а что - нет - неизвестно. Мы и сами не знаем что нам может понадобиться через пару месяцев...
2. Снизите зарплату, зато она будет гарантированной. Клиент всегда будет оплачивать работу, а не только тогда когда не удалось дешево сломать вашу защиту
Клиентов может стать только больше, т.к. снизятся расценки...3. Библиотека создавалась для внутренних целей компании, потенциальных пользователей библиотеки туева хуча, возможностей - тоже. Кому что понадобится, а что - нет - неизвестно. Мы и сами не знаем что нам может понадобиться через пару месяцев...
У меня все равно остается мнение, что когда разработчик говорить "библиотека (программа) - бесплатна, поэтому жрите, в том виде, что есть" - это гнилая отмазка, а на самом деле разработчик просто не уважает пользователей.
> Снизите зарплату, зато она будет гарантированной.
Зарплата и сейчас гарантирована. Мы отбиваем свои деньги за счет массовости. У одного пользователя не получится (возьмем только одну копию зато другие девять пользователей возьмут 10-20 копией.
Зарплата и сейчас гарантирована. Мы отбиваем свои деньги за счет массовости. У одного пользователя не получится (возьмем только одну копию зато другие девять пользователей возьмут 10-20 копией.
я так и не понял, вы эксклюзивный софт делаете или серийный?
А кто их уважает, пользователей?
Microsoft разве что.
IBM даже в миллионобаксовой DB2 не смогла сделать нормального GUI-клиента.
Просто есть такое понятие - support. Если что не нравится, надо писать.
И потом, если я правильно понимаю ситуацию, библиотека задумана как низкоуровневая. Это 100% нормально. Взять к примеру тот же OpenGL - к нему есть куча всяких сторонних ОО-оберток.
Microsoft разве что.
IBM даже в миллионобаксовой DB2 не смогла сделать нормального GUI-клиента.
Просто есть такое понятие - support. Если что не нравится, надо писать.
И потом, если я правильно понимаю ситуацию, библиотека задумана как низкоуровневая. Это 100% нормально. Взять к примеру тот же OpenGL - к нему есть куча всяких сторонних ОО-оберток.
мы делаем эксклюзивный софт на базе нашего серийного движка
в принципе так и есть, только OpenGL значительно проще в освоении, т.к. для нее достаточно основ вычислительной геометрии, которую во всех технических вузах проходят
тогда, как я понимаю, основные ваши затраты - это движок. По сути дела вы его один раз сделали (вложились хорошенько) и теперь его продаете и внедряете?
> IBM даже в миллионобаксовой DB2 не смогла сделать нормального GUI-клиента.
> Просто есть такое понятие - support. Если что не нравится, надо писать.
Не уверен, что это пример для подражания
> Взять к примеру тот же OpenGL
Open GL - это в большей степени стандартизованное API, т.е. это двухсторонее соглашение.
С одной стороны его должны поддерживать каждые разработчики каждой OpenGL-библиотеки, а с другой - этот api используют пользователи.
Из-за того, что Open GL должны поддерживать как разработчики, так и пользователи, поэтому его нельзя сделать слишком сложным, и нельзя заложить прямо в API полное удобство для пользователей.
> Просто есть такое понятие - support. Если что не нравится, надо писать.
Не уверен, что это пример для подражания
> Взять к примеру тот же OpenGL
Open GL - это в большей степени стандартизованное API, т.е. это двухсторонее соглашение.
С одной стороны его должны поддерживать каждые разработчики каждой OpenGL-библиотеки, а с другой - этот api используют пользователи.
Из-за того, что Open GL должны поддерживать как разработчики, так и пользователи, поэтому его нельзя сделать слишком сложным, и нельзя заложить прямо в API полное удобство для пользователей.
Чуть хитрее.
Мы сделали базовый простенький движок, а далее при выполнении каждого заказа навешиваем дополнительную функциональность на движок.
Мы сделали базовый простенький движок, а далее при выполнении каждого заказа навешиваем дополнительную функциональность на движок.
> Мы делаем заказы, заказы примерно похожи, поэтому у нас сделан программный движок, на который наворачивается уже
> конкретика. Это позволяет нам не задирать цены для каждого заказа и держатся на плаву.
> Но без авторского права, нам будет сложно сохранить права на движок, и сам движок нам делать будет уже не выгодно,
> нам проще будет делать каждый заказ отдельно, задрав цены.
Движок - это инфраструктурная вещь. Такое делается легко и приятно, поэтому и существуют целые свободные операционные системы. Скорее всего ваши расходы на его создание завышены, поэтому вам и нужна монополия, чтобы окупить их.
В случае свободного ПО - не сделали бы вы, сделали бы другие, дешевле. А наворачивать фичи для заказчиков и брать с них за это деньги могли бы и вы, и любая другая компания.
Таким образом:
* поощряется повторное использование кода, и выделение действительно общих подзадач (так как выгодно реализовывать лишь минимум функциональности в инфраструктуре, и добавлять новые фичи по мере того, как на них появляется спрос)
* поощряется конкуренция вследствии отмены монополии на распространение, в результате пользователь может выбирать, кто будет ему добавлять фичи и поддерживать результат.
> Мне сложно представить одиночного заказчика, который сможет придти и заказать разработку достаточно сложной
> задачи (например офиса) в полном объеме.
Что такое офис? Типа MS Office? Да, такое скорее всего не могло бы появиться без монополии, предоставляемой авторским правом. Было бы другое, потому что ни одному заказчику и не нужна такая функциональность в полном объёме. Он заплатил бы за необходимый минимум.
> конкретика. Это позволяет нам не задирать цены для каждого заказа и держатся на плаву.
> Но без авторского права, нам будет сложно сохранить права на движок, и сам движок нам делать будет уже не выгодно,
> нам проще будет делать каждый заказ отдельно, задрав цены.
Движок - это инфраструктурная вещь. Такое делается легко и приятно, поэтому и существуют целые свободные операционные системы. Скорее всего ваши расходы на его создание завышены, поэтому вам и нужна монополия, чтобы окупить их.
В случае свободного ПО - не сделали бы вы, сделали бы другие, дешевле. А наворачивать фичи для заказчиков и брать с них за это деньги могли бы и вы, и любая другая компания.
Таким образом:
* поощряется повторное использование кода, и выделение действительно общих подзадач (так как выгодно реализовывать лишь минимум функциональности в инфраструктуре, и добавлять новые фичи по мере того, как на них появляется спрос)
* поощряется конкуренция вследствии отмены монополии на распространение, в результате пользователь может выбирать, кто будет ему добавлять фичи и поддерживать результат.
> Мне сложно представить одиночного заказчика, который сможет придти и заказать разработку достаточно сложной
> задачи (например офиса) в полном объеме.
Что такое офис? Типа MS Office? Да, такое скорее всего не могло бы появиться без монополии, предоставляемой авторским правом. Было бы другое, потому что ни одному заказчику и не нужна такая функциональность в полном объёме. Он заплатил бы за необходимый минимум.
хм
как все хитро перешло на общие проблемы софта
В общем итог такой:
продажа того, что напрограммировал - отомрет, а в место этого будет - программирование под заказ.
В общем так оно и есть
как все хитро перешло на общие проблемы софта
В общем итог такой:
продажа того, что напрограммировал - отомрет, а в место этого будет - программирование под заказ.
В общем так оно и есть
> В общем итог такой:
> продажа того, что напрограммировал - отомрет, а в место этого будет - программирование под заказ.
> В общем так оно и есть
только вот не будет так
наоборот, софтоиндустрия в союзе с MPAA и RIAA лоббируют всё новые законы
> продажа того, что напрограммировал - отомрет, а в место этого будет - программирование под заказ.
> В общем так оно и есть
только вот не будет так
наоборот, софтоиндустрия в союзе с MPAA и RIAA лоббируют всё новые законы
> Движок - это инфраструктурная вещь.Такое делается легко и приятно,
Если о пользователях движка не думать - то да, это просто.
Если думать, то ...
> В случае свободного ПО - не сделали бы вы, сделали бы другие, дешевле.
Еще раз повторю основную свою мысль. Отмена авторского права даст лишь новый виток защит, запутывания кода и т.д. И не даст выигрышка не пользователям, ни разработчикам, ни вторичным разработчикам.
Но вот некая стандартизация, и перевод частного продукта (если он занимает долгое время большую часть рынка) в общественное достояние - вот это более продуктивная идея, но менее понятняя в реализации.
Если о пользователях движка не думать - то да, это просто.
Если думать, то ...
> В случае свободного ПО - не сделали бы вы, сделали бы другие, дешевле.
Еще раз повторю основную свою мысль. Отмена авторского права даст лишь новый виток защит, запутывания кода и т.д. И не даст выигрышка не пользователям, ни разработчикам, ни вторичным разработчикам.
Но вот некая стандартизация, и перевод частного продукта (если он занимает долгое время большую часть рынка) в общественное достояние - вот это более продуктивная идея, но менее понятняя в реализации.
> Если о пользователях движка не думать - то да, это просто.
А не надо о них думать, думай о себе и о заказчике - тебе на основе движка для этого заказчика делать продукт.
Заплатят если - тогда думай.
> Еще раз повторю основную свою мысль. Отмена авторского права даст лишь новый виток защит, запутывания кода и т.д. И
> не даст выигрышка не пользователям, ни разработчикам, ни вторичным разработчикам.
Я считаю, что нет, так как у свободных программ будут преимущества, понятные пользоветелям:
* возможность выбора, кто будет поддерживать продукт, отсутствие vendor lock-in
* всякие запутывания и защиты вносят неудобства для пользователя
* разработка систем защиты повышает себестоимость продукта
* снимать защиту и копировать программу станет легально, и эффект от защиты сильно снизится (один хакер ломает, пользуются все)
Таким образом, защита и запутывание кода снизит конкурентноспособность продукта.
А не надо о них думать, думай о себе и о заказчике - тебе на основе движка для этого заказчика делать продукт.
Заплатят если - тогда думай.
> Еще раз повторю основную свою мысль. Отмена авторского права даст лишь новый виток защит, запутывания кода и т.д. И
> не даст выигрышка не пользователям, ни разработчикам, ни вторичным разработчикам.
Я считаю, что нет, так как у свободных программ будут преимущества, понятные пользоветелям:
* возможность выбора, кто будет поддерживать продукт, отсутствие vendor lock-in
* всякие запутывания и защиты вносят неудобства для пользователя
* разработка систем защиты повышает себестоимость продукта
* снимать защиту и копировать программу станет легально, и эффект от защиты сильно снизится (один хакер ломает, пользуются все)
Таким образом, защита и запутывание кода снизит конкурентноспособность продукта.
По твоему, где себя более удобно чувствует мелкий разработчик и мелкий пользователь, пол *Nix-ом или под windows-ом? Причем даже не в плане защиты своих наработок, а в плане предложенных инструментов.
AFAIK, мелкому разработчику (мелкому пользователю) много удобнее под windows-ом. Потому что именно под windows-ом больше полуфабрикатов, ориентированных именно на использование.
Под *nix-ом разработчик незаинтересован в пользователях (вторичных разработчиках они ему нафиг не нужны, с пользователей (вторичных разработчиков) он не получает никакой отдачи. И поэтому не видет смысла для них что-то делать.
Под windows-ом с этим проще, потому что можно выпустить библиотеку, можно защитить свои интересы, и на этой библиотеке заработать деньги.
Т.е. под windows-ом получается много меньше пропасть между основным разработчиком (например, разработчиком ОС, или разработчиком, какой технологии и конечным пользователем.
AFAIK, мелкому разработчику (мелкому пользователю) много удобнее под windows-ом. Потому что именно под windows-ом больше полуфабрикатов, ориентированных именно на использование.
Под *nix-ом разработчик незаинтересован в пользователях (вторичных разработчиках они ему нафиг не нужны, с пользователей (вторичных разработчиков) он не получает никакой отдачи. И поэтому не видет смысла для них что-то делать.
Под windows-ом с этим проще, потому что можно выпустить библиотеку, можно защитить свои интересы, и на этой библиотеке заработать деньги.
Т.е. под windows-ом получается много меньше пропасть между основным разработчиком (например, разработчиком ОС, или разработчиком, какой технологии и конечным пользователем.
У меня все равно остается мнение, что когда разработчик говорить "библиотека (программа) - бесплатна, поэтому жрите, в том виде, что есть" - это гнилая отмазка, а на самом деле разработчик просто не уважает пользователей.
Это не отмазка. Если тебе не нравится библиотека напиши ее сам или перепиши эту. Разработчик тебе ничего не обязан.
Обязан. Ты выпустил некий продукт (не важно платный или бесплатный и ты обязан выполнять ряд условий.
Как минимум они не дожны содержать закладок, дырок, вредоносного кода и т.д.
То что на данный момент, программисты выбили себе привилегию "as is", этих самых программистов не оправдывает.
ps
Проведу аналогию.
Если ты на улице детям раздаешь мороженное бесплатно, это не значит, что ты не обязан гарантировать качество этого мороженного.
С программами все тоже самое.
Как минимум они не дожны содержать закладок, дырок, вредоносного кода и т.д.
То что на данный момент, программисты выбили себе привилегию "as is", этих самых программистов не оправдывает.
ps
Проведу аналогию.
Если ты на улице детям раздаешь мороженное бесплатно, это не значит, что ты не обязан гарантировать качество этого мороженного.
С программами все тоже самое.
AFAIK, мелкому разработчику (мелкому пользователю) много удобнее под windows-ом. Потому что именно под windows-ом больше полуфабрикатов, ориентированных именно на использование.
Под *nix-ом разработчик незаинтересован в пользователях (вторичных разработчиках они ему нафиг не нужны, с пользователей (вторичных разработчиков) он не получает никакой отдачи. И поэтому не видет смысла для них что-то делать.
Под Линуксом-Юниксом благодаря Open source любой (в том числе и мелкий разработчик) может посмотреть, как работает та или иная программа. Т.е. надо тебе узнать, как работает ls берешь и смотришь. Под Виндами тебе, скорее всего, придется удовольствоваться msdn. Если там нет информации или ее сложно найти, придется спрашивать у других и не факт, что они тебе ответят. Кроме того, под Линукс существует большое количество бесплатных библиотек для многих часто встречающихся задач (работа с графическими файлами, например).
Про UNIX(tm) не знаю, там говорят действительно много неудобного, имею опыт только со свободными системами.
Пользователю, умеющему программировать, в свободных системах удобнее, конечно.
Все библиотеки и прочие инфраструктурные пакеты созданы именно для использования, а не для продажи, так как решают реальные задачи разработчиков, а не придуманные маркетоидами.
> Под *nix-ом разработчик незаинтересован в пользователях (вторичных разработчиках они ему нафиг не нужны, с
> пользователей (вторичных разработчиков) он не получает никакой отдачи. И поэтому не видет смысла для них что-то
> делать.
Практика показывает, что это почти всегда не так.
Даже если и так, это компенсируется возможностью сделать как надо самому.
> Под windows-ом с этим проще, потому что можно выпустить библиотеку, можно защитить свои интересы, и на этой
> библиотеке заработать деньги.
Что противоестественно.
Создал библиотеку для какой-то задачи, чтобы себе же было удобно, за что дополнительные деньги?
Вот если адаптируешь её под потребности каких-то чужих задач - пожалуйста, проси денег, но в разумных пределах, на сверхприбыль рассчитывать не приходится.
> Т.е. под windows-ом получается много меньше пропасть между основным разработчиком (например, разработчиком ОС,
> или разработчиком, какой технологии и конечным пользователем.
Полная фигня.
Пойди например, свяжись с разработчиком новой технологии в Windows, попроси снапшот, примерь для своей задачи.
Сможешь ли послать разработчику патч (результат адаптации узнать его мнение, работать вместе с ним, чтобы обеспечить присутствие нужных тебе возможностей в релизе?
Успехов, хи-хи.
Пользователю, умеющему программировать, в свободных системах удобнее, конечно.
Все библиотеки и прочие инфраструктурные пакеты созданы именно для использования, а не для продажи, так как решают реальные задачи разработчиков, а не придуманные маркетоидами.
> Под *nix-ом разработчик незаинтересован в пользователях (вторичных разработчиках они ему нафиг не нужны, с
> пользователей (вторичных разработчиков) он не получает никакой отдачи. И поэтому не видет смысла для них что-то
> делать.
Практика показывает, что это почти всегда не так.
Даже если и так, это компенсируется возможностью сделать как надо самому.
> Под windows-ом с этим проще, потому что можно выпустить библиотеку, можно защитить свои интересы, и на этой
> библиотеке заработать деньги.
Что противоестественно.
Создал библиотеку для какой-то задачи, чтобы себе же было удобно, за что дополнительные деньги?
Вот если адаптируешь её под потребности каких-то чужих задач - пожалуйста, проси денег, но в разумных пределах, на сверхприбыль рассчитывать не приходится.
> Т.е. под windows-ом получается много меньше пропасть между основным разработчиком (например, разработчиком ОС,
> или разработчиком, какой технологии и конечным пользователем.
Полная фигня.
Пойди например, свяжись с разработчиком новой технологии в Windows, попроси снапшот, примерь для своей задачи.
Сможешь ли послать разработчику патч (результат адаптации узнать его мнение, работать вместе с ним, чтобы обеспечить присутствие нужных тебе возможностей в релизе?
Успехов, хи-хи.
Ничего я не обязан. И в пример надо приводить не мороженное, а книгу или картину. Я ее написал и выложил на всеобщее обозрение, кому нравится, тот может ее копировать, а кому не нравится может идти своей дорогой. Ее качество исключительно на моей совести. Если я хочу иметь хорошую репутацию, то буду выкладывать хорошие программы.
ls - это плохой пример, это системная функция.
Приведи лучше, пример, какой-нибудь несистемной библиотеки.
Например, формирование отчетов, ввод rich-текста и т.д.
Приведи лучше, пример, какой-нибудь несистемной библиотеки.
Например, формирование отчетов, ввод rich-текста и т.д.
Допустим на минуту, что текст напрямую влияет на мозг, и может напрямую привести человека к самоубийству, разрушению личности и т.д.
Твое мнение останется тем же самым?
Твое мнение останется тем же самым?
> Ты выпустил некий продукт (не важно платный или бесплатный и ты обязан выполнять ряд условий.
> Как минимум они не дожны содержать закладок, дырок, вредоносного кода и т.д.
> То что на данный момент, программисты выбили себе привилегию "as is", этих самых программистов не оправдывает.
Платный или бесплатный - важно.
Передача денег подразумевает договор.
Нет договора - нет обязательств.
Накормить ребёнка отравленным или заведомо испорченным мороженным - уголовное преступление. С программами то же самое, и не более того.
Вот если бы разработчики гарантировали бы работу продукта у пользователя - тогда понятно, за что платятся деньги за каждую копию. Но это уже не лицензия за использование, а оплата поддержки или гарантии. Пользователь платит, разработчик обеспечивает работу программы. Невыполнение обязательств - нарушение договора - суд - штрафы и компенсации. Вот это правильно.
> Как минимум они не дожны содержать закладок, дырок, вредоносного кода и т.д.
> То что на данный момент, программисты выбили себе привилегию "as is", этих самых программистов не оправдывает.
Платный или бесплатный - важно.
Передача денег подразумевает договор.
Нет договора - нет обязательств.
Накормить ребёнка отравленным или заведомо испорченным мороженным - уголовное преступление. С программами то же самое, и не более того.
Вот если бы разработчики гарантировали бы работу продукта у пользователя - тогда понятно, за что платятся деньги за каждую копию. Но это уже не лицензия за использование, а оплата поддержки или гарантии. Пользователь платит, разработчик обеспечивает работу программы. Невыполнение обязательств - нарушение договора - суд - штрафы и компенсации. Вот это правильно.
Под виндами я в свое время хотел написать автокикатель тех, кто смотрит с меня фильмы вместо того, чтобы их скачивать. Для этого мне надо было замерять скорость скачивания. Я видел, что это возможно, поскольку net показывает эту информацию, но не смог найти в msdn соответствующей системной функции, на форуме мне тоже никто ничего не ответил. А под Линуксом я бы взял и посмотрел исходники соответствующей программы и задача была бы решена за пол часа. И так везде.
что значит "формирование отчетов"? Типа Access? OpenOffice сойдет?
Rich text есть в wxWidgets (бывшая wxWindows)...
Rich text есть в wxWidgets (бывшая wxWindows)...
скажу как мелкий программист мелкому программисту KDevelop последней версии практически ни чем не уступает Visual Studio последней версии. Или ты про что?
KDevelop последней версии практически ни чем не уступает Visual Studio последней версии. Или ты про что?> Для этого мне надо было замерять скорость скачивания.
Оффтопик: скорость - плохой критерий.
Мало ли, может связь тормозная.
Наблюдать за размерами окон и заполненностью буферов в TCP - гораздо лучше, правда протокол SMB/CIFS добавляет свои сложности. Если бы чистая передача по TCP, например как в FTP, то было бы довольно легко сформулировать чёткий критерий.
Оффтопик: скорость - плохой критерий.
Мало ли, может связь тормозная.
Наблюдать за размерами окон и заполненностью буферов в TCP - гораздо лучше, правда протокол SMB/CIFS добавляет свои сложности. Если бы чистая передача по TCP, например как в FTP, то было бы довольно легко сформулировать чёткий критерий.
Ты бесплатно раздал некачественные колеса, которые лопаются на большой скорости, это привело к множеству автоаварий с человеческими жертвами. Это уголовное преступление?
Ты бесплатно раздал программы, которое выходят из строя при большой нагрузке, что привело, например, к множеству аварий на производстве с человеческими жертвами. Это уголовное преступление?
Ты бесплатно раздал программы, которое выходят из строя при большой нагрузке, что привело, например, к множеству аварий на производстве с человеческими жертвами. Это уголовное преступление?
ты лицензионное соглашение MS читал когда-нибудь? Что там написано про ущерб нанесенный неправильной работой программ?
То-то же. А за них даже деньги берут, а ты говоришь про бесплатную. В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять а в код мелкомягких программ (даже бинарный!) вообще по соглашению заглядывать нельзя, не то что дизассемблировать
То-то же. А за них даже деньги берут, а ты говоришь про бесплатную. В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять а в код мелкомягких программ (даже бинарный!) вообще по соглашению заглядывать нельзя, не то что дизассемблировать
> что значит "формирование отчетов"? Типа Access?
Что-нибудь типа Crystal Report-а, хоть он мне и не нравится.
> OpenOffice сойдет?
Что он умеет? Как выглядит для разработчика создание отчета?
Что-нибудь типа Crystal Report-а, хоть он мне и не нравится.
> OpenOffice сойдет?
Что он умеет? Как выглядит для разработчика создание отчета?
Не, критерий хороший, если только файл просматривается равномерно, а не большими кусками. Если скорость скачивания упала настолько, что это стало походить на просмотр, то отключить лишних - это даже благо.
а что умеет Crystal Reports?
Если графики-диаграмки рисовать, то есть какая-то либа, только я название забыл...
Если графики-диаграмки рисовать, то есть какая-то либа, только я название забыл...
Программы распространяются под лицензией "as is" только потому, что это вынужденная мера.
Т.к. нынешний уровень технологий не позволяет отделить действия самой программы, от действий ОС, от действий пользователей и т.д.
Как только это проблема будет решена, то программы будут распространяться под такой же лицензией, как и нормальные продукты.
> В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять
Немного наивно. Вспоминается последний скандал, связанный с изменением исходников какого-то там open source-продукта. Там даже сами разработчики не могли понять смысл изменения, хотя они непосредственно видели вредоносный участок кода.
Т.к. нынешний уровень технологий не позволяет отделить действия самой программы, от действий ОС, от действий пользователей и т.д.
Как только это проблема будет решена, то программы будут распространяться под такой же лицензией, как и нормальные продукты.
> В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять
Немного наивно. Вспоминается последний скандал, связанный с изменением исходников какого-то там open source-продукта. Там даже сами разработчики не могли понять смысл изменения, хотя они непосредственно видели вредоносный участок кода.
Если вкратце, то вывести в различных вариантах табличные данные. При этом для программирования простых задач достаточно квалификации мышкокликателя.
Далеко в сторону разговор уводишь.
Вопрос ответственности за дефекты не имеет отношения к авторскому праву.
Решает такие вопросы суд. Он определит, в какой мере за происшедшее ответственнен разработчик, в какой - пользователь.
Вообще-то должны быть стандарты безопасности, которые обязан соблюдать организатор производства или производитель автомобилей. Стандарты в том числе и на управляющий софт.
Действительно, производители софта выбили себе право на поставки as-is, в отличии от производителей станков и автомобилей. Как только участятся случаи человеческих жертв из-за ошибок в софте, они точно так же могут и лишиться этого права, по крайней мере в случае поставок для определённых целей, где ошибки приведут к серьёзным последствиям.
Скорее всего, я думаю, это будут какие-то гос. сертификации, которые должен будет пройти продукт, и пользователь не будет иметь право использовать несертифицированный код для тех задач, когда ошибка влечёт за собой человеческие жертвы.
Вопрос ответственности за дефекты не имеет отношения к авторскому праву.
Решает такие вопросы суд. Он определит, в какой мере за происшедшее ответственнен разработчик, в какой - пользователь.
Вообще-то должны быть стандарты безопасности, которые обязан соблюдать организатор производства или производитель автомобилей. Стандарты в том числе и на управляющий софт.
Действительно, производители софта выбили себе право на поставки as-is, в отличии от производителей станков и автомобилей. Как только участятся случаи человеческих жертв из-за ошибок в софте, они точно так же могут и лишиться этого права, по крайней мере в случае поставок для определённых целей, где ошибки приведут к серьёзным последствиям.
Скорее всего, я думаю, это будут какие-то гос. сертификации, которые должен будет пройти продукт, и пользователь не будет иметь право использовать несертифицированный код для тех задач, когда ошибка влечёт за собой человеческие жертвы.
Вспоминается последний скандал, связанный с изменением исходников какого-то там open source-продукта
да не было там никакого скандала: человек внес изменения, но не подписал их, чем привлек к своим изменениям внимание. А после внимательного всматривания - все стало ясно. Вообще, открытость технологии - это всегда плюс в смысле безопасности, т.к. (при прочих равных условиях) больше народу его проверяет. Например, те же криптоалгоритмы: никто не использует свои доморощенные и засекреченные, все используют многократно проверенные, давно опубликованные и стандартизованные.
ну функциональности MS Excel тебе достаточно?
> Программы распространяются под лицензией "as is" только потому, что это вынужденная мера.
> Т.к. нынешний уровень технологий не позволяет отделить действия самой программы, от действий ОС, от действий
> пользователей и т.д.
> Как только это проблема будет решена, то программы будут распространяться под такой же лицензией, как и нормальные
> продукты.
Именно. Только ни разработчики, ни пользователи совершенно не заинтересованы решать эту проблему за свой счёт.
Государство этим займётся, когда появятся трупы.
> > В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять
> Немного наивно. Вспоминается последний скандал, связанный с изменением исходников какого-то там open
> source-продукта. Там даже сами разработчики не могли понять смысл изменения, хотя они непосредственно видели
> вредоносный участок кода.
Кто-то же будет определять безопасность кода в любом случае.
Открытые исходники хотя бы принципиально дают возможность любой заинтересованной стороне обеспечить сертификацию. На практике, скорее всего, всё равно понадобиться переписывать код почти с нуля.
А может быть, общество устрашится затрат и смирится с риском, тоже правдоподобный вариант.
В упомянутом случае кстати вредоносные изменения были замечены раньше, чем код дошёл до конечных пользователей.
> Т.к. нынешний уровень технологий не позволяет отделить действия самой программы, от действий ОС, от действий
> пользователей и т.д.
> Как только это проблема будет решена, то программы будут распространяться под такой же лицензией, как и нормальные
> продукты.
Именно. Только ни разработчики, ни пользователи совершенно не заинтересованы решать эту проблему за свой счёт.
Государство этим займётся, когда появятся трупы.
> > В конце концов, если коды открыты, ты можешь их сам проверить (или спеца нанять
> Немного наивно. Вспоминается последний скандал, связанный с изменением исходников какого-то там open
> source-продукта. Там даже сами разработчики не могли понять смысл изменения, хотя они непосредственно видели
> вредоносный участок кода.
Кто-то же будет определять безопасность кода в любом случае.
Открытые исходники хотя бы принципиально дают возможность любой заинтересованной стороне обеспечить сертификацию. На практике, скорее всего, всё равно понадобиться переписывать код почти с нуля.
А может быть, общество устрашится затрат и смирится с риском, тоже правдоподобный вариант.
В упомянутом случае кстати вредоносные изменения были замечены раньше, чем код дошёл до конечных пользователей.
Когда как... Есть более удобные, и более мощные либы, чем excel.
зы
Могу замететь, что Open Office - это ответный удар на MS Office, Mozilla - ответный удар на explorer, Т.е. идет постоянное запаздывание...
ps
Возмем более мелкую задачку, например тот же грид (редактирование табличных данных через GUI-интерфейс).
Для windows-а я знаю больше десятка удобных и успешных предложений.
pps
Напомните, плиз, как обстоит сейчас дело под *nix-ом с обменом данными между приложениями? Что-нибудь кроме сокетов и корбы сейчас есть? Как, например, обстоит дело с передачей данных через clipboard?
зы
Могу замететь, что Open Office - это ответный удар на MS Office, Mozilla - ответный удар на explorer, Т.е. идет постоянное запаздывание...
ps
Возмем более мелкую задачку, например тот же грид (редактирование табличных данных через GUI-интерфейс).
Для windows-а я знаю больше десятка удобных и успешных предложений.
pps
Напомните, плиз, как обстоит сейчас дело под *nix-ом с обменом данными между приложениями? Что-нибудь кроме сокетов и корбы сейчас есть? Как, например, обстоит дело с передачей данных через clipboard?
> Именно. Только ни разработчики, ни пользователи совершенно не заинтересованы решать эту проблему за свой счёт.
> Государство этим займётся, когда появятся трупы.
Трупы уже есть. Только доказать почти ничего не возможно.
> Государство этим займётся, когда появятся трупы.
Трупы уже есть. Только доказать почти ничего не возможно.
> В упомянутом случае кстати вредоносные изменения были замечены раньше, чем код дошёл до конечных пользователей.
Потому что был замечен сам факт взлома, а не факт изменения.
Если бы изменение сделал бы зарегистрированный (внутренний) разработчик, то изменение бы никого не заинтересовало бы, и осталось бы в системе.
Потому что был замечен сам факт взлома, а не факт изменения.
Если бы изменение сделал бы зарегистрированный (внутренний) разработчик, то изменение бы никого не заинтересовало бы, и осталось бы в системе.
насчет OpenOffice'а - согласен, Mozilla появилась чуть ли не раньше IE (если не ошибаюсь) и по функционалу мне больше оперу напоминает (или наоборот?). Тут попросил аргументироватьнасчет KDevelop и VS2003, то и там и там есть комплишн (ака интелли-сенс в обоих прогах глючит (но по-разному KD радует тем, что его комплишн еще и скобочки ставит Тоже появился code fold/unfold, причем в KD даже раньше чем в VS... в общем, как редактор KD вполне хорош
Грид есть в wx (открытые исходники, платформа любая) и Qt (только исходники там вроде закрытые? а может и еще есть, надо на SourceForge поискать...
Тоже появился code fold/unfold, причем в KD даже раньше чем в VS... в общем, как редактор KD вполне хорош Грид есть в wx (открытые исходники, платформа любая) и Qt (только исходники там вроде закрытые? а может и еще есть, надо на SourceForge поискать...
> Могу замететь, что Open Office - это ответный удар на MS Office, Mozilla - ответный удар на explorer, Т.е. идет постоянное
> запаздывание...
Совершенно верно. Эти монстры сначала создаются крупными компаниями, которым копирайт даёт монополию. В отсутствии монополии эволюция совсем по-другому бы пошла.
> Напомните, плиз, как обстоит сейчас дело под *nix-ом с обменом данными между приложениями? Что-нибудь кроме сокетов и корбы сейчас есть? Как, например, обстоит дело с передачей данных через clipboard?
Подмена понятий. Передача данных через clipboard актуально для мышевозящего пользователя, а мы говорили о программирующем пользователе.
Говорили что-то о KParts, который придуман в рамках KDE. Вроде как очень круто, насколько это возможно в рамках этой идеологии. Сам я в этом не понимаю, это очень далеко от моих интересов.
> запаздывание...
Совершенно верно. Эти монстры сначала создаются крупными компаниями, которым копирайт даёт монополию. В отсутствии монополии эволюция совсем по-другому бы пошла.
> Напомните, плиз, как обстоит сейчас дело под *nix-ом с обменом данными между приложениями? Что-нибудь кроме сокетов и корбы сейчас есть? Как, например, обстоит дело с передачей данных через clipboard?
Подмена понятий. Передача данных через clipboard актуально для мышевозящего пользователя, а мы говорили о программирующем пользователе.
Говорили что-то о KParts, который придуман в рамках KDE. Вроде как очень круто, насколько это возможно в рамках этой идеологии. Сам я в этом не понимаю, это очень далеко от моих интересов.
> Как, например, обстоит дело с передачей данных через clipboard?
Clipboard работает. Очень удобно и для мышевозящего пользователя - движением мышки выделил, одним щелчком вставил. Требуется меньше нажатий, чем в Windows. Правда не все приложения корректно с ним работают - но думаю, что дело в кривости приложений, таких и под Windows достаточно.
Clipboard работает. Очень удобно и для мышевозящего пользователя - движением мышки выделил, одним щелчком вставил. Требуется меньше нажатий, чем в Windows. Правда не все приложения корректно с ним работают - но думаю, что дело в кривости приложений, таких и под Windows достаточно.
Clipboard работает.
Но только весьма условно. В X Clipboard может содержать только текст, в X протоколе такое ограничение. В Windows Clipboard может содержать любую информацию любой структуры.
Текст, или любые данные (картинки, rich text)?
Что-нибудь кроме сокетов и корбы сейчас есть?
пайпы? shared-memory?
> Подмена понятий. Передача данных через clipboard актуально для мышевозящего пользователя
Я к тому, что отсутствие вот таких простых кирпичиков приводит к тому, что небольшой разработчик чувствует себя очень неуютно, т.к. без этих кирпичиков резко вырастает себестоимость разработки.
Т.е. резко возрастает барьер выхода на рынок.
В данном случае, даже такую простую задачу, как обмен данными с другой программой через clipboard, разработчик должен сам разработать и закодить.
Причем кирпичиков не видно, именно под Linuxom. ИМХО, это именно из-за того, что разработчику отдельного кирпичика под linux-ом очень сложно защитит свои разработки.
Я к тому, что отсутствие вот таких простых кирпичиков приводит к тому, что небольшой разработчик чувствует себя очень неуютно, т.к. без этих кирпичиков резко вырастает себестоимость разработки.
Т.е. резко возрастает барьер выхода на рынок.
В данном случае, даже такую простую задачу, как обмен данными с другой программой через clipboard, разработчик должен сам разработать и закодить.
Причем кирпичиков не видно, именно под Linuxom. ИМХО, это именно из-за того, что разработчику отдельного кирпичика под linux-ом очень сложно защитит свои разработки.
Отчасти, вы (вдвоем с ) правы. Отвык я пользоваться такой штукой, как буфер обмена для сложных данных
Согласен, что с нетекстовой информацией ситуация хуже. Но из Мозиллы в Openoffice rich text и графика копируются, сейчас проверил. И в KDE вроде бы как свои дополнительные механизмы есть, но про них ничего сказать не могу, не пользуюсь.
Согласен, что с нетекстовой информацией ситуация хуже. Но из Мозиллы в Openoffice rich text и графика копируются, сейчас проверил. И в KDE вроде бы как свои дополнительные механизмы есть, но про них ничего сказать не могу, не пользуюсь.
Понимаешь, то что данные из одного конкретного приложения копируются в другое конкретное приложение своими способами (как в твоем примере) имеет еще один большой недостаток: отсутствие гарантий на совместимость. В Windows ты можешь картинку сделанную в любой программе вставить в любую программу, поддерживающую вставление картинки из clipboard. В X это понятие немного трансформируется. Ты можешь вставить картинку в данную конкретную программу, если она понимает, как разработчики другой программы решили переводить картинки в текстовой вид для буфера, причем способов может быть много, и все они не совместимы.
Скопируй таблицу из gnumeric в abiword. Или скопируй картинку из ElectricEyes в KWord.
Скопируй таблицу из gnumeric в abiword. Или скопируй картинку из ElectricEyes в KWord.
Не факт, что эти кирпичики нужны вообще.
Возможно, они не нужны с точки зрения философии разработчиков. Но я как пользователь хочу иметь удобный Clipboard. Который будет работать не только с теми программами, которые я купил/скачал у тебя, но и с программами, которые я купил/скачал у Васи. А ты как разработчик не сумеешь под X это сделать хотя бы потому, что там это не предусмотрено в концепции системы.
> Я к тому, что отсутствие вот таких простых кирпичиков приводит к тому, что небольшой разработчик чувствует себя очень
> неуютно, т.к. без этих кирпичиков резко вырастает себестоимость разработки.
Только если он привык мыслить в терминах коробок. И только если его продукт нацелен на неопытных пользователей, не умеющих пользоваться компьютером, а не ты ли говорил, что им нет места в будущем?
Для программирующего пользователя же гораздо важнее простота и документированность промежуточных форматов, протоколов и API.
Кроме того, для каждого такого кирпичика можно назвать кирпич поувесиcтей, несвободный аналог которого стоит $$$ (если существует в то время как свободный можно использовать бесплатно и без лицензионных ограничений, что упрощает создание свободного ПО.
Да и есть конечно средства передачи через clipboard давно, только с ограниченной интерорабельностью, вследствии отсутствия пока де-факто стандартов. Пользователь может заплатить интегратору за подбор софта для решения нужной задачи и обеспечения интероперабельности, либо проделать эту работу самостоятельно.
> неуютно, т.к. без этих кирпичиков резко вырастает себестоимость разработки.
Только если он привык мыслить в терминах коробок. И только если его продукт нацелен на неопытных пользователей, не умеющих пользоваться компьютером, а не ты ли говорил, что им нет места в будущем?
Для программирующего пользователя же гораздо важнее простота и документированность промежуточных форматов, протоколов и API.
Кроме того, для каждого такого кирпичика можно назвать кирпич поувесиcтей, несвободный аналог которого стоит $$$ (если существует в то время как свободный можно использовать бесплатно и без лицензионных ограничений, что упрощает создание свободного ПО.
Да и есть конечно средства передачи через clipboard давно, только с ограниченной интерорабельностью, вследствии отсутствия пока де-факто стандартов. Пользователь может заплатить интегратору за подбор софта для решения нужной задачи и обеспечения интероперабельности, либо проделать эту работу самостоятельно.
Еще в некоторой степени, open source - это удар по ООП.
Open source - нарушает один из "китов" ООП: инкапсуляцию.
Разработчиком двигает следующая мысль: зачем мне делать инкапсуляцию, и придумывать хороший (удобный, гибкий ит.д.) интерфейс взаимодействия, если пользователю все равно доступны исходники. И он в любой момент сможет все что угодно сделать под себя.
Open source - нарушает один из "китов" ООП: инкапсуляцию.
Разработчиком двигает следующая мысль: зачем мне делать инкапсуляцию, и придумывать хороший (удобный, гибкий ит.д.) интерфейс взаимодействия, если пользователю все равно доступны исходники. И он в любой момент сможет все что угодно сделать под себя.
Но сейчас Линукс все больше поворачивают лицом в сторону пользователя, поэтому, есть мнение, что аналог Clipboard будет создан (.10 утверждает, что он уже создан).
Ты путаешь, .10 утверждает, что можно подобрать набор программ, между которыми clipboard будет совместим, не спорю. Но по-моему, в широком масштабе стандартизировать это дело не удастся, потому что для этого необходимы серьезные поправки в X. В противном случае, найдется достаточно крупный производитель, который откажется следовать общим рекомендациям, которые будут несовместимы с большим количеством его собственных наработок, и вся стандартизация опять же пойдет коту под хвост. На самом деле, Clipboard это только одна небольшая проблема, а аналогичных проблем существует еще большое множество.
Это я понимаю. Но я ответил именно со своей личной точки зрения: в последнее время я как пользователь не испытываю никаких проблем с использованием буфера обмена, в отличии от ситуации n-летней давности. Возможно, причина этого заключается в том, что изменилась специфика решаемых мною задач с использованием компьютера. Возможно, я просто перестроил свои навыки работы с компьютером на использование характерных для Linux технологий.
> Для программирующего пользователя же гораздо важнее простота и документированность промежуточных форматов, протоколов и API.
Как много API-стандартизированно под Linux-ом?
Насколько распространена поддержка этих стандартов?
Под linux-ом мне приходит в голову только Posix, OpenGL.
Под windows: DDE, COM/DCOM, ODBC, ActiveX, OleDB, ADO, DirectX и т.д.
Причем есть стандарты и для узких областей.
Например, в АСУТП есть такой стандарт как OPC.
Как много API-стандартизированно под Linux-ом?
Насколько распространена поддержка этих стандартов?
Под linux-ом мне приходит в голову только Posix, OpenGL.
Под windows: DDE, COM/DCOM, ODBC, ActiveX, OleDB, ADO, DirectX и т.д.
Причем есть стандарты и для узких областей.
Например, в АСУТП есть такой стандарт как OPC.
Ещё.
В духе unix way предполагается, что логика программы будет реализована отдельно, а гуйня, если необходимо, навешиваться сверху. Хочешь на букву K, хочешь на букву G [mode=flame]Кал и Говно соответственно[/mode], хочешь на java, хочешь на windows native для виндового порта, и для ещё не созданной графической оболочки можно будет приделать.
Соответственно, общение гуя идёт через простые механизмы IPC (ну либо гуй подгружается плагином и используются прямые вызовы функций). Соответственно, если хочется заюзать средства KDE по поддержке clipboard, человек, имеющий некоторое представление о программировании для этой среды, очень просто её добавляет.
Вот тебе и инкапсуляция, на другом уровне.
Реально не все программы так сделаны, так как перед глазами авторов образцы из мира Windows.
В духе unix way предполагается, что логика программы будет реализована отдельно, а гуйня, если необходимо, навешиваться сверху. Хочешь на букву K, хочешь на букву G [mode=flame]Кал и Говно соответственно[/mode], хочешь на java, хочешь на windows native для виндового порта, и для ещё не созданной графической оболочки можно будет приделать.
Соответственно, общение гуя идёт через простые механизмы IPC (ну либо гуй подгружается плагином и используются прямые вызовы функций). Соответственно, если хочется заюзать средства KDE по поддержке clipboard, человек, имеющий некоторое представление о программировании для этой среды, очень просто её добавляет.
Вот тебе и инкапсуляция, на другом уровне.
Реально не все программы так сделаны, так как перед глазами авторов образцы из мира Windows.
Под windows: DDE, COM/DCOM, ODBC, ActiveX, OleDB, ADO, DirectX и т.д.
Это, как раз, демонстрирует кидания Микрософт из одной крайности в другую.
DDE->COM->DCOM (->ATL) & ActiveX & COM+ -> .NET
OleDB -> ADO -> ADO.NET
Windows API не совместим полностью между 98 и NT семейством.
Все эти технологии довольно сложные и становятся более менее легкими для изучения только в .NET.
DDE->COM->DCOM (->ATL) & ActiveX & COM+ -> .NETТы не прав.
Если разбить на группы, то тут смешаны в одну кучу четыре непересекающиеся группы из разных областей, которые эволюционировали самостоятельно
DDE - это API
COM/DCOM/ActiveX/COM+ - это API
ATL - это библиотека, это не API.
.NET - это платформа, это не API.
OleDB и ADO разрабатывались одновременно, независимо друг от друга и для разных целей.
Windows API совместим в известной степени, более совместимым его сделать для вообще-то двух разных операционных систем, невозможно. Точнее: весь API Windows98, не связанный с системными функциями (драйвера, конфигурирование системы) соместим с Windows NT.
Опять подмена понятий.
Не стандартизованность, а простота и документированность.
Стандарты реально нужны лишь для хорошо определённых задач, которые уже известно как решать, накоплен опыт, и надо выбрать из всех способов лучший.
> DDE, COM/DCOM, ODBC, ActiveX, OleDB,
"Стандарты хороши тем, что их так много, что есть из чего выбирать"
по аналогии с процитированным могу назвать Sun RPC, xml-rpc, DBI
но никакие стандарты не помогут мне заставить браузер вызвать для набора этого сообщения нормальный редактор вместо того отстоя, в котором я это набираю, если разработчики не оставили хук для этого дела, и если в исходниках не найти места, куда этот хук вставить
Не стандартизованность, а простота и документированность.
Стандарты реально нужны лишь для хорошо определённых задач, которые уже известно как решать, накоплен опыт, и надо выбрать из всех способов лучший.
> DDE, COM/DCOM, ODBC, ActiveX, OleDB,
"Стандарты хороши тем, что их так много, что есть из чего выбирать"
по аналогии с процитированным могу назвать Sun RPC, xml-rpc, DBI
но никакие стандарты не помогут мне заставить браузер вызвать для набора этого сообщения нормальный редактор вместо того отстоя, в котором я это набираю, если разработчики не оставили хук для этого дела, и если в исходниках не найти места, куда этот хук вставить
> Пойди например, свяжись с разработчиком новой технологии в Windows, попроси снапшот, примерь для своей задачи.
> Сможешь ли послать разработчику патч (результат адаптации узнать его мнение, работать вместе с ним, чтобы обеспечить присутствие нужных тебе возможностей в релизе?
> Успехов, хи-хи.
Все зависит от размеров меня, и размеров компании. Если размеры примерно равны, размер заказа достаточно интересен для компании-разработчика, то контакты довольно быстро налаживаются. И компания разработчик довольно сильно идет навстречу.
На ряд developer-ских продуктов Microsoft-а можно было повлиять на этапе beta-ы, т.к. есть возможность наладить хорошие отношения с российским отделением Microsoft-а, а у них есть небольшие рычаги давления на сам microsoft.
> Сможешь ли послать разработчику патч (результат адаптации узнать его мнение, работать вместе с ним, чтобы обеспечить присутствие нужных тебе возможностей в релизе?
> Успехов, хи-хи.
Все зависит от размеров меня, и размеров компании. Если размеры примерно равны, размер заказа достаточно интересен для компании-разработчика, то контакты довольно быстро налаживаются. И компания разработчик довольно сильно идет навстречу.
На ряд developer-ских продуктов Microsoft-а можно было повлиять на этапе beta-ы, т.к. есть возможность наладить хорошие отношения с российским отделением Microsoft-а, а у них есть небольшие рычаги давления на сам microsoft.
> т.к. есть возможность наладить хорошие отношения с российским отделением Microsoft-а, а у них есть небольшие рычаги
> давления на сам microsoft.
то есть через несколько слоёв менеджеров и маркетоидов
в случае свободного ПО этой пропасти нет
> давления на сам microsoft.
то есть через несколько слоёв менеджеров и маркетоидов
в случае свободного ПО этой пропасти нет
> Это, как раз, демонстрирует кидания Микрософт из одной крайности в другую.
Это не кидание из крайности в крайность, а неизбежная эволюция.
механизму DDE - лет 13 уже.
COM/OLE/ActiveX - 10 лет
.Net - 2 года.
Или ты хочешь сказать, что не надо ничего менять к лучшему?
Это не кидание из крайности в крайность, а неизбежная эволюция.
механизму DDE - лет 13 уже.
COM/OLE/ActiveX - 10 лет
.Net - 2 года.
Или ты хочешь сказать, что не надо ничего менять к лучшему?
> по аналогии с процитированным могу назвать Sun RPC, xml-rpc, DBI
На первый взгляд сплошное RPC-и, т.е. взаимодействие между отдельными компьютерами, а не между отдельными программами, или частями программы.
Замечу: что COM/ActiveX/ODBC и т.д. - это фактически стандартизация общения отдельных частей одной программы
На первый взгляд сплошное RPC-и, т.е. взаимодействие между отдельными компьютерами, а не между отдельными программами, или частями программы.
Замечу: что COM/ActiveX/ODBC и т.д. - это фактически стандартизация общения отдельных частей одной программы
Я знаю, что это не одно и тоже. Лучше это оформить это как претензию к Windows.
COM пришел на смену DDE (если не ошибаюсь). На смену COM пришел DCOM (+ActiveX). Библиотека ATL нужна, чтобы нормально работать с COM'ом (иначе можно застрелится). A .NET избавил, наконец, от этого кошмара, предложив иной способ взаимодействия программ. И все это надо было учить.
Про базы данных я не знаю точно, не работал с ними. Но то, что там Микрософт тоже напридумывал кучу разных технологий, не сомневаюсь.
Мне это кажется слишком сильным утверждением. Есть ли этому подтверждения в независимой прессе?
COM пришел на смену DDE (если не ошибаюсь). На смену COM пришел DCOM (+ActiveX). Библиотека ATL нужна, чтобы нормально работать с COM'ом (иначе можно застрелится). A .NET избавил, наконец, от этого кошмара, предложив иной способ взаимодействия программ. И все это надо было учить.
Про базы данных я не знаю точно, не работал с ними. Но то, что там Микрософт тоже напридумывал кучу разных технологий, не сомневаюсь.
Точнее: весь API Windows98, не связанный с системными функциями (драйвера, конфигурирование системы) соместим с Windows NT.
Мне это кажется слишком сильным утверждением. Есть ли этому подтверждения в независимой прессе?
общения отдельных частей одной программы
сомневаюсь что ты не слышал про exe-сервера...
Или ты хочешь сказать, что не надо ничего менять к лучшему?
Ну если сначала сделали плохо, то, конечно, нужно менять. Но можно сразу сделать хорошо.
Мне это кажется слишком сильным утверждением. Есть ли этому подтверждения в независимой прессе?
в общем это почти верно, в 9x API нет того что просто не поддерживается системой. Если ты в проге активно юзаешь дескрипторы безопасности, под не-NT она точно не заработает
>то есть через несколько слоёв менеджеров и маркетоидов
>в случае свободного ПО этой пропасти нет
Вряд ли это связано с свободным или платным распространением ПО. Размер исходного кода виндов сразу отобьет желание вносить туда какие попало изменения. Чем больше размер кода, тем больше менеджмента - это неизбежно.
>в случае свободного ПО этой пропасти нет
Вряд ли это связано с свободным или платным распространением ПО. Размер исходного кода виндов сразу отобьет желание вносить туда какие попало изменения. Чем больше размер кода, тем больше менеджмента - это неизбежно.
> На первый взгляд сплошное RPC-и, т.е. взаимодействие между отдельными компьютерами, а не между отдельными
> программами, или частями программы.
А как же сетевая прозрачность?
> Замечу: что COM/ActiveX/ODBC и т.д. - это фактически стандартизация общения отдельных частей одной программы
В рамках unix way это решается другими способами.
Программа разбивается на части, каждая из которых делает только одно дело, но делает его хорошо.
Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
Если декомпозиция выполнена правильно, то пользователь может менять схему взаимодействия частей без знания их внутреннего устройства, разобравшись только с протоколом. В этом ему помогают развитые скриптовые языки с развесистыми стандартными и не очень библиотеками.
> программами, или частями программы.
А как же сетевая прозрачность?
> Замечу: что COM/ActiveX/ODBC и т.д. - это фактически стандартизация общения отдельных частей одной программы
В рамках unix way это решается другими способами.
Программа разбивается на части, каждая из которых делает только одно дело, но делает его хорошо.
Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
Если декомпозиция выполнена правильно, то пользователь может менять схему взаимодействия частей без знания их внутреннего устройства, разобравшись только с протоколом. В этом ему помогают развитые скриптовые языки с развесистыми стандартными и не очень библиотеками.
Я сейчас посмотрел Рихтера, раздел Memory Management. Слова под Win98 этого нет встречаются довольно часто (это не связано с защитой). Кроме того, я помню, что под Win98 shared memory устроена иначе, но не помню, правда, как это отражается в API.
> но никакие стандарты не помогут мне заставить браузер вызвать для набора этого сообщения нормальный редактор вместо того отстоя, в котором я это набираю, если разработчики не оставили хук для этого дела, и если в исходниках не найти места, куда этот хук вставить
AFAIK, разработка более высокоуровневых стандартов, разработка кирпичиков поддерживающих различные части этих стандартов - это более прогрессивный путь, чем публикация исходников.
Допустим тебе доступны исходники browser-а и ты нашел куда вставить хук, и что дальше?
Вышла новая версия browser-а, в который этот участок кода был изменен. Появился другой браузер и т.д.
Ты каждый раз будешь заново разбиратся в исходниках?
AFAIK, разработка более высокоуровневых стандартов, разработка кирпичиков поддерживающих различные части этих стандартов - это более прогрессивный путь, чем публикация исходников.
Допустим тебе доступны исходники browser-а и ты нашел куда вставить хук, и что дальше?
Вышла новая версия browser-а, в который этот участок кода был изменен. Появился другой браузер и т.д.
Ты каждый раз будешь заново разбиратся в исходниках?
> Допустим тебе доступны исходники browser-а и ты нашел куда вставить хук, и что дальше?
Дальше я высылаю патч, аргументирую полезность такой фичи, авторы говорят, что надо переделать, так как их дизайн предусматривает вот такой удобный способ заведения таких хуков, я переделываю, в следующем релизе этот хук на месте.
Дальше я высылаю патч, аргументирую полезность такой фичи, авторы говорят, что надо переделать, так как их дизайн предусматривает вот такой удобный способ заведения таких хуков, я переделываю, в следующем релизе этот хук на месте.
Найти кусочек API, который не совместим можно, не вопрос. Но очень значительная часть API совместима. Под unix этого не было, нет, и вряд ли появится. Потому что unix way - это не стандартизация API, а написание программ, которые делают маленькие кусочки.
Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
Недостаткам такого подхода посвящено страниц 20 в Unix Haters Handbook. В двух словах: недостатков все же больше, чем преимуществ.
>то есть через несколько слоёв менеджеров и маркетоидов
>в случае свободного ПО этой пропасти нет
Вряд ли это связано с свободным или платным распространением ПО. Размер исходного кода виндов сразу отобьет желание вносить туда какие попало изменения. Чем больше размер кода, тем больше менеджмента - это неизбежно.
Это связано не с вопросом цены, а с вопросом отрытости. Free software <> Freeware. Исходных кодов в любом универсальном дистибутиве Linux не меньше, чем в Windows, однако разработка всех этих кодов рассредоточена в пространстве и более прозрачна, в то время как в MS она скрыта от глаз внешнего пользователя. Это не значит, что разработка свободного ПО вообще не управляется, см. например статью Петра Новодворского Конституционная анархия Debian.
UHH читал, неубедительно
Дальше я высылаю патч, аргументирую полезность такой фичи, авторы говорят, что надо переделать, так как их дизайн предусматривает вот такой удобный способ заведения таких хуков, я переделываю, в следующем релизе этот хук на месте.
Ты часто так делал? Я сталкивался с ситуациями, когда автор разработки (речь идет о rpmlib, конкретно могу ковырнуть, что же он там не хотел вносить) категорически отказывается вносить патч, необходимость которого подтверждает не один, а сразу несколько десятков пользователей. В общем, та же картина что и с продвижением через менеджеров, только вид сбоку.
В таком случае остаётся возможность поддерживать свои модификации за свой счёт.
В случае собственнического софта всё примерно так же, за исключением этой возможности.
Да и если слоёв менеджеров больше, то любой из них может оказаться отморозком, и тогда всё, приехали.
А так ты общаешься напрямую с самыми компетентными людьми. Если находятся более компетентные, они могут отфорковать свою ветку, как это недавно с зеброй произошло, вроде бы очень успешно.
В случае собственнического софта всё примерно так же, за исключением этой возможности.
Да и если слоёв менеджеров больше, то любой из них может оказаться отморозком, и тогда всё, приехали.
А так ты общаешься напрямую с самыми компетентными людьми. Если находятся более компетентные, они могут отфорковать свою ветку, как это недавно с зеброй произошло, вроде бы очень успешно.
> COM пришел на смену DDE (если не ошибаюсь).
Ошибаешься, DDE - это технология обмена данными между приложениями. COM - это базовая технология взаимодействия программ, написанными разными производителями.
Сначала был DDE.
Потом появился COM, как базовая технология.
Так же появился DCOM, как развитие COM-а на межкомпьютерное взаимодействие.
На основе COM-а был сделан OLE, как замена DDE.
Так же на основе COM-а был сделан ActiveX.
Т.е. сначала был ряд разнородных API: DDE, ODBC, WIn Api.
Далее появился COM/DCOM, как базовая технология.
Далее на эту базу были перенесены все существующие API.
Можно заметить, что большая часть WinApi, появившееся после появления COm/DCom-а, построена по тем же принципам.
С .Net-ом ситуация повторяется.
Появился новый фундамент. И все api переносятся на этот новый фундамент.
Ошибаешься, DDE - это технология обмена данными между приложениями. COM - это базовая технология взаимодействия программ, написанными разными производителями.
Сначала был DDE.
Потом появился COM, как базовая технология.
Так же появился DCOM, как развитие COM-а на межкомпьютерное взаимодействие.
На основе COM-а был сделан OLE, как замена DDE.
Так же на основе COM-а был сделан ActiveX.
Т.е. сначала был ряд разнородных API: DDE, ODBC, WIn Api.
Далее появился COM/DCOM, как базовая технология.
Далее на эту базу были перенесены все существующие API.
Можно заметить, что большая часть WinApi, появившееся после появления COm/DCom-а, построена по тем же принципам.
С .Net-ом ситуация повторяется.
Появился новый фундамент. И все api переносятся на этот новый фундамент.
> сомневаюсь что ты не слышал про exe-сервера...
Ну, и?
Com, как раз позволяет считать, что, например, база данных является частью программы, и не думать о том, что это отдельный процесс.
Взять тот же OLE, там все тоже самое. Встраиваемая программа может запускаться, как внутри нас, так и отдельным процессом, так и на другом компе. но это опять не важно.
Ну, и?
Com, как раз позволяет считать, что, например, база данных является частью программы, и не думать о том, что это отдельный процесс.
Взять тот же OLE, там все тоже самое. Встраиваемая программа может запускаться, как внутри нас, так и отдельным процессом, так и на другом компе. но это опять не важно.
> Ну если сначала сделали плохо, то, конечно, нужно менять. Но можно сразу сделать хорошо.
Месье, идеалист? или господь бог? и ты всегда сразу выдаешь наилучшее решение?
ps
Тем более есть большая вероятность, что на то время, сильно лучше сделать было нельзя.
Месье, идеалист? или господь бог? и ты всегда сразу выдаешь наилучшее решение?
ps
Тем более есть большая вероятность, что на то время, сильно лучше сделать было нельзя.
> В рамках unix way это решается другими способами.
> Программа разбивается на части, каждая из которых делает только одно дело, но делает его хорошо.
> Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
> Если декомпозиция выполнена правильно, то пользователь может менять схему взаимодействия частей без знания их внутреннего устройства, разобравшись только с протоколом. В этом ему помогают развитые скриптовые языки с развесистыми стандартными и не очень библиотеками.
Решение получается очень тяжелым, не видно простоты.
Самое главное, что очень сложно сделать нулевую заглушку. т.е. если даже мы общаемся сами с собой, то все равно нам придется поднимать сокеты, генерить команды, парсить команды и т.д.
На уровне одной программы - слишком глобально, и в то же время слишком низкоуровнево.
ИМХО, в Com-е взаимодействие сделано попроще.
Декларируется ООП-API, а как будет решена проблема транспорта, оставлена на совести окружения.
И уже в реализации - это может быть прямой вызов, может быть shared memory, могут быть socket-ы.
ps
Вот это намного проще выглядит
чем
> Программа разбивается на части, каждая из которых делает только одно дело, но делает его хорошо.
> Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
> Если декомпозиция выполнена правильно, то пользователь может менять схему взаимодействия частей без знания их внутреннего устройства, разобравшись только с протоколом. В этом ему помогают развитые скриптовые языки с развесистыми стандартными и не очень библиотеками.
Решение получается очень тяжелым, не видно простоты.
Самое главное, что очень сложно сделать нулевую заглушку. т.е. если даже мы общаемся сами с собой, то все равно нам придется поднимать сокеты, генерить команды, парсить команды и т.д.
На уровне одной программы - слишком глобально, и в то же время слишком низкоуровнево.
ИМХО, в Com-е взаимодействие сделано попроще.
Декларируется ООП-API, а как будет решена проблема транспорта, оставлена на совести окружения.
И уже в реализации - это может быть прямой вызов, может быть shared memory, могут быть socket-ы.
ps
Вот это намного проще выглядит
class Server
{
void Execute;
}
class Client
{
static void Main
{
server = GetServer;
server->Execute;
}
}
чем
class Server
{
static void Main
{
Socket socket = new Socket;
socket->Listen;
while (socket->Read
{
switch (socket->ReadCommand
case "Execute":
result = this->Execute;
socket->Write(result);
}
}
}
class Client
{
static void Main
{
Socket socket = new Socket;
socket->Connect;
socket->Write("Server.Execute");
result = socket->Read;
}
}
Тем более есть большая вероятность, что на то время, сильно лучше сделать было нельзя.
Под Linux нет такой чехарды технологий. Книгу, выпущенную 10 лет назад, можно читать и сейчас, покажи мне такую книгу для Windows.
Кстати, программисткие книги для Windows достойны отдельного обсуждения. Почему их так много по сравнению с юниксовыми?
ИМХО, в Com-е взаимодействие сделано попроще.
Не вводи в заблуждение тех, кто не знаком с этим монстром
То, что ты написал, выглядит просто, только вот реальная программа на чистом COM API будет выглядеть совсем иначе, раз так в 100 сложнее. Только ATL + import в С++ хоть как-то уменьшают сложность COM.Кроме того, межпроцессное взаимодействие в COM довольно медленное (а межмашинное еще медленней). Даже между тредами вызовы функций происходят не напрямую.
> А так ты общаешься напрямую с самыми компетентными людьми. Если находятся более компетентные, они могут отфорковать свою ветку, как это недавно с зеброй произошло, вроде бы очень успешно.
Вот это и есть нарушение инкапсуляции, т.е. опять же нет людей, которые заинтересованы в создании некоего стандартного API, в создании более высокоуровневого общего фундамента.
Каждому отдельному разработчику-пользователю проще напрямую внести изменения в исходники, чем общатся и приходить к компромиссу с разработчиком системы.
ps
Можно провести аналогию между программированием и математикой.
Сналача была арифметика, потом появился более высокоуровневый стандарт - алгебра, потом - матан (коряво, но надеюсь идея понятна)
И при доказательстве каждой новой теоремы можно не начинать все с начала и доказывать начиная с 2+2, а можно использовать стандартизованные кирпичики (теоремы).
Вот это и есть нарушение инкапсуляции, т.е. опять же нет людей, которые заинтересованы в создании некоего стандартного API, в создании более высокоуровневого общего фундамента.
Каждому отдельному разработчику-пользователю проще напрямую внести изменения в исходники, чем общатся и приходить к компромиссу с разработчиком системы.
ps
Можно провести аналогию между программированием и математикой.
Сналача была арифметика, потом появился более высокоуровневый стандарт - алгебра, потом - матан (коряво, но надеюсь идея понятна)
И при доказательстве каждой новой теоремы можно не начинать все с начала и доказывать начиная с 2+2, а можно использовать стандартизованные кирпичики (теоремы).
Это же RPC просто, а для него есть отдельные средства, я упоминал.
Ничего не могу сказать про их удобство, не разбирался, мне это не интересно.
А теперь если ты добавишь в свой код обработку ошибок, то разница станет незаметна.
А когда нужна надёжность, обработку ошибок нужно вставлять сразу, хоть нулевая заглушка, хоть минус первая. Иначе заломает потом.
У меня есть несколько success stories использования unix way.
Это дико приятно, именно для программирующего пользователя, возможно не для профессионального разработчика, для которого пару страниц тяжёлого С++ накатать - не более 10 минут времени.
Поэтому человек с весьма скромным опытом программирования может большие дела сделать.
Вот кусок из реальной программы:
Под FreeBSD это читает как из обычного файла (очень удобно для отладки, вот тебе и заглушка так и из AF_UNIX-сокета.
Буду портировать под Linux - /bin/cat заменю на специально уже написанную программу unixclient (на С, тоже очень простая, показать исходник?)
можно будет добавить вызов stat, чтобы понять, файл это или сокет, и сохранить возможность отладки
Заметь - вполне адекватная задаче обработка ошибок уже есть.
Ничего не могу сказать про их удобство, не разбирался, мне это не интересно.
А теперь если ты добавишь в свой код обработку ошибок, то разница станет незаметна.
А когда нужна надёжность, обработку ошибок нужно вставлять сразу, хоть нулевая заглушка, хоть минус первая. Иначе заломает потом.
У меня есть несколько success stories использования unix way.
Это дико приятно, именно для программирующего пользователя, возможно не для профессионального разработчика, для которого пару страниц тяжёлого С++ накатать - не более 10 минут времени.
Поэтому человек с весьма скромным опытом программирования может большие дела сделать.
Вот кусок из реальной программы:
sub fetch_flows_file ($) {
my @flows = ;
my $fname = shift;
unless (open FILE, "/bin/cat $fname|") {
warn "Could not open file $fname: $!";
return @flows;
}
@flows = <FILE>;
close FILE;
foreach (@flows) { chomp; }
return @flows;
}
Под FreeBSD это читает как из обычного файла (очень удобно для отладки, вот тебе и заглушка так и из AF_UNIX-сокета.
Буду портировать под Linux - /bin/cat заменю на специально уже написанную программу unixclient (на С, тоже очень простая, показать исходник?)
можно будет добавить вызов stat, чтобы понять, файл это или сокет, и сохранить возможность отладки
Заметь - вполне адекватная задаче обработка ошибок уже есть.
> Кстати, программисткие книги для Windows достойны отдельного обсуждения. Почему их так много по сравнению с юниксовыми?
Например, потому что про unix писать нечего, про posix давным давно все уже написано, а ничего нового не появилось.
Шутка, конечно, но доля правды есть.
Например, потому что про unix писать нечего, про posix давным давно все уже написано, а ничего нового не появилось.
Шутка, конечно, но доля правды есть.
> Каждому отдельному разработчику-пользователю проще напрямую внести изменения в исходники, чем общатся и
> приходить к компромиссу с разработчиком системы.
Ты выступаешь за технические ограничения, которые будут заставлять приходить к компромиссу даже с полными отморозками, с которыми у тебя нет никаких общих интересов?
> приходить к компромиссу с разработчиком системы.
Ты выступаешь за технические ограничения, которые будут заставлять приходить к компромиссу даже с полными отморозками, с которыми у тебя нет никаких общих интересов?
В рамках unix way это решается другими способами.
Программа разбивается на части, каждая из которых делает только одно дело, но делает его хорошо.
Общение между частями осуществляется с помощью простого протокола (обычно это текстовый протокол, который ходит через пайп или сокет).
Да, и это - просто, доступно, надежно и удобно.
Уже выше произносились слова про "программирующего пользователя". Я сейчас выступаю в роли программирующего пользователя/системного администратора, именно такого рода деятельностью я занимаюсь в последнее время. В моем распоряжении есть стандартные компоненты, например, ssh для удаленного исполнения команд, mail для отправки почты, lpr для печати. Они взаимодействуют между собой через pipes. И все это я легко натягиваю на один скелет, созданный в bash или perl.
Мне нужно удаленно выполнить команду на множестве компьютеров? Легко: bash+ssh.
Мне нужно установить и распечатать пароли для сотни пользователей? Легко: perl + passwd + lpr.
Мне нужно отправить сотне пользователей сообщения, возможно, с немного модифицированным содержанием? Легко: perl+mail.
Смогу ли я решить столь же просто аналогичные задачи под Windows?
Мне кажется, что продвинутому (программирующему) пользователю под *nix жить гораздо легче.
> Не вводи в заблуждение тех, кто не знаком с этим монстром
У меня крепнет ощущение, что ты плохо знаком с COM-ом.
> То, что ты написал, выглядит просто, только вот реальная программа на чистом COM API будет выглядеть совсем иначе, раз так в 100 сложнее. Только ATL + import в С++ хоть как-то уменьшают сложность COM.
С использованием ATL, или похожей своей либой код, будет выглядит именно так.
С использованием голого COM-а будет страшнее, но до сокетов все равно далеко.
> Кроме того, межпроцессное взаимодействие в COM довольно медленное
Медленнее, чем что?
Вроде бы логично, что вызов между процессами должен быть медленнее, чем прямой вызов.
Замечу, что в COM-е межпроцессные вызовы работают быстрее, чем вызовы построенные на socket-ах.
> (а межмашинное еще медленней).
вроде тоже логично.
> Даже между тредами вызовы функций происходят не напрямую.
Как настроишь, так и будет. Если хочешь, чтобы треды синхронизировались самой системой, то да - вызовы будут идти не напрямую.
Если будешь синхронизацию обеспечивать сам, то вызовы будут идти напрямую.
У меня крепнет ощущение, что ты плохо знаком с COM-ом.
> То, что ты написал, выглядит просто, только вот реальная программа на чистом COM API будет выглядеть совсем иначе, раз так в 100 сложнее. Только ATL + import в С++ хоть как-то уменьшают сложность COM.
С использованием ATL, или похожей своей либой код, будет выглядит именно так.
С использованием голого COM-а будет страшнее, но до сокетов все равно далеко.
> Кроме того, межпроцессное взаимодействие в COM довольно медленное
Медленнее, чем что?
Вроде бы логично, что вызов между процессами должен быть медленнее, чем прямой вызов.
Замечу, что в COM-е межпроцессные вызовы работают быстрее, чем вызовы построенные на socket-ах.
> (а межмашинное еще медленней).
вроде тоже логично.
> Даже между тредами вызовы функций происходят не напрямую.
Как настроишь, так и будет. Если хочешь, чтобы треды синхронизировались самой системой, то да - вызовы будут идти не напрямую.
Если будешь синхронизацию обеспечивать сам, то вызовы будут идти напрямую.
> А теперь если ты добавишь в свой код обработку ошибок, то разница станет незаметна.
Вот код с обработкой ошибок:
Вот код с обработкой ошибок:
class Server
{
void Execute;
}
class Client
{
void Main
{
try
{
Server server = GetServer;
server->Execute;
}
catch (exception exc)
{
cout << "fatal error" << exc.message;
}
}
}
> Ты выступаешь за технические ограничения, которые будут заставлять приходить к компромиссу даже с полными отморозками, с которыми у тебя нет никаких общих интересов?
Я только хочу сказать, что более жизнеспособным выглядит тот подход, в котором люди хоть иногда вынуждены разговаривать между собой и придумать более высокоуровневые стандарты.
Я только хочу сказать, что более жизнеспособным выглядит тот подход, в котором люди хоть иногда вынуждены разговаривать между собой и придумать более высокоуровневые стандарты.
Ты хочешь кого-то вынудить, в то время как практика показывает, что стандарты неплохо создаются в результате свободного выбора людей.
То что на данный момент, программисты выбили себе привилегию "as is", этих самых программистов не оправдывает.
ps
Проведу аналогию.
Если ты на улице детям раздаешь мороженное бесплатно, это не значит, что ты не обязан гарантировать качество этого мороженного.
С программами все тоже самое.
Аналогия трещит по швам. Никому разработчик свой код не всучивает. Вот правильная аналогия:
Автор художественной литературы пишет то, что взбредет в его больную голову - кто хочет, тот читает,
Хозяин порносайта выкладывает сколь угодно извращенный контент - кому нравится, то смотрит.
Программист пишет, что ему хочется - кому нравится пользуется.
Так что от AS IS - руки прочь.
> Автор художественной литературы пишет то, что взбредет в его больную голову - кто хочет, тот читает,
> Хозяин порносайта выкладывает сколь угодно извращенный контент - кому нравится, то смотрит.
Законодатели не стесняются ограничивать это.
> Программист пишет, что ему хочется - кому нравится пользуется.
И до него доберутся.
> Хозяин порносайта выкладывает сколь угодно извращенный контент - кому нравится, то смотрит.
Законодатели не стесняются ограничивать это.
> Программист пишет, что ему хочется - кому нравится пользуется.
И до него доберутся.
Это все старые задачи, им уже лет 30, ясно что за это время они вылизаны до блеска.
А что будет, если надо например отправить сообщения через icq-у или отправить sms-сообщения?
Вытащить список цен из оракла и положить в 1C (программу учета финансов)?
Вытащить список клиентов из 1С и положить в адрессную книгу почтового клиента?
А что будет, если надо например отправить сообщения через icq-у или отправить sms-сообщения?
Вытащить список цен из оракла и положить в 1C (программу учета финансов)?
Вытащить список клиентов из 1С и положить в адрессную книгу почтового клиента?
Да, и это - просто, доступно, надежно и удобно.
...И очень несовместимо. А так - ничего.
В результате один и тот же инструмент переписывается по десять раз и существует в разных совершенно несовместимых вариантах. Примеры нужны?
> А что будет, если надо например отправить сообщения через icq-у или отправить sms-сообщения?
В CPAN есть такое уже, я думаю.
Даже несмотря на некоторые закрытые протоколы.
> Вытащить список цен из оракла и положить в 1C (программу учета финансов)?
> Вытащить список клиентов из 1С и положить в адрессную книгу почтового клиента?
Это собственнические программы, может и не найтись хороших средств.
В CPAN есть такое уже, я думаю.
Даже несмотря на некоторые закрытые протоколы.
> Вытащить список цен из оракла и положить в 1C (программу учета финансов)?
> Вытащить список клиентов из 1С и положить в адрессную книгу почтового клиента?
Это собственнические программы, может и не найтись хороших средств.
Могу замететь, что Open Office - это ответный удар на MS Office, Mozilla - ответный удар на explorer, Т.е. идет постоянное запаздывание...
Не нужно быть гением, что догадаться, что до появления MS Office Open Office никому не был нужен. Более того, его невозможно было бы создать, потому что заранее неизвестно, что создаст MS. Просто идет война за стандарты. В некоторых областях MS удается их диктовать.
Для успешного продолжения Holy War замечу, где появились раньше понятия разграничения прав, многопроцессорность, многопользовательность, нормальная файловая система, пакетные фильтры и TCP/IP вообще. Т.е. идет постоянное запаздывание...
Опыт показывает, что стандарты появляются только тогда, когда задача не может быть выполнена в одиночку.
Например, стандартизованы почти все клиент-серверные взаимодействия, потому что часто клиента пишут другие разработчики, чем сервер.
Например, стандартизованы почти все клиент-серверные взаимодействия, потому что часто клиента пишут другие разработчики, чем сервер.
где появились раньше понятия разграничения прав, многопроцессорность, многопользовательность, нормальная файловая система, пакетные фильтры и TCP/IP вообще. Т.е. идет постоянное запаздывание...
Да, я с тобой полностью согласен. Действительно, unix сильно опаздывает и до сих пор не реализовывает это все в полной мере. Появились они на Multics, VMS, LispMachine, OS/MVT, OS/MFT, OS/360...
[Holy peace now!]
Возможно, они не нужны с точки зрения философии разработчиков. Но я как пользователь хочу иметь удобный Clipboard. Который будет работать не только с теми программами, которые я купил/скачал у тебя, но и с программами, которые я купил/скачал у Васи. А ты как разработчик не сумеешь под X это сделать хотя бы потому, что там это не предусмотрено в концепции системы.Не побоюсь сморозить чушь, но имхо Clipboard, который Вы обсуждаете это OLE. Это не может быть продумано в концепции X потому что это другой, более высокий уровень. Но спорить не буду, OLE под unix отсутствует в таком классном виде как под виндой.
> В результате один и тот же инструмент переписывается по десять раз и существует в разных совершенно несовместимых
> вариантах.
А вот это - непонимание главной мазы Open Source.
Ничего страшного!
Если кому-то нужны десять вариантов, они есть.
Понадобиться мне одинадцатый - и сделаю, и какой монополист мне не помешает.
Ты не платишь ни за один из них, можешь установить все и не мучаться.
Это в случае собственнической модели такое дублирование усилий плохо - так как на каждый вариант нужны разработчики, которым нужно платить. А тут модификации возникают по желанию пользователей. Если бы программа была закрытой, эти усилия пользователей были бы потрачены на борьбу с их ограничениями и на упрашивания компании-монополиста смиловаться и добавить нужные возможности.
Поэтому например Линус в ряде случаев может выбирать из нескольких реализаций одной и той же возможности, именно поэтому может с ядром идти три драйвера для одной и той же железки - это не есть пустая трата усилий, как было бы, если бы их авторы были бы сотрудниками одной компании. Так же и спекулятивное исполнение в современных процессорах не является напрасной тратой времени, а приводит к повышению производительности.
Потому что это не сотрудники, которым надо платить, а люди, преследующие свои интересы.
> вариантах.
А вот это - непонимание главной мазы Open Source.
Ничего страшного!
Если кому-то нужны десять вариантов, они есть.
Понадобиться мне одинадцатый - и сделаю, и какой монополист мне не помешает.
Ты не платишь ни за один из них, можешь установить все и не мучаться.
Это в случае собственнической модели такое дублирование усилий плохо - так как на каждый вариант нужны разработчики, которым нужно платить. А тут модификации возникают по желанию пользователей. Если бы программа была закрытой, эти усилия пользователей были бы потрачены на борьбу с их ограничениями и на упрашивания компании-монополиста смиловаться и добавить нужные возможности.
Поэтому например Линус в ряде случаев может выбирать из нескольких реализаций одной и той же возможности, именно поэтому может с ядром идти три драйвера для одной и той же железки - это не есть пустая трата усилий, как было бы, если бы их авторы были бы сотрудниками одной компании. Так же и спекулятивное исполнение в современных процессорах не является напрасной тратой времени, а приводит к повышению производительности.
Потому что это не сотрудники, которым надо платить, а люди, преследующие свои интересы.
> разграничения прав, многопроцессорность, многопользовательность, нормальная файловая система, пакетные фильтры и TCP/IP вообще
Это все было чуть ли не в posix-е.
А что нового появилось за последние 10 лет? 5 лет?
ps
Как, например, в linux-е обеспечить транзакционость на уровне различных приложений? Как написать свое приложение, которое встраивалось бы в общий механизм транзакционности?
Это все было чуть ли не в posix-е.
А что нового появилось за последние 10 лет? 5 лет?
ps
Как, например, в linux-е обеспечить транзакционость на уровне различных приложений? Как написать свое приложение, которое встраивалось бы в общий механизм транзакционности?
Не побоюсь сморозить чушь, но имхо Clipboard, который Вы обсуждаете это OLE.
Ты сморозил чушь.
Почитай Win32 SDK, функции GetClipboardFormatName, IsClipboardFormatAvailable, GetClipboardOwner, GetClipboardData.
Никакого отношения к OLE не имеют.
Все зависит от размеров меня, и размеров компании. Если размеры примерно равны, размер заказа достаточно интересен для компании-разработчика, то контакты довольно быстро налаживаются. И компания разработчик довольно сильно идет навстречу.Чушь. Ниже пример из жизни. Взято из личной переписки. Речь идет о том, что большая компания накупившая добра от MS начала жаловаться и даже слать грамотные bug reports. Было найдено 5 ошибок, но они пофикшены только для этой компании. MS даже не планирует их фиксить в следующих сервис паках,
На ряд developer-ских продуктов Microsoft-а можно было повлиять на этапе beta-ы, т.к. есть возможность наладить хорошие отношения с российским отделением Microsoft-а, а у них есть небольшие рычаги давления на сам microsoft.
.... У нас (через саппорт клиента)
было открыто 5 case в Микрософте по поводу их саппликанта. Они их
даже через 3 месяца пофиксили. Но это типа секретные специально для
клиента патчи . Официально все пофиксено (как минимум 3 бага из 5)
в SP2 for WinXP or SP1 for Win2003 server. Могу подробности изложить -
но писать мне лень ;-) при личной встрече /по телефону..
То есть, виндовый саппликант глючит страшно, причем он не делает ПРИНЦИПИАЛЬНЫХ
вещей в результате этих багов.
А так 802.1x штука хорошая. У вас, btw, AD or NT4 domain? Первый
случай работает, а во втором - есть еще проблемы.
....
> А вот это - непонимание главной мазы Open Source.
> Ничего страшного!
> Если кому-то нужны десять вариантов, они есть.
Но если мне нужен ОДИН РАБОТАЮЩИЙ ПРАВИЛЬНО ВАРИАНТ, то я его скорее всего не найду. У всех десяти будут те или иные недостатки, именно поэтому их и появилось десять.
> Понадобиться мне одинадцатый - и сделаю, и какой монополист мне не помешает.
И обязательно сделаю, потому что те десять делают не совсем то что мне нужно, или глючат. И сделаю одиннадцатый, который будет глючить тоже, но к счастью не в тех ситуациях, в которых я его использую сам.
> Ты не платишь ни за один из них, можешь установить все и не мучаться.
... Потому что будешь заранее знать: ни один из них не работает на 100%.
Unix Way - это такая молитва и религия, предлагаю оставить обсуждение Unix Way.
> Ничего страшного!
> Если кому-то нужны десять вариантов, они есть.
Но если мне нужен ОДИН РАБОТАЮЩИЙ ПРАВИЛЬНО ВАРИАНТ, то я его скорее всего не найду. У всех десяти будут те или иные недостатки, именно поэтому их и появилось десять.
> Понадобиться мне одинадцатый - и сделаю, и какой монополист мне не помешает.
И обязательно сделаю, потому что те десять делают не совсем то что мне нужно, или глючат. И сделаю одиннадцатый, который будет глючить тоже, но к счастью не в тех ситуациях, в которых я его использую сам.
> Ты не платишь ни за один из них, можешь установить все и не мучаться.
... Потому что будешь заранее знать: ни один из них не работает на 100%.
Unix Way - это такая молитва и религия, предлагаю оставить обсуждение Unix Way.
> GetClipboardFormatName, IsClipboardFormatAvailable, GetClipboardOwner, GetClipboardData.
насколько я понимаю, самое важное отличие этого от средств X11 - наличие нескольких предопределённых форматов, кроме текста
поэтому можно картинки передавать и ещё что-то
а в X тоже можно, но только если разработчики программ договорилсь как-нибудь, в каком формате это делать и как его назвать
насколько я понимаю, самое важное отличие этого от средств X11 - наличие нескольких предопределённых форматов, кроме текста
поэтому можно картинки передавать и ещё что-то
а в X тоже можно, но только если разработчики программ договорилсь как-нибудь, в каком формате это делать и как его назвать
Это все старые задачи, им уже лет 30, ясно что за это время они вылизаны до блеска.
1. ICQ, Oracle, 1С - закрытые продукты. Их разработчики не предусмотрели совместимость с POSIX, поэтому у меня и не возникает желания иметь с ними дело, потому что мне (не занимающемуся сейчас профессионально программированиям) будет тяжело с ними работать, осваивать новые сложные технологии ради этого я не буду. На основе открытых продуктов такие вещи строить проще: если взять Jabber, построенный на xml-протоколе и открытую СУБД (пусть менее мощную, чем Oracle, но вся мощь Oracle нужна далеко не всем). Но здесь я уже могу ошибаться, ибо не специалист.
2. То, что этим задачам по 30 лет не означает, что они неактуальны. Наоборот, это означает их широкую распространенность. Я взял эти задачи из своей практики. Необходимости работать с ICQ, Оракл, 1С у меня не возникало.
3. Я задал вопрос про простоту решения этих задач под Windows. Ответа я не получил.
Потому что unix way - это не стандартизация API, а написание программ, которые делают маленькие кусочки.
А SuS для кого писан?
На тему стандартного API: ты нашел хук для обработки DHCP ответов или сниффер писал?
> Но если мне нужен ОДИН РАБОТАЮЩИЙ ПРАВИЛЬНО ВАРИАНТ, то я его скорее всего не найду.
Ты пробовал? Обычно есть несколько, которые работают, каждый по-своему правильно.
Например, ты считаешь неправильным bash? или pdksh? или zsh? или tcsh?
В случае собственнического софта ты бы заплатил $$$ за него, а потом бы решал, что делать с отсутствием 1% нужной тебе фунциональности.
В случае Open Source ты выбираешь наиболее близкий к нужному тебе вариант, дописываешь нужный 1% и с хорошей вероятностью пропихиваешь его в mainstream.
Ты пробовал? Обычно есть несколько, которые работают, каждый по-своему правильно.
Например, ты считаешь неправильным bash? или pdksh? или zsh? или tcsh?
В случае собственнического софта ты бы заплатил $$$ за него, а потом бы решал, что делать с отсутствием 1% нужной тебе фунциональности.
В случае Open Source ты выбираешь наиболее близкий к нужному тебе вариант, дописываешь нужный 1% и с хорошей вероятностью пропихиваешь его в mainstream.
Во-первых, если уж тебя отослали к документации по API, которым ты не пользовался, и о котором ты не знаешь, то лучше бы ты прочитал эту документацию, или хотя бы просмотрел. Если бы ты почитал документацию, то ты бы наверное нашел ссылку еще на такую функцию:
RegisterClipboardFormat
Из описания: "The RegisterClipboardFormat function registers a new clipboard format. This format can then be used as a valid clipboard format."
Кроме того, если уж на то пошло, "несколько" предопределенных форматов в данном случае это не так уж мало, и не так уж несколько, их всего-то 24 штуки. Кроме того, в clipboard допустимо существование данных, экспорт которых ИЗ Clipboard может производиться не в том формате, в котором они туда поступили, причем через правильные функции преобразования форматов, API для которых стандартен.
Короче, прежде чем дальше рассуждать про Windows Clipboard, почитайте для начала что же он из себя представляет
RegisterClipboardFormat
Из описания: "The RegisterClipboardFormat function registers a new clipboard format. This format can then be used as a valid clipboard format."
Кроме того, если уж на то пошло, "несколько" предопределенных форматов в данном случае это не так уж мало, и не так уж несколько, их всего-то 24 штуки. Кроме того, в clipboard допустимо существование данных, экспорт которых ИЗ Clipboard может производиться не в том формате, в котором они туда поступили, причем через правильные функции преобразования форматов, API для которых стандартен.
Короче, прежде чем дальше рассуждать про Windows Clipboard, почитайте для начала что же он из себя представляет
А что нового появилось за последние 10 лет? 5 лет?
А зачем что-то новое, если старое работает нормально. И даже Микрософт забеспокоилась по поводу Линукса. Получается, что Микрософт бегала по кругу, изобретая технологию за технологией, раз так и не убежала от тех, что "стоял на месте".
psТак появляются поколения программистов, которые не понимают что скрывается под Execute.
Вот это намного проще выглядит
...
Server->Execute;
....
> Кроме того, если уж на то пошло, "несколько" предопределенных форматов в данном случае это не так уж мало, и не так уж
> несколько, их всего-то 24 штуки.
Я не спорю, это реальный плюс.
Я читал про эти функции, но очень давно, ещё когда не знал ни про какие фрюниксы.
Вроде ничего не изменилось с тех пор.
> несколько, их всего-то 24 штуки.
Я не спорю, это реальный плюс.
Я читал про эти функции, но очень давно, ещё когда не знал ни про какие фрюниксы.
Вроде ничего не изменилось с тех пор.
На тему стандартного API: ты нашел хук для обработки DHCP ответов или сниффер писал?Нашел хук. Стандартный. Вернее, даже хука не понадобилось. Обращаю твое особое внимание, мне для этого даже не понадобилось искать исходники. Достаточно было прочитать нормальную документацию - кстати, еще одна вещь, которой страдает Unix Way: "source is the documentation". Или иными словами: "документацию нам писать лень, нам за это не платят, читайте исходники, и скажите спасибо, что нахаляву".
А теперь аналогичная задача тебе, только для isc-dhcp. Подругому задача называется "ищи-свищи".
Да, я с тобой полностью согласен. Действительно, unix сильно опаздывает и до сих пор не реализовывает это все в полной мере. Появились они на Multics, VMS, LispMachine, OS/MVT, OS/MFT, OS/360...Особенно TCP/IP и нормальная файловая система.
> разграничения прав, многопроцессорность, многопользовательность, нормальная файловая система, пакетные фильтры и TCP/IP вообщеМаленький ликбез - POSIX это не операционная система, а стандарт. Который был придуман тогда, когда юниксы проявили тенденцию к тому что бы отличаться друг от друга.
Это все было чуть ли не в posix-е.
А что нового появилось за последние 10 лет? 5 лет?
За последние 5-10 лет появилось дофига нового. Можешь почитать списки рассылки разработчиков Linux или *BSD. Появились вещи более фундаментальные чем Office.
прав
Clipboard сейчас реализован через OLE, а эти функции просто простая надстройка над Ole, оставленная для совместимости.
см. OleGetClipboard, интерфейс IDataObject и т.д.
Clipboard сейчас реализован через OLE, а эти функции просто простая надстройка над Ole, оставленная для совместимости.
см. OleGetClipboard, интерфейс IDataObject и т.д.
> А вот это - непонимание главной мазы Open Source.Надеюсь ты не утверждаешь, что в случае non open source единственный вариант обязательно окажется правильно работающим?
> Ничего страшного!
> Если кому-то нужны десять вариантов, они есть.
Но если мне нужен ОДИН РАБОТАЮЩИЙ ПРАВИЛЬНО ВАРИАНТ, то я его скорее всего не найду. У всех десяти будут те или иные недостатки, именно поэтому их и появилось десять.
> Как, например, в linux-е обеспечить транзакционость на уровне различных приложений? Как написать свое приложение,
> которое встраивалось бы в общий механизм транзакционности?
Уверен, что это действительно нужно?
Просто это похоже на сведение сложной задачи к очень сложной.
Как-то давно я слышал про такие вещи на основе CORBA.
Тогда это было сильно недоделано.
Сейчас не знаю, как. Если до сих пор не доделано, значит никому не нужно.
> которое встраивалось бы в общий механизм транзакционности?
Уверен, что это действительно нужно?
Просто это похоже на сведение сложной задачи к очень сложной.
Как-то давно я слышал про такие вещи на основе CORBA.
Тогда это было сильно недоделано.
Сейчас не знаю, как. Если до сих пор не доделано, значит никому не нужно.
Да, Глеб, особенно нормальная файлавая система, если уж на то пошло. Которой до сих пор нет на Unix. И не путай TCP/IP и Sockets. Последние появились на unix. А вот ARPANET изначально появился в 1969 году на Multics.
...И очень несовместимо. А так - ничего.
Ничего. Придумали pam. Я сделал авторизацию пользователей на основе ldap-сервера.
Но интерфейс команды passwd от этого не поменялся.
Clipboard сейчас реализован через OLE
Тссс, какая разница, какая у него внутренняя реализация, вызывающей программе от этого ни горячо ни холодно, это все потроха, которых она не видела, и которые на нее не влияют. Пусть его реализуют на X через что угодно, если смогут.
> Которой до сих пор нет на Unix.
Надеюсь, в качестве критериев нормальности не данные из Unix Haters' Handbook?
Вот это действительно Holy War, ставь себе предупреждение.
Надеюсь, в качестве критериев нормальности не данные из Unix Haters' Handbook?
Вот это действительно Holy War, ставь себе предупреждение.
Да, Глеб, особенно нормальная файлавая система, если уж на то пошло. Которой до сих пор нет на Unix. И не путай TCP/IP и Sockets. Последние появились на unix. А вот ARPANET изначально появился в 1969 году на Multics.Так, о какой такой нормальной файловой системе ты говоришь? Я говорю о UFS, которая появилась намного раньше NTFS. И моя интуиция подсказывает мне, что на реликтах которые ты перечислил не было файловой системы сравнимой с UFS.
Я не помню даты создания ARPANET, но в 1969 году не было IP. Не знаю на чем работала ARPANET. TCP/IP изначально появился в 4.2BSD и оттудова был передран всеми, за исключением linux.
Хорошо, ты хотел пример несовместимости? Держи.
Hello, class. Today we are going to learn to program in “sh.” The
“sh” shell is a simple, versatile program, but we'll start with a basic
example:
Print the types of all the files in a directory.
(I heard that remark in the back! Those of you who are a little familiar
with the shell and bored with this can write “start an X11 client on
a remote machine” for extra credit. In the mean time, shh!)
While we're learning to sh, of course we also want the program we
are writing to be robust, portable, and elegant. I assume you've all
read the appropriate manual pages, so the following should be trivially
obvious:
file *
Very nice, isn’t it? A simple solution for a simple problem; the *
matches all the files in the directory. Well, not quite. Files beginning
with a dot are assumed to be uninteresting, and * won’t match them.
There probably aren’t any, but since we do want to be robust, we’ll
use “ls” and pass a special flag:
for file in `ls -A`
do
file $file
done
There: elegant, robust... Oh dear, the “ls” on some systems doesn’t
take a “-A” flag. No problem, we'll pass -a instead and then weed out
the . and .. files:
for file in `ls -a`
do
if [ $file != . -a $file != .. ]
then
file $file
fi
done
Not quite as elegant, but at least it’s robust and portable. What’s that?
“ls -a” doesn’t work everywhere either? No problem, we'll use “ls -f”
instead. It’s faster, anyway. I hope all this is obvious from reading
the manual pages.
Hmm, perhaps not so robust after all. Unix file names can have any
character in them (except slash). A space in a filename will break this
script, since the shell will parse it as two file names. Well, that’s not
too hard to deal with. We'll just change the IFS to not include Space
(or Tab while we're at it and carefully quote (not too little, not too
much!) our variables, like this:
IFS='
'
for file in `ls -f`
do
if [ "$file" != . -a "$file" != .. ]
then
file "$file"
fi
done
Some of you alert people will have already noticed that we have
made the problem smaller, but we haven't eliminated it, because
Linefeed is also a legal character in a filename, and it is still in IFS.
Our script has lost some of its simplicity, so it is time to reevaluate
our approach. If we removed the “ls” then we wouldn’t have to worry
about parsing its output. What about
for file in .* *
do
if [ "$file" != . -a "$file" != .. ]
then
file "$file"
fi
done
Looks good. Handles dot files and files with nonprinting characters.
We keep adding more strangely named files to our test directory, and
this script continues to work. But then someone tries it on an empty
directory, and the * pattern produces “No such file.” But we can add
a check for that…
> 3. Я задал вопрос про простоту решения этих задач под Windows. Ответа я не получил.
Мне тяжело ответить на твои вопросы, я не админ.
Мне тяжело ответить на твои вопросы, я не админ.
Можно, ссылку на первоисточник текста?
Нашел хук. Стандартный. Вернее, даже хука не понадобилось. Обращаю твое особое внимание, мне для этого даже не понадобилось искать исходники. Достаточно было прочитать нормальную документацию - кстати, еще одна вещь, которой страдает Unix Way: "source is the documentation". Или иными словами: "документацию нам писать лень, нам за это не платят, читайте исходники, и скажите спасибо, что нахаляву".
Ну перед поиском ты не был уверен что его найдешь. И готов поспорить, что я найду такую задачу где не будет хука и придется писать снифер.
А теперь аналогичная задача тебе, только для isc-dhcp. Подругому задача называется "ищи-свищи".
Зато я однозначно знаю где искать. Найти нужное место в 98 Кб кода займет у меня намного меньше времени, чем блуждание по MSDN. И самое главное - я сейчас уверен, что это найду. И уверен, что нормально реализую эту задачу. Ты же не был уверен, пока не нашел.
А несовместимость тут чего с чем, если не секрет?
Это стандартные грабли, тщательно сохраняемые именно в целях совместимости.
Если не хочется их обходить, можно написать по-другому, возможно на другом языке.
Шелл при этом сохраняет актуальность для задач, которые не ведут к наступанию на эти грабли.
Это стандартные грабли, тщательно сохраняемые именно в целях совместимости.
Если не хочется их обходить, можно написать по-другому, возможно на другом языке.
Шелл при этом сохраняет актуальность для задач, которые не ведут к наступанию на эти грабли.
Критерии нормальности:
* гибкое разделение прав доступа
* поддержка многопоточных файлов
* поддержка типов файлов и другой метаинформации о файле.
* поддержка record-based operations на файлах.
* поддержка locking
В полной мере это все не риализовано не в одной из существующих сейчас файловых систем. Наиболее полно этим требованиям удовлетворяют NTFS и AFS.
* гибкое разделение прав доступа
* поддержка многопоточных файлов
* поддержка типов файлов и другой метаинформации о файле.
* поддержка record-based operations на файлах.
* поддержка locking
В полной мере это все не риализовано не в одной из существующих сейчас файловых систем. Наиболее полно этим требованиям удовлетворяют NTFS и AFS.
Тупой пример из UHH byМолодцы, выбрали для своего примера какой-то unix, где ls не соответствует POSIX. Я тоже могу написать программку под Win98, которая не заработает на w2k потому что писал её не под Win32 а под Win98.
Несовместимость тут команды ls от разных версий операционной системы друг с другом. ls под Linux и ls под FreeBSD работают совершенно по разному, не смотря на то, что претендуют на то, чтобы быть одним и тем же.
да, это holy war
> * поддержка типов файлов и другой метаинформации о файле.
> * поддержка record-based operations на файлах.
сходи с этим в linux-kernel, подвергнешься стандартной процедуре
тебя обработают люди, которые реально работали с такими системами, и наступили на соответствующие грабли
> * поддержка типов файлов и другой метаинформации о файле.
> * поддержка record-based operations на файлах.
сходи с этим в linux-kernel, подвергнешься стандартной процедуре
тебя обработают люди, которые реально работали с такими системами, и наступили на соответствующие грабли
Прикол как раз в том, что совместимость между unix'ами сразу же кончается, как только вылещаешь за рамки posix. И, к сожалению, уже GUI в posix'е никак не оговаривается.
* поддержка многопоточных файловНе вижу применимости.
* поддержка типов файлов и другой метаинформации о файле.Применимость весьма ограничена.
И не забудем про такую еще важную фичу, как
* скорость
Вот тут твоя любимая NTFS сливает воду.
В полной мере это все не риализовано не в одной из существующих сейчас файловых систем. Наиболее полно этим требованиям удовлетворяют NTFS и AFS.
Вернемся к теме спора. Я утверждаю что первая нормальная ФС появилась под *nix.
да, это holy warпо большому счету, это было holy war с самого первого поста в этом треде.
> Как-то давно я слышал про такие вещи на основе CORBA.
> Тогда это было сильно недоделано.
> Сейчас не знаю, как. Если до сих пор не доделано, значит никому не нужно.
Да. реально нужно, как только мы начинаем работать с разнородными источниками данных.
Как ты без транзакций собираешься решать задачу:
для каждого чела, который превысил объем трафика снять деньги со счета и зачислить на счет компании?
Здесь можно увидеть целых 4 разнородных источника данных:
биллинговая система
банковская система, в которой находятся деньги чела
банковская система, в которой находятся деньги компании
финансовая система компании.
> Если до сих пор не доделано, значит никому не нужно.
Либо реализация решения получилась настолько дорогим (т.к. пришлось стандартизовать много еще никак нестандартизованных вещей что оказалось никому не нужным.
> Тогда это было сильно недоделано.
> Сейчас не знаю, как. Если до сих пор не доделано, значит никому не нужно.
Да. реально нужно, как только мы начинаем работать с разнородными источниками данных.
Как ты без транзакций собираешься решать задачу:
для каждого чела, который превысил объем трафика снять деньги со счета и зачислить на счет компании?
Здесь можно увидеть целых 4 разнородных источника данных:
биллинговая система
банковская система, в которой находятся деньги чела
банковская система, в которой находятся деньги компании
финансовая система компании.
> Если до сих пор не доделано, значит никому не нужно.
Либо реализация решения получилась настолько дорогим (т.к. пришлось стандартизовать много еще никак нестандартизованных вещей что оказалось никому не нужным.
программы, претендующие на переносимость, в таком стиле не пишутся
а теперь посмотрим на windows
программу, написанную по рекомендациям msdn, вообще никуда не перенесёшь
а теперь посмотрим на windows
программу, написанную по рекомендациям msdn, вообще никуда не перенесёшь
Несовместимость тут команды ls от разных версий операционной системы друг с другом. ls под Linux и ls под FreeBSD работают совершенно по разному, не смотря на то, что претендуют на то, чтобы быть одним и тем же.
Во FreeBSD ls соответствует POSIX, и имеет дополнительные фичи. Если программист юзает эти фичи - ССБЗ.
У меня есть доступ только к Redhat, к сожалению на 6.2 ls не соответствует POSIX. Но я думаю это вопрос времени.
Да. реально нужно, как только мы начинаем работать с разнородными источниками данных.
Как ты без транзакций собираешься решать задачу:
для каждого чела, который превысил объем трафика снять деньги со счета и зачислить на счет компании?
Здесь можно увидеть целых 4 разнородных источника данных:
биллинговая система
банковская система, в которой находятся деньги чела
банковская система, в которой находятся деньги компании
финансовая система компании.
Извини, но это задача не OS, а базы данных.
Не вижу применимости.
Разработчики Apple Macintosh (который, кстати, заслуженно считается наиболее простым и удобным в пользовании компютером) нашли применимость.
Вернемся к теме спора. Я утверждаю что первая нормальная ФС появилась под *nix.
А я утверждаю, что это была "General-Purpose File System For Secondary Storage", которая появилась на Multics в 1965 году, когда Unix'а еще даже в проекте не было.
Извини, но это задача не OS, а базы данных.
А задача OS - предоставить для базы данных простые средства решения этой задачи. Чего под Unix нет.
> банковская система, в которой находятся деньги чела
> банковская система, в которой находятся деньги компании
наверное, тут всё зависит от стандартов, которым подчиняются эти банки
если нет общего стандарта, твой монитор транзакций не пустят туда
это специфическая область, я в ней не разбираюсь совсем
но вроде тут всё сводится к атомарному переводу денег из одного банка в другой, с получением квитанции
всё остальное примерно понятно как делать
> банковская система, в которой находятся деньги компании
наверное, тут всё зависит от стандартов, которым подчиняются эти банки
если нет общего стандарта, твой монитор транзакций не пустят туда
это специфическая область, я в ней не разбираюсь совсем
но вроде тут всё сводится к атомарному переводу денег из одного банка в другой, с получением квитанции
всё остальное примерно понятно как делать
> Извини, но это задача не OS, а базы данных
Может быть.
Но обеспечить простую работу с каждой из баз данных, а также обеспечить механизм транзакционности - это уже задача ОС.
Может быть.
Но обеспечить простую работу с каждой из баз данных, а также обеспечить механизм транзакционности - это уже задача ОС.
Это чисто прикладная задача.
Передо мной лежит книжка, называется "Открытые информационные системы".
В ней есть упоминания о международных стандартах в области банковских систем.
Я уверен, что никакой привязки к windows у этих стандартов нет, судя по дате их появления.
Теперь, нам нужно следовать тем же стандартам, которым следуют интересующие нас банки.
Если нам это удаётся, дальше просто.
Транзакции вообще - это сложно.
Конкретные транзакции, которые нам нужны - гораздо проще.
Я укрепился во мнении, что общий мезанизм для поддержки любых распределённых транзакций - это очень сложная задача, к которой ты предлагаешь сводить просто сложную задачу.
И всё равно нужно будет знать, как это работает на более низком уровне, иначе сглючит - и концов не найти.
Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open, я уверен, что все нужные стандарты открытые, и к windows никак не привязаны - не в ядре же они реализованы
Передо мной лежит книжка, называется "Открытые информационные системы".
В ней есть упоминания о международных стандартах в области банковских систем.
Я уверен, что никакой привязки к windows у этих стандартов нет, судя по дате их появления.
Теперь, нам нужно следовать тем же стандартам, которым следуют интересующие нас банки.
Если нам это удаётся, дальше просто.
Транзакции вообще - это сложно.
Конкретные транзакции, которые нам нужны - гораздо проще.
Я укрепился во мнении, что общий мезанизм для поддержки любых распределённых транзакций - это очень сложная задача, к которой ты предлагаешь сводить просто сложную задачу.
И всё равно нужно будет знать, как это работает на более низком уровне, иначе сглючит - и концов не найти.
Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open, я уверен, что все нужные стандарты открытые, и к windows никак не привязаны - не в ядре же они реализованы
В Windows-е распределенные транзакции поддерживаются на уровне COM+.
Т.е. достаточно написать класс, зарегистрировать его в системе, и далее с ним можно работать стандартным способом.
AFAIK, WinFS будет тоже поддерживать механизм транзакций.
> Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open, я уверен, что все нужные стандарты открытые, и к windows никак не привязаны - не в ядре же они реализованы
Но в линуксе, эти все стандарты надо еще самому реализовывать, а под windows-ом эти стандарты уже реализованы: это COM+, OleDB(ADO, Ado.Net и активно поддерживаются.
> Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open,
При том, что "отмена авторского права" так пропагандирумого под linux-а приводит к тому, что система намного медленнее развивается, чем конкуренты.
Т.е. достаточно написать класс, зарегистрировать его в системе, и далее с ним можно работать стандартным способом.
AFAIK, WinFS будет тоже поддерживать механизм транзакций.
> Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open, я уверен, что все нужные стандарты открытые, и к windows никак не привязаны - не в ядре же они реализованы
Но в линуксе, эти все стандарты надо еще самому реализовывать, а под windows-ом эти стандарты уже реализованы: это COM+, OleDB(ADO, Ado.Net и активно поддерживаются.
> Но я не понимаю, причём здесь windows vs. linux, proprietary vs. open,
При том, что "отмена авторского права" так пропагандирумого под linux-а приводит к тому, что система намного медленнее развивается, чем конкуренты.
И что же, если у одного банка система на Sun, а у другого на S/390, COM+ и до них дойдёт?
> Т.е. достаточно написать класс, зарегистрировать его в системе, и далее с ним можно работать стандартным способом.
Если метод класса внутри транзакции отправляет клиенту письмо о перерасходе, а тут вдруг ROLLBACK - письмо вернётся?
> При том, что "отмена авторского права" так пропагандирумого под linux-а приводит к тому, что система намного медленнее
> развивается, чем конкуренты.
Не путай длинное с мягким, а всё это - с зелёным.
> Т.е. достаточно написать класс, зарегистрировать его в системе, и далее с ним можно работать стандартным способом.
Если метод класса внутри транзакции отправляет клиенту письмо о перерасходе, а тут вдруг ROLLBACK - письмо вернётся?
> При том, что "отмена авторского права" так пропагандирумого под linux-а приводит к тому, что система намного медленнее
> развивается, чем конкуренты.
Не путай длинное с мягким, а всё это - с зелёным.
> И что же, если у одного банка система на Sun, а у другого на S/390, COM+ и до них дойдёт?
Если они предоставляют OleDB-провайдер, то - да.
> Если метод класса внутри транзакции отправляет клиенту письмо о перерасходе, а тут вдруг ROLLBACK - письмо вернётся?
Нет, конечно. Smtp не предоставляет возможность транзакционной работы.
Если они предоставляют OleDB-провайдер, то - да.
> Если метод класса внутри транзакции отправляет клиенту письмо о перерасходе, а тут вдруг ROLLBACK - письмо вернётся?
Нет, конечно. Smtp не предоставляет возможность транзакционной работы.
> Если они предоставляют OleDB-провайдер, то - да.
А они должны? И как это выглядит, если до банка у тебя соединение по телефонной линии, а дальше кажется X.25 или что там используют?
Было бы логично ожидать, что если банки что-то и должны, то это следовать какому-то открытому стандарту. Если это не так, то чтож, очередной пример закона, направленного во вред обществу, в интересах некоторых крупных компаний, наряду с авторским правом.
OleDB - открытый стандарт?
> Нет, конечно. Smtp не предоставляет возможность транзакционной работы.
Как видим, чуда не произошло, общая задача не решена.
Теперь, когда мы сводим частную сложную задачу к общей, очень сложной, для которой общего решения нет, нам надо убедиться, что имеющиеся частные решения сработают. Может, COM+ поможет, а может и нет.
Теперь, отмотаем тред наверх.
Ты с нескольких попыток нашёл специфичную прикладную область, в которой твои оппоненты не разбираются, истолковал их незнание, как недостаток linux'а, модели разработки Open Source, и принципиальный недостаток свободного ПО, всего сразу, одним махом.
LOL
А они должны? И как это выглядит, если до банка у тебя соединение по телефонной линии, а дальше кажется X.25 или что там используют?
Было бы логично ожидать, что если банки что-то и должны, то это следовать какому-то открытому стандарту. Если это не так, то чтож, очередной пример закона, направленного во вред обществу, в интересах некоторых крупных компаний, наряду с авторским правом.
OleDB - открытый стандарт?
> Нет, конечно. Smtp не предоставляет возможность транзакционной работы.
Как видим, чуда не произошло, общая задача не решена.
Теперь, когда мы сводим частную сложную задачу к общей, очень сложной, для которой общего решения нет, нам надо убедиться, что имеющиеся частные решения сработают. Может, COM+ поможет, а может и нет.
Теперь, отмотаем тред наверх.
Ты с нескольких попыток нашёл специфичную прикладную область, в которой твои оппоненты не разбираются, истолковал их незнание, как недостаток linux'а, модели разработки Open Source, и принципиальный недостаток свободного ПО, всего сразу, одним махом.
LOL
Даже между тредами вызовы функций происходят не напрямую.
не обязательно, это смотря как сделать
Странно, но Oracle, DB2, PostgreSQL работают именно под Unix. А вот под винду кроме Interbase ничего путного нет.
Извини, но это задача не OS, а базы данных.
А задача OS - предоставить для базы данных простые средства решения этой задачи. Чего под Unix нет.
/* sorry, что влезаю в беседу отцов */
*/Странно, но Oracle, DB2, PostgreSQL работают именно под Unix.Первые два и под Windows работают, Postgres вроде тоже кое-как.
А вот под винду кроме Interbase ничего путного нет.А как же Oracle, DB2 и MS SQL Sever?
> Oracle, DB2, PostgreSQL работают именно под Unix.
Oracle, DB/2 - это такие монстры, для которых ОС - просто драйвер железа.
Разные драйвера различаются только различной кривизной и производительностью.
Соответственно, под виндой всё это работает.
Насколько я понимаю, с точки зрения приложений совершенно пофиг, какая ОС под БД, они не видят этого совсем.
Oracle, DB/2 - это такие монстры, для которых ОС - просто драйвер железа.
Разные драйвера различаются только различной кривизной и производительностью.
Соответственно, под виндой всё это работает.
Насколько я понимаю, с точки зрения приложений совершенно пофиг, какая ОС под БД, они не видят этого совсем.
С точки зрения приложения конечно пофиг. Но не стоит забывать, что монстроБД работают с файловой системой, а не с raw hdd. Что они работают с той памятью, что им выделила OS, а не с физической. И что threadы реализованы тоже OS. Поэтому надежность и скорость работы еще как зависит от OS. То, что приложению пофиг это ясное дело.
> Но не стоит забывать, что монстроБД работают с файловой системой, а не с raw hdd. Что они работают с той
> памятью, что им выделила OS, а не с физической.
Они предпочитают raw partitions и raw i/o и залоченную память, именно чтобы не пользоваться файловой системой, VM и т.д.
Это тебе не MySQL
> памятью, что им выделила OS, а не с физической.
Они предпочитают raw partitions и raw i/o и залоченную память, именно чтобы не пользоваться файловой системой, VM и т.д.
Это тебе не MySQL
Они предпочитают raw partitions и raw i/o и залоченную память, именно чтобы не пользоваться файловой системой, VM и т.д.
Это тебе не MySQL
Не верю.
Завтра на работе у Oracle DBA спрошу.Для тех, кто читал в этом треде ветки о проблеме свободного ПО. О том, что пишется то, что интересно разработчикам, а не юзерам.
source freebsd-net:
source freebsd-net:
> I know that our organization would love to see SACK. Much of the
> high-performance network development that used to be on FreeBSD has
> moved to Linux simply because SACK is essential. You can't run
> trans-oceanic TCP streams of gigabit or more throughput without it.
>
> Unfortunately, SACK is often looked upon as a waste of effort to those
> who use nets in more commercial forms where aggregation of lots of small
> streams is how fat pipes are used. Research big science are about the
> only ones who have a real need for this kind of performance and it's
> growing fast. Without SACK, FreeBSD will be a non-starter for these
> purposes.
Whenever i hear these comments, i am very annoyed at one thing
(which in a smaller scale repeats all over the place):
people are more than happy to spend big money for things like
routers or bandwidth or any kind of "commercial" stuff, but when
it comes to open source it must be free or nothing.
I hope it is clear to everyone that an investment in the 50K$
range would provide a professional-grade implementation of SACK
for FreeBSD, and this money is in the noise for any organization
that uses trans-oceanic gigabit links.
The fact that nobody seems to care about funding such a work
either means that whatever is available already fits their
goals, in which case I agree that there is no point
in using something different, or that these discussions
are based more on thin air than substance.
You certainly raise a valid point on the fact that for the
vast majority of people probably SACK is mostly useless.
cheers
luigi
Целых 50 кусков? За что?!
Минимум в 10 раз преувеличено IMHO.
И действительно, если пользователи не хотят платить, значит не нужно им.
> this money is in the noise for any organization
> that uses trans-oceanic gigabit links
совершенно верно
Минимум в 10 раз преувеличено IMHO.
И действительно, если пользователи не хотят платить, значит не нужно им.
> this money is in the noise for any organization
> that uses trans-oceanic gigabit links
совершенно верно
Для монстроБД очень важна переносимость. Я думаю им очень бы ХОТЕЛОСЬ работать напрямую с памятью и диском, но уж больно напряжно в такой ситуации обеспечить работу на разных аппаратных платформах %)
FreeBSD и Linux - зачем сравнивать ?
Free - единственная (насколько мне известно) опенсорс система, которая разрабатывается ПОЛНОСТЬЮ ЦЕНТРАЛИЗОВАНО (а не кусок в виде ядра в которую заложены определенные идеи-правила-концепции, которым разработчики следуют (и немаловажно - хоть и не в такой степени, как Линух, но ее не назовешь непопулярной %). Ситуация, возможно, изменится немного с выходоб релиза 5-ой ветки (в плане популярности на что я очень надеюсь. Ибо мне приятнее пользоваться действительно ЦЕЛЬНЫМ продуктом, а не париться, пересаживаясь с Линуха на Линух.
Да, и еще - не забываем, что Free помоложе Линуха будет.
Про винду отдельный разговор. Да, безусловно - удобно мышкой шарить по столу, но какой-то более-менее четкой тенденции развития своих ОС у Микрософта я не вижу. Такое ощущение, что они срут своими продуктами везде, где только можно, таким образом пытаясь расшириться-укрепить позиции. Все ихние "передовые-удобные" разработки упираются в клипбоарды и парочку технологий, а остальное все срань. Им стоит приостановиться-призадуматься и более серьезно подходить к своему детищу. Думать о совместимости-безопасности-развитии, а не везде пытаться воткнуть какое-то "нововведение". С таким подходом, как у Гейтса, админы нахуй пошлют винду с ебаными мутациями в каждой новой версии, а пользователи кнопку "старт" будут бояться тыкнуть. Пусть у Бздюнов учатся как вместе последовательно и четко свою ОС развивать.
Какого хуя до сих пор терминал сервиса под 2кПро нет ? только под сервер ? Ссш, что радует, давно в Юнихах живет. Радмин ставить ?
Зато в клипбоарде, бля, картинки можна хуярить!
зы: говорят, кусок дотнета под фрю на сайте мелкософта валяется ?
зызы: Глеб, это не тебе ответил, а так, вообще, просто имхо
Free - единственная (насколько мне известно) опенсорс система, которая разрабатывается ПОЛНОСТЬЮ ЦЕНТРАЛИЗОВАНО (а не кусок в виде ядра в которую заложены определенные идеи-правила-концепции, которым разработчики следуют (и немаловажно - хоть и не в такой степени, как Линух, но ее не назовешь непопулярной %). Ситуация, возможно, изменится немного с выходоб релиза 5-ой ветки (в плане популярности на что я очень надеюсь. Ибо мне приятнее пользоваться действительно ЦЕЛЬНЫМ продуктом, а не париться, пересаживаясь с Линуха на Линух.
Да, и еще - не забываем, что Free помоложе Линуха будет.
Про винду отдельный разговор. Да, безусловно - удобно мышкой шарить по столу, но какой-то более-менее четкой тенденции развития своих ОС у Микрософта я не вижу. Такое ощущение, что они срут своими продуктами везде, где только можно, таким образом пытаясь расшириться-укрепить позиции. Все ихние "передовые-удобные" разработки упираются в клипбоарды и парочку технологий, а остальное все срань. Им стоит приостановиться-призадуматься и более серьезно подходить к своему детищу. Думать о совместимости-безопасности-развитии, а не везде пытаться воткнуть какое-то "нововведение". С таким подходом, как у Гейтса, админы нахуй пошлют винду с ебаными мутациями в каждой новой версии, а пользователи кнопку "старт" будут бояться тыкнуть. Пусть у Бздюнов учатся как вместе последовательно и четко свою ОС развивать.
Какого хуя до сих пор терминал сервиса под 2кПро нет ? только под сервер ? Ссш, что радует, давно в Юнихах живет. Радмин ставить ?
Зато в клипбоарде, бля, картинки можна хуярить!
зы: говорят, кусок дотнета под фрю на сайте мелкософта валяется ?
зызы: Глеб, это не тебе ответил, а так, вообще, просто имхо
Сегодня беседовал на эту тему с нашим Oracle DBA. Он сказал, что действительно Oracle умеет работать на raw paritition но это strongly discouraged, тк disadvantages намного больше чем advantages. А работа с физической памятью - бред.
Free - единственная (насколько мне известно) опенсорс система, которая разрабатывается ПОЛНОСТЬЮ ЦЕНТРАЛИЗОВАНО (а не кусок в виде ядра)Еще есть OpenBSD и NetBSD. Кроме того есть: DragonflyBSD, TrustedBSD.
Еще есть частично open source QNX.
QNX-QNX-ом - тут другой прикол, что риалтайм. Его вообще нельзя с ними сравнивать особо.
Net и Open - понятно, но это, по-хорошему, та же Фря.
Про остальное не слышал, а Линухов в твоем списке почему-то нет %)
Да, с Ораклоидами нашими тоже беседовал. Сказали ту самую херню - рав можно, но на хер не нужно %)
Net и Open - понятно, но это, по-хорошему, та же Фря.
Про остальное не слышал, а Линухов в твоем списке почему-то нет %)
Да, с Ораклоидами нашими тоже беседовал. Сказали ту самую херню - рав можно, но на хер не нужно %)
Net и Open - понятно, но это, по-хорошему, та же Фря.Не показывай публично свою незнания
Самое интересное - это Raw I/O, в обход фалового кеша. А в форме raw devices или O_DIRECT - не так важно. По крайней мере в Linux эти фичи именно ораклоиды проталкивают. Поговори с DBA об этом
Про физическую память я сам придумал, мне показалось логичным. На самом деле не даст никто её, потому что не от рута запускают эти сервисы. А вот hugetlb(то есть, четырёхмегабайтные страницы на x86) базы данных очень любят, если ОС поддерживает выделение таковых, а согласись, действие VM тут исключаются - свопинг кусками в 4M - извращение.
Вместо mlock они проще делают - рекомендуют выносить базу на выделенную тачку, и правильно настраивать все параметры, отвечающие за потребление памяти, чтобы исключить свопинг.
Интересно проверить эти свои представления.
Про физическую память я сам придумал, мне показалось логичным. На самом деле не даст никто её, потому что не от рута запускают эти сервисы. А вот hugetlb(то есть, четырёхмегабайтные страницы на x86) базы данных очень любят, если ОС поддерживает выделение таковых, а согласись, действие VM тут исключаются - свопинг кусками в 4M - извращение.
Вместо mlock они проще делают - рекомендуют выносить базу на выделенную тачку, и правильно настраивать все параметры, отвечающие за потребление памяти, чтобы исключить свопинг.
Интересно проверить эти свои представления.
Я со своей "незнания" нормально уживаюсь, и ,тем более, не стесняюсь сего сожительства. Та же Фря - от ЛайтБСД, но по распространенности я думаю они все же уступают.
Ах да, насчет "незнании" - подучи ее, если не против %)
Ах да, насчет "незнании" - подучи ее, если не против %)
А я и не утверждаю, что ты страдаешь от своего незнания. Многие люди, даже не слышали букв BSD, что не мешает им умничать про юникс. То, что ты называешь ЛайтБСД, называется 4.3BSD-Lite. Утверждение, что FreeBSD (а так же Net и Open) это 4.3BSD-Lite равносильно утверждению, что Су-27, Боинг-747 и Б-52 это по сути самолет братьев Райт.
Спорить не буду. Ты прав, что в этих (назовем их "ветками bsd") штуках направления и идеи развития немного различаются. Маза в том, что БЗДя мне симпатичнее, чем Линух, а Free, в частности, симпатичнее, как самая популярная из БЗД-ей.
Вот и все, что я хотел сказать.
Вот и все, что я хотел сказать.
Очень может быть.
Но скажи пожалуйста, почему такие популярные приложения, как например Squid, Mysql, Zebra разрабытываются вначале под линухом, и лишь потом портируются на остальное ?
Также скажи пожалуйста, почему многие фичи вначале появляются именно в Liunux? а лишь через год-два в Free ?
И еще, почему Squid и Mysql работают просто в разы быстрее на Linux, чем на Free.
И еще, почему, например порт Oracle для Linux есть, причем давно, а под Free еще нет (могу ошибаться, может уже действительно вышел).
Но скажи пожалуйста, почему такие популярные приложения, как например Squid, Mysql, Zebra разрабытываются вначале под линухом, и лишь потом портируются на остальное ?
Также скажи пожалуйста, почему многие фичи вначале появляются именно в Liunux? а лишь через год-два в Free ?
И еще, почему Squid и Mysql работают просто в разы быстрее на Linux, чем на Free.
И еще, почему, например порт Oracle для Linux есть, причем давно, а под Free еще нет (могу ошибаться, может уже действительно вышел).
> почему такие популярные приложения, как например Squid, Mysql, Zebra разрабытываются вначале под линухом
Squid: вроде бы Duane Wessels предпочитает FreeBSD
Zebra: вообще клон Cisco IOS, большинство разработчиков, если судить по спискам рассылки, использует FreeBSD
Mysql: наверное
> И еще, почему Squid и Mysql работают просто в разы быстрее на Linux, чем на Free.
Бенчмарки плохие?
Squid, когда я интересовался последний раз этим, не в разы, а просто заметно быстрее работал на reiserfs. Если использовать традиционные файловые системы, то на FreeBSD было быстрее.
> Также скажи пожалуйста, почему многие фичи вначале появляются именно в Liunux? а лишь через год-два в Free ?
Сейчас скажут: это неправильные фичи, и работают под Linux они неправильно. Когда они появляются во FreeBSD, их сразу правильно реализуют.
> И еще, почему, например порт Oracle для Linux есть, причем давно, а под Free еще нет
Сейчас скажут: и не надо - в линуксляторе работает, и ещё лучше, чем под Linux.
Squid: вроде бы Duane Wessels предпочитает FreeBSD
Zebra: вообще клон Cisco IOS, большинство разработчиков, если судить по спискам рассылки, использует FreeBSD
Mysql: наверное
> И еще, почему Squid и Mysql работают просто в разы быстрее на Linux, чем на Free.
Бенчмарки плохие?
Squid, когда я интересовался последний раз этим, не в разы, а просто заметно быстрее работал на reiserfs. Если использовать традиционные файловые системы, то на FreeBSD было быстрее.
> Также скажи пожалуйста, почему многие фичи вначале появляются именно в Liunux? а лишь через год-два в Free ?
Сейчас скажут: это неправильные фичи, и работают под Linux они неправильно. Когда они появляются во FreeBSD, их сразу правильно реализуют.
> И еще, почему, например порт Oracle для Linux есть, причем давно, а под Free еще нет
Сейчас скажут: и не надо - в линуксляторе работает, и ещё лучше, чем под Linux.
Не буду повторять слов Володи, но добавлю комментарии.
Такой серьезный софт как Squid и Zebra разрабатываются по возможности в соответствии с POSIX, парраллельно поддерживая всевозможные API всевозможных OS. То, под какую ОС была написана версия 0.0.1 никого неебет, так как в версия 0.0.1 закладываются будущие фичи, а не портабельность. Если продукт оказывается интересным, то в дальнейшем его пишут портабельно.
Кстати, судя по тому, что я читал большинство разработчиков MySQL действительно работает под Linuxом. Но как известно, популярное тянется к популярному.
Подробно объясняю про MySQL (возможно тебе это не интересно, но может быть интересно кому то еще): так как действительно большая часть разработчиков MySQL работает под Linux, то работа с тредами в MySQL заточена под Linuxовую user-land реализацию тредов, когда треды фактически представляют собой процессы. При такой оптимизации, если mysqld слинковать с reentrant C library, которая была единственной реализацие тредов в FreeBSD 4.x и старее, получается сильная потеря в скорости на конкурентных запросах. Как с этим можно бороться:
1) Поставить FreeBSD 5, где KSE.
2) Залинковать mysqld на библиотеку linux_threads, которая представляет собой реализацию тредов очень похожую на linux.
Но скажи пожалуйста, почему такие популярные приложения, как например Squid, Mysql, Zebra разрабытываются вначале под линухом, и лишь потом портируются на остальное ?Откуда информация Киря? Опять слышал краем уха?
Такой серьезный софт как Squid и Zebra разрабатываются по возможности в соответствии с POSIX, парраллельно поддерживая всевозможные API всевозможных OS. То, под какую ОС была написана версия 0.0.1 никого неебет, так как в версия 0.0.1 закладываются будущие фичи, а не портабельность. Если продукт оказывается интересным, то в дальнейшем его пишут портабельно.
Кстати, судя по тому, что я читал большинство разработчиков MySQL действительно работает под Linuxом. Но как известно, популярное тянется к популярному.
Также скажи пожалуйста, почему многие фичи вначале появляются именно в Liunux? а лишь через год-два в Free ?Потому что авторы этих фич работают под Linux. Такая мысль в твою голову не приходила? Если ты подумаешь, то возможно осознаешь еще одну важную мысль: "многие фичи вначале появляются именно в *BSD, просто ты об этом не знаешь".
И еще, почему Squid и Mysql работают просто в разы быстрее на Linux, чем на Free.Киря, опять повторяешь чьи-то слова? Ну со squid тебя Володя обломал.
Подробно объясняю про MySQL (возможно тебе это не интересно, но может быть интересно кому то еще): так как действительно большая часть разработчиков MySQL работает под Linux, то работа с тредами в MySQL заточена под Linuxовую user-land реализацию тредов, когда треды фактически представляют собой процессы. При такой оптимизации, если mysqld слинковать с reentrant C library, которая была единственной реализацие тредов в FreeBSD 4.x и старее, получается сильная потеря в скорости на конкурентных запросах. Как с этим можно бороться:
1) Поставить FreeBSD 5, где KSE.
2) Залинковать mysqld на библиотеку linux_threads, которая представляет собой реализацию тредов очень похожую на linux.
И еще, почему, например порт Oracle для Linux есть, причем давно, а под Free еще нет (могу ошибаться, может уже действительно вышел).Для плохоосведомленных: есть пакеты Oracle для RedHat и для SuSE, потому что они забашляли Oracle. Все остальное unsupported настолько же, насколько unsupported FreeBSD.
Оставить комментарий
sergey_m
Сравнение Linux и *BSD в прошлом и настоящем:http://ezine.daemonnews.org/200402/dadvocate.html