Pull to refresh
0
0
lostdj @lostdj

User

Send message
Странно, что 90% комментариев — как «хакнуть» картридж.

Одного меня интересует, физика процесса преобразования бутана в электричество при таких малых габаритах и с такими заявленными характеристиками?
Понятно, что скорее всего — горение. Но не на столько это просто.
Честно говоря, это распространенное заблуждение. Например, после такого количества скобок
(function($){$(document).ready(function(){
});}());


лисп кажется раем
Для никсов, кроме Дропбокса есть:
1). Crashplan (3 USD/месяц с неограниченным пространством, правда это обычнейший сервис бэкапа данных. Впрочем, кроме самого Линукса, поддерживается ещё и Солярка).
2). Memopal (50 евро/год за 200 Гб, при этом, кроме троицы винмаклин, есть ещё айОС и Андроид)
3). SpiderOak (100 USD/100Gb/год. Понравится сторонникам СПО и Open-Source, многие компоненты открыты. 2 Гб бесплатно для всех).
4). О Wuala тут был пост, можно пошукать, но условия не очень выгодные на фоне Амазона.
5). Есть ещё ZumoDrive (осторожно, эта ссылка реферральная, вот обычная). Не очень выгодные условия, значительно хуже Дропбокса, но отдал ему предпочтения, ибо на моей машинке Дропбокс раньше тормозил, сейчас работает адекватно, но переносить файлы уже лень. Можно инвайтами набрать 5 Гб).

Если что-то понравится, то внимательно читайте внимательно соглашения, а то потом сольют все данные Кровавой Гэбне и Большому Брату и с концами.
У меня уже несколько лет сделаны фильтры.

Дома 3 кота и собака, а они ужасно линяют: раз в месяц на всех кулерах образовывался ВОЙЛОК (плотный, как валенок).

Проблему решил фильтрами: несколько слоев флизелина на входе воздуха, остальное обклеивается скотчем (все щели до единой, чтобы было герметично).
Домашний кластер работает несколько лет — раз в полгода снимаю фильтры и ставлю новые (правда, приходится полностью герметизировать корпус скотчем снова).

Внутри не то что ни одного волоска — ни пылинки. Температурный режим нормальный.

Вот фотки:

img854.imageshack.us/img854/2407/image1238.jpg
img576.imageshack.us/img576/4327/image1240.jpg
Последний вариант на 6HDD. На борту двухядерный атом + 4GB RAM + 2 гигабитные сетевушки от интела + PCI-Ex4. Кроме это, умеет IMPI. Установлена на нем Ubuntu 10.04 LTS. Прячется у меня в кладовке, хотя жаль, корпус очень красивый да и шума от него нет, но так уж сложилось.
Задачи
1) Аггрегирует бэкапы с домашник компов с глубиной в 30 дней
2) Часть кртических бэкапов льет еще и на Amazon S3
3) Хранит фото, видео, музыку.
4) Раздает инет в домашнюю сеть (к сожалнию большинство роутеров не держит 100мб/c)
5) Держит VPN подключения, если нужно добраться до фаилов не из дома


Fractal Design Array R2


Supermicro X7SPA-HF
UFO landed and left these words here
Извините, но статья не очень компетентна.

«Так как PNG-24 использует полную палитру цветов, сравнивать его с GIF бесполезно – он сразу проигрывает в итоговом размере файла во много раз.» — неправда/преувеличение. 24бита на пиксел — это без учета сжатия, со сжатием — меньше. К тому же не надо палитру хранить.

«PNG vs JPEG
А в этой битве, если прозрачность нам не нужна, PNG проигрывает.» Неправда. Сравнили мягкое с холодным. JPEG лучше подходит для фотографий (куча цветов, все нерегулярное). PNG — для другой графики (градиенты, однотонные участки и т.д. — а такого в вебе, как мне кажется, больше, чем фото). На «своем» поле PNG будет жать значительно лучше, чем JPEG. Обычно даже на глаз легко определить, чем лучше жать.
+JPEG без потерь будет сжимать гораздо хуже, чем PNG без потерь. +Jpeg 100% — это все-таки с потерями, абсолютно бессмысленный формат, как мне кажется, только если совместимость требуется.

«OptiPNG – не имеет графической оболочки и работает из командной строки. По непроверенным данным процент сжатия меньше.» Ну данные действительно непроверенные, это раз. А 2 — имеется плагин OptiPNG к Paint.net. Очень удобный. Ставишь плагин, выбираешь «Save as OptiPNG» (что-то такое), вылезает меню, где можно настроить тип PNG, посмотреть превью сжатого изображения (не попортилось ли чего, например, из-за PNG-8) и его размер для заданных параметров. Когда поставил — радовался, размер почти всех png, созданных в fireworks (flattened png), удалось уменьшить раза в 2. Для пакетной обработки не очень подходит, но для тонкой настройки, я бы сказал, вне конкуренции.

«PNG-8 в большинстве случаев уделывает и GIF, и PNG-24», «Для прозрачных элементов дизайна стоит использовать PNG-8 (очень редко PNG-24)». Не согласен. PNG-8 — когда на картинке не очень много цветов, да. Если цветов много (больше 2^8), то получим сжатие с потерями. Стоит на картинке появиться градиенту, как PNG-24 уделывает PNG-8 ввиду того, что PNG-8 начинает портить картинку. Т.е. говорить, что PNG-24 использовать стоит «очень редко» не стоит. +В маленьких картинках хранение палитры может быть накладно.

Еще можно было бы рассказать про Fireworks PNG, забавная штука.

Чтобы не только все ругать, предложу свой алгоритм действий:
1. Фотография — жмем JPEG'ом. Стоит учесть, что на высоком качестве PNG начинает уделывать JPEG даже на фотографиях.
2. Веб-графика — жмем в пнг. С помощью OptiPNG выбираем наилучший формат: grayscale (его тоже забывать не следует, часто хорошая штука, в статье не было почему-то про него), PNG-8, PNG-24, PNG-32, в таком порядке. Выбираем тот, при котором превью не портится, и размер файла минимальный.
Вводная статья (обзорная) в архитектуру железок и проблему производительности приложений. Если автор хотел раскрыть тему производительности, то, думаю, этого не получилось. Только масса вопросов и домыслов родилась у всех… надо либо раскрыть до конца, либо не соваться в эту тему.

Статья породила в комментариях (мне кажется) холи вар среди сторонников managed и unmanaged языков программирования. Одни ругают их за «обжорство» и говорят «ай да низкоуровневое программирование», другие — отстаивают, хвалят их за скорость разработки приложений. По мне так надо всегда выбирать между оптимизированным, вылизанным, быстрым приложением и скоростью его разработки. В первую очередь заказчику (в конечном счёте мы все пишем для какого-то заказчика) надо работающее (корректно, без багов) приложение и в срок. А уж во вторую очередь приложение оптимизированное. Сразу поймать двух зайцев не удастся, уж поверьте. И лучше получит сначала первое, потом второе.

Кому действительно интересна тема низкоуровневой оптимизации тем рекомендую почитать вот эти вещи:
The Software Optimization Cookbook
The Software Optimization Cookbook, Second Edition
The Software Vectorization Handbook

Для оптимизации на многоядерных железках:
Multi-Core Programming
Optimizing Applications for Multi-Core Processors

Это, так сказать, отправная точка для тех, кому интересно. А вот «клубничка» — Code Optimization: Effective Memory Usage от Криса Касперского.

Information

Rating
Does not participate
Registered
Activity