В очередной раз увидел эту штуку в мане к procfs. Возник вопрос - почему везде дефолт 0? Это же дыра для всяческих утечек. От 1 или 2 что-то может сломаться? В фрибсд всегда настраивал сокрытие чужих процессов, и даже инсталлятор там предлагает это сделать (с некоторых пор). В линуксе же кроме абзаца в мане нигде почти не упоминается, как будто не принято.
Система FreeBSD.
Ситуация такая: входящие пакеты собираются сетевухой LRO в один большой tcp-сегмент. Дальше оно должно роутиться на другой интерфейс, в него такой большой пакет не влезает. Даже если послать назад icmp ошибку, исходный хост же не виноват в ситуации и исправить ничего не сможет. TSO на втором интерфейсе нет.
Очевидное решение - отключить LRO, но есть и нетранзитные соединения (их даже большинство), где он полезен. Какие у кого есть мысли по этому поводу?
Способов нарезать назад большой tcp-сегмент на маленькие же нет? (речь не про ip фрагментацию а перепаковать именно tcp)
Это же очень важное событие для линукса, как её можно удалять?
Заметил такую штуку. Если на входящий («in») пакет сделать fwd для смены ему next-hop (старый next-hop был локалхостом в связи с тем что dst ip локальный, новый - внешний), то при последующем проходе правил на выходе для исходящего («out») пакета интерфейсом отправки всё равно значится «lo0». Т.е. пакет можно файрволить правилом с «out xmit lo0», однако на самом деле он шлётся по указанному в первом проходе файрволла next-hop-у через соответствующий ему интерфейс.
Планирую позже посмотреть маны и исходники на этот счёт, чтобы узнать это так и задумано или баг, и если баг то отправить репорт. А пока что написал тут, вдруг кто уже знает ответ.
Меня время от времени обзывают луддитом в связи с моим осуждением некоторых современных модных ИТ-штук.
Извиняюсь за внешнюю ссылку, но нашёл интересную статью про данную тему.
Ъ:
Луддиты вовсе не воевали против машин, они и сами их использовали в своей частной работе. Данный образ (борцы против автоматизации) - карикатура на них, созданная капиталистами с целью луддитов дискредитировать в глазах общества. Оборудование они, иногда, действительно ломали, но не из-за ненависти к автоматизации, а из-за желания навредить владельцам соответствующих фабрик.
Причина недовольства такая: были ремесленники, которые делали качественную продукцию (в том числе на станках), живя при этом вполне комфортно и самостоятельно выбирая сколько и когда времени посвятить работе. Потом появились коммерсанты, которые решили производить дешёвый ширпотреб, нанимая к себе не особо квалифицированную рабочую силу на конвеер, и заставляя эту самую рабочую силу работать максимально длинными сменами. Оказалось, что народ в массах привлекается низкой ценой больше чем высоким качеством, и добросовестные ремесленники начали проигрывать конкуренцию. Идти на фабрики производить ширпотреб по 15 часов в сутки за нищенскую оплату они, разумеется, не хотели, и поэтому решили вразумлять владельцев этих фабрик чтобы те сменили политику.
То есть тут прослеживается два аспекта: 1) социалистические идеи о том что трудящиеся должны жить хорошо и не должны эксплуатироваться капиталистами, 2) противодействие скатыванию своей профессии к производству хлама. Войны же с автоматизацией среди мотивов не было, это была только идеологическая карикатура на них.
В упоминаниях, если маркдаун выбрать.
Представим, что юзер открывает файл размером 10гб в редакторе кода и пролистывает хоткеем в конец. Допустим, редактор умеет корректно работать без предварительной подгрузки всего файла в память (под ответственность юзера что файл никто со стороны не испортит в неожиданное время, или пусть вообще он в read-only режиме - просмотрщик кода). Как редактор кода должен себя вести в плане подсветки синтаксиса?
В техническом плане тут всё очевидно: пока редактор не прочтёт и не распарсит все 10гб, сделать гарантированно правильную подсветку в конце он не сможет (ведь где-то в середине может быть открывание комментария, например). Вобщем-то и варианты поведения очевидны (ниже напишу), вопрос именно в том, какой их них наилучший в плане удовлетворения юзера. Допустим даже в конфиге можно выбирать эти варианты, но есть же дефолт - и он должен быть максимально не бесящим насколько это возможно.
Варианты:
1) залагать и парсить подсветку этих 10 гб, и только когда оно доделалось отлагать и нарисовать всё
2) нарисовать конец файла без подсветки, парсить её в фоне (где-нить выводить % готовности) и как закончим - нарисовать с подсветкой
3) нарисовать конец файла с черновой подсветкой, распарсенной без учёта пролистанных мимо страниц (ну, возможно ещё захватить сколько-то кбайт/строк выше верхней границы видимости), в фоне парсить нормально и как дойдёт до конца - перерисовать
4,5) варианты 2,3 но в фоне ничего не парсить и так и оставить (ведь юзер может оказаться недоволен нагрузкой на диск или на проц, из-за которых лагают другие проги)
6) каждый раз в таких случаях спрашивать у юзера хочет ли он фоновый или нефоновый парсинг (в виде попап окна) и надо ли делать предварительную неточную но быструю подсветку
Если ли способ её просто запустить (с линуксом и снаружи и внутри, разумеется), без выяснений каких-то особенностей зоопарка arm-железок? Я когда-то пытался это сделать, оказалось что «просто arm» не существует, а есть куча мучений которые надо преодолевать.
Вот чтобы я запускаю qemu с некоей командной строкой, появляется окно с экраном где видно как грузится ядро, юзерспейс например дебиана, и в конце пусть командная строка (гуи не нужно, хотя если будет гуи то тоже норм) и работающий сетевой интерфейс для связи с хостом.
А, наверно надо не только возможность запустить систему, но и возможность перед этим запустить её инсталлятор с iso-образа.
И есть ли разница в запуске 32 и 64 битных?
Хочу покодить кое что на arm ассемблере и надо где-то проверить что оно работает, а нативных arm-железок у меня нет.
Обычно сидя за столом, но замечаю у себя желание повесить монитор на стену напротив кровати, а клавиатуру прицепить как-то чтоб можно было лёжа ей комфортно пользоваться. Потом вспомнил противоположный пример - Линуса с его беговой дорожкой (кстати он до сих пор ей пользуется, не знает кто?). Возник интерес как это у остальных. Варианты думаю примерно такие:
1) сидя за нормальным столом
2) сидя, но нормальный стол не участвует
3) стоя за столом
4) стоя без стола
5) лёжа на спине
6) лёжа на животе
Для опросов в левую колонку думаю не тянет, поэтому в толксы.
Сейчас регулярно вместо этой кнопки приходится пользоваться вводом даты коммента в поиск и пролистыванием найденного, чтобы не грузить ещё одну страницу в которой будут не только ответы на это сообщение, а вся дальнейшая ветка. Было бы хорошо сделать рядом кнопку перехода по якорю на первый ответ, а рядом с надписью «ответ на» - ссылку на следующий ответ на то же сообщение, чтобы можно было просматривать их по цепочке ничего не перезагружая.
«Правительство обещает включить в законопроект описание требований по маркировке ИИ-контента, поставив точку в спорах о том, нужно ли маркировать нейрогенерацию или же, наоборот, что создано без участия ИИ. Как вы знаете, я придерживаюсь „органического подхода“, ведь нейрослоп плодится в интернете не просто быстро, а лавинообразно», - подчеркнул Горелкин.
Можно ли подсунуть smartctl-у бинарный дамп смарта (блоб 512 байт), снятый ранее отдельно (+ указать модель диска), чтобы он его распарсил и показал в удобном текстовом виде?
Вопрос не про то, как это где-то уже реализовано, а про то, какой из вариантов вам кажется наиболее удачным.
Пример, исходное состояние:
echo greet
./prog1
./prog2
./prog3
первая ветка от него с таким коммитом:
echo greet
echo test
./prog1
./test
./prog2
./prog3
вторая - с таким
echo greet
echo test
./prog1
./prog2
./test
./prog3
Мержим эти две ветки, что должно в итоге получиться?
Вариант [1] - конфликт
Вариант [2]
echo greet
echo test
./prog1
./test
./prog2
./test
./prog3
Вариант [3]
echo greet
echo test
echo test
./prog1
./test
./prog2
./test
./prog3
Или ещё что-то?
В трекере перечисляются недавние (последние) сообщения во всех темах, но ссылки почему-то ведут не на эти самые указанные сообщения, а на начала тем. По-моему это нелогично.
Я не знаю, какой раздел лучше подойдёт - этот или games, если что переместите.
----- введение, если знаете эту игру и её механику можно пропустить -------
И так, есть такая игра - cookie clicker, её суть (если опустить несущественные для задачи аспекты - их там много, но давайте их не обсуждать тут) такова: есть некий счёт, и он автоматически растёт каждую секунду на величину cps, которая зависит от того, какой набор «построек» куплен (покупка построек делается как раз с оплатой из этого счёта). Постройки есть разных типов, для удобства представим что их всего два (постройка типа A и постройка типа B). У каждого типа постройки есть:
- цена, стартовая за первый экземпляр, и дальше каждый следующий в k=1.15 раз дороже - геометрическая прогрессия
- прибавка к cps, которая даётся при покупке очередного экземпляра: если купить 10 построек, они дадут в 10 раз больше cps чем если купить одну, то есть каждое следующее добавление одного и того же cps получается дороже
Итого, текущее состояние описывается текущим счётом, количеством построек типа A и количеством построек типа B.
---------- собственно задача ------------
Текущий счёт у нас нулевой (только что всё потратили), и имеется некоторое cps = x0. Для покупки доступны две постройки:
Первая (A), с текущей ценой за штуку y1 и дающая прибавку x1 за ту же штуку.
Вторая (B), с текущей ценой за штуку y2 и дающая прибавку x2 за ту же штуку.
Первая дешевле (y1<y2), даёт меньше cps (x1<x2) и имеет худшее отношение цена/качество (y1/x1>y2/x2). Очевидно, если захотеть купить хоть что-то, то её мы сможем купить раньше - она дешевле. Вопроса два, простой и сложный.
Первый: мы хотим купить одну штуку A и одну штуку B, покупаем как только накопим. В каком порядке их надо купить чтобы быстрее добиться цели?
Второй: мы хотим максимально быстро поднять cps до некоторой неуказанной величины. Сколько раз надо купить постройку A перед первой покупкой постройки B? (формулировка не идеальная но надеюсь понятно о чём речь)
Речь именно про аналитическое решение. В первом вопросе - неравенство, в зависимости от выполнения или невыполнения которого мы выбираем один из двух вариантов ответа. Во втором - формула, которая выразит искомое число через заданные в условии переменные (+ можно задать одно граничное условие). Просто описания алгоритмов и тем более брутфорсы в качестве итогового ответа не годятся.
Найти удовлетворяющий требованиям ответ на второй вопрос мне найти пока не удалось, думаю будет интересно и недоделанные решения посмотреть.
Заголовок покороче придумать не смог.
При работе в консоли, обычно (но, к сожалению, не всегда), можно набирать заранее весь нужный клавиатурный ввод, а софт его сам, когда надо, прочитает и обработает. К слову, в ДОСе это работало ещё чаще чем в консоли современных юниксов, но там был маленький буфер ввода всего на 16 (или 32, не помню) нажатий.
В гуи ситуация обычно кардинально другая. Вот представим, я хочу запустить терминал, запустить в нём файрфокс и открыть в этом файрфоксе какой-то урл (благо фф при запуске ставит фокус на адресную строку, иначе было бы совсем печально). Тут надо:
1) нажать хоткей (или у кого-то кнопку) запуска терминала
2) подождать пока он запустится
3) набрать в нём команду и энтер
4) подождать пока запустится фф
5) набрать в нём адрес и энтер
Если не уделить должного внимания пунктам 2 и 4, ничего хорошего не получится. Хуже того, начавшее появляться окно фф не означает что 4 пункт сделан, надо ждать пока появится курсор в адресной строке.
Я понимаю, конкретно указанное действие можно реализовать иначе, вообще без терминала и с передачей урла в аргументе, но речь не про это, а про саму концепцию взаимодействия с гуи. И ещё, речь не про скорость работы компа (на достаточно быстром компе пункты 2 и 4 станут незаметно быстрыми, но проблема не в том, что они долгие, а в том что они вообще существуют).
Неужели никто не пытался это исправить? Есть ли какие-то общеупотребительные подходы?
В терминалах кстати это тоже бывает, некоторый софт сжирает весь текущий stdin без намерения его как-то обрабатывать, но пожалуй это другая тема.
Я что-то раньше не обращал внимания, а в линуксе локалхостовые роуты где-то списком можно посмотреть (ну кроме ifconfig чтобы узнать оттуда айпишники всех интерфейсов)? В фрибсд они в таблице роутинга наравне с остальными присутствуют. Имеется ввиду что вот допустим у компа есть локальный адрес 192.168.1.77 и в таблице будет что адрес 192.168.1.77 доступен через lo. Ну и 127.0.0.1 аналогично.
Насколько у меня отложилось в памяти, на каких-то древних системах readdir() возвращал данные в статическом буфере, общем на весь процесс, то есть код вида
{
DIR *dp1, *dp2;
struct dirent *a, *b;
//....
a = readdir(dp1);
printf("name1 = %s\n", a->de_name);
b = readdir(dp2);
printf("name2 = %s\n", b->de_name);
printf("name1 = %s\n", a->de_name);
//....
Кто-нить помнит о каких системах речь и где об этом почитать? Или это всё чисто теория и в реальности таких систем не было? Или я вообще всё это выдумал и нигде такого не упоминалось?
Наберите от рута lsattr -al /dev/ только на всякий случай на некритичном компе - что произойдёт?
Добавлю что получилось у меня, по /var/log/messages
Nov 28 02:38:39 nb2 kernel: [4438721.540616] NET: Registered protocol family 40
Nov 28 02:38:39 nb2 kernel: [4438721.613867] tun: Universal TUN/TAP device driver, 1.6
Nov 28 02:38:39 nb2 kernel: [4438721.683373] Non-volatile memory driver v1.3
Nov 28 02:38:39 nb2 kernel: [4438721.877780] Btrfs loaded, crc32c=crc32c-intel
Nov 28 02:38:39 nb2 kernel: [4438721.935117] serial 00:02: LSR safety check engaged!
Nov 28 02:42:14 nb2 kernel: [ 0.000000] Linux version 5.10.0-26-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.197-1 (2023-09-29)
Nov 28 02:42:14 nb2 kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-26-amd64 root=UUID=b595a138-37e4-4775-8edd-27e7455d14a1 ro acpi_backlight=vendor "acpi_osi=!Windows 2012" module_blacklist=echi_pci,ehci_hcd quiet
Как видно, lsattr подгрузил пачку каких-то ненужных модулей. А через некоторое время (секунд 15?) ноут молча ребутнулся, похоронив открытые окна за полтора месяца :(.
Корень причины понятен: в отличие от нормальных людей, у которых файловые флаги отдаются через stat(2), в линуксе чтоб их получить надо делать какое-то ioctl на открытый файловый дескриптор (и открывание с O_PATH не годится). Отсюда последствия: 1) на симлинках не работает, 2) попытка чтения их из chr/blkdev или pipe может иметь побочные эффекты т.к. открывание таких файлов их имеет (но в итоге всё равно фейлится, по крайней мере для файлов устройств). Тут кстати, неустранимый race получается - невозможно пытаться прочитать флаги, будучи уверенным что не откроешь случайно файл какого-нить устройства. Хорошо хоть следовать по симлинкам можно запретить через O_NOFOLLOW, а то было бы совсем печально.
Механизм конкретно моего сценария - точно не пойму, но есть два предположения: 1) грузится какой-то забагованный модуль (не обязательно из тех четырёх, ведь они могут и молча грузиться не отправляя ничего в dmesg) который спустя недолгое время роняет ядро 2) активируется какой-то hw watchdog, который допустим надо после этого оповещать раз в 10 секунд для избежания аварийных ребутов
Раньше я делал read() на 1048576 байт, в gstat он показывался как 8 чтений по 131072 байт, которые отправлялись очередью. После обновления 12 -> 13 в gstat оно стало видно как 1 чтение 1048576 байт, и ухудшилась скорость работы. Такая зависимость скорости от размера блока - будем считать, особенности железа, речь не про неё.
Вопрос вот какой - почему оно раньше нарезало мегабайт на части а теперь перестало, как вернуть старое поведение? Вручную делать 8 read-ов вместо одного не годится, тогда каждый следующий ждёт ответа от предыдущего и не работает hw очередь запросов.
Это всё с O_DIRECT если что, а диски multipath.
Уточнения:
1) от multipath не зависит.
2) несмотря на O_DIRECT он походу делает read-ahead, потому что см. ниже
проверял dd iflag=direct с разными bs
размер в read() размер в geom было - стало
1K 32K 32K
2K 33K 33-34K
4K 35K 36K
8K 39K 42K
16K 50-51K 62K
32K+ 128K 1M
Если кто захочет у себя потестить, код для узнавания размера geom-чанка
while true; do X=`gstat | grep -F тут_шаблон_для_грепа_строки_с_нужным_диском` ; rs=`echo $X | awk '{print $3}'` ; kbs=`echo $X | awk '{print $4}'` ; bs=`expr $kbs / $rs` ; echo "$rs $kbs $bs"; doneСамо чтение:
dd iflag=direct if=путь_к_большому_файлу_на_нужном_диске of=/dev/null bs=1024
| ← предыдущие | следующие → |