По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Операционная система (ОС) это комплекс программного обеспечения, которое превращает груду железа, которую мы называем компьютер, в выполняющую сложнейшие вычисления машину. Сегодня на рынке две основных семейства ОС: Linux опенсорсная система, первый выпуск которой был в 1991 году, и Windows платная и пожалуй самая популярная на сегодняшний день операционная система.
/p>
В наши дни большинство пользователей предпочитает второй вариант, так как он удобней и легче. Но есть пользователи, которые не против попробовать что-то новое и, может быть, перейти на новую систему. Но переустанавливать свою систему не вариант. Во-первых, файловая система этих двух семейств ОС сильно отличается. И файлы записанные на диск в одной ОС, сложно считать на другой. Во-вторых, полное форматирования уничтожит все данные, а этого никому не хочется.
Можно попробовать установив на виртуальной машину, но если ресурсы хоста ограничены, то сложно оценить все возможности новой системы. Есть ещё вариант загрузки с Live-диска, но тоже неэффективно, так как тоже не может использовать все ресурсы физической машины. Но к счастью есть возможность попробовать новую систему на реальной машине при этом не теряя ни байта данных. В этой статье речь пойдёт как раз об этой возможности.
Наиболее распространённой версией *nix-подобных систем является Ubuntu. И мы тоже не будем оставать от моды и опробуем эту версию ОС. Для начала нужно скачать образ системы с официального сайта. На момент написания статьи последняя non-LTS версия 19.10, но каждый чётный год разработчики выпускают версию LTS версия с долгосрочной поддержкой, что гарантирует выпуск обновлений в течении пяти лет. А non-LTS поддерживается только в течении 9-ти месяцев. И на текущий момент LTS версия это 18.04. Его и установим.
Скачав образ системы его нужно записать на диск или флеш-карту. Дисками уже никто не пользуется, поэтому выбираем второй вариант. Чтобы создать загрузочный диск для Linux систем рекомендуется пользоваться утилитой Unetbootin. Но старый, добрый Ultra ISO тоже хорошо справляется. Вставляем флешку, запускаем программу от имени Администратора. Выбираем образ и кликаем на нем два раза.
Образ распаковывается в основном окне. Затем выбираем Bootable->Write disk image. Выбираем нужную флешку и нажимаем на Write. Программа предупредит, что на флеш-карте все данные сотрутся, нажимаем ОК и ждём окончания записи.
Для установки рядом с Windows 10 нужно предварительно подготовить свободно место на диске. Делает это через консоль управления жёсткими дисками. Освобождаем необходимое для установки системы место. Для тестовой среды хватит 60 Гб. Чтобы запустить консоль в поиске набираем diskmgmt. Кликаем правой кнопкой мыши на диске, который хотим разделить и выбираем Сжать диск (Shrink volume).
Система подсчитывает оптимальное значение, но если нужно изменить, то выставляем нужное значение нажимаем Сжать(Shrink) .
На этой неразмеченной области и будем устанавливать Linux. Перезагружаем систему и заходим в BIOS нажав F2 (на каждой материнке по разному), выставляем загрузку с флешки. Система запустится и откроется окно выбора языка:
Здесь предоставляется возможность протестировать Live версию системы, о чём уже упоминали выше. А мы выбираем язык и нажимаем Установить Ubuntu. Затем открывается окно с опциями установки. Можно выбрать Обычную версию, Минимальную версию, а также можно сразу установить ПО сторонних разработчиков таких, как драйвера и дополнительные кодеки:
Далее выбираем раскладку клавиатуры и нажимаем Продолжить. Рекомендуем сразу выбрать Английский язык, остальные можно добавить позже:
И на этом этапе установщик определяет, что у нас на диске уже есть система Windows и предлагает вариант установки рядом с ней. Мы же выбираем Другой вариант, чтобы иметь возможность гибко распределять место на диске:
На следующем окне видим как раз наши разделы с Windows и свободный:
Выбираем свободное место и нажимаем на плюсик. 20 гигабайтов выделим под корневую директорию, куда устанавливается сама система, своеобразный диск C на Windows которая обозначается прямым слэшем. В отличии от Windows, *nix системы используют прямой слэш, вместо обратного:
Под домашний каталог выделим 40 Гб. Это место где хранятся файлы пользователя:
А 8 гигабайтов выделим под раздел подкачки:
Нажимаем продолжить. Система выводит информацию о внесённых изменения и просит подтвердить их. Ещё раз нажимаем Продолжить и переходим к выбору часового пояса. После чего выходит окно создания пользователя:
Затем установщик начинает копировать файлы. При завершении установки система просит перезагрузиться. После перезагрузки открывается меню загрузчика GRUB, где можно выбрать какую систему следует запускать. По умолчанию стоит Ubuntu и если не предпринять никаких действий, через 10 секунд она и загрузится:
Вводим пароль, нажимаем Войти и вуаля, мы только что установили Ubuntu рядом с Windows не повредив ни одного файлика:
Вот и всё, удачи!
Все мы любим компьютеры. Они могут делать столько удивительных вещей. За пару десятилетий компьютеры произвели самую настоящую революцию почти во всех аспектах человеческой жизни.
Они могут справляться с задачами различной степени сложности, просто переворачивая нули и единицы. Просто удивительно, как такое простое действие может привести к такому уровню сложности.
Но я уверен, что вы все знаете, что такой сложности нельзя добиться (практически нельзя) простым случайным переворачиванием чисел. Но за этим стоит определенные логические рассуждения. Есть правила, которые определяют, как это все должно происходить. В данной статье мы обсудим эти правила и увидим, как они управляют «мышлением» компьютера.
Что такое булева алгебра?
Это правила, о которых я упоминал выше, описываются некой областью математики, называемой булевой алгеброй.
В своей книге 1854 года британский математик Джордж Буль предложил использовать систематический набор правил для работы со значениями истинности. Эти правила положили математическую основу для работы с логическими высказываниями. А эти основы привели к развитию булевой алгебры.
Для того, чтобы понять, что из себя представляет булева алгебра, сначала мы должны понять сходства и различия между ней и другими формами алгебры.
Алгебра в целом занимается изучением математических символов и операций, которые можно выполнять над этими символами.
Эти символы сами по себе ничего не значат. Они обозначают некую величину. Именно эти величины и придают ценность этим символам, и именно с этими величинами и выполняются операции.
Булева алгебра также имеет дело с символами и правилами, позволяющими выполнять различные операции над этими символами. Разница заключается в том, что эти символы что-то значат.
В случае обычной алгебры символы обозначают действительные числа. А в булевой алгебре они обозначают значения истинности.
На рисунке ниже представлен весь набор действительных чисел. Набор действительных чисел включает натуральные числа (1, 2, 3, 4, …), положительные целые числа (все натуральные числа и 0), целые числа (…, -2, -1, 0, 1, 2, 3, …) и т.д. Обычная алгебра имеет дело со всем этим набором чисел.
Для сравнения, значения истинности состоят из набора, который включает в себя только два значения: True и False. Здесь я хотел бы отметить, что мы можем использовать любые другие символы для обозначения этих значений.
Например, в информатике, как правило, эти значения обозначают через 0 и 1 (0 используется в качестве False, 1 – в качестве True).
Вы также можете сделать это более оригинальным способом, обозначая значения истинности какими-то другими символами, например, кошки и собаки или бананы и апельсины.
Суть здесь в том, что смысл этих значений останется неизменным, как бы вы их не обозначили. Но убедитесь, что вы не меняете символы в процессе выполнения операций.
Теперь вопрос в том, что если (True и False), (0 и 1) – это просто обозначения, то что же они пытаются обозначить?
Смысл, лежащий в основе значений истинности, исходит из области логики, где значения истинности используются для того, чтобы определить, является ли высказывание «Истинным» (True) или «Ложным» (False). Здесь значения истинности обозначают соответствие высказывания истине, то есть показывают, является ли высказывание истинным или ложным.
Высказывание – это просто некоторое утверждение, что-то вроде «Все кошки милые».
Если приведенное выше высказывание верно, то мы присваиваем ему значение истинности «Истина» (True) или «1», в противном случае мы присваиваем ему значение истинности «Ложь» (False) или «0».
В цифровой электронике значения истинности используются для обозначения состояний электронных схем «включено» и «выключено». Подробнее об этом мы поговорим позже в этой же статье.
Логические операции и таблицы истинности
Как и в обычной алгебре, в булевой алгебре также можно применять операции к значениям для получения некоторых результатов. Однако эти операции не похожи на операции в обычной алгебре, поскольку, как мы уже упоминали ранее, булева алгебра работает со значениями истинности, а не с действительными числами.
В булевой алгебре есть три основные операции.
OR: OR или "ИЛИ", также известная как дизъюнкция. Эта операция выполняется над двумя логическими переменными. Результатом операции OR будет 0, если оба операнда равны 0, иначе будет 1.
Для того, чтобы более наглядно продемонстрировать принцип работы этой операции, визуализируем ее с помощью таблицы истинности.
Таблицы истинности дают нам хорошее представление о том, как работают логические операции. Также это удобный инструмент для выполнения логических операций.
Операция OR:
Переменная 1
Переменная 2
Результат
0
0
0
0
1
1
1
0
1
1
1
1
AND: AND или "И", также известная как конъюнкция. Эта операция выполняется над двумя логическими переменными. Результатом операции AND будет 1, если оба операнда равны 1, иначе будет 0. Таблица истинности выглядит следующим образом.
Операция AND:
Переменная 1
Переменная 2
Результат
0
0
0
0
1
0
1
0
0
1
1
1
NOT: NOT или "НЕ", также известное как отрицание. Эта операция выполняется только над одной переменной. Если значение переменной равно 1, то результатом этой операции будет 0, и наоборот, если значение переменной равно 0, то результатом операции будет 1.
Операция NOT:
Переменная 1
Результат
0
1
1
0
Булева алгебра и цифровые схемы
Булева алгебра после своего появления очень долго оставалась одним из тех понятий в математике, которые не имели какого-то значительного практического применения.
В 1930-х годах Клод Шеннон, американский математик, обнаружил, что булеву алгебру можно использовать в схемах, где двоичные переменные могут обозначать сигналы «низкого» и «высокого» напряжения или состояния «включено» и «выключено».
Эта простая идея создания схем с помощью булевой алгебры привела к развитию цифровой электроники, которая внесла большой вклад в разработку схем для компьютеров.
Цифровые схемы реализуют булеву алгебру при помощи логических элементов – схем, обозначающих логическую операцию. Например, элемент OR будет обозначать операцию OR. То же самое относится и к элементам AND и NOT.
Наряду с основными логическими элементами существуют и логические элементы, которые можно создать путем комбинирования основных логических элементов.
NAND: элемент NAND, или "И-НЕ", образован комбинацией элементов NOT и AND. Элемент NAND дает на выходе 0, если на обоих входах 1, в противном случае – 1.
Элемент NAND обладает свойством функциональной полноты. Это означает, что любая логическая функция может быть реализована только с помощью элементов NAND.
Элемент NAND:
Вход 1
Вход 2
Результат
0
0
1
0
1
1
1
0
1
1
1
0
NOR: элемент NOR, или "ИЛИ-НЕ", образован комбинацией элементов NOT и OR. Элемент NOR дает на выходе 1, если на обоих входах 0, в противном случае – 0.
Элемент NOR, как и элемент NAND, обладает свойством функциональной полноты. Это означает, что любая логическая функция может быть реализована только с помощью элементов NOR.
Элемент NOR:
Вход 1
Вход 2
Результат
0
0
1
0
1
0
1
0
0
1
1
0
Большинство цифровых схем построены с использованием элементов NAND и NOR из-за их функциональной полноты, а также из-за простоты изготовления.
Помимо элементов, рассмотренных выше, существуют также особые элементы, которые служат для определенных целей. Вот они:
XOR: элемент XOR, или "исключающее ИЛИ", - это особый тип логических элементов, который дает на выходе 0, если оба входа равны 0 или 1, в противном случае – 1.
Элемент XOR:
Вход 1
Вход 2
Результат
0
0
0
0
1
1
1
0
1
1
1
0
XNOR: элемент XNOR, или "исключающее ИЛИ-НЕ", - это особый тип логических элементов, который дает на выходе 1, когда оба входа равны 0 или 1, в противном случае – 0.
Элемент XNOR:
Вход 1
Вход 2
Результат
0
0
1
0
1
0
1
0
0
1
1
1
Заключение
Итак, на этом мы можем закончить обсуждение булевой алгебры. Надеюсь, что к текущему моменту у вас сложилась неплохая картина того, что же такое булева алгебра. Это, конечно, далеко не все, что вам следует знать о булевой алгебре. В ней есть множество понятий и деталей, которые мы не обсудили в данной статье.
Чтобы понять сложные вещи, нам на помощь очень часто приходят простые примеры из жизни. Сейчас предлагаем просто посмотреть на свой шкаф: возможно там царит полный порядок, а возможно, анархия. Для нашего примера понадобятся оба! Для начала представим и заглянем в шкаф, где полный беспорядок: все намешано, найти что-то сложно (не говоря о том, чтобы это что-то еще и было не мятое). Переместимся в шкаф, где царит порядок, и там есть отдельные ящики для каждой категории одежды. Всё разложено по полочкам, и без труда можно найти всё, что нужно. Так вот, микросервисная архитектура по своей сути похожа на этот шкаф с идеальным порядком, только вместо шмоток — программные компоненты. Микросервисы — это не просто модный тренд в IT, а реальная необходимость для многих компаний. Почему? Потому что современные приложения становятся всё более сложными и большими, а пользователи всё более требовательными. Никто не хочет ждать, пока приложение загрузится, или терпеть сбои из-за одной маленькой ошибки. И тут то мир подарил нам микросервисную архитектуру, дабы все упорядочить.
Микросервисная архитектура — это подход к разработке программного обеспечения, при котором приложение делится на множество независимых компонентов (или сервисов). Каждый из них отвечает за свою конкретную задачу и может работать автономно. Как в нашем идеальном шкафу: отдельная полка для футболок, штанов, носков и так далее. Что еще более важно, если какой-то компонент вышел из строя: то все остальные продолжают свою работу как ни в чём не бывало. Погрузимся же глубже.
Почему именно микросервисная архитектура?
Чтобы понять, почему микросервисы стали такими популярными, стоит понять, чем они отличаются от монолитного подхода. Рассмотрим монолитное приложение как один огромный швейцарский нож. Да, он умеет всё: и резать колбаску, и открывать пиво, и чинить батарею. Но вот проблема: если один из инструментов сломается (например, лезвие затупится), то пользоваться ножом становится неудобно или даже невозможно. Но рассмотрим аналог швейцарскому ножу, т.е. простой набор инструментов: нож, открывашка, отвёртка — каждый из них работает независимо от другого. Если нож затупился, то всё ещё можно открыть бутылку. Неплохо, верно?
Монолитное приложение — это единый большой блок кода, где все части тесно связаны друг с другом. Например, если ты разрабатываешь интернет-магазин, то в монолите всё будет в одном месте: и корзина покупок, и система оплаты, и поиск товаров. Казалось бы, удобно? Только на первый взгляд. Проблемы начинаются, когда нужно внести изменения. Допустим, ты решил обновить алгоритм поиска товаров. Трогаешь одну часть кода, а что-то неожиданно ломается в корзине или на странице оплаты. Напоминает игру в дженгу и бесконечные попытки поймать все баги.
Микросервисы же работают по-другому. Здесь каждая функция приложения — это отдельный сервис. Есть отдельный «сервис корзины», «сервис оплаты», «сервис поиска». Они общаются друг с другом через чётко определённые интерфейсы (обычно через API), но при этом остаются независимыми. Если нужно обновить алгоритм поиска, просто меняешь код в соответствующем сервисе. Остальные части приложения даже не замечают этого.
Основные принципы микросервисной архитектуры
Если микросервисы — это оркестр, то принципы, о которых мы сейчас поговорим, — это дирижёрская палочка. Без этого вся система превратится в хаотичное звучание, где барабанщик ушёл в нирвану, скрипач — в классику, а пианист вообще ушёл пить кофе. Чтобы всё работало слаженно и красиво, существуют некоторые правила, о которых сейчас и пойдёт речь.
Начнём с того, что уже частично затронули выше, а именно - независимость компонентов. Каждый микросервис — это самостоятельный механизм, который просто работает свою работу. Да, это немного, но это честная работа. Независимость позволяет командам разработчиков работать автономно. Ты можешь обновлять или чинить один сервис, не боясь, что где-то в другом месте что-то сломается.
Далее в списке идёт возможность развертывания отдельных модулей. В микросервисах ты можешь развернуть (или обновить) только один конкретный сервис, а не всё приложение целиком. Поиграем снова в имадженариум, вообразим в этот раз интернет-магазин. Нужно улучшить алгоритм рекомендаций товаров. В монолите вам пришлось бы обновить весь код приложения, протестировать его и переживать за возможные сбои. А с микросервисами ты просто выкатываешь обновление для «сервиса рекомендаций», и всё остальное продолжает работать как ни в чём не бывало. Звучит как сказка, ну… почти)
Чёткие границы ответственности. Каждый микросервис отвечает за свою чётко определённую задачу. Что также удобно при работе в команде, ведь видно сразу разделение обязанностей не только в программных компонентах, но и среди разработчиков. Чёткие границы ответственности делают систему понятной и предсказуемой. Если что-то пошло не так (например, клиент не может оформить заказ), то не нужно ковыряться в монолите кода, искать, где конкретно и кто писал эту функцию, достаточно понять, какой именно это микросервис.
Окей, это было просто понять, но вот как микросервисы между собой вообще работают? Они же не должны работать всё равно вместе. Ответ прост и состоит из трёх букв – API (а вы о чём подумали?). Микросервисы общаются друг с другом через API (Application Programming Interface) — это чётко определённый язык общения между сервисами. Он позволяет каждому сервису быть независимым и при этом эффективно взаимодействовать с другими.
Познакомились с базой, так, а что там по соотношениям плюсов к минусам? Ща разложим карты и на это.
Плюсы, минусы и вызовы микросервисной архитектуры
Конечно же, начнем с плюсов микросервисной архитектуры (а ведь их реально много). Вот они, сверху вниз:
Масштабируемость.
В случае, если вашему приложению пришло время «подрасти», то с микросервисами достаточно просто добавить воды! Ладно, на самом деле увеличить мощность только необходимых сервисов или же написать новые, и не трогать остальные. Аналогично работает и с простыми обновлениями.
Независимость разработчиков по отдельности или же команд по отдельности
(в зависимости от масштаба). Они могут работать над своим микросервисом, не мешая другим. Результат? Быстрее, чище и без лишнего стресса. Тут в целом все просто. Как и во всем, если разобраться)
Надёжность
. Этого нам всем не хватает, а вот микросервесы умеют и делают. Если один сервис упал, остальные продолжают работать. Например, если в приложении временно недоступен сервис рекомендаций товаров (потому что кто-то где-то накосячил), пользователи всё равно смогут оформить заказ.
Плюсы простые, но безумно нужные. А теперь пришло время минусов.
Сложность управления.
Чем больше микросервисов, тем сложнее ими управлять. Прикинь, если бы у тебя было 50 котиков: каждый требует внимания, ухода и еды. В итоге ты больше времени тратишь на организацию, чем на саму работу.
Сетевые задержки.
Микросервисы взаимодействуют друг с другом через сеть, а это значит, что могут возникать задержки. Например, если «сервис корзины» медленно отвечает «сервису заказов», пользователь может подумать, что приложение зависло. А если сервисов много (как и предполагается), и если хотя бы некоторые из них медленно передают друг другу API, то скорости нам не видать.
Затраты
… Всего... Каждый микросервис требует своих ресурсов: серверов, баз данных и инструментов мониторинга, людей и печенек. В итоге можно потратить больше денег на инфраструктуру, что не всегда возможно, да и вообще нужно, особенно в небольших проектах.
Сложность тестирования
. Тестировать микросервисы сложнее, чем монолитное приложение. Это нужно убедиться не только в том, что каждый сервис работает правильно, но и в том, что они корректно взаимодействуют друг с другом. А это все тянет за собой все тот же пункт про затраты.
С глобальными минусами на этом все. Согласись, они были не столь очевидны. Немаловажным вопросом так же является вопрос «А когда микросервисы могут быть избыточными?»
Когда нужны микросервисы
Не всегда стоит бежать за модой и переходить на микросервисы только потому, что «все так делают, значит круто». Иногда это просто лишняя головная боль. И так, когда же?
Небольшие проекты или стартапы. Если проект небольшой (например, приложение для учёта личных расходов), то микросервисы будут избыточны. Также, если у команды банально нет опыта. Если команда никогда раньше не работала с микросервисами, переход на них может превратиться в кошмар из бесконечных багов и срывов сроков. Не того мы хотели ведь, правда? Исходя из статьи про затраты, не трудно догадаться, что если ресурсы ограничены, то микросервисы не наш выбор, ведь они требуют больше серверов, инструментов мониторинга и специалистов по DevOps, что не сочетается с маленькой командой и небольшим бюджетом.
Собственно, микросервисы – это очень крутая тема, но, как и все в этом мире, она хорошо работает только там, где нужна. Микросервисная архитектура – относительно новый тренд и как мы поняли, это очень классный тренд, помогающий увеличить эффективность разработки многократно на больших проектах. Следим за новшествами и дальше, кто знает, что изобретут уже завтра?