Windows 7 тем же занимается в настройках по умолчанию, правда, не так интенсивно, как это делала Ubuntu :) У меня два физических диска. Первый — системный, второй файлопомойка. Так вот, винда второй периодически останавливает/запускает. Первому винту три года, второму — всего год, так за месяц использования Windows 7 количество стартов на «молодом» винте превысило такой же показатель на «старом».
Да, это, собственно, самая интересная комплектация с 3G/GPS. Обычный T91 уже вовсю распродают, а про Go пока ничего не слышно… Ну что ж, будем ждать :)
Все же хотелось бы иметь возможность полноценно удалить свою учетную запись. Через Jabber её можно фактически задизейблить, но, я так понимаю, все данные все-равно остаются. Например, на file.qip.ru зайти уже будет нельзя, но файлы там все-равно остаются?
Скорее всего это из-за широтно-импульсной модуляции (ШИМ) в схеме управления яркостью ламп подсветки. Попробуйте увеличить яркость на максимум и посмотреть что будет с мерцанием — если оно пропадет, то это ОНО :)
Даже если он разрушится, то ничего страшного не произойдет. Проблема термоядерного синтеза как раз в том, что создать условия для протекания реакции чрезвычайно сложно, не говоря уже об условиях самоподдерживающегося синтеза. В данном случае литиево-свинцовая смесь является очень сильным «предохранителем» :)
На их сайте все написано. Сфера заполнена литиево-свинцовой смесью, которая закачивается в неё через зеленые трубки слева и справа (на картинке). В сфере находится некая цилиндрическая полость, расположенная вертикально. Через эту вертикальную полость прокачивается дейтерий-тритиевое топливо (если я правильно понял, уже в виде плазмы). Сферу окружают пневматические поршни. В поршнях используется сжатый газ, чтобы разогнать ударники до скорости 50 м/с. Ударники одновременно ударяют по сфере, вызывая в литиево-свинцовой смеси волны, которые встретившись в центре образуют мощную ударную волну. За счет этой ударной волны в центре образуются условия, достаточные для кратковременной термоядерной реакции. Выделившиеся в результате реакции быстрые нейтроны тормозятся литиево-свинцовой смесью, которая при этом нагревается. Ну, а дальше скорее всего разогретая смесь идет в темплообменник где испаряет воду для турбины.
Проблема, я так понимаю, как раз в высокоточной синхронизации ударников :)
Смуту вносит значение параметра «smtpd_delay_reject = yes» по умолчанию в Postfix. Так что все работает, даже если все запихнуть в smtpd_recipient_restrictions, но идеологически верно, конечно, проверку по rbl писать в smtpd_client_restrictions. Возможно, даже, с «smtpd_delay_reject = yes» есть какие-то различия в smtpd_*_restrictions, может кто-то знает хорошо Postfix и откомментирует? :)
Небольшое дополнение про postgrey для тех, кого не устраивает задержка в доставке писем. Мое начальство было категорически против любых задержек и, как потом оказалось, не зря — некоторые отправители предпринимали вторую попытку отсылки письма чуть ли не через 15 часов. Пришлось пойти на хитрость. Теперь у меня грейлистятся только «клиенты» pbl.spamhaus.org и те, у кого нет PTR записи. Получилось довольно эффективно и жалоб нет, т.к. в грейлистинг, судя по статистике, попадают всего 2% реальных писем и, как правило, они не на столько важны ибо если IP в pbl.spamhaus.org да или PTR записи нету, то это какие-то несерьёзные люди, которые не могут нормально настроить почтовый сервер :)
Я не только торгую «приблудами», я еще и помогаю (за деньги, причем неплохие) восстанавливать данные разным самодельщикам, с подобных вот «хоронилищ данных».
Я не зря упомянул слово «адекватный» применительно к решению. Если в конторе нет спеца, который понимает как это работает, а все сделано тупо по HOWTO, то туда им и дорога. Не для них, как говорится, делалось.
Есть люди, которые пользуются типовыми, проверенными и надежными решениями, и те, кто пока еще этого не делает.
Не делайте из «проверенных» решений панацею, ломаются они ничуть не реже, чем софтовые поделки (см. выше, если правильно все настраивать). Разница лишь в том, что с софтовой поделкой я сам себе злобный буратино, но мне и карты в руки, и если они прямые, то я все быстро исправлю. В случае с корпоративными решениями мне остается только молиться, звоня в техподдержку, чтобы приехал вменяемый спец. Поверьте, я не адепт поделок, у меня и ваших «проверенных надежных» решений хватает и головной боли с ними (естественно, я их даже пальцем не трогал, железки + установка + настройка — все в комплекте закупалось), так что знаю о чем говорю.
За 10 тысяч? Точно с такой дешевкой связываться не стоит, тут я с вами совершенно согласен.
Очевидно, миллионное решение невозможно заменить на md, я указал то, которое можно. Как бы вы не старались, доказывая что стандартные проверенные решения лучше, Google вам не даст этого сделать, доказав обратное. Я достаточно наработался в корпоративном секторе в России и скажу вам, что здесь (в отличие от России) умеют ценить и деньги и тех, кто может подготовить адекватное решение, а не тупо «слить бабло на сторону».
Нет, я выше уже написал, когда стоимость рабочего времени админа и цена хранимых данных стремится к нулю — отчего бы не поиграться с экспериментами… ;)
Слава богу здесь не так :) Первое растетет пропорционально второму :)
Стандартное решение — это что такое? Кто его стандартизировал? Или вы торгуете корпоративными приблудами и вам обидно, что кто-то может обходиться без вашего железа и делать все софтово и не сильно хуже? Предлагаете для частного FTP-сервера покупать ES за мульён баксов?
Судя по вашей фразе, все что не стадартно, то не нормально. А я вам скажу, что ненормально — это покупать RAID массивы за 10 тыс баксов, когда можно обойтись md. Нормальное решение оно потому и называется нормальным, потому что адекватно задаче, а не стандарту.
Вместе с этим еще можно символы грузовика в шрифте модифицировать, сдвигая на пиксель вверх, тогда и скроллинг плавный будет и грузовик дергаться не будет :)
То есть получается, что организовав комбинированную атаку типа bandwidth consumption + resource starvation можно кого угодно поставить на бабки?
Лучше уж по старинке — фиксированный/безлимитный трафик и фиксированные ресурсы.
А есть здесь кто уже реально пользуется Amazon Web Services или Google Apps Engine?
А то, когда я слышу слова «легко» и «IT» моя рука тянется к пистолету :) Вот например, «легко масштабируется», а не получится ли потом, что вы так намасштабировали, что навсегда будете привязаны к Google и у вас будет всего два выхода — либо продолжать платить Google, либо полностью переписывать приложение, чтобы уйти, например, на собственный хостинг?
Проблема, я так понимаю, как раз в высокоточной синхронизации ударников :)
Я не зря упомянул слово «адекватный» применительно к решению. Если в конторе нет спеца, который понимает как это работает, а все сделано тупо по HOWTO, то туда им и дорога. Не для них, как говорится, делалось.
Не делайте из «проверенных» решений панацею, ломаются они ничуть не реже, чем софтовые поделки (см. выше, если правильно все настраивать). Разница лишь в том, что с софтовой поделкой я сам себе злобный буратино, но мне и карты в руки, и если они прямые, то я все быстро исправлю. В случае с корпоративными решениями мне остается только молиться, звоня в техподдержку, чтобы приехал вменяемый спец. Поверьте, я не адепт поделок, у меня и ваших «проверенных надежных» решений хватает и головной боли с ними (естественно, я их даже пальцем не трогал, железки + установка + настройка — все в комплекте закупалось), так что знаю о чем говорю.
Очевидно, миллионное решение невозможно заменить на md, я указал то, которое можно. Как бы вы не старались, доказывая что стандартные проверенные решения лучше, Google вам не даст этого сделать, доказав обратное. Я достаточно наработался в корпоративном секторе в России и скажу вам, что здесь (в отличие от России) умеют ценить и деньги и тех, кто может подготовить адекватное решение, а не тупо «слить бабло на сторону».
Слава богу здесь не так :) Первое растетет пропорционально второму :)
Судя по вашей фразе, все что не стадартно, то не нормально. А я вам скажу, что ненормально — это покупать RAID массивы за 10 тыс баксов, когда можно обойтись md. Нормальное решение оно потому и называется нормальным, потому что адекватно задаче, а не стандарту.
Лучше уж по старинке — фиксированный/безлимитный трафик и фиксированные ресурсы.
А то, когда я слышу слова «легко» и «IT» моя рука тянется к пистолету :) Вот например, «легко масштабируется», а не получится ли потом, что вы так намасштабировали, что навсегда будете привязаны к Google и у вас будет всего два выхода — либо продолжать платить Google, либо полностью переписывать приложение, чтобы уйти, например, на собственный хостинг?