И потому они Его отвергли. — Всюду пророк в почете, только не на родине и не у себя дома, — сказал им Иисус.
( Евангелие от Матфея, Глава 13, стих 57 )
Тащемта нередко считается у нас, что "наш" автор-блоггер-писатель-разработчик хуже зарубежного. ("Наш" -- бывше-советский, российский, украинский, русскоязычный...)
Но от русских текстов есть польза, например, в том же tldr: https://github.com/tldr-pages/tldr/tree/main/pages.ru (Что суть самые важные выжимки из документации, man-ов.)
Там кое-что переведено на русский, причем, скорее всего, переведено самое интересное и важное. Выходит, переводчик(и) на русский выступал(и) как фильтры самого важного-интересного.
Так собственно и в русскоязычной wikipedia. Я её читаю когда статья на английском слишком большая -- статья на русском часто короче и там обычно более важное.
(Я бы и на других языках читал, если бы понимал.)
Раньше бы читал и на украинском, ради такого дела, но теперь wikipedia на украинском становится всё больше и больше...
Кстати, нащот фильтров. В фидо в 90-х были эхи посвященные кракам к софту. (Теперь на rutracker это называют "таблэтка".)
И некоторые люди читали эти эхи с интересом, но не от большой любви к пиратскому софту. Они читали их как каталог софта. Рассуждая так -- раз софтину сломали, значит она стоящая. У них даже был мем -- "о новом софте мы узнаем по кракам к нему".
Выходит, кракеры тоже выступали в роли фильтров, сами того не зная.
Может быть и до сих пор так? На торрентах, на ru-board, итд? ХЗ, я не знаю.
Часовщик сидит в своей будке. И говорит кому-то о своем графике работы: "я здесь с четырнадцати до пол-седьмого". Это как смешивать табы и пробелы в одном исходнике, как же это бесит, кто бы знал.
Бытовая аналогия по поводу многоярусной памяти.
Это похоже на:
Лайфхак для тех у кого отключают напругу, как летом 2024 в UA.
Syncthing лучше dropbox-а! (При условии что у вас свой сервак и вам не нужен GUI для нубов, тут с этим оч.скромно.)
Внезапно проявился неожиданный бонус Syncthing-а. Он же показывает, какие еще ваши девайсы приконнекчены в этот момент.
Я забыл как-то один из своих андроидных гаджетов дома. И с другого андроида, будучи не дома, я мог видеть, есть ли дома напруга, т.е., пашет ли мой забытый дома гаджет (от аккумов) через мой домашний WiFi-роутер (в розетку воткнутый)?
Дарю идею пытливым умам. (Хотя я не пробовал.)
Как измерять качество сна при помощи дешевой вебкамеры.
Снимать себя на видео. Какой-нибудь вебкамерой, лишь бы снимала в полутьме. (Ну или спать днем.) Видос потом сжимать конвертируя во что-то.
И/или просто делать фотки, раз в минуту. Из фоток делать видос.
Чем больше ворочался -> тем хуже сжимается видос -> тем больше видос по размеру -> тем хуже качество сна.
И наоборот: чем меньше ворочался -> тем лучше сжимается -> тем меньше -> тем лучше качество сна.
Затрат вообще никаких, кроме дешевой вебкамеры. И никакой код писать не надо. Просто заюзать ffmpeg.
Но зато так можно иллюстрировать как жмется видео. Самое тяжелое для видеокодеков это, например, дождь, снег. Все помнят как на старом компе, играя видео с компакта или DVD, когда в кино/сериале начинается дождь, видео начинает шкандыбать, рваться, запинаться. Просто чтобы закодировать эти сцены, нужно уже куда больше инфы. И проц или не успевает разжимать вовремя, или не успевает читать с носителя.
У меня буквально недавно такое было, когда я пытался смотреть видео моря, в оч.большом разрешении, снятое с летающего дрона. Ну и сам файл по размеру был куда больше тех видосов, где моря не было.
Лайфхак с олдскульным веб-браузером.
yt-dlp может выкачиывать видосы с rutube, но не понимает плейлисты. Заходим на rutube на любимого видеоблоггера, листаем страницу вниз чтобы показалось нужное кол-во видосов. Сохраняем эту страницу из firefox в HTML-файл. А потом:
lynx -dump fname.html | grep rutube.ru/video | cut -d ' ' -f3 | sort | uniq
Имеем на выходе красивый список видосов/URL-ов для скармливания yt-dlp.
Кто-нибудь сможет сделать это быстрее, и не юзая консольный браузер? Ну, может быть можно найти какую-то другую утилиту, которая повыдергивает URL-ы из HTML-файла.
Я лично выкачиваю всяких видеоблоггеров сразу в mp3, чтобы слушать фоном, на ходу.
Инерционность мышления это плохо. Когда-то давно у меня был знакомый, занимался разблокированием и перешивом мобил. И была у меня в начале нулевых годов мобила Sony CMD J7. Дисплей жидкокристаллический, подсветка -- зеленые светодиоды по бокам.
И чувак этот говорит -- хочешь я тебе цвет дисплея поменяю? Я такой -- а как ты поменяешь цвет? там же светодиоды зеленые впаянные наглухо, это от прошивки никак не зависит. Он -- да причем тут прошивка, я могу просто светодиоды перепаять на другие.
Вспомнился анекдот эпохи начала 90-х годов. Встречаются программер и железячник. Железячник говорит, что у него дисковвод глючит. И что он уже всё перепаял в контроллере и в самом дисковводе, но всё равно глючит. Программер говорит что у него та же проблема, дисковвод глючит, и он уже все драйверы переписал с нуля, но всё равно глючит.
И опять логарифмы!
Двоичный логарифм, как это не удивительно, часто юзается вместе с вызовами realloc().
Частая задача -- вы читаете что-то там в буфер и буфер постепенно расширяется. Очень часто, есть просто начальный размер буфера вроде 4096, потом, если не хватает места, он умножается на 2 при каждой итерации.
Кол-во вызовов realloc() примерно равняется двоичному логарифму от размера итогового буфера.
Например, из ядра Линуха:
buffer_len = buffer_len ? buffer_len * 2 : 4096; next_buffer = realloc(buffer, buffer_len);
( src )
Еще:
log_buf_size = max((size_t)BPF_LOG_BUF_SIZE, log_buf_size * 2); tmp = realloc(log_buf, log_buf_size);
( src )
Но есть побочный эффект. Если загружаемый файл размером 1GIB + 1 байт, придется выделить буфер размером 2GiB. 1GiB = 2**30, 1GiB+1 = 2**30+1, 2GiB = 2**31.
А как иначе? Можно выделять более мелкими кусочками, но тогда будет большой overhead на вызовы менеджера памяти. Например, каждый раз, вы увеличиваете буфер на 1 килобайт. Тогда, для чтения файла размером в 1 мег, надо будет ~1000 раз вызвать менеджер памяти для перевыделения буфера.
Довольно много головоломок это просто NP-проблемы. Вплоть до тетриса.
Если вы возьмете самые популярные головоломки на смартфонов, заметите, что всё это они. Наверное в этом есть какая-то психология. Мозгу интересно решать такие проблемы, а проблемы проще (вроде простой сортировки чисел) -- скучно.
Если бы я задался целью забацать еще одну игру-головоломку для смартфонов, я бы просто рылся в книгах об NP-проблемах. Там идей -- огромное море. Ну, еще можно рыться в книгах Мартина Гарднера.
Перл это один из самых плохих ЯП в мире. Хуже Перла только Похапень.
А разгадка проста. Ларри Уолл просто юзал AWK и ему его не хватило, и он начал расширять его. Но AWK был хорош, и сейчас тоже хорош, потому что там все сбалансировано и гармонично. Перл вышел Франкенштейном, в очень плохом смысле.
У меня на лоб глаза полезли, когда я читал про "сигилы". Я знаю только один такой другой ЯП с "сигилами", а именно олдовый Бейсик. Но в Бейсике была потребность в этом. Они работали на 8-битных компах с очень маленьким размером памяти. И программер должен был подсказывать инетрпретатору тип переменной. А зачем это всунули в Перл, я вообще не врубаюсь.
Кто-то раньше юзал Перл ради либ из CPAN, но в наше время у какого-нибудь Питона этих либ тоже достаточно.
Так что, Питон всяко лучше Перла, во всех аспектах. Перлистам я не рукоподаю ни разу. Питонистам я рукоподаю стабильно.
А если вам дико интересен заумный ЯП, то посмотрите в сторону APL/J/K -- этот действительно может исполнять какой угодно случайный поток символов.
А почему же Перл такой популярный? (Был?) Спросите вы? Но это слабый аргумент: argumentum ad populum. Шаурму на улице тоже многие едят, и майонезик там, но никто и не считает это полезной едой. И Макдональдсов вокруг много и кока-колы тоже. Ну и курят-бухают.
Было смешное скандинавское кино "Большинство людей живёт в Китае". Там родитель грузит дочку о том, как делает "большинство людей", а не так, как она. Бойкая нагловатая девочка тут же отвечает, перебивая: "большинство людей живёт в Китае!" И действительно, из-за того что большинство людей живет в Китае, это не значит, что мы должны разговаривать на китайском, юзать юани, итд.
Так вот про Перл. Вероятно дело в том, что в начале 1990-х был спрос на ЯП с динамической типизацией и алголовским синтаксисом. Конечно же, был уже Лисп, но там "скобочки" -- это многих пугает, ну и learning curve у Лиспа круче (т.е., steeper). Питона и Ruby еще не было на горизонте. Вот Перл и попал в струю.
Позже раскрутился Питон и Ruby, но уже в нулевых годах. Эти ЯП практически Лиспы и есть, только с алголовским синтаксисом. Говорят что и JS это тоже почти что Лисп, впрочем я не спец.
На мой взгляд, Питон таки лучше Ruby, потому что Юкихиро Мацумото фанат Перла и натащил фичей Перла к себе в Ruby. И это очень странно. Японец явно хорошо соображает, вне всяких сомнений. Зачем ему Перл? "Месье знает толк в извращениях"? Во всяком случае, это меня отпугнуло в Ruby. А Питон имеет более-менее удачный баланс фич, IMHO.
(Тестирую MathJax.)
В раздумьях об A057839. Сколько надо бит для libgmp чтобы представить в памяти число \( 10^{2026728077} \)? В Питоне не получается подсчитать, слишком большое число.
Тогда, мы можем изменить базу числа вида \( b^x \) с 10 на 2:
>>> x 2026728077 >>> b 10 >>> x*math.log(b)/math.log(2) 6732644939.683338
Т.е., 6732644939 бит или 841580617 байт или 841MB, что худо-бедно терпимо.
Также подбешивает, когда про RSA Factoring Challenge пишут что-то вроде "RSA-120", но не указывают, это кол-во бит или кол-во десятичных знаков?
Например, RSA-170, это 170 десятичных знаков. А сколько это в битах? Переводим:
>>> 170*math.log(10)/math.log(2) 564.7277761308517
А если (публичный) RSA-ключ имеет 768 бит, то сколько это десятичных знаков? Переводим:
>>> 768*math.log(2)/math.log(10) 231.19103666993752
Сколько 16-ричных цифр (nibbles) будет занимать число длиной 10 в 10-чной форме? Можно даже запомнить коэффициент - 1.2 (это math.log(16)/math.log(10)) 10/1.2=~8.3
Сколько 10-чных цифр будет занимать число длиной 8 в 16-ричной форме? 8*1.2=~9.6. То есть, 2^32 = ~4.7 миллиарда (один DVD), и в числе 4700000000 10 цифр.
Пока сетапил syncthing... Он позволяет делать директории, которые будут расшарены не по всем вашим девайсам а только по некоторым. Это имеет смысл, например, надо с андроида закачать на определенный сервер, но при этом, не нужно, чтобы файлы копировались на все подряд гаджеты. Лично у меня такие директории называются вроде gadgetname1_gadgetname2, чтобы сразу видно было, который из гаджетов подключен.
Сколько есть вариантов таких "шар"? Директориев?
В математике это называется powerset. Это множество всех возможмных подмножеств.
Есть 4 гаджета, к примеру. Тогда есть \( 2^4=16 \) возможных комбинаций гаджетов. Т.е., как бы 4 бита и каждый бит показывает, подключен ли каждый конкретный к директорию.
Powerset order = \( 2^{set order} \).
Почему \( \frac{x+y}{z} = \frac{x}{z} + \frac{y}{z} \)?
Поехал я как-то в соседний город по делам. Потратил столько гривен: 115 + 590 + 115. А сколько это в баксах? (По тогдашнему курсу 26 грн за бакс.)
Можно считать так: \( \frac{115 + 590 + 115}{26} \).
Но это то же что и: \( \frac{115}{26} + \frac{590}{26} + \frac{115}{26} \).
Но первый вариант быстрее считать!
Так проще запомнить это правило.
Лайфхак для бекапов. Давно я заимел привычку, вместо удаления файла или директория, прибавлять к его имени префикс "2k ". Что означает "to kill". Спасло мне это много нервов, когда я мог запороть файл(ы) а бекапов не было. Потом, удаляете самые старые файлы с префиксом "2k " для чистки.
Еще: emacs при сохранении файла переименовывает предыдущий в #fname#.
Ругали когда-то ЯП Бейсик, в былые времена.
А с другой стороны, а что делать? 8-битные маломощные процы, оч.мало памяти. Какой еще интерпретируемый ЯП с возможностью отладки там можно было юзать? На ум приходит только Лисп, но это не оч. гуманно для нубов. Может быть, Форт, но я с ним не знаком толком.
Остальные ЯП в 80-ые и 90-ые -- компилируемые, и это слишком круто для тех маломощных компов.
А Бейсик (который суть упрощенный Фортран) позволял прерваться, посмотреть переменные, модифицировать их, запустить прогу с другого места. Таким был на моей памяти только Лисп.
Да, Паскаль и Си в 90-ые -- это огого по тем временам. Но для этого уже нужны были компиляторы. Которые и были, даже для ZX Spectrum, но генерили код они раздутый (поди попытайся оптимизировать что-то на таком слабом процу) и медленный.
Почему говорят "плавающая точка", "floating number"? Всё дело в маркетинге.
Было время когда девайс работающий с IEEE 754 - это было дорого. Люди постарше вспомнят "сопроцессоры" для процов 8086, 80286 и некоторых 80386 (кажется, SX).
Люди обходились fixed point, т.е., "фиксированной точкой". Просто берете integer, посредине ставите точку. Половина это целая часть, половина -- дробная.
Несколько очень известных софтин это юзали. А именно DOOM. Он шел на процах 80386 без сопроцессора. Важное замечание -- итоговая цель видеоигры это найти на дисплее пиксель и расчитать цвет для него. Для этого fixed point хватало - 32-битный регистр, 16 бит для целой части, 16 для дробной части.
Другая известная софтина это TeX Д.Кнута, начавшаяся в начале 1980-х. Конечно, мало какие компы в то время имели "сопроцессор".
Так до сих пор делают маломощные (микро)котроллеры без сопра. Какой-нибудь промышленный термометр, где работать с вещественными числами нужно, а особая точность не нужна.
Потом, в 90-х, сопроцы относительно дешевели и маркетологи юзали термин "плавающая точка" чтобы отмежеваться от fixed point. Дескать, у нас тут еще и экспонента. А значит точка "плавает" тудой-сюдой (как в Одессе говорят).
Маркетологи так говорили чтобы впаривать компы с сопроцами, или компы поновее -- 80486 уже имел сопер на кристалле, ну и всякие там Pentium потом.
Люди юзают логарифмы несознательно, сами того не зная.
Например, умножаем 30 на 500. Многие просто умножат 3 на 5, получится 15. Потом складывают кол-во нулей. 1 ноль плюс 2 нуля, будет 3 нуля. Прибавляем 15 и 3 нуля - 15000.
Вот именно так и работает умножение чисел с плавающей точкой в процу. Умножаем мантиссы и складываем экспоненты.
Ну как так можно писать в википедии?
Карбиды — соединения металлов и неметаллов с углеродом.
Так и хочется спросить, а что еще можно соеденить с этим вашим углеродом, кроме металлов и неметаллов (и самого углерода)? Может быть, полуметаллы?
В математике, есть разница между необходимым условием и достаточным (necessary and sufficient). Эти понятия часто путают.
Майонезик для оливьешки -- необходимое, но не достаточное. Достаточное -- все ингриденты и сила воли для сборки блюда.
В RE4B я писал про старую игру под MS-DOS из 90-х -- "Марьяж". И о том, что были слухи, что игра жульничает.
Что значит "жульничает"? Может ли она подсматривать в карты противника, и в прикуп? Здравый смысл подсказывает, что конечно же может -- ведь у этой игры есть доступ ко всей информации, в т.ч., к вашим картам.
Всё это так, да не совсем.
Игра может быть честной, если ГПСЧ используется для раздачи карт и ф-ция для принятия решений не использует информацию о картах противника. Хотя (технически) может и использовать.
Как узнать? В примере том я показывал, как открыть карты прикупа, т.е., там можно проследить путь от ГПСЧ до места в памяти где хранится инфа о прикупе. Далее следить, будет ли кто-то читать эту информацию, позже. Потенциально это возможно было бы сделать и в 90-ые при помощи отладчика SoftICE.
В наше время есть DosBox с фичей LOGCPU -- дампит каждую исполненную инструкцию и состояние регистров.
Эта задача напоминает taint analysis.
Если сильно заморочиться, то это можно узнать.
Люди мира! А объясните тупому, на кой хер до сих пор в кабаках и гостиницах выставляют пароль на wifi-роутеры?
Инет в наше время уже дешевле некуда. А если это такая сверхмудрая защита от "хацкеров", то ведь никто не помешает "хацкеру" спросить у бармена пароль и потом "хакерить"...
Кста и вот еще. А почему инет-провы вместо того чтобы разводить по квартирам витую пару и ставить роутеры, не выдают всем Wi-Fi? Вроде дешевле было бы. Поставил один Wi-Fi-рутер (более-менее мощный) на несколько этажей сразу, раздал пароли, ну и стриги капусту...