O Di

Оставшийся lock говорит о нештатной остановке VNC Server.

Причину можно посмотреть в /var/log/x11vnc.log
(или по другому пути, который был указан в конфиге/аргументах запуска сервера)

Если полезных данных там нет, можно проверить,
не закрывается ли он системой от OOM: dmesg | grep "kill"

UPD:
TightVNC 1.3.9 известен случайными segfault-ами. В сети очень много примеров.
Судя по слухам, в версии 1.3.10 они исправлены, но с установкой этой версии могут быть трудности (её нет в пакетах, нужно собирать самому; она имеет другие ошибки).

Самым простым решением будет перейти с tightvncserver на x11vnc, vino или другие аналоги.

На данный момент лучше чем squid и lightsquid ничего не придумали

1. Отображение формы клиенту, GET
   
2. Клиент заполняет форму и отправляет запрос, POST
   
3. сервер обрабатывает параметры с формы и выводит результат в другой странице. Ждёт "дальнейших указаний" от пользователя (опционально).
   

1. Установка минималистичного фреймворка SinatraRb
gem install sinatra

2. Файл Gemfile в корне проекта

source 'https://rubygems.org'

gem 'rack'
gem 'sinatra'
#gem 'haml'
#gem 'sqlite3'

и выполняем в командной строке команду
bundle install
(gem bundler - управление зависимостями gem - должен быть заранее установлен)

3. Файл config.ru в корне проекта

# config.ru (run with rackup)
require 'rubygems'
require 'bundler/setup'

Bundler.require

require './myapp.rb'
run Sinatra::Application

4. Файл myapp.rb в корне проекта

require 'sinatra'

get '/' do
  erb :index # Отобразить форму по пути views/index.erb. Erb - это код HTML с вкраплениями кода на Ruby
end

post '/do_it'
  "Thank you, #{params['name']}!"
end

5. views/index.erb

<form action="/do_it" method="post">
    <div>
        <label for="name">Your Name:</label><br>
        <input type="text" name="name"><br>
    </div>
    <button type="submit">Submit</button>
</form>

Дополнительно
Accessing the Request Object

Для работы с СУБД есть ещё простой гем DataMapper

Докер применяют по разному но основное применение - средство деплоя аля deb, rpm.
Вы вполне можете обойтись без него. Мало того, ненужно пихать докер повсюду это контр продуктивно.

Мало кому можно верить в интернетах? А советам как протестировать значит веришь?
Берешь свой типовой проект под Андроид который покупаешь компьютер.
И компилируешь.
Только я бы не дал непонятно что ставить на ноутбук. Может ты вирусы хочешь установить.
Дал бы попробовать ровно 1 - который ты окончательно выбрал и уже начинаешь оформление покупки.

1) тестировать можно диск, память, монитор, видеокарту, процессор.
Первая ссылка в гугле
pcpro100.info/monitoring-i-diagnostika-kompyutera-...
2) вопрос к магазину.
Удачной покупки.
Смотрите следующие ответы.

Сначало объясню на конкретном примере, а потом приведу архитектурное объяснение:
------------
Например, вы разрабатываете некоторый гейт-аггрегатор четырех систем. Одна из них на WordPress, другая на Drupal третья самописная на Django и четветрая: реалтайм чат на Meteor.js и Mongo.
---------
Проблема заключается еще и в том, что WordPress и Drupal требуют разных настроек PHP(или вообще разных их версий). А так-же разных настроек Apache/Nginx.
---------
Вам также нужно легко переключатся между системами базами, и желательно, каждую из них держать в отдельной папке в сабфолдере проекта(и без абсолютных линков, чтобы можно было легко заменять подсистемы в других проектах)
--------
Чтобы крыша не потекла не у вас ни у компьютера, ни у человека который будет это деплоить нужна система которая позволит:

• Инкапсулировать кишки каждого фреймворка/cms. Вот это не нормально.
  Это клиника. До создания докера люди этим честно занимались(часов 5 может уйти)
  
• Иметь стандартизированный интерфейс, котрый будет
  
  • достаточно абстрактным чтобы уйти от конкретных деталей каждой платформы
    
  • достаточно конкретным, чтобы абстракции не текли, т.е. не приходилось городить костыли чтобы обойти неуместную абстракцию.
    
  
  
• Иметь возможность композиции различных компонентов системы
  

=========
Штука в том, что у Докера это получилось. Это и вкусная система отзеркаливания системных портов/нужных папок, конфигурирование через переменные среды.
По факту же, контейнер ставится за пять минут(4 из которых скачивается) и тут же на месте конфигурируется в понятном и удобном интерфейсе.
==========
PS. Какой гений придумал html разметку в этом редакторе использовать. Это же неадекват, почему не markdown например.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

Я тоже долго не мог понять.
Подобрал такую аналогию - это как git для сервисов.
Например чтобы развернуть Elasticsearch надо установить яву - это отдельная эпопея, затем прописать репу эластика, сделать apt-get update, apt-get install, прописать в автостарт, установить плагин с русской морфологией, рестартануть эластик.
А можно один раз напистаь докер файл из двух строчек и потом одной командой "docker run yourlogin/elasticsearch" все это запускать на любой машине.

1. вы получаете окружение близкое или идентичное к продакшену.
2. вы получаете внятную консоль/шел из коробки.
3. вы избавляетесь от массы вопросов типа "на локалке все работает, а залил на сервер и получил жопу" (или наоборот).
4. у вас появляется более лучшее понимание как на сервере все работает.

при теперешнем развитие технологий и производительности железа, нет необходимости себя ломать.
можно попробовать в виртуалке (docker/vagrant)/дуалбуте и самому для себя решить стоит или нет.

Да. Книга "Банда четырех".

Да это разные ноутбуки. Основные отличия в следующем:

1. Игровой, обязательно есть мощная видеокарта + навороченная система охлаждения + хороший большой экран. При этом очень низкое время автономной работы, гигантский вес, в общем автономность стремится к 0. Удобство использования таким ноутбуком обычно не принимается в расчет, ведь вы всегда можете подключить свою внешнюю клавиатуру и мышь. Яркий пример ASUS G751JT. При этом, вам конечно никто не помешает и поработать на таком, но увы только рядом с розеткой.

2. Рабочий ноутбук, видеокарта обычно не сравнится с игровой, зато обладает низким энергопотреблением и не требует особого охлаждения. Все компоненты ноутбука четко заточены под высокую производительность именно профессионального софта, но не игр. Так же уделено много внимания удобству использования ноутбука, чтобы максимально снизить потребность внешних аксессуаров. Так же присутствует высокий уровень автономности, ведь часто вам может потребоваться поработать где-то в пути, в кафе и т.п. Типичный пример - Макбук Про (или Эйр в топовой комплектации). Да на них тоже можно немного во что-то поиграть, но это скорее исключение.

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

На видеокарте можно сэкономить ,если она не нужна.
Вам точно нужен ноутбук?
Стац комп будет почти всегда дешевле и проще апгрейдить., правда монитор еще нужен .