gribozavr

Я думаю, что либо C, ибо классика плюс алгоритмы — все там, только с указателями конечно засада..., либо Python ибо тоже классика, но свежее и с прицелом на параллельность вычислений, за которым собственно будущее.

www.khanacademy.org/science/computer-science — на всякий случай.

Postscript — интересная штука, совершенно без шуток ;-)
Можно упомянуть javascript.
Scala, Common Lisp, C++ — для общего развития.
Специализированные языки вроде R — для статистической обработки данных.
Prolog, SQL — для понимания.
Haskell, Clojure, D, Erlang, Scheme, Forth,… — ну, не знаю, для интереса.

Мне кажется что показать стоит всё, но особенно интересен R, понимание SQL тоже очень полезно.

Текст и картинка разные вещи. Текст печатается с разрешением принтера (например, 300 dpi — это достаточно низкое разрешение, недостатки будут заметны невооруженным глазом), а картинка — с линеатурой растра (например, 75 lpi — это, напротив, довольно высокая линеатура). Если печатать текст картинкой, он всегда будет дробиться растром, тут ничего не сделать. Копайте все-таки в сторону измерения длины строки как-то.

«Обычно» при постановке подобной задачи ставится вопрос о достаточно больших значениях n, а также о нахождении не всех, а m наиболее часто встречающихся последовательностей (в примере результата ведь нету подстроки «Карл у Клары украл кораллы, а Клара у Карла украла кларне» (исходная минус один символ), которая встречается один раз).
Соотвественно, алгоритм с n^2 плохо себя поведет.

Я не гуру, но сдаётся мне, что O(n2) — вполне достойно, по-крайней мере в той формулировке, что я понял. Ведь результатом должен быть отсортированный массив строк размером от n (исходная строка «аа… а») до (1+n)*n/2 (исходная строка «abcd..»). С введением ограничения на размер подстроки, быть может, получится и улучшить эффективность алгоритма.
А вообще, как говорил Пайк:

Правило 3: Изощрённые алгоритмы являются медленными, если n мало, а n обычно мало. В изощрённых алгоритмах присутствуют большие константы. До тех пор, пока вы не убедитесь, что n часто становится большим, избегайте изощрённости. (Даже если n становится большим, вначале используйте правило 2).

Ну или да как вариант у любой ОС, будь то Windows или GNU есть возможность подготовить unattended установку (так называется для винды, для различных дистрибутивов Linux есть FAI и т.н. preseed).

Делать 4 таблицы (коммент запроса, похожие фильмы запроса, коммент ответа, фильмы ответа) не очень хочется во нескольким причинам:
слишком много запросов в БД будет на получение списка запросов на просмотр

Ерунда, тут всё можно получить в один запрос. И не слишком-то медленный.
Вообще, у вас странная формулировка. Правильно хранить так, как удобнее доставать. Но как доставать нужно вам пишете только мельком. Поэтому пока храните в mysql нормализированно, 4 таблицы это правильно. Если (точнее когда) надо будет ускорить — денормализируйте, только в ту сторону в которую вам надо, а пока не ясно куда.

Делать 4 таблицы (коммент запроса, похожие фильмы запроса, коммент ответа, фильмы ответа) не очень хочется во нескольким причинам:
слишком много запросов в БД будет на получение списка запросов на просмотр (запрос, фильмы, кто, что советует)
слишком много лишних телодвижений будет и при ответе

Что значит слишком много? По сравнению с чем?

Вообще, 4 таблицы — это будет нормализированный способ хранения ваших данных. Можно и денормализировать, но это ухудшит расширяемость и возможности по манипуляци данными средствами SQL. Иногда денормализация приемлема, просто нужно в полной мере осознавать, какими будут последствия.

Например, можно сделать две таблицы: Comments и CommentMovies. В Comments добавить поле IsQuestion, в котором хранить TRUE, если это вопрос и FALSE, если это ответ. CommentMovies будет хранить фильмы как для вопросов, так и для ответов.
Минусом такого подхода будут проблемы функциональной расширяемости. То есть, если вы захотите добавить в таблицу Comments поле, присущее только вопросам, то у вас будет, по сути, три пути:
1) Рефакторинг структуры: разделение на ваши исходные 4 таблицы. Это трудозатратно;
2) Добавление ещё одной таблицы: QuestionCommentFields. Структура получается корявой;
3) Создание поля, которое будет хранить значения только для одного типа строк. Это уже денормализация.

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

В общем, выделите для себя какие-то приоритеты и путеводные камни. Будет ли структура часто меняться в будущем, важна ли простота поддержки? Важна ли скорость выполнения запросов, важна ли возможность менять данные напрямую SQL'ем? И т.п.

Самое эффективное — Qt и C++.
1. Среда разработки и неплохая идет в комплекте, есть дизайнер формы
2. Довольно много готовых примеров и приложений в которых всегда можно посмотреть пример реализации
3. Бинды на Python и других языках
4. На C++ много готовых библиотек, которые можно использовать в своем приложении

Яву я тоже использую (Swing)
Но сейчас что-то серъезное пищут на Java2ee, а там, на мой взгляд довольно высокий порог вхождения

Че вы все свое старье хвалите?
Javascript в браузере

Слушай, мужик, может ты себе нервы и время сэкономишь? Учись Python ;-)

Как пхп-шник с шестилетним стажем, посоветую начать с другого языка, например с java или c# =)

Не совсем понятны задачи сервера… Сколько участников в проекте. Доступ к репе по локалке или с публичных сетей тоже? И таки да, почему http? Чем не подходит стандартный ssh-транспорт?
Сами пользуем Gitolite и вам настоятельно советуем…

А почему хотите использовать http-метод? ssh для пуша не подходит?

ясен пень, всё нижеперечисленное нужно делать с копией ФС, дабы окончательно не потерять если ещё есть шанс

1. tune2fs -l /dev/sd? — что говорит? (Команда означает «напечатать содержимое суперблока в человеко-читаемой форме»)
2. если tune2fs показывает какие-то «лишние» флаги и т. п. — их можно пофиксить с помощью debugfs set_super_value (читать ман!). И вообще, debugfs продемонстрирует, можно ли что-то сделать с ФС, или уже всё. Кстати, с помощью неё можно и дёрнуть запасные суперблоки, если их содержимое отличается и более адекватно — вам повезло. после этого — fsck

кстати, может помочь просто fsck с указанием другого (запасного) суперблока для чтения информации об ФС

Начать с английской википедии (там информация довольно быстро обновляется) и далее по ссылкам.

Лично я не вижу никаких плюсов в пользу MAC на PC, скорее всего все задачи, которые отмечены вами, можно будет вменяемо выполнять, за исключением тестов кроссбраузерности при вэб разработке(большинство браузеров работают под Windows или используются под Windows пользователями, по большей части). Давайте предположим что завтра перечень выполняемых задач расширится и вам понадобится, например 1С или ещё что-то в этом духе, какие-то бизнес приложения, которые широко распространены, но под MAC не работают, на этом этапе вы столкнётесь с проблемами совместимости. С точки зрения лицензионности и MAC и Win коммерческие, графические приложения так же коммерческие, получается что и с этой стороны вы ничего не выиграете. Вот такое моё личное субъективное мнение по вашему вопросу.

Алекс Экслер «Записки невесты программиста»