То, что мы давно ждали, появилось.
Встречайте: jor1k: OpenRISC OR1K Javascript Emulator Running Linux With Network Support

• У каждой виртуалки есть общая сеть с доступом в интернет
• У каждой виртуалки есть telnetd с root без пароля
• У каждой виртуалки есть nmap ;)
• Виртуалка получает IP по DHCP
• Есть поддержка framebuffer

Сеть реализована на websockets со стороны сервера и эмулируемом OpenCores ethmac со стороны VM.

У меня на ноутбуке выдает 120 MIPS с ядром asm.js.
Более подробная информация в блоге автора.
Have fun!

Новые материалы, алгоритмы движения и поведения, инженерные решения и, самое главное, некоторые успехи в создании искусственного интеллекта вселяют робкую надежду на появление первых полноценных андроидов хотя бы при нашей жизни. Но что будет потом? Каковы будут последствия обитания среди нас действительно умных машин? Учёные, писатели и режиссёры на самые разные лады описывают всевозможные сценарии будущего сосуществования людей и андроидов. Диапазон варьируется от апокалиптического порабощения людей до идиллических картин в духе «Приключения Электроника»: «…Вкалывают роботы, / А не человек». С точки зрения коммерческого успеха, большинство фантастических фильмов и книг о роботах обыгрывают гротескные ситуации: войны, угнетение, борьбу то нас с ними, то их с нами. Иными словами, будущее людей и роботов обычно так или иначе окрашено в мрачные тона. Особенно в последние годы сценаристам приглянулась тема безысходного, тягостного будущего. Тем интереснее становятся менее популярные, и потому интересные умеренные точки зрения и сценарии.

Немножко пятничного настроения в субботу. Я думаю, все видели этот код:



Но Aras Pranckevičius пошел еще дальше. Как написать код, который не так просто обнаружить?
И если вначале идут простые примеры, то дальше начинается…

Пора майских праздников давно прошла, а я хочу поделиться впечатлениями от одного маленького голубого телефона, который скрасил мой восьмидневный отдых на берегу Красного моря. А телефончик этот – Just5 CP10s Menthol Space. Кому интересно, чем он примечателен, прошу под кат.

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

Когда я говорил, что нельзя заманивать айтишников на конференции печеньками и плюшками, вы покупали пиццу, дарили футболки и айпэды. Теперь у нас любое мероприятие начинается с поисков халявы. Этим же мероприятия и заканчиваются.

Когда я говорил вкладывать деньги в обучение специалистов, вы продолжали раздавать деньги за рекомендации. Теперь у нас никто не работает, а все рекомендуют.

Мастер Вэ Ку и разработчик под Вин Ды
Никакой разницы
Мастер Вэ Ку и прислужник Разметки
Мастер Вэ Ку и Мастер Ю Никс
Нет наилучшего инструмента
Сон мастера По У Пэ
Лучший редактор
Отчаяние медленного ученика
Постижение Vimscript
Посвящение Vim

Несколько недель назад один доктор из моей лаборатории зашёл на Амазон чтобы купить копию книги Питера Лоуренса The Making of a Fly — классический труд по биологии развития, с которым мы — и другие биологи, работающие с дрозофилами — сверяемся регулярно. Книга, вышедшая в 1992 году, уже не переиздаётся. Но на Амазоне было в продаже 17 копий: 15 использованных от $35.54 и две новых, от $1,730,045.91 (+$3.99 за доставку).

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

В комментариях к недавнему посту про неточный процессор, хабраюзер lol2Fast4U привел ссылку на интересный язык программирования — Entropy.

Суть этого языка в том, что в нем отсутствует детерминированность.

Каждый раз, когда мы обращаемся к каким-либо данным, они искажаются все больше и больше.

Казалось бы, смысл создания этого языка — весьма сомнителен. Но на деле, этот подход может быть полезным для эмуляции как раз тех самых неточных процессоров, о которых идет речь в вышеуказанном посте.

Сами понимаете, что подход к программированию в такой среде должен быть принципиально иным.

Администрация Pirate Bay представила в своем блоге (советую почитать и комментарии) новый раздел сайта, полностью посвященный чертежам для трехмерных принтеров и станков. Создатели файлообменника рассматривают 3d-печать, то есть переход информации из цифровой формы в физическую, как следующий шаг эволюции копирования.