Про опенсорс

Две мысли.

Первая. Что бы там ни говорили Столлманы и типа сочувствующие про “эффективность открытых исходников как метода разработки, модернизации и сопровождения программ”, открытые исходники – это фикция. Прежде всего необходима “внутренняя” документация, а она у многих опенсорс-разработчиков либо держится в голове (разбудите человека, занимающегося, к примеру, ядром Linux, и спросите, где реализована функция printk() – и он вам ответит: “Трактат десятый Тайного Писания, страница двести семьдесят шестая, третья строчка сверху!”), либо доступна “избранным”. Да что говорить про “внутреннюю” документацию, когда в коде напрочь отстутствуют комментарии, а пользовательская документация написана десять лет назад для версии 0.0.1! Как говорит [info]vitus_wagner, копание в коде – это “грязная работа, которой хотелось бы избежать“, а во многих случаях – еще и совершенно ненужная.

Кстати, существуют ли обфускаторы Сишного кода? Думаю, от Microsoft не убудет, если они выложат “обфусцированные” исходники какого-нибудь Word 7.0. Зато Open Source и прочие радости :) Да и вообще хороший совет – хотите быть модными и опенсорсными? Выложите нечитаемые исходники!

Вторая. В современном мире Free Software “по Столлману” – это большая глупость, точнее, не глупость, а вредительство. Причем вредительство в интересах прежде всего Китая. Поясню. Если американская или европейская фирма попытается “присвоить” права на какую-нибудь опенсорсную мелочь, использовав ее в своем продукте, но не выложив исходники, то столлманы затаскают ее по судам. Если то же самое сделают китайцы – до них Столлман сотоварищи не дотянется.

Думаю, многие ковырявшие плеер из Vogue склоняются к мысли, что в качестве софта там стоит вариант MPlayer, распространяющегося на условиях GNU GPL. Кто видел в Vogue копию лицензии? Ответ: никто. Нет, конечно, если на плате в полнолуние нажать третью и четвертую кнопки одновременно, при этом замкнув пятую и двадцать пятую ноги флешки, то может быть, нам и покажут полный текст GNU GPL на китайском, но по-хорошему делавшие плеер китайцы плевать хотели на все лицензии.

Если хорошенько “поковырять” китайские “девайсы” – уверен, можно найти такие нарушения GPL, что всех китайских производителей быдлодевайсов можно отправить на урановые рудники. А реально GPL остается примером идеализма, мешающего использованию GPL-нутого кода теми, кто в этом заинтересован.

11 комментариев

  1. [info]iprog пишет:

    > Кстати, существуют ли обфускаторы Сишного кода?

    COBF – http://www.plexaure.de/cobf/index.htm
    пользовался, правда давно уже

  2. [info]ex0-planet пишет:

    Охъ.
    Ну, то что Витус витает в каких-то там своих эмпиреях – это как бы уже и не новость, но ты-то чего? Возможность вот прямо щас слазить скользкими ручками в любой взятый наугад код нужна только красноглазикам, для всех остальных людей опенорс значит только одно: возможность форкнуть, когда припрет (см libraw и Тутубалина например). Читать код в этом случае все равно придется, и никакая документация от этого не спасет.

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

    • > возможность форкнуть, когда припрет

      Правильно, это единственный “плюс” опенсорсности – когда нужен “такой же, но с перламутровыми пуговицами”. Но что самое поганое – если перламутровые пуговицы нужны “уже вчера”, в большинстве опенсорсных проектов невозможно разобраться быстро.

      > по судам таскают только тех, с кого можно что-нибудь слупить

      В Штатах слупить можно с любого, при определенном желании. Потом, в Штатах затаскать по судам реально, а в Китае – нет. Никто не мешает FSF-у использовать методы Microsoft-а (который в свое время судился по поводу и без повода, например, с “фирмешкой” Mike Row Soft) – и чем дальше, тем больше “линукс-вендоры” будут бороться за свои права. Nothing personal, just business.

  3. dsa пишет:

    Не согласен я с ними со всеми. Во-первых, внутренния документация нужна разработчикам, чтобы придерживаться стандартов. Для тех, кто пользуется чужим кодом она никуда не упирается. Во-вторых, “комментарии” – это пережиток 20 летней давности, когда переменные назывались i, ii и половина из них была глоабльными. При нынешних методиках программирования никому они уже нафиг убились. Java, PHP, C++ код читается легче и быстрее любой документации. При том, что обладает абсолютной полнотой и правильностью.

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

    Из практического опыта – пока есть доступ к исходному коду (Открытые Java, PHP решения) любой проект делается за предсказуемо конечное время. Бывают проблемы, но их всегда понятно как решать и заранее известно какое время максимально пойдет. Как только начинается Win32 или Cocoa – все труба – в любой момент жди “делаю, как написано в документации, а все равно не работает”.

    • > При нынешних методиках программирования никому они уже нафиг убились.

      Только где в опенсорсе “нынешние методики”? Не так уж и много проектов покрыто, например, нормальным и общедоступным набором тестов, я не говорю о чем-то большем. Насчет “ненужности” комментариев – предлагаю, например, написать что-нибудь вроде Perlin noise, а затем, месяцев через пять-шесть, вспомнить, что это такое и как изменяется.

      > ничто не заменит вам знание кода своих инструментов и библиотек

      Как обстоят дела со знанием кода gcc или GNU make?

      > за предсказуемо конечное время

      Согласен. Проблема в том, что при таких же “открытых исходниках” на C “предсказуемо конечное” время катастрофически растет в сравнении с Java и PHP.

      • dsa пишет:

        :Только где в опенсорсе “нынешние методики”?

        Да вся практически джава. Там уже по факту своя операционка и не одна написана и процентов на 90% открытый код.

        :Насчет “ненужности” комментариев – предлагаю, например, написать что-нибудь вроде Perlin noise, а затем, месяцев через пять-шесть, вспомнить, что это такое и как изменяется.

        А зачем? Вот перед глазами Wordpress – php по сути тот же перл, но никакого нойза. Из недавнего у нас была проблема – не обновлялся магазин после оплаты с пейпала – задница жопная, так как все реквизиты вводятся на пейпале, то у нас в магазине есть покупка, но нет адреса куда ее отправлять. Решилось за 15 минут глядения в код и 2 часа дописывания обработчика IPN. А если б это была dll? Вешаться?

        :Как обстоят дела со знанием кода gcc или GNU make?

        “я стоял на плечах гигантов”. Для решения проблем этих инструментов есть какая нибудь “Алена С++” или сгинувший где то в NYC John Gladkih.

        А в чем заключается проблема с GNU мейк? Если оно того будет стоить, то пара человеко-недель решается практическую любую. Проблема с vcrt20.dll не решается ни засколько ни за какие деньги.

      • dsa пишет:

        :на C “предсказуемо конечное” время катастрофически растет в сравнении с Java и PHP.

        не. Объем кода написанного на С на порядки меньше, чем того, что успели наворотить на джаве, так что где-то один к одному получается. Да и не так страшен С, как его ублюдок. Оба его ублюдка.

        • Если говорить о равном объеме кода, естественно.

          • dsa пишет:

            это надуманная постановка вопроса. Из опыта проверенно, что приблибизительно равный функционал на Java,C и MVS/HLASM подразумевает пропорцинальное уменьшение количество кода. Так, что расковырять проблему с юникодным текстами в OpenSymphony based J2EE приложении (каждый прочитанный блок конвертируется, потом объеденяется – трехбайтовые японские символы на границах буфера разваливаются), подправить драйвер для PAL-версии AverMedia в линуксе и взять на саппорт IBM Tivoli Output Manager на ассемблере вещи одного порядка сложности.

  4. dsa пишет:

    :и спросите, где реализована функция printk()

    grep -r printk|grep …|grep …|grep -v …|grep -v…

    это если не заморачиваться на ctags