Две мысли.
Первая. Что бы там ни говорили Столлманы и типа сочувствующие про «эффективность открытых исходников как метода разработки, модернизации и сопровождения программ», открытые исходники — это фикция. Прежде всего необходима «внутренняя» документация, а она у многих опенсорс-разработчиков либо держится в голове (разбудите человека, занимающегося, к примеру, ядром Linux, и спросите, где реализована функция printk() — и он вам ответит: «Трактат десятый Тайного Писания, страница двести семьдесят шестая, третья строчка сверху!»), либо доступна «избранным». Да что говорить про «внутреннюю» документацию, когда в коде напрочь отстутствуют комментарии, а пользовательская документация написана десять лет назад для версии 0.0.1! Как говорит ![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
vitus_wagner, копание в коде — это «грязная работа, которой хотелось бы избежать«, а во многих случаях — еще и совершенно ненужная.
Кстати, существуют ли обфускаторы Сишного кода? Думаю, от Microsoft не убудет, если они выложат «обфусцированные» исходники какого-нибудь Word 7.0. Зато Open Source и прочие радости :) Да и вообще хороший совет — хотите быть модными и опенсорсными? Выложите нечитаемые исходники!
Вторая. В современном мире Free Software «по Столлману» — это большая глупость, точнее, не глупость, а вредительство. Причем вредительство в интересах прежде всего Китая. Поясню. Если американская или европейская фирма попытается «присвоить» права на какую-нибудь опенсорсную мелочь, использовав ее в своем продукте, но не выложив исходники, то столлманы затаскают ее по судам. Если то же самое сделают китайцы — до них Столлман сотоварищи не дотянется.
Думаю, многие ковырявшие плеер из Vogue склоняются к мысли, что в качестве софта там стоит вариант MPlayer, распространяющегося на условиях GNU GPL. Кто видел в Vogue копию лицензии? Ответ: никто. Нет, конечно, если на плате в полнолуние нажать третью и четвертую кнопки одновременно, при этом замкнув пятую и двадцать пятую ноги флешки, то может быть, нам и покажут полный текст GNU GPL на китайском, но по-хорошему делавшие плеер китайцы плевать хотели на все лицензии.
Если хорошенько «поковырять» китайские «девайсы» — уверен, можно найти такие нарушения GPL, что всех китайских производителей быдлодевайсов можно отправить на урановые рудники. А реально GPL остается примером идеализма, мешающего использованию GPL-нутого кода теми, кто в этом заинтересован.
> Кстати, существуют ли обфускаторы Сишного кода?
COBF — http://www.plexaure.de/cobf/index.htm
пользовался, правда давно уже
Охъ.
Ну, то что Витус витает в каких-то там своих эмпиреях — это как бы уже и не новость, но ты-то чего? Возможность вот прямо щас слазить скользкими ручками в любой взятый наугад код нужна только красноглазикам, для всех остальных людей опенорс значит только одно: возможность форкнуть, когда припрет (см libraw и Тутубалина например). Читать код в этом случае все равно придется, и никакая документация от этого не спасет.
И, это, по судам таскают только тех, с кого можно что-нибудь слупить. Остальные же… правильно, всем похуй. Массовый американский софтопроизводитель в этом смысле ничем не отличается от массового китайского.
> возможность форкнуть, когда припрет
Правильно, это единственный «плюс» опенсорсности — когда нужен «такой же, но с перламутровыми пуговицами». Но что самое поганое — если перламутровые пуговицы нужны «уже вчера», в большинстве опенсорсных проектов невозможно разобраться быстро.
> по судам таскают только тех, с кого можно что-нибудь слупить
В Штатах слупить можно с любого, при определенном желании. Потом, в Штатах затаскать по судам реально, а в Китае — нет. Никто не мешает FSF-у использовать методы Microsoft-а (который в свое время судился по поводу и без повода, например, с «фирмешкой» Mike Row Soft) — и чем дальше, тем больше «линукс-вендоры» будут бороться за свои права. Nothing personal, just business.
Не согласен я с ними со всеми. Во-первых, внутренния документация нужна разработчикам, чтобы придерживаться стандартов. Для тех, кто пользуется чужим кодом она никуда не упирается. Во-вторых, «комментарии» — это пережиток 20 летней давности, когда переменные назывались i, ii и половина из них была глоабльными. При нынешних методиках программирования никому они уже нафиг убились. Java, PHP, C++ код читается легче и быстрее любой документации. При том, что обладает абсолютной полнотой и правильностью.
Про «копаниие в чужом коде» — это личное мнение товарища. Я своим наоборот говорю — ничто не заменит вам знание кода своих инструментов и библиотек. «Ненужная работа» — это зубрение документации, написаной ленивыми восточноевропейскими гастарбайтерами, которые нихера не знают продукта и знать не хотят.
Из практического опыта — пока есть доступ к исходному коду (Открытые Java, PHP решения) любой проект делается за предсказуемо конечное время. Бывают проблемы, но их всегда понятно как решать и заранее известно какое время максимально пойдет. Как только начинается Win32 или Cocoa — все труба — в любой момент жди «делаю, как написано в документации, а все равно не работает».
> При нынешних методиках программирования никому они уже нафиг убились.
Только где в опенсорсе «нынешние методики»? Не так уж и много проектов покрыто, например, нормальным и общедоступным набором тестов, я не говорю о чем-то большем. Насчет «ненужности» комментариев — предлагаю, например, написать что-нибудь вроде Perlin noise, а затем, месяцев через пять-шесть, вспомнить, что это такое и как изменяется.
> ничто не заменит вам знание кода своих инструментов и библиотек
Как обстоят дела со знанием кода gcc или GNU make?
> за предсказуемо конечное время
Согласен. Проблема в том, что при таких же «открытых исходниках» на C «предсказуемо конечное» время катастрофически растет в сравнении с Java и PHP.
:Только где в опенсорсе “нынешние методики”?
Да вся практически джава. Там уже по факту своя операционка и не одна написана и процентов на 90% открытый код.
:Насчет “ненужности” комментариев – предлагаю, например, написать что-нибудь вроде Perlin noise, а затем, месяцев через пять-шесть, вспомнить, что это такое и как изменяется.
А зачем? Вот перед глазами WordPress — php по сути тот же перл, но никакого нойза. Из недавнего у нас была проблема — не обновлялся магазин после оплаты с пейпала — задница жопная, так как все реквизиты вводятся на пейпале, то у нас в магазине есть покупка, но нет адреса куда ее отправлять. Решилось за 15 минут глядения в код и 2 часа дописывания обработчика IPN. А если б это была dll? Вешаться?
:Как обстоят дела со знанием кода gcc или GNU make?
«я стоял на плечах гигантов». Для решения проблем этих инструментов есть какая нибудь «Алена С++» или сгинувший где то в NYC John Gladkih.
А в чем заключается проблема с GNU мейк? Если оно того будет стоить, то пара человеко-недель решается практическую любую. Проблема с vcrt20.dll не решается ни засколько ни за какие деньги.
> Вот перед глазами WordPress – php по сути тот же перл, но никакого нойза.
Perlin noise не имеет никакого отношения к Perl, если чё.
:на C “предсказуемо конечное” время катастрофически растет в сравнении с Java и PHP.
не. Объем кода написанного на С на порядки меньше, чем того, что успели наворотить на джаве, так что где-то один к одному получается. Да и не так страшен С, как его ублюдок. Оба его ублюдка.
Если говорить о равном объеме кода, естественно.
это надуманная постановка вопроса. Из опыта проверенно, что приблибизительно равный функционал на Java,C и MVS/HLASM подразумевает пропорцинальное уменьшение количество кода. Так, что расковырять проблему с юникодным текстами в OpenSymphony based J2EE приложении (каждый прочитанный блок конвертируется, потом объеденяется — трехбайтовые японские символы на границах буфера разваливаются), подправить драйвер для PAL-версии AverMedia в линуксе и взять на саппорт IBM Tivoli Output Manager на ассемблере вещи одного порядка сложности.
:и спросите, где реализована функция printk()
grep -r printk|grep …|grep …|grep -v …|grep -v…
это если не заморачиваться на ctags