Washington Post рекомендует

[Ali1]

...

1. среднестатистическая умолчательная установка Linux существенно безопаснее, чем умолчательная установка любой винды (хоть 9х, хоть висты);
2. усилий по доведению её до некого (вообще говоря, любого) порогового уровня безопасности нужно затратить не в пример меньше.

Насчет усилий по доведению, обеспечение хорошего (для персональной машины) уровня безопасности в винде достигается путем выполнения следующих простых шагов:
1. Создание учетки с ограниченными правами (делается и в линуксе, просто на этапе установки): 1-2 минуты
2. НЕвыключение имеющихся механизмов безопасности: 0 минут
3. НЕвыключение автоматических обновлений (или установка хотя бы обновлений безопасности): 0 минут
4. Для пущей надежности можно добавить установку простых бесплатных антивируса и фаервола - еще минут 10-15 вместе с настройкой.
Как минимум 90% гуляющей инет-заразы после этого станет для данной машины неопасна. А если еще пользователь не будет открывать каждый невесть откуда пришедший аттач, то станет вообще хорошо. Проблема в том, что большинство пользователей выполняют вышеперечисленные действия с точностью до наоборот, после чего сильно удивляются возникающим проблемам.

Т.е Вы утверждаете:

• умолчательная установка Windows существенно небезопаса
• для доведения windows до приемлемого состояния требуется выполнить некоторые действия
• windows слабо препятствует диструктивным действиям пользователей, а скорее наоборот - потворствует
• window позволяет без ограничений "открывать каждый невесть откуда пришедший аттач"
• Все вышеперечисленное не есть дефекты проектирования системы.

Не нужно искажать мои слова. Это были примеры ошибок проектирования системы, в качестве иллюстрации к общей квалификации её архитекторов.

Я не могу согласится в том, что вышеперечисленное характеризует квалификацию разработчиков. ИМХО это сознательное решение, преследующее внешние цели.

ЗЫ
//offtop

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

Углубте и расширте Ваш тезис. Мне просто интересно.

[Iskan Der]

• умолчательная установка Windows существенно небезопаса
• для доведения windows до приемлемого состояния требуется выполнить некоторые действия
• windows слабо препятствует диструктивным действиям пользователей, а скорее наоборот - потворствует
• window позволяет без ограничений "открывать каждый невесть откуда пришедший аттач"
• Все вышеперечисленное не есть дефекты проектирования системы.

Умолчальная установка создает лишь одного юзера, который назначается админом. То, что работать под админом/рутом нехорошо с точки зрения безопасности, знают все. Поэтому следует создать себе учетку с ограниченными правами. Где тут "существенно небезопасна"? Про "потворствование деструктивным действиям" я что-то ничего не вижу. В части открытия непонятных аттачей ни одна ОС не ограничивает (разве что отсутствием ПО для открытия аттача). В общем, перечитайте еще раз мой пост, вы что-то не так поняли.

Углубте и расширте Ваш тезис. Мне просто интересно.

А что здесь расширять/углублять? Нету - значит нету. Ну может не забыли, специально не сделали, хотя не могу предположить, зачем.

[Yaros]

Углубте и расширте Ваш тезис. Мне просто интересно.

А что здесь расширять/углублять? Нету - значит нету. Ну может не забыли, специально не сделали, хотя не могу предположить, зачем.

Ыыы. Троллинг, не иначе.
Уважаемый, потрудитесь объяснить общественности, что такое "нормальный" API. И чем linux в этом плане ненормален. А то даже не смешно ведь...

[Ali1]

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

Я типа не знаю.

Поэтому следует создать себе учетку с ограниченными правами. Где тут "существенно небезопасна"?

Тут - существенно небезопасна.
Учетная запись с ограниченными правами должна быть безусловно создана при инсталляции системы.
не создается обычный пользователь

В части открытия непонятных аттачей ни одна ОС не ограничивает (разве что отсутствием ПО для открытия аттача).

А как же наличие текущего каталога в PATH?

В общем, перечитайте еще раз мой пост, вы что-то не так поняли.

Возможно, верно и обратное.

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

Возможно, я не понимаю значения термина "API для прикладных разработчиков" и bash написан без использования glibc сразу в опкодах.

[Boboms]

Да чё вы на него навалились, то? (и я, кстатьи, тоже)

Человек не успевает: то надо википедию перечитывать, то своему спонсору звонить. Дайте пару часов, еще трактат сгенерит Загоняете ведь внештатного сотрудника ...

[Iskan Der]

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

Она никому ничего не должна. Если юзер хочет безопасности, он себе такую запись создаст, благо делов на два клика. Если ему просто охота быть самым крутым в системе, то он и в линуксе под рутом будет жить. Так что делать трагедию из данного момента просто неуместно.

А как же наличие текущего каталога в PATH?

Эээ, и что?

Возможно, я не понимаю значения термина "API для прикладных разработчиков" и bash написан без использования glibc сразу в опкодах.

glibc - это хорошо, но слабовато. Создание GUI? Работа с БД? Транзакции? Распределенная разработка? Ну и т.п.
Одним лишь этим API разработчику прикладного ПО удается обойтись весьма редко, вот и приходится таскать за собой ворох сторонних библиотек (Gtk, Qt и всякоразно). Что, в свою очередь, влечет за собой массу трудностей на этапе развертывания и поддержки (всеми любимые игры с зависимостями).

[t.t]

Не нужно искажать мои слова. Это были примеры ошибок проектирования системы, в качестве иллюстрации к общей квалификации её архитекторов.

Я не могу согласится в том, что вышеперечисленное характеризует квалификацию разработчиков. ИМХО это сознательное решение, преследующее внешние цели.

Да, такой вариант и я приводил выше. Конкретно здесь я исходил из предположения, что компания-разработчик не занималась сознательным вредительством.

[Yaros]

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

Она никому ничего не должна. Если юзер хочет безопасности, он себе такую запись создаст, благо делов на два клика. Если ему просто охота быть самым крутым в системе, то он и в линуксе под рутом будет жить. Так что делать трагедию из данного момента просто неуместно.

Она и вправду никому ничего не должна... Поэтому в винде мы имеем то, что имеем Однако это Ваше "если юзер хочет безопасности" указывает, что по умолчанию ОС имени Б.Г. на безопасность забивает, что указывает на правоту товарища t.t.

glibc - это хорошо, но слабовато. Создание GUI? Работа с БД? Транзакции? Распределенная разработка? Ну и т.п.
Одним лишь этим API разработчику прикладного ПО удается обойтись весьма редко, вот и приходится таскать за собой ворох сторонних библиотек (Gtk, Qt и всякоразно). Что, в свою очередь, влечет за собой массу трудностей на этапе развертывания и поддержки (всеми любимые игры с зависимостями).

Ввиду того, что GUI, БД и прочее перечисленное вами может отсутствовать в конкретной системе, пихать все это в ядро с гордым названием API - глупо. А с зависимостями у меня aptitude шикарно справляется - никакой винде и не снилось.

[t.t]

При написании и распространении вируса основную роль играет не "выбор кого бомбануть", а как раз квалификация его автора. Не зря ведь авторов вирусов, породивших массовые эпидемии, приглашают на работу крупные компании: степень распространения хорошо говорит о квалификации автора

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

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

1. среднестатистическая умолчательная установка Linux существенно безопаснее, чем умолчательная установка любой винды (хоть 9х, хоть висты);
2. усилий по доведению её до некого (вообще говоря, любого) порогового уровня безопасности нужно затратить не в пример меньше.

Насчет усилий по доведению, обеспечение хорошего (для персональной машины) уровня безопасности в винде достигается путем выполнения следующих простых шагов:
1. Создание учетки с ограниченными правами (делается и в линуксе, просто на этапе установки): 1-2 минуты
2. НЕвыключение имеющихся механизмов безопасности: 0 минут
3. НЕвыключение автоматических обновлений (или установка хотя бы обновлений безопасности): 0 минут
4. Для пущей надежности можно добавить установку простых бесплатных антивируса и фаервола - еще минут 10-15 вместе с настройкой.
Как минимум 90% гуляющей инет-заразы после этого станет для данной машины неопасна. А если еще пользователь не будет открывать каждый невесть откуда пришедший аттач, то станет вообще хорошо. Проблема в том, что большинство пользователей выполняют вышеперечисленные действия с точностью до наоборот, после чего сильно удивляются возникающим проблемам.

Проблема в том, что пользователь _обязан_ выполнять какие-то "простые" шаги только для того, чтобы получить уровень безопасности даже ниже, чем в большинстве дистрибутивов Linux он получит сразу после установки. В том числе, нужно знать, где раздобыть те самые бесплатные фаервол и антивирус. Кроме того, цифра 90%, на мой взгляд, сильно преувеличена. По крайней мере, в моём опыте эта цифра была ниже как минимум на треть (никаких атачей, да и вообще почты, не было и в помине).

Не нужно искажать мои слова. Это были примеры ошибок проектирования системы, в качестве иллюстрации к общей квалификации её архитекторов.

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

И после этого Вы обижаетесь на слово "глупости"?? Потрудитесь тогда по крайней мере объясниться, что Вы подразумевали под этими словами.

[Iskan Der]

Проблема в том, что пользователь _обязан_ выполнять какие-то "простые" шаги только для того, чтобы получить уровень безопасности даже ниже, чем в большинстве дистрибутивов Linux он получит сразу после установки.

Ограниченную учетку и в линуксе создавать надо. Тут просто одно действие переносится на другой этап, и все.

Кроме того, цифра 90%, на мой взгляд, сильно преувеличена. По крайней мере, в моём опыте эта цифра была ниже как минимум на треть (никаких атачей, да и вообще почты, не было и в помине).

Ну не знаю, я ограничился лишь бесплатными антивирем/фаером (т.е. только пункт 4), вот уже три года не знаю проблем. Почта, аттачи и всякоразно прочее присутствуют в полном объеме.

Ввиду того, что GUI, БД и прочее перечисленное вами может отсутствовать в конкретной системе, пихать все это в ядро с гордым названием API - глупо. А с зависимостями у меня aptitude шикарно справляется - никакой винде и не снилось.

Во-первых, API в ядро пихать не надо. Во-вторых, никто не запрещает ему быть таким же модульным, как сама система. В-третьих, шикарную работу aptitude видел вживую, впечатлен не был. Как-то так.

[Yaros]

Проблема в том, что пользователь _обязан_ выполнять какие-то "простые" шаги только для того, чтобы получить уровень безопасности даже ниже, чем в большинстве дистрибутивов Linux он получит сразу после установки.

Ограниченную учетку и в линуксе создавать надо. Тут просто одно действие переносится на другой этап, и все.

Вы не думали, что многие юзеры об этом другом этапе не в курсе? Мелочь, а неприятно

Ввиду того, что GUI, БД и прочее перечисленное вами может отсутствовать в конкретной системе, пихать все это в ядро с гордым названием API - глупо. А с зависимостями у меня aptitude шикарно справляется - никакой винде и не снилось.

Во-первых, API в ядро пихать не надо. Во-вторых, никто не запрещает ему быть таким же модульным, как сама система. В-третьих, шикарную работу aptitude видел вживую, впечатлен не был. Как-то так.

И все же, я не понимаю - что конкретно Вам надо от LinAPI. Для работы с БД, например, есть библиотеки для тех СУБД, под которыми все будет работать. Да и вообще, не хотите QT или GTK+ - напишите универсальное решение, если оно будет действительно классным, Вы прославитесь и его включат в ядро а пока оно просто не нужно (в описанном Вами ракурсе).
P.S. А Aptitude и не пытался вас впечатлить, он просто делает свою работу - и делает ее шикарно.

[Ali1]

Ограниченную учетку и в линуксе создавать надо. Тут просто одно действие переносится на другой этап, и все.

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

[Iskan Der]

Вы не думали, что многие юзеры об этом другом этапе не в курсе? Мелочь, а неприятно

Если следовать парадигме "юзер не в курсе", то линуксом вообще пользоваться нереально будет Я в свое время несколько дней убил на настройку вафли в сусе 10.2, ибо был не в курсе, что ей еще надо где-то firmware добывать и куда-то подкладывать.

И все же, я не понимаю - что конкретно Вам надо от LinAPI. Для работы с БД, например, есть библиотеки для тех СУБД, под которыми все будет работать.

Я говорю API, которого было бы достаточно для написания приложений. Чтобы не надо было таскать за собой вязанки сторонних библиотек. Чтобы иметь стандартизированные решения типовых задач вроде той же работы с БД (а не свой API для каждой из них). В качестве примера можно взять WinAPI, .NET, Carbon, Cocoa и им подобные.

Aptitude и не пытался вас впечатлить, он просто делает свою работу - и делает ее шикарно.

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

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

А Карфаген должен быть разрушен Проглядел Ветхий завет, в списке 10ти заповедей про это ничего не говорится. Так откуда такие сведения?

[t.t]

Проблема в том, что пользователь _обязан_ выполнять какие-то "простые" шаги только для того, чтобы получить уровень безопасности даже ниже, чем в большинстве дистрибутивов Linux он получит сразу после установки.

Ограниченную учетку и в линуксе создавать надо. Тут просто одно действие переносится на другой этап, и все.

Её создаёт установщик в полуавтоматическом режиме; предлагая ввести имя и пароль. И во многих дистрибутивах этот же установщик сам пояснит, почему под рутом работать нехорошо. Это сильно отличается от решения типа "догадайся, мол, сама".

Кроме того, Вы проигнорировали замечание касательно антивируса и фаервола.

Кроме того, цифра 90%, на мой взгляд, сильно преувеличена. По крайней мере, в моём опыте эта цифра была ниже как минимум на треть (никаких атачей, да и вообще почты, не было и в помине).

Ну не знаю, я ограничился лишь бесплатными антивирем/фаером (т.е. только пункт 4), вот уже три года не знаю проблем. Почта, аттачи и всякоразно прочее присутствуют в полном объеме.

Ну и что? Из тех машин, о которых я говорил в прошлом посте, одна нахватала вирей за первые пол-часа после установки фаервола. Ещё вопрос, какой из этих двух единичных примеров считать более показательным.

Ввиду того, что GUI, БД и прочее перечисленное вами может отсутствовать в конкретной системе, пихать все это в ядро с гордым названием API - глупо. А с зависимостями у меня aptitude шикарно справляется - никакой винде и не снилось.

Во-первых, API в ядро пихать не надо. Во-вторых, никто не запрещает ему быть таким же модульным, как сама система.

Модульный апи -- это, в переводе на русский язык, "у каждой отдельной части -- отдельный апи", я правильно Вас понимаю? Если нет, то потрудитесь объяснить. А если да, то укажите, пожалуйста, те части, у которых этого отдельного апи нет.

В-третьих, шикарную работу aptitude видел вживую, впечатлен не был. Как-то так.

Это из категории "мне Мойша напел". Либо приводите конкретные недостатки, либо не стоит засорять пространство своими необоснованными впечатлениями. Потому как я aptitude использую почти семь лет, и могу утверждать весьма компетентно: сравнимого по качеству средства простой установки мне не встречалось; все без исключения виндовые средства -- хуже на несколько порядков.

P.S. Ответы Вам других участников форума подсказывают мне, что скорее всего я всё-таки не слишком предвзят.

[Iskan Der]

Кроме того, Вы проигнорировали замечание касательно антивируса и фаервола.

Проглядел
Фаерволл есть и встроенный. Антивирь да, придется ставить отдельно, но об этом сама система скажет , кстати.

Ещё вопрос, какой из этих двух единичных примеров считать более показательным.

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

Модульный апи -- это, в переводе на русский язык, "у каждой отдельной части -- отдельный апи", я правильно Вас понимаю? Если нет, то потрудитесь объяснить.

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

Либо приводите конкретные недостатки, либо не стоит засорять пространство своими необоснованными впечатлениями.

Конкретно проблемы возникают при наличии нескольких репозиториев, когда конфликтуют пакеты. Впрочем, да, погорячился, сам aptitude тут не виноват, виновата система.

[Yaros]

Кроме того, Вы проигнорировали замечание касательно антивируса и фаервола.

Фаерволл есть и встроенный.

О мертвых либо хорошо, либо ничего. Поэтому оставим...

Модульный апи -- это, в переводе на русский язык, "у каждой отдельной части -- отдельный апи", я правильно Вас понимаю? Если нет, то потрудитесь объяснить.

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

Есть старые добрые системные вызовы...

[Ali1]

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

Думаю, Вы упрощаете. Единый АПИ, механически порезанный на куски, вовсе не становится модульным. Нужны языковые средства описания и контроля интерфейсов модулей. Не в linux, не в windos(без .нет) подобных механизмов нет.

Цитата(Ali1 @ Oct 21 2009, в 19:41) *
Учетная запись с ограниченными правами должна быть безусловно создана при инсталляции системы.

А Карфаген должен быть разрушен smile.gif Проглядел Ветхий завет, в списке 10ти заповедей про это ничего не говорится. Так откуда такие сведения? smile.gif

Должен! И с этим согласна корпорация M$ создавшая UAC (User Account Control) и новый инсталлятор в NT6.? .

[Iskan Der]

Единый АПИ, механически порезанный на куски, вовсе не становится модульным. Нужны языковые средства описания и контроля интерфейсов модулей

А я этого и не утверждаю, заметьте. Главное - архитектурная целостность такого АПИ, т.е. это именно единая система, а не просто набор разнородных фрагментов.

[mirlas]

До единого API становится откровенно ...уй когда дело доходит до стадии реализации проекта Когда на кону скорость/удобство/документированность - Единым API в винде и не пахнет. Как и не пахнет единством в чем либо вообще в этой ОС. В ней только один воплощенный плюс - простота разворачивания. Но ведь на это история не заканчивается. Далее идет самая тяжелая часть: поддержка работы, мониторинг, модификации и т.д. А вот здесь нас ожидают большие сюрпризы в маленьких делах. Разговоры про API - это конечно здорово, но когда ты не можешь выполнить элементарных вещей - становится как-то неуютно. Банальный пример - кодировка имен в системе: их там (в винде) _ЧЕТЫРЕ ОДНОВРЕМЕННО_ (!!!) Некоторые вещи вообще не работают и исправлять их (внимание, фанатам "поддержки") в суппорте _ОТКАЗЫВАЮТСЯ_ ссылаясь на неповторимость результата. Про какой, нахрен, API может идти речь, когда я не могу быть уверен что в этом "единстве" все будет работать и завтра и осознавая, что выбора нет?
Пора уже осознавать, что в частной коммерческой системе есть только одна цель - получение прибыли любой ценой. И только для этого она и создавалась. Никакие человеческие ценности туда не закладываются. Зачем, если благо можно продать?! Да, можеть быть линукс и делался для удовольствия, но для удовольствия сложно сделать неудобно. Как минимум, систма, в которую вложены человеческие ценности, такие как интузиазм, желание достигать максимального, попытки сделать совершенней что-то - должна работать гораздо лучше.

[t.t]

Кроме того, Вы проигнорировали замечание касательно антивируса и фаервола.

Проглядел
Фаерволл есть и встроенный. Антивирь да, придется ставить отдельно, но об этом сама система скажет , кстати.

Система не скажет где его взять. А встроенный фаервол даже в книжках для чайников использовать не советуют.

Модульный апи -- это, в переводе на русский язык, "у каждой отдельной части -- отдельный апи", я правильно Вас понимаю? Если нет, то потрудитесь объяснить.

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

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

Либо приводите конкретные недостатки, либо не стоит засорять пространство своими необоснованными впечатлениями.

Конкретно проблемы возникают при наличии нескольких репозиториев, когда конфликтуют пакеты. Впрочем, да, погорячился, сам aptitude тут не виноват, виновата система.

Также приведите, пожалуйста, такой пример. Для справки: в моей системе сейчас отлично сочетаются: пять репозиториев Debian (oldstable, stable, testing, unstable, experimental); репозитории emdebian-devel и debian-multimedia; четыре репозитория убунты (dapper, intrepid, jaunty, launchpad); это не считая сторонних пакетов из мелких deb-репозитариев, а также сконвертированных утилитой alien пакетов rpm. До того у меня с различными ветками Debian и debian-multimedia сочетались в одной системе пакеты из репозиториев XandrOS, Mepis и Lindows-free.

[Iskan Der]

А встроенный фаервол даже в книжках для чайников использовать не советуют.

Начиная с XP SP2 он не так уж и плох, кстати говоря. Не Agnitum Outpost, но вполне юзабельно.

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

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

Также приведите, пожалуйста, такой пример. Для справки: в моей системе сейчас отлично сочетаются: пять репозиториев Debian (oldstable, stable, testing, unstable, experimental); репозитории emdebian-devel и debian-multimedia; четыре репозитория убунты (dapper, intrepid, jaunty, launchpad); это не считая сторонних пакетов из мелких deb-репозитариев, а также сконвертированных утилитой alien пакетов rpm. До того у меня с различными ветками Debian и debian-multimedia сочетались в одной системе пакеты из репозиториев XandrOS, Mepis и Lindows-free.

Не могу, vinny опять будет ругаться, что я старую пластинку завожу
Если кратко, то один лишь debian-multimedia у меня не сумел ужиться со stable: после установки пары приложений оттуда была куча конфликтов пакетов. Сейчас дебианом уже не пользуюсь, поставил сусе - там схожая картина: после установки пары приложений из стороннего репозитория (Packman) напрочь пропал звук.

[sash-kan]

поставил сусе - там схожая картина

карма.
вам на слор пора. там таких много (живых или клонов — не суть важно). и у всех — карма.

[Minton]

Несколько трудно уловить связь между пропавшим звуком и архитектурными недостатками системы управления ПО... У меня вот с Пакмана много чего стоит, а звук нормально работает, так что это не аргумент. Но я с нетерпением жду весомых доводов о недостатках aptitude

[Yaros]

А встроенный фаервол даже в книжках для чайников использовать не советуют.

Начиная с XP SP2 он не так уж и плох, кстати говоря. Не Agnitum Outpost, но вполне юзабельно.

Не доверил бы даже туалет охранять.

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

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

Странно. Ни разу не сталкивался. Видимо, я неудачник... :-(

[sash-kan]

я с нетерпением жду весомых доводов о недостатках aptitude

1. название длинное.
2. лицензия не православная.

[DarkPhoenix]

Кстати, я так и не увидел конкретных примеров "единого" апи в винде :о

Ну и месье, похоже, не очень сильно шарит в этих самых апи, раз так стремится стандартизировать. Сделать "единый апи" для БД - а вдруг в одном из движков фича а-ля ноу-хау появится? А потом и в другом... да и вообще у разных БД архитектура может быть разная. В итоге наличие выбора практически всегда подразумевает некоего набора АПИ, а не чего-то единого.

В винде кстате похожая ситуация.

[t.t]

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

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

Код: Выделить всё

#ifdef __cplusplus
extern "C" {

Вы даже этого не знаете? Или я что-то неправильно понял?

Также приведите, пожалуйста, такой пример. Для справки: в моей системе сейчас отлично сочетаются: пять репозиториев Debian (oldstable, stable, testing, unstable, experimental); репозитории emdebian-devel и debian-multimedia; четыре репозитория убунты (dapper, intrepid, jaunty, launchpad); это не считая сторонних пакетов из мелких deb-репозитариев, а также сконвертированных утилитой alien пакетов rpm. До того у меня с различными ветками Debian и debian-multimedia сочетались в одной системе пакеты из репозиториев XandrOS, Mepis и Lindows-free.

Не могу, vinny опять будет ругаться, что я старую пластинку завожу
Если кратко, то один лишь debian-multimedia у меня не сумел ужиться со stable: после установки пары приложений оттуда была куча конфликтов пакетов. Сейчас дебианом уже не пользуюсь, поставил сусе - там схожая картина: после установки пары приложений из стороннего репозитория (Packman) напрочь пропал звук.

Во-первых, если у Вас такое действительно было, то это и правда "карма": такого не бывает в принципе, кроме разве что ошибки в конкретном пакете, которая должна быть достаточно быстро утсранена, если даже предположить, что пакет с такой ошибкой вообще мог попасть в репозиторий. Во-вторых, в aptitude я уже не помню сколько времени есь автоматический решатель зависимостей; справляется довольно хорошо. В-третьих, даже до его появления все проблемные случаи легко разруливались руками через интерактивный интерфейс aptitude. Это всё, конечно, если не делать очевидных глупостей, типа подключения к stable системе testing или unstable из d-m.

[YUKLA]

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

Пожалуйста - GNU LibC и GLIB. Функции перечислить? И libX11 и libxcb. Это только на вскидку.
А есть еще одна замечательная библиотека - libsysfs, про которую в sysfs-rules.txt написано следующее:

Do not use libsysfs
It makes assumptions about sysfs which are not true. Its API does not offer any abstraction, it exposes all the kernel driver-core implementation details in its own API. Therefore it is not better than reading directories and opening the files yourself. Also, it is not actively maintained, in the sense of reflecting the current kernel development. The goal of providing a stable interface
to sysfs has failed; it causes more problems than it solves. It violates many of the rules in this document.

Вообще - стоит внимательно почитать sysfs-rules.txt - там много написано про то, как стоит интерпретировать информацию в /sys, и как это может быть не правильно реализовано в других программах.

Примеры можно приводить и дальше. Если у вас CUPS запущен - сходите на http://localhost:631/ и посмотрите там Documentation/Help, раздел Programming. А потом сравните с тем, что написано в соотв *.h файлах. Вас ждет много открытий.

И так далее и тому подобное.

Итог. API в Linux:

• Отвратно документировано
• Не стандартизовано
• Постоянно меняется
• Часто не имеет обратной совместимости после этого

[Davinel]

Ну не знаю, я ограничился лишь бесплатными антивирем/фаером (т.е. только пункт 4), вот уже три года не знаю проблем. Почта, аттачи и всякоразно прочее присутствуют в полном объеме.

Мне вот что интересно.. А откуда вы собственно знаете, что у вас нет вирусов? "Правильные" вирусы обычно ведут себя так, что вы их вряд ли заметите, без кучи дополнительных телодвижений, типа просмотра логов сетевой активности на досуге.

Начиная с XP SP2 он не так уж и плох, кстати говоря. Не Agnitum Outpost, но вполне юзабельно.

Откровенно говоря агнитиум весьма уныл )

Если кратко, то один лишь debian-multimedia у меня не сумел ужиться со stable: после установки пары приложений оттуда была куча конфликтов пакетов.

Там все без проблем разруливается.. Всегда. Если не хотите, чтобы нужно было "разруливать" - не используйте сторонние репозитории. Все просто.

Итог. API в Linux:
[*]Отвратно документировано

Глупости

[*]Не стандартизовано
[*]Постоянно меняется
[*]Часто не имеет обратной совместимости после этого

Как и везде.. Как и везде.

[YUKLA]

Итог. API в Linux:
[*]Отвратно документировано

Глупости

Аргументировать сможете?