Забыл еще вариант плохого развития событий — либа вообще перестаёт развиваться, и остаётся всего два варианта — либо ты сам её продолжаешь развивать (иногда для этого требуется выкуп прав), либо переписываешь с нуля.
А еще бывает так, что при начальном подключении чужой библиотеки всё вроде бы хорошо, а с годами вылазят проблемы — то в очередной версии либы не выдержат обратную совместимость, то применят решение, которое резко снижает производительность именно в вашем варианте её использования, или не поддерживает новых требований стандартов (по этой теме), то еще какой-нибудь неприятный сюрприз (также как и при смене версий ОС :).
В итоге приходится либо останавливаться на какой-то конкретной устаревшей версии либы, либо вступать в длительную переписку с разработчиком без гарантии исправления (или хотя бы принятия патчей), либо плюнуть на всё, и форкнуть либу или написать свою с нуля.
Автор статьи — разработчик shareware-программы, в России таких сотни или тысячи (swrus.com). У кого-то получается (написать и продавать программу), у кого-то нет. Проводя аналогию с фермерством — если достаточно хорошо изучил свойства земли и растений, то будет получаться с большой вероятностью.
> Любой качественный продукт это годы разработки и допиливания, создание сообщества потребителей.
Бывают всё-таки и исключения: выпустить первую качественную версию небольшой программы и начать получать за неё деньги можно и за 2-3 месяца (лично знаю таких шароварщиков :), но если продукт действительно интересный/полезный, то при таком низком входном пороге (2 месяца работы) сразу набежит масса конкурентов. И вот тогда начинается гонка на выживание, в которой победит… зависит от многих условий. Может победить «исходный» фермер, тщательно ухаживающий за своими посевами и оберегающий их от набегов соседей, а может победить и сосед, если у него дубинка тяжелее (больше свободных рук, доступ к рекламным площадкам, и т.д.). Вполне может получиться так, что исходного инноватора затопчут, а развитие альтернативных продуктов остановится, т.к. для них это был «только бизнес, ничего личного». В итоге все в проигрыше.
А я имел в виду доступные роутеры, а не «Cisco с поддержкой IPv6». Да, а со свичами — «горе от ума» — если свич умный, то ум ему придётся апгрейдить с большой вероятностью.
Обычный свич работает на уровне MAC, и про IP4/IP6 вообще ничего не знает, т.е. апгрейда до IPv6 не требует. А вот доступные роутеры с нормальной поддержкой IPv6 появились всего года два как.
Вероятно имеется в виду, что при расчете контрольной суммы заголовка IP-пакета в случае IPv6 требуется меньше возни, чем в IPv4 просто за счет более продуманной структуры полей. Вот на этом уровне код маршрутизатора вполне может получиться в разы быстрее. Но этого выигрыша не видно на верхних уровнях, т.к. контрольные суммы обычно рассчитывают сами контроллеры, а уровнем выше основное время уходит на копирование буферов, которое от заголовков уже не зависит.
Кстати, с предшественником упомянутого асинхронного процессора GA144 (144-ядерный форт-процессор производства GreenArrays) — 40-ядерным вариантом — отечественные программеры успели плотно поработать (американцы нанимали наших форт-программистов для разработки базового софта), интересная штука.
В eMule'овском варианте использования DHT поиск реализован (ключевые слова хранятся в той же DHT). И вцелом архитектура мулов сделана правильнее, чем торренты, но это их (eMule) не спасло. Даже наоборот повредила — 1) полная децентрализация сделала невозможной модерацию, поэтому eMule завален мусором и заспамлен до предела, что отпугивает пользователей; 2) полная неубиваемость привела к тому, что емульная DHT стала использоваться для посторонних целей ценителями надежных оверлейных сетей — например для координации работы ботнетов.
Программисту надо положить процент от прибыли с того проекта, в котором он участвует. Чтобы он ощущал взаимосвязь качества своей работы и зарплаты. Тогда он не только свой код будет улучшать, но начнет выдвигать идеи повышения эффективности всей компании ;)
ICANN и таблицы маршрутизации не связаны. Блоки IP-адресов получаются и AS регистрируются в локальных регистратурах (LIR), а маршрутизация между AS распространяется по BGP по взаимным соглашениям провайдеров. В общем, фактически децентрализовано. Никакой ICANN за таким процессом уследить не в состоянии, даже при желании, по-моему.
Вот я и говорю, остается отвязать корни от ICANN. Больше ничто не связывает DNS и ICANN.
Набор IP этих корневых серверов (хранимый в ОС) имеет полную аналогию в существующих P2P-системах. Так, например, eMule загружает список нескольких пиров (откуда потом раскручивает всю необходимую пользователю ветку DHT) из файла nodes.dat. Хотя эти nodes.dat могут быть у всех разные, но за счет пересечения пространства хэшей общая сеть не сегментируется (в отличие от торрентовых сетей, сегментированных по трекерам, хотя retracker.local частично от этого спасает).
Попытки построения DNS по аналогичной технологии (овернетом над DHT) уже были. Они вполне работспособны, но на порядок-два тормознутее, чем «штатный» DNS.
Вы тут выше про ЦП для NS писали, так этот вопрос тоже уже подробно проработан — в DNSSEC и в его вариантах для DHT.
В общем, все велосипеды уже изобретены и даже отлажены, остаются чисто организационные вопросы. Вероятно в очередной раз получится небольшая альтернативная сеточка, держащаяся на энтузиастах, и, когда им надоест, всё загнётся. В т.ч. и по финансовым причинам — ведь такую сеть в отличие от трекера монетизировать сложно.
Чтобы отвязаться от ICANN достаточно задать в своих DNS-резолверах другие IP корневых DNS-серверов (которые будут хоститься пиратами :), и всё, никакие программы менять не потребуется.
Электронная почта, какой она была последние лет 30 :), никогда не была связана с конкретным пользовательским интерфейсом. Просто асинхронная передача сообщений, независимо от среды, устройств, программ, стиля использования и т.п. В этом смысле она не изменится никогда. И никогда не умрёт.
А GoogleWave фактически неотделима от своего своеобразного пользовательского интерфейса. Те, кто не смог приспособить свой стиль общения к этому интерфейсу, не стали копать глубже, а просто отказались от этой игрушки.
У меня такие же колонки уже три года. Звуком доволен (и пульт как новенький), НО: у меня они гудят, когда источник звука молчит. С самого начала так было. Независимо от того, к чему подключены (или вообще отключены от компьютера, или mute), в какой сети питания подключены (летом на даче), и т.д. — гудят и всё. Как будто с блоком питания что-то не то. Приходится выключать, когда не используются, чтоб на нервы не действовали. А в этом году вообще оставил их на даче — достали они меня уже этим гудением :( Раз никто больше не жалуется — значит мне одному так не повезло?
Volch: «Мне всегда казалось, что ему свойственно отбрасывание всех входящих соединений, и только если трансляция с определенного порта куда-то специально задана, то содинения не отбрасываются.»
«Отбрасывание» сделано не специально для защиты, а просто потому, что неизвестно (без предварительной специальной настройки), в какой локальный IP этот запрос перенаправлять. Вот и приходится отбрасывать.
Народ постоянно путает NAT и Firewall'ы, потому что они обычно реализуются в одних и тех же устройствах (т.к. работают на одном и том же сетевом уровне), но вполне может быть NAT без Firewall и наоборот (на публичном IP NAT не нужен, а firewall нужен).
NAT не добавляет защищенности компьютерам внутри ЛС, а скорее наоборот немножко её отнимает, т.к. без NAT (или прокси) компьютеры внутри ЛС (с локальными IP) вообще с интернетом не могут общаться, никакие «сканирования портов» к ним не пройдут.
Malamut> А постфикс из коробки фильтрует при правильной настройке практически весь спам (естественно без единого RBL)
А что вы против RBL имеете? CBL и BRBL — хорошие RBL.
И что за настройка Postfix фильтрует практически весь спам? Наверное домен молодой, не засвеченный, и спамеры пока попадаются глупые. А со временем придётся поставить хотя бы SpamAssassin (не лучший вариант, но под линуксом с хорошими спам-фильтрами туго).
А я использую Eserv/4, там всё описанное (SMTP+IMAP+Chat) есть, причем изначально интегрированное (т.к. от одного разработчика), плюс там же встроенный LDAP для общей адресной книги, веб-интерфейс к почте (webmail) и общим IMAP-папкам (в вебе они прикидываются форумами), плюс wiki и т.д.
В итоге приходится либо останавливаться на какой-то конкретной устаревшей версии либы, либо вступать в длительную переписку с разработчиком без гарантии исправления (или хотя бы принятия патчей), либо плюнуть на всё, и форкнуть либу или написать свою с нуля.
> Любой качественный продукт это годы разработки и допиливания, создание сообщества потребителей.
Бывают всё-таки и исключения: выпустить первую качественную версию небольшой программы и начать получать за неё деньги можно и за 2-3 месяца (лично знаю таких шароварщиков :), но если продукт действительно интересный/полезный, то при таком низком входном пороге (2 месяца работы) сразу набежит масса конкурентов. И вот тогда начинается гонка на выживание, в которой победит… зависит от многих условий. Может победить «исходный» фермер, тщательно ухаживающий за своими посевами и оберегающий их от набегов соседей, а может победить и сосед, если у него дубинка тяжелее (больше свободных рук, доступ к рекламным площадкам, и т.д.). Вполне может получиться так, что исходного инноватора затопчут, а развитие альтернативных продуктов остановится, т.к. для них это был «только бизнес, ничего личного». В итоге все в проигрыше.
Набор IP этих корневых серверов (хранимый в ОС) имеет полную аналогию в существующих P2P-системах. Так, например, eMule загружает список нескольких пиров (откуда потом раскручивает всю необходимую пользователю ветку DHT) из файла nodes.dat. Хотя эти nodes.dat могут быть у всех разные, но за счет пересечения пространства хэшей общая сеть не сегментируется (в отличие от торрентовых сетей, сегментированных по трекерам, хотя retracker.local частично от этого спасает).
Попытки построения DNS по аналогичной технологии (овернетом над DHT) уже были. Они вполне работспособны, но на порядок-два тормознутее, чем «штатный» DNS.
Вы тут выше про ЦП для NS писали, так этот вопрос тоже уже подробно проработан — в DNSSEC и в его вариантах для DHT.
В общем, все велосипеды уже изобретены и даже отлажены, остаются чисто организационные вопросы. Вероятно в очередной раз получится небольшая альтернативная сеточка, держащаяся на энтузиастах, и, когда им надоест, всё загнётся. В т.ч. и по финансовым причинам — ведь такую сеть в отличие от трекера монетизировать сложно.
Чтобы отвязаться от ICANN достаточно задать в своих DNS-резолверах другие IP корневых DNS-серверов (которые будут хоститься пиратами :), и всё, никакие программы менять не потребуется.
А GoogleWave фактически неотделима от своего своеобразного пользовательского интерфейса. Те, кто не смог приспособить свой стиль общения к этому интерфейсу, не стали копать глубже, а просто отказались от этой игрушки.
«Отбрасывание» сделано не специально для защиты, а просто потому, что неизвестно (без предварительной специальной настройки), в какой локальный IP этот запрос перенаправлять. Вот и приходится отбрасывать.
Народ постоянно путает NAT и Firewall'ы, потому что они обычно реализуются в одних и тех же устройствах (т.к. работают на одном и том же сетевом уровне), но вполне может быть NAT без Firewall и наоборот (на публичном IP NAT не нужен, а firewall нужен).
NAT не добавляет защищенности компьютерам внутри ЛС, а скорее наоборот немножко её отнимает, т.к. без NAT (или прокси) компьютеры внутри ЛС (с локальными IP) вообще с интернетом не могут общаться, никакие «сканирования портов» к ним не пройдут.
www.eserv.ru/NAT
А что вы против RBL имеете? CBL и BRBL — хорошие RBL.
И что за настройка Postfix фильтрует практически весь спам? Наверное домен молодой, не засвеченный, и спамеры пока попадаются глупые. А со временем придётся поставить хотя бы SpamAssassin (не лучший вариант, но под линуксом с хорошими спам-фильтрами туго).