Обновить
202
Дмитрий Арехта@DaemonI

Пользователь

54
Подписчики
Отправить сообщение
Хм, на iPhones была статья человека, вернее размышления на тему, почему iPhone настолько закрытая платформа, почему нет copy&paste и т.д. После прочтения складывается достаточно четкая картина, что все это было сделано для того, чтобы обезопасить пользователя от проблем, вирусов, червей, утери конфиденциальных данных. Если подобная неприятность имеет место быть, то могу предположить, что это не от недосмотра, а by design.

Да и глупо чинить на пустом месте панику. Если у спецслужб окажется ваш iPhone, то они вытянут гораздо больше интересной информации из таблиц SQL Lite, из ваших СМС и т.д., и вероятность, что там будет крытся что-то более конфиденциальное, чем на скриншотах, выше. И заголовок статьи специально нагнетает ситуацию. iPhone не идеален, но поверьте, дыры есть везде, уязвимости и шансы потери конфиденциальных данных — тоже.
Имелось ввиду, что сначала выполняется ресайзинг до нужных размеров, потом это все рендерится и в итоге тормозов нет. Это как вариант. Ведь выполнять выгрузку приложения и визуальный эффект можно параллельно, а тут скорее последовательные действия.
Нет, специальное API делает скриншот из файла, потом он рендерится на экран и ресайзится естественно в ОЗУ.

Но я не исключаю следующего сценария, что препроцессинг над файлом выполняется не в момент сворачивания, а до него, чтобы гарантировать отсутствие тормозов. Ведь после нажатия на клавишу, в независимости от того, тяжелое приложение или нет, iPod ждет определенное время, а потом выполняет эффект сворачивания.

Так что да, экономия, вы неверно интерпретировали мою мысль %)
Для того, чтобы не забивать ОЗУ, в iPhone экономят на всем, в итоге интерфейс работает без тормозов.
Ну что я могу сказать. Проблема 5 часов — это проблема незнания тех трудностей, с которыми могут столкнутся пользователи. Я лично к такому уже привык, по этому для меня подобные вещи не оказались большой сложностью.

Однако, стоит заметить неприятную тенденцию. Служба поддержки нацеленна только на поддержку Vista, что неприемлимо. Также драйвера под висту достаточно старые на сайте Dell. Я уже привык к тому, что для апдейта драйвера видеокарты, мне нужно качать официальные драйвера и править inf файл. Качество поддержки удручает, видимо в следующий раз прийдется смотреть в сторону продукции других компаний.
ath5 на Software MAC стеке давно с такими работает.

Единственное, что сделано через одно место — это настройка этих самых вай фай соединений и возня с сапликантом.
И все-таки я не могу понять, как для багфиксинга можно выделять 1 день. Конечно можно подтянуть 2-3 более-менее серьезных бага, но достаточно запутанные баги таким образом не выловить. Для этого нужно провести в дебагере 3-4 дня. Не будет ли подобный подход к багфиксингу способствовать тому, что достаточно серьезные баги будут кочевать из итерации в итерацию, т.е. из релиза в релиз?
Не сам планировщик, а та часть, которая отвечает за синхронизацию. Потому как Mutex, Events вызывают функции ядра. Кстати онные примитивы отлично подходят чтобы реализовать синхронизацию user mode и kernel mode кода. А, к примеру, CriticalSection основана на примитивном механизме spin lock, реализовать который можно в самом процессе.
Следует добавить, что примитивы синхронизации для легковесных потоках работают только в пределах одного процесса.
Хорошо придумал: вот вам статья, но если она показалось вам поверхностной, то мопед не мой, я только разместил объяву :)

Кроме того, имеются неточности в самой статье:

> принципе, поток — это процесс, который исполняется на выделенном процессоре, выполнение которого контролирует планировщик (scheduler) ОС, и который может быть заблокирован.

Поток — это не процесс, я думаю тут мешанина из терминов получилась. Лучше написать, что поток — это процесс выполнение на процессоре инструкций и т.д.

> Linux позволяет использовать данные потоки с помощью библиотеки pthread. BSDs тоже поддерживает pthreads. Потоки Windows работают аналогично.

Нууу, кто использовал pthreads и потоки win32, тот знает, что разница в их работе разительна. Например pthreads не умеют делать suspend/resume, win32 потоку нельзя сделать cancel, как в pthread, его можно только нелегальным образом убить. Также средства синхронизации разительно отличаются. Events нет в posix, conditional variables нет в win32 (только в висте) и т.д. То что и pthreads и win32 потоки — preemptive, зависит от операционной системы, а не от поточной модели. Далее можно было рассказать о preemptive и cooperative потоках.

А так, еще один интересный факт. Carbon фреймворк на Mac OS X использует свой трид менеджер, который реализует cooperative модель, когда сама Mac OS X использует preemptive.
А я скажу следующие. По моему мнению:
— Ничего прятать не надо. Почему? Просто потому, что если хабр — это социальная сеть, он моделирует саморегулирующиеся общество, со своими законами, и нормами морали. Так вот. Если человек хороший — это будут знать окружающие его люди. Если плохой — весть эта тоже хорошо распространится. Так вот считайте, что показатели кармы — это харизма человека, хабрасилы — его поступки, как их оценивает общество. Сделал хороший поступок, написал статью — получил плюс и т.д. В реальном обществе харизматичных людей — заметно, также о поступках человека все знают, потому советую показатели не прятать.
— Сама идея состоит вот в чем. Минус в карму — нет ничего плохого, это просто показывает отношение минусующего к человеку, что он ему неприятен, к примеру. А вот в хабрасилу — это с определенной точки плохой поступок по отношению к человеку. Люди могут солить друг другу, но человек который вредит постоянно — опасен для общества. Что делают с опасными людьми? Правильно, они попадают в лапы правосудия. По этому предлагаю взять этот пример из нашей жизни и воплотить на хабре Сама идея состоит в том, чтобы за человеком закреплялся какой-то коэфициент поступкой, т.е. плюсов/минусов. Примерно так, как сказал автор темы. Затем, если человек переступил определенную черту, т.е. много минусовал, есть два варианта:
1. Придать его суду линча, чтобы народ сам с ним имел дело. К примеру, если человек «плохой» — показывать у него в профиле коэфициент, чтобы остальные люди знали, что он волк в овечьей шукре.
2. Предусмотреть какое-то наказание. Например этот коэффициент будет отбирать у человека хабросилу. Нужно просто более точно высчитать вот это вот процентное соотношение. Ведь по сути, если человек много минусует — чинит зло, то у него нужно отнимать эту возможность, читай уменьшать хабросилу.
Да тут обыватели писали этот текст.

«Хотя Chrome отлично проходит тесты Acid3, но де-факто большинство сайтов создавались под конкретные существующие браузеры, а под Chrome их никто не проверял, так что в новом браузере некоторые сайты выглядят не очень хорошо.»

Буд-то на вебките один браузер основан и о Safari все забыли…

«6. Нет выпадающего меню в адресной строке. „

У меня у одного выпадающее меню было?
7 тоже за уши притянуто, пока притянуто…
2 месяца, а как работали над движком, фуллтайм, или свободное время?
Есть рациональное зерно в этих мыслях. Особенно про узкоспециализированные статьи. После одной такой, мне писать на подобную тему расхотелось. А про «Вау спасибо», такая уж человеческая природа, кто успел — того и тапки. Меня например не волнует получение огромного количества хабросилы, это бесполезно. Меня волнует лишь то, чтобы мои статьи адекватно ценились людьми. А тех кому нужна хабрасила — пущай себе пишут, мне жить это не мешает. А вот минусующие все и вся — раздражают, сам бы таких приплопывал бы. Поблагодарил сегодня (в кои-то веки! не пишу я обычно спасибо), человека за статью, и получил отрицательную оценку поста. Господа минусующие, вам что жить статья/комментарий мешает? :)
Вы отличный реверсер. Спасибо за интересный материал :)
Обломали с Mac OS X версией, а я уж было пошел скачативать. Выглядит как Pidgin с возможностью хранения истории на сервере. Вообщем идея понятна и ясна, но вот с таким пользовательским интерфейсом вы врядли сможете привлечь много поклонников.

Более того, определить популярность топика и комментария стало очень тяжело, потому как сила голоса уже не 1, а зависит от хабрасилы/кармы. С одной стороны хорошо, позволяет выделить создающих, от просто читающих. С другой стороны плохо, так как при оценивании теряется объективность ситуации.
Не в айфонах дело, а в качестве материала прежде всего. Иначе скоро места техническим топикам тут не будет :)
Опять будут 10-ки тем про айфоны, сотни байопиков о своем пути, расскази об утерянных мобильниках и прочая прочая. Надежда, что количество перейдет в качество, при текущей аудитории хабра — мало вероятно.

Это все — маркетинг, реклама и прочая шелуха, которая призвана за ваш счет, повысить популярност ресурса. Писать нужно не ради приза, а если есть о чем рассказать.
Я смотрю на хабре популярность статей уходит от чисто технических, и приходит к более социальным. В последнее время, так вообще личные байопики — писк моды. Не думайте, что в других профессиях игра менее интересна %) Да и у каждого свой путь.

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность