А поясните, почему нельзя? Имеется ввиду разделение сущностей и создание реляций? Потому что если тикет представлять глазами как раз бухгалтера, то никаких реляций там нет и быть не может.
История разработки — это набор ключевых моментов, когда кто-то что-то затронул, в том числе во время работы над фичой.
Для истории выполненных задач у нас есть таск-трекеры, а в гите, будьте добры, подробности — дабы в случае необходимости вычленить конкретный небольшой коммит, затрагивающий только одну подсистему в рамках одной фичи (или нескольких — вот тут как раз не принципиально, что само является плюсом).
Хорошо это устроено в Linux (LKML), где целостные патчи, охватывающие разные подсистемы, попросту не принимают.
Программист без хорошо развитого абстрактного мышления — не программист. Считаю, что «человеческие» интерфейсы только вредят там, где не разобравшись в подноготной лучше мышкой не тыкать.
своп может и не используется на сервере на какой-то узкоспециализированной задаче
Например, на домашнем сервере
Домашний сервер — это куча хлама начиная от почтовика, матрикса, приложений типа Home Assistant, Frigate и подобных в докере и заканчивая игровыми серверами и веб-приложениями. Там явно больше всего происходит, чем на «ноутбуке разработчика» — и с кратно большим аптаймом.
недостаточно просто того, чтобы в свопе было достаточно места для гибернации. нужен непрерывный участок.
Нет. Вы заблуждаетесь. Нужен непрерывный своп (т.е. один файл/раздел достаточного размера, а не сумма нескольких). За фрагментацией следит само ядро, и фрагментация свопа не помешает процессу гибернации.
Я заканчиваю работу с лаптопом, просто закрывая крышку
Я тоже. Но если я знаю, что для меня критически важно что-либо в RAM, я перед этим лишний раз кину взгляд на индикатор в панели, чтобы убедиться, что памяти занято меньше 80% — обычно этого хватает с учётом сжатия при свопе в полтора объёма RAM. Это происходит машинально.
А ещё ровно поэтому существуют режимы гибридного сна и suspend-then-hibernate, которые в любом случае не позволят вам потерять состояние, если батарея доживёт до включения (а в современных ультрабуках с S0iX это десятки часов).
как в 2025-ом году вы объясняете это пользователю WIndows или Mac, что перед тем как закрыть крышку ноутбука, им нужно проверить место в свопе
Во-первых, зачем мне им это объяснять? Ради холивара? Во-вторых, на Windows файл hiberfil.sysвсегда занимает место на диске (не неся пользы помимо гибернации) и постоянно растёт (небыстро; читай: не уменьшается сам), я же не готов отдавать объём больше строго фиксированного, предопределённого мной.
Повторю свои же слова, правильно сконфигурированный линукс умеет производить гибернацию в частично занятый своп (этот факт очевиден), а следить за общим (RAM+swap) объёмом занимаемой оперативной памяти — ответственность юзера. Мы есть админы своих систем, без элементарного уровня понимания устройства системы пользоваться линуксом не стоит — это как раз удел винды и мака.
и, кстати говоря, [мой скрипт] срабатывает не всегда с первого раза.
Дело в вашем скрипте и/или конфигурации, а не в линуксе. Никогда не следует вкостыливать кастомные наколеночные скрипты туда, где ответственен функционал системного демона. Линукс на то и опенсорсен, что вы вольны править в вашей системе то, что вам заблагорассудится. Напишите патч для того же systemd — может быть, сообщество оценит и примет. А подобным скриптам место на винде. Я лично для многих вещей модули ядра не ленюсь писать, хотя, наверное, можно было бы обойтись скриптом на питоне (но не нужно).
приоритеты можно покрутить, но это тоже не гарант
Конечно. Если у вас настолько неконтролируемо забита память, что вам не хватает объёма её и собственноручно настроенного свопа — увеличивайте своп, не пишите скрипты!
А всякие
TCP_NODELAY, «квик-квак» и пр. разве не спасают?Даёшь
NFQUEUE!А поясните, почему нельзя? Имеется ввиду разделение сущностей и создание реляций? Потому что если тикет представлять глазами как раз бухгалтера, то никаких реляций там нет и быть не может.
Как раз статья и говорит о том, что надо перестать так делать и начать д у м а т ь.
Ну, написано:
Так что всё-таки, получается, не обёртка.
Согласно документации, это прямой аналог
git stash.Будут удалены при чистке без учёта MRов, а вот в гитлабе это настраивается глобально или в параметрах репы, мол, MRы считать рефами и не трогать.
Сказать-то можно, а вот услышать вначале рассуждения или не услышать — это критерий.
Всё равно же, одна ветка — одна задача.
История разработки — это набор ключевых моментов, когда кто-то что-то затронул, в том числе во время работы над фичой.
Для истории выполненных задач у нас есть таск-трекеры, а в гите, будьте добры, подробности — дабы в случае необходимости вычленить конкретный небольшой коммит, затрагивающий только одну подсистему в рамках одной фичи (или нескольких — вот тут как раз не принципиально, что само является плюсом).
Хорошо это устроено в Linux (LKML), где целостные патчи, охватывающие разные подсистемы, попросту не принимают.
«delete» ведь не полностью её удалит, а только реф снимет. Всё равно через MR к нужной ветке доступ получить можно будет.
Программист без хорошо развитого абстрактного мышления — не программист. Считаю, что «человеческие» интерфейсы только вредят там, где не разобравшись в подноготной лучше мышкой не тыкать.
А поделитесь ссылкой? Звучит интересно.
GitHub + Obtainium.
А кто-то спорит?
Не надо нам такого «общественно полезного» труда!
FUTO. Полностью локальная и опенсорсная, от небезызвестного Louis Rossmann.
Домашний сервер — это куча хлама начиная от почтовика, матрикса, приложений типа Home Assistant, Frigate и подобных в докере и заканчивая игровыми серверами и веб-приложениями. Там явно больше всего происходит, чем на «ноутбуке разработчика» — и с кратно большим аптаймом.
Нет. Вы заблуждаетесь. Нужен непрерывный своп (т.е. один файл/раздел достаточного размера, а не сумма нескольких). За фрагментацией следит само ядро, и фрагментация свопа не помешает процессу гибернации.
Я тоже. Но если я знаю, что для меня критически важно что-либо в RAM, я перед этим лишний раз кину взгляд на индикатор в панели, чтобы убедиться, что памяти занято меньше 80% — обычно этого хватает с учётом сжатия при свопе в полтора объёма RAM. Это происходит машинально.
А ещё ровно поэтому существуют режимы гибридного сна и
suspend-then-hibernate, которые в любом случае не позволят вам потерять состояние, если батарея доживёт до включения (а в современных ультрабуках с S0iX это десятки часов).Во-первых, зачем мне им это объяснять? Ради холивара? Во-вторых, на Windows файл
hiberfil.sysвсегда занимает место на диске (не неся пользы помимо гибернации) и постоянно растёт (небыстро; читай: не уменьшается сам), я же не готов отдавать объём больше строго фиксированного, предопределённого мной.Повторю свои же слова, правильно сконфигурированный линукс умеет производить гибернацию в частично занятый своп (этот факт очевиден), а следить за общим (RAM+swap) объёмом занимаемой оперативной памяти — ответственность юзера. Мы есть админы своих систем, без элементарного уровня понимания устройства системы пользоваться линуксом не стоит — это как раз удел винды и мака.
Дело в вашем скрипте и/или конфигурации, а не в линуксе. Никогда не следует вкостыливать кастомные наколеночные скрипты туда, где ответственен функционал системного демона. Линукс на то и опенсорсен, что вы вольны править в вашей системе то, что вам заблагорассудится. Напишите патч для того же
systemd— может быть, сообщество оценит и примет. А подобным скриптам место на винде. Я лично для многих вещей модули ядра не ленюсь писать, хотя, наверное, можно было бы обойтись скриптом на питоне (но не нужно).Конечно. Если у вас настолько неконтролируемо забита память, что вам не хватает объёма её и собственноручно настроенного свопа — увеличивайте своп, не пишите скрипты!
Сомнительное условие. Но так можно и холивар устроить.