По второй ссылке можно прочитать, что в основную ветку от них уже принято 606 патчей (отсортированы по алфавиту, тык наугад показывает, что среди них есть и патчи 2025 года). Насчёт ярдов из бюджета не в курсе, оно под эгидой ИСП РАН, собственно, это непосредственная деятельность этого самого ИСП.
Про финна в гараже, это, простите, даже не смешно. На том уровне, на котором линукс делался в гараже, свои ОС сейчас можно выпекать непосредственно по инструкциям с osdev.org, только толку-то. Сейчас нужна безопасность, нужны оптимизации, нужны драйвера.
Свой API - это не так плохо, на неё можно портировать GTK или основные модули Qt, так появится и софт.
А вот то, что она гвоздями прибита к x86 - это вызывает уныние. Сейчас не 1999 год, Intel уже не царь горы, хотя ещё силён. Haiku, например, тоже хоббийная система, но её даже на RISC-V портировали, не говоря уж про ARM.
Всю жизнь пользуюсь стрелками на нумпаде, считаю их гораздо удобнее нижних-мелких (да, особенно на ноутбуках. В линуксах пришлось озадачиться, там по умолчанию сочетания Shift+стрелки вели себя не так, как ожидалось, потом открыл для себя параметр numpad:microsoft в XkbOptions (название опции, конечно, крайне неудачное, к MS оно никакого отношения не имеет, кроме того, что в MS просто всё сразу сделали по логике), и мои волосы вновь гладкие и шелковистые).
Но я программист, я букв ввожу гораздо больше чем цифр, и цифры как-то привык вводить в верхнем ряду.
Ну я, например, узнал, но у меня самого KDE+Manjaro. :))) И да, для интересующихся со стороны это можно было бы написать в самом начале, это очевидно не для всех. Так-то статья хорошая.
Поскольку значительная часть поста посвящена колдовству с файлами и файловыми системами, рискну порекомендовать полезную на мой взгляд утилитку QDirStat. Она графически отображает, какие файлы и каталоги съедают место на диске, с глубоким уровнем вложенности.
Да, вы всё правильно поняли:
1) это очередная графическая реализация старого доброго du -h.
2) таких графических диско-рисовалок довольно много, одни баобабы рисуют, другие концентрические круги...
...но на мой взгляд, именно вложенные прямоугольники, как в QDirStat, отображают эту информацию наиболее наглядно. Похожая концепция была в своё время в плагине визуализации для konqueror, но для этого плагина нужен целый konqueror, а тут отдельная утилитка.
Поискал - да, действительно, в других книгах есть, например, "Алиса и чудовище". Но впервые появился таки в сериале.
Спасибо за уточнение. Я просто будучи подростком в своё время, сериал не принял именно потому, что незадолго до этого прочитал книгу, и книга мне понравилась. А сериал всё-таки от книги в ряде мест сильно отошёл. Мой юношеский максимализм такого принять не мог. :)
А в какой именно книге было уточнение про слово Wärter?
Не, ну то, что автор первым делом начинает сравнивать сабж с SQLite, которая вообще не столько СУБД, сколько библиотека доступа к данным с SQL-синтаксисом - для многих читателей это будет сигналом закрыть статью и не открывать её больше. Да, ниже уже упоминаются Oracle и MS SQL Server, но до этого места надо ещё дойти. Понятно, что автор хотел упростить себе задачу (преимущества PostgreSQL перед SQLite, разумеется, показать, куда легче), но эффект, боюсь, для читателей, которые что-то знают про базы данных, получился прямо противоположным. Если бы сразу начать сравнение Postgre vs Oracle - статья бы выглядела более серьёзной. :)
Упоминание NoSQL-решений... Вообще, это крайне холиварная тема, но правильнее всего было бы упомянуть, что реляционные и нереляционные СУБД можно не противопоставлять, а сочетать. И в некоторых крупных проектах так и делают (если не ошибаюсь, про авито был такой доклад, и кажется, там PostgreSQL и упоминался, но это неточно). А так да, если человек не собирается делать миллионы транзакций в минуту и сразу тащит в рот NoSQL исключительно из соображений того, что он сэкономит время на проектировании структуры данных - он делает неправильно, тут соглашусь с автором.
Наконец, если кто-то затевает долгоиграющий проект с сильно более чем одним внедрением - ему стоит подумать над тем, чтобы сделать СУБД "сменной". У меня, например, есть опыт разработки проекта, где хранилище могло быть либо клиент-серверным (PostgreSQL), либо локальным (внутренняя СУБД - SQLite плюс выгрузка-загрузка в XML либо JSON, для пользователя локального варианта это выглядит просто как работа с XML-файлами), при этом по необходимости можно было легко перейти от одного варианта к другому, просто загрузив XML в PostgreSQL утилитой импорта. При этом порядка 90% SQL-запросов работали одинаково на обеих СУБД (кое-где таки пришлось сделать СУБД-специфичные ветки и то, главным образом, для оптимизации).
"Кормить надо лучше, они и не улетят" (из старой рекламы).
Автору статьи спасибо за хороший термин, наверное, можно использовать его в резюме. Я как раз тот самый старый программист, который упорото хочет заниматься разработкой и которого в тимлиды калачом не заманишь.
Журналисты пишут, что руководители больших компаний не должны решать, кто достоин работы в эпоху нейросетей, и не могут открыто рассказывать, что некоторым профессиям не стоило существовать.
А под названием Lemon есть ещё вполне живой проект генерации парсеров на замену YACC/Bison. Я даже удивился, думал, это про него, при чём, думаю, тут дичь.
А тут, оказывается, кто-то название для фреймворка неосмотрительно выбрал.
Есть репозиторий от российского консорциума исследования безопасности Linux.
Репозиторий: https://git.linuxtesting.ru/
Портал: https://portal.linuxtesting.ru/
По второй ссылке можно прочитать, что в основную ветку от них уже принято 606 патчей (отсортированы по алфавиту, тык наугад показывает, что среди них есть и патчи 2025 года). Насчёт ярдов из бюджета не в курсе, оно под эгидой ИСП РАН, собственно, это непосредственная деятельность этого самого ИСП.
Про финна в гараже, это, простите, даже не смешно. На том уровне, на котором линукс делался в гараже, свои ОС сейчас можно выпекать непосредственно по инструкциям с osdev.org, только толку-то. Сейчас нужна безопасность, нужны оптимизации, нужны драйвера.
Вот только автор статьи за нашу страну переживает, а вы почему-то за Запад.
Да, интересная система.
Свой API - это не так плохо, на неё можно портировать GTK или основные модули Qt, так появится и софт.
А вот то, что она гвоздями прибита к x86 - это вызывает уныние. Сейчас не 1999 год, Intel уже не царь горы, хотя ещё силён. Haiku, например, тоже хоббийная система, но её даже на RISC-V портировали, не говоря уж про ARM.
Ну добро пожаловать в клуб.
Всю жизнь пользуюсь стрелками на нумпаде, считаю их гораздо удобнее нижних-мелких (да, особенно на ноутбуках. В линуксах пришлось озадачиться, там по умолчанию сочетания Shift+стрелки вели себя не так, как ожидалось, потом открыл для себя параметр numpad:microsoft в XkbOptions (название опции, конечно, крайне неудачное, к MS оно никакого отношения не имеет, кроме того, что в MS просто всё сразу сделали по логике), и мои волосы вновь гладкие и шелковистые).
Но я программист, я букв ввожу гораздо больше чем цифр, и цифры как-то привык вводить в верхнем ряду.
Ну я, например, узнал, но у меня самого KDE+Manjaro. :))) И да, для интересующихся со стороны это можно было бы написать в самом начале, это очевидно не для всех. Так-то статья хорошая.
Поскольку значительная часть поста посвящена колдовству с файлами и файловыми системами, рискну порекомендовать полезную на мой взгляд утилитку QDirStat. Она графически отображает, какие файлы и каталоги съедают место на диске, с глубоким уровнем вложенности.
Да, вы всё правильно поняли:
1) это очередная графическая реализация старого доброго du -h.
2) таких графических диско-рисовалок довольно много, одни баобабы рисуют, другие концентрические круги...
...но на мой взгляд, именно вложенные прямоугольники, как в QDirStat, отображают эту информацию наиболее наглядно. Похожая концепция была в своё время в плагине визуализации для konqueror, но для этого плагина нужен целый konqueror, а тут отдельная утилитка.
Странно, что с таким опытом Вы прошли мимо MyTetra.
Я в 2020 попробовал на новом компе (с KDE), да так и остался.
А в более новых есть?
Поискал - да, действительно, в других книгах есть, например, "Алиса и чудовище". Но впервые появился таки в сериале.
Спасибо за уточнение. Я просто будучи подростком в своё время, сериал не принял именно потому, что незадолго до этого прочитал книгу, и книга мне понравилась. А сериал всё-таки от книги в ряде мест сильно отошёл. Мой юношеский максимализм такого принять не мог. :)
А в какой именно книге было уточнение про слово Wärter?
У Булычёва (если мы конкретно про "Сто лет тому вперёд") никакого Вертера не было, этот образ экранизаторы придумали.
Полтора года спустя запрос про человека на берегу моря выдаёт вот такое:
http://zvyozdochkin.ru/img-host/habr.com/neuro-kand/beachbook.jpg
Человек, конечно, непонятно куда пропал, вместе с головой, ногами и коленями (может, в песок зарылся), зато ноутбук получился супер-инновационный :)
Не, ну то, что автор первым делом начинает сравнивать сабж с SQLite, которая вообще не столько СУБД, сколько библиотека доступа к данным с SQL-синтаксисом - для многих читателей это будет сигналом закрыть статью и не открывать её больше. Да, ниже уже упоминаются Oracle и MS SQL Server, но до этого места надо ещё дойти. Понятно, что автор хотел упростить себе задачу (преимущества PostgreSQL перед SQLite, разумеется, показать, куда легче), но эффект, боюсь, для читателей, которые что-то знают про базы данных, получился прямо противоположным. Если бы сразу начать сравнение Postgre vs Oracle - статья бы выглядела более серьёзной. :)
Упоминание NoSQL-решений... Вообще, это крайне холиварная тема, но правильнее всего было бы упомянуть, что реляционные и нереляционные СУБД можно не противопоставлять, а сочетать. И в некоторых крупных проектах так и делают (если не ошибаюсь, про авито был такой доклад, и кажется, там PostgreSQL и упоминался, но это неточно). А так да, если человек не собирается делать миллионы транзакций в минуту и сразу тащит в рот NoSQL исключительно из соображений того, что он сэкономит время на проектировании структуры данных - он делает неправильно, тут соглашусь с автором.
Наконец, если кто-то затевает долгоиграющий проект с сильно более чем одним внедрением - ему стоит подумать над тем, чтобы сделать СУБД "сменной". У меня, например, есть опыт разработки проекта, где хранилище могло быть либо клиент-серверным (PostgreSQL), либо локальным (внутренняя СУБД - SQLite плюс выгрузка-загрузка в XML либо JSON, для пользователя локального варианта это выглядит просто как работа с XML-файлами), при этом по необходимости можно было легко перейти от одного варианта к другому, просто загрузив XML в PostgreSQL утилитой импорта. При этом порядка 90% SQL-запросов работали одинаково на обеих СУБД (кое-где таки пришлось сделать СУБД-специфичные ветки и то, главным образом, для оптимизации).
"Кормить надо лучше, они и не улетят" (из старой рекламы).
Автору статьи спасибо за хороший термин, наверное, можно использовать его в резюме. Я как раз тот самый старый программист, который упорото хочет заниматься разработкой и которого в тимлиды калачом не заманишь.
Не нашёл в статье информации о лицензии самой SerenityOS. Восполняю пробел - там двухпунктная BSD.
Одобряю этих журналистов.
А под названием Lemon есть ещё вполне живой проект генерации парсеров на замену YACC/Bison. Я даже удивился, думал, это про него, при чём, думаю, тут дичь.
А тут, оказывается, кто-то название для фреймворка неосмотрительно выбрал.
Мне показалось, что первые два проекта, особенно второй - отсылка не столько к HTML, сколько к XML.
P.S. А вот, выше уже про SGML подметили :)
"Выложат" и "утекали" это понятия совсем из разных реальностей, вообще-то.
Исходники под GPL плохо перевариваются Микрософтом, вот был бы MIT какой-нибудь - другое дело.
И это хорошо, пусть проект сохраняет самобыность!