А я вот (в Windows 3.1 правда, но мы же решили что это тоже оболочка DOS?) обожал PCTools Desktop. Настолько, что когда перешел на Windows 95, да и сейчас в Linux держу панель задач сверху экрана (в PCTools Desktop это было "by design", и не настраивалось). И логично же: меню приложений - сверху, панели инструментов/вкладки браузера - тоже, а вот панель задач - снизу почему-то, начиная с Win95. И наматывай километры мышкой вверх-вниз по экрану. А зачем? Кстати, наличие нескольких (до 4-х) виртуальных рабочих столов со своими отдельными окнами, обоями и иконками - оттуда же, из PCTools Desktop.
Почему писать в Arduino IDE - зашквар (сам в свое время поднабравшись опыта перешел на AVR Studio и чистый C) - но это же просто набор макросов, а под капотом тот же avr-gcc? И что, всех кто пытается делать минимальные реализации Python/JS делать для AVR - сразу "под шконку и в петушиную масть"?
В свое время (не скажу за всех, но в моем окружении) ее почему-то считали сиквелом Another World (хотя из общего - только разработчик и векторная анимация главного героя и кат-сцен ( Another World был целиком векторный). Хотя в Flashback ИМХО рулит именно pixel-art и умелая работа с палитрой в разных локациях (от зелени джунглей до неона киберпанка).
ЧЬИХ ожиданий? "говорили они" - кто говорил? "не совсем так, как мы ожидали" - кто это "мы?" Менеджеры среднего звена, которые возомнили что это такой себе "Silver Bullet" чтобы "срезать косты"?
Для PowerBI разработчик нужен. Ну или очень-очень продвинутый пользователь (чтобы дашборды сам себе делал). А SSAS (для пользователя неважно, Tabular или multidimensional) - с точки зрения юзера - просто сводные таблицы в Excel. Только предрассчитанные на сервере
Нет. GET - ПОЛУЧИТЬ готовый результат. POST - ОТПРАВИТЬ данные для обработки и получить ее результат. Возможно, не сразу (202). Для меня (senior, 40+) такого ответа (для джуна) было бы достаточно.
Эх, а во времена ZX-Spectrum (вот где реальный дефицит памяти был!) некоторые программы часть своего кода и данных в видеопамяти держали! Например, ленточные копировщики. Вот на этом скриншоте под цифрами "44032" и серым фоном - часть данных копируемых файлов (но они невидимые, потому что цвет фона и "текста" в этих "знакоместах" (т.н. атрибутах) совпадают. Да еще эти данные и сжимались на лету прямо в процессе чтения с ленты. Каким-то очень простым алгоритмом, что-то вроде RLE, но в реальном времени при чтении с ленты - на 3,5Mhz это было невероятно (и цифры вот эти тоже кстати в реальном времени в процессе чтения менялись)
А мне вот интересно: фотография PNG-24 (без потерь) была до этого JPEG/AVIF/JXL более высокого разрешения. И при сжатии и уменьшении больше всего страдает (сглаживается) как раз этот самый LSB (как самый невидимый, но добавляющий при этом кучу энтропии в данные, сильно мешая сжатию). И по идее отделив этот самый LSB и увидев что там "белый шум" сразу закрадутся подозрения, что "это-жж-ж неспроста"?
https://www.bee-link.com/products/beelink-gti14-ultra9-185h В нем есть полноценный PCI-Ex16 (хотя выведено на него только 8 линий), и через специальную док-станцию к нему подключали именно RTX4090 (гуглите "Я Зібрав Найбільший Міні-ПК в Світі")
Мое мнение про PSSR можно выразить цитатой Воланда из классики: «Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут» (М.Булгаков). Ведь есть же открытый FSR3 от AMD (чип от которых там УЖЕ стоит), а DLSS им NVidia никогда бы не лицензировала, т.к. это бы означало, что никакой особой нейросетевой магии у них нет и технология эта и на "красных" работать может. Ну или XeSS от Intel (они и так на дно идут). А так - еще один велосипед и как следствие - рихтовка квадратных колес (причем я так понял, руками студий, а не самой Sony).
Не скажу за все СУБД - но в тех с которыми имел дело - не отображается. Да и "табличкой" это я назвал весьма условно. По байту добавлять для каждого поля - А) Накладно Б) Теряем выравнивание по границе слова. А по слову добавлять - так вообще 4 байта теряем. Поэтому и битовые карты. Хотя может где-то есть и другие решения. В PostgreSQL это стараются оптимизировать как могут, например если в таблице меньше 8 колонок допускающих NULL-они действительно отдельный байт на строку выделяют, вот тут чуть подробнее: https://dba.stackexchange.com/questions/197425/why-does-postgresql-create-an-additional-null-bitmap-if-all-fields-after-the-8th Одно точно можно сказать - NULL-ы это всегда какой-никакой оверхед для движка БД.
Значительная часть советов в статье - я считаю универсальная, а не только про PostgreSQL. Я бы от себя еще добавил: Не используйте без крайней необходимости поля, допускающие NULL! Рациональное объяснение: вот есть у нас поле типа int not null (предположим, что int у нас - 4 байта). Тогда это поле может содержать 2^32 значений. Всё отлично выровнено по границе байтов (кластеров, блоков, чего угодно). Но если это это же поле у нас имеет тип int null - нам нужно как-то обеспечить, чтобы оно хранило уже 2^32+1 значений. Куда девать этот "лишний" бит? Расширять поле на целый байт? Слишком накладно. Поэтому умные дядьки придумали для колонок с полями, которые могут содержать NULL отдельную сущность - "карты" или "битмапы" NULL-ов - по-сути отдельную табличку, хранящую в одном бите является значение NULL-ом или нет. Но это мало того, что дополнительная сущность - к ней движок БД должен обращаться при КАЖДОМ запросе, причем делая кучу вычислений смещений и битовых операций просто для того, чтобы узнать: "А не NULL ли у нас конкретно в этом поле этой строки лежит?"
А я вот (в Windows 3.1 правда, но мы же решили что это тоже оболочка DOS?) обожал PCTools Desktop. Настолько, что когда перешел на Windows 95, да и сейчас в Linux держу панель задач сверху экрана (в PCTools Desktop это было "by design", и не настраивалось). И логично же: меню приложений - сверху, панели инструментов/вкладки браузера - тоже, а вот панель задач - снизу почему-то, начиная с Win95. И наматывай километры мышкой вверх-вниз по экрану. А зачем?
Кстати, наличие нескольких (до 4-х) виртуальных рабочих столов со своими отдельными окнами, обоями и иконками - оттуда же, из PCTools Desktop.
Почему писать в Arduino IDE - зашквар (сам в свое время поднабравшись опыта перешел на AVR Studio и чистый C) - но это же просто набор макросов, а под капотом тот же avr-gcc? И что, всех кто пытается делать минимальные реализации Python/JS делать для AVR - сразу "под шконку и в петушиную масть"?
В свое время (не скажу за всех, но в моем окружении) ее почему-то считали сиквелом Another World (хотя из общего - только разработчик и векторная анимация главного героя и кат-сцен ( Another World был целиком векторный). Хотя в Flashback ИМХО рулит именно pixel-art и умелая работа с палитрой в разных локациях (от зелени джунглей до неона киберпанка).
Чувствуется что-странное тут, и "зачем я это прочитал", но ООО "БАХИЛЫ СОТОНЫ" - You made my вечер пятницы!
ЧЬИХ ожиданий? "говорили они" - кто говорил? "не совсем так, как мы ожидали" - кто это "мы?" Менеджеры среднего звена, которые возомнили что это такой себе "Silver Bullet" чтобы "срезать косты"?
Для PowerBI разработчик нужен. Ну или очень-очень продвинутый пользователь (чтобы дашборды сам себе делал). А SSAS (для пользователя неважно, Tabular или multidimensional) - с точки зрения юзера - просто сводные таблицы в Excel. Только предрассчитанные на сервере
Пока в Libre/Open/Мой/Твой/Office не появится поддержка подключения к MS Analysis Services - для бизнеса это не альтернативы.
Нет. GET - ПОЛУЧИТЬ готовый результат. POST - ОТПРАВИТЬ данные для обработки и получить ее результат. Возможно, не сразу (202). Для меня (senior, 40+) такого ответа (для джуна) было бы достаточно.
Вершинные шейдеры и инстансинг там были (я еще вспоминаю восторг моего шефа с топовой на то время 9800XT) - "Блин, там КОЛОСКИ шевелятся на ветру!!"
QR-коды-то хоть есть?
Ну писал же Сам Он: "Remember the Vasa!"
https://www.stroustrup.com/P0977-remember-the-vasa.pdf
Но я так понимаю что "дедушка старый уже, дедушке под 80, чё это он молодежь поучать вздумал на старости лет?"
"Thank you, and Fuck you". (C) Control '2019
Эх, а во времена ZX-Spectrum (вот где реальный дефицит памяти был!) некоторые программы часть своего кода и данных в видеопамяти держали! Например, ленточные копировщики. Вот на этом скриншоте под цифрами "44032" и серым фоном - часть данных копируемых файлов (но они невидимые, потому что цвет фона и "текста" в этих "знакоместах" (т.н. атрибутах) совпадают. Да еще эти данные и сжимались на лету прямо в процессе чтения с ленты. Каким-то очень простым алгоритмом, что-то вроде RLE, но в реальном времени при чтении с ленты - на 3,5Mhz это было невероятно (и цифры вот эти тоже кстати в реальном времени в процессе чтения менялись)
А мне вот интересно: фотография PNG-24 (без потерь) была до этого JPEG/AVIF/JXL более высокого разрешения. И при сжатии и уменьшении больше всего страдает (сглаживается) как раз этот самый LSB (как самый невидимый, но добавляющий при этом кучу энтропии в данные, сильно мешая сжатию). И по идее отделив этот самый LSB и увидев что там "белый шум" сразу закрадутся подозрения, что "это-жж-ж неспроста"?
https://www.bee-link.com/products/beelink-gti14-ultra9-185h
В нем есть полноценный PCI-Ex16 (хотя выведено на него только 8 линий), и через специальную док-станцию к нему подключали именно RTX4090 (гуглите "Я Зібрав Найбільший Міні-ПК в Світі")
Мое мнение про PSSR можно выразить цитатой Воланда из классики: «Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут» (М.Булгаков). Ведь есть же открытый FSR3 от AMD (чип от которых там УЖЕ стоит), а DLSS им NVidia никогда бы не лицензировала, т.к. это бы означало, что никакой особой нейросетевой магии у них нет и технология эта и на "красных" работать может. Ну или XeSS от Intel (они и так на дно идут). А так - еще один велосипед и как следствие - рихтовка квадратных колес (причем я так понял, руками студий, а не самой Sony).
Это много где, не только в Postgres. Даже SQLite нужен vacuum (он там и называется так же), и MSSQL (а там - SHRINKFILE)
Позволю не согласиться - есть, на процессор при всех этих манипуляциях с битами. Хоть на современных процессорах он и минимален.
Не скажу за все СУБД - но в тех с которыми имел дело - не отображается. Да и "табличкой" это я назвал весьма условно. По байту добавлять для каждого поля - А) Накладно Б) Теряем выравнивание по границе слова. А по слову добавлять - так вообще 4 байта теряем. Поэтому и битовые карты. Хотя может где-то есть и другие решения. В PostgreSQL это стараются оптимизировать как могут, например если в таблице меньше 8 колонок допускающих NULL-они действительно отдельный байт на строку выделяют, вот тут чуть подробнее:
https://dba.stackexchange.com/questions/197425/why-does-postgresql-create-an-additional-null-bitmap-if-all-fields-after-the-8th
Одно точно можно сказать - NULL-ы это всегда какой-никакой оверхед для движка БД.
Значительная часть советов в статье - я считаю универсальная, а не только про PostgreSQL. Я бы от себя еще добавил:
Не используйте без крайней необходимости поля, допускающие NULL!
Рациональное объяснение: вот есть у нас поле типа int not null (предположим, что int у нас - 4 байта). Тогда это поле может содержать 2^32 значений. Всё отлично выровнено по границе байтов (кластеров, блоков, чего угодно). Но если это это же поле у нас имеет тип int null - нам нужно как-то обеспечить, чтобы оно хранило уже 2^32+1 значений. Куда девать этот "лишний" бит? Расширять поле на целый байт? Слишком накладно. Поэтому умные дядьки придумали для колонок с полями, которые могут содержать NULL отдельную сущность - "карты" или "битмапы" NULL-ов - по-сути отдельную табличку, хранящую в одном бите является значение NULL-ом или нет. Но это мало того, что дополнительная сущность - к ней движок БД должен обращаться при КАЖДОМ запросе, причем делая кучу вычислений смещений и битовых операций просто для того, чтобы узнать: "А не NULL ли у нас конкретно в этом поле этой строки лежит?"