Category: история

Category was added automatically. Read all entries about "история".

404

научно-дистопическое

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

Наиболее страшной силой становится string theory вместе с Weyl symmetry. Её открытие требует несколько тысячелетий, после чего несколько тысячелетий длится эпоха погони за симметриями, после чего приходит крах цивилизации. До этого происходит много меньших циклов, приводящих к замедлению, но только string theory обладает достаточной эстетической силой, чтобы разрушить цивилизацию до пре-каменного века.
404

(no subject)

Скажите, как у вас на машине выглядит юникод u3333 (㌳)? У меня вот так: (это _ОДИН_ символ юникода)


Я его даже прочитать не могу. fyiito? hyiito? fuiito?

Это какая-то феерия. u3334 тоже слово (㌴), если моего мунспикнутого хватает, то это "butusieru" и гугль по этому слову более чем конкретен.

Попытка копипаста этих штук в консоль приводит её в неистовство, а vim в замешательство.

UPD: http://unicode-table.com/ru/3334/
Квадратный bussyeru U+3334


Знаки совместимости ККЯ 3300—33FF

Количество символов: 256
Тип: слоговое письмо
Языки: китайский, японский, корейский, вьетнамский
Страны: Перу, Лаос, КНДР, Китай, Камбоджа, Япония, Гуам, Тайвань, Южная Корея, Вьетнам, Сомали, Судан, Израиль, Сингапур, Филиппины, Малайзия, Индонезия, Таиланд

Китайское письмо (кит. трад. 漢字, упр. 汉字, пиньинь: hànzì, палл.: ханьцзы) уже несколько тысяч лет является единственным общепринятым способом записи китайского языка. Знаки китайского письма также широко используются в японском и корейском письме (там они называются кандзи и ханчча, соответственно). До 1945 года китайское письмо использовалось также для записи вьетнамского языка (хан ты).

В контексте интернационализации, письменности, основанные на китайской, называют CJK (англ. Chinese, Japanese, Korean) или CJKV (с добавлением англ. Vietnamese).

Возраст китайской письменности постоянно уточняется. В 1962 году при раскопках неолитическое поселение Цзяху реке Хуанхэ обнаруженные надписи на панцирях черепах, напоминающие по начертанию древнейшие китайские иероглифы. Пиктограммы относят к VI тыс. до н. э., что ещё древнее, чем шумерская письменность. Ранее известный исследователь китайской письменности Тан Лань высказывал предположение, что китайская иероглифика возникла 4-5 тысячелетий назад.

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


Вот я думаю, мне баг репортить или нет, и если да, про какой пакет? Терминал? Шрифт?
404

Уголовный кодекс РСФСР 1926 года. Редакция 05.03.1926

Оригинал взят у dimez в Уголовный кодекс РСФСР 1926 года. Редакция 05.03.1926
Оригинал взят у toxa в Уголовный кодекс РСФСР 1926 года. Редакция 05.03.1926
Глава IV. НАРУШЕНИЕ ПРАВИЛ ОБ ОТДЕЛЕНИИ ЦЕРКВИ ОТ ГОСУДАРСТВА

122. Преподавание малолетним или несовершеннолетним религиозных вероучений в государственных или частных учебных заведениях и школах или с нарушением установленных для этого правил влечет за собой -
принудительные работы на срок до одного года.
123. Совершение обманных действий с целью возбуждения суеверия в массах населения, для извлечения таким путем каких-либо выгод, -
принудительные работы на срок до одного года с конфискацией части имущества или штраф до пятисот рублей.
124. Принудительное взимание сборов в пользу церковных и религиозных групп -
принудительные работы на срок до шести месяцев или штраф до трехсот рублей.
125. Присвоение себе религиозными или церковными организациями административных, судебных или иных публично - правовых функций и прав юридических лиц -
принудительные работы на срок до шести месяцев или штраф до трехсот рублей.
126. Совершение в государственных и общественных учреждениях и предприятиях религиозных обрядов, а равно помещение в этих учреждениях и предприятиях каких-либо религиозных изображений, -
принудительные работы на срок до трех месяцев или штраф до трехсот рублей.
127. Воспрепятствование исполнению религиозных обрядов, поскольку они не нарушают общественного порядка и не сопровождаются посягательствами на права граждан, -
принудительные работы на срок до шести месяцев.


404

Norand

Кстати, история норанда очень важна - 400 лет назад Grand Line только-только осваивался. А до этого было что-то, что приводило к войне за понегриф с Шандиа.

Вопрос: были ли kaizoku в то время, или их появление совпало с моментом массированной экспансии на грандлайн?

И знал ли "король" из North Blue о существовании Tenryuubi?
404

antique: Anime Oyako Gekijou (1982)

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

Я бы, если бы не знал о времени происхождения, смело бы этот скриншот в конец 80ых записал, а то и в ранние 90ые. Хотя, определённые характерные черты того времени есть (например, круглый нос, специфичный рисунок верхней губы, тень над щекой, слегка гипертрофированная "дальняя" щека), но в общем и целом это явно не ужасы 80ых . И даже вполне сравнимо с 97ым (вторая картинка).


404

TENGEN TOPPA GUREN LAGANN - LAGAN HEN

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

Всё величие человеческого духа, вся его сила, красота, гордость, вся его смелость и благородство - это всё в Гренн Лагане.

Прочь унылые гаремники и тупые slice of life. Великая битва духа, великая преграда и ещё большая сила, преодолевающая невозможное!

Великая песнь Гайнакса звучит вновь. Я не хочу обижать еву и фурикури, но ТТГЛ всё-таки самое их великое творение.

Грен Лаганн можно (нужно!) считать символом сёнена, выражением самого его сокровенного. Это тест на любовь к сёнену. Либо ТТГЛ пустышка и ерунда - тогда человек не создан для сёнена. Либо ТТГЛ - это пламя и любовь - и тогда сёнен, сёнен и ещё раз сёнен.



Алсо, я не буду иметь ничего против ежегодного ремейка Гренн Лаганна. Он восхитителен своим существованием, каждым мгновением своей силы и духа.
404

tagfs - примерная спецификация

благодарю анонима с пятью двойками в IP.

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

Основа (хранилище) - обычная ™ файловая система, в которой предусмотрена метаинформация [в этом месте я плаваю]. Файлы хранятся либо в виде дерева каталогов (а-ля сквидовый кеш/b-tree), либо просто тупой помойкой в каталое tagfs_files. Доступ к ним, конечно, пользователь может получить (и внести изменения), но весь цимус - в работе с файлами не с помощью "файловой системы-носителя", а с помощью tagfs. Каталогов (в пользовательском смысле) в файловой системе нет, это частный случай атрибутов файла.

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

Атрибуты файла представляют:
* его "неотъемлимые" (системные) данные: размер, дату изменения/модификации
* теги

Основное с тегами: они представляют собой граф, в котором тег может указывать на вложенные теги, вышестоящие теги (т.е. тег может указывать на своих "сыновей" и "родителей", причём, возможно, без ведома родителей). Так же поддерживаются логические выражения (когда тег является выполнением ряда условий по наличию тегов и\или каким-то ещё условиям).

Часть тегов может быть автоматически генерируемой на основании другой информации файла (например, md5, или части имени).

tagfs представляет систему видов (представлений, view) информации. Каждое представление - выборка по тегам с указанными условиями.

Частным случаем tagfs является дерево каталогов, построенное как последовательная выборка по тегу directory_name. Но, разумеется, и остальные виды так же могут быть.

Основным проблемным моментом является переосмысление файловых операций:

1) open/read/write/stat вполне однозначно определены - они выполнят указанное действие. Тут проблем нет.

А дальше начинаются проблемы:
2) создание нового файла (копирование с внешних фс на указанную) создаёт файл в хранилище и присваивает ему указанные теги. При этом, очевидно, что мы можем только присваивать теги, но никак не результат выполнения запроса. Например, если у нас представление вида 'if 'aaa' in filename, то мы не сможем создать такие теги, которые бы устраивали условие. Отсюда мысль: представления могут быть с возможностью пополнения (теговое представление) и в без него (представление запроса). Я не говорю режимы r/o и r/w, потому что возможность удаления остаётся даже для представления, которое нельзя расширить.
3) Создание каталогов == создание новой метки. Возможно это только при теговом представлении.
4) Удаление файла... Тут мы приходим к двузначности:
а) удаление файла означает удаление его из хранилища (т.е. автоматическое удаление из всех представлений)
б) удаление файла означает удаление у него того тега, который стал основой для вида.

Возникает соблазн сказать, что "удалять файл" мы будем только из представления запроса, а "удалять метку" из тегового представления. Но это внесёт жуткую путаницу, так что следует однозначно определить тип операции, эквивалентный удалению. Это будет 'generic' операция, файловый менеджер, который будет "знать" про tagfs будет иметь право вызвать альтернативный вызов.

Как мне кажется, самым спокойным вариантом поведения является удаление тега, в этом случае поведение эквивалентно удалению линка.

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

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

Мне видится один из двух выходов:

1) Файл, добавляемый в представление запроса, помещается в группу "без тегов" и показывается в представлении "силком" (tagfs помнит, что теперь запрос выглядит так: старый_запрос + этот_файл).

2) У файла сохраняется пометка (в виде специфичного тега), что он соответствует запросу "старый_запрос" вне зависимости от чего-либо. Грубо говоря, тег выглядит так: текст_запроса=true. И при выполнении запроса это поле ищется и включается.

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

... Есть ещё третий путь, но он не совместим с generic dir i/o: возможность сделать команду 'convert selection to tag tag_name'. В результате представление запроса превращается в представление тэга и все последующие операции очевидным образом выполняются в рамках общей логики. Важным моментом будет следующее: не смотря на то, что тип представления поменялся, все открытые хэндлеры для каталога у всех приложений остались валидными. (грубо говоря, это эквивалентно переименованию каталога в обычной fs).

Итог:

tagfs-совместимый файл-менеджер должен уметь две дополнительные операции:
* Удаление файла из хранилища вообще (итого у нас есть три уровня удаления информации: delete (удаление метки), drop (удаление файла из хранилища), wipe (затирание нулями и удаление файла из хранилища).
* Конвертацию представления запроса в представление метки (теговое представление).

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

Открытым остаётся вопрос о том, в каком формате хранить информацию о тегах... Метаинформация файлов - очень неудобна с точки зрения быстрой выборки. SQL - медленно (представьте себе обхождение всех сгенерированных представлений du, например), плюс нет согласованности с фс...
404

разгребание аниме

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

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

В третьих, у меня (благодаря подписям [of XX] в конце) перестали копиться нераспознанные комплиты.

В четвёртых, разделение онгоинг/анкопмлит позволяет охватить взглядом онгоинг и постепенно сокращать анкомплит. Аналогично, разделение анкомплит и сталлед позволяет видеть анкомплит как реальную цель.

Ну и итог: - в incoming у меня сейчас меньше 400 файлов. А в сорт (от старых времён оставшемся) - 450. По сравнению с ~1600 в incoming и 3000 в sort, большой прогресс.