Выше я говорил как раз не про X forwarding, а про удаленное подключение через ssh туннель к уже работающему экземпляру X сервера, под которым залогинен локальный пользователь машины.
Если интересно, то можно почитать, например, здесь: http://www.umgum.com/xorg-x11vnc
В результате как раз должен получиться screen sharing. А X forwarding — это когда используется ssh клиент без туннеля, но с опцией -X.
Ну в общем-то, я сам пытаюсь работать по этой схеме. Обычно у меня получается так:
1. В начале разработки создаются 1-2 версии, которые пишутся с нуля, а затем просто выкидываются. Это позволяет доопределиться с функционалом, архитектурой, используемыми паттернами и т.д.
2. Далее используется именно цикл код->рефакторинг, причем рефакторинг двух типов — локальный (переделка отдельных функций, классов) и глобальный, сопровождаемый внесением изменений в архитектуру и базовые типы данных.
3. Если код становится совсем монструозным, цикл прерывается и пишется новая версия с нуля, из старого кода туда переносятся только реализации отдельных функций, алгоритмов, то есть мелкие куски. А архитектура разрабатывается с нуля с учетом опыта предыдущей версии.
Гентушный хендбук — это сурово. Может, для начала что-нибудь попроще? Типа Ubuntu, Debian или какой-нибудь Fedora? Там хотя бы есть гуяшный инсталлятор.
Обычно в описанных случаях я полагаюсь на два принципа:
1. Сначала делаю, чтобы работало хоть как-то, потом — чтобы работало хорошо. При этом потенциальные проблемы я просто выписываю на листочек, чтобы когда-нибудь потом с ними разобраться (когда они возникнут). Если они так и не возникают — значит, это все бред и ересь, и листочек можно спустить в сортир.
2. Пытаюсь внести устойчивость к ошибкам туда, где потенциально можно их быстро исправить. Если брать пример из статьи — я просто пишу данные в файл, а вот когда что-то не прочитается, приложение будет пытаться исправлять косяки в данных, задавать какие-то значения по-умолчанию, и т.д.
Когда я закончил универ, один из моих однокурсников устроился в какой-то банк и сейчас разрабатывает там ПО (может, и не ДБО, но тем не менее). Между тем, программирует он так, что я бы лично ему и разработку калькулятора не доверил. Вот что он там может понаписать хорошего?
Скорее всего, на них просто сэкономили, чтобы иметь возможность поставить хороший дисплей и батарею. Это хоть и мелочи, но они тоже денег стоят. Я лично с ними согласен, мне батарея и хороший экран важнее, хотя кому-то их будет не хватать. Но если хочется все и сразу — надо смотреть аппараты подороже.
ifstream, как таковой, не плох, но я не люблю, когда в коде появляется логика перевода типов данных одной библиотеки в типы данных другой. Эту логику ведь придется отлаживать, а потом еще и поддерживать. Я стараюсь этого по возможности избежать.
Для перевода на Яндекс.Деньги использую интернет-банк прямо из дома, комиссии нет (видимо, у них с моим банком договоренность). А насчет карты на Яндексе — недавно узнал, сейчас думаю заказать. Вот ее я может и привяжу к аккаунту на маркете.
Покупать что-либо в GooglePlay меня отпугивает тот факт, что они хотят мою карточку. Если приделают оплату через Webmoney или Яндекс.Деньги, я еще подумаю. А так нет, пожалуй. Пока бесплатным софтом попользуюсь.
А в каких ситуациях такая проблема может возникнуть? Ведь чтобы данные потерять, это ведь нужно, чтобы сервер неожиданно отключился и простоял выключенным 10 часов. Если отключится электропитание, то процесс переливания данных с i-RAM на SSD может пройти автоматически, пока работает бесперебойник, и тогда все будет нормально. Или Вы подразумеваете что-то типа выхода из строя блока питания?
P.S. У меня возникла неожиданная идея — ведь если у нас питания нет, то серверу об этом сообщит бесперебойник, и мы можем записать данные на безопасный носитель. А если есть, то мы в любом случае можем еще долго питать i-RAM от внешнего блока питания.
1. Ну раз хватает, так хватает :)
2. В случае ЧП за 10-12 часов базу с такого диска можно хоть на дискетки настрогать, а уж тем более не проблема перенести на обычный HDD или SSD.
Просто я подумал, что если производительности SSD вдруг будет не хватать, то i-RAM можно использовать в качестве «третьего слоя» над SSD.
Ну не скажите. Например, если главную страницу Яндекса со всей кучей виджетов запихать на мобильник, это будет просто ужасно. А так, в андроидном браузере у них совсем другой, простой интерфейс.
Выше я говорил как раз не про X forwarding, а про удаленное подключение через ssh туннель к уже работающему экземпляру X сервера, под которым залогинен локальный пользователь машины.
Если интересно, то можно почитать, например, здесь: http://www.umgum.com/xorg-x11vnc
В результате как раз должен получиться screen sharing. А X forwarding — это когда используется ssh клиент без туннеля, но с опцией -X.
1. В начале разработки создаются 1-2 версии, которые пишутся с нуля, а затем просто выкидываются. Это позволяет доопределиться с функционалом, архитектурой, используемыми паттернами и т.д.
2. Далее используется именно цикл код->рефакторинг, причем рефакторинг двух типов — локальный (переделка отдельных функций, классов) и глобальный, сопровождаемый внесением изменений в архитектуру и базовые типы данных.
3. Если код становится совсем монструозным, цикл прерывается и пишется новая версия с нуля, из старого кода туда переносятся только реализации отдельных функций, алгоритмов, то есть мелкие куски. А архитектура разрабатывается с нуля с учетом опыта предыдущей версии.
1. Сначала делаю, чтобы работало хоть как-то, потом — чтобы работало хорошо. При этом потенциальные проблемы я просто выписываю на листочек, чтобы когда-нибудь потом с ними разобраться (когда они возникнут). Если они так и не возникают — значит, это все бред и ересь, и листочек можно спустить в сортир.
2. Пытаюсь внести устойчивость к ошибкам туда, где потенциально можно их быстро исправить. Если брать пример из статьи — я просто пишу данные в файл, а вот когда что-то не прочитается, приложение будет пытаться исправлять косяки в данных, задавать какие-то значения по-умолчанию, и т.д.
Скорее всего, на них просто сэкономили, чтобы иметь возможность поставить хороший дисплей и батарею. Это хоть и мелочи, но они тоже денег стоят. Я лично с ними согласен, мне батарея и хороший экран важнее, хотя кому-то их будет не хватать. Но если хочется все и сразу — надо смотреть аппараты подороже.
… Начинаете ржать в неожиданных местах при просмотре фильмов про «хакеров»
P.S. У меня возникла неожиданная идея — ведь если у нас питания нет, то серверу об этом сообщит бесперебойник, и мы можем записать данные на безопасный носитель. А если есть, то мы в любом случае можем еще долго питать i-RAM от внешнего блока питания.
2. В случае ЧП за 10-12 часов базу с такого диска можно хоть на дискетки настрогать, а уж тем более не проблема перенести на обычный HDD или SSD.
Просто я подумал, что если производительности SSD вдруг будет не хватать, то i-RAM можно использовать в качестве «третьего слоя» над SSD.