Они оба "скомпилированное и протестированое", а rhck и есть kernel default, не надо путать с kernel vanila. Не придумывайте проблему там где её нет. Uek ядро нужно только в специфических кейсах и только для тех кто знает его особенности и ограничения, при установке oracle linux вам следовало выбрать шаблон с классическим ядром, а не ставить uek и потом жаловаться что на урезанном ядре у вас не получается сделать что-то.
1) справка по одному флагу одной утилиты не тянет на статью 2) эта тема в целом не заслуживает отдельной статьи так как каждая утилита для скачивания имеет свой man 3) если уж так хочется написать статью на эту тему то можно было бы добавить информации про другие утилиты (хотя бы wget и aria2 как самые известные) и описать чем принципиально отличается ограничения скорости скачивания в этих утилитах
На чем написан Хром, на qt, Gtk, XM? Вам это интересно? Скорее всего нет, вы просто запускаете Хром.
мне вот интересно, несколько лет назад я открыл для себя что моя рабочая производительность немного выше когда весь софт на экране выглядит в одном стиле, чего к сожалению не возможно добиться в винде и макоси впринципе, но можно к этому хотя бы немного приблизиться на линуксе. и раньше хром мог отрисовывать хотя бы бордеры родные от qt, а сейчас с переходом на gtk не может. не то чтобы это было важно, но всё же печально.
Виндовс: когда все окошки в одном стиле
ах если бы это было так. к сожалению большинство разработчиков под винду (включая тех что работает в майкрософте) не в состоянии следовать какому либо общему стилю, в самой винде порядка 12 разных оформлений сосуществуют в ужасном симбиозе, а сторонние разработчики только добавляют в эту вакханалью ещё пару десятков. в линуксе к слову есть такие же наркоманы, они даже пытаются продвигать эту идею как хорошую (я конечно же про переход гнома на CSD и про это в том числе) забывая про потребности пользователей для которых они собственно и пишут свой софт.
Что Oracle database , что Postgres работают на Oracle linux примерно также как и на Windows (если железо одинаковое) .
не знаю как сейчас, но лет так 5 назад гонял тесты для одного проекта, и на одной и той же железки под нагрузкой постгря показывала производительность под linux (насколько я помню это была centos, хотя возможно и opensuse, но точно что-то rpm based) немного выше (точных цифр не помню, но в среднем по палате немногим выше 10% при большом кол-ве соединений и множественных запросов), хотел бы я поделиться самими тестами и их результатами, но увы они остались у клиента как и вся прочая оверсекретная (по его мнению) документация по так и не случившемуся проекту.
и к слову для 1с тесты тоже гонялись мной, правда ещё раньше и для другого клиента, тогда производительность распределилась так (от худшей к лучшей): 1) 1с на винде и пг на винде 2) 1с на винде, пг на линуксе 3) 1с на линуксе и пг на линуксе все тесты в режиме тонкого клиента, все тесты когда сервер 1с и база пг на разных железках, все тесты одни и те же две железки, все тесты без тонкого тюнинга ос под задачу, хотя можно было поигравшись sysctl выиграть ещё немного производительности, но задача была не в этом.
в данном контексте нет никакой разницы. но с "не успел сбросить на диск" это тоже работает, и вы можете это лично проверить создайте VM, сделайте сервис который будет срать в лог чем угодно, хоть временем хоть рандомом, но чем длиннее строка тем лучше, запустите journalctl -f после чего искуственно снижайте скорость записи на виртуальный диски наблюдайте. в какой-то момент лог перестанет успевать писаться на диск, но при этом продолжит выводиться без проблем и задержек.
я к сожалению не достаточно хорош чтобы найти в коде systemd как это работает и засчёт чего получается, но я наблюдал это вживую и поэтому так уверенно говорю.
В качестве эксперимента я делал на основе этого гейтвея схему в которой f2b живёт на одном хосте, а сервис который он защищает на другом. С этим http интерфейсом можно работать почти так же как с journalctl получая постоянный поток или определённое кол-во строк по желанию, можно так же фидьтровать и всё такое.
Но вообще в данном контексте под запросом можно понимать даже пинание journalctl
являясь посредником между "читателем" и "писателем" получив свежую запись от процесса он конечно же содержит её в памяти, и вне зависимости от того успел он сохранить данные на диск или нет он может эту запись уже отдать по запросу если такой есть. это не магия, это нормальная работа journald. это же не субд чтобы не считать запись валидной до тех пор пока не убедится что она надёжно сохранена на диске.
В вашем случае скорее всего да, но дело не в линуксе, не в дистрибутиве и не в ядре, просто вам так хочется. Ибо самый простой путь вам уже писали: https://habr.com/ru/articles/969664/comments/#comment_29161674
Простите, не уловил связи
Они оба "скомпилированное и протестированое", а rhck и есть kernel default, не надо путать с kernel vanila. Не придумывайте проблему там где её нет. Uek ядро нужно только в специфических кейсах и только для тех кто знает его особенности и ограничения, при установке oracle linux вам следовало выбрать шаблон с классическим ядром, а не ставить uek и потом жаловаться что на урезанном ядре у вас не получается сделать что-то.
ну это уже даже не смешно..
1) справка по одному флагу одной утилиты не тянет на статью
2) эта тема в целом не заслуживает отдельной статьи так как каждая утилита для скачивания имеет свой man
3) если уж так хочется написать статью на эту тему то можно было бы добавить информации про другие утилиты (хотя бы wget и aria2 как самые известные) и описать чем принципиально отличается ограничения скорости скачивания в этих утилитах
мне вот интересно, несколько лет назад я открыл для себя что моя рабочая производительность немного выше когда весь софт на экране выглядит в одном стиле, чего к сожалению не возможно добиться в винде и макоси впринципе, но можно к этому хотя бы немного приблизиться на линуксе. и раньше хром мог отрисовывать хотя бы бордеры родные от qt, а сейчас с переходом на gtk не может. не то чтобы это было важно, но всё же печально.
ах если бы это было так. к сожалению большинство разработчиков под винду (включая тех что работает в майкрософте) не в состоянии следовать какому либо общему стилю, в самой винде порядка 12 разных оформлений сосуществуют в ужасном симбиозе, а сторонние разработчики только добавляют в эту вакханалью ещё пару десятков. в линуксе к слову есть такие же наркоманы, они даже пытаются продвигать эту идею как хорошую (я конечно же про переход гнома на CSD и про это в том числе) забывая про потребности пользователей для которых они собственно и пишут свой софт.
не знаю как сейчас, но лет так 5 назад гонял тесты для одного проекта, и на одной и той же железки под нагрузкой постгря показывала производительность под linux (насколько я помню это была centos, хотя возможно и opensuse, но точно что-то rpm based) немного выше (точных цифр не помню, но в среднем по палате немногим выше 10% при большом кол-ве соединений и множественных запросов), хотел бы я поделиться самими тестами и их результатами, но увы они остались у клиента как и вся прочая оверсекретная (по его мнению) документация по так и не случившемуся проекту.
и к слову для 1с тесты тоже гонялись мной, правда ещё раньше и для другого клиента, тогда производительность распределилась так (от худшей к лучшей):
1) 1с на винде и пг на винде
2) 1с на винде, пг на линуксе
3) 1с на линуксе и пг на линуксе
все тесты в режиме тонкого клиента, все тесты когда сервер 1с и база пг на разных железках, все тесты одни и те же две железки, все тесты без тонкого тюнинга ос под задачу, хотя можно было поигравшись sysctl выиграть ещё немного производительности, но задача была не в этом.
не развалится, kernel default поддерживается ровно так же как и kernel uek.
вообще очень странный подход юзать нестандартное ядро с кучей особенностей и возмущаться на него при этом не знать в чём эти особенности заключаются.
какой жирный но совершенно безсмысленный наброс..
Поправьте меня если я ошибаюсь, но docker на windows не совсем на windows, используется прослойка навроде wsl.
Вероятность того что для нужного мне для работы софта понадобится wine ничтожно мала, в другом случае же мне бы постоянно пришлось сношаться с wsl.
кликхаус не пробовал, но постгря отлично работала, никаких проблем не испытывал. а у вас что именно мешает постгре работать?
в данном контексте нет никакой разницы.
но с "не успел сбросить на диск" это тоже работает, и вы можете это лично проверить
создайте VM, сделайте сервис который будет срать в лог чем угодно, хоть временем хоть рандомом, но чем длиннее строка тем лучше, запустите journalctl -f после чего искуственно снижайте скорость записи на виртуальный диски наблюдайте. в какой-то момент лог перестанет успевать писаться на диск, но при этом продолжит выводиться без проблем и задержек.
я к сожалению не достаточно хорош чтобы найти в коде systemd как это работает и засчёт чего получается, но я наблюдал это вживую и поэтому так уверенно говорю.
А, ну собсна да, результат тот же но подошди с другой стороны. Так да, так можно.
Ну тогда скрипт в студию
-f в скрипте для f2b? хмммм.......
который tmpfs тоесть в памяти. с чего я собственно и начал..
тогда как это работает когда локальный стораж journald вообще выключен в конфиге?
А вы попробуйте мне не преписывать не мои слова
Есть, просто выключен по дефолту:
В качестве эксперимента я делал на основе этого гейтвея схему в которой f2b живёт на одном хосте, а сервис который он защищает на другом. С этим http интерфейсом можно работать почти так же как с journalctl получая постоянный поток или определённое кол-во строк по желанию, можно так же фидьтровать и всё такое.
Но вообще в данном контексте под запросом можно понимать даже пинание journalctl
являясь посредником между "читателем" и "писателем" получив свежую запись от процесса он конечно же содержит её в памяти, и вне зависимости от того успел он сохранить данные на диск или нет он может эту запись уже отдать по запросу если такой есть. это не магия, это нормальная работа journald. это же не субд чтобы не считать запись валидной до тех пор пока не убедится что она надёжно сохранена на диске.
судя по тому как меня убеждают в том что я говорил то чего не говорил и в том что лучше знают где и как я живу мы уже не на хабре а на пикабу))