Не видел, чтобы Хабр был недоступен. Но пос е 22 часов при входе на него очень часто отображались ошибки 502 и 504. А это значит сам Хабр был доступен, но лежал бэкенд за nginx.
С лагом в одну секунду, что при реалтаймовой отладке чего-нибудь раздражает
Ради интереса открыл journalctl -f на своём компьютере и попробовал обратиться к веб-серверу nginx локальному. За одно туда много пишет отладочной информации php-fpm, всё-таки у меня сервер стоит для разработки. Время от нажатия кнопки обновить в браузере и вывод логов занимает доли секунды. Точнее, чтобы узнать сколько, нужно что-то аппаратное, потому что глазом видно, что это происходит почти мгновенно.
Вероятно на продакшене может быть задержка, Но она связана, скорее всего, с повышением эффективности логирования. Если нагрузка большая и логов много, логично накапливать их в оперативной памяти, а потом сбрасывать на диск всем куском, чем дёргать диск на каждый чих.
Вышеупомянутый перенос логов nginx из текстовых файлов в journald для меня выглядит самоубийством
Рекомендую всё-таки ознакомиться с возможностями journalctl. Там есть и свой grep, и фильтр по датам, и поиск по метаданным, и аналог tail -f.... Лично мне больше понравилось. Плюс не нужно быть root, чтобы логи смотреть. Достаточно дать пользователю необходимые права. А также вместо путей /var/log… можно пользоваться просто тегами или именами сервисов (опять таки, надо смотреть что удобнее в каждом конкретном случае). Мне тоже, по началу, казалось сложно, но сейчас наоборот - ведение логов в текстовых файлах кажется дичью.
Скорее всего где-то вы ошиблись. Внимательно посмотрите на то, что там пишется. Может быть какой-то сервис сильно много чего-то пишет. В любом случае, если у вас journald, то там есть ограничение на максимальный объём файлов журнала. В случае переполнения, старые логи просто начнут удаляться и дополнительного места на диске уже не потребуется. Я бы просто запустил journalctl -f и посмотрел чего у меня там летит такого, что постоянно забивает логи. Возможно у какого-то сервиса не выключена отладка или что-то сбоит.
Могу сказать только в защиту nginx. Он по умолчанию пишет сообщения самостоятельно. Но это легко меняется в настройках и он отлично пишет в journald. Особенно удобно, когда логи nginx можно просматривать совместно с логами php-fpm через journalctl. Сразу видно какой запрос пришёл, какую отладочную информацию выдал php-fpm и какие проблемы возникли при обработке запроса PHP. В java, наверно, тоже можно сделать что-то подобное.
Это не вредительство, это обычное поведение файловой системы linux. Оно в корне отличается от того, что происходит в Windows. Пока что-то держит файл, файл после rm физически не удаляется и продолжает работать. При этом для тех, кто файл не держал, файл фактически считается удалённым. В Windows же при попытке удалить файл, пока его кто-то держит, вываливается ошибка.
Всех этих мучений, что описаны в статье, можно было бы избежать, если бы сервис не писал файлы логов самостоятельно, а доверил это какому-либо сервису по ведению логов. Там все особенности файловой системы linux уже учтены.
А я как-то привык писать логи в journald. Он, и логи в сжатом виде хранит (с поиском по ним), и о ротации заботится, и чтобы диск не забивался логами (ограничение на максимальный размер). А ещё du себя очень странно ведёт на дисках с btrfs. У самой утилиты обслуживания btrfs есть свой btrfs filesystem du.
У нас на работе не были PDF, которые были удобнее для печати. Нам слали docx, что по сути тот же самый PDF, но его можно передалать для чтения. Но в документах не это важное. Всё было оформлено по стандратам. Введение, зачем документ, сам документ канцелярским языком, заключение, список кокращений и прочая хрень. Т.е. там документа на 1 страницу обычного печатного текста, а, по факту, там листов 20-30. Видимо какого-то родственника наняли, чтобы эти документы делать. И документы были вроде того, как инженер должен заходить в хату. Не в смысле тюремного. Как в дом зайти к абоненту. Куча текста, информации полезной никакой.
Тут мы сталкиваемся с проблемой. Мне через СБП пришли деньги, но у меня нет способа отозвать платёж. Да и отправитель не может отменить что-то ошибочное, даже если свяжется с получателем. Получатель вынужден будет отправлять платёж назад, как-будь-то он это сам делает. Это ещё один недостаток СБП, кроме того, что я озвучил. Это быстро, но это трындец как ненадёжно и небезопасно. Понятное дело, что Сбербанк, как один из крупных банков в РФ придумывает свои костыли, вместо того, чтобы наезжать на СБП и требовать пофиксить баги.
Ты перевёл за аренду, а тебе говорят, что ничего не пришло. Выселяйся. В таком случае суд - просто супер вариант. Через год докажешь, что ты прав, при этом заплатив юристам, пошлины и прочее. Отличный вариант, надёжный как...
Ну так банк говорит, у нас транзакция с СБП прошла, деньги ушли. Если обращаться в СБП, то они говорят - обращайтесь к получателю. Занавес. Я не против. Если у вас есть алгоритм действий в таком случае, опишите. У нас не получилось. За квартиру платили тем кто сдавал. 40 тысяч рублей ушло, но пропало.
С СБП так не работает. Они тупо закрывают транзакцию и полностью про неё забывают. Ты, как отправитель вообще ничего не можешь сделать. Ты даже не можешь подтвердить, что деньги пришли на счёт получателя. Грубо говоря, у тебя деньги ушли, а собеседник говорит, что никаких денег нет. И ты ничем не докажешь, что деньги ушли и вернуть не можешь, то, что ушло.
так там опять сборка и вот это все - вместо нормального html и js
Ну так сборка и позволяет избавиться от сложности. Я тоже могу делать просто HTML страницу и даже так делал. Но потом в этой каше сложно разобраться. Можно поделить на фрагменты, которые будут отвечать за каждый отдельный элемент интерфейса. Банально, разнести в разные файлы заголовок страницы с меню и футером. Просто потом возникает вопрос как потом собрать всё в кучу. Одним из первых моих решений было использовать PHP. Да. Банально инлудил файлы. Тогда естественно никакой сборки не было.
В любом случае, какую-то сборку сейчас приходится применять. Ну не руками же создавать CSS со всеми совместимостями под разные браузеры? Можно какой-нибудь тайлвинд влепить и обвешаться гигантскими наборами классов для каждого элемента, как будь-то мы попали в 90-е годы, где у многих тегов были вереницы атрибутов.
А я делал... делал свой микрофеймворк. А потом оказалось, что на Symfony оно гораздо быстрее работает. И не надо постоянно код переписывать. Просто обновляешь фреймворк и всё работает. Хотя тоже есть некоторые проблемы. И вот прямо бесит, что ORM без привязки к конкретной БД. Столько времени уходит, чтобы подружить базу с сущностями. Реально проще SQL писать.
Krusader в подмётки не годится Total Commander. Много раз пробовал, но вообще не заходит. Это при том, что я активно пользовался Total Commander на Windows. Ну а сейчас больше пользуюсь Double Commander. Но не так активно, как TC на Windows. Больше времени в MC провожу, даже с тем учётом, что Far никогда не пользовался.
В России вообще сложно прикинуть сколько было всего продано клонов ZX-Spectrum. Их клепали все, кто могли. А уж игр под эту платформу можно было найти сколько угодно. Ни для какой другой столько софта не было.
Я всё детство провёл за ZX-Spectrum. Даже с его схемой разбирался. Всегда думал, что у него очень плохая графика, хоть и красочная. Но, сейчас, когда посмотрел что было на других платформах, понял, что не такая же и плохая была графика. Просто свои особенности, например, структура видеопамяти такая, что позволяла делать графику очень быстрой. Это сейчас смотрится дико. В 90-е воспринималась нормально.
Это на Commodore 64 сочная? Там хоть и есть цвет, но такая дикая цветовая гамма, да ещё и бледная. Яркая графика была как раз на ZX-Spectrum. Недавно баловался эмулятором Commodore 64. Знакомые игры с ZX-Spectrum выглядят блекло. Пробовал и в Elite поиграть. На ZX-Spectrum тоже Elite была, вроде с 1985 года. Кстати, анимания Elite в статье как раз, похоже, с ZX-Spectrum, судя по цветовой гамме.
Если бизнес делает, то это кому-то нужно. В своё время Задорнов смеялся над тем, что на трамваях поставили устройства транслирующие их координаты GPS. Ему и залу смешно. Но по факту ведь реально полезная информация попадала в систему, которая помогала сразу выявить проблему и быстро решить.
Не видел, чтобы Хабр был недоступен. Но пос е 22 часов при входе на него очень часто отображались ошибки 502 и 504. А это значит сам Хабр был доступен, но лежал бэкенд за nginx.
Ради интереса открыл journalctl -f на своём компьютере и попробовал обратиться к веб-серверу nginx локальному. За одно туда много пишет отладочной информации php-fpm, всё-таки у меня сервер стоит для разработки. Время от нажатия кнопки обновить в браузере и вывод логов занимает доли секунды. Точнее, чтобы узнать сколько, нужно что-то аппаратное, потому что глазом видно, что это происходит почти мгновенно.
Вероятно на продакшене может быть задержка, Но она связана, скорее всего, с повышением эффективности логирования. Если нагрузка большая и логов много, логично накапливать их в оперативной памяти, а потом сбрасывать на диск всем куском, чем дёргать диск на каждый чих.
Рекомендую всё-таки ознакомиться с возможностями journalctl. Там есть и свой grep, и фильтр по датам, и поиск по метаданным, и аналог
tail -f.... Лично мне больше понравилось. Плюс не нужно быть root, чтобы логи смотреть. Достаточно дать пользователю необходимые права. А также вместо путей /var/log… можно пользоваться просто тегами или именами сервисов (опять таки, надо смотреть что удобнее в каждом конкретном случае). Мне тоже, по началу, казалось сложно, но сейчас наоборот - ведение логов в текстовых файлах кажется дичью.Скорее всего где-то вы ошиблись. Внимательно посмотрите на то, что там пишется. Может быть какой-то сервис сильно много чего-то пишет. В любом случае, если у вас journald, то там есть ограничение на максимальный объём файлов журнала. В случае переполнения, старые логи просто начнут удаляться и дополнительного места на диске уже не потребуется. Я бы просто запустил
journalctl -fи посмотрел чего у меня там летит такого, что постоянно забивает логи. Возможно у какого-то сервиса не выключена отладка или что-то сбоит.Могу сказать только в защиту nginx. Он по умолчанию пишет сообщения самостоятельно. Но это легко меняется в настройках и он отлично пишет в journald. Особенно удобно, когда логи nginx можно просматривать совместно с логами php-fpm через journalctl. Сразу видно какой запрос пришёл, какую отладочную информацию выдал php-fpm и какие проблемы возникли при обработке запроса PHP. В java, наверно, тоже можно сделать что-то подобное.
Это не вредительство, это обычное поведение файловой системы linux. Оно в корне отличается от того, что происходит в Windows. Пока что-то держит файл, файл после rm физически не удаляется и продолжает работать. При этом для тех, кто файл не держал, файл фактически считается удалённым. В Windows же при попытке удалить файл, пока его кто-то держит, вываливается ошибка.
Всех этих мучений, что описаны в статье, можно было бы избежать, если бы сервис не писал файлы логов самостоятельно, а доверил это какому-либо сервису по ведению логов. Там все особенности файловой системы linux уже учтены.
А я как-то привык писать логи в journald. Он, и логи в сжатом виде хранит (с поиском по ним), и о ротации заботится, и чтобы диск не забивался логами (ограничение на максимальный размер). А ещё du себя очень странно ведёт на дисках с btrfs. У самой утилиты обслуживания btrfs есть свой
btrfs filesystem du.У нас на работе не были PDF, которые были удобнее для печати. Нам слали docx, что по сути тот же самый PDF, но его можно передалать для чтения. Но в документах не это важное. Всё было оформлено по стандратам. Введение, зачем документ, сам документ канцелярским языком, заключение, список кокращений и прочая хрень. Т.е. там документа на 1 страницу обычного печатного текста, а, по факту, там листов 20-30. Видимо какого-то родственника наняли, чтобы эти документы делать. И документы были вроде того, как инженер должен заходить в хату. Не в смысле тюремного. Как в дом зайти к абоненту. Куча текста, информации полезной никакой.
Тут мы сталкиваемся с проблемой. Мне через СБП пришли деньги, но у меня нет способа отозвать платёж. Да и отправитель не может отменить что-то ошибочное, даже если свяжется с получателем. Получатель вынужден будет отправлять платёж назад, как-будь-то он это сам делает. Это ещё один недостаток СБП, кроме того, что я озвучил. Это быстро, но это трындец как ненадёжно и небезопасно. Понятное дело, что Сбербанк, как один из крупных банков в РФ придумывает свои костыли, вместо того, чтобы наезжать на СБП и требовать пофиксить баги.
Ты перевёл за аренду, а тебе говорят, что ничего не пришло. Выселяйся. В таком случае суд - просто супер вариант. Через год докажешь, что ты прав, при этом заплатив юристам, пошлины и прочее. Отличный вариант, надёжный как...
Ну так банк говорит, у нас транзакция с СБП прошла, деньги ушли. Если обращаться в СБП, то они говорят - обращайтесь к получателю. Занавес. Я не против. Если у вас есть алгоритм действий в таком случае, опишите. У нас не получилось. За квартиру платили тем кто сдавал. 40 тысяч рублей ушло, но пропало.
С СБП так не работает. Они тупо закрывают транзакцию и полностью про неё забывают. Ты, как отправитель вообще ничего не можешь сделать. Ты даже не можешь подтвердить, что деньги пришли на счёт получателя. Грубо говоря, у тебя деньги ушли, а собеседник говорит, что никаких денег нет. И ты ничем не докажешь, что деньги ушли и вернуть не можешь, то, что ушло.
Ну так сборка и позволяет избавиться от сложности. Я тоже могу делать просто HTML страницу и даже так делал. Но потом в этой каше сложно разобраться. Можно поделить на фрагменты, которые будут отвечать за каждый отдельный элемент интерфейса. Банально, разнести в разные файлы заголовок страницы с меню и футером. Просто потом возникает вопрос как потом собрать всё в кучу. Одним из первых моих решений было использовать PHP. Да. Банально инлудил файлы. Тогда естественно никакой сборки не было.
В любом случае, какую-то сборку сейчас приходится применять. Ну не руками же создавать CSS со всеми совместимостями под разные браузеры? Можно какой-нибудь тайлвинд влепить и обвешаться гигантскими наборами классов для каждого элемента, как будь-то мы попали в 90-е годы, где у многих тегов были вереницы атрибутов.
Astro?
А я делал... делал свой микрофеймворк. А потом оказалось, что на Symfony оно гораздо быстрее работает. И не надо постоянно код переписывать. Просто обновляешь фреймворк и всё работает. Хотя тоже есть некоторые проблемы. И вот прямо бесит, что ORM без привязки к конкретной БД. Столько времени уходит, чтобы подружить базу с сущностями. Реально проще SQL писать.
Krusader в подмётки не годится Total Commander. Много раз пробовал, но вообще не заходит. Это при том, что я активно пользовался Total Commander на Windows. Ну а сейчас больше пользуюсь Double Commander. Но не так активно, как TC на Windows. Больше времени в MC провожу, даже с тем учётом, что Far никогда не пользовался.
В России вообще сложно прикинуть сколько было всего продано клонов ZX-Spectrum. Их клепали все, кто могли. А уж игр под эту платформу можно было найти сколько угодно. Ни для какой другой столько софта не было.
Я всё детство провёл за ZX-Spectrum. Даже с его схемой разбирался. Всегда думал, что у него очень плохая графика, хоть и красочная. Но, сейчас, когда посмотрел что было на других платформах, понял, что не такая же и плохая была графика. Просто свои особенности, например, структура видеопамяти такая, что позволяла делать графику очень быстрой. Это сейчас смотрится дико. В 90-е воспринималась нормально.
Это на Commodore 64 сочная? Там хоть и есть цвет, но такая дикая цветовая гамма, да ещё и бледная. Яркая графика была как раз на ZX-Spectrum. Недавно баловался эмулятором Commodore 64. Знакомые игры с ZX-Spectrum выглядят блекло. Пробовал и в Elite поиграть. На ZX-Spectrum тоже Elite была, вроде с 1985 года. Кстати, анимания Elite в статье как раз, похоже, с ZX-Spectrum, судя по цветовой гамме.
Если бизнес делает, то это кому-то нужно. В своё время Задорнов смеялся над тем, что на трамваях поставили устройства транслирующие их координаты GPS. Ему и залу смешно. Но по факту ведь реально полезная информация попадала в систему, которая помогала сразу выявить проблему и быстро решить.