Домкрат? А использовать велосипедный насос? Для большего давления можно использовать велосипедный насос высокого давления, предназначенный для накачки вилок. Да, можете возразить, как обратно? Спускаем давление (неполностью), обратно поршень возвращает пружина.
Лично я категорически против того, чтобы пилоты думали о том, как сэкономить топливо. У пилотов и так нагрузка аховая, у них ответственность чудовищная, и смещать фокус внимания с безопасности на повышение экономичности (на самом деле, конечно, на получение лишнего баблишка в карман менеджеров) - это просто преступление. Менеджеров, СЕО, директорат, которые грузят пилотов экономией топлива, надо просто бить по башке палкой.
Пардон за некрокоммент. Мне кажется, у нас с вами расхождения по термину "право". Право - это не разрешение субъекту что-то делать. Право - это обеспечение общества для субъекта в чём-то. Например, право на труд - это не разрешение вам, можно работать, а можно не работать. Это обязанность, которое накладывается на общество в лице государства обеспечить вас работой с адекватным вознаграждением (и как следствием, отсутствием голодной смерти). Право на жизнь - это не разрешение жить или умирать, и тем более, не запрет кому-то убивать. Это обязанность, накладываемая на государство, реализовать такую систему, при которой никто вас не сможет убивать по своему желанию. Тюрьма - всего лишь метод, которым государство эту обязанность по мере возможности реализует.
Есть пирамида Маслоу (или как там?). Работать человека мотивируют не только деньги. Деньги - это база. Далее идет уважение, удовольствие от работы и прочее (не помню уже).
Говорить, что "деньги не являются мотиватором качественной работы" (как нам пытаются втирать недобросовестные работодатели) - некорректно, впрочем, как тезис, что только деньги является мотиватором.
Деньги - база, обязательное условие. Мотиваторами являются И деньги, И уважение, И интерес.
Спасибо. Еще вопрос - при создании виртуальных потоков выделяется контекст? Навскидку - ну раньше выделялась память на контекст в ОС средствами процессора (или ОС?), сейчас память выделяется на каждую задачу в JVM.
Мне вот хочется объяснения у специалистов. Автор пишет
простаивает на долгих I/O‑операциях, например, при обращениях к базе данных, по сети: поток «ждет байтики», занимая OS‑поток и ничего не делая.
В чем проблема? Из книг Рихтера, Таненбаума я знаю, что работа с потоками организована на уровне процессора: поток выполняется, уходит в спящий режим, выводится из спящего режима. Когда код отправляет запрос на I/O, он средствами windows отправляет поток в спящий режим. При этом ставится семафор (или что-то подобное, если я не ошибаюсь). При этом процессор НЕ ВЫПОЛНЯЕТ команды в этом потоке, то есть, вычислительные ресурсы НЕ ТРАТЯТСЯ. Когда оборудование выполнит I/O и загрузит данные в память (если я не ошибаюсь, даже без участия процессора), оно дает сигнал прерывания. ОС ловит этот сигнал и возобновляет выполнение потока. Далее этот поток снова начинает участвовать в карусели и получает толику процессорного времени.
Читая статьи по виртуальным потокам и глядя на картиночки, складывается впечатление, что авторы полагают, что поток "ждет байтики и ничего не делает" следующим образом: впадает в цикл и бесконечно опрашивает какую-то переменную в памяти "когда-же, когда-же?". Но ведь это не так?
Организация с потоками ОС сделана на уровне процессора, то есть, по-идее - быстро, эффективно, чисто, надежно. Организация виртуальных потоков - на уровне кода JVM, то есть, это какая-то надстройка, прорва кода, планировщиков, то есть лишние затраты процессора, ненадежность, какие-то костыли. Разве не так?
Второе замечание.
Как правильно сделал вывод автор, практически единственная сфера деательности виртуальных потоков, где они показывают результат - это кейс сервера, обрабатывающего небольшие запросы от клиентов. Проанализировав этот кейс, приходишь к выводу, что фактически, система виртуальных потоков создает очередь запросов, отлавливает tcp-запросы, складывает в очередь, а затем планировщик виртуальных "потоков" натравливает два-четыре потока ОС для выполнения этих задач по порядку из очереди. И это работает, да. Вместо создания тысяч потоков работают четыре-восемь, без перегрузки ОС, без чудовищного разбухания карусели потоков, и соответственно, без голодания остальными потоками приложений и ОС, без возможных блокировок и гонок. Прекрасно. Но данная задача сервис-клиенты решена, скажем так, через ж..., имхо. Не лучше ли ЯВНО решить задачу обработки запросов, через слушатель, очередь запросов и несколько воркеров?
Если вы администратор бизнес-приложений, попробуйте двигаться в сторону аналитики и интегратора. Программистов-быдлокодеров много, а людей, понимающих как работает бизнес и приложения - очень мало.
Загрузка данных, связь приложений друг с другом - вот, что нужно.
Перескочите через этап быдлокодинга (есть шанс застрять там на всю жизнь), предложите услуги более высокого уровня.
А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
public static class PetClientController {
@Getter(lazy = true)
private final JavaMailSender javaMailSender = new JavaMailSenderImpl();
public void adoptPet(SecurityProperties.User user, Object pet) {
//...
getJavaMailSender().send(new MimeMessage(...));
}
}
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Про ранд простейшее же решение - используй if и повторно используй ранд.
Домкрат? А использовать велосипедный насос? Для большего давления можно использовать велосипедный насос высокого давления, предназначенный для накачки вилок. Да, можете возразить, как обратно? Спускаем давление (неполностью), обратно поршень возвращает пружина.
Лично я категорически против того, чтобы пилоты думали о том, как сэкономить топливо. У пилотов и так нагрузка аховая, у них ответственность чудовищная, и смещать фокус внимания с безопасности на повышение экономичности (на самом деле, конечно, на получение лишнего баблишка в карман менеджеров) - это просто преступление. Менеджеров, СЕО, директорат, которые грузят пилотов экономией топлива, надо просто бить по башке палкой.
Пардон за некрокоммент. Мне кажется, у нас с вами расхождения по термину "право". Право - это не разрешение субъекту что-то делать. Право - это обеспечение общества для субъекта в чём-то. Например, право на труд - это не разрешение вам, можно работать, а можно не работать. Это обязанность, которое накладывается на общество в лице государства обеспечить вас работой с адекватным вознаграждением (и как следствием, отсутствием голодной смерти). Право на жизнь - это не разрешение жить или умирать, и тем более, не запрет кому-то убивать. Это обязанность, накладываемая на государство, реализовать такую систему, при которой никто вас не сможет убивать по своему желанию. Тюрьма - всего лишь метод, которым государство эту обязанность по мере возможности реализует.
Человечество в целом в порядке. В реальном производстве (и в реальной сфере экономики, кстати, тоже) всё хорошо. Это в ИТ бардак.
Есть пирамида Маслоу (или как там?). Работать человека мотивируют не только деньги. Деньги - это база. Далее идет уважение, удовольствие от работы и прочее (не помню уже).
Говорить, что "деньги не являются мотиватором качественной работы" (как нам пытаются втирать недобросовестные работодатели) - некорректно, впрочем, как тезис, что только деньги является мотиватором.
Деньги - база, обязательное условие. Мотиваторами являются И деньги, И уважение, И интерес.
Спасибо. Еще вопрос - при создании виртуальных потоков выделяется контекст? Навскидку - ну раньше выделялась память на контекст в ОС средствами процессора (или ОС?), сейчас память выделяется на каждую задачу в JVM.
Мне вот хочется объяснения у специалистов. Автор пишет
простаивает на долгих I/O‑операциях, например, при обращениях к базе данных, по сети: поток «ждет байтики», занимая OS‑поток и ничего не делая.
В чем проблема? Из книг Рихтера, Таненбаума я знаю, что работа с потоками организована на уровне процессора: поток выполняется, уходит в спящий режим, выводится из спящего режима. Когда код отправляет запрос на I/O, он средствами windows отправляет поток в спящий режим. При этом ставится семафор (или что-то подобное, если я не ошибаюсь). При этом процессор НЕ ВЫПОЛНЯЕТ команды в этом потоке, то есть, вычислительные ресурсы НЕ ТРАТЯТСЯ. Когда оборудование выполнит I/O и загрузит данные в память (если я не ошибаюсь, даже без участия процессора), оно дает сигнал прерывания. ОС ловит этот сигнал и возобновляет выполнение потока. Далее этот поток снова начинает участвовать в карусели и получает толику процессорного времени.
Читая статьи по виртуальным потокам и глядя на картиночки, складывается впечатление, что авторы полагают, что поток "ждет байтики и ничего не делает" следующим образом: впадает в цикл и бесконечно опрашивает какую-то переменную в памяти "когда-же, когда-же?". Но ведь это не так?
Организация с потоками ОС сделана на уровне процессора, то есть, по-идее - быстро, эффективно, чисто, надежно. Организация виртуальных потоков - на уровне кода JVM, то есть, это какая-то надстройка, прорва кода, планировщиков, то есть лишние затраты процессора, ненадежность, какие-то костыли. Разве не так?
Второе замечание.
Как правильно сделал вывод автор, практически единственная сфера деательности виртуальных потоков, где они показывают результат - это кейс сервера, обрабатывающего небольшие запросы от клиентов. Проанализировав этот кейс, приходишь к выводу, что фактически, система виртуальных потоков создает очередь запросов, отлавливает tcp-запросы, складывает в очередь, а затем планировщик виртуальных "потоков" натравливает два-четыре потока ОС для выполнения этих задач по порядку из очереди. И это работает, да. Вместо создания тысяч потоков работают четыре-восемь, без перегрузки ОС, без чудовищного разбухания карусели потоков, и соответственно, без голодания остальными потоками приложений и ОС, без возможных блокировок и гонок. Прекрасно. Но данная задача сервис-клиенты решена, скажем так, через ж..., имхо. Не лучше ли ЯВНО решить задачу обработки запросов, через слушатель, очередь запросов и несколько воркеров?
Слишком поспешно и оптимистично.
Если вы администратор бизнес-приложений, попробуйте двигаться в сторону аналитики и интегратора. Программистов-быдлокодеров много, а людей, понимающих как работает бизнес и приложения - очень мало.
Загрузка данных, связь приложений друг с другом - вот, что нужно.
Перескочите через этап быдлокодинга (есть шанс застрять там на всю жизнь), предложите услуги более высокого уровня.
А что, для всех убийц "not awailable"? Или некоторые убийцы кого надо убийцы?
Если вы покажете (и докажете), что для ВСЕХ убийц not awailable, а не так, что для некоторых - not awailable (мы все понимаем, для каких), а для некоторых - ок (мы все понимаем, для каких) - то тогда можно продолжать, если же нет (а мы все понимаем, что нет), то тогда вопрос в национальности, и этот тред можно преращать.
С определенной даты (мы все знаем, с какой) у вас нет морального права говорить про "убийц" в контектсе кидалова netflix (и прочих западных компаний) читателей Хабра.
Надо соблюдать Трудовое законодательство.
Они и в цехе любого производство мастера тем-же самым занимаются. Собачья работа.
Честно говоря, автор идеалист, и занимался чепухой.
Этот "Эффект манделы" разве что в головах зумеров.
Чем этот StableValue отличается от ломбокоской lazy? Если реализация - только еще один библиотечный класс, работающий на обычной java, то зачем все это?
Чем Jep-овская приблуда лучше этого кода?
Теория игр говорит, что при выборе решения нужно выбирать решение, при котором возможный проигрыш минимальный, а не то решение, при котором выигрыш максимальный.
Если мы выберем запретить ИИ - какие возможные выигрыш и проигрыш - выигрыш - медленное развитие человечества, излечение от всех болезней, расселение по всем планетам через тысячи лет, проигрыш - медленное угасание человечества. Если выберем использовать ИИ, выигрыш - излечивание всех болезней, автоматизация, генетическое преобразование человека, возможно, расселение по планетам, причем за срок порядка столения. Проигрыш при этом - уничтожение человечества, причем за годы.
Делайте выводы.
Больше всего удар по бойлерплейт нанес record. С ним почти все фичи ломбока можно запретить.
Годный материал.
"Эксперимент" - как пример того, когда неспециалист, психолог, биолог-недоучка, проектирует эксперимент над животными.
Пример: "Руководители часто винят регулирование или недостаточную производительность моделей ".
Если какая-то деятельность противоречит пусть даже всем мировым (кстати, какие еще есть?) религиям, это не делает ее пустой тратой времени и денег.