Ну вот поэтому и мы и ориентируемся на статистику и цифры, а не на ощущения. Статистика, конечно, тоже может врать, но ощущения на больших числах врут почти всегда.
Нам в общем-то и этот пробег не очень важен: важен суммарный километраж, а ещё лучше -- суммарное потребление топлива.
А смотря что считать. Зачем нам считать размер батареек? Это как считать потребление бензина по размеру бака. Нам пробег нужен. Для примера, возьмём по Германии:
получаем средний пробег в ~16 километров в день. Средний электромобиль ест примерно 20кВтч/100км, возьмём с запасом 30кВт. Итого ~5 кВтч в день или ~1700 кВт*ч в год.
Сколько всего автомобилей в Германии? 50 млн. Умножаем одно на другое и получаем примерно 85 ТВт*ч. То есть меньше 20% от текущего потребления.
Вообще, если не хочется теоритизировать, есть Норвегия, где удельный вес электромобилей достаточно большой, чтобы это начало влиять на потребление энергии -- до трети автопарка.
Это что-то уровня отказа от Кобола. Они, конечно, могут отказаться от новых проектов на С++, но переписать весь старый код до 2030 -- это абсурд. (Вообще, этот проект больше исследование, чем план)
Скорее, наоборот, то, что было с 11 по 23 упростило разработку до какого-то вменяемого уровня. Сложность языка всё ещё запредельная, но писать стало приятнее.
Вот именно. Обычно автоматизировать вещи нужно только один раз. И только те вещи, что автоматизировать выгодно. Дальше тоже нужно, но в меньшем масштабе.
Нет. Что там будет гораздо меньше ошибок определённого класса, что судя по массовой миграции бигтеха с С++ на Раст, подтверждается. Правда, зачем всё переписывать, тем более с такой скоростью - непонятно.
Если нужен карьерный рост, то маленькие компании обычно не подходят -- там действительно расти почти некуда. Точнее, карьерный рост может выглядеть как "ушёл делать свой бизнес".
42 как раз несложно. Это ещё тот уровень, когда директор лично может сказать чем занимается каждый из сотрудников. Вот когда счёт сотрудников идёт на сотни, то законы физики начинают работать по-другому.
Телеграм был хорош для совсем мелких команд, либо для общения между командами. С ростом конечно же обычно переходили хотя бы на Mattermost.
Не, N100 гораздо хуже. К счастью, ноутбуки N100 и не стоят $600
Почему? Людей, которые переходили с Linux на MacOS я видел прилично. В основном, по причине "тоже unix с консолью, но более юзер-френдли".
Работает с качеством почты. Это не плохо для почты, но для мессенджера не очень удобно.
Речь про потребление. Тут, по-хорошему, рост должен быть заметен. Либо мы можем перевести на электричество треть автопарка и почти не заметить.
Ну вот поэтому и мы и ориентируемся на статистику и цифры, а не на ощущения. Статистика, конечно, тоже может врать, но ощущения на больших числах врут почти всегда.
Нам в общем-то и этот пробег не очень важен: важен суммарный километраж, а ещё лучше -- суммарное потребление топлива.
А смотря что считать. Зачем нам считать размер батареек? Это как считать потребление бензина по размеру бака. Нам пробег нужен. Для примера, возьмём по Германии:
https://www.cleanenergywire.org/news/germans-drive-over-15-kilometres-daily-car-use-down-after-pandemic
получаем средний пробег в ~16 километров в день. Средний электромобиль ест примерно 20кВтч/100км, возьмём с запасом 30кВт. Итого ~5 кВтч в день или ~1700 кВт*ч в год.
Сколько всего автомобилей в Германии? 50 млн. Умножаем одно на другое и получаем примерно 85 ТВт*ч. То есть меньше 20% от текущего потребления.
Вообще, если не хочется теоритизировать, есть Норвегия, где удельный вес электромобилей достаточно большой, чтобы это начало влиять на потребление энергии -- до трети автопарка.
А он просто больше не нужен. Правда, он уже больше года не нужен.
Выходит дороже. :)
Code тоже неплохо интегрирован в VSCode, но кроме того ещё и неплохо интегрирован с чем угодно. А с чем ещё не интегрирован -- можно интегрировать.
Obsidian -- это таки хороший пример приложения на Electron, возможно один из лучших.
Это что-то уровня отказа от Кобола. Они, конечно, могут отказаться от новых проектов на С++, но переписать весь старый код до 2030 -- это абсурд.
(Вообще, этот проект больше исследование, чем план)
Скорее, наоборот, то, что было с 11 по 23 упростило разработку до какого-то вменяемого уровня. Сложность языка всё ещё запредельная, но писать стало приятнее.
Вот именно. Обычно автоматизировать вещи нужно только один раз. И только те вещи, что автоматизировать выгодно. Дальше тоже нужно, но в меньшем масштабе.
По совместимости с софтом и железом (а зачем нам ещё нужна ОС?). По совместимости с Windows-софтом ReactOS хуже чем Linux с Wine.
Нет. Что там будет гораздо меньше ошибок определённого класса, что судя по массовой миграции бигтеха с С++ на Раст, подтверждается. Правда, зачем всё переписывать, тем более с такой скоростью - непонятно.
Так речь не про сложность руководства, а про сохранение размера. Размеры маленькой компании ещё поддаются контролю. :)
Что и прекрасно. Задачу решает и ладно.
А зачем в мире два онлифанса?
Если нужен карьерный рост, то маленькие компании обычно не подходят -- там действительно расти почти некуда. Точнее, карьерный рост может выглядеть как "ушёл делать свой бизнес".
42 как раз несложно. Это ещё тот уровень, когда директор лично может сказать чем занимается каждый из сотрудников. Вот когда счёт сотрудников идёт на сотни, то законы физики начинают работать по-другому.