В прошлый раз здорово пообсуждали тему намагничивания неодима вот тут. Но нерассказанной осталась история одной катушки. Не той, которую скрутило всмятку на первых этапах испытаний, а той, которая была задизайнена после такого эпичного фейла. В принципе, изделие должно было получиться простым: 20 витков эмальпровода, сложенного вчетверо, в два слоя, на каркасе диаметром 50мм и такой же примерно высоты. Но был нюанс — при прохождении тока 10кА (кило‑Ампер, значит), первое решение «по‑простому» быстро схлопывается из‑за возникающих в проводниках Амперовых сил. Так что надо было придумать что‑то покрепче и намотанное поплотнее, дабы не дать возможности проводникам перемещаться по катушке во время рабочего импульса.

Импульсный (пере-)магничиватель для неодимовых магнитов (из HDD). Много конденсаторов, толстый тиристор, пыщ-пыдыщ, всё как мы любим.

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

Задача выяснить, как влияет “быстрая” зарядка на скорость деградации Li-ion аккумуляторов в устройствах с высоким током потребления.

В рамках исследования провел ряд экспериментов. Эксперимент заключается в зарядке аккумулятора током в 4-5 раз выше номинального. Номинальный ток заряда для исследуемых аккумуляторов от 2 до 5А, я буду использовать ток 20А.
В результате эксперимента будет видно, как “быстрая” зарядка увеличивает скорость деградации аккумуляторов.

В качестве испытуемых выбраны Li-ion аккумуляторы Sanyo NSX и LG 18650HG2 в формфакторе 18650.Выбор формфактора обусловлен тем, что именно данный они чаще всего применяется в устройствах с высоким током потребления. А именно: аккумуляторный электроинструмент, электронные сигареты, мощные фонари и некоторые виды электротранспорта.

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

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

Я — ведущий гейм дизайнер с опытом разработки крупных, хардкорных проектов в жанрах от MMORPG и CRPG до мобильной MOBA. Почти три года мы с лучшим другом продюсировали, дизайнили, разрабатывали и занимались живым оперированием своих серверов по игре ARK: Survival Evolved. За это время мы неплохо заработали (в среднем проект приносил $6000-12000 gross ежемесячно). Конечно же, мы столкнулись с тонной сложностей и челленджей, и выучили много уроков. В этой статье я хочу не только рассказать о нашем приключении, но и поделиться выученными уроками. Оперирование кастомных серверов огромных франшиз типа Roblox, Fortnite или Minecraft и других игр похожа на разработку игр в классическом понимании, но имеет под собой свою специфику. Этот опыт будет полезен не только моддерам, но и разработчикам и продюсерам игр. 

ARK: Survival Evolved — ММО экшен от 1 и 3-го лица с крафтом, строительством и динозаврами. На динозаврах в игре можно охотиться, можно приручать, ездить на них, разводить и воевать с другими племенами в игре, и это основная фишка, привлекающая игроков. Но настоящая основная особенность игры в том, что карты — собственно, ковчеги, объединены в кластеры, внутри которых игроки могут беспрепятственно путешествовать между карт, превращая мир игры в настоящее ММО — в отличие от большинства остальных подобных игр. Это гениальная игра, о которой невозможно рассказать в двух словах, и она доводит своих игроков до настоящей аддикции, и те проводят в ней тысячи и десятки тысяч часов.

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?

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

Я понимаю, что пока, за использования VPN, аннонимайзеров и/или tor не применяют уголовные статьи, поэтому гораздо проще скачать какое нибудь приложение из магазина приложений и бесплатно воспользоваться им. Но где гарантия, что завтра они будут работать?

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

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

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

Интересно?

Можно с уверенностью сказать, что с момента публикации первой версии стандарта RS‑232 в мае 1960 года и по настоящее время, было написано приблизительно 10⁹ независимых реализаций UART на всём, чём угодно. Однако, подобно «Hello world» в мире прикладного ПО, а также мигания светодиодом — «Hello world» в мире цифровой электроники (сигнализирующий об успешной настройке оборудования и среды разработки) — процесс написания UART способен проиллюстрировать особенности языка или платформы, демонстрируя применение тех или иных синтаксических конструкций для решения практических, насущных и понятных проблем.

В данном цикле статей будет рассказано про написание модуля UART на SystemVerilog, про синтез данного модуля на различных платформах и про некоторые другие аспекты применения UART в ПЛИС. Но прежде, чем писать код, поговорим про сам протокол и про особенности аппаратной части вне контекста ПЛИС.

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

Это настолько просто сделать, что я даже не понимаю как вообще об этом можно написать полноценную статью. Весь туториал можно уместить буквально в один комментарий под постом, т. к. тут нет чего-то сверхтяжёлого.

Устранение неполадок сетевого подключения

• Визуальное отображение потери пакетов
• Анализ ретрансляции TCP
• График по пакетам с большой задержкой ответа

Исследование сессий прикладного уровня (даже при шифровании с помощью SSL/TLS, см. ниже)

• Полный просмотр HTTP-сессий, включая все заголовки и данные для запросов и ответов
• Просмотр сеансов Telnet, просмотр паролей, введённых команд и ответов
• Просмотр трафика SMTP и POP3, чтение писем

Давайте сразу вопрос на засыпку: может ли быть так, что клиент подключается, ну, например, к серверу www.python.org (самому настоящему, тому, к которому обращаются еще миллионы клиентов со всего мира), а потом использует его как прокси и гоняет через это подключение трафик до своего VPS для доступа в неподцензурный интернет? Если вы не уверены в ответе на этот вопрос или почему-то ответили "нет", то добро пожаловать в статью.

Я уже не раз рассказывал здесь о технологии XTLS-Reality (1, 2, 3) суть которой в том, что ваш прокси-сервер VPS может очень достоверно маскироваться под какой-нибудь популярный веб-сайт - принимать подключения, которые будут выглядит точно так же, как обращения к настоящему сайту, отвечать на них полностью аутентичным TLS-сертификатом, и в целом вести себя как тот настоящий сайт. Единственная проблема - сам IP-адрес. Немного подозрительно, когда к какому-нибудь якобы www.google.com постоянно обращается только один пользователь, а IP-адрес этого сервера на самом деле даже не относится к автономной сети Google.

Еще я рассказывал о разных вариантах проксировать трафик посредством вебсокетов и простых HTTP-туннелей через различные CDN, такие как Cloudflare и Gcore. Вероятность того, что под блокировку попадет вся CDN гораздо ниже, чем что забанят какой-то один сервер или диапазон хостера, но та схема требовала регистрацию своего домена для работы через CDN.

И наверняка многим в голову приходила идея, а нельзя ли как-нибудь совместить эти два механизма? Проксироваться через CDN, но при этом "прикрываясь" каким-нибудь чужим доменом? Ответ: да, можно, и сейчас мы посмотрим, как именно.

Предупреждение

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

Введение

Исследуемая crackme является оконным приложением, и написана на assembler. Наша задача состоит в том, чтобы понять алгоритм генерации ключа, найти валидный серийный номер (или номера), и написать кейген.

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

Сегодня я расскажу о замечательном инструменте под названием GOST. Не пугайтесь, он не имеет никакого отношения к ГОСТ-шифрованию или чему-то подобному, на самом деле это Go Simple Tunnel. Он действительно simple (простой) в использовании и настройке, но при этом невероятно мощный, поскольку поддерживает огромное количество протоколов и транспортов, из которых вы при желании сможете построить самые упоротые и бронебойные комбинации, а именно...