JoveLebedev

Вот здесь задавали похожий вопрос.
у GRUB убирается настройка GRUB_HIDDEN_TIMEOUT=0 после чего меню не отображается, но в него можно попасть если при загрузке зажать shift.
Как-то так.

Привет,
Думаю, что практически у любого хостера VDS можно взять два VDS (KVM) и связать их по NFS.

Тонкий клиент на сервере. Vim + плагины+резервное копирование по cron. Подключаетесь к серверу удаленно с чего угодно и работаете.

Если есть доступ к интернету, то можно попробовать облачные IDE:

c9.io
Koding
Codeanywhere

и др.

Но насколько я понял, вам важно что бы работало без интернета, тогда может как альтернатива openserver есть www.easyphp.org, а для IDE думаю ничего лучше шторма нет :) Но если вы готовы пожертвовать на редактор, то можно использовать VSCode.

SSD во внешний Mobile Rack?

Сам учу андрюшу, SDK Android +Java+Android Studio+ курсы Devcolibri (здесь на хабре тоже есть уроки их), нормально заходит

Чистый ява или фреймворк?

фреймворков в том понимании к которому вы привыкли в веб разработке нет и еще не скоро появятся
если говорить про уровень входа то ios быстрее и легче android, я бы рекомендовал swift и ios, если с железом проблемы то android (я люблю android и java но ряд проблем делают разработку под android куда геморойней чем под ios)

Вот отличная статья на эту тему и с договором. habrahabr.ru/company/sibirix/blog/188690

$('#element').animate({width:'toggle'}, 350)

1) Хранить подобные данные можно, но никто не гарантирует объема хранилища, а так же сохранности содержимого.
2) Безопасно от кого? К сообщениям будет иметь доступ любой пользователь браузера на локальной ЭВМ.
3) Для протоколирования вкладок организуйте список уникальных ключей вкладок, установите время жизни этих переменных и обновляйте их раз в небольшой период.

Вообще по поводу всего этого мыслю, что хранить непосредственные конфиденциальные данные в незашифрованном виде в локальном хранилище не стоит. Используйте серверный вариант, а на клиенте храните хеши или guid ключи. Если же серверный вариант никак не пригоден, используйте шифрование методами javascript и внимательно следите за ключем, чтобы он не существовал в памяти браузера дольше, чем сеанс работы пользователя.

Рекомендую к использованию библиотеку jStorage.

Обращаю Ваше внимание на то, что не все браузеры поддерживают функционал надлежащим образом. Имейте бексовместимость.

Сайт builtwith для определения всего на любом сайте, включая серверные технологии, cms и тд.
Есть так же их плагин.

Саморез Самопис

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

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

Представьте, что вы отправляете копии пригласительные на свадьбу друзьям и родственникам. Каждая копия - это отдельная сущность. И если один приглашение разорвёт - то у остальных оно не должно разорваться автоматически. Кто-то захочет что-то на нём написать, например, телефон сантехника. Кто-то сомнёт и подложит под ножку качающегося стола. Кто-то сделает ксерокопию и пригласит ещё кого-то на вашу свадьбу без вашего ведома. При этом - это будут разные пригласительные, с одинаковым содержанием. То же самое с сообщениями и чатами.

Кстати, необязательно хранить систему личных сообщений в базе. Можно, но необязательно. Для этого даже тупо xml'ы/json'ы подойдут. Ведь что чаще всего нужно от чата собеседнику? Чтобы 1) отправить сообщение, чтобы его прочитали; 2) получить сообщение; 3) заглянуть в историю чата. Это прекрасно ложится на модель "каждому пользователю - по отдельной копии каждого чата". Да, денормализация, но почитайте выше пример про пригласительные и ксерокс. В вашем случае контроллер будет делать "ксерокопии" письма и отправлять их всем адресатам. А что с этим письмом делать дальше - уже дело каждого.

кусок верстки в студио, иначе не поймем что советовать...увидим на чем у вас они построены, мы же не ванги

Так вы напишите, как сами придумали и в чем сомневаетесь. А то получается не сайт советов и помощи, а сайт решения чужих проблем под ключ.