У меня еще 1 вопрос, https://cockpit-project.org/ живое и юзабельное?

community blog - это для тех кто контрибьютить хочет любым способом, в magazine - для внешнего мира

Но всё равно, я уверен, что у феско бложика примерно 0 читателей кроме участников федора сообщества

в этом и смысл

А есть еще какие-то бложики?

на ask-форуме помощи просят, а на discussions - опять же всякие глубокомысленные темы обсуждают, хотели как замену мейллистам сделать. но вряд ли оно приживется

а что оно не https ?

Не приживается из-за инертности. Мне движок discussions.fedoraproject.org оч нравится.

Не приживается из-за инертности. Мне движок discussions.fedoraproject.org оч нравится.

движок ок, но визуальный мусор на главной странице раздражает

Вполне чистый и незагроможденный интерфейс

ну разница как между pidgin и riot

аватарки отступы, шрифт крупный и т.п.

Это я о том, что планета федоры страшно тупит.

Но в целом оч нравится UX хоть и непривычно немного. Все таки это больше как форумный движок и если вспомнить предшественников, то там вот был ад и весь этот информационный мусор, подписи и т.д.

UX - да, с phpbb не сравнить конечно

Я сейчас за городом и у меня медленный интернет. Удивительно, но сайты написанные на современных фреймворках более отзывчивые, чем классические ребята. Загрузить 1 раз жс бандл в 2 мб менее больно, чем ждать загрузки каждую страницу. Интернет всё же становится лучше)

а я пожалуй именно себе представляю рассылки как газету. такое длинное чтение за чашечкой кофе, и оформление мелким шрифтом длинные тексты по три страницы..

три содержательных строки на экран

И если бы это был один длинный пост, то было бы ОК

не, вот все кроме текстовых полей убрать и было бы нормально

Кстати в настройках можно выбирать размер шрифта. Нужно создать Feature request: Zen mode чтобы запилили чтобы без полей и т.д.

А можно спросить, почему так пересжато? Это специально?

ну и это вот важный момент: в рассылки просто не пишут по одному предложению. потмоу что письмо - это серьезно, а в форумы постят. При попытке переместить рассылку в форум она теряет концентрацию инфы на единицу поста.

а на лор я пока чайник кипит успеваю 15 комментов написать ни о чем

Палево 😄 docker-ce.repo

Ну еще потому что En vs Ru lang.

Даже он пишет что некоторые вещи нужно делать только после одобрения folks которые отвечают за какое-то узкое место в ядре. Я к тому что нет одного человека который бы понимал как надо сделать это правильно и решить данную проблему. Ну и раскритиковал код earlyoom :)

Может ты до сих пор не понял что текущее, предложенное решение может создать больше проблем чем решить. Давай ты почитаешь сначала хотя бы что Леня пишет, а потом послушаем уже мнение других экспертов Hmm, are we sure this is something we want to have in the default install? Is the code really good enough for that? Looking at the sources very superficially I see a couple of problems: 1. Waking up all the time in 100ms intervals? We generally try to avoid waking the CPU up all the time if nothing happens. Saving power and things. 2. New code using system() in the year 2020? Really? 3. Fixed size buffers and implicit, undetected, truncation of strings at various places (for example, when formatting the shell string to pass to system()). But more importantly: are we sure this actually operates the way we should? i.e. PSI is really what should be watched. It is not interesting who uses how much memory and triggering kills on that. What matters is to detect when the system becomes slow due to that, i.e. *latencies* introduced due to memory pressure and that's what PSI is about, and hence what should be used. But even if we'd ignore that in order fight latencies one should watch latencies: OOM killing per process is just not appropriate on a systemd system: all our system services (and a good chunk of our user services too) are sorted neatly into cgroups, and we really should kill them as a whole and not just individual processes inside them. systemd manages that today, and makes exceptions configurable via OOMPolicy=, and with your earlyoom stuff you break that. This looks like second guessing the kernel memory management folks at a place where one can only lose, and at the time breaking correct OOM reporting by the kernel via cgroups and stuff. Also: what precisely is this even supposed to do? Replace the algorithm for detecting *when* to go on a kill rampage? Or actually replace the algorithm selecting *what* to kill during a kill rampage? If it's the former (which the name of the project suggests, _early_oom)), then at the most basic the tool should let the kernel do the killing, i.e. "echo f > /proc/sysrq-trigger". That way the reporting via cgroups isn't fucked, and systemd can still do its thing, and the kernel can kill per cgroup rather than per process... Anyway, this all sounds very very fishy to me. Not thought to the end, and I am pretty sure this is something the kernel memory management folks should give a blessing to. Second guessing the kernel like that is just a bad idea if you ask me. I mean, yes, the OOM killer might not be that great currently, but this sounds like something to fix in kernel land, and if that doesn't work out for some reason because kernel devs can't agree, then do it as fallback in userspace, but with sound input from the kernel folks, and the blessing of at least some of the kernel folks. Lennart

В 5.4.10 починили тачпад на моем ноуте (он подключен через i2c и после пробуждения не работал пока модул ядра i2c_hid не перезапустишь) теперь после пробуждения работает все кроме прокрутки двумя пальцами, опять же если перезапустить i2c_hid прокрутка работает

DELL Inspiron 5391

DELL Inspiron 5391

Привет! Кто-то знает какая команда запуска у vim?

Очень толсто

Что?

Очень толсто

Троллинг толстый очень.

Я задам наитупейший вопрос: А в настройках в разделе "Устройства" смотрели настройки?