В 1952 году компания IBM, уже тогда известная своими новаторскими решениями в сфере вычислительной техники, представила миру свой первый электронный компьютер – IBM 701. Его появление стало началом нового этапа – эры цифровых технологий. Об IBM 701 мы упоминали в материале «История IBM: От табуляторов до суперкомпьютеров». В этой статье погрузимся в историю создания этого устройства и расскажем, что же сделало IBM 701 столь значимым.

IT-индустрия совершила интересный виток развития в последние десятилетия. На заре IT-революции, когда компьютеры были дорогими, их ресурсы, хоть и скромные по нынешним временам, нужно было использовать эффективно. Это привело к появлению многопользовательских OS, например, семейства UNIX, созданию компьютерных сетей и появлению протоколов удаленного доступа. 

Стремительное развитие производительности чипов и удешевление железа привело к революции персональных компьютеров. Однако опережающий рост вычислительных потребностей запустил развитие на новый круг. Сейчас найдется немного компаний и организаций, которые обходятся исключительно персональными компьютерами и сервисами в локальной сети. Когда-то диковинные IaaS, PaaS, SaaS, распределенные вычислительные технологии плотно вошли в жизнь. Доступ к удаленным системам — обыденная потребность не только для администраторов и программистов. Все знают о протоколах ssh, rdp, vnc, многие пользуются TeamViewer, AnyDesk, Remmina, X2Go и т. п. Ввиду того, что IPv4 сети и порожденный ими NAT пока еще более чем актуальны, не каждое из перечисленных средств позволяет подключиться к машине, находящейся за NAT, если у вас нет возможности пробросить порты.

Язык программирования Swift наиболее широко применяется в разработке программного обеспечения для операционных систем от компании Apple. Но не так давно появилась заметка, в которой говорится, что теперь на этом языке можно писать программы, основанные на GTK4+Libadwaita.

В статье рассмотрим несколько небольших примеров, иллюстрирующих применение Swift в разработке приложений для GNOME, а в конце создадим простенький генератор паролей.

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

Представьте, что у вас есть друг, который дает разные ответы на один и тот же вопрос в зависимости от того, как вы его задали. «Какая столица Перу?» получит один ответ, а «Лима — столица Перу?» — другой. Вы, вероятно, немного обеспокоены умственными способностями вашего друга, и вам почти наверняка будет трудно доверять его ответам. 

Именно это и происходит со многими большими языковыми моделями (LLM), сверхмощными инструментами машинного обучения, которые поддерживают ChatGPT и другие чудеса искусственного интеллекта. Генеративный вопрос, который является открытым, дает один ответ, а дискриминативный вопрос, который подразумевает необходимость выбора между вариантами, часто дает другой. «Происходит разрыв, когда один и тот же вопрос формулируется по-разному», — сказал Атул Пол Джейкоб, докторант Массачусетского технологического института.

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

Для демонстрации будем использовать модели caffe и onnx. Сервис напишем с использованием golang. Ниже приведен пример изображения, на котором распознан пол и примерный возраст человека. В нашем сервисе мы будем возвращать JSON, в котором будут указаны возраст, эмоции, пол и местоположение лиц на фотографии.

Все сталкивались с ситуацией, когда нужно было объяснять что-то другому человеку — будь то коллега, ребенок, друг или родственник. Иногда это происходит легко и непринужденно, а иногда… превращается в настоящую пытку. Особенно когда человек, которому мы объясняем, никак не может «включиться» и понять. 

 В такие моменты мы начинаем думать: «Как это можно не понять? Это же элементарно!» или «Он просто прикидывается, чтобы я сделал его работу!». Но, скорее всего, истина лежит гораздо глубже. Мы забываем, что когда-то и сами этого не знали. И в этом замешано проклятие знания.

Проклятие знания — ошибка мышления, из-за которой мы предполагаем, что другие люди обладают теми же знаниями, что и мы.

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

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

В прошлой части мы проецировали внешние контракты в DTO на примере REST. В этой будем проецировать методы контрактов в нечто, что позволит вызывать их вот так:

let! issues = gitflic.project.["kleidemos"].["myFirstProject"].issue.GET(limit = 24)

Имитация пути метода вызывает наибольший интерес, однако её реализации будет предшествовать ряд самодостаточных стадий.

Оптические нейронные сети, использующие фотоны вместо электронов, имеют преимущества перед традиционными системами. Но они также сталкиваются и с серьезными препятствиями.

Закон Мура уже работает весьма быстро. Он утверждает, что примерно каждые два года число транзисторов в компьютерных чипах увеличивается в два раза, и это приводит к значительному скачку скорости и эффективности. Но потребности в вычислениях в эпоху глубокого обучения растут ещё быстрее — темпами, которые, вероятно, могут меняться. Международное энергетическое агентство прогнозирует, что в 2026 году искусственный интеллект будет потреблять в 10 раз больше энергии, чем в 2023 году, и что центры обработки данных в этом году будут потреблять столько же энергии, сколько вся Япония.

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

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

В данном цикле я хочу поговорить об одном из вариантов представления REST-клиента. Но я буду обсуждать частное (REST), чтобы использовать его как точку опоры для перехода к общему — проблеме проекций внешних контрактов. В первых двух частях я сосредоточусь на синтаксисе и «архитектурных» ходах, а потом поговорю о генераторах кода. Сложность будет расти с каждой частью, но предлагаемые подходы даже в рамках одной части можно применять независимо. Например, сейчас мы поговорим про DTO (Data Transfer Object), в следующий раз — про перенос методов и их иерархии. Это близкие модули, но их взаимное влияние осознанно будет сведено к минимуму.

Ранее я накатал большой цикл по локальному F#-кодогену и высказал намерение периодически возвращаться к генераторам на примере каких-то узконаправленных задачек. Данный цикл — пробный шар в этом направлении. Он логически вытекает из последних двух частей цикла, так что осилившие «Большой код» смогут посмотреть на уже знакомые концепции немного под другим углом.

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

Учёные, занимающиеся информатикой, — это требовательная группа. Им недостаточно получить правильный ответ — цель почти всегда состоит в том, чтобы получить ответ как можно эффективнее.

Возьмем, к примеру, умножение матриц или массивов чисел. В 1812 году французский математик Жак Филипп Мари Бине разработал базовый набор правил, которым мы до сих пор обучаем студентов. Это работает прекрасно, но другие математики нашли способы упростить и ускорить процесс умножения матриц.

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

В конце прошлого года технологический гигант IBM объявил о том, что может показаться важной вехой в квантовых вычислениях: о первом в мире чипе под названием Condor, содержащем более 1000 квантовых битов или кубитов. Прошло всего два года после того, как компания представила Eagle, первый чип с более чем 100 кубитами. Казалось, что эта область стремительно движется вперёд. Создание квантовых компьютеров, способных решать полезные задачи за рамками даже самых мощных классических суперкомпьютеров, требует ещё большего их масштабирования — возможно, до многих десятков или сотен тысяч кубитов. Но это ведь всего лишь вопрос техники, верно?

Далеко не все работающие на сегодняшний день компьютеры и ноутбуки имеют объём оперативной памяти, гарантированно перекрывающий потребности возложенных на них задач. Для ноутбуков среднего и нижнего ценовых сегментов типовой задачей может быть работа с большим количеством открытых вкладок браузера, для более дорогих ноутбуков или системных блоков — ресурсоёмкие игры, рендеринг, видеомонтаж, для серверов — базы данных и прочие требовательные к RAM задачи.

Когда RAM близка к заполнению, данные неактивных в данный момент приложений начинают выгружаться из неё на диск, в файл или раздел подкачки. Когда при запуске ещё одного приложения, открытии файла или вкладки браузера, потребуется срочно освободить нужный для этого действия объём оперативной памяти, пауза в работе компьютера может быть заметна, даже когда в системе стоит SSD. На HDD же, в случае запуска ресурсоёмкого приложения, подкачка может приостановить работу и на несколько десятков секунд. Кроме того, постоянная подкачка на SSD приводит к его ускоренному износу, что с учётом цены SSD, также не лучшее решение.

Если типовые задачи вашего компьютера требуют в 2-3 раза больше оперативной памяти, чем стоит в системе, наилучшим решением будет её увеличение. Если установить больше памяти невозможно технически (самый, пожалуй, острый пример — нетбуки на процессоре Atom с максимально возможным объёмом RAM 2 Гб) — ресурсоёмкие задачи лучше перенести на более мощный аппарат, а этот использовать только для офисно-браузерных задач (отдать детям или родителям). В случае же менее значительной нехватки (в пределах половины имеющегося объёма RAM), есть возможность улучшить ситуацию.

В этой статье мы напишем небольшой сервис аутентификации на go с использованием токенов PASETO. Этот токен можно использовать вместо JWT для процесса аутентификации. Если хотите узнать о PASETO подробнее, то можете почитать статьи на Хабре или гитхабе.

Godot — игровой движок, который имеет нативную поддержку dotnet. К сожалению, эта поддержка до такой степени заточена под C#, что F# она выходит боком. Почти все проблемы разрешимы, но при недостатке опыта они скатываются в большой пластилиново-волосатый валик у самого входа в подземелье, который иногда приводит к преждевременной и бессмысленной гибели. Чтобы избежать этого в данной статье я дам программу-минимум, которая позволит выжить в Godot, но не выжать из него максимум.

Это не значит, что у сочетания F# + Godot нет своих плюшек. Просто мне хотелось съесть вначале сосредоточить всех мух в одном месте, а котлетами заняться потом и в более свободной манере. Также я предполагаю, что на данную статью будут натыкаться как новички в F#, так и новички в Godot, поэтому местами я буду дублировать базовые руководства.

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

Целочисленное линейное программирование может помочь найти ответ на множество реальных проблем. Теперь исследователи нашли гораздо более быстрый способ это сделать.  

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

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

В 1936 году британский математик Алан Тьюринг выдвинул идею универсального компьютера. Это было простое устройство: бесконечная полоса ленты, покрытая нулями и единицами, вместе с машиной, которая могла двигаться вперед и назад по ленте, меняя нули на единицы и наоборот в соответствии с некоторым набором правил. Он показал, что такое устройство можно использовать для выполнения любых вычислений.

А в сентябре 2023 года Инна Захаревич из Корнельского университета и Томас Халл из колледжа Франклина и Маршалла показали, что всё вычислимое можно вычислить, сложив бумагу.

В прошлой части мы научились определять собственные типы и модули. Мы облекли все достопримечательности в конкретные типы и теперь можем снабдить их индивидуальными свойствами-ребрами (см. рисунок ниже).

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

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

Мы возьмём сугубо игровую задачу с понятным результатом и на её примере узнаем:

• на какие ноды AST стоит обратить внимание в первую очередь;
• где Fantomas-у нельзя доверять;
• где можно хакать;
• где лучше придерживаться пуризма;
• и как на F# можно строить Fluent API.

В этой части мы сосредоточимся на общей организации генератора, входных данных и основных элементах AST. В следующей сделаем то же самое, но на более сложном уровне, сместив повествование в сторону устройства Fluent API.