- 1
IT Оффтоп #226-
Куча / Говнокод #29218
0
#196: https://govnokod.ru/28925 https://govnokod.xyz/_28925
#197: https://govnokod.ru/28935 https://govnokod.xyz/_28935
#198: https://govnokod.ru/28938 https://govnokod.xyz/_28938
#199: https://govnokod.ru/28942 https://govnokod.xyz/_28942
#200: https://govnokod.ru/28945 https://govnokod.xyz/_28945
#201: https://govnokod.ru/28948 https://govnokod.xyz/_28948
#202: https://govnokod.ru/28951 https://govnokod.xyz/_28951
#203: https://govnokod.ru/28954 https://govnokod.xyz/_28954
#204: https://govnokod.ru/28971 https://govnokod.xyz/_28971
#205: https://govnokod.ru/28986 https://govnokod.xyz/_28986
#206: https://govnokod.ru/28991 https://govnokod.xyz/_28991
#207: https://govnokod.ru/29002 https://govnokod.xyz/_29002
#208: https://govnokod.ru/29060 https://govnokod.xyz/_29060
#209: https://govnokod.ru/29070 https://govnokod.xyz/_29070
#210: https://govnokod.ru/29079 https://govnokod.xyz/_29079
#211: https://govnokod.ru/29092 https://govnokod.xyz/_29092
#212: https://govnokod.ru/29093 https://govnokod.xyz/_29093
#213: https://govnokod.ru/29104 https://govnokod.xyz/_29104
#214: https://govnokod.ru/29114 https://govnokod.xyz/_29114
#215: https://govnokod.ru/29125 https://govnokod.xyz/_29125
#216: https://govnokod.ru/29132 https://govnokod.xyz/_29132
#217: https://govnokod.ru/29147 https://govnokod.xyz/_29147
#218: https://govnokod.ru/29156 https://govnokod.xyz/_29156
#219: https://govnokod.ru/29166 https://govnokod.xyz/_29166
#220: https://govnokod.ru/29181 https://govnokod.xyz/_29181
#221: https://govnokod.ru/29185 https://govnokod.xyz/_29185
#222: https://govnokod.ru/29190 https://govnokod.xyz/_29190
#223: https://govnokod.ru/29203 https://govnokod.xyz/_29203
#224: https://govnokod.ru/29211 https://govnokod.xyz/_29211
#225: https://govnokod.ru/29212 https://govnokod.xyz/_29212Запостил:
nepeKamHblu_nemyx,
10 Января 2026
Follow us!
Этот оффтоп сгенерирован автоматически.
Индекс оффтопов: https://index.gcode.space/.
Зеркала Говнокода и полезные ресурсы:
* https://govnokod.xyz/ (альтернативный Говнокод)
* https://gcode.space/ (read-only зеркало Говнокода)
* https://t.me/GovnokodBot (Говнокод-бот в «Telegram»)
* https://t.me/GovnokodChannel (Тематический канал в «Telegram»)
* https://app.element.io/#/room/#govnokod:matrix.org (резервный чат)
Примечание: автоматические перекаты в настоящее время осуществляются только с аккаунта nepeKamHblu_nemyx.
Остерегайтесь подделок. Берегите себя и своих близких. Кок!
да
https://www.computer-museum.ru/histsoft/rubin.htm
Кормана не читал
Никлауса нашего Вирта "структуры и алгоритмы" не читал
Что ты вообще в армии делаешь?
Это было бы неплохо для обычных игроков. Большинство макросов просто автоматически возвращают тебя назад с помощью так называемого "failsafe" и перезапускают скрипт.
Да не, я норм отношусь к перезагрузкам серверов теперь
Шучу конечно ))
Мартышки, не обосравшейся с эскейпингом, не существует. Умение "не обосраться с эскейпингом" было утеряно где-то вместе с "греческим огнём"
https://postimg.cc/LhMWn2Br
At least 140 Gbytes of free disk space, though much more will help to run multiple builds and increase performance by reusing build artifacts.
At least 32 Gbytes of RAM, though a modern build host with as much RAM and as many CPU cores as possible is strongly recommended to maximize build performance.
ну ладно, если это говно нужно для сборки, то пусть будет. Я просто напомню, что Slackware 7.0 занимал несколько гигабайт на диске, и имел гуй на Xfree86 + KDE, и я там даже, прости господи, на перле CGIйки писал
Что касается Коржика, то он ничем не прославился.
Зачем они это делают, это же не смишно
Как потестить?
Записываешь в блок по адресу 256 гигов минус несколько блоков слово «пизда», потом в блок по адресу 512 гигов минус несколько блоков слово «хуй». Возвращаешься и пытаешься прочитать пизду. Если её перетёр хуй, значит, реальный размер 256 гигов или меньше. Если она сохранилась, то реальный размер больше.
Но это грубо. Х. з., какая арифметика может быть в реальности. Там ещё wear leveling может дать ложное срабатывание, так что нужно потестировать несколько раз с разными словами.
Можно как-то так сделать
head -c размервбайтахдиска /dev/urandom | tee /dev/sda_какой-тотам | md5sum
И потом можно у всего ссд посчитать md5. Или можно какой-то прогой попробовать вычислить место, где оно зацикливается при чтении байтиков
и потом это говно проверить
Джей, почему документация в прыщах такое говно?
Вот например тут написан протухший двадцать лет назад пиздеж: https://www.kernel.org/doc/html/v5.6/driver-api/usb/hotplug.html
Во-первых "/proc/sys/kernel/hotplug" поменяли на "/sys/kernel/uevent_helper" 2.6.16
https://lwn.net/Articles/166954/
Во-вторых это давно уже отключили в польщу NETLINK, о чем написано в документации `CONFIG_UEVENT_HELPER`:
>
The uevent helper program is forked by the kernel for every uevent. Before the switch to the netlink-based uevent source, this was used to hook hotplug scripts into kernel device events. It usually pointed to a shell script at /sbin/hotplug. This should not be used today, because usual systems create many events at bootup or device discovery in a very short time frame. One forked process per event can create so many processes that it creates a high system load, or on smaller systems it is known to create out-of-memory situations during bootup.
>
Имхо, это ёбаный стыд какой-то. Это как если бы ты открыл MSDN про WDM почитать, а там тебе такие: "ну это надо DEVICEHIGH в config.sys делать "
То, что не является API, документировать не надо.
Also, тут речь не про отсутствие доки, а то про, что в доке НАВРАНО: там устаревшая на ДЕВЯТНАДЦАТЬ ЛЕТ ПРИМЕРНО инфа
Потому что что? Если у тебя юзерспейсная прога вызывает сискол винды (допустим это какой-то вирус или троян) и ты этот вирус исследуешь, тебе будет нужна документация на этот вызов для понимания того, что за хуйня тут происходит. И тебе будет насрать на то, API это или не API
Потому что документируя что-то ты:
1. обязуешься поддерживать обратную совместимость (и этим не даешь развиваться продукту)
2. тратишь время на то, что довольно скоро поменяется
ну и разумеется отсутствие документации лучше, чем неправильная дока
Нет. Обратную совместимость ломают, при этом документацию можно менять. Реальный пример: SDL2, SDL3 - вот про миграцию https://wiki.libsdl.org/SDL3/README-migration
Тогда поддержка документации будет стоить еще дороже, а прыщи вон даже обычную доку не осилили
Если у тебя есть бага, AI её и опишет.
Но я senior AI hater, у меня черный пояс по обсиранию AI, так что я предвзят
ЛОЛ!
По-моему, это кульминация обсуждения, /pthread
А как сами разработчики системных либ винды (работающие в майкрософте) понимают, что именно делает какая-то там хуйня типа той же NtReleaseWorkerFactoryWorker? У них где-то документация есть, и они ей с кем попало не делятся, или они в исходники смотрят каждый раз?
> ну и разумеется отсутствие документации лучше, чем неправильная дока
Нет, не лучше. Если в хуйне версии 2 апи незначительно поменялось в сравнении с версией 1, и есть документация только на апи версии 1, и ее тупо скопировали, назвав документацией к версии 2, то это явно лучше, чем если б документации бы вообще нихуя не было ни на версию 1 ни на 2
А в прыщах как понимают?
Код смотрят. Но может быть у них есть приватная документация
>Если в хуйне версии 2 апи незначительно поменялось в сравнении с версией 1,
Я тебе буквально принес пример, где поменялось, и очень сильно.
Там написано, что при добавлении нового устройства ядро запускает скрипт, который должен создать файл устройства
Но это не нужно делать, так никто не делает: все подключаются через NETLINK, и слушают события. Не нужно запускать скрипт на каждый чих (примерно по той же причине, по какой не надо CGI использовать)
Причем сама же дока ядра в соседнем документе явно про это говорит
Ну так напиши им багрепорт на документацию. Я однажды вот написал багрепорт на документацию, читая доки GCC (прям в багзиллу добавил), и потом это через какое-то время исправили. Или тебе проще на говнокоде поныть?
> . Или тебе проще на говнокоде поныть?
само собой: это святое!
Если документация 100% хуйня, это настолько же бесполезно, как ее полное отсутствие, но обычно это не так. Например, часто бывает что нет даташита на какую-то микросхемку, но есть даташит на похожую микросхемку (какой-то более старой или более новой версии того же производителя). Так вот, наличие таких неправильных даташитов лучше, чем полное нихуя, если тебе надо что-то с такой микросхемкой делать.
во-вторых потому что менее надо
В обычной винде половина примерно сервисов (демонов по-вашему) работает от LocalSystem (тоесть от рута), причем многие слушают сеть, и используют протоколы, которые придумал один случайный программист в 1993-м году, и протоколы эти известного качества.
А например HTTP просто в ядре реализован.
TBH, поцтеринг всё таки не часть _ядра_, а лишь один из десятков тех, кто срет непереваренной хуйней в прыщедистры, но ядро и без него неплохо справляется
Первые гигабаты махом пролетели, как можно ускорить?
Такой подход может нихуя не сработать из-за дискового кеша. Лучше засрать весь диск байтами uint64_t начиная с нуля, отключить и потом опять включить на всякий случай, и потом его анализировать
Попробовал ещё victoria и aida64, тоже говорят норм, но я просто прверку райт/верифай запустил, не знаю, умеют ли они такое определять.
Надо транслятор перешивать, а я не знаю, как.
тестил на флешке, видимо она не выдержала таких издевательств, ссд быстро потестился
> е��ли
Напоминает, как Питер Паркер забыл про мудифекатор «u» в рагулярке и распидорасил UTF-8. Но Питер Паркер ошибку исправил, а некоторые хабробляди продолжают так срать.
Тут ты приползла
Во истину свидетельствую же перед Аллахом: нет в мире такого ГэЦэ, который не поел бы говна.
Сука у меня в юности книжка по С++-2003 от Старуструпа тоньше была, совсем ебанулись что ли
--Нет
--А чего тогда уши из трубки торчат?
Раньше надо было с�ать в текущий через document.createElement
Ещё через 10 лет додумаются до виртуальных элементов без документа
Могли бы глобальный метод в window или navigator сделать
С JSON.parse уже было
also, что может быть говенее ООП?
1. ничего
2. эмуляция ООП через анально-ректальную жопу как в Pre6 JS / Perl
Иногда приходится эмулировать ООП на Lua
Я так и не понял, зачем нужон этот DOM, если его нельзя собирать полностью с нуля?
Типа
> Я так и не понял, зачем нужон этот DOM, если его нельзя собирать полностью с нуля?
наверное чтобы парсить пришедшие с сервера данные?
Или такое:
эти две строчки эквопенисуальны же?
сиречь я могу и так написить
Пахнет жопаскриптом до версии шесть, да.
Нет, первая похерит все остальные ключи в foo, если они там были
Wrong
$env.config = {
show_banner: false
}
This would reset any other settings that had been changed, since the entire record would be overwritten.
Я вот тебе скажу: а в ДЖАВАСКРИПТЕ можно написать
а ты такой: НЕЕЕТ, первая надпись ПОХЕРИТ фу
ну разумеется похерит, блин
Я имел ввиду что добавить метод к таблице это просто добавить в нее значение
Но это похоже на "виртуальные" функции в крестах
Хотя...
Не, говно
Я бы скорее посмотрел на это как на смолток: ты можешь в рантайме добавлять любой обраточик месседжа (в данном случае -- вызова метода).
Причем, сама функция конечняо ничего не знает про то, что она -- метод. Она просто ждет self первым аргументом.
В луа нет разницы: между `foo.bar = fun`, `foo["bar"] = func` и `function foo.bar`
Это как если в ES6 не добавили бы
и вебмакаки писали бы
Я так думаю, в луа изначально не было никаких ООП, туда просто завезли синтаксис с ":" потом для неявного передача self, и всё.
В 1993-м году в мире языков для конфигурации какой-то хуйни вот менее всего думали про ООП.
Но луа хорроша тем, что она реально очень простая: Таблица -- единственный нескалярынй тип. Он и ассоциативный массив, и просто массив (как в сам знаеш каком языке АХАХАХАХА), и объект это просто ассоциативный массив, в котором лежат переменные (как блеснутый хеш в перле) и функции. Причем они даже шарят один неймспейс.
also, а инхеритнс через метатаблицу делается же?
Есть ещё потоки и userdata
> а инхеритнс через метатаблицу делается же?
Да https://en.wikipedia.org/wiki/Lua#Inheritance
про потоки ничего не знаю, ятолько корутины крутил на луа (вручную, лол), а userdata это вроде черный ящик для интеропа с няшной.
>Да
метакласс, eigenclass, вот это всё, я понял. Наследование делать через магию метаклассов это как-бы сразу намек на то, что не надо наследование делать (используй делегирование, хотя эмбеддинг структур тоже без меты не сделать, придется писить вручную)
Кстати, эта хуйня не будет работать без
потмоу чтопо-умолчанию луа настолько простой, что не имеет доступа к внещним источникам энтропии КАКОЙ БАГОР ))
Чем это отличается от math.random(4) % 2 == 0 ?
> не имеет доступа к внещним источникам энтропии
УМВР
ничем, просто у меня десять пальцев же
>УМВР
а теперь сложи print(math.random(10)) в файл, и запусти его с командой строки `lua file.lua`
Кнопка "перейти к элементу" показывается, но не работает
genius
Да ёб твою мать
Сколько ещё хуйни прилетит
чё
зиг надо учить, или дальше в раст закапываться. Скоро всем питонистам, джавистам, котлинистам, и прочим формошлёпам отрежут задницы, и отправят гулять по Антропику, и разносить горячие пирожки сотрунидикам, а AI будет программировать вместо них.
А вот такие штуки типа на зиге написаной какой-то хуйне реально будут ценны
Хелло, я специалист по написанию DTO на джава и моделей на Django. Горячий пирожок попробуете?
> Применение препроцессоров дает выигрыш в производительности в среднем от 8 до 18 процентов.
>
> Препроцессоры KAP и VAST для компилятора FORTRAN реструктурируют исходный код на языке FORTRAN с целью более эффективного использования ресурсов процессоров семейства Семейство POWER, POWER2 и PowerPC и иерархической структуры памяти. Существует также версия препроцессора KAP для программ на C. Препроцессоры выполняют оптимизацию управления памятью, арифметические преобразования, встраивание, межпроцедурный анализ и другие операции по повышению производительности приложений на FORTRAN и C.
>
> Препроцессоры KAP и VAST пытаются преобразовать исходные алгоритмы в алгоритмы, позволяющие в полной мере воспользоваться оптимизирующими возможностями компилятора. Кроме того, препроцессоры создают распечатки с указанием выполняемых преобразований, а также фрагментов кода, препятствующих преобразованиям. Препроцессоры анализируют исходный код и выполняют преобразования, повышающие производительность программы.
Где вы еще такую хуйню встретите?
в любом оптимизирующем компиляторе?
вот я написал такой препроцессор, который оптимизирует любой код на СИ в независимости от компилятора, и использую для этого проприаетраные свои знания
Купи мой оптимизатор, а запусти на любом компиляторе
А препроцессор показывает, что изменилось. Программист обучится и будет сразу писать оптимальнее.
Любой код при ударе этой бомбы превращается в код на PHP
Ту же самую задачу можно выполнить с помощью функции shmat():
они реально учат ммапить файл в память через SysV хуйню вместо POSIX??
sala?
Какая технология ибм вошла в массы, кроме ибм пэцэ?
Но конкретно тут у нас AIX. Это очень давно отпочковавшийся от SysV юникс IBM, он может не уметь еще позикс.
Он хактерен тем, что придумал настрйоку загрущки чуть ли не в бинарных конфигах, и ушел от SysV init задолго до systemd, launchd, забыл-как-в-солярке-называется (SMF же вроде?)
ну и конечно OS/2 могучий привет
А еще есть мейнфреймы с OS/360 и блядь эта хуйня работает до сих пор, какие-то блядь банки в Швейцарии чи Манхетенне до сих пор юзают хуйню которую купили в 1971-м году, бо рабоатет -- не трогай
ТРАМП СОСНУЛ
By default, this task_work runs whenever the application
transitions from user to kernel space. If the thread is busy (for example, during a join or scan), the kernel may issue an inter-processor
interrupt (IPI) to process pending completions. This effectively preempts the application, disrupts cache locality, increases jitter, and
reduces batching efficiency. To mitigate these effects, io_uring offers
the COOP_TASKRUN flag (CoopTR), which reduces IPIs and allows
applications to delay task_work. However, completions are still processed on any kernel-user transition, including unrelated syscalls
such as malloc().
КАКОЙ БАГРИЩЕ )))
По чесноку конечно, многая сискола может привести к перешедулингу в ядре, но спутать сишный API с сисколом ядра это какой-то такой зашквар, что я не знаю даже..
Выделение памяти в MMU мире уже почти на всех либлсях позиксовых делается через `mmap(2)` (иногда подпиливается через `sbrk(2)` потом) бо анонимный ммап и есть маллок.
Пруфануть на прыще можно через `strace`, но лучше почитать доку
гнусь: https://man7.org/linux/man-pages/man3/free.3.html
(искать по MMAP_THRESHOLD)
фрибздунишкин jemalloc:
https://man.freebsd.org/cgi/man.cgi?malloc
(искатьпо IMPL. NOTES)
ну и конечно опенок
https://man.openbsd.org/reallocarray
A new implementation by Chris Kingsley was introduced in 4.2BSD, followed by a complete rewrite by Poul-Henning Kamp which appeared in FreeBSD 2.2 and was included in OpenBSD 2.0. These implementations were all sbrk(2) based. In OpenBSD 3.8, Thierry Deval rewrote malloc to use the mmap(2) system call, making the page addresses returned by malloc random.
зы: консоль не терминал, UART не компорт, UEFI не BIOS, снигири ни гири, malloc не сискол
Надо будет на собесе такой вопрос задать: как реализовать свой маллок? Пусть у формошлепа глаз на жопу налезет
thread local allocation buffer
выделил себе кусман, потом нарезаешь
разумеется. Вопрос был в том, причем тут тред локал?
ты видишь, что я маллокнул в одном треде, а прочитал в другом?
Напрмиер, я попросил маллок 1КБ а ты попросил у операционки 4КБ и поклал в буфер треда
Когда я следующий раз попрошу в том же треде, то получу оттуда
верно?
Вопрос для собеседы был в том, сколько брать из операционки чтбы:
1. не было фрагментации
2. не засрать слишком уж много памяти
3. не заебать ядро сисколами
Знаешь алгоритм Бадди?
Но подзабыл уже, чтобы уверенно рассуждать
Пусть у тебя есть ячейка размером `N`.
Я попросил у тебя `N/2 - 1`.
Ты раскусил `N` на две опловинки, одну дал мне.
Когда я тебе ее вернул, ты присовокупил ее обратно ко второй половинке и снова получил `N` и тем самым избежал фрагментации, и можешь другоу питуху отдать `N`.
На самом деле всё сложнее гораздо, но если бы школьник делал, и отдавал бы `N/2 -1` , то довольно быстро вся память была бы изъедена молью, и хуй бы ты там наскреб бы потом N.
А так ты жертвуешьк онечно чуть чуть место, но выиграешь вот дефрагментацию
ебать спасибо нахуй
друзья помогите решить
1. CPU умеет PCIe 5.0
2. nvme умеет PCIe 5.0
3. хардварный рейд умеет PCIe 4.0
можно сделать софтварный рейд средствами ОС, а можно хардварный средствами железки. Но PCIe 4.0. Но не тратит CPU. Но если сломается, то нужно искать замену железке. Но надежнее софтварного (я не доверяю софту). Но медленее в теории. Но с батарейкой. Но дороже.
This.
Если ты не фермой серверов управляешь, то пользуй софтвар и чини потом на любом другом устройстве. Допом ещё ставлю одинаковую свинью на то, что ты не разработчик БД, которому раз в неделю надо i/o стресс-тесты гонять, и тебе даже скорости pcie 3 за глаза, а нагрузка на проц минимальная.
Свинофермой управляю, этим я горжуся!
> тебе даже скорости pcie 3 за глаза,
Откудава ты знаешь ради чего это хочу? Вдруг там 1С ERP во все поля?
Альсо, а вдруг я ESXi хочу? Он софтварный рейд не умеет впринципе
1. Хотплаг (u2)
2. Не ебет CPU
3. Можно поставить операционку. Любую. Загрузика мне UEFI с софтварного рейда винды, дружок. Настрой мне софтварный рейд на esxi.
4. батарейка позволяет не обосраца даже если у тебя нет журнала
5. стабильность. Я как-то отвал рейда реже видел чем багу операционки
6. рейд умеет делать себе патрол рид, и слать емейлы если там говно
Ну да, чуть медленее, но зато НАДЕЖНАСТЬ
(не надо только мне рассказывать что надежность это бекап: Бекап будет само собой, но бекап развернуть занимает час, а вынуть диск из рейда и вставить другой занимает 0 секунд, потмоу что юзеры ничего не заметят даже)
Этот мир не заслуживает Руби.
Серьезно, из всей скриптохуйни руби самый прикольный
Там уже завезли стандарт или всё ещё "курите исходники irb"?
Над дурман-травой стоит туман.
"js" это единственный, который реально имеет стандарт (и сам ему не соответствует порой, null is object)
> perl эзотерический,
это не правда: на нем половина раннего веба написана же
Ну и кривые оптимизации циклов мы тоже обсирали.
Ладно, IE честно признаётся, что у него свой «стандарт». Но остальные браузеры почему творят хуйню?
Also: https://dev.to/yenyih/temporal-instead-of-date-3e0d
* я настоьько старый, что помню, как всем было похуй на другие браузеры, и я реально писал чото итменно под IE: там был div (в NN был layer), там был VBS (ну потому что скриптинг хост, IDispatchable вот это всё) были какие-то градиенты в CSS свои через ActiveX... серьезная платформа была!
В IE был VML, когда ещё SVG не был встроен в браузеры.
В общем, они тогда ещё реально что-то интересное изобретали.
А багор с hasLayout помнишь?
да! он самый! DXImageTransform и пр. API к DirectX же.
> В IE был VML, когда ещё SVG не был встроен в браузеры.
VRML помню, для 3Д хуйни
>А багор с hasLayout помнишь?
Так проверяли IE, да)
А помнишь ie box model bug?
1. DXImageTransform — это фильтры, реализованные через интерфейс ActiveX.
К слову, у Хрома были свои фильтры, несовместимые со стандартом W3C, который поддержали Фуррифокс и Опера. Так что война браузеров продолжалась.
behavior — это другое, это для навешивания обработчика.
Вспомнил! Было ещё expression() в CSS, ещё задолго до того, как W3C предложил calc(). Вот оно тормозило при скроллинге, потому что всё пересчитывалось.
2. VRML — это 3Д, да, поддерживалось плагинами NPAPI или ActiveX после установки внешнего рендерера. А вот VML — это аналог SVG, только с другими ключевыми словами. Попрошу не путать!
3. Не то. У hasLayout не было публичного API, его нельзя было проверить, но можно было косвенно установить. Чтобы в IE элемент с display:block отрендерился правильно, нужно установить hasLayout в true косвенным методом, добавив свойство zoom: 1. А как его сбросить для display: inline, я уже не помню.
Проверяли IE другими способами.
4. Я помню, что с размерами padding и outline была жопа в зависимости от доктайпа и от браузера, так что приходилось пердолиться, чтобы не получить двойной отступ.
На MUMPS тоже писали ранний медицинский софт
Менее упоротым это его не делает
https://thedailywtf.com/articles/A_Case_of_the_MUMPS
PS гк не хочет отправлять комментарий с того браузера
Самый главный пример говнокода на этом сайте в нижнем правом углу
• лишний пробел или разрыв строки может совершенно изменить смысл синтаксической конструкции;
• ключевые слова языка не зарезервированы и могут широко использоваться в качестве идентификаторов.
Зашибись. А ещё mumps — это английское название паротита (свинки).
GLOBAL ARRAYS: arrays that start with a caret symbol. Stored on disk, available to all processes, persist when process terminates. This is M's main "database" mechanism.
Это же Active Record из рельсов, первый ORM!
LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.
No GC.
XECUTE [which is my personal favorite, it allows arbitrary execution of code contained in a variable]
Обычное eval'о.
CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.
А это в точности, как в «PHP». Совсем не удивило.
https://perldoc.perl.org/functions/tie
MUMPS does not require declaration of variables, and is untyped: all variables, including numbers, are effectively string
Все зависит от операции: есть сложение, а есть кокотенация. Есть разыменовыаание ссылки. Есть булевы выражения.
внмиание вопрос: а какие НЕ скалярные типы есть в перле, знаешь?
Какой Tcl )))
Остерхаут писал же, что программирование-в-малом (анисание глукода, и скриптиков на пол странички) не нуждается ни в статической, ни в строгой типизации.
Потмоу кстати ЯПы типа питона это изврат.
По-хорошему, нужен аналог Питона, с его bignum и околофункциональной питушнёй, но компилируемый в нативный код и со статической типизацией (которая впрочем не исключает Variant, как в Delphi).
Julia can be compiled to binary executables with PackageCompiler.jl.[20] (or with juliac). Smaller executables can also be written using a static subset of the language provided by StaticCompiler.jl that does not support runtime dispatch (nor garbage collection, since excludes the runtime that provides it).[90]
Static subset интересно. Только где в документации оно описано?
На главной странице их сайта:
> где в документации
https://docs.julialang.org/en/v1/devdocs/aot/#Ahead-of-Time-Compilation
http://www.faqs.org/faqs/m-technology-faq/part2/
causes X to become "[email protected]"
Удобно.
Перевожу на «PHP»:
$xyz = 'abc';
$$xyz = 123; // теперь $abc хранит 123
$subrou = 'report';
$$subrou(); // вызовется report()
Предикаты!
Эх, никакого тарасоформатирования...
ХУЙ СОСЕТ ХУЙ СО СВОИМ ДЖЕЙ!
can be rewritten as
ну вот совсем другое дело же! намного читаемее!
Сокращение ключевых слов до одной буквы меняет язык до неузнаваемости.
отсоси потом проси
Logical binary operators (||, &&, and and or) at the beginning of a line continue the previous line, like fluent dot. The following code examples are equal:
Previously:
Они добавили то, что в языках с точкой с запятой уже есть из коробки.
в руби вообще много приколов, например там у функций скобки можно не писать
А в тцл скобки для функций вообще писать не надо...
кака-жаба
а я я
Коко не получица на жаба, там конвеншын овер конфигурейшн. коко надо кот генерить (как в рельсе)
https://meetmiddelen.eu/fluke-networks-dsx2-8000
Справедливости ради, 8 категория это для 40Гб/с, а это для ДЦ петухов, а у ДЦ петухов денег куры не клюют, так что не грех у с них три месячные зарплаты сис-админа попрсоить за хуйню для проверки кабеля
о точно у меня же роутер для элиты беспроводной а не как у этих
Я посмотрел видос по диологонали, оно конечно правда дохуя всего умеет: перекосы всякие наверное тебе довольно важны, если ты рядом с источниками помех свое кабельное хозяйство развернул, и оно всё это трекает
Будешь делать сетку на заводе -- купи обязательно
https://youtu.be/mDUu3su8fjs?t=1970
как прямо из модемного детства: ближнее эхо, дальнее эхо, затухание, вот это всё...
какой амперметр ))
https://youtu.be/mDUu3su8fjs?t=2274
Тогда тебе не обходим
https://www.have-digitap.nl/nl/fluke-networks-dsx2-5000qi-int-1ghz-cableanalyzercertifiber-quad-oltsfi-1000
> Versiv Open Source Software CD
серьезно?
Но обычная хоррошая витуха шестой категории даже вручную обжатая обычно норм работает с гигабитом, если не нарушать длину.
Я однажды видел такую хуйню в сервере в датацентре, но там сотрудник центра налажал с настройкой портов на свиче, и было 100 мегабит. Причем сука горело оранжевой лампой, и он не заметил (заметили в итоге через `ethtool(8)` и дали пизды).
А еще была хуйня когда дебил прицепил на виндовый сервер внешний флешдрайв по USB 2.0. Нашли через usbview (кстати, удивительно годная программа для пинды, и бесплатная) и тоже дали пизды.
Apparently, Zhopa is safe now
В коко нету никаких await
и Делэй там в коробке
А в гошке вообще калоринга функий нет. Зачем писать на поносном языке, который придумакл дебил-на-солфеточке?
Вечно какая-то хуета происходит. То подвисшие транзакции, то непонятные connect error, то ещё какая-нибудь хуйня каждую неделю происходит. Нахуя я три реплики в кластере держу? Чтобы когда слейв отвалился, всё нахуй тормозить начинало?
Почему я не могу просто пользоваться и течь, а не постоянно ебаться с этим говном?
Ты хочешь убедиться, что твои данные в двух местах лежат?
Мой знакомый админ на такие штуки забил, и просто делает полный дамп базы раз в сутки. Бухгалтера не сахарные, один день наверстают
Так синхронная реплика тебе не даст гарантию "данные в двух местах" лол. После коммита - да, для in-flight - шо синхронная, шо асинхронная, история может быть нарушена, данные могут оказаться только в одном из двух мест, чтение с разных узлов может давать разный результат.
Я про потоковую (WAL-based) репликацию в синхронном режиме:
https://www.postgresql.org/docs/current/warm-standby.html#SYNCHRONOUS-REPLICATION
Ты можешь задать список питухов, которых нужно реально ждать
https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES
> There will be one or more active synchronous standbys; transactions waiting for commit will be allowed to proceed after these standby servers confirm receipt of their data
Кроме синхронной, есть еще асинхронная (когда ты просто серанул валом куда Бог пошлет) и есть логическая репликация: в ней никто не шлет WALы, а просто PUBит сообщение что вот такая-то табла изменилась, и это уже задача клиента изменения подтянуть.
Продакшеновые решения это один главный сервер, и пять стендбаев в разных странах.
- один сервер принял и применил, другой крашнулся до применения
- кто из них мастер - вообще поебать, история уже разъехалась
единственный плюс только в явном подтверждении у клиента, что что-то куда-то записано, но клиент вообще никак не влияет на целостность
единственный плюс синхронной репликации только в явном подтверждении у клиента, что что-то куда-то записано, но клиент вообще никак не влияет на целостность
1. client->master: COMMIT
2. master: (коммитит WAL)
3. master->slave: COMMIT THE WAL
4. slave->master: COMMITED
5. master->client: OK
Если вселенная взорвалась между 2 и 3, то пробужденный клиент увидит, что у него древняя версия WAL, получит WAL от мастера, и допишет его.
Разумеется, для этого мастер не должен удалять старый WAL (см. replication slots). Если у тебя standby сервер отвалился на сутки на высоконагруженном OLTP, то ты соснул хуй, но тут тебе никто не поможет.
У клиента есть гарантия, что его высеры попали в волы мастера и стендбая. А если они в волах есть, то рано или поздно окажутся и в базе, в своей страничке на восемь килобайт, не?
Фике, почитай ман, он неожиданно хорошо написан (ну как неожиданно? Постгрес вообще хорошо документирован, это не прыщи)
https://www.postgresql.org/docs/current/warm-standby.html
Если ты про реплику, то ты говоришь про сценарий из вселенной хэппи эндов разряда "База данных чихнула и сказала «ой, а чего это я!». И все засмеялись", в котором существует только одна параллельная транзакция. Базы данных не падают просто так, она либо до устранения проблемы вручную так и будет лежать, либо будет перезагружаться, либо это вообще проблемы сети - которая не целиком отвалилась, а порвалась в каком-то месте, и это обязательно будет какой-то свитч с протухшим питанием, которое заставляет его моргать по десять раз в минуту. И реплики нужны для двух вещей: снятия нагрузки с мастера для olap и для того, чтобы запромоутить реплику до мастера, когда мастер упадёт. И тут у тебя легко будет ситуация, когда на одной реплике A есть Т2 > Т1, но промоутишь ты B, на которой есть только Т1, получая в итоге фантомные данные. А реплика В тоже потом падает от нагрузки или моргающей сети, и тут у тебя уже вообще пиздец с историями.
> 2. master: (коммитит WAL)
Это, блядь, вообще пиздец. Я был уверен, что у пг два режима: сначала закоммить у себя, потом реплицируй (асинхронный) или сначала реплицируй, потом коммить (синхронный). Но тут оказывается, что синхронный это тоже асинхронный, просто чуть больше жонглирования временем и форматом ответа. Это значит, что второй клиент может прийти и прочитать на мастере данные, которых нет и не будет на репликах даже в условиях синхронной репликации.
> У клиента есть гарантия, что его высеры попали в волы мастера и стендбая.
Это если сценарий с хэппи эндом.
> он неожиданно хорошо написан
Я только что оценил максимально ебанутый поиск и невозможность найти четкого определения процесса репликации, где в синхронном случае совершается первый коммит - на мастере или на реплике.
А у огурца нет педалей. Разве кто-то с этим спорил?
>о промоутишь ты B, на которой есть только Т1, получая в итоге фантомные данные.
што?
Еще раз: мастер это единственный сурс оф трус. У мастера WAL. Стэндбай реплика поднялась, и говорит: "вот у меня версия мира 3", а мастер говорит "а у меня в воле есть запись 3->4". Сетндбай её забрал, и применил.
> или сначала реплицируй, потом коммить (синхронный).
тогда у стендбая будет более свежая версия, чем у мастера.
> Это если сценарий с хэппи эндом.
The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. (C)
Приведи конкретнывй сценарий, когда у тебя проебутся данные.
> где в синхронном случае совершается первый коммит - на мастере или на реплике.
Мастер на стендбаи шлет WAL посредством walsender, который читает уже записанный лог. Разумеется, мастер сначала пишет у себя лог, а затем шлет его стендбаям.
Разница между синхронной и асинхронной только в том, что в синхронной он ждет подтверждения, что стендбай записал WAL на диск* , а в асинхронной он бежит дальше. Ты же понимаешь, что все ченджи сначала пишутся в WAL, а потом проигрываются на настоящей базе?
*в случае внешнего рейда/hba в режимом write-back, речь идет о записи во временный кеш, отуда он сбросит данные на диск даже в случае отвала питания, если есть батарея
зы: `synchronous_commit` бывает еще "remote_apply", и тогда мастер ждет не только записи в вол, но и применения его
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT
Если ты хочешь пользоваться БД, то тебе не нужна потоковая репликация (aka warm standby).
Она тебе нужна только если ты скилловый петух, который хочет скилловые задачи решать, и тут уже придется выбирать стулья:
1. более быстрая работа, но меньшая надежность
2. наоборот
Это сложный трейдофф, который DBA вместе с бизнесом должен решить: иногда проеб минуты работы стоит три копейки, и похуй на него.
А иногда стоит миллион, и не похуй.
Я не знаю, как в других СУБД: может быть у оракла есть бесплатная, и не требущая настройки репликация, лишенная этих проблем?
В 80% случав тебе НЕ нужда потокая репликация: ты просто поставь RAID1, два БП, и память с ECC, и теки.
Ты понимаешь же, что репликация нужна если у тебя физически два разных компа? Это уже нифига не нубская конфигурация
Я могу просто течь, или нужно ебаться?
2. включи потоковую репликацию с него на два других
3. включи на мастере "synchronous_commit"remote_apply
4.перечисли два других сервера у мастера в "synchronous_standby_names"
Мне кажется, ты просто потечешь, и всё, не?
Всё, что делает постгря, это:
1. на мастере постоянно шлет лог на стендбаи
2. они его там выполняют
мастер выключил, стендбая запромоутил, всё. Всё вручную.
Нельзя из ружья выстрелить в случайных три компа из десяти, и надеяться, что само собой всё заработает.
Может быть и есть такие решения, но оин не из коробки постгри.
also, она не умеет в мульти-мастер даже (а напрример AD -- умеет), но когда у тебя мультимастер у тебя такая банка с червями (кворумы-хуероумы, рафты-паксосы, и византийские генералы) что там сам полковник Дибич ногу сломит.
patroni, stolon, paf
это какие-то стронние пеиухи, которые переключают тебе мастера сами, когда старый мастер отваливается?
Весь срач сводится к тому, что ты просто хочешь систему репликации БД, у которой будет и consistency, и availability, и partition tolerance.
Второй guest6 предлагает тебе комбинацию двух букв, ты замечаешь, что третьей нет, он тебе предлагает другую комбинацию двух букв, но тут внезапно обнаруживается, что той буквы, которая была раньше, теперь нет.
К сожалению, это не проблема «PostgreSQL».
P.S. Врана был тут:
https://govnokod.xyz/_23353/#comment-354037
А где творчество? Где творчество, я вас спрашиваю???
проблема в том, что потоковая репликация не про это: она про постоянный бекап просто. Она даже не пытается решить и без того нерешаемую проблему
Мастер ничего не говорит, он в этом сценарии упал. Он отреплицировал данные на А, но не на В.
тогда у стендбая будет более свежая версия, чем у мастера.
А там нет другого выбора, кто-то из двух коммитит первым
The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. (C)
А в доке кафки написано про exactly-once. В этом условии нет переключения мастера. А нахуя реплики, если его не переключать?
Приведи конкретнывй сценарий, когда у тебя проебутся данные.
1)
- Мастер среплицировал на А, но не на В
- В стала новым мастером
- А в этом промежутке была авторитетным источником данных
2)
- Мастер закоммитил у себя, но не среплицировал
- Второй клиент прочитал закомиченное с мастера
- Мастер умер вместе с диском
Ты же понимаешь, что все ченджи сначала пишутся в WAL, а потом проигрываются на настоящей базе?
Implementation dependent. Как и вообще наличие WAL в БД.
в случае внешнего рейда/hba в режимом write-back, речь идет о записи во временный кеш, отуда он сбросит данные на диск даже в случае отвала питания, если есть батарея
Это ещё один assumption, что беды у тебя не из-за дисков и не из-за контроллера
зы: `synchronous_commit` бывает еще "remote_apply", и тогда мастер ждет не только записи в вол, но и применения его
Меняет абсолютно ничего. Все эти настройки меняют только способы ответа клиенту, но никак не влияют на возможности десинхрона.
Значит, на мастере и на A есть свежие данные, а на B -- нету.
Ты можешь руками посмотреть где более свежие данные, что не так?
У WAL есть LSN, видно через pg_waldump
> В этом условии нет переключения мастера.
Переключи, пожалста. У тебя проблема в том, что тебе не понятно кого из стендбаев сделать новым мастером?
Посмтори у кого свежнее LSN?
> Мастер среплицировал на А, но не на В
- В стала новым мастеро
Сама стала что ли? Ты должен осознанно выбрать нового мастера. Проверь приведенной выше командой, укого WAL свежее.
> Implementation dependent. Как и вообще наличие WAL в БД.
Так. Во-первых журналирование сейчас есть примерно везде: от файловых систем (NTFS, ext3/4) до баз данных (Postgres, MS-SQL и пр).
Даже у экзотичной хуйни типа AD (хранилище называется ESET aka Jet Blue) есть лог.
Очень странно про него не знать, ну.
Нет, я не могу на это рассчитывать. Ты смотришь с позитивной точки зрения, что в сценарии стало плохо немножечко какой-то конкретной ограниченной штуке. Я смотрю с негативной, где руки могут быть обрублено по самое не могу. В случае рандомных партиций сети я не могу руками посмотреть узлы, к которым не могу пробиться. При этом то, что я не могу к ним пробиться, ещё не означает, что на них не может пробиться мастер с репликацией, например.
> Переключи, пожалста. У тебя проблема в том, что тебе не понятно кого из стендбаев сделать новым мастером?
Проблема в том, что те данные, которые были видны, как закомиченные, исчезли.
> Так. Во-первых журналирование сейчас есть примерно везде: от файловых систем (NTFS, ext3/4) до баз данных (Postgres, MS-SQL и пр).
Оно там не для репликации.
> Я не понял этой фразы. Ну если ты записал в контролер, а он сдох (например потому,что ты включил write-back и забыл вставить батарейку) то конечно ты проебал данные, но тут ты сам виноват.
Там может быть история хоть с рейдом дисков hpe, которые вставлялись в машину одновременно и одновременно же сдохли после 32768 часов работы. Это всё надежды, а не гарантии.
> Кроме того, твоя задача -- держать мир консистентным. Если ты проебал последнюю запись,
...то ты консистентность потерял
и что? У них или нет данных (и тогда они получат их от мастера) или есть данные, и тогда проблемы нет
>Проблема в том, что те данные, которые были видны, как закомиченные, исчезли.
Не может быть такого. Если данные видны как закомиченные, то они уже попали в WAL всех стендаьбаев, и там проиграются.
Если конечно под "видны как закомиченные" ты имеешь ввиду ответ клиента (потому что нихуя не понятно кому и что должно быть видно)
>Оно там не для репликации.
Как блядь не для репликации если физическая репликация в постгре буквально работает посредством шипинга лога?
Вот буквально запись в лог пеердается с мастера на стендбаи
(логическая рабоатет иначе, но мы нке про нее)
> которые вставлялись в машину одновременно и одновременно же сдохли после 32768 часов работы.
может (потому HDD лучше брать от рахных вендоров) а постгря тут причем?
>...то ты консистентность потерял
нет, не потерял. У тебя база совершенно консистнента на момент до первой записи.
Почитай как работает WAL:
https://www.postgresql.org/docs/current/wal-intro.html
Или тут (главы 10/11):
https://balka-book.com/files/2023/03_17/08_54/u_files_store_35_5.pdf
У клиента была возможность получить данные, которые потом исчезли.
У клиента будет возможность получить данные, которые не существовали в параллельной вселенной, после того, как сеть восстановится.
Это нарушение D в acid.
> Не может быть такого.
Я же два примера написал. Оно даже будет при чтении с разных реплик в отсутствие каких-либо инфраструктурных проблем. Оно упирается в проблему двух генералов.
> Как блядь не для репликации
Ответить на этот вопрос очень просто. Спросить "существовал бы WAL в postgresql, если бы там не было функциональности репликации" или "есть ли репликация в упомянутой ext4". Его удобно шипать, но он там не для этого, это просто приятный бонус.
> может (потому HDD лучше брать от рахных вендоров) а постгря тут причем?
При том, что мы не можем полагаться на то, что её архитектурная проблема будет решена соломой в виде нижележащей инфраструктуры.
> нет, не потерял.
В терминах ACID это конечно не C, а D, но с точки зрения приложения, которое предполагает, что каждое чтение отображает завершенное состояние, это будет отсутствием консистентности, нарушающим контракт.
Если клиент увидел данные, закомиченные в рамках другой транзакции, то эти данные уже есть в WAL мастера и всех его стендабев, иначе транзакция не закоммитится.
> Оно даже будет при чтении с разных реплик в отсутствие каких-либо инфраструктурных проблем.
Разумеется, ты можешь параллельно читать из мастера и стендбая, и получать из мастера более новые данные. Это нерешаемая проблема, потому что у тебя нет транзакции на два кластера. Не делай так.
Единственная гарантия -- консистенотность каждого отдельного кластера.
> генералов
В обсуждаемом нами сценарии нет мультимастера, откуда тут эта проблема?
>Спросить "существовал бы WAL в postgresql, если бы там не было функциональности репликации"
WAL не используется в репликации, потому что он существовал там до репликации.
Байты не используются в Интернете, потому что байты существовали до появления Интернета, ну.
Чтобы понять, как работает теплая потоковая репликация в постгрес (и перестать говорить что она нарушает "D") надо знать, как работает WAL.
>При том, что мы не можем полагаться на то, что её архитектурная проблема будет решена соломой в виде нижележащей инфраструктуры.
Ты так и не смог объяснить, какая у нее архитектурная проблема.
>В терминах ACID это конечно не C, а D,
С durability всё будет впорядке: если ты увидел транзакцию на мастере, то она есть в WAL других стендбаев, и там проиграется. При запуске кластер не даст тебе ничего читать, пока не проиграет свой вол полностью.
to be cont.
Вот тебе секвенс юмээль диаграмма рисовальщик, написуй мне сценарий, в котором нарушится "D".
https://plantuml.com/sequence-diagram
Это работает только в позитивном случае, когда ты переключился и пошел дальше пить чай, а дальше никогда ничего не происходило.
- У тебя развалился кластер на две части по причине сети. Мастер находится в недоступной.
- Ты назначаешь одну из доступных реплик мастером.
- Она не проигрывает свой WAL на всех стендбаях, потому что всех стендбаев у тебя уже нет, даже если только один мастер завалился, у тебя уже кластер размера N - 1.
- У тебя снова разрезает сеть, только теперь в противоположную сторону: часть, которая была недоступной, стала доступной, и наоборот.
- У тебя нет вариантов, кроме как назначить мастером кого-то, кто не видел всю историю. Вариант "не назначать никого" мы не рассматриваем по той причине, что мы обсуждаем как сделать систему отказоустойчивой и возвращаться в строй в случае проблем - если мы принимаем за норму "сидит вообще без сервиса", то сама идея вводить реплики для подхвата не имеет смысла.
Здесь мы и теряем durability.
> Не делай так.
Так это автоматом при переключении мастера происходит. Если ты назначил нового мастера, то всё.
(Есть ещё нюанс, что никто не разворачивает реплики, с которых не читают, но этих замечательных ребят мы не обсуждаем)
Существование WAL не обусловлено репликацией.
> В обсуждаемом нами сценарии нет мультимастера, откуда тут эта проблема?
У мультимастера нет какой-то дополнительной связи с генералами, она есть у любых двух обменивающихся данными узлов, количество продюсеров не имеет значения. Тут проблема из предыдущего абзаца, у тебя один узел коммитит первым, другой вторым, никакого выхода из этой ситуации нет. Либо данные появляются на реплике, когда их нет на мастере, либо наоборот. Смена мастеров делает ситуацию неразрешимой даже когда в один момент времени всё проходит только через один узел.
> Ты так и не смог объяснить, какая у нее архитектурная проблема.
Отсутствие консенсуса.
> Чтобы понять, как работает теплая потоковая репликация в постгрес (и перестать говорить что она нарушает "D") надо знать, как работает WAL.
Репликация не нарушает, нарушает отсутствие консенсуса. Потоковая она или нет - не имеет разницы, можно хоть последовательно записи передавать голубиной почтой в должном порядке с заметками обо окончании транзакции, это никак не меняет ситуацию - только даёт удобство, скорость и прочие ништяки, не влияющие на гарантии.
D нарушается по той причине, что запись на одном узле не обязательно существует на всех узлах, и отстутствие консенсуса, в общем случае проверки существования записи на мажорити при чтении этой записи, даёт свободу любым эффектам. Это не правило постгреса. Это правило _любой_ распределённой системы. Как именно осуществляется репликация, не влияет на возможные феномены, на них влияет наличие консенсуса.
> Во-вторых, если ты хочешь настраивать репликацию в СУБД, то всё таки нужно чото про нее почитать.
Давайте всё-таки не будем аргументировать к авторитету текстов. У кафки вон exactly-once существует.
Однако репликация не работала бы без WAL, потому полезно про него знать прежде, чем обсуждать репликацию.
> У мультимастера нет какой-то дополнительной связи с генералами, она есть у любых двух обменивающихся данными узлов
Проблема генералов и консенсуса имеет смысл только когда у тебя несколько источников правды. Когда у тебя один мастер, никаких генералов нет.
В постгресе в любой момент у тебя только один мастер.
> у тебя один узел коммитит первым, другой вторым, никакого выхода из этой ситуации нет
Я гляжу, ты так и не стал читать, как работает WAL. Давай я тебе помогу:
1. WAL пишется на master
2. WAL пишется на standby
3. после этого на мастере и на стенбае WALы проигрываются
Данные на стендбае не могут оказаться там раньше данных мастера.
Если же стендбай сдох, то ты его включил, и он закачал WAL с мастера, а после этого только дал к себе доступ.
Если же сдох мастер, то у тебя не закоммитилась транзакция, и клиент пошлет её снова. Если же ты сделал мастер стендбаем, он закачает более свежие данные с другого узла
>нарушает отсутствие консенсуса.
В warm репликации постгрес нет понятия "консенсус". Ты читаешь всегда с одного кластера.
При отсутствии мультмастера у тебя всегда все изменения идут через одного питуха, последовательно. В WAL есть LSN, и по немиу всегда можно понять что было позже.
Вот если у тебя случилось два мастера, то будет сплит, но тогда ты сам виноват: постгрес это не поддерживаает
The first general may start by sending a message: "Attack at 0900 on August 4." However, once dispatched, the first general has no idea whether or not the messenger got through. This uncertainty may lead the first general to hesitate to attack due to the risk of being the sole attacker.
Это источник правды. В нашем случае - мастер, который закоммитился первым.
To be sure, the second general may send a confirmation back to the first: "I received your message and will attack at 0900 on August 4."
Это потребитель правды. В нашем случае - реплика, которая слушает.
Например, в одном кластере ты уже перевел мне миллион долларов, а в другом не перевел, и можешь перевести их еще раз, и у меня будет два миллона
Реплики все ридонли, ты не можешь в них ничего менять.
Более того, клиент, реализующий интерфейс с другими систеами (с которыми он хочет поддерживать консистеность) должен работать с мастером. Не нужно ему рабоатть с ворм копиями: они для бекапа.
А как там появляются новые данные?
Считываются с мастера.
Напомни, я не говорил случайно, что это не мультимастер? Что ты не можешь в любую реплику писать? что ты должен писать всегда в мастер, и он раскатывает потом евенчуали на реплики?
Проблему двух генералов мы сейчас обсуждаем без какого-либо участия клиента, его нет в этой истории. Есть мастер, который распространяет изменения, есть реплики, которые их принимают. В этой системе данные, даже без клиента в картине, должны закоммититься. Если они просто начнут обмениваться сообщениями "я послал тебе данные, готов коммититься" - "я принял данные, сообщи когда коммититься" - "я готов коммититься, а ты?" - "а я готов, а сам-то как?" - то это и является проблемой. У нас остаётся выбор:
- Мастер оптимистично признаёт данные закомиченными, отправляет реплике (репликам) сигнал "вот эта транзакция официально принята и видима", реплики записывают эту информацию следом за мастером
- Мастер рассылает реплике (репликам) сигнал "примите эту транзакцию как видимую", у себя ставит такую же галку только после N ответов
В этой системе не существует ситуации, когда все участники одновременно приняли транзакцию. У кого-то её может быть вообще нет, у кого-то она висит в пендинг, у кого-то уже принята. В этот момент существует расхождение историй, если это первый сплит, то пока ещё бесконфликтное, но уже существующее: если опрашивать два узла, то видимость данных на них будет разная.
Это всё является и проблемой двух генералов, и ключами к воротам для аномалий. При этом в этой схеме пока нет ни клиента (если мы будем рассуждать в более общих терминах, то у нас и понятия клиента не будет, только обмен данными), ни мультимастера.
В смысле? Почему я не могу просто записывать нужные странички под локом всей системы и отправлять потом в любом виде, в котором мне нужно?
> Когда у тебя один мастер
Ты переключаешься. У тебя их априори несколько.
> В постгресе в любой момент у тебя только один мастер.
Нет, если ты руками назначаешь узлы, то это не так.
> 1. WAL пишется на master
> 2. WAL пишется на standby
Это и есть то, что я описываю.
> Данные на стендбае не могут оказаться там раньше данных мастера.
Данные на разных стендбаях могут оказаться от разных мастеров.
Это работало бы, если бы нельзя было а) назначить произвольного мастера с произвольными репликами или б) был некоторый внутренний механизм, трекающий количество участников кластера и запрещающий создавать кластеры из подмножества меньше чем мажорити.
> Если же сдох мастер, то у тебя не закоммитилась транзакция
Ты же сам пишешь: 1. WAL пишется на master
Это проблема двух генералов. Либо мастер коммитит раньше, чем реплика, и тогда нарушается контракт, либо реплика раньше мастера, и тогда появляется фантомная история, не присутствующая на мастере.
> В warm репликации постгрес нет понятия "консенсус".
Оттуда и проблемы. Что есть один мастер, которому поебать на то, что знают и видят другие.
В warm stand by replication нет понятия "лок всей системы'
>Данные на разных стендбаях могут оказаться от разных мастеров.
В warm stand by replication нет понятия "нескольких мастеров"
Мастер + единственная реплика.
На мастере (тут некоторые ошметки от другого скрипта, у меня сил не хватит всё перерабатывать):
оба возвращают что надо
реплика теряет коннект
с мастера пытаются записать
запись висит, как и должна
у мастера моргает электричество
мастер не потерял конфигурацию
слейв всё ещё жив, но записи "split" нет
любой клиент, достучавшийся до мастера, прочтёт запись, которая исчезнет вместе с мастером
Она окажется там не сразу, но это никто и не гарантирует: WAL среплицируется, и проиграется там.
Ты не можешь прыгать с между кластерами, и ждать, что они всегда будут отдавать тебе одну информацию.
Warm standby вообще не для этого: он не для того, чтобы ты мог по двадцати серверам прыгать, он для быстрого восстановления из бекапа. Ты можешь читать данные с него, но они могут быть не очень свежие (как и в любом бекапе).
Думай о потоковой репликации как о бекапе, который попингуй делает на стример каждые N милисекеунд
Ну вот же выше репро, что нет
И eventually разбивает весь ACID вдребезги
Если оно долетает eventually, то это значит, что существует ситуация, когда на мастере данные опубликованы, а на реплике нет -> мы опять с потерей мастера теряем эти данные.
Лондон столица Парижа.
Нет, реплика не часть кластера.
Кластером называется один сервер постгри, работающий с несколькими базами данных.
Реплика это другой кластер.
Стендбай это теплая репликация, которая в любой момент заменить сдохший мастер. Смысл её в том, чтобы время восстановления из бекапа было минимальным.
Представь себе, что ты делаешь бекап раз в час, с помощью тулы `pg_dump(1)`. Разве ты ждешь отсюда каких-то буков из CAP? Думаешь о генералах?
Скорее всего нет, ты думаешь просто о том, что если шифировальщик зашифрует твою базу, ты сможешь восстановиться на час назад, и не проедать хотя бы час работы.
Потоковая репликация это тоже самое, только ты делаешь бекап после каждого коммита. Никто не гарантирует тебе, что ты можешь скакать по мастеру и стендбаям. Никто не обещает какой-то распределенности. Это просто обычный бекап, только очень частый (чтобы поменьше проеебать, и быстрее развернуться)
Ты говоришь "мы нарушаем ACID", но ACID гарантирует один кластер (я бы сказал "один иностанс `postgrres(1)`, но не могу: он может форкаться").
У нас нет понятия "системы в целом", которая дает какие-то гарантии, потому что это просто бекап.
Я-то нет, но утверждение было, что система с репликами соблюдает D. Выходит, что нет. Разговор был именно про мастер + реплики и про синхронную репликацию, не инстанс в изоляции.
Во-вторых, если ты хочешь настраивать репликацию в СУБД, то всё таки нужно чото про нее почитать.
>Это ещё один assumption, что беды у тебя не из-за дисков и не из-за контроллера
Я не понял этой фразы. Ну если ты записал в контролер, а он сдох (например потому,что ты включил write-back и забыл вставить батарейку) то конечно ты проебал данные, но тут ты сам виноват.
>Все эти настройки меняют только способы ответа клиенту
не совсем: в асинхронном режиме мастер может у тебя убежать уже так далеко вперед, что клиент его никогда не догонит, а в синхронном он будет ждать.
Кроме того, твоя задача -- держать мир консистентным. Если ты проебал последнюю запись, но получил консистентную картину на минуту назад, то всё хорошо.
Если у тебя есть связь с внешими системами (с коьорыми тоже нужно быть консистентынм) то тут как раз отвал клиента и поможет: не сообщай банку что ты провел транзакцию, пока не получил ответ от мастера.
Нагугли "postgres 16 изнутри pdf" (она на русском, бесплатна) и почитай 10 и 11 главы, про WAL очень важно знать
Ты включил потоквую репликацию синхронную чтоли?
вот, кампуктер для сёмы сделали
Тут тончно eek -> англ. ook (дуб) и hoorn это анг. acorn (жолудь)
ja hoor
https://x.com/Rainmaker1973/status/2012200047962714238
К сожаолению, постгресу нужен или DBA, или петух, который осилил вдумчивно почитать документацию. Но может есть готовые докер-имаджи боль-мень внятно настроеные, неебу.
https://pgtune.leopard.in.ua/
Обычно тебе надо ответить на вопрос:
1. сколько памяти сервера ты готов отдать постгре под буфера
2. сколько у тебя будет примерно коннектов
3. сколько памяти нужно коннекту (ну будет он там делать временные таблы или джойнить 256 таблиц между собой, или будет делать в основном селект из одной)
4. насколько у твоего хранилища скорость последовательного доступа выше случайного (это про индексы/vs seq. скан. понятно, да?)
5. насколько тебе страшно проебать какие-то данные: согласен ты в случае выдергивания шнура из компа потерять несколько секунд работы, или вот вообще пиздец никогда? Сюда же относится: есть ли у тебя упс, батарея в рейде в случае write-back (райт сру похуй) итд
6. сколько места ты готов отдать под бекап, и сколько времени на восстановление. Готов восстанавливаться 20 минут? Тогда можно чекпоинты делать пореже, но и дрочить диск поменьше.
7. есть ли у тебя huge pages? если да, то сколько ты отдашь постгре?
Крмое того, можно профилировать работу, и чото настраивать. Обычно всем похуй, если только ты на хуй лоад. А когда ты хуй лоад, у тебя выделенный DBA, который с этим ебеца.
Первым аргументом там очередь, в которую нужно покласться, но это не важно.
Собссно, загадка: в сишне нет лямбд, но как же работает
?
(опотные сишнки сразу поймут, просьба не подсказывать, вопрос для скриптомакак)
неужели кто-то не справился?
Если что, макрос — это не API, это фактически твой код, который ты можешь кромсать на своё усмотрение. И имена макросов в приличном обществе принято писать ЗАГЛАВНЫМИ.
думаешь, я из головы его придумал?:)
https://elixir.bootlin.com/linux/v6.18.6/source/include/linux/wait.h#L501
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-ioassignarcname
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
И замыкания есть:
https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
И даже так можно:
Как понимаешь, присваивать это выражение int (*max)(int, int) совсем не обязательно, его можно и в функцию передать как аргумент типа указатель на функцию.
Это если wait_event_interruptible должна подставлять аргумент. А если petuz глобальный, то ещё проще:
У ядра вообще очень много низкоуровневой хуйни, за которую прикладники плюнули бы в рожу
А знаешь, как ядерщики называют бизивейт?
"Спинлок".
https://www.youtube.com/watch?v=7CfpGpPmMKA
Из «Яндекса».
https://www.pjsgames.com/cdn/shop/products/Back-to-the-Future-NES-Nintendo-Game-Screenshot-1.jpg?v=1481336155&width=1497
Если интерфейс говно, то реализация, скорее всего, тоже будет не очень, как ни старайся...
ИДИ НА ХУЙ
ты что, с ума сошел? На кой черт тебе вагрант в 2026-м году, когда докер десктоп есть буквально везде?
Я, если честно, тестовую сеть из виртуалок собирал просто тупо создавая виртуалки, и объединяя их через виртуальные свичи (это было на хиперви) но если тебе удобнее вагрантом, то ок
хотя мне кажется просто скрипт нагавнять проще
есть вариант разряда напрямую подцепить libvirt, но там ещё больше геморроя уйдет на то, чтобы подготовить готовый образ, в котором уже можно гонять что надо, что и выполняет вагрант своими боксами
а libvirt это типа API чтобы говорить гипервизору "гипервизор-гипервизор, создай виртуалочку о трех интерфейсах четырех виртуальных ядрах"?
“Only implement the minimum needed for ChromeOS and container‑VM workloads.”
Нужно чтобы на нашей хуйне запускалась поебень размером пара гигов которая жрет 800 мегабайт памяти сходу, и собирается четыре часа на 12-ти ядерном i9, потому что ей нужно реализовать все кривые хуевые стандарты которые как-то сами собой высрались анскильными петухами за последние тридцать лет, и теперь это говно занимает больше чем ВСЯ НАХУЙ операциона на которой крутился ebay в 90-х.
Потом пускаем туда веб-макак, и они высирают еще 800 мегабайт node_modules и получают веб-приложение по удосбтву сравнимае с Windows 95.
ну как идея?
Тим Бёрнс Ли, иди нахуй.
просто иди нахуй, там тебя уже ждут Райан Даль и Брендан "голова-как-у-глиста" Айк.
Реально Лердорф и Видениус со своей сраной ЛАМПочкой меньшее зло сотворили, чем блядь екма262слизь
8б уже так себе. Плохо!
"AI пидор! AI пидор! AI пидор!": шепот пронёсся по коридорам говнокода. При виде AI пидора программисты делали лица кирпичем, и старались перейти на другую сторону коридора.
AI пидор, как это часто бывает у людей с лёгкой степенью олигофрении, смотрел на жинь позитивно: AI только что сгенерил ему тринадцать тысяч примерно одинаковых файлов, и AI пидор собирался их закоммитить весело капая слюной на клавиатуру.
Мне в целом чтобы бот хуйней отвечал
---
Это кстати оказлся инференс на цпу лмаоооооо
Там только-только в ллама цпп саппорт добавили
Unable to find image 'ghcr.io/snapdragon-toolchain/arm64-android:v0.3' locally
v0.3: Pulling from snapdragon-toolchain/arm64-android
docker pull --platform linux/arm64 ghcr.io/snapdragon-toolchain/arm64-android:v0.3
Unable to find image 'ghcr.io/snapdragon-toolchain/arm64-android:v0.3' locally
v0.3: Pulling from snapdragon-toolchain/arm64-android
docker: no matching manifest for linux/arm64 in the manifest list entries
от это багрище, тулчейн для арма не существует на арме
Или у тебя малинки-малинки?
> snapdragon
[BEGIN]: 1. It is a complex tool that requires extensive knowledge of programming and scripting.
2. It is not as widely used as some other automation tools.
3. It can be difficult to debug and troubleshoot.
4. It is not as flexible as some automation tools.
5. It can be slow and resource-intensive.
6. It can be difficult to maintain and update.
7. It can be difficult to manage permissions.
8. It can be difficult to configure and update.
9. It can be difficult to manage and scale.
10. It can be difficult to use with different types of infrastructure.
11. It can be difficult to use with different programming languages.
12. It can be difficult to use with different types of automation tools.
13. It can be difficult to use with different types of automation.
14. It can be difficult to use with different types of automation.
15. It can be difficult to use with different types of automation.
16. It can be difficult to use with different types of automation.
17. It can be difficult to use with different types of automation.
18. It can be difficult to use with different types of automation.
19. It can be difficult to use with different types of automation.
...
39. It can be difficult to use with different types of automation.
40. It can be difficult to use with different types of automation.[END]
хорошо-то как )))
-- It is a complex tool that requires extensive knowledge of programming and scripting.
evaluations and penetration tests prior to release. No details of these audits appear to be in
the public domain at the time of writing.
кмбу
We show that s2n — as initially released — was vulnerable to a timing attack on its
implementation of CBC-mode ciphersuites. Specifically, we show that the two levels of protection offered against the Lucky 13 attack [AP13] in s2n at the time of first release were
imperfect, and that a novel variant of the Lucky 13 attack could be mounted against s2n.
The attack is particularly powerful in the web setting, where an attack involving malicious
client-side Javascript (as per BEAST, POODLE [MDK14] and Lucky 13) results in the complete recovery of HTTP session cookies, and user credentials such as BasicAuth passwords.
дальше можно не читать, впринципе. Денис Попов изобрел алгоритм шифрования, который невозможно взломать, и алгоритм сжатия, гарантирующий сжатие в десять тысяч раз любого zip файла.
No details of these checks appear to be in the public domain, но его мама сказала, что работает
НОРМАЛЬНЫЕ массивы
НОРМАЛЬНЫЕ объекты
НОРМАЛЬНЫЕ параметры
НОРМАЛЬНЫЕ типы
НОРМАЛЬНЫЙ пайпинг
НОРМАЛЬНАЯ совместимость
НОРМАЛЬНАЯ интеграция
https://web.archive.org/web/20070110032136/hottabych.net/kisa/
КИСА КУКУ
Чем доказывается, что это не кот-близнец?
https://govnokod.ru/29220
https://govnokod.xyz/_29220/