Я использую СПО и в качестве помощи помогаю развивать проект.
Одно дело когда я разрабатываю на компанию и она получает неплохой доход с этого, тут работаю за ЗП. И совсем другое дело, что наработки сделанные отправляю обратно в проект, этим я не только себя избавляю от накладывания патчей с каждой новой версией, но и надеюсь, что другие поступают также, избавляя от багов на которые я ещё не наткнулся.
Оригинальный автор статьи тоже начинал путь в СПО с корыстной целью улучшить свои знания в perl, он мог бы оставить наработки у себя, но выложил в открытый доступ и избавил других людей от повторения этих же операций по портированию и отладке, НО первоначальный стимул был «надеялся, что смогу улучшить свое знание языка».
Не понимаю многих которые считают, что помощь это:
1. нужно обязятельно помогать деньгами
2. нужно сидеть и кодить, кодить, кодить просив работу, семью.
Зачем?
Если у вас есть свободная монетка, можно и скинуть автору на пиво, ведь с помощью его программы вы сэкономили себе больше времени чем вам стоит заработать эту монетку. Если же нашли багу, но что вам стоит вместо того чтобы из версии в версии ругать программу и говорить какая она бажная зайти на сайт и ОДИН раз повесить баг, и его пофиксят, или разработчик программы, или вольный программер который вообще взглянул на эту программу только для того, чтобы улучшить свои знания в этом языке программирования.
Допустим у нас активно используется hadoop, я занимаюсь разработкой под него, можно сказать зарабатываю на еду с помощью свободного ПО. В процессе разработки уже пофиксил 3 бага (тикет в их жиру + прикладывание патча, уже внедрены в ветку). hadoop не первый проект с которым приходилось работать и слать патчи.
Могли зажать эти патчи у себя, типо мы пофиксили себе, а на остальных плевать. Но ведь на том и стоит СПО, что даже если каждый поправит или хотя бы сообщит по багу, то всем будет лучше, продукт развивается, стабилизируется и возвращаются в виде более цельных и рабочих решений нам же самим.
Так что прежде чем говорить про покушать, нужно сразу осмотреться вокруг и задуматься с помощью каких инструментов это покушать зарабатывается.
да, по поводу явы немного ошибся, уточняя вопрос по второй ссылке объяснение от самих gnu.
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
а у большинства продуктов в eula явно прописано, что реверсинженеринг запрещён.
Одно из основных отличий GPL и LGPL в том, что первая запрещает линковать модули под ней в закрытые приложениях, а LGPL позволяет это делать (на этом и выеждают многие разработчики: пижут закрытый софт, пижут LGPL библиотеку A которая в свою очередь дёргает популярную GPL библиотеку B, в итоге можно смело открывать A, так как она ничего не содержит полезного, но в тоже время позволяет осталять сам продукт закрытым).
но со стороны явы мы имеем «public interface MyLib extends Library», то есть уже идёт расширение/модификация кода и продукт по идее тоже должен быть уже под LGPL.
Вот из-за этого нюанса и висит вопрос, так как объяснений я пока ещё не встречал как его интерпретировать
в общем всё зависит от того как и где использовать, для внутреннего потребления сойдут обе, а вот если проект открытый и дописываешь функционал, то сразу нужно уточнить в каком виде примут твой патч.
да, увеливая размер хипа мы автоматически увеличиваем размед и eden, вот только нередко видел ситуации с 1.5G под old и 12M под eden, из параметров были только -Xmx1500m. поведение думаю вы себе представляете.
по поводу тормозов при нехватке permgen, то тут уже сама ява машина должна была ругаться усиленно в лог «java.lang.OutOfMemoryError: PermGen space», что уже должно было насторожить.
пост отписал не к тому что вы что-то неправильно делали, а к тому, что помимо permgen бывают различные ситуации, и к каждой проблеме нужно подходить внимательно.
Так же помимо размера permgen иногда помогает -XX:NewRatio который отвечает за молодое поколение
основной принцип работы gc:
заполнился eden? — чистим мертвецов, выживших закидываем в survivor
заполняется survivor? — меняем местами 2 наших слота survivor (с полным работаем, свободный становится активным, пошло заполнение с eden), вышившие в old
заполнился old? — ну тут уже глобал счастье, курите все пока мы разбираемся с мусором (а при большом heap дело нешустрое)
Основное правило явы «живи быстро, умри молодым», в случае недостаточного количества под young не выполняется.
По умолчанию выделяется достаточно низкий уровень, в итоге под нагрузкой eden забивается моментом, survivor тоже оказывается заполненный, а следовательно объект сразу попадает в old.
В итоге имеем ситуацию:
1. eden дёргается сборщиком мусора практически непрерывно, доп нагрузка на проц.
2. данные перетекают сразу в old, хотя уже в следующий момент оказываются мертвы и лишь занимают память, когда же заполниться old, то сборка по нему это уже совсем другая история с нагрузками на проц.
увеличивая размер eden имеем
1. eden заполняется постепеннь, выжившие зачастую влезают в survivor, так как те кто там уже были к этому времени почти все поумирали
2. old заполняется уже намного медленнее, следовательно глобальный сборщик запуститься позже или отработает меньше времени.
хотя слишком усердствовать тоже не надо, так как алгоритмы сборки мусора по old более оптимальны по скорости сборки и под большие объёмы, во всём нужно искать середину.
Я использую СПО и в качестве помощи помогаю развивать проект.
Одно дело когда я разрабатываю на компанию и она получает неплохой доход с этого, тут работаю за ЗП. И совсем другое дело, что наработки сделанные отправляю обратно в проект, этим я не только себя избавляю от накладывания патчей с каждой новой версией, но и надеюсь, что другие поступают также, избавляя от багов на которые я ещё не наткнулся.
Оригинальный автор статьи тоже начинал путь в СПО с корыстной целью улучшить свои знания в perl, он мог бы оставить наработки у себя, но выложил в открытый доступ и избавил других людей от повторения этих же операций по портированию и отладке, НО первоначальный стимул был «надеялся, что смогу улучшить свое знание языка».
Не понимаю многих которые считают, что помощь это:
1. нужно обязятельно помогать деньгами
2. нужно сидеть и кодить, кодить, кодить просив работу, семью.
Зачем?
Если у вас есть свободная монетка, можно и скинуть автору на пиво, ведь с помощью его программы вы сэкономили себе больше времени чем вам стоит заработать эту монетку. Если же нашли багу, но что вам стоит вместо того чтобы из версии в версии ругать программу и говорить какая она бажная зайти на сайт и ОДИН раз повесить баг, и его пофиксят, или разработчик программы, или вольный программер который вообще взглянул на эту программу только для того, чтобы улучшить свои знания в этом языке программирования.
Могли зажать эти патчи у себя, типо мы пофиксили себе, а на остальных плевать. Но ведь на том и стоит СПО, что даже если каждый поправит или хотя бы сообщит по багу, то всем будет лучше, продукт развивается, стабилизируется и возвращаются в виде более цельных и рабочих решений нам же самим.
Так что прежде чем говорить про покушать, нужно сразу осмотреться вокруг и задуматься с помощью каких инструментов это покушать зарабатывается.
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
а у большинства продуктов в eula явно прописано, что реверсинженеринг запрещён.
Одно из основных отличий GPL и LGPL в том, что первая запрещает линковать модули под ней в закрытые приложениях, а LGPL позволяет это делать (на этом и выеждают многие разработчики: пижут закрытый софт, пижут LGPL библиотеку A которая в свою очередь дёргает популярную GPL библиотеку B, в итоге можно смело открывать A, так как она ничего не содержит полезного, но в тоже время позволяет осталять сам продукт закрытым).
но со стороны явы мы имеем «public interface MyLib extends Library», то есть уже идёт расширение/модификация кода и продукт по идее тоже должен быть уже под LGPL.
Вот из-за этого нюанса и висит вопрос, так как объяснений я пока ещё не встречал как его интерпретировать
1. jni в некоторых случаях оказывается пошустрее (одна из первых ссылок в гугле stackoverflow.com/questions/1556421/use-jni-instead-of-jna-to-call-native-code)
2. нюансы с лицензиями (для примера из того же хадуп стека, что и касандра issues.apache.org/jira/browse/HADOOP-6767)
в общем всё зависит от того как и где использовать, для внутреннего потребления сойдут обе, а вот если проект открытый и дописываешь функционал, то сразу нужно уточнить в каком виде примут твой патч.
по поводу тормозов при нехватке permgen, то тут уже сама ява машина должна была ругаться усиленно в лог «java.lang.OutOfMemoryError: PermGen space», что уже должно было насторожить.
пост отписал не к тому что вы что-то неправильно делали, а к тому, что помимо permgen бывают различные ситуации, и к каждой проблеме нужно подходить внимательно.
основной принцип работы gc:
заполнился eden? — чистим мертвецов, выживших закидываем в survivor
заполняется survivor? — меняем местами 2 наших слота survivor (с полным работаем, свободный становится активным, пошло заполнение с eden), вышившие в old
заполнился old? — ну тут уже глобал счастье, курите все пока мы разбираемся с мусором (а при большом heap дело нешустрое)
Основное правило явы «живи быстро, умри молодым», в случае недостаточного количества под young не выполняется.
По умолчанию выделяется достаточно низкий уровень, в итоге под нагрузкой eden забивается моментом, survivor тоже оказывается заполненный, а следовательно объект сразу попадает в old.
В итоге имеем ситуацию:
1. eden дёргается сборщиком мусора практически непрерывно, доп нагрузка на проц.
2. данные перетекают сразу в old, хотя уже в следующий момент оказываются мертвы и лишь занимают память, когда же заполниться old, то сборка по нему это уже совсем другая история с нагрузками на проц.
увеличивая размер eden имеем
1. eden заполняется постепеннь, выжившие зачастую влезают в survivor, так как те кто там уже были к этому времени почти все поумирали
2. old заполняется уже намного медленнее, следовательно глобальный сборщик запуститься позже или отработает меньше времени.
хотя слишком усердствовать тоже не надо, так как алгоритмы сборки мусора по old более оптимальны по скорости сборки и под большие объёмы, во всём нужно искать середину.