эмм… я всё правильно понял, что Gnome Terminal обвиняется в монструозности и жоре памяти (20 мегабайт), а альтернативой ему предлагается Hyper на базе Electron?
чем скорость мерили, time с format?
Аргументация подкачала конечно…
Даже на ноуте <2 секунд vscode стартует. Тестировал с 9 плагинами и 4 вкладками. На десктопе ещё быстрее.
Как и другие ждал аргументы в пользу того почему neovim > vim (пользуюсь последним для Си и конфигов)
Автор — клоун, я даже дочитать этот опус не смог. Коллеги выше уже отметили нулевые знания в области (непонимание concurrency, parallelism, CSP), так ещё и полное профанство в языке Go (15-минутный go tour очевидно не пройден).
Даже лень комментировать этот бред: «go похож на goto (нет), поэтому они одинаковые (нет)», "'go' ломает исключения, а без них ошибки не обработать" (исключений в Go нет), «каналы ещё не придуманы и не существуют», «мифические абстракции ломаются (автор не знает какие абстракции есть в Go, но уверен что они ломаются)», «go ломает автоотчистку ресурсов» (её в Go тоже нет, но автор и этого не знает).
Немного питонирую и могу понять, какую проблему автор «героически» решает. Но это проблема именно языка Python (и многих других к сожалению), а Go с его «go» спроектирован на базе решения этой проблемы и просто иммунен к ней (но не ко многим другим к сожалению).
А Ansible и не требует 10+ хостов. Зато иногда надо рабочую машину переустановить (новое железо например).
Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
Спасибо за статью. По-моему одного маленького шажка не хватило — Ansible. Скрипты делают своё дело, но это инструмент прошлого тысячелетия (тогда софт был заметно проще, его было меньше, open source и коллаборация были на совершенно ином уровне), поддерживать чужой плейбук проще простого, а вот скрипт уже кому как.
Ну если вчитаться в доки этого F-Stack, то оно базируется на DPDK. Так что оно не в userspace работает, а прямо на железе (и только на поддерживаемом). В userspace только управление этим делом. Видимо нужно отдать специально обученную железку специально обученному софту (я как понял даже open source надо патчить) и только так оно будет быстрее. Чудес не бывает, и практически любой userspace использует те же самые возможности ядра только в режиме конкурентности и в порядке живой очереди.
Нет только компаний, которые бы вкладывали деньги и труд своих сотрудников.
Есть мнение, что они есть, но не возвращают большую часть своих наработок в upstream по той или иной причине. Лицензия же позволяет. Потому и имеем то, что имеем.
негативный опыт: старое здание с протекающей крышей, частые отключения света при дожде (обычное дело — отключение на 6+ часов ночью и на выходных, бесперебойники столько не держали), бывали отключения подряд (т.е. ФС восстанавливается после отключения и в этот самый момент происходит следующее отключение).
EXT4: многочасовые fsck, с которыми непонятно что делать, многократные поломки самой ФС, которые не лечатся fsck вообще (иногда второе следовало за первым т.е. я сидел, ждал, а в итоге ОС не может даже загрузиться)
XFS: любая проверка меньше 15 секунд, нулевое количество разрушений ОС за примерно аналогичный период (2 года против 2.5)
справедливости ради несохраненные данные лучше «выживали» на ext4 (если сама ФС не дохла), но кого это волнует? — у нормального админа все важные данные забэкаплены в любом случае
BTRFS хороша для системного раздела (если использовали атомарные обновления, понимаете), но не для данных (производительность может быть ниже в разы)
для установки CentOS 7 нужно минимум 1 GB памяти (я ставил и на 750 MB), просто нужно освоить kickstart и текстовую установку
отключать SELinux нельзя. просто нельзя и всё.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам (ну ext4 — это экскременты (простите за французский)) а в storage продуктах даже не поддерживает(!). SUSE тоже не рекомендует. только XFS.
зачем нужны Development tools (make, strace, gdb вот это всё) на боевом сервере (чтобы проще было руткиты и бэкдоры конпелять?) не оч понятно
Поэтому одна volume group используется для системы и обязательно другая исползуется для данных! Это логическое разделение сильно помогает в жизни!
можно пожалуйста поподробнее, кому помогает, как? бэкап PV — одна простая команда, аналогично и с восстановлением бэкапа, вы всю VG бэкапите? как если не секрет? много лет одной VG обходился…
Спасибо за статью. Тема бюджета не оч интересна, а вот исходник бота бы с удовольствием посмотрел (сам гофер + хочу бота одного написать), но ссылку не нашел, ткнёт кто-нибудь?
«Увы и Ах», многие беженцы с других языков используют пустые интерфейсы по сути для отмены типизации. Это неидеоматично, уродливо, небезопасно и медленно.
Пару раз пытался увещевать: «мол, не делайте так, сделайте лучше нормальный интерфес». В ответ лишь непонимание…
Принято считать, что языки программирования, такие как Rust, Erlang, Dart, а также некоторые другие являются самыми редкими в мире IT
кем принято? они даже в топ-20 самых редких не попадут, никак
Rust занял первую позицию(третий год подряд) в списке самых любимых языков
как этот опрос коррелирует с редкостью из заголовка? очень слабо. как этот опрос коррелирует с «дороговизной» из заголовка? вообще никак. зачем оно здесь?
Несмотря на то, что язык достаточно популярен в мире (… это про Rust ...)
false
не-pet проектов на Rust с значительной пользовательской базой крайне мало. проектов целиком на Rust без unsafe и unstable фич, но с пользаками ещё в принципе не существует! на популярном языке уже написали бы что-нибудь
Предлагают работу Rust разработчикам 32 компании на Headhunter
нет там такого, максиму что я видел 9
и да, «требуется React-разработчик, знание любого языка из списка следующих 6 (среди них есть Rust)» не значит что там ждут Rust-разработчика
Go не вытеснит Erlang, потому что для действительно высоконагруженных и сложных проектов Erlang является незаменимым языком.
киллер-фичи erlang — горячая замена кода и realtime (и около-realtime), в них может и не вытеснит, но в «высоконагруженных» и «сложных» вытеснит
“топовыми” языками для освоения являются: Rust, Erlang, Dart — есть спрос, высокая зарплата
надеюсь, это исследование увидит как можно меньше людей…
топовыми языками для освоения являются JavaScript и Python. там и спрос есть, а при наличии опредленных навыков и опыта ещё и зряплаты клёвые
Map_Handler стоило бы переписать, в Go принято обрабатывать ошибки явно, вот здесь:
нужно вернуть клиенту HTTP ошибку или JSON с описанием этой ошибки (иначе можно долго потом дебажить странное на клиенте)
ну и коллегу выше поддержку — нейминг надо починить (снейк-кейс, константы)
чем скорость мерили, time с format?
Даже на ноуте <2 секунд vscode стартует. Тестировал с 9 плагинами и 4 вкладками. На десктопе ещё быстрее.
Как и другие ждал аргументы в пользу того почему neovim > vim (пользуюсь последним для Си и конфигов)
хм…
такая версия точно существует? у меня в самой новой убунте 2.30
Автор — клоун, я даже дочитать этот опус не смог. Коллеги выше уже отметили нулевые знания в области (непонимание concurrency, parallelism, CSP), так ещё и полное профанство в языке Go (15-минутный go tour очевидно не пройден).
Даже лень комментировать этот бред: «go похож на goto (нет), поэтому они одинаковые (нет)», "'go' ломает исключения, а без них ошибки не обработать" (исключений в Go нет), «каналы ещё не придуманы и не существуют», «мифические абстракции ломаются (автор не знает какие абстракции есть в Go, но уверен что они ломаются)», «go ломает автоотчистку ресурсов» (её в Go тоже нет, но автор и этого не знает).
Немного питонирую и могу понять, какую проблему автор «героически» решает. Но это проблема именно языка Python (и многих других к сожалению), а Go с его «go» спроектирован на базе решения этой проблемы и просто иммунен к ней (но не ко многим другим к сожалению).
Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
Есть мнение, что они есть, но не возвращают большую часть своих наработок в upstream по той или иной причине. Лицензия же позволяет. Потому и имеем то, что имеем.
EXT4: многочасовые fsck, с которыми непонятно что делать, многократные поломки самой ФС, которые не лечатся fsck вообще (иногда второе следовало за первым т.е. я сидел, ждал, а в итоге ОС не может даже загрузиться)
XFS: любая проверка меньше 15 секунд, нулевое количество разрушений ОС за примерно аналогичный период (2 года против 2.5)
справедливости ради несохраненные данные лучше «выживали» на ext4 (если сама ФС не дохла), но кого это волнует? — у нормального админа все важные данные забэкаплены в любом случае
BTRFS хороша для системного раздела (если использовали атомарные обновления, понимаете), но не для данных (производительность может быть ниже в разы)
отключать SELinux нельзя. просто нельзя и всё.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам (ну ext4 — это экскременты (простите за французский)) а в storage продуктах даже не поддерживает(!). SUSE тоже не рекомендует. только XFS.
зачем нужны Development tools (make, strace, gdb вот это всё) на боевом сервере (чтобы проще было руткиты и бэкдоры конпелять?) не оч понятно
можно пожалуйста поподробнее, кому помогает, как? бэкап PV — одна простая команда, аналогично и с восстановлением бэкапа, вы всю VG бэкапите? как если не секрет? много лет одной VG обходился…
Как там у Снома с OPUS и SRTP в локализованных прошивках у бюджетных моделей?
<Шумно выдохнул...>
Ну раз ушли, следующая статья обещает быть интересной. Ждём.
Пару раз пытался увещевать: «мол, не делайте так, сделайте лучше нормальный интерфес». В ответ лишь непонимание…
статья бредовая:
1. автор пишет/использует несамодокументируемый код
2. указывает очевидную несамодокументированность кода
3. делает нелепые выводы
Роба Пайка бы лучше почитал/посмотрел
Дайте угадаю, Go не первый язык, а до него был C#? DI — это антипаттерн, ORM — тоже. GORM — два антипаттерна.
кем принято? они даже в топ-20 самых редких не попадут, никак
как этот опрос коррелирует с редкостью из заголовка? очень слабо. как этот опрос коррелирует с «дороговизной» из заголовка? вообще никак. зачем оно здесь?
false
не-pet проектов на Rust с значительной пользовательской базой крайне мало. проектов целиком на Rust без unsafe и unstable фич, но с пользаками ещё в принципе не существует! на популярном языке уже написали бы что-нибудь
нет там такого, максиму что я видел 9
и да, «требуется React-разработчик, знание любого языка из списка следующих 6 (среди них есть Rust)» не значит что там ждут Rust-разработчика
киллер-фичи erlang — горячая замена кода и realtime (и около-realtime), в них может и не вытеснит, но в «высоконагруженных» и «сложных» вытеснит
надеюсь, это исследование увидит как можно меньше людей…
топовыми языками для освоения являются JavaScript и Python. там и спрос есть, а при наличии опредленных навыков и опыта ещё и зряплаты клёвые