wizzard

ну вот какого черта у меня есть easy_install (несколько easy_install’ов, для разных питонов), npm и apt-get и я должен разгребать то, что каждый по отдельности из них насооружал?

или ставить все руками? тогда нафига они вообще нужны, эти “очень удобные штуки, которых так не хватает в винде”? в винде, кстати, easy_install работает обычно гораздо лучше, чем в никсах.

единый пакадж менеджер, точнее, идея о том, что он в дистрибутиве один, и других нету  – это такая же утопическая хуйня, как и единая онтология, как и единый язык программирования например.

либо они должны как-то взаимодействовать, либо жить каждый в своем мире (SxS), либо во всяком случае не полагаться на closed world model (“все, чего нет в моей базе – не существует”)

как выключить возвращение на предыдущую страницу по “Backspace” в Chrome?

UPD: И в Safari. И в Opera. Аррргх. Вообще, какой дебил придумал такой хоткей, а также перебиндивать *клавиши редактирования текста*, безо всяких модификаторов (Alt, Ctrl) на абсолютно несвязанные действия?

Всё было бы хорошо, если бы он не срабатывал в текстбоксах, созданных SVG-злементами. Не зря все же Flash и Silverlight вырубают хоткеи браузера, не зря… Толку со всего зтого кавая и открытости, если я не могу сделать банальное текстовое поле?

Еще раз убедился, что подавляющее большинство т.н. «опенсорц стандартов» и «демократических решений, за которые проголосовало большинство» поражены раком design by committee anti-pattern`a с рождения, и зто не лечится. Потому что умных людей МЕНЬШИНСТВО.

И пропагандой своих идей массам заниматься любят далеко не все – зтот навык вообще редко пересекается с навыком придумывать что-то *новое и внятное одновременно*. А БОЛЬШИНСТВО, как правило, способно включить свой скудный умишко только ради того, чтобы *передрать* ОДИН СЦЕНАРИЙ использования ОДНОЙ ФИЧИ, причем ЧЕРЕЗ ЖОПУ. Одна спецификация HTML5 чего стоит - "ааа, мы хотим видео потому что во флеше есть, а нам завидно! мы хотим звуки! мы хотим геотаггинг! уголки круглые! и тени полупрозрачные!". А как зто всё будет работать ВМЕСТЕ, вы подумали? Ну, я уже не говорю о таких извращениях, как WebGL и прочих поделиях издыхающего OpenGL committee, такого сейчас много. Нахуй-нахуй.

/me пошел переписывать код с JS обратно на Silverlight (хотя он тоже раковый, с такой скоростью смены фич и версий изучать библиотеку как-то не очень хочется…)

*** в голову снова приходят с трудом изгнанные фрустрированные мысли начать строить с самого низу, начиная от виртуальной машины, языка и ОС...

кажется, у них всех едет крыша. на фоне Flash, Silverlight и JavaFX, может, идеи по запуску native кода в браузере и хороши, но:

- это ведет к closed-source, мертвым после изменения внутренностей API бинарям, вирусам и антивирусам для веб-приложений (потому что шеллкод, как ни крути, читать не так удобно, как javascript), продлеванию жизни ущербной Интеловской платформы и обрастания браузера толстенными слоями совместимости со старыми версиями бинарей (см. windows :) - конечно, это не столь актуально в свете наличия auto-update, но я не думаю, что каждый вендор будет поддерживать каждый свой продукт пожизненно)

- люди пойдут искать баги в процессорах (впрочем, это в каком-то смысле хорошо, вот только голов лететь будет много)

- и баги в проверялке, коих, если не оставить в х86 только арифметику, очень и очень много

- в любом случае идет лесом аппаратное ускорение видео, 3D и прочее (если дать возможность бросать произвольные данные "туда" - то птичка вылетит из клетки. за примером тоже далеко ходить не надо, тот же Xbox360 взломали именно так)

правильное секурити строится по принципу "все что не разрешено - то запрещено", а не методом огораживания саркофагом реактора.

проблема, собственно, в том, что никакое fuzzy-тестирование не поможет против целенаправленного исследования алгоритмов работы песочницы - это в свое время успешно доказали VMWare и прочие, которые вроде бы должны быть гораздо сильнее изолированы от гостевой ОС.

да и еще мне крайне интересно, как эта штука относится к 64-бит, не-х86, мобильным платформам наконец?

http://googleonlinesecurity.blogspot.com/2008/12/native-client-technology-for-running.html

похоже, придется переходить на замечательный браузер NetFront под PSP :)
(суть не в браузере, а в MIPS процессоре, если кто не понял :) )

crossposted to ru_programming 

Все краем уха где-то слышали, что .NET MSIL-код - интерпретируется. И я слышал. Еще большинство слышало, что для оптимизации его компилируют в native code. Но не всегда.

В итоге, поиски интерпретатора MSIL привели... ни к чему.

Интерпретаторов MSIL нет. Все имеющиеся в природе closed- и open-source реализации - только компилирующие :(

MS .NET Framework - компилирует в x86/x64/IA64 (Win) native, интерпретатора нет
MS .NET Compact Framework (XNA, Silverlight) - компилирует в ARM/PPC/MIPS/x86/x64 (Win/Xbox/WinMobile) код, интерпретатора нет
MS .NET Micro Framework - при билде (!) компилирует в native или direct-threaded код, в зависимости от характеристик устройства. Компиляция производится при билде, а не в run-time (т.е. сборки, не обработанные NGEN'ом, просто отказываются запускаться)
Rotor (SSCLI) - компилирует в x86 native
Mono - до версии 0.2х интерпретировал, теперь там есть два различающихся по оптимальности компилятора. Внимательный просмотр кода версии 2.0.1 следов интерпретатора не нашел (хотя место, куда воткнуть, в принципе есть)
Net60 Compact Framework - компилирует в ARM (Symbian) код на лету
Portable.NET, он же dotGNU - компилирует в direct-threaded код на лету
DotNetAnywhere - компилирует в direct-threaded код на лету.
CrossNet - генерирует C++ код
Volta - генерирует JavaScript код (с одной стороны, это ахтунг, с другой стороны, интерпретатор MSIL на JS был бы еще на два порядка медленнее)


Усе, приехали. Если кто вдруг знает еще дотнет-рантаймы :-D - буду рад узнать. Особенно, если это будет таки чистый MSIL интерпретатор.

А, да. direct-threaded code - это нечто среднее между байткодом и native, по эффективности сравнимо с native кодом, который генерирует неоптимизирующий компилятор.