Довольно забавно сравнивать одну только стандартную библиотеку с++ с кучей разрозненных репозиториев на github. Давайте тогда ещё boost и abseil в сравнение включим
Могу сказать за себя. У нас тимбилдинги выглядят чаще всего как корпоративная попойка оплаченная из кармана компании. И в какой-то мере это работает. Идиотами вроде себя никто не чувствует
Я не слишком хорошо знаком с миром Java-разработки, но разве не приложения под Android/ какие-то серверные штуки являются основной частью? Standalone Jar я так понимаю не слишком часто встречаются.
Там необходимо указывать точку входа.
Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
Потому что в линуксе вообще в среднем отвратные GUI, свистелок прикручено много, а спонтанное срабатывание первого пункта контекстного меню так и не изменилось за последние 10 лет.
Имею диаметрально противоположное мнение: как в уже установленной системе сменить основной язык? А чтобы при этом не отвалились локали консоли и не было мучительно больно из-за неработающего графического логина, потерявшего настроенную локаль?
На самом деле это следует из широкой распространённости Linux среди разработчиков, что я могу понять лишь частично. В Windows-мире не принято плевать в пользователя текстовым интерфейсом и требовать, чтобы человек на основании знаний предков(т.к. в доках и хелпе есть далеко не всё) узнавал какие же ещё ключи нужно передать конкретной утилите. Связано это видимо с тем, что средняя Windows-система предполагает наличие интегрированного везде GUI, тогда как X является лишь средней паршивости костылём.
Этот мозг-матрёшка ничем принципиально не отличается от имеющихся у нас вычислительных средств. Вернее там вообще ничего не говорится про прирроду этого компьютера, только про его масштабы и источник энергии.
"-l" контролирует load average, причём получает его при помощи getloadavg(), так что точность оставляет желать лучшего. И получается так же как у ТС в той ветке. Т.е. линкер сначала памяти использует мало, и ninja спокойно спавнит их 8 штук. А потом каждый линкер начинает использовать по 7-8Гб памяти и всё это уходит в глубокий swap или падает по oom.
Там была идея добавлять к каждому таргету оценочное использование памяти чтобы ninja мог делать оценку перед запуском процесса. И это выглядит единственным достоверным решением.
Он неплох, но совсем не бесплатный. И у него какие-то совершенно жуткие представления о удобной настройке хоткеев. Когда любой установленный пакет вываливает тебе в лицо пустой текстовый файл конфигурации и нужно ещё пойти в поисковик и отрыть документацию, чтобы понять какие команды он вообще предоставляет.
Atom ужасный и тормозной. Пробовал его использовать — настроить нормально не смог. Получить плавную прокрутку с работающим outline для хотя-бы базового набора языков мне не удалось.
Пока перебиваюсь Sublime, но отдавать за текстовый редактор 70$ как-то многовато, а по ощущениям он почти перестал развиваться.
VSCode использует тот же Electron, что и Atom и наследует все его недостатки.
Skype под винду тоже ужасен, но с ним всё-таки можно жить. А перейти с него до конца я, к сожалению, не могу.
Kati же просто генерирует Ninja.build на основе Makefile. А весь llvm и так использует CMake, так что использовать Ninja можно и так. Только отличий во времени сборки/потреблению памяти я не заметил.
Это бы нужно добавлять в систему сборки какой-то механизм отслеживания загрузки, и не создавать новые процессы, когда память/ресурсы CPU уже на пределе.
Вот тут даже есть обсуждение чего-то подобного. Но дальше обсуждений дело не продвинулось.
Использую Win10 как основную с 2015 года. Читал про это и не представляю что нужно делать, чтобы это повторить. Ну разве что в течении нескольких месяцев откладывать обновления( и жаловаться, что окошки небезопасные ).
Замену foobar2000(DEADBEEF и Foobnix пробовал — не то) мне найти не удалось. Полноценную замену для notepad++, чтобы без костылей и плясок с бубном тоже не обнаружил. Skype под линукс — был тихим ужасом, когда я видел его последний раз.
При сборке swift по умолчанию ld.gold как раз используется. Всё равно приходится прерывать сборку c -j10 и ставить -j1 иначе всей системе приходит конец.
Но тут скорее уже make виноват, продолжая спавнить процессы, даже когда ресурсы на пределе.
Вы действительно не понимаете, что разницы никакой? Во всех дистрах, где представлены GUI есть эта проблема. Стоит загрузке процессора/использованию физической памяти дойти до 100% и это всегда происходит.
Дебаг сборка llvm-clang при линковке у меня заставляет Xorg задуматься о сущности вселенной минут на 40. Это связано даже не с иксами, т.к. Wayland эту проблему не решает
А разве ж это дело, когда строка в какиих-то жалких 270 символов уезжает за пределы второго экрана при настройке отображения табов на 18 пробелов.
P.S. Единственный серьёзный аргумент — желание, чтобы у всех код выглядел одинаково. Но вообще может стоит просто писать так, чтобы не нужно было выравнивать по 30 строк?
Я по быстрому посмотрел 50 серию, да всё так же. Это, может быть, неплохо подходит, чтобы познакомить детей младшего школьного возраста с физикой, но мало что имеет с изучением физики как науки.
Если запускать обновления раз в 1.5 года, то да, тороза и глюки. На линуксе такого нет, там обычно после такого обновления просто не стартует всё, начиная с XOrg и заканчивая init.
А саму ОС на пакеты разбить.
Ни в коем случае. Винда именно тем и хороша, что работает из коробки и что не нужно поддерживать 60 млн. хомячков с 300 разными версиями одной и той же библиотеки. А ещё не требует после каждого обновления вспоминать, какие же ещё конфиги снова переписано пакетником и их бы нужно опять восстановить.
Довольно забавно сравнивать одну только стандартную библиотеку с++ с кучей разрозненных репозиториев на github. Давайте тогда ещё boost и abseil в сравнение включим
Могу сказать за себя. У нас тимбилдинги выглядят чаще всего как корпоративная попойка оплаченная из кармана компании. И в какой-то мере это работает. Идиотами вроде себя никто не чувствует
Я не слишком хорошо знаком с миром Java-разработки, но разве не приложения под Android/ какие-то серверные штуки являются основной частью? Standalone Jar я так понимаю не слишком часто встречаются.
Но ведь есть целая куча Jar-библиотек, которые вообще не предполагается использовать для запуска
Всё почти так же. В качестве Main класса можно указать любой класс, содержащий статический метод main(). Можно иметь несколько точек входа
не осилите, для этого вам придётся нос вывернуть градусов на 180, так он у вас задран
Там была идея добавлять к каждому таргету оценочное использование памяти чтобы ninja мог делать оценку перед запуском процесса. И это выглядит единственным достоверным решением.
Пока перебиваюсь Sublime, но отдавать за текстовый редактор 70$ как-то многовато, а по ощущениям он почти перестал развиваться.
VSCode использует тот же Electron, что и Atom и наследует все его недостатки.
Skype под винду тоже ужасен, но с ним всё-таки можно жить. А перейти с него до конца я, к сожалению, не могу.
Это бы нужно добавлять в систему сборки какой-то механизм отслеживания загрузки, и не создавать новые процессы, когда память/ресурсы CPU уже на пределе.
Вот тут даже есть обсуждение чего-то подобного. Но дальше обсуждений дело не продвинулось.
Но тут скорее уже make виноват, продолжая спавнить процессы, даже когда ресурсы на пределе.
Дебаг сборка llvm-clang при линковке у меня заставляет Xorg задуматься о сущности вселенной минут на 40. Это связано даже не с иксами, т.к. Wayland эту проблему не решает
А разве ж это дело, когда строка в какиих-то жалких 270 символов уезжает за пределы второго экрана при настройке отображения табов на 18 пробелов.
P.S. Единственный серьёзный аргумент — желание, чтобы у всех код выглядел одинаково. Но вообще может стоит просто писать так, чтобы не нужно было выравнивать по 30 строк?
Если запускать обновления раз в 1.5 года, то да, тороза и глюки. На линуксе такого нет, там обычно после такого обновления просто не стартует всё, начиная с XOrg и заканчивая init.
Ни в коем случае. Винда именно тем и хороша, что работает из коробки и что не нужно поддерживать 60 млн. хомячков с 300 разными версиями одной и той же библиотеки. А ещё не требует после каждого обновления вспоминать, какие же ещё конфиги снова переписано пакетником и их бы нужно опять восстановить.