Не по самому кешированию, а по тому, что кеширующее железо стоит персонально для гугла и недоступно на тех же условиях третьим лицам. Нормальной ситуацией был бы договор гугла с отдельной независимой (от гугла, по крайней мере) компанией, которая обслуживала бы эти кеш-сервера, и предоставляла услуги на одинаковых условиях всем желающим.
Самое время ещё поднять цены. И поднимать до тех пор пока очередь не рассосётся. (А может быть можно и дальше поднимать — вдруг окажется что выгоднее добывать в 50 раз меньше по цене в 10000 раз больше). Заодно поможет снизить потребление.
Совершенно ужасный сайт. Более того, у меня на нём за последние годы ни разу не получилось посмотреть видео штатным образом.
Вместо централизованных хостингов лучше учить пользователей хранить нужные материалы у себя а не в сети. А сеть использвать только для первичного их скачивания с сайта автора (личного сайта, а не видеохостинга с аккаунтом на нём).
Это всё не имеет никакого отношения к ситуации со спутником. Если государство решило, что работы на один завод, то второй бы простаивал. Если бы государство решило, что работы на два завода, оно бы построило второй ради его прямого назначения. В обоих случаях спутник не влияет на ситуацию, и постройка одноразового завода без решения выпускать на нём основную продукцию привела бы к его простою.
Если там работы было на один завод, то при двух заводах они бы наполовину простаивали (либо второй бы просто не работал, либо каждый бы работал в полсилы, но суть от этого не меняется).
По хорошему этим ФАС должно было заниматься ещё давно. Они конечно могут всякие отмазки технического характера придумывать по типу «да мы просто сервера в стойке арендовали», но по сути это большая компания использует своё положение для дальнейшего подавления более маленьких конкурентов, которые не могут использовать такие же кеширующие сервера по всему миру.
Я не очень понял, что же собственно за устройство вы делаете. Мне под названием "инвертор" известен преобразователь постоянного тока в синусоиду — это он, или что-то другое? Если он, то зачем там вообще какой-то код?
Кстати, те, кто не хочет писать код, то могу на али купить микросхему EG8010, именно микросхему, а не модуль и получить такой же инвертор без необходимости писать код для STM32. Думаю многих любителей альтернативной энергетики это несомненно обрадует, т.к. не все могут и не всем хочется писать код по микроконтроллеры.
Был такой эпизод, оборудование единственного в стране чулочно носочного комбината который собственно те колготки и производил, использовали для производства теплоизоляции. Около двух месяцев, что ли… Жить это совершенно не мешает. снижает качество жизни, но не мешает. И таких примеров масса. Жить в таких условиях можно, но уже не хочется.
Если тот спутник был разовым проектом то по-моему всё правильно сделали. Иначе бы построили новое оборудование, которое потом бы стояло без дела и разваливалось.
Что, в общем случае, значит "не пускать"? Ввести строгое госурегулирование типа как у врачей?
Думаю, имелось ввиду — наплевать на их существование и делать всё так, как будто их нет. Таким образом вы поставите свою долю преград на их пути, по крайней мере к вашему коду.
Глобальная static-переменная мало чем отличается, у неё точно так же ограничена область видимости окружающим её кодом (для static-поля окружающий код это класс, для глобальной static-переменой — файл исходника с ней, а есть ещё локальные static-переменные с областью видимости — функией, где она объявлена).
Почему специализированный у нас процесс, а состояние — вся железка?
Потому что там ещё было слово "высоконагруженный". В таких случаях на каждого функционального демона выделяется своя железка, а то и несколько железок (как в вк). И цель оптимизаций — выжать максимум из железки для конкретного одного демона, и полностью плевать на сценарии, где на том же компе будет запущено что-то ещё.
то бранч индирекшон предиктор быстро обучится.
Вам всё равно придётся держать лишний занятый регистр под этот this и тратить несколько лишних байт кода чтобы в него загрузить нужное значение. Может быть это и не особо большой оверхед (хотя насчёт занятого регистра мне всё-таки кажется что заметный) но польза то от этого вообще нулевая в данном случае.
Потому что о программах без глобального состояния проще
Не всегда. А в случае высоконагруженного специализированного процесса — почти всегда наоборот. А если точнее, то "глобальное состояние" там — это состояние всего сервера (железки) с операционной системой. А любой процесс — уже локален, считайте что это экземпляр объекта "сервер" со своими полями. Вас же не смущает, когда методы класса меняют состояние класса, а не только свои локальные переменные? А оверхед "модного ооп-кода" убрали — он тут ни к чему, экземпляр этого объекта строго один на процесс, а может быть и на серверную железку, и поддержка нескольких экземпляров одновременно только создаёт лишнюю нагрузку (например обратиться к this->a всегда сложнее чем к глобальной переменной a).
Вместо централизованных хостингов лучше учить пользователей хранить нужные материалы у себя а не в сети. А сеть использвать только для первичного их скачивания с сайта автора (личного сайта, а не видеохостинга с аккаунтом на нём).
Я не очень понял, что же собственно за устройство вы делаете. Мне под названием "инвертор" известен преобразователь постоянного тока в синусоиду — это он, или что-то другое? Если он, то зачем там вообще какой-то код?
Опять, зачем писать код, если и без него можно?
Если тот спутник был разовым проектом то по-моему всё правильно сделали. Иначе бы построили новое оборудование, которое потом бы стояло без дела и разваливалось.
Думаю, имелось ввиду — наплевать на их существование и делать всё так, как будто их нет. Таким образом вы поставите свою долю преград на их пути, по крайней мере к вашему коду.
Глобальная static-переменная мало чем отличается, у неё точно так же ограничена область видимости окружающим её кодом (для static-поля окружающий код это класс, для глобальной static-переменой — файл исходника с ней, а есть ещё локальные static-переменные с областью видимости — функией, где она объявлена).
Потому что там ещё было слово "высоконагруженный". В таких случаях на каждого функционального демона выделяется своя железка, а то и несколько железок (как в вк). И цель оптимизаций — выжать максимум из железки для конкретного одного демона, и полностью плевать на сценарии, где на том же компе будет запущено что-то ещё.
Вам всё равно придётся держать лишний занятый регистр под этот this и тратить несколько лишних байт кода чтобы в него загрузить нужное значение. Может быть это и не особо большой оверхед (хотя насчёт занятого регистра мне всё-таки кажется что заметный) но польза то от этого вообще нулевая в данном случае.
Не всегда. А в случае высоконагруженного специализированного процесса — почти всегда наоборот. А если точнее, то "глобальное состояние" там — это состояние всего сервера (железки) с операционной системой. А любой процесс — уже локален, считайте что это экземпляр объекта "сервер" со своими полями. Вас же не смущает, когда методы класса меняют состояние класса, а не только свои локальные переменные? А оверхед "модного ооп-кода" убрали — он тут ни к чему, экземпляр этого объекта строго один на процесс, а может быть и на серверную железку, и поддержка нескольких экземпляров одновременно только создаёт лишнюю нагрузку (например обратиться к this->a всегда сложнее чем к глобальной переменной a).