Это мне тоже, честно говоря, непонятно. Я не специалист в делопроизводстве (автор оригинальной статьи, как я понимаю, тоже), и мне последние 10 лет за глаза хватает OO/LO для того, чтобы набросать презенташку для конфы, коммерческое предложение, заявление в инстанцию, подбить персональные финансы и т. п. Ни с какими шоу-стопперами ещё не сталкивался. ЧЯДНТ, как говорится?
А есть ли вообще причины использовать эту WSL вместо давно уже существующих решений? Преимущества, специфические юзкейсы?
А то так-то Linux уже лет 10 как можно с тем же успехом установить в VirtualBox, Windows − в KVM с VirtManager. Linux-программы собираются и пакуются для Windows с помощью Cygwin или MSYS2. В обратную сторону − libwine. С иксами тоже нет проблем. К чему весь этот хайп? E3?
С кодом гораздо сложнее исследование придумать, тут от языка много зависит
Я так не думаю. Скорее всего, всё зависит от напряжения глазодвигательных мышц.
А можно ссылку почитать подробнее? Всегда думал, что широкоформатные мониторы стали повсеместными из-за медиаконтента, поэтому именно 16:9, а не 17:8 например.
Это всё давно было, ссылки уже протухли, да и я могу что-то путать, но отдельные отголоски ещё встречаются. Вот, например:
“It is all about reducing manufacturing costs. The new 16:9 aspect ratio panels are more cost effective to manufacture locally than the previous 16:10 panels,” Budler said.
Или вот ещё:
Напомним еще раз: при равной диагонали ЖК-панели с соотношением сторон 16:10 имеют меньшую площадь, нежели изделия с форматом экрана 5:4. Это обстоятельство позволяет при тех же производственных затратах изготавливать на одной пластине большее количество заготовок широкоформатных ЖК-панелей. Иными словами, производство широкоформатных ЖК-панелей обходится дешевле.
По читабельности печатного текста есть а) многовековая традиция и б) десятки более-менее современных исследований, которые её подтверждают. Читабельностью кода на экране монитора то ли никто не интересуется, то ли я не в курсе этой движухи. Но я бы не стал менять стайлгайды без достаточных на то оснований.
Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
Правила типографики устанавливают ширину колонки в 45-75 символов, иначе неудобно перемещать взгляд. Я думаю, нет смысла ломать эту традицию, не имея серьёзных теоретических обоснований. Кто-нибудь в курсе, исследовался ли этот вопрос недавно? А то Линус рассуждает в своём письме чисто эмпирически, меня лично это не убеждает. Я буду в оформлении кода придерживаться тех норм, которые ближе к типографическим, то есть до 80 символов в колонке.
Я думаю, достаточно того, что Microsoft в своих анонсах и документации никогда не называла Windows операционной системой. Вплоть до выхода Windows 95. (Да, я в курсе, что NT 3.5 вышла раньше 95, с ней всё понятно.) Термин, который тогда использовался − операционная среда (operating environment). GEM Desktop, например, тоже назывался операционной средой.
В то же время MS DOS, CP/M, Xenix и др. вполне себе назывались и являлись операционными системами. В отличие от Windows 1/2/3.
Внутри интел одна команда обещала и показывала быструю «монетизацию», а другая нет. Инвесторы посмотрели/подождали и запустили stop-loss. Примерно всё.
А как насчёт HP или Fujitsu? У них запасной архитектуры не было, в отличие от Intel.
Нет, ладно, допустим, у HP и Fujitsu были другие профильные активы. Но у Transmeta их точно не было.
В общем, VLIW проиграл по всем фронтам, и это был закономерный процесс.
Для side-channel атаки по времени достаточно иметь более-менее точный таймер, который позволит засекать разницу (например при кэш-промахе) с более-менее приемлемой вероятностью.
Засечь разницу один раз недостаточно. Чтобы прочитать, допустим, пароль в открытом виде, пока он не будет захеширован, сохранён в БД и затёрт, нужно сделать по 2^32 измерений на каждое слово (4 байта) из тех, в которых хранится пароль. Время, в течение которого пароль не успевает затереться, определяется преимущественно понятием программиста о комфортном пользовании его программой (как быстро сервер должен дать ответ). А вот успеет ли атакующий прочитать память через side-channel, зависит уже от того, сколько попаданий/промахов он сможет сделать за это время, то есть от производительности процессора.
Это значит реализовать то, что другие (intel) не осилили.
Насколько я понимаю вопрос, процессорные архитектуры не создаются «на слабо». Это несколько более рациональный процесс.
У VLIW были причины подняться в 1980х, когда паралеллизм на уровне инструкций был ещё мало изучен, а эксперименты в кремнии стоили слишком дорого и шли слишком долго. Тогда перенести оптимизацию с микро- на макропрограммный уровень казалось удачной и многообещающей идеей.
Но годы шли, а обещания сверхэффективных компиляторов так и оставались обещаниями (“...the «Itanium» approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.” − Дональд Кнут, 2008 г.). В то же время опыт в оптимизации имевшихся RISC- и CISC-архитектур накапливался. Все фишки, которые обещал VLIW − multi-issue, OoOE, BP − всё постепенно реализовалось в рамках суперскалярной архитектуры. По мере того, как всё больше места на кристалле стали занимать кеши, разница в транзисторах между сложным управляющим устройством суперскаляра и простым УУ VLIW стала незначащей. Архитектура VLIW проиграла.
Единственными коммерчески осмысленными VLIW-процессорами в истории остались процессоры Transmeta (Crusoe, Efficeon). Они «взлетели» без огромных финансовых вливаний и громких имён и несколько лет жили в энергоэффективном сегменте, пока их не добил Centrino. И ЧСХ компилятор для них так и не был представлен публике. Crusoe выполняли код i386, транслировавшийся «на лету» в VLIW-инструкции при помощи тайной техномагии.
глядя на текущую ситуацию с Meltdown/Spectre/IntelME
Уязвимости side-channel можно было предсказать хоть в XVIII веке, а вот эксплуатировать их имеет смысл только при очень высокой производительности системы. Иначе говоря, Эльбрус ещё не дорос до своих Spectre/Meltdown. И вам упоминать эти проблемы не стоило бы.
Стоит также «обозначить для широкого круга», что строить сегодня процессор на VLIW-архитектуре − это значит топтаться по граблям эдак 15-летней давности.
Talos Lite с процессором будут от 150000 рублей, зато мощнее на порядок кмк. Сопоставимо по производительности − одноплатные ПК типа RockPi N10 или Jetson Nano (+компактность, -расширяемость) или PowerMac G4/G5. Да хоть новые амиги на FPGA. В общем, если задаться целью найти десктопное решение на архитектуре, альтернативной мейнстриму, то есть достаточно вариантов на любой кошелёк, только это будут хорошо известные, проверенные временем ISA с достаточным количеством оптимизированного, поддерживаемого софта, даже с какой-то перспективой развития. А экзотический VLIW без документации с закрытым компилятором под НДА… Зачем?
Я думаю, дело было так. Кто-то от Microsoft упомянул возможность атаковать память через Thunderbolt (DMA attack). Кто-то возразил, что, если иметь устройство в руках, то память можно прочитать и без уязвимости в Thunderbolt: хоть через отладочный интерфейс, хоть в жидком азоте её заморозить. Потом reddit изнасиловал журналиста, и пошло-поехало…
И да, на само́й 500 странице тоже есть пометка, инструкция практически: “You're seeing this error because you have DEBUG = True in your Django settings file.”
Конечно, можно сказать, что вся проблема − это низкий порог входа в Django. Но тогда представьте, чего может наворотить тот же разработчик, если начнёт писать (или тем более дописывать) веб-приложение на чистом Python. Утечкой трейсов дело явно не обойдётся.
Мой посыл в том, что это можно уложить было всё в несколько десятков строк кода (что было реализовано за вечер под пиво на чистом Python'е и он залетал), а не пихать движок весом в 20 мб, написать как бог на душу положит и успокоится.
Я не думаю, что это правильный посыл сейчас. Даже самое минимальное приложение должно безопасно хранить пароли и сессии, экранировать SQL-запросы, очищать ввод от XSS-скриптов, предусматривать CSRF и много чего ещё. Реализовать всё это «за вечер под пиво»? Серьёзно?
С другой стороны вы столько всего наставили на VDS явно не просто так, а для ускорения.
Я ничего не «ускоряю», я просто стараюсь придерживаться лучших практик, насколько могу. Да, если засунуть больше сотни строк в SQLite, или использовать SQL для хранения K-V данных, сайт будет работать медленно. Значит ли это, что Postgres или Redis «ускоряют» сайт? Нет, я бы сказал, что это просто адекватные инструменты.
А то так-то Linux уже лет 10 как можно с тем же успехом установить в VirtualBox, Windows − в KVM с VirtManager. Linux-программы собираются и пакуются для Windows с помощью Cygwin или MSYS2. В обратную сторону − libwine. С иксами тоже нет проблем. К чему весь этот хайп? E3?
Ну, что же вы так мелко плаваете.
Я так не думаю. Скорее всего, всё зависит от напряжения глазодвигательных мышц.
Это всё давно было, ссылки уже протухли, да и я могу что-то путать, но отдельные отголоски ещё встречаются. Вот, например:
Или вот ещё:
Широкоформатные мониторы, если что, не для удобства придумали, а для оптимизации производства − так процент годных матриц выше.
Именно об удобстве, которым традиционно жертвуют в вебе. Редактирование кода, видимо, было последним бастионом здравого смысла.
“For best legibility, typographic manuals suggest that columns should be wide enough to contain roughly 60 characters per line.” − это вики обобщённо цитирует “Typografic Design: Form and Communication”.
В то же время MS DOS, CP/M, Xenix и др. вполне себе назывались и являлись операционными системами. В отличие от Windows 1/2/3.
systemctl --user.requirements.txt), а лучше используйте pipenv или напишите свойsetup.py.Есть ещё мелкие недочёты, а так − неплохой гайд. Пожалуй, даже лучший за последнюю неделю. =)
? </irony>
Нет, ладно, допустим, у HP и Fujitsu были другие профильные активы. Но у Transmeta их точно не было.
В общем, VLIW проиграл по всем фронтам, и это был закономерный процесс.
Засечь разницу один раз недостаточно. Чтобы прочитать, допустим, пароль в открытом виде, пока он не будет захеширован, сохранён в БД и затёрт, нужно сделать по 2^32 измерений на каждое слово (4 байта) из тех, в которых хранится пароль. Время, в течение которого пароль не успевает затереться, определяется преимущественно понятием программиста о комфортном пользовании его программой (как быстро сервер должен дать ответ). А вот успеет ли атакующий прочитать память через side-channel, зависит уже от того, сколько попаданий/промахов он сможет сделать за это время, то есть от производительности процессора.
У VLIW были причины подняться в 1980х, когда паралеллизм на уровне инструкций был ещё мало изучен, а эксперименты в кремнии стоили слишком дорого и шли слишком долго. Тогда перенести оптимизацию с микро- на макропрограммный уровень казалось удачной и многообещающей идеей.
Но годы шли, а обещания сверхэффективных компиляторов так и оставались обещаниями (“...the «Itanium» approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.” − Дональд Кнут, 2008 г.). В то же время опыт в оптимизации имевшихся RISC- и CISC-архитектур накапливался. Все фишки, которые обещал VLIW − multi-issue, OoOE, BP − всё постепенно реализовалось в рамках суперскалярной архитектуры. По мере того, как всё больше места на кристалле стали занимать кеши, разница в транзисторах между сложным управляющим устройством суперскаляра и простым УУ VLIW стала незначащей. Архитектура VLIW проиграла.
Единственными коммерчески осмысленными VLIW-процессорами в истории остались процессоры Transmeta (Crusoe, Efficeon). Они «взлетели» без огромных финансовых вливаний и громких имён и несколько лет жили в энергоэффективном сегменте, пока их не добил Centrino. И ЧСХ компилятор для них так и не был представлен публике. Crusoe выполняли код i386, транслировавшийся «на лету» в VLIW-инструкции при помощи тайной техномагии.
Уязвимости side-channel можно было предсказать хоть в XVIII веке, а вот эксплуатировать их имеет смысл только при очень высокой производительности системы. Иначе говоря, Эльбрус ещё не дорос до своих Spectre/Meltdown. И вам упоминать эти проблемы не стоило бы.
Плюс в документации чёрным по белому: “Never deploy a site into production with DEBUG turned on.”
И да, на само́й 500 странице тоже есть пометка, инструкция практически: “You're seeing this error because you have DEBUG = True in your Django settings file.”
Конечно, можно сказать, что вся проблема − это низкий порог входа в Django. Но тогда представьте, чего может наворотить тот же разработчик, если начнёт писать (или тем более дописывать) веб-приложение на чистом Python. Утечкой трейсов дело явно не обойдётся.
Я ничего не «ускоряю», я просто стараюсь придерживаться лучших практик, насколько могу. Да, если засунуть больше сотни строк в SQLite, или использовать SQL для хранения K-V данных, сайт будет работать медленно. Значит ли это, что Postgres или Redis «ускоряют» сайт? Нет, я бы сказал, что это просто адекватные инструменты.