MegaMufa

Мне известно четыре основных способа заработка, напрямую связанных со свободными программами:

— Первый, самый прямой, но от того почему-то всем не менее неочевидный — брать и продавать копии свободных программ. Аудитория: любые конечные пользователи. Примеры: Parted Magic, ряд программок для «Андроида», ну например, «Conversations». Высокоморальность: в полном порядке.

— Второй — это уже известная вами продажа поддержки. А фактически иногда и просто своего имени, когда какая-то реальная поддержка начинается с сумм несколько больших, чем базовый контракт. Аудитория: те, для кого ваша программа есть орудие производства, то есть компании и предприниматели. Пример: уже озвученный вами Canonical. Высокоморальность: в полном порядке.

— Третий — это продажа исключений из авторского лева. Аудиторией будут разработчики несвободных программ, а программа ваша должна быть библиотекой под (как нетрудно догадаться) авторским левом, причем чаще сильным. Суть в том, что для добрых людей ваш продукт свободен на условиях, скажем, GNU GPL или GNU AGPL, а проприетарщики пусть платят за возможность использовать его в своих шкурных интересах. Примеры: GhostScript, MySQL. Высокоморльность: прихрамывает маленько.

— Четвертый — это то, о чем помянул тов. CityCat4 — т. н. free crippleware, то есть полноценная ваша программа несвободна и платна, но у нее есть свободный урезанный вариант. Причем урезано может быть как что-то существенное, так и сущая ерунда. Аудитория: кто угодно. Примеры: Odoo, GitLab, ProcessMaker. Высокоморальность: от невысокой до никакой, смотря сколько отрезано.

И разумеется, все вышеперечисленно можно комбинировать: Qt, к примеру, и поддержку (обучение) предоставляет, и исключения из авторского лева (причем слабого!) продает, и совсем ерундовую несвободную часть имеет. А упомянутый вами Red Hat — продает копии и предоставляет поддержку. А иногда и такое бывает: программка для «Андроида» под названием OsmAnd полностью свободна, но поставляется в Гуглоплэе в двух вариантах: полном за копеечку и урезанном бесплатно. Еще раз: обе версии свободны, то есть никакой моральной проблемы здесь нет.

――

P. S. Я перечислил только способы заработка на программах как таковых, полагая, что схемы, где свободные программы участвуют косвенно, и без того очевидны, но в комментариях только о них и говорят, так что надо, наверное, упомянуть, что да, конечно, свободная программа также может быть:
— Частью продаваемой услуги — чаще всего услуги специфического хостинга, как ставимый здесь в пример Openshift или (если ближе к народу) Feedly.
— Частью продаваемого устройства, причем само устройство может быть как свободным, так и нет. Тысячи их.
— И наконец, просто частью приносящего прибыль техпроцесса. То есть компания пишет (заказывает) программу себе для внутреннего использования и могла бы ее вообще не распространять, но, не считая ее своим «ноу-хау», ведет себя благородно и просто свободно делится ею со всеми. Известнейший пример — Reddit (хотя в последнее время они подскурвились).

――

И не могу все-таки не отметить, что unix-way отношение к свободе имеет такое же, как мелкое к горячему.

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

sudo /lib/ld-linux.so /bin/chmod 755 /bin/chmod

Или:

sudo /lib64/ld-linux-x86-64.so.2 /bin/chmod 755 /bin/chmod

Или:

sudo /lib/x86_64-linux-gnu/ld-2.19.so /bin/chmod 755 /bin/chmod

Путь в разных дистрибутивах и разрядности может отличаться.

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

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

1) Разбиваем по категориям, каждую категорию - в свою папку. Если надо - еще подпапки.
2) Общий или старый код вынести в библиотеку, подключать только .h + .lib
3) Использовать систему контроля версий.
4) Ввести лимит по количеству строк на файл, перераспределять код таким образом, чтобы в одном .c файле было не больше 1000 строк (имхо даже 500 на с уже много. )

И да, и нет. Все зависит от цели. Постараюсь объяснить.

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

Пример:
я начинал с Доусона. Проработав капитально, взялся за Лутца. После - Fluent Python, Python Cookbook и иже с ними... (HTML, Django, CSS, работа над собственным проектом - это я все опускаю, как не относящиеся к сути вопроса детали. Говорим только про Python и книги.)

Так вот, к Доусону я больше не возвращался, к Лутцу - иногда возвращаюсь, а "иже с ними" я перечитываю по кругу и каждый раз открываю для себя что-то новое. Это, скорее всего, связано с тем, что всякий раз ты возвращаешься на исходную позицию с уже более прокачанными знаниями/пониманием, отстутствие которых не позволяет охватить все и сразу с первой попытки; плюс, каждый автор преподносит один и тот же материал с другой стороны (другими примерами), что дополнительно углубляет твое понимание пройденого.

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

Замечу, что все вышеописанное базируется на предположении, что вы стремитесь к максимальному развитию в рамках своей технологии. На мой взгляд, нельзя объять необъятное и хвататься за все сразу; step-by-step, как я говорил. Должна быть, по меньшей мере одна крепкая база + сопутствующее. Но эта база должна быть отшлифована до блеска, как птичьи плоды одного из небезызвестного персонажа из бронзы, расположеного на севере парка Боулинг-Грин в Финансовом квартале Нью-Йорка, в двух кварталах южнее Нью-Йоркской фондовой биржи.

Для меня такой базой, в настоящее время, является Python. Ему я и уделяю большую часть времени, распределяя оставшееся на Прочее. А вот когда я абсолютно и полностью исчерпаю Python - буду искать следующую Приоритетную цель на его место. И так далее. Процесс, фактически, бесконечен.

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

Ну а если все вышенаписанное не про вас, Python так, мимо проходил, тогда, может быть, да. Вот очень неплохой вариант.

P.S. Про литературу в целом можете посмотреть ТУТ.

https://habrahabr.ru/company/mosigra/blog/113876/
https://habrahabr.ru/company/xmlshop/blog/114014/
https://geektimes.ru/post/258762/
https://geektimes.ru/post/254122/

Судя по всему, единичные экземпляры - не очень реалистично.

вот этот работает подобным образом wordsfromtext.com

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

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

function setHandler(el){

   var obj = new MyController(el);

  $(el).on("click", function hand(){
      alert(obj.name);
  });

}

setHandler(element1);
setHandler(element2);

После выполнения данного кода в память браузера попадают:

• Функция setHandler
  
• Два объекта типа MyController
  
• Две функции hand - обработчики события onclick.
  

Да-да, для каждого вызова setHandler создается своя функция hand. Две (три, десять или даже миллион) разные функции с одинаковым телом. Все, что их отличает - область видимости, в которой они объявлены (к примеру, внутри каждой из них доступен свой obj).

Но, спрашивается, как мы можем оптимизировать потребление памяти в данной ситуации? А вот так:

function hand(){

  var obj = $(this).data("obj");

  alert(obj.name);

}

function setHandler(el){

   var obj = new MyController(el);

  $(el)
    .data("obj", obj) //Как вариант
    .on("click", hand)
  ;

}

setHandler(element1);
setHandler(element2);

Вынесем hand в более высокую область видимости.

Теперь в памяти сохранены:

• Функция setHandler
  
• Функция hand
  
• Два объекта MyController