Adamos

for i in `find /yourdirectory -type f`;do sed -i 's/чтоменять/начтоменять/g' $i;done
с gui вот скрипт:
a=`zenity --entry --text="Что меняем" --entry-text=""`
b=`zenity --entry --text="На что меняем" --entry-text=""`
for i in `find /yourdirectory -type f`;do sed -i "s/${a}/${b}/g" $i;done

MySQL не поддерживает ASSERTION.
Используйте триггеры BEFORE INSERT и BEFORE UPDATE.

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

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

Внутри 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 спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

Создавать GUI с помощью WinAPI - это, конечно, очень полезно с точки зрения своего развития, но... сейчас мало кто этим занимается. Есть Qt, есть GTK, есть <вставьте свое название>, которые заметно упрощают разработку пользовательских интерфейсов. Если вам будет необходимо создавать сложные интерфейсы (вспомните MS Office или Adobe Photoshop) - стоит выбрать что-то из этого и использовать, но в случае с разработкой игр ситуация немного другая: в играх интерфейс такого рода обычно не нужен. Вообще. Там обычно только одно "главное меню" и немножко элементов интерфейса, которые мало похожи на то, что вы видите в среднестатистическом приложении. Поэтому (личное мнение) если вы хотите заниматься разработкой игр, вам стоит изучать то, что в них более востребовано - например SDL. И сразу читать что-то вроде SDL Game Development и писать. Через некоторое время будете делать 2D-игры без проблем (со звуком, спрайтами, клавиатурой/мышью/джойстиком, нормальными уровнями, и.т.д.) и, заодно, поймете принципы создания архитектуры подобного рода проектов. А потом смотреть в сторону каких-либо физических движков или углубляться в графику (OpenGL/DirectX).

Да.

Так вы разделите классы ComPort и Device.
И при создание обьекта Device передавайте в него обьект ComPort.
Наследование в вашей задаче не нужно.

https://habrahabr.ru/post/259505/ — вот этой книги должно хватить с головой.

Хотя тему байтов, битов, кодировок и битовых операций любой вузовский учебник раскроет на достаточном уровне, чтобы изучать С, С++.

Приветствую.
Прежде всего, не стоит представлять себе решение задачи, как "большую кнопку", т.к. наши представления об управлении инфраструкурой несколько извращены опытом работы с продуктами MS. Интерфейс скрывает от нас стек ПО используемого для достижения цели. Например, WSUS. Под его капотом находится набор служб, каждая из которых играет определенную роль - bits для загрузки на сервер и доставки пакетов на клиента, веб-сервер для управляющих команд, база данных для хранения состояния клиентов и исправлений, .net приложение, обьединяющее все это. Для парка nix машин вам предстоит построить подобную архитектуру самому, выбирая каждый раз инструмент, который будет играть ту или иную роль.
На втором шаге вам нужно посмотреть на задачу. Если у вас десяток инфраструктурных серверов, то Ansible действительно неплохой выбор. Но только не "скрипт". "Скрипт" - это язык, который говорит как достичь результата. Но инструменты управления конфигурацией избавляют вас от этого, с помощью декларативного языка вы описываете сам конечный результат(это ключевой момент) и не задумывайтесь о том, какой дистрибутив (читай менеджер пакетов, расположение конфигурационного файла) установлен на управляемой системе.
Если вам нужно дать доступ большому количеству пользователей к большому количеству машин, то на первом шаге вам нужно выбрать два инструмента:
1. управление конфигурацией.
2. управление sudo.
Первый инструмент с натяжкой может предоставить вам возможность решить пункт 2, т.к. в этом втором пункте вам нужно управлять теми самыми политиками: группе пользователей дать доступ на группу машин и разрешить выполнять группу команд. Здесь в игру вступает Identity Manager и этот вопрос для меня по крайней мере, открыт. Текущие тенденции ведут к развертыванию двух каталогов (MS AD и каталог для парка NIX), но не берусь сказать насколько это правильно. Обойтись без второго каталога можно и, если отбросить шелуху, то ключевой проблемой, в таком случае, является сопоставление идентификаторов безопасности пользователей в MS AD и в nix системах (просто когда один домен, сложнее когда лес, совсем не просто в случае созданных вручную доверительных отношений). Раньше этот вопрос решал winbind с набором библиотек, реализующих тот или иной алгоритм сопоставления, теперь это SSSD, реализующий два алгоритма. Опять же вопрос с выполнением привилегированных команд в такой конфигурации не решается. RedHat предлагает скомпанованные в единый продукт инструменты, которые, якобы эти задачи решают. Поддержкак от этого самого редахата стоит бешеных для нас денег, но вы посмотрите из чего состоят такие решения как Sattelit и IdM, это открытые продукты (FreeIPA, candlepin, pulp, katello, puppet и, наконец, foreman.) которые, возможно вам и нужны.

Задача сводится к выяснению того, сколькими кубиками (не способами, а именно кубиками) может быть задана исходная сумма (нижних граней).
Например, 1 может быть задано только 1-м кубиком, ответ - 1
2 может быть задано как 1-м, так и 2-мя кубиками, ответ - 2
3 может быть задано 1-м, 2-мя или 3-мя кубиками, ответ - 3.
Рассмотрим 4. Может быть задано от 1-го до 4-х кубиками. Т.е. ответ - 4. Рассмотрим случай 2-х кубиков. Это могут быть комбинации 2 + 2 или 1 + 3, но оба они дадут одну и ту же сумму верхних граней: 6 + 6 - (2+2) или 6 + 6 - (1+3), что явно одно и то же.
У разных же количеств кубиков сумма разная, так как разное кол-во 6-к (самых больших чисел).

Итак, надо выяснить, сколькими кубиками можно задать сумму s. Понятно, что если s ≤ 6, то любым кол-вом от 1 до s. Но если s > 6, то одним кубиком уже не задать. Если s > 12 (6 * 2), то не задать уже и двумя.
Т.е. если s > 6, надо вычесть 1, если s > 12, надо вычесть 2, если s > 18, то вычесть 3.
Или, иначе говоря, если s > 6k, надо вычесть k. k можно посчитать как (s - 1) / 6 (целочисленное деление). Как только s становится больше 6k, то есть становится 6k + 1, получаем (6k + 1 - 1) / 6 = k. Если же s = 6k, то (6k - 1) / 6 = k - 1, что нам и надо.
Т.о. результат: s - (s - 1) / 6, что эквивалентно вашей формуле, так как
(s + 5) / 6 = (s - 1) / 6 - 1
(s + 5) / 6 - 1 = (s - 1) / 6

Когда я захожу на определенный сайт, провайдер видит URL?

Да.

А если я захожу на https?

Известен IP сервера и имя домена. Больше ничего.

Откуда провайдер узнает, что я скачиваю определенный фильм/программу через torrent?

Торрент-клиент общается с трекером по HTTP. Все видно насквозь: конкретные торренты + вся статистика (когда начато скачивание, когда закончено, когда пошла раздача, сколько роздано). Возможно подключение к трекеру и по HTTPS, но rutracker.org такой возможности не дает (мне тоже интересно почему).

Все пакеты которые я получаю и раздаю значит провайдер скачивает себе, чтобы узнать что это за фильм/программа?

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

Или он отслеживает факт скачивания .torrent файла, а затем делает вывод по идущим пакетам, что это скачивается?

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

Когда я пользуюсь VPN, что видит провайдер?

Видит шифрованный траффик на конкретный IP. По IP можно узнать, что этот диапазон продается под VPSы. Сам факт шифрованного трафика вешает абонента в списки тех, "кому есть что скрывать", а значит подозреваемых при любом розыске.

Что я зашел на определенный IP и с него идут зашифрованные потоки?

Дальнейшее направление трафика от VPN-сервера отследить невозможно (по крайней мере, на оборудовании провайдера в автоматическом режиме). Но при целенаправленной слежке за абонентом в принципе возможно по временным меткам сопоставить трафик абонента с трафиком любого сервера.

OpenVPN будет работать через VPN IP и в браузере и при обновлении Windows, драйверов, ...?

В зависимости от настройки. Но в общем случае, да, так.

Читал, что в Windows есть такая особенность, что если провайдер как-то урезает пакет, то VPN отключается и сайту показывается мой реальный IP?

Это не связанно с провайдером. Это особенность Windows. Когда VPN отваливается, весь трафик вылетает наружу в открытом виде. Опять же зависит от настроек. Но это еще одна цена "удобства" при использовании Windows.

При этом провайдер видит на каком я сайте, что скачиваю?

VPN отвалился - хацкер спалился.

Таких фишек много?

Смотря о чем речь. В сфере сетевой безопасности и анонимности различных нюансов вообще много.

Как от них защитится?

Учить мат.часть. Разбираться в сетевых протоколах и в устройстве ОС.

Если пользуюсь каким-то расширением типа ZenMate, dotvpn, провайдер аналогично как и с VPN видит что что-то отправляется и приходит на определенный VPN IP?

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

При использовании Tor, кто-то пользуется моим IP, пока я пользуюсь чужим?

Нет. Если у вас не сконфигурирован Exit Node.

Что при этом видит провайдер, что я получаю потоки данных с определенных IP и каждый раз разный IP?

У них есть система точного обнаружения использования Tor. Это факт остается в логах с теми же последствиями, что и для VPN.

Провайдер видит URL?

Через Tor и VPN - нет.

Каким образом можно полностью управлять сетью на ПК, видеть что, куда и когда отправляется или приходит на ПК (Windows, Linux)?

Видеть все: https://www.google.com/search?q=Wireshark
Блокировать все лишнее: https://www.google.com/search?q=Comodo+Firewall

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