Проект NetBeans стал Top-Level project в Apache Foundation

После трёх релизов в Apache Incubator проект Netbeans стал Top-Level project в Apache Software Foundation.

В 2016 году компания Oracle передала проект NetBeans под крыло ASF. Согласно принятой процедуре все проекты переданные в Apache сначала попадают в Apache Incubator. За время проведённое в инкубаторе проекты приводятся в соответствие стандартам ASF. Также проводится проверка на лицензионную чистоту переданной интеллектуальной собственности.

Последний релиз Apache NetBeans 11.0 (incubating) состоялся 4 апреля 2019. Это был третий крупный релиз под крылом ASF. В 2018 году проект получил Duke’s Choice Award.

В проект NetBeans входят:

• 
  

  NetBeans IDE — свободная интегрированная среда разработки приложений (IDE) на языках программирования Java, Python, PHP, Javasсript, C, C++, Ада и ряда других.

  
  


• 
  

  NetBeans platform — платформа для разработки модульных кроссплатформенных Java-приложений. Проекты основанные на NetBeans platform: VisualVM, SweetHome3d, SNAP и т.д.

  
  

 apache foundation, netbeans

---

Релиз XMage 1.4.35 - альтернативы онлайновой игры Magic The Gathering Online

Состоялся очередной релиз XMage 1.4.35 — свободного клиента и сервера для игры в Magic: The Gathering как в онлайне, так и против компьютера (ИИ).

MTG — это первая в мире коллекционная карточная игра в жанре фэнтези, прародитель всех современных ККИ типа Hearthstone и Eternal.

XMage — мультиплатформенное клиент-серверное приложение, написанное на языке Java с использованием графического инструментария Swing.

Возможности приложения:

• доступ ко всем 18 тысячам уникальных карт, выпущенных за 20-летнюю историю MTG;


• автоматический контроль и применение правил игры;


• многопользовательский режим с поиском игроков на общем сервере;


• одиночный режим с игрой против компьютера (AI);


• десятки форматом и режимов игры (Standard, Modern, Vintage, Commander и многое другое);


• возможность проведения как одиночных матчей, так и турниров.

Что нового в этой версии:

• Полная поддержка нового, еще не вышедшего сета карт War of the Spark, со всеми картами и игровыми механиками;


• Почти 300 новых карт;


• Добавлена поддержка горячих клавиш CTRL/SHIFT/ALT;


• Добавлена возможность переключаться между чатом по F12;


• Улучшена работа с подключением и отключением от сервера;


• Улучшен режим Rich Man, в т.ч. добавлено сохранение настроек с выбранными сетами;


• Добавлен импорт колоды из логов драфта XMage и MTGO;


• Многочисленные улучшения в ИИ для более стабильной игры с компьютером;


• Улучшена совместимость с MacOS.

 magic the gathering, mtg, mtgwar, xmage, карточные игры

---

Суббота 27-е, встреча МЛУГ.

Уведомляю господ/товарищей/граждан ЛОРовцев о том, что в субботу (27.04) пройдет очередная встреча московских линуксоидов.

Место: м. Курская, ул. Земляной Вал, д. 33, T.G.I. Friday's 17:30 - 22:00 В случае чего, с одним из организаторов встречи можно будет связаться по телефону: [phone]

ссылка на сайт

alpha,
om-nom-nimouse,
dk-,
Dispetcher14,
BambarbiyaKirgudu,
DELIRIUM,
trofk,
umren,
murmur,
d,
Meyer,
deep-purple,
next_time,
te111011010,
drunken_train,
lexxus-lex,
iVS,
lolset,
imul,
poison1456,
ncrmnt,
GNU-Ubuntu1204LTS,
MrClon,
XMs,
Goury,
djambeyshik

 mlug, мероприятие, млуг, москва

---

OpenBSD 6.5

Вышла версия OpenBSD 6.5. Вот какие изменения изменения есть в системе:


1. Добавлена поддержка новых устройств:

• 1. Компилятор clang теперь доступен на mips64
  
• 2. Добавлена поддержка OCTEON GPIO контроллера.
  
• 3. Добавлен драйвер паравиртуальных часов в системе виртуализации KVM.
  
• 4. В драйвер ix(4) добавлена поддержка Intel Ethernet 700 series.
  

2. Изменения в сетевой подсистеме:

• 1. Добавлена поддержка протокола PBB(PBE).
  
• 2. Добавлен драйвер, MPLS-IP L2.
  
• 3. Также для MPLS-интерфейсов добавлена возможность настройки маршрутных доменов, отличных от основного.
  

3. Доступен следующий софт:

• 1. OpenSSH до 8.0
  
• 2. GCC 4.9.4 и 8.3.0
  
• 3. Go 1.12.1
  
• 4. Lua 5.1.5, 5.2.4 и 5.3.5
  
• 5. Suricata 4.1.3
  
• 6. Node.js 10.15.0
  
• 7. Mono 5.18.1.0
  
• 8. MariaDB 10.0.38
  

Подробности вы можете посмотреть на сайте проекта.

 openbsd

---

Обеспечиваете ли вы свою анонимность в интернете?

Не отвечаю на такие опросы "да".	1
Нахожусь в звании майора.	1
Нет, не применяю специальных мер.	0
Да, использую деперсонализированные учётные записи и сетевые адреса на значительном числе ресурсов.	0
Да, скрываю любую чувствительную информацию где это возможно.	0
Нет, стараюсь по возможности облегчить поиск моих контактов	0
Всего голосов: 2

 анонимность, приватность

---

Моя слака!

И так! Вот моя основная система, Slackware 14.2 с XFCE4. Приложения в основном
gtk2, так как мне нравятся темы под него, мне нравится как устроенны программы на нем.
Есть еще qt4 приложения, они хорошо умеют притворяться gtk2-приложениями по внешнему виду,
но это если не всматриваться, но ограничивать себя я не стал, и все же поставил их.

Как браузер использую Palemoon, так как у него приятный интерфейс, хотя скорость на некоторых
сайтах очень неочень, я все же привык к Chromium, потому поставил Matrix дополнение, и с выключенными
скриптами все работает довольно таки быстро, а если они и нужны то могу выбрать какие нужны именно. Как
плеер использую deadbeef с плагином для дерева файлов, так как папок с музыкой у меня много, а захотеть
что то послушать я могу в любой момент! Моя IDE - Geany, собираю ее сам, так как никто ее не собирает
уже из дистров нормально, ставлю все плагины, отладчик, навигация по коду, менеджер проектов, скачиваю
с офф.сайта все теги для автокомплита, ну и пишу, выходит вполне юзабельно, да и работает очень быстро. В /home папки на английском так как мне лень переключаться на русский когда набираю путь.

Теперь о sladeb, который у меня на скриншоте в терминале, в слаке пакетов очень много, но некоторая их часть есть только в
виде SlackBuild'ов, то есть пакеты нужно сначала собрать, редко такое бывает нужным, так как почти все пакеты уже собранны, но мне нужно...
Поэтому я как истинный ценитель бинарных дистров, брал и воровал пакеты из других дистров, но делалось
это через гугл, зависимости сами не ставились, ну я и решил написать себе что то типа пакетного менеджера, который бы автоматизировал это дело, что бы я смог удобно ставить пакеты из разных дистрибутивов.
Он использует sources.list, с небольшим расширением для указывания архитектуры... Ну и умеет проверять
зависимости по хитрым алгоритмам, на скриншоте он пишет при установке GPick что к примеру libc6, gtk2
у меня уже имеются, но с Debian'a я их конечно же не ставил, он сравнивает по умному и не очень файлы
которые есть в деб-пакетах и у меня, и приходит к выводу что у меня уже все есть, кроме разве что
самого gpick и lua. Lua действительно я не нашел в чистой Slackware 14.2, что мне показалось странным. Ну и еще он ссылки сам делает, если они нужны... Так как у разных дистров разные папки, работу sladeb по этой части можно увидеть в Thunar.

GPick слева внизу был запущен после установки с помощью sladeb.

>>> Просмотр
(1920x1080,
624 Kb)

 debian, slackware64, xfce4

---

Очередное обострение клавиатурной болезни

И так, возможно, некоторые запомнили мои прошлые клавиатуры

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

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

По факту я взял идею Planck, взял приятные на мой вкус свичи(kailh pro light green), разработал модельку корпуса и отпечатал.

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

Удобно ли мне работать с такой клавиатурой? Да.

Предложу ли Вам попробовать что-нибудь такое? Возможно.

Стоит ли Вам через силу лезть на такое? Точно нет.

>>> Просмотр
(1280x720,
129 Kb)

 клавиатура

---

Debian с XFCE на нетбуке

Вдохновляясь этим примеров в галерее решил оживить свой старый нетбук. Железо дефолтное - 32-битный (!) атом на 1.6Ггц, 1Гб ОЗУ и медленный HDD.

После многих экспериментов решил выбрать Debian с XFCE4. Работает, выглядит красиво и не тормозит. Дефолтный список (тема, иконки, шрифт) приводить не буду, в выводе screenfetch все есть.

---

Капча!!!1111

гугл охуел! Я, блядь, 15 сраных минут кликал по ебучим светофорам и пешеходным переходам чтобы зарегистрироваться!!! Издец! Я вам тут не нанимался эти вонючие нейросети гугловские тренировать безплатно. Нахуй идите со своими рекапчами! Изверги! Геноцид, блядь, какой-то1 В рот я ебал это всё. Какой пидорас поставил здесь это??? Сука, лучше платную регистрацию сделайте.

 bt, google, lg, recaptcha

---

Krita падает на Qt 5.12

Падает с приблизительно таким сообщением:

free(): double free detected in tcache 2

Предыдущие строчки лога чаще всего не повторяются, так что думаю, что к ошибке не относятся. Но на всякий случай пример лога: https://paste.ubuntu.com/p/Cd8VsRT28W/

Покопавшись в инетах, я нашел похожий по симптомам багрепорт: https://bugzilla.redhat.com/show_bug.cgi?id=1666197

Который, в свою очередь, отсылает к: https://bugreports.qt.io/browse/QTBUG-72488

На реддите пишут, что в мейнстриме Krita уже заворкераундили: https://www.reddit.com/r/krita/comments/aanv5s/krita_crashes_when_opening_new_file/

В связи с чем реквест к Sunderland93. Можете залить свежую версию для Ubuntu Disco в Krita Lime PPA? Спасибо заранее.

 bug, krita, qt5

---

В ядро Linux для ФС Ext4 включена поддержка работы без учёта регистра символов

Тед Цо (Ted Ts'o), автор файловых систем ext2/ext3/ext4, принял в ветку Linux-next, на основе которой будет сформирован выпуск ядра Linux 5.2, набор изменений, реализующих поддержку регистронезависимых операций в файловой системе Ext4. Патчи также добавляют поддержку символов UTF-8 в именах файлов.

---

Подскажите название алгоритма

Есть N массивов, нужно создать все возможные варианты пар из значений массивов.

Пример для двух массивов по 2 числа:

const numbers1 = [1, 2];
const numbers2 = [4, 5];
// makeMagick(numbers1, numbers2) -> [[1,4],[1,5],[2,4],[2,5]]

 алгоритмы

---

Почему в торрентах не раздают видео, аудио и субтитры отдельно?

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

 torrents, тупняк

---

Школа MBA forLady

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

Наши контакты:
Специалист: saagrig
Сайт: https://mbalady.1stlfs.com
Viber: [phone]
[phone]
[phone]
Email: [email protected]
Skype: [email protected]
Telegram: @leadsforsuccess

 lid

---

Наработка базы клиентов

Компания «Leads For Success» – быстрый и эффективный способ привлечения потенциальных клиентов! Наши Базы имеют обширную, актуальную информацию, которая поможет быстро приобрести новых клиентов, увеличить продажи и больше зарабатывать! Вы получаете не только имя, телефон, электронный адрес, но и аудиозапись разговора оператора с клиентом с указанием, на какой минуте клиент выявил интерес к Вашему товару или услуге. Подберем клиентские базы именно Вашей целевой аудитории!

Наши контакты:
Специалист: saagrig
[phone]
[phone]
[phone]
Site: https://1stlfs.ru
Email: [email protected]
Skype: [email protected]
Telegram: @lfs_ru

 lid

---

InnoDB - как физически сохраняет блоки B+-Tree на диск?

Назовём «хранилкой» такую штуку: некий демон, слушающий порт, принимающий команды SET/GET и т.п., строящий в памяти некую структуру данных, хранящий её также каким-то образом на диске и способный подняться после вырубания питания. Примеры «хранилок»: InnoDB, Redis, PostgreSQL и др.

Примитивная схема работы «хранилки»: есть структура данных в памяти - «дерево» (или что-то ещё: хештаблица, список, массив и т.п.) и есть журнал. Журнал - бесконечно растущий файл. Все пишущие операции сначала пишем в журнал, потом исполняем на «дереве». В случае падения, просто исполняем весь журнал с начала до конца и получаем в памяти «дерево» на момент падения. Или не критично отличающуюся (например декартово дерево, где есть рандомчик). Минус: журнал только растёт и на высоконагруженной системе через 2 года журнал будет читаться и исполняться целых две недели при поднятии после падения.

Схема получше: кроме журнала есть «дамп» - файл, новая версия которого каждые сутки пишется на диск, а внутри наше сериализованное «дерево» + позиция в журнале на момент записи «дампа». При поднятии нужно только построить «дерево» по дампу и дальше «догнаться» по журналу до его конца, начиная с позиции, являвшейся концом журнала на момент записи «дампа».

Второй принцип используется много где.

Когда в память всё не влезало и умные люди занимались вопросами поиска во внешней памяти, то придумали и полюбили B+-Tree за то, что основание логарифма в оценке средней стоимости доступа к ключу у такого дерева конское со всеми вытекающими - т.е. примерно 2-3 рандомных доступа к диску на поиск любого ключа в базе примерно любого адового объёма. Да и вообще конское основание логарифма - хорошо, когда операция обращения вычислителя к своей памяти передаёт не байты, а блоки байтов, что верно уже чуть более чем для всего, где память иерархична: проц, кеш L1, L2, L3, оператива, диск — в этой иерархии размер блока растёт с удалением по иерархии от вычислителя. Чем дальше надо идти, тем выгоднее взять сразу много. А раз приехало много, то лучше чтобы всё приехавшее было полезно: вот так и родилось B+-Tree. Чем плох бинарный поиск в mmap-леном файле? Тем, что операции все в блоках (секторах диска по 4096), а из блока нужен только один ключ для принятия решения о том, вправо шагать или влево. То есть из всего приехавшего нам блока размером 4096 мы используем процента 2, остальное в помойку. Для сокращения пространства поиска всего в 2 раза мы гоняем целый блок с кучей ключей. Пропускная способность линии обмена с внешней памяти тратится бездарно. В B+-Tree всё не так - каждый приехавший блок полезен на 100% и сокращает пространство поиска сразу в B раз, где B - fanout дерева, который конечно может быть переменный из-за разницы в длинах ключей, но уже неважно, профит и так громадный.

Хотя конечно у самых умных чуваков на диск пишется и читается минимум мегабайт по 64, чтобы оправдать цену seek головы (что для ssd тоже имеет цену) - поэтому размер SSTable в гугловом BigTable примерно такой. Короче это тема LSM структур, но вопрос про B+-Tree.

Изначальный вопрос про хранилки на B+-Tree. Во внешней памяти лежит куча блоков B+-Tree и обмен с внешней памятью идёт поблочно. Иногда мы меняем блоки, тогда в памяти повисают «грязные» блоки, которые надо потом скинуть обратно в файл. Понятно, что попутно мы всё пишем в точно такой же журнал, как описано в начале. Вот тут наступает хрень - нельзя просто так взять и записать все блоки на те места, где они были. Мы же умные чуваки и не хотим гонять с диска мелочь, поэтому наши блоки больше размера сектора - ну например 16 кб или даже 4 мб. Посередине записи такого блока может пропасть питалово и тогда у нас не останется даже предыдущей копии такого блока, ведь мы записывали сразу поверх старого. Накатить из журнала мы тоже ничего не можем - там нет целых блоков, а только отдельные операции SET. Эти операции SET поднимали блок с диска, меняли и делали «грязным». Но с диска мы уже ничего не поднимем, там на месте блока уже мусор.

Поэтому умные чуваки из InnoDB догадались сделать double write buffer. Типа, все блоки, которые надо записать, сначала запишем в специальное место файла, потом вызовем fsync(), а потом уже начнём их записывать поверх старых версий тех же блоков. Тогда всё ништяк - питалово может пропадать в любом месте: мы либо в double write buffer их ещё не дописали и тогда «оригинальные» невредимы, либо если зафакапили оригинальные у нас есть «микрожурнал» в виде double write buffer откуда мы можем блоки поднять.

Чуваки в Postgres сделали по-моему чуть проще и в чём-то надёжнее (из-за простоты) - пишут блок целиком в ЖУРНАЛ, а потом уже на место назначения. Там у них есть такое понятие как checkpoint process - это такой длительный размазанный по времени процесс, чтобы не мешать обычной работе СУБД, чтобы не юзать диск сразу в полку, а скинуть все грязные страницы помедленнее. Он выглядит примерно так:

1. Атомарно собрать список всех грязных блоков в памяти, которые хотим синхронизировать - просто массив их ID. Ну, или указателей, чё там в реализации творится не знаю.

2. Новые грязные после взятия этого списка могут плодиться как хотят, но в данный checkpoint process они не попадают.

3. Записать в журнал метку «checkpoint» (эта метка называется checkpoint, а есть ещё в англоязычной литературе «checkpointing process» - это сам процесс вот этого всего).

4. Читать начиная с этой метки мы можем только при условии, что checkpoint process дойдёт до конца без падения.

5. Лениво начать такое: любой блок из множества выбранных пишется в журнал, потом в своё законное место. Если вдруг в ходе этого процесса на блок прилетает меняющая его команда, а в журнал этот блок ещё не попал, то прилетевшая отдельная команда в журнал не пишется, а сразу накатывается на уже грязный блок и уже блок целиком пишется в журнал. Далее блок становится «полугрязный» и все меняющие операции с этим блоком пишутся в журнал как обычно, отдельными мелкими записями, а не в виде новых изменённых версий блока - блок у журнал после начала данного checkpoint process достаточно записать только 1 раз. Короче надо записать все выбранные в начале блоки в журнал и максимум 1 раз, но меняющие эти блоки входящие команды не должны оказаться в журнале ДО самого этого блока.

5. После записи блока в журнал можно перезаписывать его в «дампе» (он же «файл таблицы». Короче, журнал тут послужил double write buffer - от этого деться нельзя, если только не специальная аппаратура - куда-то надо записать блок до того, как перезаписывать его старую версию новой. Тут два варианта - сначала записать все выбранные в журнал, а потом начать их писать в файл таблицы, либо можно по одному «в журнал и сразу в файл таблицы». Тут вопрос в обработке ситуации падения прямо в этот момент: если выбрать второй способ, то мы будем видеть в файле таблицы блоки свежее, чем им следовало бы быть согласно той позиции журнала, с которой мы начнём читать журнал после падения — а нечнём мы читать журнал не с нашей новой только что записанной метки «checkpoint», а с предыдущей у которой «checkpointing process» дошёл до конца. А на момент той метки наши блоки были более древними, чем оказались перезаписанными в ходе нового «checkpointing process». Короче, кажется эта ситуация теоретически может быть обработана: нужно будет уметь для таких чрезмерно новых блоков пропускать все команды в журнале более старые, чем сам блок. Для простоты можно думать, что сделано первым способом - «сначала все блоки скинуть в журнал, потом начать скидывать в файл таблицы».

6. Предположим, процесс сдох тут где-то посередине. Просто читаем журнал с прошлого «checkpoint», встречаем постепенно нашу новую метку «checkpoint» и доводим этот новый checkpoint process до конца, дописывае блоки которые ещё не дописались куда нужно - мы их спокойно поднимем из файла таблицы: там спокойно лежат старые блоки, которые не начали перезаписываться новыми версиями, ведь эти новые версии ещё не дозаписались в журнал. Ну или дозаписались и начали перезаписываться в файле таблицы, тогда можно просто сравнивать байтики блоков - если в файле таблицы блок лежит не такой, как записался в журнал, значит тупо перезаписать его тем, что записался в журнал. Ну CRC32 ещё или MD5 там везде понакрутить конечно.

Фактически у нас тут тот же double write buffer, только им служит журнал. Чем мне такое нравится - журнал можно тупо зареплицировать на бесконечное число других хостов и поднять там реплики. Я PostgreSQL не админил, возможно там такое почему-то сделать нельзя, но точно не по идеологическим причинам, а из-за каких-то тактических архитектурных фекапов. А вот в случае MySQL там какая-то жесть: нельзя просто так взять и зареплицировать некий журнал, он там какой-то непростой. Это всё холивар и содомия, я вообще не шарю.

Вот хочется почитать как именно устроена работа по синхронизации блоков B+-Tree с диском в MySQL.

Про Postgres я тут изложил упрощённо, реально есть нюансы, но общая идея в том, что давайте просто запишем блок в журнал целиком и это будет нашим двойным буфером. Заодно такой журнал просто зареплицировать как поток команд и это PROFIT.

В случае с MySQL есть загадки. Во-первых меня смутило упоминание в литературе того, что их этот double write buffer ограничен (естественно, под него же выделено место в файле таблицы) где-то 128 блоками (настраивается). А что если грязных блоков больше? Или они делают checkpoint когда грязных блоков НЕ БОЛЕЕ 128 всегда? Но вроде нет, что-то читал про умение делать это группами блоков.

Как-бэ загадка вот в чём: например журнал начался на позиции 500. Мы с него поднялись. У нас народилось 200 грязных блоков. Мы херак записали 128 из них сначала в DWB, потом в файл таблицы. Всё чинно и благородно, никакие байтики не помялись. Тут херак упали.

Поднимаемся с позиции журнала 500. Начинаем накатывать какие-то команды. Команды требуют поднятия с диска блоков и их изменения. Мы идём в файл таблицы, а там херак 128 из этих блоков новее чем другие. Возможно это обрабатывается так же, как я предположил для postgres - на блоке просто стоит число, мол «я актуален для позиции журнала 700», поэтому мы херак и пропускаем все команды для него до позиции 700. Возможно это бред и всё не так.

Плюс там есть ещё какой-то fuzzy checkpointing.

 innodb

---

Генерация клиентских баз

Бизнес всегда находится в поиске новых торговых площадок и способов привлечения как можно большего количества клиентов! Одним из способов продвижения товара является телемаркетинг. Компания «LeadsforSuccess», работающая в сфере входящего и исходящего телемаркетинга предоставит Вам клиентов! Вашей организации мы передаём клиентов, которые уже знают о Вас, получили КП и готовы вести с Вами диалог по поводу покупки товара или услуги.

Наши контакты:
Специалист: saagrig
[phone]
[phone]
[phone]
[phone]
Site: https://1stlfs.com/
Email: info@1stlfs.сom
Skype:[email protected]
Telegram: @leadsforsuccess

 lid

---

Как на openvpn сервере, контролировать сгенерированные .ovpn файлы?

Допустить я одному сгенерировал, другому. а как их отключать выданные эти файлы? с .ovpn расширениями?

 openvpn

---

Детективные квесты

Есть какие-нибудь хорошие детективные квесты (или просто игры, не обязательно с pixel-hunting), чтобы с интересным сюжетом и голову приложить надо было. Помню как-то давно играл в scratches - xорошая игорь была, но с мистическим уклоном.

 игры, квесты

---

Мир как дипломная работа

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

Каковы шансы, что наша Вселенная это чей-то интернет? Где заметны лишь ~5% информации, а основная масса данных скрывается в даркнете. Господи, да почему вообще существуют все эти структуры, а?

 вселенная, пиво, пятница, физика, философии тред