Что интересно, замок этот был программным, а не аппаратным. И само отключение клавы производилось BIOS-ом на довольно поздней стадии загрузки компа (уже после теста памяти). Затем BIOS писал что-то типа «нажмите F1 для продолжения», но нажать-то было нельзя, потому что клава-то была отключена.
Или все-таки можно?
Оказалось, что можно. Если успеть сразу после включения компа нажать в нужный момент эту F1, то клавиша попадала в буфер ввода клавиатуры, и в момент запроса F1 BIOS-ом отлично оттуда доставалась, а загрузка - продолжалась. Соответственно, если была подключена мышь, то можно было одной мышью дальше пользоваться: запускать игры кликом в Norton Commander, играть в них и т.д.
Мне было, кажется, лет 10 тогда. И одной из немногих игр, где можно было управляться исключительно мышью без клавиатуры, была Балда (это игра в слова на клетчатом поле). Ух сколько же часов я в нее проиграл от безысходности… сотни, наверное. А отец потом удивлялся, приходя домой, зачем же монитор теплый - но так и не смог понять, в чем был трюк (потом он стал забирать шнур питания, но я сделал свой из провода, фанеры и изоленты - но это уже совсем другая история).
Возможно, перепутаны причина и следствие. Это не язык популярен, потому что у главного инфлюенсера борода. Это у автора появляется борода, когда язык становится популярным: пользовательская база растет, а фич-реквестов и фидбэка становится так много, что у автора заканчивается время и, главное, мотивация, чтобы бриться (плюс известность и популярность автора тоже растут).
Брать того, кто имеет отличные технические навыки И умеет эффективно использовать cursor. Все просто. Cursor - это инструмент, такой же технический навык. Как рычаг. Кто его не использует, просто сам себе злобный буратина - «взял билет и не поехал». Потом, к хорошему быстро привыкаешь.
основная причина существования таких мнений - либо недостаточная осведомленность о том, что умеют новые инструменты, и как ими пользоваться, либо какая-то защитная реакция психики
Думаю, вы на 100% правы (причем не «либо-либо», а «и»). Но только никто не поверит с такой фразы (в том числе вот и я пока не верю, как раз по этим причинам). Реквестую конкретные примеры и/или конкретное видео, где показывается, как вы работаете и как это все выглядит на практике.
Из поста может сложиться впечатление, что эти суперчарджеры прямо-таки абсолютно необходимы, и без них никуда.
Реальность же такова: я лично заряжаю от обыкновенной бытовой розетки 110 вольт в гараже, этого хватает с лихвой для покрытия дневных поездок в сумме на ~65 км. Т.е. даже не требуется силовая розетка - просто самая обычная. Вот стоит сушилка для ботинок, а вот воткнута зарядка, все. Я сначала думал провести 3-фазную розетку на 240 вольт (типа как для электроплиты), но уже через несколько дней понял, что она не очень-то и нужна.
На суперчарджерах заряжаю очень редко, типа раз в месяц, обычно если на лыжах кататься едешь далеко или типа того. И, может, раз в месяц у магазина какого-нибудь от нетесельных зарядок, чисто заодно.
От розетки заряжать получается раза в 3 дешевле, чем бензин бы стоил; на суперчарджерах или сторонних станциях - ну где-то раза в 1.2-1.5 дешевле бензина. Т.е. от розетки заметная экономия.
Как только у вас будет запущен не один процесс приложения, а сотня-другая, все это превратится в тыкву, и без решения типа PgBouncer-а (пулер на стороне сервера) станет не обойтись. Придется иметь и то, и другое.
Но тут получается boilerplate (кажется) - во-первых, везде надо .0 писать, а во-вторых, вот это MyType/MyTypeInner - дублируется часть “MyType”, и имя “inner” тоже попахивает. Выглядит неаккуратненько как-то. Может быть, есть какой-то более нативный способ?
Уж очень хочется иногда в многопоточном приложении иметь объект, который в методах доступен через arc-mutex на self (а не через статические функции индивидуально по полям, где каждое поле есть сам себе arc-mutex).
Или какой-то другой паттерн вместо этого используют? Уж очень не хватает простоты «традиционных» языков в этом месте.
Что касается «почему в pgbouncer не сделают» - там уже никогда ничего не сделают, проект старый, код старый, порос мхом и лишайником. Но он все равно самый популярный, т.к. по инерции идет репутация, плюс все давно обложили костылями существующие баги и неудобства.
Балансировать несколько процессов pgbouncer я люблю через ipvsadm. Немного кривовато (на localhost его слушать мне так и не удалось заставить - только на реальном ip-адресе), зато честный round robin и максимально низкие накладные расходы.
Не может быть “теста Тьюринга в области xyz”. Весь смысл теста Тьюринга - что нет ограничений темы. Как хочешь, так и общайся, на любую тему. Иначе это черт-те что, а не тест: могут быть как в одну сторону результаты, так и в другую, ничего удивительного.
Я просто оставлю это здесь. Видео длинное, но оно прям в точку о том, где мы и что нас ждет; точно стоит того, чтобы досмотреть. Чувак посчитал рост копипаста/энтропии в интернете, ассоциированный с AI, и делает разные интересные выводы и прогнозы.
Суровая правда в том, что это не так важно - монолит или не монолит. Вернее, это важно только в смысле «сам себе злобный буратина»: проблема масштабирования stateless compute очень маленькая по сравнению с реально сложной вещью - масштабированием stateful database layer.
А почему люди так любят рассуждать про масштабирование compute - да вот как раз поэтому, из-за того, что рассуждать на данную тему легко. Это вообще паттерн: из всей задачи выделить самые простые 5% и раздуть их до 100% в текстах, документации, выступлениях на конференциях и т.д. Касается не только айти кстати, но и других аспектов жизни.
Поэтому я бы сказал не столько «монолит - твой друг», сколько «монолит или не монолит, это мало на что влияет, и можно в любой момент поменять».
А вот если у нас в базе монолит изначально (нет горизонтального масштабирования и не предусматривался такой путь развития), вот это прям беда-беда.
В защищенном режиме в регистрах типа DS, ES и т.д. хранился не индекс сегмента (который надо умножить на 16, чтобы получить абсолютный адрес), а селектор. И была таблица селекторов (в памяти по определенному адресу, заданному в другом регистре), где говорилось, к примеру (условно): “селектор 5 ссылается на область памяти, начиная со смещения 123456, длиной 789 и с атрибутами read-only и no-exec”. Запись номера селектора в DS приводила к чтению этой структуры и сохранению ее во внутреннее состояние регистра, ассоциированное с DS (и это очень дорогая операция). Блин, не помню уже все термины.
Так что операция инкремента селектора не имела смысла. Вероятно, поэтому разработчики процессора ее и не добавили в 8086, понимая, куда будет дуть ветер в будущем.
А вообще, все эти регистры сегментов и селекторы - мертворожденная идея. Поэтому ее и выпилили в x64 в пользу обычной страничной адресации. Да и в 8086 они пожадничали и сделали шаг сегментов 16-байтным, что не позволяло адресовать больше 1М памяти даже в теории - а могли бы шаг сделать, например, 256 байтов, и тогда бы получили «забесплатно» возможность в будущем расширить архитектуру до 16М памяти без переписывания софта.
Что интересно, замок этот был программным, а не аппаратным. И само отключение клавы производилось BIOS-ом на довольно поздней стадии загрузки компа (уже после теста памяти). Затем BIOS писал что-то типа «нажмите F1 для продолжения», но нажать-то было нельзя, потому что клава-то была отключена.
Или все-таки можно?
Оказалось, что можно. Если успеть сразу после включения компа нажать в нужный момент эту F1, то клавиша попадала в буфер ввода клавиатуры, и в момент запроса F1 BIOS-ом отлично оттуда доставалась, а загрузка - продолжалась. Соответственно, если была подключена мышь, то можно было одной мышью дальше пользоваться: запускать игры кликом в Norton Commander, играть в них и т.д.
Мне было, кажется, лет 10 тогда. И одной из немногих игр, где можно было управляться исключительно мышью без клавиатуры, была Балда (это игра в слова на клетчатом поле). Ух сколько же часов я в нее проиграл от безысходности… сотни, наверное. А отец потом удивлялся, приходя домой, зачем же монитор теплый - но так и не смог понять, в чем был трюк (потом он стал забирать шнур питания, но я сделал свой из провода, фанеры и изоленты - но это уже совсем другая история).
Один я только 4 раза с удивлением перечитал заголовок, но все равно понял, что речь не о Lurkmore, лишь когда кликнул?
Возможно, перепутаны причина и следствие. Это не язык популярен, потому что у главного инфлюенсера борода. Это у автора появляется борода, когда язык становится популярным: пользовательская база растет, а фич-реквестов и фидбэка становится так много, что у автора заканчивается время и, главное, мотивация, чтобы бриться (плюс известность и популярность автора тоже растут).
Брать того, кто имеет отличные технические навыки И умеет эффективно использовать cursor. Все просто. Cursor - это инструмент, такой же технический навык. Как рычаг. Кто его не использует, просто сам себе злобный буратина - «взял билет и не поехал». Потом, к хорошему быстро привыкаешь.
Думаю, вы на 100% правы (причем не «либо-либо», а «и»). Но только никто не поверит с такой фразы (в том числе вот и я пока не верю, как раз по этим причинам). Реквестую конкретные примеры и/или конкретное видео, где показывается, как вы работаете и как это все выглядит на практике.
О сколько нам открытий чудных
Готовят просвещенья дух
И Опыт, [сын] ошибок трудных…
Из поста может сложиться впечатление, что эти суперчарджеры прямо-таки абсолютно необходимы, и без них никуда.
Реальность же такова: я лично заряжаю от обыкновенной бытовой розетки 110 вольт в гараже, этого хватает с лихвой для покрытия дневных поездок в сумме на ~65 км. Т.е. даже не требуется силовая розетка - просто самая обычная. Вот стоит сушилка для ботинок, а вот воткнута зарядка, все. Я сначала думал провести 3-фазную розетку на 240 вольт (типа как для электроплиты), но уже через несколько дней понял, что она не очень-то и нужна.
На суперчарджерах заряжаю очень редко, типа раз в месяц, обычно если на лыжах кататься едешь далеко или типа того. И, может, раз в месяц у магазина какого-нибудь от нетесельных зарядок, чисто заодно.
От розетки заряжать получается раза в 3 дешевле, чем бензин бы стоил; на суперчарджерах или сторонних станциях - ну где-то раза в 1.2-1.5 дешевле бензина. Т.е. от розетки заметная экономия.
Ссылки по теме: статья про то, что в PostgreSQL одно соединение = один ОС-процесс, статья про work_mem.
Как только у вас будет запущен не один процесс приложения, а сотня-другая, все это превратится в тыкву, и без решения типа PgBouncer-а (пулер на стороне сервера) станет не обойтись. Придется иметь и то, и другое.
Но тут получается boilerplate (кажется) - во-первых, везде надо .0 писать, а во-вторых, вот это MyType/MyTypeInner - дублируется часть “MyType”, и имя “inner” тоже попахивает. Выглядит неаккуратненько как-то. Может быть, есть какой-то более нативный способ?
Про Раст мало на Хабре пишут, так что рискну спросить оффтопик: кто-нить в качестве паттерна делает ли как-то вот так:
Уж очень хочется иногда в многопоточном приложении иметь объект, который в методах доступен через arc-mutex на self (а не через статические функции индивидуально по полям, где каждое поле есть сам себе arc-mutex).
Или какой-то другой паттерн вместо этого используют? Уж очень не хватает простоты «традиционных» языков в этом месте.
Что касается «почему в pgbouncer не сделают» - там уже никогда ничего не сделают, проект старый, код старый, порос мхом и лишайником. Но он все равно самый популярный, т.к. по инерции идет репутация, плюс все давно обложили костылями существующие баги и неудобства.
Балансировать несколько процессов pgbouncer я люблю через ipvsadm. Немного кривовато (на localhost его слушать мне так и не удалось заставить - только на реальном ip-адресе), зато честный round robin и максимально низкие накладные расходы.
Это понятно, аналогов полно. Есть еще pgcat например. Но у аналогов есть и недостатки.
Rust абыдэлса на эту статью.
Не может быть “теста Тьюринга в области xyz”. Весь смысл теста Тьюринга - что нет ограничений темы. Как хочешь, так и общайся, на любую тему. Иначе это черт-те что, а не тест: могут быть как в одну сторону результаты, так и в другую, ничего удивительного.
Чо-то нет консистентности: ни PascalCase, ни camelCase, ни snake_case… что-то все время промежуточное и смешанное.
Я просто оставлю это здесь. Видео длинное, но оно прям в точку о том, где мы и что нас ждет; точно стоит того, чтобы досмотреть. Чувак посчитал рост копипаста/энтропии в интернете, ассоциированный с AI, и делает разные интересные выводы и прогнозы.
https://m.youtube.com/watch?v=Et8CqMu_e6s
Суровая правда в том, что это не так важно - монолит или не монолит. Вернее, это важно только в смысле «сам себе злобный буратина»: проблема масштабирования stateless compute очень маленькая по сравнению с реально сложной вещью - масштабированием stateful database layer.
А почему люди так любят рассуждать про масштабирование compute - да вот как раз поэтому, из-за того, что рассуждать на данную тему легко. Это вообще паттерн: из всей задачи выделить самые простые 5% и раздуть их до 100% в текстах, документации, выступлениях на конференциях и т.д. Касается не только айти кстати, но и других аспектов жизни.
Поэтому я бы сказал не столько «монолит - твой друг», сколько «монолит или не монолит, это мало на что влияет, и можно в любой момент поменять».
А вот если у нас в базе монолит изначально (нет горизонтального масштабирования и не предусматривался такой путь развития), вот это прям беда-беда.
В защищенном режиме в регистрах типа DS, ES и т.д. хранился не индекс сегмента (который надо умножить на 16, чтобы получить абсолютный адрес), а селектор. И была таблица селекторов (в памяти по определенному адресу, заданному в другом регистре), где говорилось, к примеру (условно): “селектор 5 ссылается на область памяти, начиная со смещения 123456, длиной 789 и с атрибутами read-only и no-exec”. Запись номера селектора в DS приводила к чтению этой структуры и сохранению ее во внутреннее состояние регистра, ассоциированное с DS (и это очень дорогая операция). Блин, не помню уже все термины.
Так что операция инкремента селектора не имела смысла. Вероятно, поэтому разработчики процессора ее и не добавили в 8086, понимая, куда будет дуть ветер в будущем.
А вообще, все эти регистры сегментов и селекторы - мертворожденная идея. Поэтому ее и выпилили в x64 в пользу обычной страничной адресации. Да и в 8086 они пожадничали и сделали шаг сегментов 16-байтным, что не позволяло адресовать больше 1М памяти даже в теории - а могли бы шаг сделать, например, 256 байтов, и тогда бы получили «забесплатно» возможность в будущем расширить архитектуру до 16М памяти без переписывания софта.
Вообще, по-хорошему это должен был бы быть флаг в pg_repack. Проблема-то общая.