Давайте признаем - что предыдущий ваш коммент был пальцем в небо. Объём помещения не влияет на необходимый объём приточного воздуха.
Теперь рассмотрим ещё один ваш тезис:
Если говорить о поддержании нормы СО2, то качество внешнего воздуха напрямую влияет на объёмы необходимые для смены воздуха.
Если рассмотреть "домик в лесу" и "дом в центре Москвы" - то разница в притоке составит примерно 15%-27% (15% - если целевое значение СО2 1400ppm и 27% - если целевое значение 1000ppm). Как по мне - это довольно незначительное значение (особенно если учесть, что подавляющее большинство людей вообще без приточки живёт и норм).
Как вывод: извините за прямоту - но в этой ветке вы делитесь прямо кледезью суеверий и заблуждений относительно приточной вентиляции. Хотя что проще - открыть имеющиеся документы и провести рассчёты.
1. Smalltalk-80 system browser (https://www.youtube.com/watch?v=JLPiMl8XUKU) - дейтсвительно выглядит как полноценная IDE. Если там была возможность просмотреть весь исходный код как исходники - её следует поставить на 1е место, а turbo-pascal перенести в 4 или ниже. С одним примечанием: в таких технологиях (ещё forth сюда же) - просто должны быть фатальные недостатки по которым они не взлетели. Такие рекламные ролики такие недостатки не показывают, неплохо бы понять их.
1.1 Например могу ли я - написать программу в виде текста (от и до), запустить её и отдебажить? Или эта система позволяла использовать толькоприложения, без полноценного цикла написания...отладки для всех остальных?
2 Разница между LSP + VSCode (первая его имплементация) vs Eclipse - в том, что в Eclipse не было языкового сервера, доступного другим фронтэндам (IDE-редакторам), а в LSP + VSCode был. Несомненно революция несомненно 2 место - сразу полсле "создания полноценной IDE".
Ни приоритеты ни логика не ясны. На первых местах стоят не прорывные, а просто "неплохие" технологии которые всплыли когда звёзды сошлись. По-моему так быть не должно.
Как должен выглядеть список по моему мнению:
Turbo Pascal - потому, что был первой массовой IDE в которой был интегрирован цикл разработки: Typing - Compiling - Running - Debugging.
Visual Studio Code - потому, что первый кто имплеменитировал LSP (Language Server Protocol): дав возможность разделить написание языкового сервера от фронтэнда-IDE-редактора.
Borland Delphi - первый качественный IDE, органически расширяемый компонентами с оконным фреймворком. Всё по отдельности было до. Но соединено вместе и такой высокой планкой качества было впервые в Delphi (в 1999 MS Visual Studio в подмётки не годилось Borland Delpi). RIP Delphi - ты не смог приспособиться к написанию больших программ.
MS Visual Studio (или 5?) - до C# был массовой, но плохой IDE. Потом стал массовой и хорошей.
Eclipse (или 4?) - за то, что был долгое время (пока MS Visual Studio балду пинало "мы так видим разработку") был передовым тулом "как хорошо бы делать IDE".
IntellyJ Idea - за то, что сейчас наверное лучший IDE tool-chain.
[g]vim / emacs - утешительный приз за хорошую попытку собрать open-source IDE с плагинами. К сожалению до LSP дело не дошло.
Из моих впечатлений (я, правда, пока в prod не затащил и всё ещё сомневаюсь - но пару внутренних утилит написал, а перед этим интересовался rust-"движухой"):
В теории - Rust мало ошибок и бОльшая гибкость за счёт выделения слоя абстракций (ну сколько там D и Haskell переходили на big endian архитектуры? лет по 6? А вот писали runtime на Rust - переход занял бы месяцы).
На практике - писать низкоуровневый код с выделениме всех абстракций и соблюдением растовского safe-API с памятью рука устанет. А какую-нибудь арифметику проще вообще *.try_into(..).unwrap() использовать, чем учитывать наличие платформ, где usize < u32 (выяснили что безопасность стоит времени, где-то подзабили, где-то вылезли из бюджета, хорошо если вообще Rust оставили).
Давайте я попробую сформулировать контр-тезис , пока у меня получилось вот что: "Программа в школе не перегружена, на практике, в том числе исходя из времени, требуемого ученику на домашнее задание и на домашнее задание с родителем".
Я правильно сформулировал ваш контр-тезис, или вы хотите его поправить?
общую систему профессиональной подготовки и профотбора в обществе
этапы и направления развития классической школы
формы и методы подготовки педагогических кадров
экономическую базу функционирования школьного образования
роль знания как фактор прогресса
и еще целую кучу еще более мелких тем.
О_О спасибо. Когда кто-то в следующий раз начнёт рассказывать "как нам обустроить школу", на самом деле имея в виду №7 и реже №3 - выкачу ему этот список.
Первая часть по-моему не релевантна. Интернет-сервисы же как-то справляются с 3 оценками (5, 4, 1) - и норм, статистика спасает.
Как по мне самая содержательная часть (и наверное основная в школе) - это часть, где за "2" наказывают учителя. Это действительно проблема. В итоге один ученик (не важно злонамеренный хулиган или умственно-особенный в классе с инклюзией) - портит обучение остальным 29. Это да огромная проблема. При этом "учиться" в школе, как и думать вообще - довольно сложно. И к подростковому возрасту ещё и вопрос появляется - вон Вася плохо себя ведёт, сделать ему ничего не могут, зачем мне напрягаться.
Честно говоря ни фига не понял как работает "наблюдающий знает ключ для расшифровки" и "наблюдающий знает о наличии сообщения".
Вот у нас есть картинка Pic, в которых младшие биты информации о цвете как-то распределены и текс Tex (много меньше картинки) который нам надо передать.
1. Что можно сделать - это получить новую картинку: Hide(Pic, Tex) = Pic_Tex такую, что: а) текст Tex будет замешан в картику Pic б) статистики распределения разных битов в картинке Pic_Tex не вызовут подозрений.
2. Что мы в итоге получим: а) Получатель может извлечь из Pic_Tex текст Tex б) Атакующий тоже может извлечь из Pic_Tex текст Tex (если будет просто пытаться вскрывать все сообщения от подозреваемого отправителя).
3. Итак вопрос: что же всё-таки сделали (я честно не понял)?
В части математики, скажем, вы смешиваете "подход в целом" и "реализацию подхода". Это очень хорошо видно на конкретных вопросах. Смотрите:
Зачем мы считаем дискриминант?
Для квадратного уравнения (общий случай оставим - тут дискриминант суррогат основной теоремы алгебры в действительных числах) на все эти вопросы содержательно отвечают в школе - решая сперва квадратное уравнение аналитически (методом выделения полного квадрата и разности квадратов). А дальше - поскольку надо идти вперёд просто однажды сделанное решение запоминается и идут дальше. К стати вы когда библиотеку пишите - разве не то же самое делаете? Один раз пишите код, решающий задачу, а дальше написанным кодом пользуетесь?
Проблема в том, что на практике программа перегружена. И по-существу нет времени, чтобы остановится и хорошо понять какие-то фундаментальные вещи. Надо спешить поверхностно охватить бОльшее количество тем.
Так и бороться, как мне кажется, надо с: - перегруженностью школьной программы - невозможностью справиться с "плохими" (нарушающими дисциплину) учениками.
Изходя из пунктов 1 и 3 - "большая сложная книга" не должна быть книгой на бумажном носителе, а должна представлять собой гипертекст, возможно ещё и со встроенным поиском.
Исходя из этого - точно ли такие книги нужно верстать для и печатать на бумаге? А если они верстаются и печатаются - не является ли такое действие борьбой против их потребителей?
В целом работает (более того я бы наверное "с ходу" написал бы с +/- такими же константами);
Но всё-таки с одним уточнением: step_size 128 - многовато.
На архитектурах, где malloc выравнивает пользовательский адрес по 8 байт (64 бита) - теоретически можно словить выход за пределы brk() и чтение из PROT_READ страницы.
ПС Другие примеры - вроде бы тоже привели в комментариях.
"можно организовать только через Х" и "через Х организовать проще всего, а ICmparable добавлять муторно" - разные утверждения. Я уже молчу что от пользователя мы получаем +/- строки (строки \ xml-json \ кортежи SELECT из базы).
На момент прошлого коммента не понимал: выкручивание будучи пойманным за руку - принципиальная позиция или стечение обстоятельств, когда неудобно признаться в неправоте. Сейчас понятно. DIXI.
Вы сказали фактически неверную вещь: "А элементы в общем случае сравнить можно только по хеш-коду".
Будучи пойманным за руку применили 2 очень некрасивые попытки выкрутиться: 1. Смена тезиса 2. "Это не я меняю тезис это вы (не важно что тут идёт, т.к. тезис был сменён)"
Если это ваша позиция - то разговор нужно завершать. Конструктив при такой позиции не просматривается.
> Чтобы бакет сделать деревом — нужен компаратор для элементов. А элементы в общем случае сравнить можно только по хеш-коду.
> для чего можно взять hash можно и сравнить побайтно
Это вы вообще про какой язык написали, что у вас есть бесплатный доступ к побайтовому сравнению любых данных?
Вы меняете тезис в процессе обсуждения. Не надо так ;)
> Не говоря уже о том - что для сравнения можно использовать более сильные хэш ф-ии
SHA2 да, атаке не подвержено. Но она сама по себе небыстрая, использовать её для хеш-таблиц — что из пушки по воробьям.
А где вы видели использования для хэш-таблиц? Использование только для компарации по дереву внутри бакета (ну и да бакет становится деревом, есил элементов в нём больше, чем N, в java ЕМНИП=4). Т.е. исключительно редко или если нас начали DOS-ить.
Чтобы бакет сделать деревом — нужен компаратор для элементов. А элементы в общем случае сравнить можно только по хеш-коду.
Это же прямо ложно. Всё из чего можно сделать хороший хэш (и/или взять Eq) - можно сравнить побайтно лексикографически, что для наших целей вполне подходит. Не говоря уже о том - что для сравнения можно использовать более сильные хэш ф-ии (SHA2 вроде не подвержено атаке искусственными коллизиями).
В общем это типичный пример когда "в теории" всё сложно, но если вам надо не шашечки, а ехать - то всё решаемо.
Крайне спорная статья. Вместо технических подробностей - голословные утверждения:
О том, что AMD повалит на лопатки Intel и будет пинать конкурента так же, как пинали ее саму в конце 00-х не может быть и речи: позиции «синих» слишком сильны, а наследие Мура в плане исследований и производства не могут разбазарить даже самые упрямые маркетологи компании, хотя в середине-конце 2010-х они очень старались.
А почему AMD не сможет в будущем технологически победить Intel?
В чём выражается "наследие Мура" в плане исследований?
В чём выражается "наследие Мура" в плане производства (учитывая, что по значимым метрикам Intel как раз отстаёт от TSMC)?
Вышел легендарный Pentium 4
А в чём легендарность? Один из самых неудачных процессоров. 30-стадийный конвейр (со всё ещё плохим branch prediction) выдавал очень плохую реальную производительность.
Давайте признаем - что предыдущий ваш коммент был пальцем в небо. Объём помещения не влияет на необходимый объём приточного воздуха.
Теперь рассмотрим ещё один ваш тезис:
Если рассмотреть "домик в лесу" и "дом в центре Москвы" - то разница в притоке составит примерно 15%-27% (15% - если целевое значение СО2 1400ppm и 27% - если целевое значение 1000ppm).
Как по мне - это довольно незначительное значение (особенно если учесть, что подавляющее большинство людей вообще без приточки живёт и норм).
Как вывод: извините за прямоту - но в этой ветке вы делитесь прямо кледезью суеверий и заблуждений относительно приточной вентиляции. Хотя что проще - открыть имеющиеся документы и провести рассчёты.
"количество нового кислорода \ час" = "количество потребляемого жильцами кислорода \ час".
Скажите пожалуйста где в этой простейшей формуле есть объём помещения?
И да санитарные нормы действительно рассчитываются исходя из потребления человеком (порядка 60м3 \ час в среднем), а не количества воздуха в квартире.
Но вы же действительно перепутали "граф" и "техническую реализацию" графа.
1. Smalltalk-80 system browser (https://www.youtube.com/watch?v=JLPiMl8XUKU) - дейтсвительно выглядит как полноценная IDE. Если там была возможность просмотреть весь исходный код как исходники - её следует поставить на 1е место, а turbo-pascal перенести в 4 или ниже. С одним примечанием: в таких технологиях (ещё forth сюда же) - просто должны быть фатальные недостатки по которым они не взлетели. Такие рекламные ролики такие недостатки не показывают, неплохо бы понять их.
1.1 Например могу ли я - написать программу в виде текста (от и до), запустить её и отдебажить? Или эта система позволяла использовать только приложения, без полноценного цикла написания...отладки для всех остальных?
2 Разница между LSP + VSCode (первая его имплементация) vs Eclipse - в том, что в Eclipse не было языкового сервера, доступного другим фронтэндам (IDE-редакторам), а в LSP + VSCode был. Несомненно революция несомненно 2 место - сразу полсле "создания полноценной IDE".
Ни приоритеты ни логика не ясны. На первых местах стоят не прорывные, а просто "неплохие" технологии которые всплыли когда звёзды сошлись. По-моему так быть не должно.
Как должен выглядеть список по моему мнению:
Turbo Pascal - потому, что был первой массовой IDE в которой был интегрирован цикл разработки: Typing - Compiling - Running - Debugging.
Visual Studio Code - потому, что первый кто имплеменитировал LSP (Language Server Protocol): дав возможность разделить написание языкового сервера от фронтэнда-IDE-редактора.
Borland Delphi - первый качественный IDE, органически расширяемый компонентами с оконным фреймворком. Всё по отдельности было до. Но соединено вместе и такой высокой планкой качества было впервые в Delphi (в 1999 MS Visual Studio в подмётки не годилось Borland Delpi). RIP Delphi - ты не смог приспособиться к написанию больших программ.
MS Visual Studio (или 5?) - до C# был массовой, но плохой IDE. Потом стал массовой и хорошей.
Eclipse (или 4?) - за то, что был долгое время (пока MS Visual Studio балду пинало "мы так видим разработку") был передовым тулом "как хорошо бы делать IDE".
IntellyJ Idea - за то, что сейчас наверное лучший IDE tool-chain.
[g]vim / emacs - утешительный приз за хорошую попытку собрать open-source IDE с плагинами. К сожалению до LSP дело не дошло.
Из моих впечатлений (я, правда, пока в prod не затащил и всё ещё сомневаюсь - но пару внутренних утилит написал, а перед этим интересовался rust-"движухой"):
В теории - Rust мало ошибок и бОльшая гибкость за счёт выделения слоя абстракций (ну сколько там D и Haskell переходили на big endian архитектуры? лет по 6? А вот писали runtime на Rust - переход занял бы месяцы).
На практике - писать низкоуровневый код с выделениме всех абстракций и соблюдением растовского safe-API с памятью рука устанет. А какую-нибудь арифметику проще вообще *.try_into(..).unwrap() использовать, чем учитывать наличие платформ, где usize < u32 (выяснили что безопасность стоит времени, где-то подзабили, где-то вылезли из бюджета, хорошо если вообще Rust оставили).
Давайте я попробую сформулировать контр-тезис , пока у меня получилось вот что: "Программа в школе не перегружена, на практике, в том числе исходя из времени, требуемого ученику на домашнее задание и на домашнее задание с родителем".
Я правильно сформулировал ваш контр-тезис, или вы хотите его поправить?
социальную функцию школы
средообразующий фактор образования
общую систему профессиональной подготовки и профотбора в обществе
этапы и направления развития классической школы
формы и методы подготовки педагогических кадров
экономическую базу функционирования школьного образования
роль знания как фактор прогресса
и еще целую кучу еще более мелких тем.
О_О спасибо.
Когда кто-то в следующий раз начнёт рассказывать "как нам обустроить школу", на самом деле имея в виду №7 и реже №3 - выкачу ему этот список.
Первая часть по-моему не релевантна. Интернет-сервисы же как-то справляются с 3 оценками (5, 4, 1) - и норм, статистика спасает.
Как по мне самая содержательная часть (и наверное основная в школе) - это часть, где за "2" наказывают учителя. Это действительно проблема.
В итоге один ученик (не важно злонамеренный хулиган или умственно-особенный в классе с инклюзией) - портит обучение остальным 29. Это да огромная проблема.
При этом "учиться" в школе, как и думать вообще - довольно сложно. И к подростковому возрасту ещё и вопрос появляется - вон Вася плохо себя ведёт, сделать ему ничего не могут, зачем мне напрягаться.
Честно говоря ни фига не понял как работает "наблюдающий знает ключ для расшифровки" и "наблюдающий знает о наличии сообщения".
Вот у нас есть картинка Pic, в которых младшие биты информации о цвете как-то распределены и текс Tex (много меньше картинки) который нам надо передать.
1. Что можно сделать - это получить новую картинку: Hide(Pic, Tex) = Pic_Tex такую, что:
а) текст Tex будет замешан в картику Pic
б) статистики распределения разных битов в картинке Pic_Tex не вызовут подозрений.
2. Что мы в итоге получим:
а) Получатель может извлечь из Pic_Tex текст Tex
б) Атакующий тоже может извлечь из Pic_Tex текст Tex (если будет просто пытаться вскрывать все сообщения от подозреваемого отправителя).
3. Итак вопрос: что же всё-таки сделали (я честно не понял)?
В части математики, скажем, вы смешиваете "подход в целом" и "реализацию подхода". Это очень хорошо видно на конкретных вопросах. Смотрите:
Для квадратного уравнения (общий случай оставим - тут дискриминант суррогат основной теоремы алгебры в действительных числах) на все эти вопросы содержательно отвечают в школе - решая сперва квадратное уравнение аналитически (методом выделения полного квадрата и разности квадратов). А дальше - поскольку надо идти вперёд просто однажды сделанное решение запоминается и идут дальше.
К стати вы когда библиотеку пишите - разве не то же самое делаете? Один раз пишите код, решающий задачу, а дальше написанным кодом пользуетесь?
Проблема в том, что на практике программа перегружена. И по-существу нет времени, чтобы остановится и хорошо понять какие-то фундаментальные вещи. Надо спешить поверхностно охватить бОльшее количество тем.
Так и бороться, как мне кажется, надо с:
- перегруженностью школьной программы
- невозможностью справиться с "плохими" (нарушающими дисциплину) учениками.
Изходя из пунктов 1 и 3 - "большая сложная книга" не должна быть книгой на бумажном носителе, а должна представлять собой гипертекст, возможно ещё и со встроенным поиском.
Исходя из этого - точно ли такие книги нужно верстать для и печатать на бумаге? А если они верстаются и печатаются - не является ли такое действие борьбой против их потребителей?
В целом работает (более того я бы наверное "с ходу" написал бы с +/- такими же константами);
Но всё-таки с одним уточнением: step_size 128 - многовато.
На архитектурах, где malloc выравнивает пользовательский адрес по 8 байт (64 бита) - теоретически можно словить выход за пределы brk() и чтение из PROT_READ страницы.
ПС
Другие примеры - вроде бы тоже привели в комментариях.
"можно организовать только через Х" и "через Х организовать проще всего, а ICmparable добавлять муторно" - разные утверждения.
Я уже молчу что от пользователя мы получаем +/- строки (строки \ xml-json \ кортежи SELECT из базы).
На момент прошлого коммента не понимал: выкручивание будучи пойманным за руку - принципиальная позиция или стечение обстоятельств, когда неудобно признаться в неправоте.
Сейчас понятно. DIXI.
Вы сказали фактически неверную вещь: "А элементы в общем случае сравнить можно только по хеш-коду".
Будучи пойманным за руку применили 2 очень некрасивые попытки выкрутиться:
1. Смена тезиса
2. "Это не я меняю тезис это вы (не важно что тут идёт, т.к. тезис был сменён)"
Если это ваша позиция - то разговор нужно завершать. Конструктив при такой позиции не просматривается.
Вы меняете тезис в процессе обсуждения. Не надо так ;)
А где вы видели использования для хэш-таблиц? Использование только для компарации по дереву внутри бакета (ну и да бакет становится деревом, есил элементов в нём больше, чем N, в java ЕМНИП=4). Т.е. исключительно редко или если нас начали DOS-ить.
Это же прямо ложно. Всё из чего можно сделать хороший хэш (и/или взять Eq) - можно сравнить побайтно лексикографически, что для наших целей вполне подходит.
Не говоря уже о том - что для сравнения можно использовать более сильные хэш ф-ии (SHA2 вроде не подвержено атаке искусственными коллизиями).
В общем это типичный пример когда "в теории" всё сложно, но если вам надо не шашечки, а ехать - то всё решаемо.
Используйте нормальные библиотеки хэшмап (или языки, где хэшмап из коробки нормальный). И атака не состоится.
Нормальные - это те, где бакеты организованы в виде деревьев.
Крайне спорная статья. Вместо технических подробностей - голословные утверждения:
А почему AMD не сможет в будущем технологически победить Intel?
В чём выражается "наследие Мура" в плане исследований?
В чём выражается "наследие Мура" в плане производства (учитывая, что по значимым метрикам Intel как раз отстаёт от TSMC)?
А в чём легендарность? Один из самых неудачных процессоров. 30-стадийный конвейр (со всё ещё плохим branch prediction) выдавал очень плохую реальную производительность.
Спасибо! Тот случай, когда комментарий ценнее самой статьи.