Задумывались ли вы о том, насколько архаичен дизайн операционных систем, которыми мы пользуемся в настоящее время?
Например, почему в Windows (включая 11-тую версию) основной диск с операционной системой называется
C
?C
?Здравствуйте Друзья!
По роду деятельности приходится немного писать на PowerShell. В результате родился Телеграм бот и на этом языке.
Это шаблон или "рыба". Начинка уже зависит от вашей фантазии. Проектировался для больших нагрузок, реализована многопоточная обработка сообщений.
Но через -AsJob мы не пошли. Всё сделано на Runspaces.
Обработка потоковых данных стала крайне важна в настоящее время. И на это есть веские причины, такие как:
Компании жаждут получать данный как можно быстрее, и переход на потоковую обработку будет хорошим способом уменьшить задержки.
Объемные неограниченные наборы данных, все чаще встречающиеся в современных бизнес процессах, могут быть легче обузданы применением систем, специально спроектированных для таких объемов информации
Обработка данных по мере их поступления распределяет нагрузку более равномерно по времени, приводя с стабильному и предсказуемому потреблению вычислительных ресурсов.
Несмотря на существенный интерес к потоковой обработке данных со стороны бизнеса, львиная доля таких систем оставалась относительно незрелой по сравнению с аналогичными системами, ориентированными на пакетную обработку данных, так что это привело к недавнему всплеску вдохновляющих разработок в этой сфере.
Как тот, кто работал над крупно‑масштабной системой потоковой обработки в Google на протяжении последний пяти с лишним лет (MillWheel, Cloud Dataflow), я, мягко говоря, в восторге от сложившихся тенденций. Я все также заинтересован в том, чтобы люди понимали, что именно системы потоковой обработки в состоянии выполнять, и как их использовать наилучшим образом, в частности, закрыв нехватку знаний, оставшуюся между существующими системами пакетной обработки и потоковыми. С этой целью замечательные ребята из O»Reilly пригласили меня предоставить письменную версию моего доклада «Say Goodbye to Batch» с конференции Strata + Hadoop World London 2015.
Основная задача любой операционной системы - предоставить приложениям возможность унифицированного способа доступа к ресурсам оборудования, а пользователю - запускать и останавливать работающие приложения.
Murmulator OS (далее MOS) не является исключением. Как намекает название, данная ОС разработана для Murmulator https://github.com/AlexEkb4ever/MURMULATOR_classical_scheme (далее просто Мурмулятор), который основан на ультрабюджетной плате Raspberry Pi Pico (процессор-микроконтроллер RP2040) + специальная плата расширения, подробнее про которую можно почитать на сайте https://murmulator.ru. Таким образом, Murmulator - полноценный ультрадешевый (бюджетная версия которого обходится не дороже $5) микрокомпьютер.
9 сентября Notion ограничит доступ к приложению из России: они обязаны это сделать, чтобы соблюсти новые законы США. Я почитал документацию и ответы техподдержки пользователям — рассказываю, что понял.
Если верить Notion, пользователей банить не будут. Приложение не будет открываться из России, но вы восстановите доступ, как только окажетесь в другой стране. Это значит, что, скорее всего, Notion можно будет использовать из России через VPN.
Сегодня многие полагают, что «Unix» и «Linux» — это одно и то же. Но по состоянию на 2024 год с большинством дистрибутивов, которые мы причисляем к «Unix» и «Linux» ситуация почти так и обстоит.
Но у Unix долгая история. Если у вас в распоряжении только известные сейчас системы Linux, то сложно размышлять о том «какова была ситуация на заре Unix», поскольку так много с тех пор изменилось.
Без лишних слов, если вы захотели запустить свой minecraft сервер, с полным доступом, кастомизацией, чтобы ни от кого не зависеть, в этой статье я подробно расскажу как это сделать.
ZX Murmulator - одноплатный ультрадешевый микрокомпьютер на основе платы Raspberry Pi Pico (далее "пика"), которая, в свою очередь, основана на микроконтроллере - RP2040.
RP2040 - одна из наиболее известных двухъядерных реализаций ARM Cortex-M0+ с 264 КБ встроенной SRAM памяти и от 2-ух до 16-ти МБ flash-памяти подключаемых по QSPI интерфейсу, распаянной на плате пики. Данный микроконтроллер легко гонится до 400 МГц без какого либо радиатора, не смотря на свои штатные 133. Что позволяет запускать на нём достаточно прожорливые задачи.
Доброго дня. Это мой первый пост на хабре, поэтому не будьте особо строги к нему.
В мире разработки, системного администрирования и DevOps не смотря на то, что давно существуют и заняли свою нишу инструменты, связанные с централизованным сбором, визуализацией и анализом логов (graylog, ELK/EFK, loki, loggly и другие), всё ещё существует необходимость периодически взять шашку в руки и поработать со старыми/добрыми (а может быть и не очень добрыми) текстовыми логами. За 21 год своей деятельности я успел побыть системным администратором, DevOps инженером, разработчиком, CTO и системным аналитиком, но необходимость периодической работы с логами неизменно присутствовала в том или ином виде всегда. Это может быть разбор вывода нового сервиса или контейнера на машине разработчика, что-то, что ещё не успели завести (или сознательно по каким-либо причинам не завели) на централизованную систему сбора логов или, например, сервис, временно включенный в режиме debug для поиска причин проблемы. Ситуаций бывает много и ситуации бывают разные, а текстовые логи были, есть и ещё долго будут с нами.
Все, кто как-либо связан с DevOps знают про такие утилиты как more, less, tail, head, grep, sed, awk (а кто-то и ещё десяток более специфичных) и при необходимости их используют, но из тех, с кем я общался, никто не подтвердил мне, что знает про lnav. Я и сам не знал и искал нечто подобное более десяти лет. lnav — это не просто швейцарский армейский нож в мире работы с логами, а целый космический корабль, на котором можно улететь в соседнюю галактику. Мой мир разделился на "до" и "после" знакомства с этой утилитой. Там, где раньше требовались часы, а то и десятки часов на анализ логов, теперь хватает считанных минут.
Примерно год назад я писал статью в которой приводил процесс поднятия узла анонимной сети Hidden Lake. По моим ощущениям статья получилась неудачной, т.к. в ней уделялось слишком много внимания деталям, из-за чего возникало сопутствующее представление о сложности подобного процесса. С тех пор прошло уже 11 месяцев, код сети Hidden Lake постепенно редактировался, некоторые схемы запуска изменялись, добавлялись новые возможности. Вслед за этим я решил выпустить более новую статью с целью удаления или переноса излишков информации в отдельные секции спойлеров или ссылки, а также с целью актуализации текущего процесса запуска и функционирования сети. В результате, статья должна получиться простой, минималистичной и понятной, буквально на пять минут чтения.
🔹В статье приведен краткий обзор термина «среда общих данных» (СОД) и история развития этого понятия. В основной части дается информация об имеющихся вариантах организации СОД, исторически сформировавшихся в строительной отрасли и получивших свое развитие.
🔹Автором предлагается теория уровней развития СОД, какими они были ранее и что ждет их в будущем. Показаны общие требования со стороны отрасли, предъявляемые к СОД и что необходимо делать для приближения, и достижения успешного результата применения СОД – повышение эффективности работ в строительных проектах на всех стадиях.
Привет, меня зовут Борис Литвиненко, я занимаюсь SRE и DevOps в Yandex Infrastructure. Такие задачи я решаю уже очень давно, последние 10 лет — в Яндексе.
Естественно, в инфраструктурных подразделениях мы не гнушаемся и разработкой: все описанные в этом материале события происходят в группе разработки сетевой инфраструктуры и мониторинга, где мы делаем всё, что касается сети и какой‑то автоматизации. А как вы понимаете, сетевая инфраструктура большей своей частью не может зависеть от остальных сервисов.
Сегодня я расскажу о нашей специфике обслуживания базовой части инфраструктуры и причинах, которые привели к необходимости всё стандартизировать, а также выбрать облачный подход и запуститься в k8s. Но давайте всё по порядку.
Когда бизнес-аналитика внедряется как корпоративный инструмент, ее пользователями становятся сотни или даже тысячи людей из разных подразделений. Кроме этого нередко результаты прогнозов, расчетов и визуализаций все чаще выкладывают прямо на порталы или открывают к ним доступ без авторизации, чтобы сторонние наблюдатели могли получить важную для себя информацию. Все это порождает проблемы конфиденциальности, которые раньше решались с помощью дублирования данных и создания нескольких контуров BI. Но, как говорится, «есть способ лучше»! Сегодня мы поговорим про механизм Row Level Security (RLS), который позволяет и BI предложить сразу всем, и доступ разграничить, и не плодить личные сущности. Ну а подопытным, которому мы будем ограничивать доступ в наших примерах, как вы уже догадались, будет Александр Сергеевич.
Когда компании только начинают рассматривать возможность переноса своих рабочих нагрузок в облако, они часто представляют его как идеальное решение, которое поможет решить все проблемы с масштабируемостью, доступностью и сокращением расходов на IT. Однако, иногда на пути к своей цели организации принимают неверные решения.
Все же пользуются компьютерной мышью, так ведь? Ну, большинство уж точно. А как бы мы с вами жили без гиперссылок? Видеосвязи? А без современного графического интерфейса с окнами?
И удивительно, что такая уйма всего инновационного была продемонстрирована публике буквально в один день — 9 декабря 1968 года. Этот исторический момент получил название «Mother of all Demos». А причастна к нему команда разработчиков из Augmentation Research Center (ARC) под руководством Дага Энгельбарта. Скромного инженера, который стремился сделать жизнь всех людей проще.
Имея за плечами опыт работы с Kubernetes в различных облачных провайдерах вроде AWS и Yandex Cloud я столкнулся с необходимостью развертывания кластера вне облака на виртуальных машинах.
В статье расскажу про то, как подготовить high-availability кластер, используя инструмент под названием RKE2 - Rancher Kubernetes Engine.
Основной признак начального уровня зрелости процесса управления программными активами – отсутствие качественных данных. Чтобы начать движение из этой точки в сторону повышения уровня зрелости, нужно правильно организовать сбор и валидацию информации о программных активах. В этой статье разберемся, где искать нужные данные о ПО и лицензиях, как их правильно собирать и анализировать.
Tesla решила адаптировать Ethernet к своим потребностям с помощью изменения протокола транспортного уровня. TCP был заменен на Tesla Transport Protocol over Ethernet, или TTPoE. TTPoE разработан как для обеспечения микросекундных задержек, так и для простой аппаратной нагрузки. Уровни нижнего слоя остались без изменений, что позволило протоколу работать через стандартные коммутаторы Ethernet.